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 <[email protected]> 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. > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
