G'day, Background: Debian GNU/Linux 11 (bullseye) FreeRADIUS Version 3.0.21 Samba Version 4.16.11-Debian (AD) Freeradius does user authentication against the Samba AD backend using ntlm_auth/mschapv2 and this works flawlessly. Problem: I'm looking at the doc for ldap xlat syntax: https://wiki.freeradius.org/modules/Rlm_ldap#ldap-xlat The following ldapsearch query works and returns a list of sAMAccountNames which are members of the 'staff' group. ldapsearch -D "cn=Administrator,cn=Users,dc=foo,dc=bar,dc=com" -w super_secret! -h "localhost" -b "cn=Users,dc=foo,dc=bar,dc=com" -s sub "(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com))" sAMAccountName I am trying to replicate this in an ldap xlate inside the post-auth section like so: update reply { Reply-Message += "AD-Group: %{ldap:ldap:///cn=Users,dc=foo,dc=bar,dc=com?(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com))?sAMAccountName}", } However, freeradius complains: (12) update reply { (12) ERROR: Parsing LDAP URL failed (12) EXPAND AD-Group: %{ldap:ldap:///cn=Users,dc=foo,dc=bar,dc=com?(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com))?sAMAccountName} (12) --> AD-Group: (12) Reply-Message += AD-Group: Questions: 1. Is this sort of query possible using ldap xlat? 2. If so, am I missing something obvious? 3. Is there a way to test/debug ldap xlat expressions which is more efficient/simple than embedding them in the config and testing? Thanks, Chris
On Apr 26, 2024, at 3:42 PM, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
(12) update reply { (12) ERROR: Parsing LDAP URL failed (12) EXPAND AD-Group: %{ldap:ldap:///cn=Users,dc=foo,dc=bar,dc=com?(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com))?sAMAccountName} (12) --> AD-Group: (12) Reply-Message += AD-Group:
FreeRADIUS is just calling the OpenLDAP APIs to parse that URL. So if it fails, it's because OpenLDAP doesn't like the URL. Looking at it closely, you have 3 "/", not 2.
Questions:
1. Is this sort of query possible using ldap xlat?
Yes.
2. If so, am I missing something obvious?
3. Is there a way to test/debug ldap xlat expressions which is more efficient/simple than embedding them in the config and testing?
Use ldapsearch and/ldapurl from OpenLDAP. Or, just update the config & run the server in debug mode. Alan DeKok.
Thanks for your help Alan. It got me off of high-center. On Fri, Apr 26, 2024 at 4:21 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 26, 2024, at 3:42 PM, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
(12) update reply { (12) ERROR: Parsing LDAP URL failed (12) EXPAND AD-Group: %{ldap:ldap:///cn=Users,dc=foo,dc=bar,dc=com?(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com))?sAMAccountName} (12) --> AD-Group: (12) Reply-Message += AD-Group:
FreeRADIUS is just calling the OpenLDAP APIs to parse that URL. So if it fails, it's because OpenLDAP doesn't like the URL.
Looking at it closely, you have 3 "/", not 2.
So as a result of your suggestion below to use ldapurl to help, I ended up reading RFC 4516 (I usually don't do things like that on Friday evening. ;-) The triple slash is supposed to allow the client to select the LDAP server of its choice. [1] That said, I ended up using ldap://localhost/ since my Freeradius is on the same box as my Samba AD DC and it cut out a potential ambiguity.
Questions: 3. Is there a way to test/debug ldap xlat expressions which is more efficient/simple than embedding them in the config and testing?
Use ldapsearch and/ldapurl from OpenLDAP.
The pointer to ldapurl was probably the most helpful part of all. I owe you a coffee. Here is what I actually ended up with which works very nicely: if ("%{ldap:ldap://localhost/cn=Users,dc=foo,dc=bar,dc=com?sAMAccountName?sub?(&(objectclass=user)(memberOf=CN=staff,CN=Users,DC=foo,DC=bar,DC=com)(sAMAccountName=%{reply:User-Name}))}" == "%{reply:User-Name}") { update reply { Reply-Message += "Group: staff", ## Do more foo here. ## } } Thanks again for your help. Chris [1] https://datatracker.ietf.org/doc/html/rfc4516#section-4
participants (2)
-
Alan DeKok -
Christopher Nighswonger