can't figure out why apache LDAP auth fails
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>
Solution 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.
Solution 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]
Solution 3:
Do you have access to the logs from your LDAP server? They might be helpful in troubleshooting this problem.
Solution 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.