client's system clock is ahead of KDC system clock

Marcus Watts mdw at umich.edu
Wed Jan 30 16:34:12 EST 2013


> Date:    Tue, 29 Jan 2013 17:33:47 CST
> To:      Marcus Watts <mdw at umich.edu>
> cc:      "kerberos at mit.edu" <kerberos at mit.edu>
> From:    Nico Williams <nico at cryptonector.com>
> Subject: Re: client's system clock is ahead of KDC system clock
> 
> Content-Type: text/plain; charset=UTF-8
> 
> On Tue, Jan 29, 2013 at 5:09 PM, Marcus Watts <mdw at umich.edu> wrote:
> >> Hi, if a client's system clock is one hour ahead of KDC system clock, should
>  I
> >> get a valid TGT?, or
> >> should I get clock skewed error?
> >>
> >> We have clients that are able to get TGT when system clock is ahead of serve
> r c
> >> lock. Any idea if this is client issue? a  KDC server issue?
> >> Thanks
> >
> > Actually it's a perfectly valid case (so far as the kdc is concerned);
> > you're just getting postdated tickets that will be valid in one hour.
> > So if you're patient...
> 
> But the clients generally don't specify a "from" time.  And to get a
> postdated ticket the client would have to set the postdated flag.

I don't remember why now, but I do remember experimenting
with some of this and getting some pretty odd results.

"generally" - is implementation dependent.  And we know this
guy is likely using something besides MIT on unix.  His one hour
off problem is a classic sign of daylight savings time and
non-utc local machine clocks.  windows?  macos 9??

It would certainly be interesting to know more specifically what he's got.

> 
> In practice it will work (see Greg's reply).
> 
> > The more interesting case is if the clock is only a fraction
> > of a second fast.  This isn't a problem for users, but it
> > is a problem for scripts that get a ticket and immediately use
> > it: the result is sometimes the ticket will work, and
> > sometimes it won't.
> 
> That's within the typical (default) skew allowance of 5 minutes.

You're right, and my memory of running into this is conveniently fading.
But this doesn't eliminate the problem.

If you've got an environment of machines that mostly use ntp,
but have enough drift that some of the kdcs are *slightly* ahead
or behind, and your machine happens to pick a kdc that's slightly
ahead, and your application happens to be picky about
clock skew...  Or your client or application or kdc aren't
actually using ntp anymore and silently drift 5 minutes off...
There's a point where you don't necesssarily get complete success or
complete failure, but something inbetween that can be timing dependent.

					-Marcus Watts


More information about the Kerberos mailing list