Kerberos clock skew: “There is a time and/or date difference between the client and server” (KRB_AP_ERR_SKEW)

Someone cannot sign in to a domain PC, a mapped drive keeps asking for a password, or a domain controller refuses to replicate with another one. Somewhere in the chain you find this message or its technical name:

There is a time and/or date difference between the client and server.
(error 1398, 0x576, ERROR_TIME_SKEW)

KRB_AP_ERR_SKEW

Kerberos, the sign-in protocol Active Directory uses, refuses to work when two clocks disagree by too much. Nothing is wrong with the password or the account. The fix is to find the clock that is wrong, and more importantly to find out why it is wrong, because a clock you correct by hand will drift again.

Applies to: Windows 10, Windows 11 and Windows Server in an Active Directory domain, physical or virtual. Commands run in an elevated Command Prompt (right-click, Run as administrator). Changes on domain controllers need a domain administrator. A note on event IDs: this problem is sometimes searched as “Event ID 14”. In Microsoft’s Kerberos troubleshooting table, Event ID 14 is a different problem (an “unsupported etype” encryption type error). The clock skew error is logged as Kerberos Event ID 4 (KRB_AP_ERR_SKEW).

What is going on

Kerberos tickets carry timestamps. A server rejects a request whose timestamp is too far from its own clock, which stops an attacker from recording a ticket and replaying it later. The allowed difference is 5 minutes by default. It is set by the Kerberos policy setting in the Default Domain Policy (Maximum tolerance for computer clock synchronization), and the same default shows up in the Kerberos registry value SkewTime (5 minutes). Microsoft’s guidance is that the difference between the domain controller and the client or target server must be less than five minutes.

Kerberos does not care whether the clock is right against the real world. It only cares that the clocks involved agree with each other. That is why a whole domain can keep working while being 20 minutes wrong, until one machine syncs to an outside source and suddenly disagrees with everyone else.

In a healthy domain, time flows down a chain, and nobody is meant to hold a separate opinion:

• Domain members (PCs and member servers) take their time from a domain controller (DC).
• Domain controllers take their time from the DC that holds the PDC emulator role for their domain, ultimately from the PDC emulator of the forest root domain.
• The forest root PDC emulator sits at the top. It is the one machine that should be configured to take its time from an outside source, a reliable NTP (Network Time Protocol) server.

If the machine at the top has the wrong time, or is using its own motherboard clock, everyone below it agrees on the wrong time. Skew appears when anything breaks that chain: a manually configured time server on a PC, a dead battery, a virtual machine that is told the time by its host instead of by the domain, or an outside time server that cannot be reached.

Diagnosis

1. Confirm it is the clock

Look for the evidence in the System log on the client and on the target server: Kerberos Event ID 4 with KRB_AP_ERR_SKEW. For a computer that cannot authenticate at all, Group Policy Event ID 1097 (“Windows could not determine the computer account”) is one that Microsoft explicitly ties to a clock difference over five minutes. In Active Directory replication, the same cause appears as an access denied error with ERROR_TIME_SKEW.

2. Measure the offset

Compare the PC against a domain controller. This prints the difference every few seconds without changing anything:

w32tm /stripchart /computer:<domain controller name> /samples:5 /dataonly

The right-hand column is the offset in seconds between this computer and that DC. Anything above 300 seconds (5 minutes) is outside the default tolerance. Check the time zone as well, because a PC set to the wrong zone shows the wrong hour even when the underlying time is correct:

w32tm /tz

3. See where the PC gets its time

w32tm /query /source
w32tm /query /status

On a domain member, the source should be a domain controller. These are the answers that need attention:

• A name that is not a DC (a public pool, an old server): the PC was manually set to a time server, probably before it joined the domain. Microsoft documents this case as the one where you reconfigure the PC to use the domain hierarchy.
• Local CMOS Clock or a free-running clock: it has no time source and is trusting its own hardware clock. Look for a stopped Windows Time service, blocked UDP port 123 to the DC, or a failing CMOS battery on an older machine.
• VM IC Time Synchronization Provider: a virtual machine that is taking its time from the Hyper-V host rather than from the domain. See the virtual machine section below.

The status output also shows the last successful sync time, and the offset (“Phase Offset”). A last sync from days ago means the service is not syncing.

4. Work up the chain: is it one PC or the whole domain?

If it is one PC, the problem is on that PC. If many machines are wrong, or domain controllers disagree with each other, check the top of the hierarchy. Find the PDC emulator for the domain:

nltest /dsgetdc:<domain name> /pdc

Or in PowerShell: [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().PdcRoleOwner.Name. Then list the DCs and their offsets in the domain:

w32tm /monitor /domain:<domain name>

Microsoft recommends tracing the chain the same way: run w32tm /query /status on a client to get its source, then use w32tm /stripchart against that source to find the next one up, until you find the point where the offset suddenly gets worse. That machine, or what it syncs from, is the root of the problem. Note that /monitor only checks domain controllers in the domain you give it, so run it per domain in a multi-domain forest.

5. Is it a virtual machine?

Check the source from step 3. A virtual domain controller or PC can get its time from the hypervisor, from the domain, or from both, and the two will fight. Microsoft documents domain controller virtual machines logging Windows Time events 24, 29 and 38 when this happens. That is the signature of the time moving back and forth between competing sources.

Root cause

One or more computers have a clock more than 5 minutes away from the domain controller they authenticate against, so Kerberos rejects their tickets with KRB_AP_ERR_SKEW. The usual underlying causes are: a PC following a manually configured time source rather than the domain; a forest root PDC emulator that is not synced to a reliable outside source (or is using its own BIOS clock); a hypervisor feeding a virtual machine its own time; or a dead CMOS battery or stopped Windows Time service.

The fix

Fix the source, not the symptom. Dragging the clock by hand on each PC only works until the next sync. Changes on the PDC emulator affect the whole domain, so make them once, on the right machine, and write down the old configuration first (w32tm /query /configuration). Do not set the clock by hand on a domain controller: sudden time jumps on a DC can cause problems with replication.

Step 1: fix a single PC

Correct the time zone if it was wrong, then make the PC rediscover its time sources and resync. Microsoft recommends this command when the clock is out of sync by more than 48 hours, or when the PC is not using a domain controller from its own domain as its time server:

w32tm /resync /rediscover

If step 3 of the diagnosis showed a manual time server, put the PC back on the domain hierarchy, restart the service and resync:

w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /rediscover

If the service is stopped or the PC still shows Local CMOS Clock, check that the Windows Time service starts, and that UDP port 123 is open between the PC and its DC. W32Time uses UDP 123 for all synchronisation.

Step 2: fix the top of the chain (forest root PDC emulator)

When the whole domain is wrong, check the PDC emulator of the forest root domain. By default it is not told where to get time from. Microsoft recommends pointing it directly at a reliable external NTP source (or at a single internal time server that is itself synced externally). On that one domain controller, as a domain administrator:

w32tm /config /syncfromflags:manual /manualpeerlist:"<time server 1>,0x8 <time server 2>,0x8 <time server 3>,0x8" /reliable:yes /update
w32tm /resync /rediscover

• /syncfromflags:manual makes it use the list you give it instead of the domain hierarchy. /reliable:yes marks it as a reliable time source, and is only meaningful on a domain controller, and only for the forest root PDC emulator.
• ,0x8 after each name means “send requests in client mode”, the setting Microsoft shows in its example. Separate servers with spaces and keep the whole list in quotes.
• Microsoft recommends three or more time servers for current Windows versions, because of how the newer time algorithm weighs sources. With only two, mark one as 0x2 (fallback only) so the other takes priority.
• Pick time servers your organisation trusts (for example a national laboratory or your cloud provider’s NTP service). UDP port 123 must be allowed outbound from this DC.

Other DCs and members then follow on their own through the domain hierarchy. You do not set an outside time source on them.

Step 3: virtual machines and the hypervisor

The aim is exactly one authority for time, and it must be accurate. Microsoft’s guidance varies by case, so choose deliberately:

• A domain-joined member server or PC in a VM: best practice is to disable the hypervisor time sync for the guest and let it follow its domain controller. In Hyper-V this is the Time synchronization checkbox under the VM’s Integration services. The registry setting inside the guest is HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider, value Enabled = 0. Restart the Windows Time service after changing it.
• A virtual domain controller: do not leave it taking time from both the host and the domain. For guests of Windows Server 2016 on Windows Server 2016 hosts, Microsoft says the old disruption “should no longer exist”. For older combinations Microsoft documents turning host time sync off for the DC and letting it follow the domain hierarchy.
• The PDC emulator as a VM: be careful. If you disable host sync and give it no outside time source, it falls back to its own virtual clock, which Microsoft describes as the one thing that is always wrong in a VM. Either give it an outside NTP source as in Step 2, or leave host sync on and make sure the host itself has accurate time from a reliable source.
• A VM restored from a snapshot or saved state comes back with an old clock. Check the time after any restore before the machine talks to the domain.
• Other hypervisors (VMware and similar): they have their own guest time sync setting. Check the vendor’s documentation. This article did not verify it.

Verification

w32tm /query /status
w32tm /query /source
w32tm /stripchart /computer:<domain controller name> /samples:5 /dataonly

The source should be what you expect (a DC for members, the configured NTP servers for the forest root PDC emulator), the last successful sync time should be recent, and the offset against the DC should be well under a second or two. The stratum is one higher than the stratum of the source it follows, so do not expect a fixed number. Then clear the old tickets and test the thing that was failing:

klist purge

Sign in again or open the share. In the System log there should be no new Kerberos Event ID 4 with KRB_AP_ERR_SKEW. Check again after a day, and after the next restart of any virtual machine involved.

Notes

• Adjusting the clock by hand on each PC is the common wrong turn. It holds until the next sync, then the real cause pulls it back.
• Do not use w32tm /unregister followed by /register as a routine fix. Microsoft documents /unregister as removing all the service’s configuration from the registry, and /register as putting the default configuration back. That is useful only if the Windows Time service is missing or broken, and it throws away any time source you configured on purpose.
• The 5 minutes is a default, not a law. It can be changed in the Kerberos policy, but widening it to hide a time problem weakens a protection that exists for a reason. Fix the time instead.
• A clock that moved far away at some point is a hint that the machine was restored or reverted. That same event is a common cause of a broken computer account password. See The trust relationship between this workstation and the primary domain failed.
• Name resolution and time share causes with sign-in failures. If the PC cannot find a DC at all, see Group Policy Event ID 1053 / 1055.
• Pages this article was checked against on Microsoft Learn: “Kerberos authentication troubleshooting guidance”, “Windows Time service tools and settings”, “Time accuracy improvements for Windows Server 2016”, “Recommendation: Configure the Root PDC with an Authoritative Time Source and Avoid a Widespread Time Skew”, and the Hyper-V domain controller time synchronization articles.

Not sure which clock is wrong? Post the output of w32tm /query /status and w32tm /monitor (blank out anything private), and say whether the machines involved are virtual, in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.