Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 171786 - pam_ldap ignores server authentication
pam_ldap ignores server authentication
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nss_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2005-10-26 10:02 EDT by bugreports2005
Modified: 2015-01-07 19:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 14:52:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Automate test to show that nss_ldap and pam_ldap work correctly. (12.62 KB, text/plain)
2005-10-28 15:53 EDT, Jay Fenlason
no flags Details

  None (edit)
Description bugreports2005 2005-10-26 10:02:33 EDT
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):

How reproducible:

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:
Comment 1 Nalin Dahyabhai 2005-10-27 18:42:58 EDT
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?
Comment 2 bugreports2005 2005-10-28 03:49:44 EDT
(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.
Comment 3 Nalin Dahyabhai 2005-10-28 11:53:15 EDT
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.
Comment 4 Jay Fenlason 2005-10-28 15:53:26 EDT
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.
Comment 5 bugreports2005 2005-10-31 03:16:47 EST
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.
Comment 6 Josh Bressers 2006-10-02 15:58:04 EDT
I'm removing the security keyword from this bug.  This is not a security
Comment 7 RHEL Product and Program Management 2007-10-19 14:52:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.