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