Kerberos and 2038 date rollover in effect - how to fix?
Tucks
jez.tucker at rushes.co.uk
Fri Sep 3 13:00:49 EDT 2010
Hello.
I've had a hilariously fun day so far, so I need to pick your brains
so to speak.
When our Kerberos V5 system was setup on FC 8, for reasons quite
unknown, the ticket maxlife was set to 10000 days. Sometime early
this morning (today + 10000 days) >= 2038 bug date and the kerberos
ticket expiry dates wrapped to 1901. Yay!
So... I've altered the ticket_lifetime and renew_lifetime in krb5.conf
and kdc.conf to something far more sensible. I've also altered the
policies and users ticket times accordingly. Services were bounced
post mod.
Though this made remote kadmin work (kadmin.local obv always worked),
when you kinit, the ticket is still set for expiry in 1901. (It's
definitely 1901, not 2001.)
jtucker at elmo ~ 16]$ klist
Ticket cache: FILE:/tmp/krb5cc_2004_mCYQrZ Default principal:
jtucker at MYDOMAIN.CO.UK
Valid starting Expires Service principal
09/03/10 17:39:13 12/14/01 10:10:57
krbtgt/MYDOMAIN.CO.UK at MYDOMAIN.CO.UK
renew until 09/03/10 17:39:13
Kerberos 4 ticket cache: /tmp/tkt2004
klist: You have no tickets cached
Strangely, Linux workstations can login and obtain tickets, though the
kde ticket expiry notifier is rather noisy. OSX workstations will not
login and have temporarily been switched to local accounts. All
systems are ntpd, so time sync client/server is not the issue.
Does anyone have any idea how to force through the new ticket expiry
change? According to all the documentation I've read, it should be
good, but isn't. I've probably missed something trivial.
Rock on Friday night...
Jez
More information about the Kerberos
mailing list