How to Configure NTP Time Sync Correctly on a Windows Domain

Kerberos authentication fails if a client’s clock drifts more than 5 minutes from the domain controller’s, and since Kerberos underpins virtually all AD authentication, a domain-wide time sync problem manifests as bizarre, seemingly unrelated login failures rather than an obvious “clock is wrong” error. Windows handles time sync automatically via a hierarchy, but it’s worth understanding and verifying rather than assuming it’s fine.

• The PDC Emulator FSMO role holder is the authoritative time source for the whole domain
• Every other DC syncs from the domain hierarchy automatically; only the PDC Emulator needs external configuration
• Member computers sync from any DC in their domain, not directly from an external source
• Virtualised DCs need special handling to avoid the hypervisor’s own time sync fighting with Windows Time service

Step 1: Point the PDC Emulator at a reliable external source

Find the current PDC Emulator with netdom query fsmo, then configure it to sync from an external NTP source rather than its own hardware clock:

w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Step 2: Leave other DCs and members on the domain hierarchy

Every other domain-joined machine should sync automatically through the domain hierarchy (NT5DS). Don’t manually configure external NTP servers on member servers or workstations, as this bypasses the domain hierarchy and can itself cause the drift you’re trying to avoid.

Step 3: Handle virtualised domain controllers correctly

If your PDC Emulator is a Hyper-V VM, disable the hypervisor’s time synchronization integration service for that specific VM. Otherwise the hypervisor and Windows Time service can fight over authoritative time, causing exactly the drift problem you’re trying to prevent. This is one of the most common causes of “correctly configured” time sync still drifting.

Verifying it’s actually working

w32tm /monitor run from any domain-joined machine shows the time offset for every DC in the domain at a glance. Anything beyond a second or two of drift is worth investigating before it becomes a Kerberos problem.

For official guidance, see Microsoft’s Windows Server documentation.