Active Directory Time Synchronization: Fix PDC Emulator, W32Time, and Kerberos Clock Skew

Kerberos authentication requires every machine in your domain to agree on the time within five minutes. Cross that threshold — one machine drifts, a snapshot restores an old clock, or the PDC Emulator loses its NTP source — and authentication tickets get rejected, logons fail, replication breaks, and GPO stops applying. Active directory time synchronization is not a background service you configure once. It is a security enforcement mechanism that breaks the domain when it fails.

This guide covers active directory time synchronization as a troubleshooting and recovery problem: W32Time Event 29, “Local CMOS Clock” on a DC, a Kerberos KRB_AP_ERR_SKEW, virtual DC drift after a snapshot restore, and domain-wide drift recovery. Configuration reference is included, but it exists to support the fix path — not as the main story.

Why Time Breaks Active Directory

Kerberos uses timestamps as part of its replay-attack protection. Every authentication request includes a timestamp, and the KDC verifies it against its own clock. If the difference exceeds the Maximum tolerance for computer clock synchronization policy — default five minutes, configured at Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy — the ticket is rejected with KRB_AP_ERR_SKEW. This is the core reason active directory time synchronization matters: it is not a housekeeping task, it is a Kerberos dependency.

The downstream effects go beyond logon failures. Replication between domain controllers uses Kerberos for authentication — skew causes replication access denied errors and USN conflicts. Group Policy processing requires an authenticated DC connection. Certificate validation compares timestamps. Log correlation across DCs becomes unreliable. Time is structural, not decorative.

The AD Time Hierarchy

Active directory time synchronization follows a defined authority chain. The forest-root PDC Emulator is at the top — it syncs from an external NTP source and is marked reliable. All other DCs in the domain sync from the PDC Emulator using the domain hierarchy (NT5DS). Domain members — servers, workstations — sync from any available DC in their site. This hierarchy is automatic once it is configured correctly.

The stratum level matters for reference. External NTP sources such as pool.ntp.org operate at Stratum 1 or 2. The forest-root PDCe becomes Stratum 2 or 3. Other DCs are one step below. Domain members sit below that. Windows does not display stratum directly, but w32tm /query /status shows it.

Two configurations break this hierarchy immediately: configuring non-PDCe DCs to use external NTP directly (creates competing time sources), and leaving hypervisor time synchronization enabled on virtual DCs (overrides W32Time with host clock).

First Response: Scope the Problem

Before running any fix, determine whether one machine is wrong or the whole domain is wrong. These are different problems with different starting points.

Find the PDC Emulator and Check Its Configuration

In /query /status, look at three fields: Source (should be an NTP hostname, not Local CMOS Clock), Last Successful Sync Time (should be recent), and Stratum (2–4 is normal for a DC; 16 means unsynced).

In /query /configuration, the PDCe should show Type: NTP and NtpServer: <your-peers>. Any other DC should show Type: NT5DS. If a non-PDCe DC shows Type: NTP with manual peers, that is a misconfiguration — it creates a competing time source for active directory time synchronization and must be returned to NT5DS.

Configure the Forest-Root PDC Emulator

Run these commands on the PDC Emulator only. Never run this configuration on a non-PDCe DC.

The ,0x8 flag forces client mode. Without it, some NTP servers reject Windows requests because Windows defaults to symmetric active mode. The /reliable:YES flag marks this DC as the authoritative time source for the domain — without it, other DCs may not recognize it as the top of the hierarchy.

Use multiple peers for redundancy. If one NTP server is unavailable, Windows selects another from the list. A single peer creates a single point of failure at the top of the entire domain time chain. Microsoft’s documentation on configuring an authoritative time server covers this configuration in detail.

To return a non-PDCe DC to the domain hierarchy after accidental misconfiguration:

Fix “Local CMOS Clock” on a Domain Controller

“Local CMOS Clock” in w32tm /query /source means W32Time has fallen back to the hardware clock because it cannot find a valid time source. This is one of the most common active directory time synchronization problems, and the fix depends on which DC is showing it.

If this is the forest-root PDCe: no external NTP is configured or reachable. Configure external NTP as above, then check that UDP 123 is not blocked outbound from this DC.

If this is another DC: it has lost contact with the PDCe or the domain hierarchy. Check network connectivity to the PDCe, then run w32tm /resync /rediscover. Verify its configuration shows Type: NT5DS. If the PDCe itself is broken, fix the PDCe first.

If this is a member server or workstation: check domain connectivity, Netlogon service status, and whether the machine can reach a DC. Time sync follows domain health — if the machine cannot authenticate to a DC, it cannot sync from one either.

Fix “The Computer Did Not Resync Because No Time Data Was Available”

This error from w32tm /resync is one of the most-searched W32Time messages. It surfaces for several different root causes, so the diagnostic order matters.

Fix 0x800705B4 and NTP Timeout Errors

0x800705B4 is a generic timeout — the NTP request was sent but no reply came back. The most common causes are UDP 123 blocked at the firewall, the NTP server not running or rejecting the client, NAT breaking NTP packet timing, or wrong peer flags causing mode mismatch.

If stripchart shows timeouts on all peers, the firewall is blocking UDP 123 outbound from the DC. Check firewall rules on the DC itself (Windows Firewall) and on any perimeter firewall. Some environments block UDP 123 outbound from servers by default.

If the peer responds to stripchart but Windows still will not sync, check the manualpeerlist flags. The ,0x8 (client mode) flag is required for many public NTP servers. Without it, Windows uses symmetric active mode and some servers refuse the request.

W32Time Event ID Reference

The 38 → 47 → 29 sequence is the most common active directory time synchronization event cascade. Events 38 and 47 indicate a peer is failing; Event 29 means no source is accessible at all. Always fix the peer source before anything else when you see this sequence in Event Viewer.

Kerberos Errors Caused by Clock Skew

Kerberos authentication failures caused by time skew are frequently misdiagnosed as SPN problems, password issues, or network errors. Time skew is the correct first check whenever Kerberos fails with an error code that maps to clock-related conditions.

If an appliance — NAS, backup product, Linux service, FortiGate — reports KRB_AP_ERR_SKEW, start by comparing the appliance clock to the DC it uses for Kerberos. Do not start with SPNs. SPN errors produce a different error code (KRB_AP_ERR_MODIFIED). Clock skew and SPN problems are not the same failure.

Domain Controller Not Advertising as a Time Server

dcdiag /test:Advertising checks whether the DC is advertising itself as usable. A failure here often correlates with Event 142 — the DC stopped announcing itself as a time source because its local clock is not synchronized. Fix the underlying active directory time synchronization issue first. Once W32Time syncs successfully, the DC resumes advertising and Event 35 or 37 confirms the recovery.

Virtual Domain Controllers: Hyper-V, VMware, and Proxmox/KVM

Virtual DCs are the most common source of persistent domain time drift in homelab and SMB environments. Hypervisor time synchronization overrides W32Time — the VM clock follows the host instead of the domain hierarchy. The fix is to disable the hypervisor guest time sync feature on every DC VM.

Hyper-V and VMICTimeProvider

Hyper-V injects a time provider called VMICTimeProvider into the guest. When enabled, it can override W32Time and sync the guest to the Hyper-V host clock. For domain controllers, the domain hierarchy must remain authoritative for active directory time synchronization.

The loop to avoid: a virtual DC syncs from the Hyper-V host. The host is itself a domain member and syncs from that DC. Both machines end up following each other, drifting together, and neither corrects the other.

VMware ESXi and the One-Off Synchronization Problem

VMware Tools has two time synchronization mechanisms: periodic sync (runs continuously) and one-off sync (runs during lifecycle events — vMotion, snapshot consolidation, resume from suspended state). Disabling the visible checkbox in VM settings disables periodic sync but may leave one-off sync active.

Per Broadcom KB 432522, VMware Tools can still perform one-off time corrections during VM lifecycle events even when periodic timesync shows as disabled. For domain controllers, verify both mechanisms. Keep the ESXi host clock accurate even when guests follow the AD hierarchy — if the host drifts and triggers a one-off correction, the guest DC clock changes unpredictably and active directory time synchronization breaks.

Proxmox and KVM: RTC localtime vs UTC

Windows traditionally expects the hardware RTC (Real-Time Clock) to store local time. Linux/KVM environments default to UTC. When a Windows DC VM runs on Proxmox, this mismatch creates large apparent time jumps after a shutdown/start cycle — the VM reads a UTC RTC value as local time and applies a timezone offset on top, producing a clock error equal to the UTC offset of the machine configured timezone.

In Proxmox VM settings, the “Use local time for RTC” option controls whether the hypervisor exposes local or UTC time to the guest. What matters is that the Windows guest and the Proxmox setting agree. Test this in a non-production VM before changing production DCs, and force a resync after any change: w32tm /resync /force.

Recovering From Domain-Wide Time Drift

When multiple DCs have wrong time — after a snapshot restore, a hypervisor host failure, or a prolonged NTP outage — fix in order. DCs must not all be corrected simultaneously. Correct the PDCe first, let it propagate, then validate downstream. This is the most operationally critical active directory time synchronization procedure.

Why a Domain Controller Will Not Correct a Huge Time Offset

Windows restricts how large a time jump W32Time will accept automatically. Domain controllers have a MaxPosPhaseCorrection (maximum forward correction) and MaxNegPhaseCorrection (maximum backward correction), both defaulting to 48 hours (172800 seconds) on Windows Server 2008 R2 and later. Member servers default to 0xFFFFFFFF (unlimited).

If a DC clock is wrong by more than 48 hours — after a prolonged outage, a corrupted CMOS, or a hypervisor failure — W32Time will not auto-correct it. The service accepts the NTP data, determines the required jump exceeds the phase correction limit, and does nothing. The clock stays wrong. This is a frequent source of confusion when active directory time synchronization appears healthy on the NTP side but the DC clock stays incorrect.

The fix is to correct the clock manually first, then let W32Time take over:

Do not permanently set MaxPosPhaseCorrection or MaxNegPhaseCorrection to unlimited on domain controllers. The 48-hour default is intentional — it prevents a corrupt NTP source from moving a DC clock by an arbitrary amount. Manual correction for exceptional situations is the right path, not permanently widening the safety limit.

After Moving the PDC Emulator Role, Update Time Configuration

When the PDC Emulator FSMO role is transferred or seized, the time configuration does not follow automatically. The new PDCe is still configured as a standard DC (Type=NT5DS), and the old PDCe may remain marked reliable with manual peers configured. Left uncorrected, active directory time synchronization breaks at the top of the hierarchy within hours.

This step is easy to skip after a role seizure during an outage. Add it to the FSMO seizure runbook. See FSMO roles in Active Directory for the full role transfer and seizure procedures.

Secure Time Seeding and Windows Server 2025

Secure Time Seeding (STS) is a feature that uses SSL/TLS certificate timestamps from HTTPS connections to periodically correct the clock. It is enabled by default in Windows Server 2016, 2019, and 2022. In Windows Server 2025, Microsoft disabled STS by default after customer reports of unexpected large time jumps in certain environments.

STS is not the routine cause of active directory time synchronization drift. It is a rare but serious cause of unexplained, large, one-time time jumps — the kind where the clock moves by hours or days with no W32Time event pointing to it directly. Microsoft’s guidance on Secure Time Seeding recommendations advises evaluating STS on domain controllers and VM hosts specifically.

On Windows Server 2025, STS is disabled by default and this step is not required. On Server 2022 and earlier DCs, consider disabling STS if you see unexplained time jumps that do not correlate with NTP source changes or hypervisor events.

Kerberos RC4/AES Hardening: Related, Not the Same Problem

Windows updates from April 14, 2026 (KB5073381) change the Kerberos KDC default for DefaultDomainSupportedEncTypes, moving toward AES-SHA1 only for accounts without an explicitly configured encryption type attribute. This affects authentication behavior but is distinct from clock skew — the two problems surface similar symptoms but require completely different fixes.

The connection: both time skew and Kerberos encryption changes can produce authentication failures after an update. If Kerberos auth is failing and active directory time synchronization checks out clean, check whether the RC4 hardening rollout is the cause — particularly for service accounts, legacy applications, or non-Windows systems without msDS-SupportedEncryptionTypes configured.

Validation Checklist

Prevention

Most active directory time synchronization failures are preventable with two standing practices: keep hypervisor time sync disabled on all DC VMs, and configure at least two external NTP peers on the PDCe. The rest of the hierarchy follows automatically.

For environments where the PDCe cannot reach public NTP — air-gapped networks, strict outbound firewall rules — a hardware Stratum-1 NTP appliance eliminates the public NTP dependency. A Raspberry Pi with a GPS HAT is a practical homelab option for under $50; commercial GPS NTP appliances are available for SMB environments where the hardware cost is justified by uptime requirements.

Add active directory time synchronization validation to the DC post-install checklist. See Active Directory post-install checklist for the full build-out sequence. When the PDCe FSMO role is moved, update time configuration on both the new and old PDCe immediately — it is a step that gets skipped in the stress of a failover and causes problems hours later. The full W32Time tools and settings reference is documented by Microsoft in their Windows Time Service tools and settings guide.

Frequently Asked Questions

Why does my domain controller show “Local CMOS Clock” as the time source?

W32Time cannot find a valid upstream time source and has fallen back to the hardware clock. On the forest-root PDCe, this means external NTP is not configured or UDP 123 is blocked. On any other DC, it means it has lost contact with the domain hierarchy. This is one of the most visible signs of active directory time synchronization failure at the top of the hierarchy.

Should the PDC Emulator use NT5DS or NTP?

NTP, with external manual peers. The forest-root PDCe must use Type=NTP with /reliable:YES. NT5DS is the domain hierarchy mode — if the PDCe uses it, it tries to sync from itself or another DC, finds no valid source, and falls back to Local CMOS Clock. Every other DC should use NT5DS.

Why does w32tm /resync say “The computer did not resync because no time data was available”?

Usually one of: no reachable upstream source (PDCe misconfigured or UDP 123 blocked), broken W32Time service registration (fix with /unregister + /register), or a domain member that cannot find the PDCe. Run w32tm /query /source and w32tm /query /configuration first to narrow the cause before resetting the service.

What does KRB_AP_ERR_SKEW mean?

Clock skew between the client and the KDC exceeds the Kerberos tolerance (default five minutes). The authentication ticket was rejected because the timestamp difference is too large. Compare the affected machine clock against the DC it authenticates against, then fix the time source through active directory time synchronization — not SPNs.

What is Event 4769 failure code 0x25?

A Kerberos service ticket request failed due to clock skew. Code 0x25 is KRB_AP_ERR_SKEW. It is distinct from 0x20 (expired ticket, common and often benign). When you see 0x25, check active directory time synchronization before investigating SPNs or passwords.

Can VMware Tools change the guest clock even when time sync is disabled?

Yes. Disabling periodic time sync in VMware Tools settings does not necessarily disable one-off synchronization during lifecycle events (vMotion, snapshot consolidation, resume). Per Broadcom KB 432522, the guest clock can still be corrected during these events. For DC VMs, verify both synchronization behaviors and keep the ESXi host time accurate regardless.

Should I disable Hyper-V time synchronization on domain controllers?

Yes. Disable the Time Synchronization integration service on all DC VMs in Hyper-V. Let W32Time and the domain hierarchy manage active directory time synchronization. The risk of leaving it enabled is a loop where the virtual DC follows the Hyper-V host clock and the host is itself a domain member syncing from that DC.

Why will a domain controller not correct a large time difference automatically?

MaxPosPhaseCorrection and MaxNegPhaseCorrection limit automatic clock corrections to 48 hours by default on domain controllers. If the offset exceeds this limit, W32Time will not apply it. Manually set the correct time first with Set-Date, then let W32Time resync from the corrected state.

Should I disable Secure Time Seeding on domain controllers?

On Windows Server 2025, STS is disabled by default — no action needed. On Server 2022 and earlier, consider disabling STS (UtilizeSslTimeData=0) on domain controllers and VM hosts if you experience unexplained large time jumps. STS is not the cause of ordinary active directory time synchronization drift, but it can produce rare, hard-to-diagnose sudden time corrections.