Bug 171786
Summary: | pam_ldap ignores server authentication | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | bugreports2005 | ||||
Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Jay Turner <jturner> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | fenlason, srevivo | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-10-19 18:52:09 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
bugreports2005
2005-10-26 14:02:33 UTC
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. |