Red Hat Bugzilla – Bug 171786
pam_ldap ignores server authentication
Last modified: 2015-01-07 19:11:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051001 Firefox/1.0.7
Description of problem:
We wish to authenticate against an LDAP directory on an iPlanet Directory Server. Our /etc/ldap.conf contains the following:
We expect it to contact the server, verify that the server certificate is signed by the authority whose keys are in /etc/ssl/cert.pem, start TLS, and authenticate.
Authentication works, but it doesn't seem much like the tls_checkpeer option does. As a test of functionality we replaced /etc/ssl/cert.pem with the keys of another authority, and pam_ldap still happily grants access to the client.
We believe authenticating the LDAP server is of critical importance when trusting it to grant access to client and to provide it with information such as group memberships. Also, pam_ldap should never trust the server with the user password unless its certificate can be verified.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup tls options in /etc/ldap.conf as above and system-auth to use pam_ldap
2. Put as /etc/ssl/cert.pem a key _NOT_ used for signing the server certificate
Actual Results: pam_ldap grants access to the client.
Expected Results: Connection to server should be closed when the server certificate cannot be verified.
Untrusted server should not be handed the user password.
Untrusted server should not be allowed to grant access to the client.
It appears to fail as expected when I try to reproduce this here. The pam_ldap
module is dynamically linked with libldap. Which version of the openldap
package do you have installed?
(In reply to comment #1)
> It appears to fail as expected when I try to reproduce this here. The pam_ldap
> module is dynamically linked with libldap. Which version of the openldap
> package do you have installed?
Our Red Hat Enterprise Linux 3 workstations have the openldap-2.0.27-20 package
installed. Unless I'm mistaken, we have also tried this with Enterprise Linux 4
with the same result, although not recently.
Server authentication works as expected on Solaris 9 clients, using tools native
I've double-checked that the versions of the nss_ldap and openldap packages on
my test system match yours, and I still can't reproduce the failure. The module
reliably logs a "pam_ldap: ldap_start_tls_s: Connect error" message to
/var/log/messages when certificate validation fails.
Can you attach the contents of your /etc/ldap.conf and /etc/openldap/ldap.conf
files, and the LDIF for a sample user account, to this bug ID? I'd like to rule
out any differences there.
Can you reproduce this with OpenLDAP as your server? The client should behave
the same, but I'd like to rule it out as well.
Created attachment 120515 [details]
Automate test to show that nss_ldap and pam_ldap work correctly.
I'm attaching the automated test I wrote to try to reproduce this problem.
Like Nalin, I've been unable to get it to fail. As you can see in the test,
when the LDAP server has an invalid certificate, nss_ldap does not successfully
connect to the server, so it doesn't see the user, even though it exists in the
We found out the cause of this at last. It turns out server authentication did
take place, but not through /etc/ssl/cert.pem as specified in /etc/ldap.conf.
We had the certificate of the same authority under /usr/share/ssl/certs for
another purpose, and it appears to get used as a fallback if the key in the
specified file does not match - but not if the file doesn't exist, or if it is
We did not realise this would happen, particularly since we are not using the
tls_cacertdir option in /etc/ldap.conf. I'm still looking for documentation on
wether this is correct behaviour, but it sure did baffle us.
I'm removing the security keyword from this bug. This is not a security
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.