The Windows Time service (W32Time) is designed to maintain date and time synchronization for computers running client and server versions of Microsoft Windows. The primary use for such time synchronization is to ensure the security of Kerberos authentication within an Active Directory environment including virtual machines running on Hyper-V hosts. To prevent replay attacks, Kerberos tickets presented to domain controllers by clients are time-stamped. The authenticating domain controller checks to make sure the timestamp is unique and falls within an allowable skew before accepting the ticket and authenticating the client. To ensure this system works properly, both the client and the domain controller clocks must be loosely synchronized within the allowable skew, and W32Time ensures this is the case.
W32Time is based on the Simple Network Time Protocol (SNTP) and its most current version (v4) is now specified by the IETF informational standard RFC 4330 and the proposed standard RFC 5905. SNTP is designed to ensure loose synchronization only, which in the W32Time implementation means the clocks of all Windows computers in a forest will agree within 20 seconds of one another (or two seconds difference within a particular site). W32Time expresses clock times in Coordinated Universal Time (UTC), an atomic time scale previously known as Greenwich Mean Time (GMT). W32Time is started by default on all Windows computers when they belong to an Active Directory domain.
Understanding the time hierarchy
W32Time synchronizes clocks within a forest using a time hierarchy that begins with the PDC Emulator in the forest root domain, which is considered the stratum 2 time source for the forest. This domain controller can have its own clock controlled several ways:
- By synching to a reliable time server on the Internet.
- By synching to an locally connected hardware time source such as an atomic clock.
- By relying on its own internal CMOS clock for reliable time.
In the first two examples above, the Internet time server or atomic clock is considered a stratum 1 time source. Other domain controllers in the forest root domain and PDC Emulators in child domains use W32Time to poll the PDC Emulator in the forest root domain periodically to ensure their clocks remain synchronized. Workstations and member servers then poll domain controllers in their domains to synchronize their own clocks, with the result being that all computers in the forest synchronize their clocks, either directly or indirectly, with the PDC Emulator in the forest root domain (and hence the external time server or atomic clock, if present). The following table summarizes how the W32Time hierarchy works, starting from the external source.
|1||Locally connected hardware clock (optional)
Internet time server (optional)
|2||PDC Emulator in forest root domain|
|3||Other domain controllers in forest root domain
PDC Emulators in child domains
|4||Workstations and member servers in forest root domain
Other domain controllers in child domains
|5||Workstations and member servers in child domains|
The polling process is initiated when W32Time starts on the client and is repeated every 45 minutes by default. If clocks are determined to be synchronized for three consecutive polls, the polling interval is increased to every eight hours.
The remainder of this article focuses on time synchronization in an Active Directory environment where domain controllers are running Windows Server 2008 or later. For information about the various improvements to the Windows Time Service that have been implemented in Windows Server 2016 see this documentation in the Windows IT Center on Microsoft’s website.
Synching to an internal time source
The simplest solution to time synchronization in an Active Directory environment is to let the PDC Emulator in the forest root domain use its own CMOS clock as the source of reliable time for the forest. To do this, you can simply take no action. The only annoying result is that you will occasionally see the following event logged to the System log in Event Viewer:
Event ID: 12
Event source: W32Time
Event description: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.
Basically, what this event means is that the PDC Emulator in the forest root domain has not been configured to synchronize its clock with an external stratum 1 time source, and as a result the clocks on all machines in your forest cannot be considered reliable. Now this may be an issue if employees rely upon their workstations’ CMOS clocks for signing in and out, but as far as Kerberos is concerned it’s a nonissue because Kerberos only requires that clocks on clients and authenticators agree with each other, not that they display accurate time. So if every machine’s clock in the forest is one hour late, Kerberos will still work fine and replay attacks will be prevented, which is the purpose of W32Time anyway.
Synching to an external time source
If you want to ensure that the clocks on your machines are more accurate in terms of absolute (and not just relative) time, you can sync the PDC Emulator in your forest root domain to one of the reliable time servers available on the Internet. This is a good idea if your company is a large enterprise with sites spanning several countries, or if your organization has two or more forests linked by forest trusts. The procedure for doing this on the PDC Emulator in your forest root domain is as follows. Open Registry Editor (regedit.exe) and configure the following registry entries:
This registry entry determines that peers W32Time will accept synchronization from. Change this REG_SZ value from NT5DS to NTP so the PDC Emulator synchronizes from the list of reliable time servers specified in the NtpServer registry entry described below:
This registry entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change this REG_DWORD value from 10 to 5 here:
This registry entry specifies a space-delimited list of stratum 1 time servers from which the local computer can obtain reliable time stamps. The list may consist of one or more DNS names or IP addresses (if DNS names are used then you must append ,0x1 to the end of each DNS name). For example, to synchronize the PDC Emulator in your forest root domain with tock.usno.navy.mil, an open-access SNTP time server run by the United States Naval Observatory, change the value of the NtpServer registry entry from time.windows.com,0x1 to tock.usno.navy.mil,0x1 here. Alternatively, you can specify the IP address of this time server, which is 126.96.36.199 instead.
TIP: For other stratum 1 time servers maintained by the United States Naval Observatory (USNO) see here.
Now stop and restart the Windows Time Service using the following commands:
net stop w32time
net start w32time
It may take an hour or so for the PDC Emulator to fully synchronize with the external time server because of the nature of the polling method W32Time uses. Depending on the latency of your Internet connection, the accuracy of the CMOS clock on your forest root PDC Emulator may be within a second or two of UTC. If you need more accurate time, however, you can purchase a hardware time source like an atomic clock and connect it to your PDC emulator.
Alternatively, if you don’t want to wait for time convergence to occur between your stratum 2 time server (your forest root PDC Emulator) and the external stratum 1 time server, you can run the following command on your PDC Emulator:
w32tm /resync /rediscover
TIP: There are some additional registry settings you can configure to ensure external time synchronization operates effectively. See this article in the Microsoft Knowledge Base if your domain controllers are running Windows Server 2008 or Windows Server 2008 R2 or this documentation in the Windows IT Center on Microsoft’s website if your domain controllers are running Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016.