UserDN escape problem and Group membership checking in 3.0.3

[Arran Cudbard-Bell]

> On 20 Nov 2014, at 09:30, Winders, Timothy A <twinders at southplainscollege.edu> wrote:
> 
> On 11/20/14, 8:11 AM, "Alan DeKok" <aland at 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 at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2