Azure AD LDAP / memberOf / Not all groups being assigned to control:LDAP-Group
Hello, Freeradius info: freeradius -v radiusd: FreeRADIUS Version 3.0.20, for host x86_64-pc-linux-gnu, built on Jan 4 2023 at 03:22:36 FreeRADIUS Version 3.0.20 more /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS" I've been using pfSense + OpenVPN + FreeRadius, using an Azure AD LDAP backend successfully for quite a while now. This morning I had a user reach out to let me know they are unable to access specific resources via the OpenVPN client. As part of the post-auth, I am creating a Cisco-AVPair to dynamically create rules in pf, this is (was?) working as expected. What I discovered after some digging is that the 'control:LDAP-Group' variable is not being assigned all the groups the user is a member of. Since some groups are missing from the result, some of the post-auth group checks are never hit, so the firewall rule is not being added to the Cisco-AVPair ex: I have the following in the 'ldap' module server = 'ldaps://ldaps.domain.com' identity = '<username>@domain.com' password = '<password>' base_dn = 'dc=domain,dc=com' If I do an ldapsearch for the user using the variables above: ldapsearch -D '$identiry' -w '$password -H '$server' -b '$base_dn' '(&(objectClass=user)(sAMAccountName=<username>))' memberOf | grep ^memberOf | wc -l The command returns 112 groups for the user I have queried. When I run 'freeradius -f -XXX', and monitor the output for the above users login, the number of groups assigned to control:LDAP-Group is only 65. I have a different user who is a member of 70 groups, testing with that user I see the same result from the 'freeradius -f -XXX' output for this user as well, only 65 groups. Has anyone else experienced this? Is there a knob I have to tune somewhere that I am unaware of? Thanks, Mike
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
participants (2)
-
Mike Mercier -
Nick Porter