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): nss_ldap-234-4 How reproducible: Always 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> * fix for BUG#138 (blind last char remove in ldap.secret)
I can send packet captures but would prefer to email them. Let me know if you would like them.
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 password. 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.
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
(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.
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?
Created attachment 116564 [details] proper patch
len = strlen(b) b[len] is always '\0' last character of a string is b[len-1]
temporary workaround until there is an errate package available: echo -n "yourpassword" > /etc/ldap.secret
Created attachment 116579 [details] SRPM with patch integrated. Builds & fixes problem under FC4
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.
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.
This issue is resolved in FC6. Not sure about 5.