Kerberos and 2038 date rollover in effect - how to fix?

Jeremy Hunt jeremyh at optimation.com.au
Sun Sep 5 20:06:42 EDT 2010


You do not mention the max_life parameter in the kdc.conf. Have you changed this as this is the relevant parameter?

For good measure you should probably set max_renewable_life as well.

Of course this parameter should be set in the REALMS section of the kdc.conf file.

For good measure I would restart all the krb5kdc processes on the master and slave kdc systems.

You also imply the Linux workstations work and OSX workstations don't. Are there other OS's that fail?

In any case look at how kerberos is integrated in the OSX (and other defective environments if any) systems. There may be some process/interface in the way that is configured in opposition to your KDCs that is causing the problem. It may be that this integrator needs to be bounced so it can take cognizance of the expiry time of the tickets as set by your KDC. I am thinking of something like LDAP or Active Directory getting in the way here.

Good Luck.

On 4/09/2010 3:00 AM, Tucks wrote:
> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>
>
> 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>


-- 

"The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected." -- G. K. Chesterton




More information about the Kerberos mailing list