Home / server / Questions / 70903
In Process
SethG
Asked: 2009-10-03 11:45:39 +0800 CST

can't figure out why apache LDAP auth fails

  • 772

Suddenly, yesterday, one of my apache servers became unable to connect to my LDAP (AD) server. I have two sites running on that server, both of which use LDAP to auth against my AD server when a user logs in to either site. It had been working fine two days ago. For reasons unknown, as of yesterday, it stopped working. The error log only says this:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

I thought perhaps my self-signed SSL cert had expired, so I created a new one for mysite.com, but not for the server hostname itself, and the problem persisted. I enabled debug-level logging. It shows the full SSL transaction with the LDAP server, and it appears to complete without errors until the very end when I get the "Can't contact LDAP server" message. I can run ldapsearch from the commandline on this server, and I can login to it, which also uses LDAP, so I know that the server can connect to and query the LDAP/AD server. It is only apache that cannot connect.

Googling for an answer has turned up nothing, so I'm asking here. Can anybody provide insight to this problem?

Here's the LDAP section from the apache config:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>
linux

14 Answers

  1. A packet trace from the httpd server/LDAP client revealed a message about the CA being unknown.

    TLSv1 Alert (Level: Fatal, Description: Unknown CA)

    I found and added the following option to my httpd.conf:

      LDAPVerifyServerCert          off

    That fixed my issue under CentOS 6. The CentOS 5 httpd servers did not require any modification and had worked all along without the option.

    • 9

  2. I have had an issue similar to this before with AD on Windows 2003: the solution I found was to not bind using the full DN but instead use the user@domain syntax:

    AuthLDAPBindDN [email protected]
    • 2

  3. Do you have access to the logs from your LDAP server? They might be helpful in troubleshooting this problem.

    • 1

  4. I've seen this when a package update causes changes in the client ldap.conf (usually /etc/ldap.conf or /etc/openldap/ldap.conf) and resets the TLS_REQCERT option to a more stringent setting. It can negotiate the SSL properly, but will still fail at the end as it can't validate the certificate chain from a trusted root.

    • 1

  5. You might want to check the clock of the servers. If the time difference is more than a couple of minutes, the authentication ticket will be invalid.

    Although this is not exactly the error message, the 'the other server suddenly gets the same problem' part might indicate such a problem.

    • 1

  6. You need to impoert the LDAP CA certificate to work with LDAPS

    • 1

  7. I have a similar problem, which I've identified by running this command:

    openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. I think mod_ldap uses openssl underneath, so this should be fairly consistent for debugging.

    I compared it against another SSL encrypted server I knew was working. A properly verified SSL connection will show a chain going to a root CA and return 0. A failure of SSL verification will give a number and reason. You can use the output to determine what's going wrong.

    In my case, the LDAP server certs are signed by Verisign, which uses Intermediate CA certs. OpenSSL is unable to verify the cert and the connection is refused ("connection refused by server" is unhelpful).

    • 1

  8. I had a similar problem. I could get the cert with openssl, I could query Active Directory over SSL with ldapsearch on the same ports. Finally I changed to the Microsoft Global Catalog ports 3268 or 3269 and they both worked. The Microsoft Windows 2003 servers had been patched, but that happened days before the problems started occurring.

    • 1

  9. I was implementing LDAPS across all of our servers and also ran into this problem. Does it go away if you revert to plaintext LDAP (Not ideal, but useful to know the source of the problem). If so, I have yet to find a solution, but perhaps together we can isolate a bug in authnz_ldap.

    • 0

  10. I'm assuming that your command-line experiments were using the same "bind user" as in your apache configs. If not, you should check that you have the correct current password.

    In the past, I once had to use the global catalog port instead of the standard LDAP port for the AD domain. I can't remember the reason why. For ldaps as in your url above, this would be port 3269.

    • 0