CentOS 5.2 LDAP/kerberos authentication fails against Active Directory
I have a CentOS 5.2 installation doing LDAP lookups and kerberos authentication against Active Directory 2003. NSCD is enabled. If no LDAP user logs in to the system for 24 hours (exact number unknown) then the first auth attempt will fail for several attempts but eventually succeed. After the first failure, another LDAP user can log in fine but the original user trying to log in will continue to fail for several attempts (approximately 25 seconds).
Here's my /etc/krb5.conf file: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = DOMAINNAME.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] DOMAINNAME.COM = { kdc = dc1.DOMAINNAME.COM kdc = dc2.DOMAINNAME.COM kdc = dc3.DOMAINNAME.COM admin_server = dc1.DOMAINNAME.COM default_domain = DOMAINNAME.COM } [domain_realm] DOMAINNAME.COM = DOMAINNAME.COM .DOMAINNAME.COM = DOMAINNAME.COM [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } My /etc/ldap.conf with comments removed host lvdc03.DOMAINNAME.COM lvdc02.DOMAINNAME.COM lvdc01.DOMAINNAME.COM base dc=DOMAINNAME,dc=com uri ldap://dc1.DOMAINNAME.COM ldap://dc2.DOMAINNAME.COM ldap://dc3.DOMAINNAME.COM ldap_version 3 binddn cn=**bind user**,cn=Users,dc=DOMAINNAME,dc=com bindpw **bind pass** scope sub timelimit 360 bind_timelimit 250 bind_policy soft idle_timelimit 0 pam_password md5 nss_base_passwd dc=DOMAINNAME,dc=com?sub?&(objectCategory=user)(uidnumber=*) nss_base_shadow dc=DOMAINNAME,dc=com?sub?&(objectCategory=user)(uidnumber=*) nss_base_group dc=DOMAINNAME,dc=com?sub?&(objectCategory=group)(gidnumber=*) nss_base_hosts cn=Computers,dc=DOMAINNAME,dc=com?sub nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid sAMAccountName nss_map_attribute uniqueMember member nss_map_attribute userPassword unixUserPassword nss_map_attribute homeDirectory unixHomeDirectory nss_map_objectclass posixGroup Group pam_login_attribute sAMAccountName pam_filter objectClass=User referrals no nss_initgroups_ignoreusers avahi,lsi,avahi-autoipd,backup,bin,daemon,dbus,dhcp,games,gdm,gnats,haldaemon,hplip,irc,klog,libuuid,list,lp,mail,ma n,messagebus,news,nx,polkituser,proxy,pulse,root,sshd,sync,sys,syslog,uucp,www-data,ftp,digibk,sysadmin,docs,nagios ssl no tls_cacertdir /etc/openldap/cacerts My /etc/nscd file: server-user nscd debug-level 0 paranoia no enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 My /etc/nsswitch.conf file passwd: files ldap shadow: files ldap group: files ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files ldap publickey: nisplus automount: files ldap aliases: files nisplus My /etc/pam.d/system-auth-ac file auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so |
That's a pretty bizarre problem. Does the behaviour change if you disable nscd?
Have you had any other luck figuring out what's going on? - Arch |
No, the behavior does not change if I disable nscd. No, I still have no clue on what's going on.
|
When the LDAP users login, anything show up in the system logs at all?
What about local users, they can login no problem at any time? And what about your nss info? Do either getent passwd or getent group return the correct info during your "blackout" period? Is there anything else that might have an effect on whether users can login like a network mounted home directory? - Arch |
Nothing shows up in the logs. Root can log in and can run getent passwd, getent group, and id $ldapuser with correct results. I had not considered the NFS mounted home directories though. They are mounted with Autofs, but Autofs never gave any kind of error in the logs. If my home directory wasn't mounting, then I would get a permission denied error, not an authentication error. However, I'll look in to it further.
|
Quote:
Assuming you can, to me that seems pretty clear your connection to the directory is fine so maybe Kerberos is the thing to look at but I have much less experience with that (read: next to none). I guess the only thing I know to check there is that your system time is okay. It's not like your system clock has drifted out of that magical 5 minute range and then just happens to get corrected soon thereafter? Somehow, I suspect you've already got your system time checked and under control... Sorry, I don't know what else it could be. - Arch |
AutoFS is definitely not the issue. NSCD was disabled. I started experiencing the problem this morning and managed to log in to a local account on the system. Let's say I have an LDAP user with username foo. If I log in as root, the command '# id foo' fails with "id: foo: No such user". However, the command '# getent passwd' returns the list of users, both local and LDAP, correctly. After waiting a few seconds, the foo user is available again and can be logged in to. So the issue is not Kerberos. The issue is not NSCD. The issue is not AutoFS. That just leaves NSS right?
|
Quote:
Can you check authconfig and see if it shows anything out of place? authconfig --test Thanks, - Arch |
I don't have Kerberos on my systems, but here's my output of authconfig --test for your reference (with disabled sections snipped for brevity):
Code:
caching is disabled |
I had both the host and uri set in /etc/ldap.conf. This was causing some weird output from authconfig --test. I doubt it was significant, but I'm going to try with just the uri set and see what happens.
|
Oh, and the bind_policy can't be changed. I can't have my systems stop responding just because the DCs go down.
|
We are seeing a very similar issue under RedHat 5.1 doing both lookups and authentication using LDAP against Active Directory. NSCD is enable and we have been suspecting it but have not yet found the smoking gun. Have you made any headway since your last post?
|
Nope. No progress. The problem exists on some machines, but not others while they all have identical configurations. If you have any ideas, I'm more than willing to collaborate on solving it.
|
nss_map entries...
Hello,
I've been experiencing the same issue with my setup. To fix it, I had to update the nss_map entries. I replaced/add the following lines to /etc/ldap.conf # Services for UNIX 3.5 mappings nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid msSFU30Name nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute uniqueMember msSFU30PosixMember nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute cn cn pam_login_attribute msSFU30Name pam_member_attribute msSFU30PosixMember pam_filter objectclass=User pam_password md5 As soon, as theses entries were added. I've been able to use AD to auth myself. This map is incomplete, when I want to validate it I use the following commands: - getent passwd - getent shadow - getent group getent passwd --> works like a charm! getent shadow --> seems to work, but there's lots of incompleted fields getent group --> dosen't work! It returns only the local groups There's a minor difference between your setup and mine. I'm NOT using kerberos and I don't intend to! Hopefully this will help you with your setup... If you can fix the group issues. Let me know Thanks -FB PS: Sorry for the bad english, is not my mother tongue |
Quote:
Code:
# RFC 2307 (AD) mappings What I found most effective was getting a LDIF of a sample user (I used my own account typically) and then just looked at which attributes fit for the mappings I wanted. And it shouldn't matter if you use Kerberos auth or not. This is mostly plain LDAP. - Arch |
All times are GMT -5. The time now is 04:40 PM. |