Dourty, Brian R. (IATS) wrote:
Upgrading is what broke this functionality. It works with version 1.0.1. Sometime after that a change was made to rlm_ldap.c. This change modified the ldap_escape_func() function. The way this function works in 1.1.4 and up is different than 1.0.1. Basically, it didn't escape anything in 1.0.1 and now it does.
What we see in 1.1.4/1.1.6 is that a UserDN returned from AD using OpenLDAP looks like this:
CN=Lastname\,Firstname, CN=bla,DC=bla
After the ldap_escape_func() returns it looks like this:
CN\\3dLastname\\5c\\5c\\2cFirstname\\2cCN\\3dbla\\2cDC\\3dbla
The \, gets escaped then translated and becomes \\5c\\5c\\2c which doesn't match \, in the member= results of the group.
Actually now that you mention it I seem to remember this coming up before, and me giving the same answer to someone else: FreeRadius' ldap_escape_func appears very over-zealous. I believe it's only necessary to escape: * ( ) \ NUL ...when substituting values into LDAP filters. FR escapes in addition to this: , + " <
; = (and not NUL, but of course FR can't actually deal with strings containing embedded nulls. Binary types yes, not strings) See: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg34741.h... And: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg22126.h... Note that the post in that latter thread is wrong - RFC2254 only mandates escaping of the chars in my 1st list, and explicitly not the others. However, RFC2254 does *permit* escaping of other chars. I'm guessing AD doesn't process that however and thus the fault. I'd like to know why FR ldap_escape_func was made more strict - was there an actual problem or was it solving a problem that doesn't actually exist?