Bug 170056 - libnss_ldap fails to pass password to pam_ldap
libnss_ldap fails to pass password to pam_ldap
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2005-10-06 16:49 EDT by Need Real Name
Modified: 2008-03-09 03:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-09 03:22:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/ldap.conf file (9.16 KB, text/plain)
2005-10-06 17:27 EDT, Need Real Name
no flags Details
\etc\openldap\ldap.conf (455 bytes, text/plain)
2005-10-06 17:28 EDT, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2005-10-06 16:49:37 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):

How reproducible:

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.
Comment 1 Nalin Dahyabhai 2005-10-06 17:21:35 EDT
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?
Comment 2 Need Real Name 2005-10-06 17:27:09 EDT
Created attachment 119691 [details]
/etc/ldap.conf file
Comment 3 Need Real Name 2005-10-06 17:28:01 EDT
Created attachment 119692 [details]
Comment 4 Need Real Name 2005-10-06 17:30:34 EDT
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.
Comment 5 Need Real Name 2005-10-06 17:39:49 EDT
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
Comment 6 Nalin Dahyabhai 2005-10-06 17:59:00 EDT
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.
Comment 7 Need Real Name 2005-10-06 20:13:18 EDT
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.
Comment 8 Need Real Name 2005-10-06 20:14:49 EDT
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.
Comment 9 Christian Iseli 2007-01-22 06:05:10 EST
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 ?

Comment 10 petrosyan 2008-03-09 03:22:59 EDT
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.

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