[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Azure AD LDAP / memberOf / Not all groups being assigned to control:LDAP-Group
From:       Nick Porter <nick () portercomputing ! co ! uk>
Date:       2024-03-07 18:44:39
Message-ID: 3311e70a-eb7a-4b87-8e19-de854c2a7ba5 () portercomputing ! co ! uk
[Download RAW message or body]

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
[Attachment #2 (multipart/mixed)]

[Attachment #4 (text/plain)]

On 07/03/2024 18:01, Mike Mercier wrote:
> Has anyone else experienced this?  Is there a knob I have to tune somewhere
> that I am unaware of?
It partly depends on how you are resolving group membership.

Firstly, upgrade to version 3.2.3 (from https://packages.networkradius.com)

Prior to that version there was a hard coded limit on the number of 
groups which would be cached.

In version 3.2.3, that limit only applies if the caching involves doing 
a group name -> DN resolution (i.e. the LDAP server returns names and 
you've asked for DNs to be cached).


For the most efficient group checks, it is worth verifying how the LDAP 
server returns groups and use that form.

I.e. if the server returns names, then set cacheable_name = 'yes' and do 
all your checks using group names.  If the server returns DNs then set 
cacheable_dn = 'yes' and do all your checks using DNs.  This 
significantly reduces the number of LDAP queries that are run.


Nick

-- 
Nick Porter


["OpenPGP_signature.asc" (application/pgp-signature)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--===============6439298141615186042==--

[prev in list] [next in list] [prev in thread] [next in thread]