Ldap group troubles

[Phil Mayers]

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?