Kerberos, PAM, LDAP Authentication failure: pam_krb5 and clock skew

Posted by salo 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 failed
sudo: 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 = true
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
  krb4_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@DOMAIN
sudo: pam_krb5(sudo:auth): (user user) krb5_get_init_creds_password: Clock skew too great
sudo: 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!)

Filed in it 2 comments
2 Comments
Sep 4, 2010
12:39 pm
#1 Christophe :

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.

Oct 11, 2010
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!

Leave a Comment

Name

Email

Website

Previous Post
«
Next Post
»

Switch to our mobile site