Bug 291401
| Summary: | cannot authenticate against active directory with nss-ldap | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Dominic Lepiane <dominicl> | ||||
| Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.0 | CC: | dpal, etzion.bar-noy, jplans, sputhenp | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-05-05 19:32:24 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dominic Lepiane
2007-09-14 18:15:20 UTC
Created attachment 196061 [details]
Installation notes
System is RHEL 5, all updates Linux 2.6.18-8.1.10.el5 #1 SMP Thu Aug 30 20:43:28 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux 2 x Xeon dual-core (4 cores total) 4 GB ram I've seen mention of bindpolicy soft vs. hard, non-existant "nvram" group, and comments about using a non-SMP kernel but with various random platforms... I just don't see anything in syslog and I am getting as far as getting getent passwd working so this really seems like a bug of some sort. I was able to reproduce this problem on RHEL5.2 and RHEL5.3 with the same configuration as used by RHEL4. On RHEL4 it is working correctly, while on RHEL5 CPU utilization is sky-high. I attempted some tcpdump on the session to find it queries the DC and does not get answer. The problem disappeared when I entered "ldap_version 2" to /etc/ldap.conf and waited for a short while (killing all processes using 100% CPU) That this doesn't trigger a problem with "ldap_version 2" suggests that this might be related to referral processing, which isn't something the client even tries to do unless ldap_version is set to (or left at the default value of) 3. The 5.5 build links with a newer version of openldap that fixed a few things in this area (notably #472920). Does it make a difference here? As an aside, you may want to try setting "nss_initgroups backlink" in ldap.conf to make use of the group membership information AD prefers clients use -- there's a good chance it'll be faster. It's been a while and I don't remember the work-around, but I've been using "referrals no". I tried removing "referrals no" which definitely used to give me problems, and it works fine now (nss_ldap-253-22.el5_4). So maybe this is fixed? I have also been using different attribute mappings than what's been provided with the stock config in the past. nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute shadowLastChange pwdLastSet nss_map_attribute gecos name nss_map_attribute cn sAMAccountName nss_map_objectclass posixGroup group nss_map_attribute uniqueMember member pam_login_attribute sAMAccountName pam_filter objectclass=User Everything else is fairly stock / generic. System config otherwise works with authconfig. I just tried adding the nss_initgroups backlink as well. This does not appear to have significant impact for our site. Thanks It seems that the problem is addressed in the later versions of the nss_ldap. Closing the bug. |