Kerberos Clock Skew — KRB_AP_ERR_SKEW

Introduction

A user reports they cannot log on to a workstation that was fine yesterday. Or a scheduled task running under a service account suddenly fails every morning at the same time. Or a newly built VM joins the domain without complaint but nobody can authenticate to it. The common thread: nothing about permissions, passwords, or group membership changed. What changed is time.

Kerberos is deliberately intolerant of clock drift, and that intolerance is a security feature, not a bug. Once you accept that KRB_AP_ERR_SKEW is the protocol doing exactly what it was designed to do, the troubleshooting narrows fast — you are not debugging Active Directory, you are debugging whichever clock stopped following the domain’s time hierarchy.

What You’re Seeing

The error surfaces slightly differently depending on where you look. On the client, the System log records it under the Kerberos source:

# System log, Source: Kerberos, Event ID 4
The kerberos client received a KRB_AP_ERR_SKEW error from the server host/DC01.corp.example.com.
This indicates that the time difference between the client and server is too great.

On the domain controller side, a failed TGT request logs as Event ID 4771 in the Security log, with the failure code that corresponds to the same underlying RFC 4120 error:

# Security log on the DC, Event ID 4771
Status: 0x25
Failure Code: KRB_AP_ERR_SKEW (Clock skew too great)

A logon attempt that fails specifically because of time can also appear as an Event ID 4625 logon failure with sub status 0xC0000133 (STATUS_TIME_DIFFERENCE_AT_DC). Whichever event you land on, the message is the same: authentication was refused on timing grounds alone, not credentials.

What It Actually Means

Every Kerberos exchange includes an encrypted timestamp, and the Key Distribution Center on each domain controller checks that timestamp against its own clock before honouring the request. This exists specifically to defeat replay attacks — without a time check, a captured ticket or authenticator could be resubmitted indefinitely. The acceptable difference between a client clock and the domain controller clock is governed by the Maximum tolerance for computer clock synchronization Kerberos policy setting, found at Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy in the Default Domain Policy. Its default value is 5 minutes, and Microsoft’s own guidance is to leave it there rather than widen it.

If the gap between the two clocks is inside that window, the timestamp is accepted as authentic and authentication proceeds normally. Cross the threshold in either direction — the client ahead or behind — and the KDC returns KRB_AP_ERR_SKEW. The directory itself, the account, and the password are all untouched by this; the request never gets far enough to check them.

How to Diagnose

Work from cheapest check to deepest. Most skew incidents resolve at the first or second step.

# 1. Compare the affected computer's time against a healthy domain controller
w32tm /stripchart /computer:DC01.corp.example.com /samples:3 /dataonly

# 2. Check what this computer thinks its time source is, and how confident it is
w32tm /query /status /verbose

# 3. Confirm the computer is actually configured to sync from the domain hierarchy
w32tm /query /configuration

# 4. List the peers this computer is currently using
w32tm /query /peers

# 5. Force an immediate resync, rediscovering time sources on the network
w32tm /resync /computer:WORKSTATION01 /rediscover

# 6. Confirm a domain controller is reachable at all - a skew report can
# sometimes be a symptom of a bigger DC-locator problem
nltest /dsgetdc:corp.example.com /force /kdc

Common Causes

Working Through a Fix

Start with the machine reporting the error, not the domain controller. Run w32tm /query /status /verbose and look at the Source and Phase Offset lines — this tells you what the computer believes its time source is and how far off it currently measures itself. If Source is anything other than a domain controller and the machine is domain-joined, the sync chain is broken before you even get to the offset.

# Point the client back at the domain hierarchy explicitly
w32tm /config /syncfromflags:domhier /update

net stop w32time
net start w32time

# Force the resync and confirm the offset has closed
w32tm /resync /rediscover
w32tm /query /status /verbose

If the affected machine is itself a domain controller, check whether it is the PDC emulator for the forest root domain. Every other domain-joined computer eventually chains its time up to that one machine, so if the PDC emulator’s own external time source is stale or unreachable, the drift can appear on unrelated workstations days later with no obvious pattern. The PDC emulator should be the only machine in the environment configured with an external source and /reliable:YES; everything else — including other domain controllers — should inherit from the domain hierarchy (NT5DS), not from an external server directly.

# On the forest root PDC emulator only
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:YES /update
net stop w32time && net start w32time

How to Prevent It

Leave the Maximum tolerance for computer clock synchronization policy at its 5-minute default rather than widening it to make an error disappear — the tolerance exists to stop replay attacks, and loosening it trades a real security control for a cosmetic fix. Instead, make sure every domain-joined computer is actually inheriting time from the domain hierarchy rather than a leftover manual configuration from before it joined, and make sure the forest root PDC emulator has a reliable external source configured. On virtualized domain controllers, disable the hypervisor’s own time synchronization integration component so it cannot fight W32Time for control of the clock — this is a frequent source of drift that has nothing to do with Active Directory configuration at all.

Monitor proactively rather than waiting for a help desk ticket: a scheduled w32tm /stripchart or w32tm /monitor /domain:corp.example.com against your domain controllers will surface a drifting PDC emulator before it cascades into workstation-level Kerberos failures. The same time discipline that prevents KRB_AP_ERR_SKEW also underpins the NTP hierarchy your logs, certificates, and replication all depend on.

Quick Reference

Final Thoughts

KRB_AP_ERR_SKEW looks alarming because it blocks logons outright, but it is one of the more mechanically simple Kerberos failures once you stop looking at the directory and start looking at the clock. The protocol is working correctly — it just refuses to trust a timestamp it cannot verify.

Measure the offset first, trace it back to whichever source stopped following the domain hierarchy, and fix that source rather than the symptom. A domain where every machine inherits time from a well-configured PDC emulator rarely sees this error at all.