Re: client's system clock is ahead of KDC system clock

[Marcus Watts]

> Date:Tue, 29 Jan 2013 17:33:47 CST
> To:  Marcus Watts 
> cc:  "kerberos@mit.edu" 
> From:Nico Williams 
> 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  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

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Hi

[vlad]

Deepak,

Actually if your sites are for internal users only you might as well just 
protect the entire site with kerberos authentication, using Apache's mod_krb5  

When your entire site is protected you don't need any special login code in 
your application.  Just get the user identity from REMOTE_USER variable.

If you are on IIS,  all you need to do is to click the checkbox that says  
'Enable Integrated Windows Authentication'

If you have a hybrid site that is accessible to both internal and external 
users, you have to go with the Ken's suggestion.

Good thing about having the entire site proctected is that every browser 
request will be protected by unique token.  This way you will get extra 
protection against people who try to steal authenitcation cookies  Don't worry 
about the performance, kerberos authentication is ligthningly fast.   However,  
if your traffic goes outside of your corporate network you have to use 
encrypted channels either through VPN or HTTPS.

  


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos