LDAP group authorization with MSAD

[Nick Porter]

On 23/01/2024 15:33, Nick Schmalenberger wrote:
> Thank you! You put me on the right track, and with doing 
> %{User-Name}@example.com in the user filter, I didn't need to override 
> LDAP-UserDN at all :)
Great
> I can bind as user with the actual DN and use it in the group check too. Either of these work:
>      membership_filter = "(member=%{control:LDAP-UserDn})"
>      membership_attribute = 'memberOf'
>
> Is it better to use memberOf because freeradius already has the user object and doesn't need to make another query? In packet capturing it looks like it requests at least the matching group object too.
>
> Are these just different in performance, or useful in some different situations? Is one more readable or idiomatic in freeradius? Anything else I should consider?

The challenge with LDAP is that each directory is configured 
differently.  E.g. some directories have a memberOf attribute and others 
don't - meaning different approaches have to be taken to resolving group 
membership.

Typically the aim should be to minimise the number of queries being run 
(which you can see from running FreeRADIUS in debug mode).

However, you also need to consider what indexes are set up to ensure 
that the queries are efficient.


Given a memberOf attribute which is part of the user object, I would 
usually choose that option, and then make sure that the "cache" option 
matches the format that the data in that attribute is presented.  This 
is because in that case, the group membership is returned in the same 
LDAP query as finding the user object.

I.e. if the memberOf attribute returns DNs, then use cacheable_dn = 
'yes', and do all your work using those DN formats for group names.

If memberOf returns DNs and you set cacheable_name = 'yes' then further 
queries will be run to map the group DNs to their names.


In addition, if you are using LDAP binds to authenticate, if you have 
not already called the ldap module in authorize, then the first thing 
that FreeRADIUS will do is lookup the user's DN.

This typically means the most efficient thing to do is to call ldap in 
authorize to retrieve the user DN and group membership, before calling 
it again in authenticate to bind as the user.


It's all about understanding how data is returned from the directory, 
and adapting your policy to match that (if possible).


As an aside, with AD, it can also be beneficial to use the Global 
Catalog rather than the standard LDAP port - if all the data you require 
is available in the Global Catalog.  Using the standard LDAP port can 
result in redirects, depending on the base DN that searches are 
performed in.

-- 
Nick Porter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20240123/5a5cf907/attachment.sig>