Bug 170056 - libnss_ldap fails to pass password to pam_ldap
Summary: libnss_ldap fails to pass password to pam_ldap
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss_ldap
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-10-06 20:49 UTC by Need Real Name
Modified: 2008-03-09 07:22 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-03-09 07:22:59 UTC
Type: ---
Embargoed:


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

Description Need Real Name 2005-10-06 20:49:37 UTC
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.

Comment 1 Nalin Dahyabhai 2005-10-06 21:21:35 UTC
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 21:27:09 UTC
Created attachment 119691 [details]
/etc/ldap.conf file

Comment 3 Need Real Name 2005-10-06 21:28:01 UTC
Created attachment 119692 [details]
\etc\openldap\ldap.conf

Comment 4 Need Real Name 2005-10-06 21:30:34 UTC
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 21:39:49 UTC
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 21:59:00 UTC
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-07 00:13:18 UTC
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-07 00:14:49 UTC
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 11:05:10 UTC
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.

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