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: http://www.padl.com/download/nss_ldap.tgz everything worked as expected. Version-Release number of selected component (if applicable): nss_ldap-234-4 How reproducible: Always 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[8006]: 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. Additional info: 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] /etc/ldap.conf file
Created attachment 119692 [details] \etc\openldap\ldap.conf
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 working correctly. 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 ? Thanks.
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.