Windows Time Service was originally designed to provide the level of clock synchronisation required by Kerberos. In a normal Active Directory environment, the domain hierarchy keeps domain controllers, member servers and workstations within the permitted time difference.

The default Kerberos tolerance is five minutes. This is not a target accuracy and should not be treated as permission for systems to drift by several minutes. It is the limit beyond which Kerberos timestamps may no longer be accepted as authentic.

Typical symptoms

A time problem may first appear as an application or authentication fault rather than as a Windows Time warning.

Possible symptoms include:

  • A domain user cannot sign in.
  • A mapped drive or file share rejects otherwise valid credentials.
  • A service cannot authenticate to another server.
  • Remote Desktop or another management connection fails unexpectedly.
  • An application falls back from Kerberos to NTLM, or fails because no fallback is available.
  • SQL Server reports an SSPI or integrated authentication failure.
  • Exchange, IIS or another Kerberos-aware service reports authentication errors.
  • Domain controller replication or secure-channel operations fail alongside an obvious time difference.

These symptoms are not unique to clock skew. SPN errors, DNS faults, broken secure channels, duplicate accounts and network problems can produce similar messages. Time should be checked early, but it should not be assumed to be the cause without evidence.

KRB_AP_ERR_SKEW

The clearest Kerberos indication is:

KRB_AP_ERR_SKEW

This means that the client and the system validating the Kerberos request disagree about the time by more than the permitted tolerance.

Microsoft also documents Event ID 4 with KRB_AP_ERR_SKEW as an instruction to confirm that the computer clocks are synchronised.

Do not confuse this with:

KRB_AP_ERR_MODIFIED

KRB_AP_ERR_MODIFIED is usually associated with a service ticket that the target cannot decrypt, often because of an SPN or account-key problem. Time can be part of the surrounding fault, but that error is not proof of clock skew by itself.

The five-minute tolerance

The default domain Kerberos policy permits a maximum clock difference of five minutes.

The setting is:

Computer Configuration
  Windows Settings
    Security Settings
      Account Policies
        Kerberos Policy
          Maximum tolerance for computer clock synchronization

Increasing this tolerance is rarely the correct fix. It weakens replay protection and hides the failed time configuration rather than repairing it.

The correct response is to identify why one or more systems are outside the normal Active Directory hierarchy.

Which clocks need comparing?

Kerberos authentication can involve several systems:

  • The client requesting access.
  • The domain controller providing the Kerberos ticket.
  • The target server accepting the ticket.

Do not compare only the client with the wall clock. Compare all systems involved in the failed authentication.

On each Windows computer, run:

w32tm /query /source
w32tm /query /status

Record the selected source, current time and last successful synchronisation.

Start with the affected client

On a normal domain member, the source should usually be a domain controller selected through the Active Directory hierarchy.

If the client reports Local CMOS Clock, Free-running System Clock, a manual public peer or a hypervisor provider, investigate why it is not using the domain hierarchy.

Return a domain member to automatic hierarchy discovery with:

w32tm /config /syncfromflags:domhier /reliable:no /update
w32tm /resync /rediscover

If the resynchronisation fails, continue with Windows Time Synchronisation Fails.

Check the target server

The client can have correct time while the server accepting the Kerberos ticket is wrong.

This is particularly easy to miss on:

  • A server recently restored from backup or snapshot.
  • A virtual machine resumed after a long suspension.
  • A server moved between virtualisation hosts.
  • A member server with an old manual peer configuration.
  • A server whose secure channel or DNS registration is also unhealthy.

Check the same source and status information on the target before changing accounts or SPNs.

Check the domain controllers

If several users or servers are affected, work from the top of the Active Directory hierarchy downwards.

Identify the FSMO role holders:

netdom query fsmo

Then verify the forest root PDC Emulator:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

The forest root PDC Emulator should use the approved external or internal reference. Other domain controllers should normally follow the domain hierarchy.

Review the domain controllers together with:

w32tm /monitor

This shows the measured offsets between domain controllers and can quickly reveal one system that is significantly different from the others.

Rediscover and resynchronise

Where the hierarchy is correct but a member has retained an unsuitable source, run:

w32tm /resync /rediscover

Microsoft's Kerberos troubleshooting guidance also supports running the command remotely:

w32tm /resync /computer:SERVER01 /rediscover

A successful command means that the request was accepted. Check the source and status afterwards to confirm the result.

Large time differences

If a system is hours, days or years out, it may not be able to use normal domain authentication to correct itself cleanly.

First establish why the time is so wrong. Common causes include:

  • An incorrect virtualisation host clock.
  • A restored snapshot.
  • A failed CMOS battery.
  • A computer disconnected for a long period.
  • A PDC Emulator with no valid upstream source.
  • A manual peer that no longer exists.

A one-off manual correction may be necessary to bring the system close enough for authentication and Windows Time Service to resume, but it should not be treated as the complete repair. Correct the source and verify a successful synchronisation afterwards.

Virtual machines

Virtualisation is a common cause of sudden clock changes.

Check whether the affected VM has just:

  • Started on a host with an incorrect clock.
  • Resumed from suspension.
  • Been restored from a snapshot.
  • Migrated to another host.
  • Had guest-tools time synchronisation enabled or changed.

For domain members, the preferred configuration used throughout this site is for Windows Time Service to follow Active Directory while ongoing host-to-guest synchronisation is disabled.

Use the relevant platform guidance:

Cached Kerberos tickets

Kerberos tickets contain timestamps and remain cached for reuse. Correcting the clock does not always make an existing failed session recover immediately.

After fixing time, first retry the failed authentication. If the same session continues to fail, sign out and back in, restart the affected service or computer where appropriate, or purge the user's cached tickets:

klist purge

Use klist purge carefully on a production server. It removes cached Kerberos tickets for the current logon session and can interrupt existing authenticated connections.

Do not rebuild the trust relationship too quickly

A message about a failed trust relationship does not automatically mean that the computer account password is wrong.

If the machine clock is outside the Kerberos tolerance, domain authentication can fail before the secure channel is tested normally. Correct and verify time first.

Only reset the secure channel or rejoin the domain when separate evidence shows that the trust itself is broken.

Do not change SPNs without evidence

Application errors such as an SSPI failure can result from DNS, SPN, service-account or time problems.

If KRB_AP_ERR_SKEW is present, correct time first. If time is already correct and the error is KRB_AP_ERR_MODIFIED, KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE, investigate SPNs and service identities separately.

Changing SPNs to solve a clock problem can create a second authentication fault.

Event logs to review

Check the Security and System logs on:

  • The client.
  • The target server.
  • The authenticating domain controller.

Relevant event sources include:

  • Kerberos.
  • Key Distribution Center (KDC).
  • LSA or LsaSrv.
  • Netlogon.
  • Microsoft-Windows-Time-Service.

Record the names of the client, target server and domain controller from the event before making changes. Kerberos failures are much easier to understand when the complete authentication path is known.

Confirm the repair

After correcting time, verify all affected systems:

w32tm /query /source
w32tm /query /status

Then retry the original action rather than relying only on a successful time command.

A complete repair means:

  • The clocks are within normal tolerance.
  • Each system uses the expected source.
  • The last successful synchronisation is recent.
  • The original Kerberos or application authentication succeeds.

Microsoft documentation

Related information