Export (0) Print
Expand All

Authentication Errors are Caused by Unsynchronized Clocks

Updated: March 2, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Clients can be prevented from authenticating by the mechanisms that Kerberos authentication uses to prevent "replay" attacks. In a replay attack, a malicious user captures the network traffic and replays it to trick the authenticating server into accepting the attacker as a legitimate user who is providing credentials.

Kerberos authentication prevents a replay attack by using two mechanisms:

  • The Kerberos client on the local computer encrypts a timestamp inside the authenticator and then sends it to the Key Distribution Center (KDC). If the KDC verifies that the time it decrypts from the authenticator is within a specified amount of the local time on the KDC (the default is five minutes), the system can assume that the credentials presented are genuine.

  • All tickets issued by the KDC have an expiration time. Thus, if a ticket is compromised, it cannot be used outside of a specified time range — usually short enough to make the risk of a replay attack minimal.

Because of these mechanisms, Kerberos authentication relies on the date and time that are set on the KDC and the client. If there is too great a time difference between the KDC and a client requesting tickets, the KDC cannot determine whether the request is legitimate or a replay. Therefore, it is vital that the time on all of the computers on a network be synchronized in order for Kerberos authentication to function properly.

Clock skew can be easily diagnosed by reviewing the information in the System log.

Causes

If the ticket presented to the server is not yet valid (in relationship to the server time), the "0x21 - KRB_AP_ERR_TKT_NYV: Ticket not yet valid" error will be recorded. The most probable cause is that the clocks on the KDC and the client are not synchronized.

In addition, the errors "0xB - KDC_ERR_NEVER_VALID: Requested start time is later than end time," "KDC_ERR_PREAUTH_FAILED: Pre-authentication information was invalid," and "KDC_ERR_NEVER_VALID: Requested start time is later than end time" are caused because the times on the KDC and the client do not match.

Solution

In this case no action is needed. In a Windows environment, the domain controller will supply the correct time on the domain controller to the Kerberos client. The Kerberos client then uses the correct domain controller time to attempt the authentication request a second time. Presuming that the user’s credentials are valid, the user will be authenticated on the second try.

Cause

Typically, when the value for the Maximum lifetime for user ticket Kerberos policy setting is set too low, the "KRB_AP_ERR_TKT_EXPIRED: Ticket expired" error occurs.

Solution

Because ticket renewal is automatic, you should not have to do anything if you get this message.

Cause

If Kerberos authentication fails when it is being attempted between realms, the clocks in the KDC in the target realm and the KDC in the client realm might not be synchronized.

Solution

For non-Windows Kerberos realms, consult the operating system documentation to synchronize clocks on the KDCs in the two realms.

Cause

If a client requests the postdating of a Kerberos ticket, the "0xA - KDC_ERR_CANNOT_POSTDATE: Ticket not eligible for postdating" error can occur. Postdating is the act of requesting that a ticket’s start time be set into the future. Postdating is not allowed therefore the client will not be authenticated.

Solution

No action is necessary. This behavior is by design.

Cause

Typically, when the difference between client timestamp in the authenticator or KRB_AS_REQ and the server is greater than the Maximum tolerance for computer clock synchronization setting in the domain policy, the "0x25 - KRB_AP_ERR_SKEW: Clock skew too great" error occurs. This error is logged if a client computer sends a timestamp whose value differs from that of the server’s timestamp by more than the number of minutes found in the Maximum tolerance for computer clock synchronization setting in Kerberos policy.

Solution

Although the "0x25 - KRB_AP_ERR_SKEW: Clock skew too great" error might show up in the logs, it will not prevent a user from being authenticated. When this error is returned, the domain controller also supplies the correct time on the domain controller. The Kerberos client uses the correct domain controller time to attempt the authentication request a second time. Presuming that the user’s credentials are valid, the user will be authenticated on the second try.

This error can more commonly occur as the number of portable, or frequently disconnected, computers in your network increases.

To avoid getting this error, you can change the value of the Maximum tolerance for computer clock synchronization setting to a higher value.

CautionCaution
Beware that the higher you set this value, the more susceptible the network becomes to replay attacks.

To set Maximum tolerance for computer clock synchronization Kerberos policy by using Active Directory Users and Computers
  1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.

  2. Right-click the domain whose policy you wish to change, and then click Properties.

  3. Click the Group Policy tab, select the Default Domain Policy, and then click the Edit button to launch the Group Policy Object Editor.

  4. Open Computer Configuration, open Windows Settings, and then open Security Settings.

  5. Click Account Policies, double-click Kerberos Policy, and then double-click Maximum tolerance for computer clock synchronization.

  6. Increase the value in the Maximum tolerance box, and then click OK.

  7. You can wait for the policy change to propagate or you can run gpupdate /force on the client computers to force propagation immediately.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft