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

KB ID 2610040006

Problem: Kerberos authentication fails in an Active Directory domain because the clock on a computer is more than the allowed 5 minutes away from the domain controller. Users cannot sign in, shares ask for passwords, or domain controllers fail to replicate.
Applies to: Kerberos, Windows Time service (W32Time), w32tm, Active Directory Domain Services
Time to fix: 10 to 20 minutes for one PC; longer if the time hierarchy is wrong

Symptoms, platforms, difficulty and more

Symptoms: Error text "There is a time and/or date difference between the client and server." (error 1398, 0x576, ERROR_TIME_SKEW). Kerberos error KRB_AP_ERR_SKEW; the System log shows Kerberos Event ID 4. Group Policy Event ID 1097 can also point at the clock. Sign-in or access to a share fails; time source shows Local CMOS Clock or a virtual machine time provider.
Platforms affected: Windows 10, Windows 11, Windows Server (domain members and domain controllers), including virtual machines on Hyper-V and other hypervisors
Difficulty: Intermediate (command line on clients; domain administrator on the PDC emulator for the root fix)
Verified on: Not yet tested by KEH-TECH on a live system. Steps and commands checked against Microsoft Learn on 4 October 2026 (Kerberos authentication troubleshooting guidance, Windows Time service tools and settings, time accuracy improvements for Windows Server 2016, the root PDC time source recommendation, and the Hyper-V time synchronization articles). VMware behaviour was not checked against VMware documentation. Nothing was run against Windows or Active Directory.
Category: Troubleshooting
Updated: 4 Oct 2026
Tags: Active Directory, Hyper-V, Kerberos, w32tm, Windows, Windows Server, Windows Time

The fix only. No explanation, no diagnosis. Read the full article if any of this does not match what you are seeing.

Open an elevated Command Prompt on the affected PC. Check the time zone and date are right first. A wrong time zone looks like a wrong clock.
Measure how far off it is, and see where it gets its time from.

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

Make the PC re-find its time source and resync.

w32tm /resync /rediscover

If the PC was set to a manual time server and should follow the domain, put it back on the domain hierarchy.

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

If many machines are wrong, the problem is above them. Find the PDC emulator and check where it gets its time.

nltest /dsgetdc:<domain name> /pdc
w32tm /monitor /domain:<domain name>

On the forest root PDC emulator only, point it at an external time source.

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

For a virtual machine, make sure the hypervisor is not feeding it a different time (see the article).

Do not set the clock by hand on a domain controller or PDC emulator. It drifts back, and time jumps on a DC can cause replication trouble.

Do not run w32tm /unregister as a routine fix. It deletes the Windows Time configuration.

← Full article, with the diagnosis and the why

Was this helpful?

Updated on October 4, 2026