Bug 197261 - nss_ldap-207-17 breaks windows 2003 AD ldap auth
nss_ldap-207-17 breaks windows 2003 AD ldap auth
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nss_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2006-06-29 14:37 EDT by Matt Flusche
Modified: 2015-01-07 19:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 14:42:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Flusche 2006-06-29 14:37:32 EDT
The nss_ldap-207-17 breaks my AD 2003 authentication via LDAP.  This same 
configuration works fine with the previous nss_ldap-207-15 package (and the 
RHEL4 - nss_ldap-226-13 package).  Please let me know what configuration 
information you need.  I can switch between -17 and -15 packages and easily 
reproduce the failure.  Thanks, Matt
Comment 1 Nalin Dahyabhai 2006-06-29 17:45:09 EDT
Please provide the ldap.conf file, along with more information on what error
messages you're seeing, including any which get logged to either
/var/log/messages or /var/log/secure when you try to authenticate a user.
Comment 2 Matt Flusche 2006-06-29 18:11:01 EDT
No errors in /var/log/messages or /var/log/secure.  The pam_ldap module seems 
to silently fail... From a user perspective, I just get a failed password 

base dc=tvguide,dc=com
binddn cn=xbind,ou=service accounts,ou=universal,dc=tvguide,dc=com
bindpw ******
ldap_version 3
nss_base_group dc=tvguide,dc=com
nss_base_netgroup ou=sudo,ou=universal,dc=tvguide,dc=com
nss_base_passwd dc=tvguide,dc=com
nss_base_shadow dc=tvguide,dc=com
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uid msSFU30Name
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute gecos name
nss_map_objectclass posixGroup group
pam_login_attribute msSFU30Name
pam_password ads
referrals no
scope sub
ssl yes
uri ldaps://tul1ad1.tvguide.com ldaps://tul1ad2.tvguide.com

auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore 
system_err=ignore] /lib/security/$ISA/pam_ldap.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so
Comment 3 Dominic Lepiane 2007-09-14 12:54:58 EDT
I am also trying to authenticate against a MS Windows 2003 AD.  If I run nscd,
nscd goes up to 100% cpu utilization.  The "id" command also goes up to 100% cpu.

However getent works fine either getting the whole passwd table or a single user.
getent passwd
getent passwd username

And the killer is that "id" will work on some users but not others, and if I
reboot, then it changes up which users I can look up and which ones fail.

System info:
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)

The ADs are Win 2003 Server R2 SP1, one is x86, the other is x86_64 but I get
the same failure no matter which I use.

My ldap.conf is similar but I'm using sAMAccountName for uid (and
Comment 4 Nalin Dahyabhai 2007-09-14 13:50:04 EDT
Matt, you're using SSL. Have you downloaded and stored the CA certificate which
signed your server's SSL certificate and configured your client to trust it?

Dominic, I suspect you may be looking at a different problem, given that you're
running RHEL 5 while this bug is filed against RHEL 3, and you're getting
different symptoms.  Wild guess, but is your DNS up and running?

Can you search your directory servers using (from Matt's configuration, adjust
as needed)
  ldapsearch -H "ldaps://tul1ad1.tvguide.com" -x -D "cn=xbind,ou=service
accounts,ou=universal,dc=tvguide,dc=com" -w -b "dc=tvguide,dc=com"

If you turn up connection errors or SSL certificate validation errors, those are
going to need to be solved for nss_ldap before it can be expected to work.
Comment 5 RHEL Product and Program Management 2007-10-19 14:42:37 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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