Bug 291401 - cannot authenticate against active directory with nss-ldap
cannot authenticate against active directory with nss-ldap
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss_ldap (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2007-09-14 14:15 EDT by Dominic Lepiane
Modified: 2010-05-05 15:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-05 15:32:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Installation notes (7.38 KB, text/plain)
2007-09-14 14:16 EDT, Dominic Lepiane
no flags Details

  None (edit)
Description Dominic Lepiane 2007-09-14 14:15:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070725 Firefox/

Description of problem:
After configuring RHEL5 server to use Windows 2003 Active Directory servers for user authentication, certain processes usually hang when I try to get user info.  I am just using pam-ldap and nss-ldap so my nsswitch.conf has "files ldap".  I will attach my configuration notes, they are fairly exhaustive.

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

How reproducible:

Steps to Reproduce:
(see attached)

Actual Results:
id <username> hangs, 100% cpu utilization, no output
nscd also goes up to 100% cpu utilization
sshd process for user log hangs when user tried to login (after they provide uid)
getent passwd and getent passwd <username> both work

Expected Results:
id <username> should immediately return user info (homedir, shell, etc)

Additional info:
selinux now disabled, nscd off, nothing comes up in syslog.  Some users I can get "id" info back right away, some take time, but most just don't return.
Comment 1 Dominic Lepiane 2007-09-14 14:16:05 EDT
Created attachment 196061 [details]
Installation notes
Comment 2 Dominic Lepiane 2007-09-14 14:17:09 EDT
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
2 x Xeon dual-core (4 cores total)
4 GB ram
Comment 3 Dominic Lepiane 2007-09-14 14:24:08 EDT
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.
Comment 4 Etzion Bar-Noy 2009-06-05 14:04:56 EDT
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)
Comment 5 Nalin Dahyabhai 2010-05-04 18:44:19 EDT
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.
Comment 6 Dominic Lepiane 2010-05-04 19:39:50 EDT
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.

Comment 7 Dmitri Pal 2010-05-05 15:32:24 EDT
It seems that the problem is addressed in the later versions of the nss_ldap.
Closing the bug.

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