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