Bug 161437

Summary: nss_ldap adding newline (\n) to password in /etc/ldap.secret
Product: [Fedora] Fedora Reporter: Andrew Rechenberg <arechenberg>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: macgyver, ronny-rhbugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: 253-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-22 15:43:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Reverses the "fix" for PADL bug 138 and allows nss_ldap-234 to connect to Active Directory LDAP server
Patch to SPEC file for nss_ldap as related to this bug
proper patch
SRPM with patch integrated. Builds & fixes problem under FC4 none

Description Andrew Rechenberg 2005-06-23 13:19:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
Trying to use nss_ldap-234-4 against Active Directory for user information.  When fingering a username that's in AD it returns with 'no such user'  This same configuration file works fine with FC2 and 3 (stock or current updated versions of nss_ldap that came with the distro).

Packet captures from the finger command show that nss_ldap is adding a '\n' to the end of the password that is being sent to the AD server.  A capture of an ldapsearch shows no '\n' character being added to the password.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install FC4
2. Configure nss_ldap to connect to an LDAP server (AD in my case ... could be all LDAP servers)


Actual Results:  All user information lookup against the LDAP server fails due to newline (\n) character being added to the password.

Expected Results:  finger, and other commands and logins should return proper information from LDAP server.

Additional info:

Not sure if this line in the Changelog is related, but it could be:

232     Luke Howard <lukeh@padl.com>

        * fix for BUG#138 (blind last char remove in ldap.secret)

Comment 1 Andrew Rechenberg 2005-06-23 14:06:57 UTC
I can send packet captures but would prefer to email them.  Let me know if you
would like them.

Comment 2 Andrew Rechenberg 2005-06-23 14:45:37 UTC
Created attachment 115874 [details]
Reverses the "fix" for PADL bug 138 and allows nss_ldap-234 to connect to Active Directory LDAP server

My suspicion about the Changelog comment was correct.  If I remove the '&&
b[len]' check on line 917 in util.c, then nss_ldap works as expected.

I'm not sure if the PADL "fix" works on non-Active Directory LDAP servers, but
something about AD doesn't like the newline character at the end of the bind

This patch may not be the proper way to solve this issue, but this seems to fix
my issue.

This patch works when adding it to the SPEC file and rebuilding the RPM.  I'll
also attach a patch to the SPEC.

Comment 3 Andrew Rechenberg 2005-06-23 14:48:25 UTC
Created attachment 115875 [details]
Patch to SPEC file for nss_ldap as related to this bug

Just a patch to the SPEC file so that one can include the other patch in this
bug and rebuild the SRPM

Comment 4 Habeeb J. Dihu 2005-06-27 05:32:13 UTC
(In reply to comment #3)
> Created an attachment (id=115875) [edit]
> Patch to SPEC file for nss_ldap as related to this bug
> Just a patch to the SPEC file so that one can include the other patch in this
> bug and rebuild the SRPM

Short version -- I can confirm that the above patches work when authenticating
against stock FC3 or FC4 OpenLDAP servers and this patch should quickly filter
out to Fedora Updates.

This is definitely a show-stopper bug and I would strongly urge the maintainers
to push the fix (either the above or the 'proper' fix) out to Fedora Updates. 
LDAP and all user authentication broke completely for us when upgrading from FC3
to FC4 in a small, but busy internal LAN environment that relies exclusively on
LDAP.  Our FC3 configuration was working fine, but once we upgraded, only root
could login to any of the machines.

Per the above...I tried removing the newline in ldap.secret, adding in a second
newline, and various combinations thereof to no avail.  We're authenticating
against the stock FC3 (and now FC4) OpenLDAP servers...nothing exotic here.

Last, but not least...the README.nss_ldap file does explicitly state (#7 I
believe) that a newline must appear at the end of the password in the
ldap.secret file...weird to me, but hey, I didn't write it.  Our prior working
setup did have a single newline at the end of the password in ldap.secret.

Comment 5 Habeeb J. Dihu 2005-06-27 05:57:13 UTC
I should add that, interestingly enough, root logins using the credentials
stored on the LDAP server worked correctly in all cases.  Our root passwords are
different on each local machine, so it was pretty straightforward to test where
the credentials were getting authenticated.  I suspect root (or it's equivalent)
perhaps takes a different code path that doesn't manifest the bug in question?

Comment 6 Ronny Buchmann 2005-07-10 11:35:30 UTC
Created attachment 116564 [details]
proper patch

Comment 7 Ronny Buchmann 2005-07-10 11:36:55 UTC
len = strlen(b)
b[len] is always '\0'

last character of a string is b[len-1]

Comment 8 Ronny Buchmann 2005-07-10 11:40:58 UTC
temporary workaround until there is an errate package available:

echo -n "yourpassword" > /etc/ldap.secret

Comment 9 Chris Evich 2005-07-11 02:22:23 UTC
Created attachment 116579 [details]
SRPM with patch integrated.  Builds & fixes problem under FC4

Comment 10 Chris Evich 2005-11-09 19:13:34 UTC
Ran into this same problem on FC4 test box.  I built the attached SRPM and
confirmed it does indeed fix the problem.  Not sure if it is or isn't the
"right" fix for the issue, but it did work for me.

Comment 11 Christian Iseli 2007-01-22 10:24:35 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 ?


Comment 12 Andrew Rechenberg 2007-01-22 15:43:02 UTC
This issue is resolved in FC6.  Not sure about 5.