## TL;DR
Kerberos rejects authentication when the client clock differs from the domain controller by more than about five minutes. Resync the clock to the domain time source and the failures stop immediately.

## The query
```text
kerberos "clock skew too great" on domain-joined laptop
```

## Use this when
- Kerberos errors mention clock skew or KRB_AP_ERR_SKEW
- domain logons and file shares fail but the password is correct
- the laptop was asleep, dual-booted, or in a different time zone

## Not for
- Kerberos failures naming a specific SPN (service principal name problem)
- delegation or constrained-delegation errors
- NTLM fallback issues

## Steps
1. Compare the laptop clock against the domain controller time to confirm the skew exceeds five minutes. Expected output: a visible time difference matching the error.
2. Check that the time zone is set correctly; a wrong zone with a right-looking clock still breaks Kerberos. Expected output: the zone matches the user's location.
3. Run w32tm /resync from an elevated prompt to sync with the domain time source. Expected output: the command reports success and the clock jumps to the correct time.
4. Verify the Windows Time service is running and set to automatic, pointing at the domain hierarchy. Expected output: the service is running and the source is the domain.
5. Retry the failing Kerberos action, like a share or domain logon. Expected output: authentication succeeds without the skew error.

## Applies to
Windows 10/11 and Server domain members, w32tm, Active Directory Kerberos. macOS and Linux members use their own NTP clients with the same five-minute rule.

## Variant phrasings
### Skew returns after every reboot
The CMOS battery may be dead or a hypervisor is fighting the guest clock; check virtualization time-sync settings.

### Skew only on one subnet
A firewall may be blocking NTP (UDP 123) so the client never syncs; allow it to the DC.

## Why it happens
Kerberos timestamps every ticket and allows only a small skew window to block replay attacks. Sleep, dead CMOS batteries, wrong zones, or blocked NTP all push clients outside it.

## Edge cases
- Dual-boot machines often leave the hardware clock in the wrong base; pick UTC or local consistently.
- VMs should sync to the host or the domain, not both fighting each other.
- After a big jump, some apps need a restart to pick up fresh tickets.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RPpuKqIaLWPkSOCFY6yTxw