On 02/05/2014 03:36 AM, Arpit Srivastava wrote: > -1765328373 KRB5KDC_ERR_NEVER_VALID Requested effective lifetime is > negative or too short
This means the KDC responded with protocol error 11 (KDC_ERR_NEVER_VALID), which means that based on the requested end time, the ticket would be immediately invalid. This error would result when (a) the client's clock is so far in the past that its requested end time is before the current time, and (b) the KDC implementation is Heimdal or (I think) Active Directory. The MIT krb5 KDC doesn't generate this code, I believe. > and > -1765328347 KRB5KRB_AP_ERR_SKEW Clock skew too great This code is generated when a timestamp which is supposed to be close to the current time is more than five minutes off. This could be the timestamp in an authenticator (for a TGS-REQ or an AP-REQ), the timestamp in encrypted timestamp preauth, or a similar situation. Generally it means your clock is off by more than five minutes. > I also obseved that, in case of clock skew is great - I am getting > credentials expired error code instead of clock skew too great error code. > Is there any explaination for this behaviour. Let's say you want ten-hour tickets but your client's clock is nine hours in the past. The client computes an end time which is one hour after the KDC's current time, so the KDC issues a one-hour ticket. The client may have a mechanism which adjusts the effective time for TGS and AP-REQs, but one hour later, the ticket expires. If the client's clock is super far in the past, like a full day, then it would asks for a ticket with an end time in the past. An AD or Heimdal KDC would respond with KDC_ERR_NEVER_VALID, but the MIT KDC simply issues a ticket with a zero lifetime. Five minutes later, the ticket expires. This could all work better if krb5 had used a ticket lifetime instead of an end time (like krb4 did, but without the crazy 8-bit representation of the lifetime). But the protocol was designed under the assumption that clients, servers, and KDCs would all have mostly synchronized clocks, so it went with the simplification of always using absolute timestamps and never relative intervals. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
