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 escapeanything 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.htmlNote 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?