Time Services

The introduction of Kerberos for authentication in Windows 2000 provided much more secure authentication than was available with Windows NT. However, because Kerberos provides secure authentication by comparing time stamps between client and server, accurate Time Services is critical. Windows 2000 implemented time synchronization through w32tim.dll and used the Simple Network Time Protocol (SNTP), which is described in RFC 1769 and uses UDP ( User Datagram Protocol) port 123. SNTP allows time synchronization of computers within about two seconds. Windows 2000 also provided the W32tm.exe troubleshooting utility for performing time configuration modifications.

Windows 2003 increased the accuracy of time synchronization by adopting the Network Time Protocol (NTP), which has the capability to synchronize time within milliseconds . Because all computers ” clients , servers, DCs ”must all converge on the same time, accurate time synchronization is important.

Time Services Role in Authentication

Because I have never found any satisfactory documents explaining how Windows 2003 time services works with authentication, I'm providing it here with illustrations to help explain the concepts. Figures 6.14 through 6.18 show details of how Time Services work during the authentication process. In Figure 6.14, the user enters a username and password in response to an authentication request. At that point, the authenticator is created, which contains the user's public key, certificate, and a time stamp. The KDC (Kerberos Distribution Center) checks the credentials and, if valid, allows the user to log in. The time stamp reflects the time the request was made and is obtained from the client's system clock. The KDC validates the user account and password, checks the public key and certificate, and allows the user to log in.

Figure 6.14. Basic Kerberos authentication in Windows 2003 requires the use of system Time Services.

Figure 6.18. The session ticket is presented by the authenticated client to each server for access to resources. The server makes the final determination of access based on permissions applied to the resource.

Now let's look more closely at the role of Time Services in that process. Figure 6.15 shows the internals of the authenticator. The time stamp is encrypted for security to prevent attacks known as Expired Ticket Acceptance Attacks and Replay Attacks, discussed later in this section. If the client's time from the authenticator, compared to the server's system time, is within the allowable time skew (default is five minutes), then the request is honored. If the time skew is greater than the defined value, the server requests the Windows Time Service to correct the time stamp to allow the logon request to succeed, as depicted in Figure 6.16. This allows computers in trusted domains ” especially those in different forests ”to authenticate without changing the client's system time for each request.

Figure 6.15. The client time stamp is decrypted and checked against the server's system time to determine whether it is within the defined skew.

Figure 6.16. Dealing with time skew error in Windows 2003.

note

When the server corrects the client's time when the skew is greater than the value allowed (default is five minutes), and within the defined Kerberos user ticket lifetime (default is ten hours), it is corrected only in the time stamp of the authenticator. It does not change the client's system time.

If a client receives a clock skew error, the server allows the client to authenticate up to four times before the request is denied , forcing the client clock to be synchronized with the server clock.

At this point, illustrated in Figure 6.17, the server returns the authenticator to the client with its public key and corrected system time if necessary, the user obtains a session ticket, and the logon request is successful.

Figure 6.17. The server returns modified authenticator to the client if logon is successful.

Time Services in Basic Authorization

After the user obtains a session ticket, he or she can present that ticket to any server in the domain or a trusted domain to access resources such as file shares, databases, printers, and so on. This is referred to as authorization . The server hosting the resource authorizes use of the resource if the following are true:

• The session ticket hasn't expired.

• The user was properly authorized by a KDC in the domain.

• The user has necessary permissions to perform the desired operation on the resource.

The session ticket needs to be presented only once during the ticket lifetime (default ten hours) to a server to access any resources that server is responsible for. For example, if a ticket is presented to SRV1 for access to a printer, SRV1 does not require the ticket to be presented for access to a file share it hosts if the request is made within the lifetime of the ticket, as shown in Figure 6.18. However, if the user accesses a resource on another server, the session ticket must be presented to that server. This is basic Kerberos authorization with the exception that in the Windows environment, the KDC is located via the DNS Kerberos SRV record.

Security Functions

The use of Time Services in user authentication prevents Expired Ticket Acceptance Attacks where the attacker uses a previously sent ticket that has been used for authentication to a server whose clock is slow. Kerberos requires the computers to have their time synchronized within a defined time skew. In Windows 2000 and 2003, the default is five minutes and is configurable via Group Policy in Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\Maximum Tolerance for computer clock synchronization, as shown in Figure 6.19. Kerberos also prevents Replay Attacks in which the attacker uses an authentication request to gain access to a restricted resource. When the server decrypts the client's time stamp, it's checked to ensure that the time is not the same or earlier than the time of another access request made by the same client. The server checks each request with a list of times stamped on access requests made within the skew time. If the time received is the same or earlier than the time of the last entry from that client, an error is logged on the client and access is denied.

Figure 6.19. Kerberos time skew is defined in Group Policy as Maximum Tolerance for Computer Clock Synchronization.

Configuring Kerberos Policies

Although the ticket lifetime and the time skew are configurable via Group Policy, I would not recommend modifying the default values, because this will have performance and security consequences. Shortening the time skew or the ticket lifetime makes security tighter by limiting the time a ticket could be used by an attacker, but it also reduces the performance for the user by requiring a new ticket more frequently (ticket lifetime) and reduces the allowable window that the computers in the domain can be out of sync with each other, making time management more difficult. Before you modify these values, remember to carefully analyze the need and potential risks and test it before putting it in production.

External Time Source

External time sources are not necessarily required for Windows; however, by default, Windows 2003 Server and Windows XP define time.windows.com as the external time server. This can be seen on the Internet Time tab in the Date and Time Properties dialog box for standalone computers or by entering the command net time /querysntp at the command prompt. The Internet Time tab is hidden from view if the computer is a member of a domain or if the user does not have Administrator privileges. Note that Windows 2000 Server and Professional have no default external time source defined.

An external time source is useful for configuring Kerberos trusts across multiple forests. Although Time Services can be synchronized across forests, there is no way to provide security for NTP outside the domain/forest. Therefore, if each forest uses an external time source for the PDC of the root domain in each forest, both forests will be in sync, making cross forest trust functions work reliably.

Domain Time Hierarchy

Each Windows 2003 server or XP client must find an authoritative time source when it boots. DCPromo also performs time synchronization during the promotion of a new DC. When booting, each client and member server computer uses its authenticating DC as a time source. DCs in a child domain use the PDC Emulator of their domain or any DC in the parent domain as the authoritative time source when they boot, and the PDCs of child domains use the PDC of the forest root domain or any DC in the root domain as the authoritative time source. DCs in the root domain use the PDC of the root domain as the reliable time source. The PDC of the root domain should be configured to point to a reliable external time source. The PDC can point to itself as the time source, and Windows will be happy. However, you might have applications or external trusts that dictate the configuration of an external time source.

Designation of Reliable Time Source

Although the domain hierarchy just described is the default and is recommended to use, you can designate a reliable time source of your choosing. A reliable time source must synchronize with a DC in the parent domain; like any DC, this DC will never attempt to synchronize with itself. A reliable time source can be manually configured via Group Policy in Computer Configuration\Administrative Templates\System\Windows Time Service. Go to Global Settings, click the Enabled option; then find Announce Flags in the list below that, and set that value to 6 as shown in Figure 6.20.

Figure 6.20. Setting the Group Policy setting to configure a specific reliable time source.

Designation of NTP Server

You can manually designate an NTP server or optionally use a third-party NTP service. If you do the latter, you must disable the Windows Time Service and disable the Windows NTP client in Group Policy under Computer Configuration\Administrative Templates\System\Windows Time Service\Enable Windows NTP Client.

The NTP server can be specified manually in the W32tm.exe command-line tool built into the OS. The syntax is:

 W32tm /config /syncfromflags:MANUAL /manualpeerlist:list DNS or IP address /  update  

The manualpeerlist specifies the DNS name or IP address of the NTP server to be used. Multiple entries must be separated with commas.

This is intended for standalone computers that are not members of a domain. However, you can specify the NTP server in a domain, but this is not recommended. I had one customer who complained about Time Services not working correctly ”he was logging W32tm errors and warnings in the system event log, replication was broken, and authentication was sporadic. On questioning him, he admitted to "designing" his Time Services and specifying an NTP server. Thus, he had overridden all of the automatic configuration built into Windows for Time Services. It took awhile, but we reset everything back to default ”removed the Group Policy, reset the W32tm configuration, and so on. After everything was back to default, it all worked again.

warning

Windows 2003 Time Services in a Windows 2003 domain with Windows 2003 DCs does not require any configuration or intervention. Unless you have good, supportable reasons to change it, leave it alone. Time Services are critical to the security and health of the environment. Don't configure them on a whim.

Basic Troubleshooting with W32tm.exe

One of the most common problems regarding Time Services is the failure of a client (including DCs) to find a time source for synchronization. Microsoft provided the W32tm.exe tool native to Windows 2000 to help resolve these issues. However, the errors and solutions are very different between Windows 2000 and 2003, and the W32tm tool has different options and behaviors.

In Windows 2000, Event ID 54 and 64 (warnings) are recorded in the system event log, with a W32time source. Failure to correct this condition could result in authentication failure if the system clocks are more than five minutes (or whatever you defined the time skew to be in Group Policy) out of sync with each other. This will not only prevent users from logging in, but will cause replication and other services to fail. This is a fairly easy problem to resolve. Note the description of Event ID 64:

 12/2/2003     8:21:19 PM    w32time Warning None 64 N/A ATL-DC1 "Because of repeated network problems, the time service has not been able to find a domain  controller to synchronize with for a long time. To reduce network traffic, the time  service will wait 960 minutes before trying again. No synchronization will take place  during this interval, even if network connectivity is restored. Accumulated time errors  may cause certain network operations to fail. To tell the time service that network  connectivity has been restored and that it should resynchronize, execute the following  command from the command line:  C:/> w32tm /s  

This event is usually caused by a network connectivity issue, the server being down, or the server being otherwise unavailable. The command shown in bold in the event is incorrect. There are actually two common commands that can be used:

 C:> w32tm s [computer] Forces the local computer to synchronize if [computer] is blank, or enter a computer name  to execute this for a remote computer. OR C:> w32tm once  Forces the local computer to synchronize once. 

There are a lot of command options, but these two are usually the only ones you need. Look at the online help for information on the other options. You could also manually synchronize with the time server using the SNTP command C:> Net Time /setsntp=<time server name> , but it's not the preferred method.

In Windows 2003, there are more warnings, better descriptions, and a more tolerant algorithm for synchronizing out-of-step servers. Typically, a DC records Event ID 14 and 29 (W32Time source) in the system log:

 8/21/2003 11:40:15 PM W32Time Error   None   29 N/A ATL-DC1 The time provider NtpClient is  configured to acquire time from one or more time sources, however none of the sources are  currently accessible. No attempt to contact a source will be made for 15 minutes.  NtpClient has no source of accurate time. 8/21/2003 11:40:15 PM   W32Time Warning None 14N/A ATL-DC1 The time provider NtpClient was  unable to find a domain controller to use as a time source. NtpClient will try again in 15  minutes. 

This event will be repeated 6 more times indicating retry periods of 30, 60, 120, 240, 480, and 960 minutes. At last, it will record Event ID 49:

 9/12/2003   2:47:15 AM   W32Time   Warning   None   49   N/A   ATL-DC1   The time provider  NtpClient was unable to find a domain controller to use as a time source. NtpClient will  continue trying to locate a DC every 960 minutes. This message will not be logged again  until after a domain controller is found. 

Obviously these need to be monitored , but they also indicate effort on the part of W32time to synchronize with a reliable time source. If it does, Event ID 35 will be recorded:

 8/28/2003   6:09:34 AM   W32Time   Warning   None   50   N/A   ATL-DC1   The time service  is now synchronizing the system time with the time source hemlock.internal.myhappyvpn.com  (ntp.d  10.0.7.253:123->10.0.2.252:123). 

Also note that Event ID 50 will indicate the client is outside the time skew:

 8/28/2003   6:09:34 AM   W32Time   Warning   None   50   N/A   ATL-DC1   The time service  detected a time difference of greater than 5000 milliseconds for 900 seconds. The time  difference might be caused by synchronization with low-accuracy time sources or by  suboptimal network conditions. The time service is no longer synchronized and cannot  provide the time to other clients or update the system clock. When a valid time stamp is  received from a time service provider, the time service will correct itself. 

These logs came from a Windows 2003 DC that is in a domain deployed across several sites, all connected by VPN links. The DC was trying to synchronize with a time source (the PDC Emulator for the domain) across the VPN link, and occasionally failed due to the unreliability of the VPN connection.

The solution again is in the built-in Windows 2003 W32tm.exe tool. The options commonly used to resolve time synchronization errors ( assuming the time server is accessible) include

• W32tm /resync : This forces the computer to resync its clock.

• W32tm /config /manualpeerlist:<peers> : Defines the computer to synchronize time with those in the peer list.

• W32tm /config /synchfromflags:DOMHIER : This permits the computer to synchronize from the domain hierarchy as explained previously in this section. This is typically the best solution.

• w32tm /stripchart /computer:<target> : This command produces a strip chart of the time difference between the local computer and the computer specified in the command as <target>. This is an easy way to observe the time skew.

note

The Windows 2000 version of W32tm.exe is very different from the Windows Server 2003 version. The options in the previous list are not available for the Windows 2000 version, but one handy command is w32tm /once , which synchronizes to the time server once. You can get additional information about w32tm in the online help and at the Microsoft Web site.