Kerberos, PAM, LDAP Authentication failure: pam_krb5 and clock skew
2 comments
I’ve been fighting with a very ugly issue on my system for the past 2 days now. I’m running an Ubuntu box, having 2 accounts: (i) one local user and (ii) a LDAP user. Most of the time I’m logged in as the LDAP user and do all my work from there. Yesterday evening, out of the blue, while trying to ‘sudo‘ to root from my LDAP account, this failed (‘sudo‘ from the local account worked fine). Moreover, trying to ‘sudo‘ to root from my LDAP account from some cluster boxes worked fine – so this meant there is an issue with my local machine.
Digging into /var/logs/auth.log I saw:
sudo: pam_krb5(sudo:auth): authentication failure; logname=user uid=0 euid=0 tty=/dev/pts/42 ruser= rhost=sudo: pam_unix(sudo:auth): conversation failedsudo: pam_unix(sudo:auth): auth could not identify password for [user]
Not a very intuitive error … especially as I knew the password was right (no caps lock stuff going on). After going through the incredible hassle of reading the /etc/pam.d/ configurations, I ended up in /etc/krb5.conf where I toggled the debug switch from false to true:
[appdefaults]pam = {debug = trueticket_lifetime = 36000renew_lifetime = 36000forwardable = truekrb4_convert = false}
Taking a look at the output in auth.log – the error became clear:
sudo: pam_krb5(sudo:auth): pam_sm_authenticate: entry (0x8000)sudo: pam_krb5(sudo:auth): (user user) attempting authentication as user@DOMAINsudo: pam_krb5(sudo:auth): (user user) krb5_get_init_creds_password: Clock skew too greatsudo: pam_krb5(sudo:auth): authentication failure; logname=user uid=0 euid=0 tty=/dev/pts/42 ruser= rhost=sudo: pam_krb5(sudo:auth): pam_sm_authenticate: exit (failure)
Never thought I’d get an authentication failure because my clock was off by 6 minutes!
After I updated my clock:
sudo ntpdate pool.ntp.org
Everything went back to normal.
Conclusions: debug mode rules, error messages are never explicit and very many times overloaded, always have a backup way of getting into your system (don’t trust LDAP, trust local!)
3:25 pm
Clock accuracy is a must nowadays since many applications, especially those where timing is critical, take it for granted.
NTP or virtualization support for time sync is one of the first things I enable on a new machine.
Offcourse, I don’t do it by hand. Puppet and/or kickstart to the rescue!
« Console based system Next Post
And so you code »











12:39 pm
Yes, that’s true with Kerberos and some other id/auth methods.
In Windows setups, for instance, machines that are outside of the domain (Active Directory) are sometimes ill-configured and do not synchronize through NTP, which causes exactly the same trouble: you can’t connect to the domain accounts.