In order to authenticate against ActiveDirectory-style uids with backslashes in them the authentication user name contains this character. Unfortunately the LDAP logs are showing that Apache is over-escaping the backslash -- at least on Windows (2000 SP4, all security updates applied). I suspect this above the LDAP SDK layer and thus applies to all platforms, but I could be proven wrong, of course. This is a serious issue to anyone needing to support use of such (existing) directories. Both workarounds and pointers to code areas to investigate (other than "look at the mod_auth_ldap and/or util_ldap sources" -- I know that much) would be greatly appreciated!
It turns out that the Microsoft LDAP SDK escapes these characters on its own! I found the filter escape code in mod_auth_ldap_build_filter in mod_auth_ldap.c and observed that its input and output was exactly what I'd expect. I also note that it's output is what is passed to the LDAP SDK. I commented out the escape code (in the simplest fashion, i.e. yes, I could use strncpy at this point) and then (and only then) am able to authenticate with \, ), (, and * in my user name. I assume this is a Microsoft LDAP SDK feature as my other LDAP SDK experience suggests the escaping done by mod_auth_ldap is required. All the same, I believe we should #if out this filter code when using the Microsoft LDAP SDK -- as it only currently serves to prevent that which it is intended to allow. My change is to add the comments in the code excerpt below taken from mod_auth_ldap.c (sorry, I'm not creating a patch as strncpy would be better, etc, etc): filtbuf_end = filtbuf + FILTER_LENGTH - 1; for (p = user, q=filtbuf + strlen(filtbuf); *p && q < filtbuf_end; *q++ = *p++) { /* Microsoft LDAP SDK does this automatically (!); doing this here causes double-escaping!!! The following code block must therefore be removed when using Microsoft's LDAP SDK. */ /* if (strchr("*()\\", *p) != NULL) { *q++ = '\\'; if (q >= filtbuf_end) { break; } } */ }
I believe your patch is correct, however we need to use a #ifdef to make this determination, to prevent clashes with folks building under OpenLDAP or the Netscape LDAP sdk.
Yes, that's a big reason why I did not provide a patch -- I had not taken the time to investigate the proper #ifdef's, etc, to use.
Patch committed to v2.1.0-dev Please test if this solves this problem.
Doh! I'm sure that will work as it is identical to my fix apart from a proper #if block. I should have taken the 2 extra minutes when I patched this on my own copy to look in apr_ldap.h and see #define APR_HAS_MICROSOFT_LDAPSDK 1 on Windows and done a proper #if block around this. Thanks for rounding out this fix and getting it in. A merge back to 2.0 would be good too :-)
Fixed in v2.0.50-dev.
As the person who provided the patch, I must regretfully re-open this SPR. The patch works great *except* when the character immediately following the \ is a valid hexidecimal character. I'm not sure how to handle this case with the Microsoft LDAP SDK. Hopefully we're missing some simple "behave correctly" flag on the Microsoft LDAP SDK...
Created attachment 12919 [details] Patch to address remaining issues (\[0-9,a-f], e.g. \a, etc)
I discovered Microsoft documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/search_filter_syntax.asp that essentially states "RFC 1960 says...", followed by an accurate quote of this IETF RFC, followed by section titled "Special characters" where they state a completely different means by which they require you to handle all the special characters from the IETF RFC -- without actually stating that they're requiring other syntax than that indicated by the RFC much less why they require this! I produced a patch wherein the Microsoft documentation is obeyed when using their LDAP SDK. This seems to fix the remaining issues, so I've attached the patch (see above).
Is it possible to create a patch for v2.1 also? The patch does not apply cleanly to mod_authnz_ldap.c, not sure why.
Created attachment 12930 [details] Patch against HEAD rather than against 2.0.52
I've attached a patch against mod_authnz_ldap.c as requested. Note that I've only tested this on Windows against Microsoft's LDAP at this point (the problematic case). After pre-processing, there should be no differences in the code for any other platform resulting from my changes.
Committed to HEAD, backport proposed to v2.0
The LDAP code in v2.0 is effectively abandoned, as it's too difficult to fix at this point (most of the fixes have involved major rewrites and have gone in httpd v2.1 and apr v1.1). If this is broken in httpd v2.1, please reopen this bug.
I guess I'll check again in 2.2 whenever it is "stable". I have to support a redistribution of a stable 2.x release, so at this time that would be 2.0.52. Thus I'll keep applying my patch to 2.0.x.
Hello, I just found same problem using 2.2.22-1ubuntu1.4 apache2 package. Seems like this bug still needs to be patched. Any help with this problem will be appreciated.