Eric Covener wrote: > On Mon, Jan 19, 2009 at 7:06 PM, Craig McQueen > <mcquee...@edsrd1.yzk.co.jp> wrote: > >> Eric Covener wrote: >> >> On Mon, Dec 22, 2008 at 10:21 PM, Craig McQueen >> <mcquee...@edsrd1.yzk.co.jp> wrote: >> >> >> I'm trying to do LDAP authorisation with an Active Directory server, and the >> "Base DN" has Japanese characters in it. This should be no problem, but I >> can't get it to work. >> >> The Base DN is something like: >> OU=裾野,OU=管理,DC=edsrd00,DC=local >> The corresponding LDAP URL is something like: >> AuthLDAPURL >> "ldap://server:389/OU=\e8\a3\be\e9\87\8e,OU=\e7\ae\a1\e7\90\86,DC=edsrd00,DC=local?sAMAccountName?sub?(objectClass=*)" >> NONE >> >> I think it has the Japanese characters specified in proper RFC 2255 format. >> So I think there is a problem in the LDAP authentication module in properly >> sending the queries with UTF-8 content in the base DN. The error.log file >> says "[ldap_search_ext_s() for user failed][No Such Object]" which seems to >> indicate that the LDAP server isn't getting a valid base DN. >> >> Any insights on this? >> >> >> packet trace would tell you what was put in the wire compared to a >> working command-line search. >> >> >> I finally got a chance to check this out with Wireshark. I found that the >> Apache server is just putting the URI on the wire as given, backslashes and >> numbers and all. So I guess it's not parsing the backslash codes as RFC 2255 >> specifies. >> >> Does this mean I should submit a bug report? >> > > The RFC URL-escapes everything, have you tried that syntax? APR seems > to know something about that. > I've tried this:
AuthLDAPURL "ldap://server:389/OU=%5ce8%5ca3%5cbe%5ce9%5c87%5c8e,OU=%5ce7%5cae%5ca1%5ce7%5c90%5c86,DC=edsrd00,DC=local?sAMAccountName?sub?(objectClass=*)" NONE (as previous, but "\" replaced by "%5c") It appeared that Apache translated the %5c into backslashes, then put the backslashes and number characters on the wire as-is, without doing any further LDAP backslash un-escaping. I also tried this: AuthLDAPURL "ldap://server:389/OU=%e8%a3%be%e9%87%8e,OU=%e7%ae%a1%e7%90%86,DC=edsrd00,DC=local?sAMAccountName?sub?(objectClass=*)" NONE (as original, but "\" replaced by "%") It seemed that Apache output some other character bytes other than what I expected. Perhaps it was converting to some other character set. E.g. for those first few Japanese characters, instead of E8 A3 BE E9 87 8E it output C3 A8 C2 A3 C2 BE C3 A9 E2 80 A1 C5 BD Any other ideas? Regards, Craig McQueen
