Clock skew too great status code
Greg Hudson
ghudson at MIT.EDU
Thu Feb 6 11:17:47 EST 2014
On 02/06/2014 09:24 AM, Arpit Srivastava wrote:
> When I increase the time at client side, say 2015, I get following error
> codes.
Minor codes can't be deciphered after the fact, because they are just
points in a mapping table; you need to pass them to gss_display_status
to make them meaningful in an email message or log file.
> How to handle such situations ? because I am not getting clock skew
> error even once (I get it only at the time of kinit).
> Pls advice how to handle clock-related problems at client-side.
If you (1) require preauth on user principals, (2) use MIT krb5 1.12 or
later on the client, and (3) have kdc_timesync turned on (as it is by
default), then I think the client should adjust for even large clock
skew values when it gets initial tickets. The client's initial request
may be nonsensical, but it will resync using the time in the
PREAUTH_REQUIRED error from the KDC. The only concern is whether the
KDC will return PREAUTH_REQUIRED for the initial request or whether it
could return NEVER_VALID instead, which would abort the initial ticket
exchange.
Any clock drift *after* the initial tickets are obtained could still
cause problems, but hopefully the clock doesn't drift by five minutes
over eight hours.
More information about the Kerberos
mailing list