Clock Drift Breaks Kerberos: Fixing Domain Login Time Errors

A user cannot log on. Or they log on but every mapped drive prompts for a password and Outlook keeps asking for credentials. The event log on the PC mentions a time difference, or you see Kerberos error KRB_AP_ERR_SKEW. The PC's clock has drifted too far from the domain controller.

Kerberos allows five minutes of skew by default. Beyond that, tickets are rejected as a replay-protection measure. The fix is usually quick, but the cause is worth finding, because a machine that drifted once will drift again.

How to confirm time skew is the problem

Compare the PC clock with the domain controller before you do anything else. A visual check of the taskbar is not enough, since the time zone might be hiding a real offset. Use `w32tm` on the PC and read the offset it reports against the DC.

On the PC, run `w32tm /query /status`. Note the Source line. If it says Local CMOS Clock or Free-running System Clock, the machine is not syncing at all.
Run `w32tm /stripchart /computer:dc01.yourdomain.local /samples:5 /dataonly` to see the offset in seconds. Anything over 300 seconds explains the login failure.
Check the System log for Event ID 4 (Kerberos) or Event ID 50 (W32Time) on the affected PC.
On a Mac or Linux box that joins the domain, run `date` and compare to `w32tm /query /status` on the DC. The same five-minute rule applies.

w32tm /query /status
w32tm /stripchart /computer:dc01.yourdomain.local /samples:5 /dataonly

Resync the client

A domain-joined PC should take time from the domain hierarchy automatically. When it stops, the usual cause is a forced NTP setting left behind by an image, a laptop that lived off the network for months, or the Windows Time service being disabled by a tuning script.

Run the commands below from an elevated prompt. The first one tells the PC to use the domain hierarchy again, the second forces a resync, and the third confirms the source changed. If the offset is very large, `w32tm /resync` may refuse. Set the clock close to correct by hand first, then resync.

Make sure the service is running: `Set-Service W32Time -StartupType Automatic; Start-Service W32Time`.
Reset the source to the domain: `w32tm /config /syncfromflags:domhier /update`.
Force a resync: `w32tm /resync /rediscover`.
Verify: `w32tm /query /source` should name a domain controller.
Lock the workstation and unlock it, or reboot, so a fresh Kerberos ticket is issued. Cached tickets do not fix themselves.

w32tm /config /syncfromflags:domhier /update
w32tm /resync /rediscover
w32tm /query /source

Fix the top of the hierarchy

If many machines drift together, the domain controller holding the PDC Emulator role is the one to check. Every other DC and every client follows it. If the PDC Emulator takes time from its own CMOS clock, the whole domain drifts as one, and you only notice when a cloud service or a partner's system rejects you.

The PDC Emulator should sync from a reliable external source such as pool.ntp.org or your firewall if the firewall syncs upstream. Configure it once and check it after any DC replacement, since the role moves with the server.

Find the role holder: `netdom query fsmo`.
On that DC, point it at external NTP: `w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update`.
Restart the service: `Restart-Service W32Time`, then `w32tm /resync`.
Allow UDP 123 outbound from the DC on the firewall.
Every other DC should use `/syncfromflags:domhier`, not a manual peer list.

netdom query fsmo
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Virtual machines have their own trap

On Hyper-V, VMware and Proxmox, the guest can take time from the hypervisor through integration services or guest tools. That is fine for a member server, but on a domain controller it creates a loop: the host syncs from the DC, the DC syncs from the host, and both drift together.

Turn off host time sync for domain controllers. In Hyper-V that is the Time Synchronization integration service in the VM settings. On VMware it is the "Synchronize guest time with host" option in VMware Tools. On Proxmox with the QEMU guest agent, check that the DC's Windows Time service is not being overridden by the agent's time sync. Let the PDC Emulator talk to real NTP and let everything else follow it.

Frequently asked questions

Why five minutes?

That is the default MaxClockSkew in the Kerberos policy. It stops an attacker from replaying a captured ticket much later. You can raise it in Group Policy, but the right answer is to fix the clocks, not loosen the check.

The clock looks right but Kerberos still fails. Why?

Check the time zone and the daylight saving setting. A clock that shows the right local time in the wrong zone is still off by an hour in UTC, and Kerberos compares UTC.

Can a dead CMOS battery cause this?

Yes. If a desktop boots with the clock reset to a date years in the past, the offset is far beyond what w32tm will correct automatically. Replace the battery, set the time by hand, then resync.

Takeaway

Kerberos time errors look like account problems but they are clock problems. Check the offset with w32tm, resync the client, then make sure the PDC Emulator is taking time from a real NTP source and that virtual DCs are not syncing from their host. Once the hierarchy is right, individual drift tickets mostly disappear.