Active Directory domains rely on synchronized time for a number of key operations. For example, all Kerberos messages passed between domain members and domain controllers have a maximum default lifetime of 5 minutes. This limitation is intended to make the messages useless to attackers who might capture the messages on the network; by the time the attacker is able to decrypt and modify the packet (if the attacker is able to do so at all), the message will be useless.
Active Directory replication is not especially time-sensitive and only uses timestamps as a tiebreaker in certain circumstances.
If time synchronization fails, the operations that depend upon it can also fail. For example, suppose a client computer has a local time of 10:00am, and its closest domain controller has a local time of 10:06am. Kerberos packets time-stamped by the client will be considered out of date by the domain controller even if those packets arrive immediately. The domain controller will reject the logon attempt, and the client will display a generic logon failure message— making it a difficult problem to detect without careful detective work. Understanding how the time sync process works is important to keeping the process running smoothly and solving any problems that occur.
Windows 2000 (Win2K) and later include the Windows Time (W32Time) service, which is configured as a standard Windows background service to start automatically and to log on as the special LocalSystem account. This service is a Microsoft implementation of a Request for Comment (RFC)-compliant Simple Network Time Protocol (SNTP) client and server.
The Windows Time service originally provided in the Windows NT resource kit is not compatible with W32Time. However, Microsoft makes an NT-compatible W32Time service, which allows NT computers to participate in Active Directory domain time sync. Obtain the updated service from Microsoft.
Computers that aren't members of a domain don't automatically synchronize time. However, because the W32Time service is a standard SNTP client, you can configure it to synchronize with any available SNTP server. To do so, simply double-click the clock in the computer's taskbar, and select the Internet Time tab, which Figure 7.1 shows.
Figure 7.1: Manually configuring time sync.
As Figure 7.1 shows, Windows XP Professional includes a number of preconfigured Internet time servers, including one made available by Microsoft. Other time sources include the official United States government time server at http://www.time.gov.
Obviously, time sync can only occur when the computer is connected to the Internet, so it works best if your computer utilizes an always-on broadband connection. However, Windows will automatically detect a network connection—such as a dial-up connection—and attempt time sync when necessary. By default, Windows attempts to sync about every 8 days.
Windows doesn't synchronize the system date only the time. Furthermore, Windows won't synchronize the time if the date isn't correctly set.
Within a domain, time synchronization is a good deal more complex because there are so many computers that need to be in sync with one another. At the top of the time sync authority list is the domain controller that holds the PDC emulator role in the forest root domain. That domain controller is considered the most authoritative source for time information in the entire forest, and the time sync process attempts to bring all other domain clocks into sync with that domain controller.
All domain controllers within a domain attempt to synchronize time. If possible, they try to find a reliable time service in their parent domain. If unavailable, they'll try for a reliable time service in their own domain. Generally, the reliable time service is held by the domain controller that holds the PDC emulator role for the domain. This query process of determining a reliable time service is a bit complex, and I'll cover it in more detail next.
All domain controllers holding the PDC emulator role will try to sync time with the PDC emulator of their parent domain. This behavior creates an easy-to-understand hierarchy of time sync leading up to the forest root domain's PDC emulator.
All client computers synchronize time with the domain controller that authenticates them to the domain. The key, then, is in how domain controllers (other than those holding the PDC emulator role) decide which computer to synchronize time with.
Domain controllers will nearly always select their parent domain's PDC emulator as their time source. However, if that computer is unavailable or does not respond promptly, they will attempt to instead synchronize with their own domain's PDC emulator. Each domain controller's selection is based upon an initial query; if, for example, the parent domain's PDC emulator doesn't quickly respond to the initial query, the domain controller will be more likely to choose the PDC emulator from its own domain.
The entire time sync process for domain controllers ranks time sources by stratum. Stratum one is an external time source, such as the US Naval Observatory (which I'll discuss in the next section). The forest root PDC emulator represents stratum two. All domain controllers accessing time from the forest root PDC emulator are stratum three, and any domain controllers that get their time from them (the domain controllers accessing time from the forest root PDC emulator) are in stratum four, and so forth. Each stratum is progressively less accurate due to network latency, local clock inaccuracies, and so forth.
Windows includes the ReliableTimeSource registry entry, which optimizes time synchronization. When set to 1 on a domain controller, the Netlogon service on that domain controller broadcasts an announcement that the domain controller is a reliable time service. Other domain controllers will prefer a reliable time service if one is available. Generally, this registry entry should only be set to 1 when the computer is in stratum two (synchronizing with an external time source). When a domain controller starts, it will attempt to locate a time source:
These attributes are ranked from most important to least important, and result in a selection preference something like the following order (from most preferred to least preferred):
This list can enable you to determine which time source a domain controller will attempt to select. Keep in mind that if such a source is available but is too busy to respond to a domain controller's initial query, the domain controller will try to find the next preferred source on the list.
Computers will never choose themselves to sync with. They'll move on to the next preferred source on the list, if necessary.
The PDC emulator in the forest root domain does not attempt to synchronize time with anyone; it considers itself authoritative by default. For the best time synchronization, however, you should configure this domain controller to synchronize with an authoritative, Internet-based time source. To do so, open a command-line window on the domain controller. Run
net time /setsntp:server replacing server with the fully qualified name of an authoritative time source.
The US Naval Observatory is considered the United States' official source of time. The observatory maintains a cesium-based atomic clock that is the most accurate timepiece in the world. This clock is connected to several Internet-based time servers that can be used by the public (including ntp2.usno.navy.mil and tock.usno.navy.mil). Note that the SNTP protocol uses UDP port 123 by default, so your domain controller will need access to the Internet on that port in order to sync time.
If your network spans multiple time zones, you should always configure your forest root PDC emulator to synchronize with an authoritative outside time source. Doing so will ensure that your entire network receives authoritative time, and that time-dependent network operations will work as smoothly as possible.
For Microsoft's documentation about configuring a time source, see the Microsoft articles "How to Configure an Authoritative Time Server in Windows 2000" and "How to Configure an Authoritative Time Server in Windows XP."
When computers sync time, they don't necessarily make an instant, radical adjustment to their local clocks. Doing so could disrupt other processes, so the time sync process takes a more gradual approach.
First, the W32Time service exchanges network packets with its selected time source to determine network latency. Doing so provides an internal adjustment based on how much time is required for time sync packets to physically cross the network, and is measured in nanoseconds.
Next, the service examines the target time provided by its times source. If the target time is ahead of the current local time, the service immediately adjusts the local time to the target time. A slow local clock can be a major problem for Kerberos and other operations, so any other potential disruptions by the sudden shift in time are considered secondary concerns.
The actual formula used to calculate target time is specified in RFC 1769, and is LocalClockOffset = ((ReceiveTimestamp – OriginateTimestamp) + (TransmitTimestamp – DestinationTimestamp)) / 2, which accounts for network latency.
If the target time is behind the current local time, the local time is slowed until it equals the target time. Effectively, local time will begin to pass more slowly until the target time catches up. However, if the local time and target time are more than 3 minutes out of sync, the local clock is immediately adjusted to match the target time.
Time sync normally occurs about every 45 minutes by default. Once time sync has successfully completed at least three times, the period is extended to 8 hours, and remains at that setting so long as each attempt to sync is successful. If any attempt fails, time sync reverts back to 45 minutes.
Sync periods are more frequent than 8 days for computers that use the Kerberos protocol because time is so important to this protocol.