7

When authenticating against LDAP (Active Directory, Server 2008) from an Apache server I get the following message in the error log:

authentication failure for "/": Password Mismatch

This only happens when the password contains German umlauts (ä, ö, ü). After changing the password or trying with a different account without umlauts in its password the authentication works fine.

Here's my configuration:

AuthType Basic
AuthzLDAPAuthoritative off
AuthLDAPURL "ldap://[SERVER]:3268/DC=[DOMAIN]?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN       "user"
AuthLDAPBindPassword "pass"
require valid-user

I use Apache2 (2.2.16-6+squeeze1) under Debian (2.6.26-2-686). The funny thing is, that the above configuration worked until yesterday (even for passwords with umlauts) and I didn't touch it (I swear ;-) ). I've already found other people with the same problem but no solution.

Does anyone have an idea how to solve the problem or simply what to do next to perhaps identify the erroneous module?

Best regards, Stefan

StefanMacke
  • 81
  • 4

1 Answers1

3

It would appear that there is an encoding issue happening somewhere. I can't tell you where it is, but I can suggest how to find it.

As I understand it, there are 5 places where the encoding could be being incorrectly handled or interpreted. These are:

  1. Browser turning characters into bytes to send to the web server
  2. Apache understanding those bytes to build the password string
  3. Apache + OpenLDAP turning the password string into bytes to send to the LDAP server
  4. Active Directory turning the bytes in the LDAP bind request into something it can compare with it's password database
  5. Active Directory turning characters into bytes when setting the user's password

Assuming you can log into windows as the user, then we know #5 isn't your problem. What you need to do is identify where along the way your problem comes. My hunch is that it's in steps 2 or 3, but I can't be sure.

First up, make sure you're either not using https for talking to the webserver, and not using ldaps to talk to the LDAP server. (You may well not want that for production, but it makes life easier). Now, use wireshark to sniff the traffic for the two legs, browser -> Apache and Apache -> AD. Do you see the correct information there?

Next, set the loglevel in Apache to debug, and see what's printed out there. That won't show you the password, but in debug level it should show you other information like the username. If you use a fake username containing accents, do they correctly show up?

Once you've identified the step that is breaking the encoding, you're about 90% of the way to knowing how to fix it!

Gagravarr
  • 747
  • 3
  • 7
  • 21