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