httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <>
Subject Re: Apache - MS LDAPSDK with multi-byte DN
Date Thu, 17 Jul 2008 15:00:27 GMT
Sequence of events are as follows:
ldap_search_ext_s to an ldap URL and search base that does not contain 
UTF-8 characters.
manager bindDn and bindPw do not contain UTF-8 charaters  (all are 
US-ASCII) only.  The attribute being searched for (uid) does not contain 
UTF-8 characters as well.

For example
ldap://server/cn=Name[UTF-8 character]MoreName, ou=people
                       -> uid=usasciiname (attribute)

The DN returned once Apache pulls it out from the ldap_search_ext_s 
results is now cn=Name?MoreName, ou=people.

Basically the dn returned in the following two lines is already mangled 
with the ? character:
    entry = ldap_first_entry(ldc->ldap, res);
    dn = ldap_get_dn(ldc->ldap, entry);


Eric Covener wrote:
> On Wed, Jul 16, 2008 at 4:55 PM, Andy Wang <> wrote:
>> the case where we're seeing this none of the arguments contain anything
>> other than US ASCII characters.  If you're ldap_search_ext_sW call contains
>> only US-ASCII but the returned DN contains UTF-8 shouldn't this still work
>> or is there something I'm missing here?
> Can you more concretely describe which LDAP call fails?  The sequence
> is roughly:
> authn: Apache searches for a DN that corresponds to the basic auth username
> authn: Apache binds with the retrieved DN and the basic auth password
> authz: Apache may do searches with a base of the retrieved DN.
> You previously implied the failure happened after we'd bind'ed with
> the DN to check the users password, which would mean the failing call
> does in fact have non US-ASCII characters (the DN).  The only
> US-ASCII-safe input in this workflow should be the initial search from
> basic auth -> DN
> If your LDAP data were somehow not the UTF-8 sequence you expected,
> that might be the cause of the unexpected result.

View raw message