Hi,

we changed some Redhat Enterprise Multiprocessor Workstations to authenticate against Active Directory LDAP with OpenLDAP client (not samba with winbind).

Login works fine but we ran in strange problems.
Note: These problems don't appear with Redhat Enterprise 3 (Kernel 2.4) or with Enterprise 4 (Kernel 2.6) booted with Single Processor kernel, only kernel 2.6 Multiprocessor with ldap authenticated user (not local user).

When authenticated against ldap (console or graphic, no difference) and starting a program (process), some background processes which idled before grab the whole cpu time. These are not only processes of this user but also of other ldap authenticated users. System is running at it's limit then. When killing the initial process the system becomes reusable and processes idle again.
Running nscd service does not change behaviour.
We don't know if it's a kernel or a ldap problem or something else.

Anyone has a clue for this strange behaviour?

Regards,

Peter

Hi,

I am getting a similar problem with RHEL5. We have RHEL5 running with an x86_64 kernel on dual xeons (dual core, 4 cores total). Same kind of setup: pam_ldap and nss_ldap, not samba or winbind, with AD servers.

Basically, what happens is if I do some operation that requires the directory, I see nscd go up to 100% cpu and doesn't come down. Some queries return successfully, some return after several seconds, and some just hang also sitting at 100% cpu (on another core, I guess). I'm basically just trying "id <username>" for the handful of users for whom I've setup UNIX attributes in the domain.

Initially, I was seeing a ton of messages in syslog from selinux, but I still get the same behaviour after disabling selinux.

Any advice much appreciated.

This appears to be a problem in all Red Hat builds and their descendants. I’ve reproduced this on RHEL5, CentOS5, FC6 and FC7. My ldap.conf is as follows:

timelimit 30
bind_timelimit 10
idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon
base dc=example,dc=com
binddn cn=<ACCOUNT>,cn=Users,dc=example,dc=com
bindpw <PASSWORD>
bind_policy soft
scope sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid sAMAccountName
nss_map_attribute LoginShell msSFU30LoginShell
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password md5
sasl_secprops maxssf=0
#uri ldap://example.com/
uri ldap://a-dc1.example.com/ ldap://a-dc2.example.com/ ldap://b-dc1.example.com/ ldap://b-dc2.example.com/

One interesting note is I don’t see this behavior when I use just the uri of ldap://example.com/, but if I use a list of FQDN for my Active Directory domain controllers then I can reproduce the issue easily. It seems to be a problem with nss_ldap as sshd fails during the account phase of the login and also hangs taking up 100% of the CPU.

The solution seems to be to add "referrals no" in the /etc/ldap.conf .
The problem is related to the entry of group: files, ldap in nsswitch.conf

"referrals no" seems to solve this for me (RHEL 5, x86_64).