Created attachment 25729 [details] ldif file containing user that doesn't work. Password for the user is the string: two If a user's DN contains a multi-byte character, auth_ldap will not authenticate the user because the multi-byte characters returned by the searchRequest will be converted to ?'s when attempting to bind. For example a user with the following dn: cn=t[UTF-8: 0xE6 0x88 0x91], ou=people UTF-8: 0xE6 0x88 0x91 is the utf-8 character for the chinese word for me. Will not work because the bind request will be for cn=t?,ou=people See this mailing list thread with a discussion on this: http://marc.info/?l=apache-httpd-dev&m=121623942300453&w=2 Attached is an ldif file containing the dn I used.
I was able to get this to work by setting the system locale on the windows server to one that has a codepage mapping for the multi-byte character. I still don't understand exactly how Windows handles UTF-8 codepage enough to explain why this works, but it does appear that if multiple languages are necessary in LDAP DNs that are not all represented within a Windows language, then this method of setting the system locale will probably not work. From William Rowe on the apache-dev mailing list: I'd presume there are ldap_funcW() equivalents which accept unicode (trivial conversion from utf8) which could be leveraged on win32, but there is noone right now who is really focused on improving the msldap32 compatibility.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.