Clock skew too great status code

[Arpit Srivastava]

I have one more observation that I want some clarification on.

When credentials expires, and I immediately call gss_init_sec_context, I
get minor -1765328373 (Requested effective lifetime is negative or too
short)
but after 2-3 minutes, I call gss_init_sec_context again, I get expected
minor code of credentials expired.

What is the reasoning behind this behaviour. I have MIT Krb5 client and
Windows AD KDC.

Arpit

On Thu, Feb 6, 2014 at 9:47 PM, Greg Hudson <ghudson at mit.edu> wrote:

> 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.
>
>