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.

Crap, well if you can get user info, it's not that you're not connected to the directory... Sorry, I guess I should clarify, can you do getent passwd / group with NSCD off?

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?

That's got to be NSS-LDAP. I looked at your config again and I still don't see anything awry... Maybe changing the bind_policy would be good? Sorry, don't know about that.

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

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.

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

I use the RFC 2307 (AD) mappings instead of the Services for UNIX ones. Those will get you closer to mapping regular group memberships rather than relying on the UNIX attributes tab. Here's the mappings I'm using:

This is slightly adjusted from what I had originally posted just to get certain attributes to line-up better.

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