Time synchronization in Active Directory: the PDC emulator, Kerberos and virtualization pitfalls
Time synchronization is one of those topics nobody notices until it breaks. Yet in an Active Directory domain, time is a security matter: Kerberos depends on it, and so does log correlation. A sloppy setup leads to authentication failures that are hard to diagnose and to misleading investigations.
Why time is a security issue
Kerberos relies on timestamps to protect against replay: a request whose time differs too much from the domain controller's is rejected. The tolerance is set by the Kerberos policy setting "Maximum tolerance for computer clock synchronization", five minutes by default. Raising it to hide a synchronization problem weakens protection and solves nothing.
Beyond Kerberos, time governs certificate validity, time-based one-time codes and, above all, the ability to reconstruct an attack. When logs from domain controllers, firewalls and workstations are not aligned, the timeline of an incident becomes a matter of debate rather than an established fact.
The domain time hierarchy
The Windows Time service (W32Time) builds an automatic hierarchy when machines use domain hierarchy synchronization (type NT5DS):
- member workstations and servers sync with a domain controller in their domain;
- domain controllers sync with their domain's PDC emulator, or with a DC in the parent domain;
- the PDC emulator of the forest root domain is the reference source for the whole forest.
Only that last one should be configured to query external sources (type NTP), ideally several reliable servers: internal time servers backed by a hardware reference, or trusted public servers allowed through the firewall. All other domain controllers stay in hierarchy mode. Manually setting an external source on every DC breaks the consistency of the hierarchy.
Following the PDC emulator role
The classic trap appears when the PDC emulator role is transferred: the new holder points to no external source, while the old one keeps advertising itself as a reliable source. To avoid this, many organisations apply the configuration through a dedicated GPO linked to the Domain Controllers OU and filtered by a WMI query targeting the PDC emulator role. The configuration then follows the role automatically. Also add a time check to your FSMO role transfer procedure.
The commands w32tm /query /status, w32tm /query /source and w32tm /monitor let you verify each machine's effective source and the offset between domain controllers.
Virtualized domain controllers
Virtualization adds a second potential time source: the hypervisor. Hyper-V integration services and guest tools on other platforms can sync the virtual machine's clock with the host. If the host drifts, or if it syncs itself from a domain controller it hosts, you get loops and unpredictable time jumps.
The general recommendation is for virtualized DCs to get their time from the domain hierarchy rather than the hypervisor, while keeping in mind that some platforms resync the clock on specific events (resume from suspend, migration, snapshot restore). The exact settings depend on the platform and its version: follow the hypervisor vendor's documentation and Microsoft's guidance on virtualized domain controllers.
Watch automatic mechanisms too. Some Windows features designed to correct the clock at startup have caused large time jumps in certain environments. Assess how they behave on your domain controllers in light of current Microsoft recommendations.
What an audit checks
- the time source of the forest root PDC emulator and its reliability;
- hierarchy mode on other domain controllers and on member machines;
- the measured offset between domain controllers and the Kerberos tolerance value;
- hypervisor time sync configuration for virtualized DCs;
- whether time checks are part of role transfer procedures.