Bug 24437 - mod_auth_ldap doubly-escapes backslash (\) characters in uids
Summary: mod_auth_ldap doubly-escapes backslash (\) characters in uids
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap (show other bugs)
Version: 2.0.47
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2003-11-05 16:58 UTC by Jess Holle
Modified: 2015-07-07 08:50 UTC (History)
0 users

Patch to address remaining issues (\[0-9,a-f], e.g. \a, etc) (1.63 KB, patch)
2004-10-01 22:02 UTC, Jess Holle
Details | Diff
Patch against HEAD rather than against 2.0.52 (1.58 KB, patch)
2004-10-04 12:55 UTC, Jess Holle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jess Holle 2003-11-05 16:58:29 UTC
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!
Comment 1 Jess Holle 2003-11-05 18:41:08 UTC
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
   The following code block must therefore be removed when using Microsoft's
        if (strchr("*()\\", *p) != NULL) {
            *q++ = '\\';
            if (q >= filtbuf_end) {
Comment 2 William A. Rowe Jr. 2003-11-14 17:23:18 UTC
  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.
Comment 3 Jess Holle 2003-11-14 17:43:50 UTC
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.
Comment 4 Graham Leggett 2004-05-21 01:16:05 UTC
Patch committed to v2.1.0-dev

Please test if this solves this problem.
Comment 5 Jess Holle 2004-05-21 14:56:33 UTC

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
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 :-)
Comment 6 Graham Leggett 2004-05-21 23:22:25 UTC
Fixed in v2.0.50-dev.
Comment 7 Jess Holle 2004-09-24 19:27:51 UTC
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
Comment 8 Jess Holle 2004-10-01 22:02:59 UTC
Created attachment 12919 [details]
Patch to address remaining issues (\[0-9,a-f], e.g. \a, etc)
Comment 9 Jess Holle 2004-10-01 22:04:17 UTC
I discovered Microsoft documentation at
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).
Comment 10 Graham Leggett 2004-10-03 15:31:21 UTC
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.
Comment 11 Jess Holle 2004-10-04 12:55:28 UTC
Created attachment 12930 [details]
Patch against HEAD rather than against 2.0.52
Comment 12 Jess Holle 2004-10-04 12:58:31 UTC
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.
Comment 13 Graham Leggett 2004-10-05 00:34:39 UTC
Committed to HEAD, backport proposed to v2.0
Comment 14 Graham Leggett 2005-01-21 22:48:40 UTC
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.
Comment 15 Jess Holle 2005-01-21 23:08:14 UTC
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.
Comment 16 Kano 2015-07-07 08:50:54 UTC

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.