Red Hat Bugzilla – Bug 170056
libnss_ldap fails to pass password to pam_ldap
Last modified: 2008-03-09 03:22:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
Description of problem:
Am unable to authenticate using su or ssh as a user in the ldap database using the libnss_ldap-2.3.5.so file that is included with the nss_ldap-234-4 rpm.
After replacing that lib with one I compiled myself from:
everything worked as expected.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ssh testuser1
Actual Results: slapd debug output of authentication packet:
ldap_read: want=73, got=73
0000: 01 03 04 36 75 69 64 3d 74 65 73 74 75 73 65 72 ...6uid=testuser
0010: 31 2c 6f 75 3d 55 73 65 72 73 2c 64 63 3d 69 6e 1,ou=Users,dc=in
0020: 74 72 61 6e 65 74 2c 64 63 3d 7a 65 73 74 79 73 tranet,dc=zestys
0030: 6f 66 74 2c 64 63 3d 63 6f 6d 80 0d 08 0a 0d 7f oft,dc=com......
0040: 49 4e 43 4f 52 52 45 43 54 INCORRECT
(last part is supposed to be the plain-text password, but instead INCORRECT is sent).
This causes this error to appear in the message log:
Oct 6 13:34:53 secure sshd: pam_ldap: error trying to bind as user "uid=testuser1,ou=Users,dc=intranet,dc=zestysoft,dc=com" (Invalid credentials)
Expected Results: Authentication should succeed.
I attempted to rebuild the nss_ldap rpm from the SRPM, but that didn't fix the issue.
Only after replacing the file with nss_ldap version 2.4.3 did everything start to work correctly.
The actual word "INCORRECT" is sent as the password in the bind attempt? Can
you provide your /etc/ldap.conf and /etc/openldap/ldap.conf configuration files?
Created attachment 119691 [details]
Created attachment 119692 [details]
Btw, It looks like the newer nss_ldap doesn't actually fix the problem.. it
simply breaks nss enough to authenticate the user. If I stop the slapd service,
and attempt to restart, the new nss_ldap doesn't allow things to start up again.
:/ Also, at debug level 3 I'm still seeing that "INCORRECT" word, so I don't
have a solution to this problem that I thought I did!
What's strange is I can't grep "INCORRECT" in either the pam_ldap or nss_ldap
source, so I'm lost as to where that's coming from. Also, changing the password
to INCORRECT also doesn't actually make things work correctly either.
Also, I'm correctly able to bind that user using:
ldapsearch -x -W -D 'uid=testuser1,ou=Users,dc=intranet,dc=zestysoft,dc=com' -b
'' -s base -LLL -H ldap://secure.intranet.zestysoft.com/ supportedSASLMechanisms -ZZ
and I'm able to also bind using the nssldap user which is responsible for doing
the nss lookups:
ldapsearch -x -W -D 'cn=nssldap,ou=DSA,dc=intranet,dc=zestysoft,dc=com' -b '' -s
base -LLL -H ldap://secure.intranet.zestysoft.com/ supportedSASLMechanisms -ZZ
The use of "INCORRECT" is something sshd does to avoid timing attacks if it
can't look up information about the user name which the client supplied
("testuser1", in your example). I think that once "getent passwd testuser1"
works, that particular problem will be solved, and this is looking more and more
like a duplicate of bug #166647.
Thank you!!! That was it alright. vi didn't show there was a newline, but a
hexdump of the ldap.secret file showed the extra 0A byte.
I hope this didn't take too much of your time.
Thank you!!! That was it alright. vi didn't show a new line, but hexdump
showed the extra 0A byte. I used dd to truncate the file and that got getent
Thanks for your help.
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Fedora Core 4 is no longer maintained.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.