UserDN escape problem and Group membership checking in 3.0.3
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package) I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query. I have tried various ldap configuration options, none of which quite work. If I remove all the filter settings from the group checking and only use the membership_attribute = "memberOf", I get the following Invalid DN syntax error: rlm_ldap (ldap): Bind successful (11) User object found at DN "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (11) Checking user object membership (memberOf) attributes (11) Waiting for bind result... (11) Bind successful (11) Performing unfiltered search in 'CN=Winders, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (11) Waiting for search result... (11) ERROR: Failed performing search: Invalid DN syntax (11) ERROR: Server said: 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350, best match of: 'CN=Winders, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu' . Notice the first User object found has the correct DN, with the comma in the CN= attribute escaped. This is the way the DN is stored in Active Directory. However, when doing the unfiltered search, the comma is no longer escaped resulting in the Invalid DN syntax. If I remove the membership_attribute and do the member checking in the group, I don¹t get the invalid DN (as the DN is no longer being searched), but the UserDn attribute is escaped differently rlm_ldap (ldap): Bind successful (11) User object found at DN "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (11) Checking for user in group objects (11) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (11) --> (&(objectClass=group)(member=CN\3dWinders\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) ) (11) Waiting for bind result... (11) Bind successful (11) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) )', scope 'sub' (11) Waiting for search result... (11) Search returned no results (11) Search returned not found Again, notice the successful user object found with the correct DN, but when doing the expansion of control:Ldap-UserDn the resulting DN is badly mangled. I found lots of information in the archives about UserDn escaping, but nothing current and no helpful information on how to fix this. Suggestions? -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 19 Nov 2014, at 13:17, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package)
I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query.
Yeah pairparsevalue was molesting the DN string before writing it to the DN attribute. It shouldn't really have been de-escaping \, as it's not something we escape normally, and the LDAP code shouldn't of been calling a function that used pairparsevalue anyway. So i've fixed both those issues. The fix will go in 3.0.5 which'll be released very soon. If you could build from v3.0.x HEAD and check it's resolved, that'd be helpful. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 11/19/14, 1:35 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 19 Nov 2014, at 13:17, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package)
I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query.
Yeah pairparsevalue was molesting the DN string before writing it to the DN attribute.
It shouldn't really have been de-escaping \, as it's not something we escape normally, and the LDAP code shouldn't of been calling a function that used pairparsevalue anyway.
So i've fixed both those issues. The fix will go in 3.0.5 which'll be released very soon. If you could build from v3.0.x HEAD and check it's resolved, that'd be helpful.
Always nice to know I¹ve reported a bug and not just a dumb-ass move! I¹ll dig through the docs to see if I can figure out how to checkout the 3.0.x HEAD branch and build from source. I have the packages installed now, so it might take me a bit to figure it all out Thanks! -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 11/19/14, 1:35 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 19 Nov 2014, at 13:17, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package)
I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query.
Yeah pairparsevalue was molesting the DN string before writing it to the DN attribute.
It shouldn't really have been de-escaping \, as it's not something we escape normally, and the LDAP code shouldn't of been calling a function that used pairparsevalue anyway.
So i've fixed both those issues. The fix will go in 3.0.5 which'll be released very soon. If you could build from v3.0.x HEAD and check it's resolved, that'd be helpful.
OK. I think I have done this correctlyŠ I saved my existing /etc/freeradius configuration files and then removed all the freeradius-3.0.3 packages from the system. I downloaded the v3.0.x.zip file from https://github.com/FreeRADIUS/freeradius-server/archive/v3.0.x.zip I unzipped the file to /usr/local/src and ran ./configure from the directory, looked through the output and corrected all relevant WARNING messages, installing a TON of -dev packages to the system. Finally ran make and make install. I saved the new /usr/local/etc/raddb files and moved my previous /etc/freeradius/* files to /usr/local/etc/raddb/* /usr/local/sbin/radiusd -v reports FreeRADIUS Version 3.0.5, for host x86_64-unknown-linux-gnu I ran /usr/local/sbin/radiusd -XC to check configured files. Fixed the problems with clients.conf (ipaddr format changes between 3.0.3 and 3.0.5?) and finally ran /usr/local/sbin/radiusd -X and connected with my client. I got the same badly escaped DN as before. (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" rlm_ldap (ldap): Reserved connection (2) (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking for user in group objects (12) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (12) --> (&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) ) (12) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) )', scope 'sub' (12) Waiting for search result... (12) Search returned no results (12) Search returned not found Either I downloaded the wrong source files, or the change you thought you corrected didn¹t fix the problem... -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
Not sure how 'live' that zip file is. Use GIT to get the latest code. ... The rest of what you did looks okay (you could have built the deb packages yourself to do standard install - guides are online) alan
On 11/19/14, 2:49 PM, "Winders, Timothy A" <twinders@southplainscollege.edu> wrote:
On 11/19/14, 1:35 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 19 Nov 2014, at 13:17, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package)
I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query.
Yeah pairparsevalue was molesting the DN string before writing it to the DN attribute.
It shouldn't really have been de-escaping \, as it's not something we escape normally, and the LDAP code shouldn't of been calling a function that used pairparsevalue anyway.
So i've fixed both those issues. The fix will go in 3.0.5 which'll be released very soon. If you could build from v3.0.x HEAD and check it's resolved, that'd be helpful.
OK. I think I have done this correctlyŠ
I saved my existing /etc/freeradius configuration files and then removed all the freeradius-3.0.3 packages from the system.
I downloaded the v3.0.x.zip file from https://github.com/FreeRADIUS/freeradius-server/archive/v3.0.x.zip
I unzipped the file to /usr/local/src and ran ./configure from the directory, looked through the output and corrected all relevant WARNING messages, installing a TON of -dev packages to the system. Finally ran make and make install.
I saved the new /usr/local/etc/raddb files and moved my previous /etc/freeradius/* files to /usr/local/etc/raddb/*
/usr/local/sbin/radiusd -v reports FreeRADIUS Version 3.0.5, for host x86_64-unknown-linux-gnu
I ran /usr/local/sbin/radiusd -XC to check configured files. Fixed the problems with clients.conf (ipaddr format changes between 3.0.3 and 3.0.5?) and finally ran /usr/local/sbin/radiusd -X and connected with my client.
I got the same badly escaped DN as before.
(12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" rlm_ldap (ldap): Reserved connection (2) (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking for user in group objects (12) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (12) --> (&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu ) ) (12) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu ) )', scope 'sub' (12) Waiting for search result... (12) Search returned no results (12) Search returned not found
Either I downloaded the wrong source files, or the change you thought you corrected didn¹t fix the problem...
I saw Alan replied, but I’ll reply here to keep the previous message thread in tact… To Alan - I’ll look for the instructions on building the deb packages for the 3.0.5 release and decide if that makes sense for me. I realized in my test above, I only tested the group membership_filter attribute (giving the escape problem above), but did not test test the membership_attribute = "memberOf". I removed the membership_filter and added the membership_attribute and IT WORKS! I’ve snipped some of the debug for clarity, but you can see the unfiltered search is now using the unescaped UserDn! (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking user object membership (memberOf) attributes (12) Performing unfiltered search in 'CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (12) Waiting for search result... (12) Processing group membership value "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (12) User found. Comparison between membership: dn, check: dn (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") -> TRUE So, at least part of the code is correct. -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 19 Nov 2014, at 15:49, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/19/14, 1:35 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 19 Nov 2014, at 13:17, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
I have FreeRadius 3.0.3 installed on Ubuntu 14.0.4 (free radius 3.0.3-ppa1~trustry package)
I have everything setup with Active Directory for user authentication. This is working correctly, but I am having a problem with Active Directory group membership checking. It appears the problem is with the way FreeRadius escapes the UserDN when doing the query.
Yeah pairparsevalue was molesting the DN string before writing it to the DN attribute.
It shouldn't really have been de-escaping \, as it's not something we escape normally, and the LDAP code shouldn't of been calling a function that used pairparsevalue anyway.
So i've fixed both those issues. The fix will go in 3.0.5 which'll be released very soon. If you could build from v3.0.x HEAD and check it's resolved, that'd be helpful.
OK. I think I have done this correctlyŠ
I saved my existing /etc/freeradius configuration files and then removed all the freeradius-3.0.3 packages from the system.
I downloaded the v3.0.x.zip file from https://github.com/FreeRADIUS/freeradius-server/archive/v3.0.x.zip
I unzipped the file to /usr/local/src and ran ./configure from the directory, looked through the output and corrected all relevant WARNING messages, installing a TON of -dev packages to the system. Finally ran make and make install.
I saved the new /usr/local/etc/raddb files and moved my previous /etc/freeradius/* files to /usr/local/etc/raddb/*
/usr/local/sbin/radiusd -v reports FreeRADIUS Version 3.0.5, for host x86_64-unknown-linux-gnu
I ran /usr/local/sbin/radiusd -XC to check configured files. Fixed the problems with clients.conf (ipaddr format changes between 3.0.3 and 3.0.5?) and finally ran /usr/local/sbin/radiusd -X and connected with my client.
I got the same badly escaped DN as before.
(12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" rlm_ldap (ldap): Reserved connection (2) (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking for user in group objects (12) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (12) --> (&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) ) (12) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\5c\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) )', scope 'sub' (12) Waiting for search result... (12) Search returned no results (12) Search returned not found
Either I downloaded the wrong source files, or the change you thought you corrected didn¹t fix the problem...
No, the fix corrected the original problem. Note that:
CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu
Now has \, which is correct. Alan and I just discussed this offline, and we think we've determined the correct fix. The issue is with the string expansion code. When it finds an attribute expansion in the string such as %{control:Ldap-UserDN}, it tries to make it safe by escaping chars with special meanings like \r \n \. It does this *even* if an escaping callback is provided by the module wanting to do the string expansion. So before the LDAP escape function ever gets the string "CN=Winders\, Tim" it has become "CN=winders\\, Tim". Which then gets encoded to "CN\3dWinders\5c\5c\2c Tim". The fix appears to be, to hand off escaping completely to the escape function if one is set by the module, and to do the normal escaping otherwise. I'll add a fix, but it'll probably go into 3.0.6 as this may change other behaviour. -- Regarding liveness of zip files, that one will be the HEAD of the repo. -- Regarding building debs 'make deb' -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 11/19/14, 3:57 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
Alan and I just discussed this offline, and we think we've determined the correct fix.
The issue is with the string expansion code. When it finds an attribute expansion in the string such as %{control:Ldap-UserDN}, it tries to make it safe by escaping chars with special meanings like \r \n \.
It does this *even* if an escaping callback is provided by the module wanting to do the string expansion.
So before the LDAP escape function ever gets the string "CN=Winders\, Tim" it has become "CN=winders\\, Tim".
Which then gets encoded to "CN\3dWinders\5c\5c\2c Tim".
The fix appears to be, to hand off escaping completely to the escape function if one is set by the module, and to do the normal escaping otherwise.
I'll add a fix, but it'll probably go into 3.0.6 as this may change other behaviour.
-- Regarding liveness of zip files, that one will be the HEAD of the repo. -- Regarding building debs 'make deb'
You guys rock! I¹m happy with the current solution and will be looking for the 3.0.6 release for the complete fix! -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 19 Nov 2014, at 17:07, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/19/14, 3:57 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
Alan and I just discussed this offline, and we think we've determined the correct fix.
The issue is with the string expansion code. When it finds an attribute expansion in the string such as %{control:Ldap-UserDN}, it tries to make it safe by escaping chars with special meanings like \r \n \.
It does this *even* if an escaping callback is provided by the module wanting to do the string expansion.
So before the LDAP escape function ever gets the string "CN=Winders\, Tim" it has become "CN=winders\\, Tim".
Which then gets encoded to "CN\3dWinders\5c\5c\2c Tim".
The fix appears to be, to hand off escaping completely to the escape function if one is set by the module, and to do the normal escaping otherwise.
I'll add a fix, but it'll probably go into 3.0.6 as this may change other behaviour.
-- Regarding liveness of zip files, that one will be the HEAD of the repo. -- Regarding building debs 'make deb'
You guys rock!
I¹m happy with the current solution and will be looking for the 3.0.6 release for the complete fix!
Ok, pushed the fix. If you can confirm it works tomorrow, we can probably sneak it in 3.0.5. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 11/19/14, 10:31 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
Ok, pushed the fix. If you can confirm it works tomorrow, we can probably sneak it in 3.0.5.
Yes. I will test that in the next couple of hours and let you know. Is there a specific place, URL, instruction, to make sure I download the correct code to compile? -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 20 Nov 2014, at 14:02, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
Yes. I will test that in the next couple of hours and let you know.
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/archive/v3.0.x.zip :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Winders, Timothy A wrote:
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x And click on the "download zip" button on the right hand side. Alan DeKok.
On 11/20/14, 8:11 AM, "Alan DeKok" <aland@deployingradius.com> wrote:
Winders, Timothy A wrote:
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x
And click on the "download zip" button on the right hand side.
Downloaded and installed The problem with membership_filter seems to be resolved. I still see the escaping happening, but, the user in group object is found. (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" rlm_ldap (ldap): Reserved connection (2) (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking for user in group objects (12) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (12) --> (&(objectClass=group)(member=CN\3dWinders\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) ) (12) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) )', scope 'sub' (12) Waiting for search result... ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. (12) User found in group object rlm_ldap (ldap): Released connection (2) (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") -> TRUE removing the membership_filter and adding the membership_attribute = "memberOf" directive also continues to work: (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking user object membership (memberOf) attributes (12) Performing unfiltered search in 'CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (12) Waiting for search result... (12) Processing group membership value "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (12) User found. Comparison between membership: dn, check: dn rlm_ldap (ldap): Released connection (2) (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") -> TRUE So, from my limited testing, this appears to be working correctly for both configuration option. Thank you!
On 20 Nov 2014, at 09:30, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/20/14, 8:11 AM, "Alan DeKok" <aland@deployingradius.com> wrote:
Winders, Timothy A wrote:
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x
And click on the "download zip" button on the right hand side.
Downloaded and installedŠ
The problem with membership_filter seems to be resolved. I still see the escaping happening, but, the user in group object is found.
Great, that's exactly how it should work. What's fun is it appears both forms of escaping are allowed by RFC 4514 so it can either be \<hex><hex> or \<special>. I just tested this would with our OpenLDAP directory and it returned: (0) ldap: Added control:Ldap-Group with value "cn=employees\2C foo,ou=groups,dc=networkradius,dc=com" (0) ldap: Added control:Ldap-Group with value "employees, foo" Which suggests that it's up to the directory server what escape format it wants to use to fix special chars in DNs, and that some directories will normalise the DNs internally (i passed cn=employees\, foo). So we should probably normalise any DNs we want to compare to one form or the other *before* comparing them. Standards are great :(
(12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") { (12) Searching for user in group "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" rlm_ldap (ldap): Reserved connection (2) (12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking for user in group objects (12) EXPAND (&(objectClass=group)(member=%{control:Ldap-UserDn})) (12) --> (&(objectClass=group)(member=CN\3dWinders\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) ) (12) Performing search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu' with filter '(&(objectClass=group)(member=CN\3dWinders\5c\2c Tim \280552\29\2cOU\3dStudents\2cOU\3dSPC\2cDC\3dsouthplainscollege\2cDC\3dedu) )', scope 'sub' (12) Waiting for search result... ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed.
Hmm, well i've never seen that before. Do you have additional ldap debugging enabled?
(12) User found in group object rlm_ldap (ldap): Released connection (2) (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") -> TRUE removing the membership_filter and adding the membership_attribute = "memberOf" directive also continues to work:
(12) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (12) Checking user object membership (memberOf) attributes (12) Performing unfiltered search in 'CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (12) Waiting for search result... (12) Processing group membership value "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (12) User found. Comparison between membership: dn, check: dn rlm_ldap (ldap): Released connection (2) (12) if (LDAP-Group == "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu") -> TRUE
Yes, that means your user objects also have memberOf attributes that point to group objects. You'll find that LDAP-Group == 'Students Security Group' will also work, for both cases, if you set group.name_attribute. The LDAP code is smart enough to tell the difference between when you want to check a DN and when you want to check a name, and do all the cross conversions. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 11/20/14, 9:48 AM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 20 Nov 2014, at 09:30, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/20/14, 8:11 AM, "Alan DeKok" <aland@deployingradius.com> wrote:
Winders, Timothy A wrote:
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x
And click on the "download zip" button on the right hand side.
Downloaded and installedŠ
The problem with membership_filter seems to be resolved. I still see the escaping happening, but, the user in group object is found.
(12) Waiting for search result... ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed.
Hmm, well i've never seen that before. Do you have additional ldap debugging enabled?
Nope. I'm just running "radiusd -X" and copying the (relevant) parts of the debug. This time it doesn't show up in the debug. It's (highly likely) that my configurations are less than optimal. 8-)
You'll find that LDAP-Group == 'Students Security Group' will also work, for both cases, if you set group.name_attribute.
Confirmed! (27) if (LDAP-Group == "Students Security Group") { (27) Searching for user in group "Students Security Group" rlm_ldap (ldap): 0 of 0 connections in use. You probably need to increase "spare" rlm_ldap (ldap): Opening additional connection (7) rlm_ldap (ldap): Connecting to ldap.southplainscollege.edu:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (7) (27) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (27) Checking user object membership (memberOf) attributes (27) Performing unfiltered search in 'CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (27) Waiting for search result... (27) Processing group membership value "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (27) Converting group DN to group Name (27) Performing unfiltered search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (27) Waiting for search result... (27) Group name is "Students Security Group" (27) User found. Comparison between membership: name (resolved from DN), check: name rlm_ldap (ldap): Released connection (7) -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 20 Nov 2014, at 11:24, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/20/14, 9:48 AM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 20 Nov 2014, at 09:30, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/20/14, 8:11 AM, "Alan DeKok" <aland@deployingradius.com> wrote:
Winders, Timothy A wrote:
Is there a specific place, URL, instruction, to make sure I download the correct code to compile?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x
And click on the "download zip" button on the right hand side.
Downloaded and installedŠ
The problem with membership_filter seems to be resolved. I still see the escaping happening, but, the user in group object is found.
(12) Waiting for search result... ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed. ber_get_next failed.
Hmm, well i've never seen that before. Do you have additional ldap debugging enabled?
Nope. I'm just running "radiusd -X" and copying the (relevant) parts of the debug. This time it doesn't show up in the debug. It's (highly likely) that my configurations are less than optimal. 8-)
You'll find that LDAP-Group == 'Students Security Group' will also work, for both cases, if you set group.name_attribute.
Confirmed!
(27) if (LDAP-Group == "Students Security Group") { (27) Searching for user in group "Students Security Group" rlm_ldap (ldap): 0 of 0 connections in use. You probably need to increase "spare" rlm_ldap (ldap): Opening additional connection (7) rlm_ldap (ldap): Connecting to ldap.southplainscollege.edu:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (7) (27) Using user DN from request "CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu" (27) Checking user object membership (memberOf) attributes (27) Performing unfiltered search in 'CN=Winders\, Tim (0552),OU=Students,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (27) Waiting for search result... (27) Processing group membership value "CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu" (27) Converting group DN to group Name (27) Performing unfiltered search in 'CN=Students Security Group,OU=Standard Groups,OU=Groups,OU=SPC,DC=southplainscollege,DC=edu', scope 'base' (27) Waiting for search result... (27) Group name is "Students Security Group" (27) User found. Comparison between membership: name (resolved from DN), check: name rlm_ldap (ldap): Released connection (7)
Excellent. I've pushed a fix for the escaping/normalisation issue as well. If you do a group check for: cn=group\2c bar,ou=example,ou=org the code will convert it to cn=group\, bar, ou=example,ou=org and likewise if the directory returns: cn=group\2c bar,ou=example,ou=org it'll be converted to cn=group\, bar, ou=example,ou=org before comparison. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 11/20/14, 5:04 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
(27) Group name is "Students Security Group" (27) User found. Comparison between membership: name (resolved from DN), check: name rlm_ldap (ldap): Released connection (7)
Excellent.
I've pushed a fix for the escaping/normalisation issue as well.
If you do a group check for:
cn=group\2c bar,ou=example,ou=org
the code will convert it to
cn=group\, bar, ou=example,ou=org
and likewise if the directory returns:
cn=group\2c bar,ou=example,ou=org
it'll be converted to
cn=group\, bar, ou=example,ou=org
before comparison.
Most excellent! Will this be in the 3.0.5 release or part of the 3.0.6 code? -- Tim Winders Associate Dean of Information Technology South Plains College (806) 716-2369
On 21 Nov 2014, at 09:11, Winders, Timothy A <twinders@southplainscollege.edu> wrote:
On 11/20/14, 5:04 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
(27) Group name is "Students Security Group" (27) User found. Comparison between membership: name (resolved from DN), check: name rlm_ldap (ldap): Released connection (7)
Excellent.
I've pushed a fix for the escaping/normalisation issue as well.
If you do a group check for:
cn=group\2c bar,ou=example,ou=org
the code will convert it to
cn=group\, bar, ou=example,ou=org
and likewise if the directory returns:
cn=group\2c bar,ou=example,ou=org
it'll be converted to
cn=group\, bar, ou=example,ou=org
before comparison.
Most excellent! Will this be in the 3.0.5 release or part of the 3.0.6 code?
Everything went into 3.0.5 after careful review of the other modules that register escape functions :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Stefan Paetow -
Winders, Timothy A