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: host <servername.serverdomain> tls_checkpeer yes tls_cacertfile /etc/ssl/cert.pem ssl start_tls 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): nss_ldap-207-17 How reproducible: Always 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 3. login. 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. Additional info:
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 to Solaris.
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 LDAP database.
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 empty. 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 vulnerability.
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: http://www.redhat.com/security/updates/errata/ 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.