Fixing Kerberos Authentication Failures Caused by Clock Skew

Domain authentication failures that seem to appear without any configuration change — a machine that was authenticating fine suddenly failing to log in, join a domain, or access domain resources, sometimes with cryptic errors referencing “clock skew” directly, sometimes with more generic authentication failure messages — very often trace back to the affected machine’s clock having drifted too far from the domain controller’s, rather than any actual credential or permission problem.

Why Kerberos cares about clock time at all

Kerberos authentication (which Windows domain authentication is built on) relies on timestamps as part of its protection against replay attacks — tickets are only valid within a specific, relatively narrow time window, and a client whose clock has drifted too far from the Key Distribution Center’s (a role the domain controller performs) clock will have its ticket requests rejected as appearing either expired or not-yet-valid, even though the actual credentials being used are entirely correct.

The default tolerance, and why exceeding it causes total authentication failure

Windows’s default Kerberos maximum clock skew tolerance is five minutes. This is a deliberately narrow window — wide enough to accommodate normal, minor clock drift between systems, but narrow enough to meaningfully limit the window during which a captured, replayed ticket could be reused by an attacker. A machine whose clock has drifted more than five minutes from the domain controller’s will fail Kerberos authentication entirely, and critically, this failure can look like a generic authentication or access-denied problem rather than obviously pointing at time as the cause, unless you specifically know to check for it.

Confirming clock skew is actually the cause

w32tm /stripchart /computer:dc-hostname /samples:1

This directly queries the domain controller’s time and reports the actual offset between it and the local machine’s clock — a definitive way to confirm whether skew is the actual cause, rather than assuming based on symptoms alone, since several other authentication failure causes can present with superficially similar symptoms.

Checking the affected machine’s time synchronization configuration

w32tm /query /status

This reports the current time source the machine is actually synchronizing against, and its current sync status — a machine that should be synchronizing against the domain hierarchy but shows a different, unexpected source (or shows sync errors) has found the actual root cause: whatever should be keeping its clock in sync with the domain isn’t functioning correctly.

Why domain-joined machines are supposed to stay in sync automatically

Windows domain architecture is designed around a specific time-synchronization hierarchy: domain-joined machines synchronize against the domain controller that authenticated them, and domain controllers themselves synchronize against the domain’s PDC emulator (a specific, designated domain controller role), which in turn typically synchronizes against an external, authoritative time source. This hierarchy is supposed to keep every domain-joined machine’s clock within Kerberos’s tolerance automatically, without manual intervention — clock skew becoming a genuine problem usually indicates this automatic hierarchy has broken down somewhere, not that time sync was never configured in the first place.

Common reasons the automatic hierarchy breaks down

A virtual machine that’s been suspended and resumed after an extended pause (common in test/lab environments, and occasionally in production VM environments during maintenance) can have its clock drift significantly during the suspended period, with time sync not immediately correcting it on resume. A machine’s own local hardware clock battery failing can cause drift after every reboot. Misconfigured or removed time synchronization group policy settings can leave a machine without a properly configured time source at all, silently drifting on its own local hardware clock instead.

Forcing an immediate resync

w32tm /resync /force

This forces an immediate resynchronization against the machine’s currently configured time source — the direct fix once you’ve confirmed clock skew is the actual cause and the underlying time source configuration itself is correct.

Fixing the PDC emulator’s own external time source, if that’s the actual root cause

If the affected machine’s local sync configuration is correct but its assigned time source (ultimately tracing back to the domain’s PDC emulator) is itself not synchronized against a genuinely reliable external time source, the fix belongs at the PDC emulator level, not on individual client machines:

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /reliable:yes /update

(run on the PDC emulator specifically) — configuring it against a reliable external NTP source ensures the entire domain’s time hierarchy has an actually accurate root, rather than each client machine potentially drifting independently if the domain’s own top-level time source is itself unreliable or unconfigured.

Why this is worth checking before assuming a credentials problem

Because clock skew doesn’t announce itself clearly in every error message, and because the actual underlying fix (correcting time synchronization) is completely unrelated to anything a user or administrator would normally think to check when troubleshooting what looks like a login or permissions failure, confirming actual clock offset directly via w32tm /stripchart early in the troubleshooting process avoids wasted effort investigating credentials, group memberships, or permissions that were never actually the problem.