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.html And: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg22126.html 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? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html