Keeping Time in Windows 2000

The Windows Time Synchronization service ensures that all your machines stay—tick for tock—on the same clock.

• By Michael Chacon
• May 01, 2001

Does anybody really know what time it is? Does anyone really care? Well, you do if your network authentication system depends upon a network-wide concurrent time stamp. With Windows 2000, the default authentication protocol is Kerberos—that cross-platform, triple-headed hound of security. One of the components of that authentication method is the granting of tickets that are time-stamped. This time stamping is partly used to verify the legitimacy of the ticket. And these time-stamped tickets are your entry into the resources of your network. For this reason alone, a time service on a Win2K network is essential. I’m not going to go into the gory details of Kerberos here, but—trust me—time is important. It’s also important for many other applications and, if nothing else, it’s quite convenient to know when a file was created or modified.

Get In Synch
Win2K uses the Windows Time Synchronization service to ensure that all of the Win2K machines in the enterprise share a common time. This service is run as W32Time by default on every Win2K machine. W32Time is an implementation of Simple Network Time Protocol (SNTP), described in Informational RFC 1769.

SNTP is an adaptation of the Network Time Protocol (NTP) described in Standard RFC 1305. NTP is used to provide a level of accuracy of 1 to 50 ms between connected computer clocks across the Internet, taking into account latency, jitter and other internetwork anomalies. This is fine for major backbones, but the same accuracy, complexity and overhead isn’t required for simple LAN purposes. SNTP is quite sufficient. SNTP operates in either a unicast or multicast mode. Unicast is preferable, since you can specify the server from which you’re requesting service and ignore attempts from unknown parties that could distort or misdirect your timeserver. The multicast mode, which finds anonymously available timeservers, isn’t a good idea.

The W32Time SNTP service needs to access an NTP server to use as its authoritative time-setting source, and there are three connection methods. One is via radio, accessed via a specialized piece of hardware that’s essentially a radio that listens in at the MHz listed. You won’t find this in most organizations. The U.S. Bureau of Standards broadcasts the time at 5MHz, 10MHz, 15MHz, 20MHz, and 25MHz, which can be tuned into with a special receiver. This is probably overkill for most facilities, but available if microsecond accuracy is important to your network.

Using a modem to directly dial into an NTP server is another method. This necessitates dialing repeatedly into an NTP server and brings potential modem difficulties into play that are best avoided.

Both of these methods provide direct connections to the NTP server, eliminating latency when setting the clock.

The third and easiest way to obtain time from an NTP server is to connect through the Internet. There are many NTP servers that can be reached on a regular basis. As with all Internet connections, there are latency issues, so it’s best to pick a few NTP servers that are consistently available. A simple way to determine reliable and available time service is to locate candidate NTP servers, PING them periodically over a period of several hours and days, and analyze the replies for the shortest consistent round-trip delays.

Set Up the Service
After determining which NTP servers to use as the authoritative timeserver, you can use that source to set the W32Time SNTP service with these commands:

NET TIME \\W2KSERVER.DOMAIN.COM //SETSNTP:
"Ntp2.usno.navy.milTock.usno.navy.mil"

or

NET TIME \\W2KSERVER.DOMAIN.COM //SETSNTP:
"192.5.41.209 192.5.41.41"

As you can see, the NET TIME command can use either a DNS host name or an IP address. The host name is somewhat self-documenting, but an IP address removes any name-resolution problems when obtaining the time.

Cover your Bases
Regardless of your approach, you should enter several servers’ addresses in the command line in case an NTP server fails to respond or is otherwise unavailable. If one isn’t available, W32Time will query the next server in the command line. For this reason, it’s also a good idea to list servers in different physical locations in case of Internet brownouts or other availability problems.

Another consideration is the rank of the NTP server you’re connecting to as the authoritative server. This layered ranking of the NTP hierarchy to which a server belongs is called a stratum. Stratum 1 is an NTP server that’s directly synchronized with the Coordinated Universal Time (UTC) through a radio, satellite or modem connection. UTC is an international cooperative effort to pinpoint an agreed-upon world time. The United States uses atomic clocks managed by the National Institute of Standards and Technology (NIST) and the U.S. Naval Observatory to establish the time and provide our contribution to the worldwide UTC effort. An NTP stratum 2 server obtains its time from an NTP stratum 1 server, a stratum 3 server gets its time from a stratum 2 server, and so on. Thus, the higher along the stratum food chain you obtain your time, the more accurate the time on your network.

Set the Pecking Order
So now, which server on your Win2K network do you make authoritative? You’re probably aware that the multimaster model of Active Directory is still dependent upon several single master domain servers in the directory. These are called Flexible Single Master Operations (FSMO) servers and they perform various functions for maintaining AD and provide backward compatibility with Windows NT.

Since W32Time synchronization uses the AD domain hierarchy to maintain time synchronization, the PDC Emulator FSMO in the root domain of the Win2K AD forest is the authoritative timeserver for the Win2K network. This server should have the time from the NTP stratum 1 server using the NET TIME command. Other domain controllers in other domains will synchronize from this one, and any child domains of these DCs will get their time from their parent DCs. As workstations are authenticated, they’ll obtain their time from the authoritative DC . In this manner, all Win2K machines will have a consistent time based upon the time obtained from the authoritative NTP server.

When the Win2K workstation client boots SNTP, packets are exchanged with the authenticating DC, and W32Time determines the correct time from its authoritative server. If the client time is behind the server time, it’s immediately changed to the correct time. However, if the client time is ahead less than two minutes, the client clock is slowed down until the time is synchronized.

After this initial synchronization, the client performs a time check in eight hours. If the time is off by more that two seconds, the next check is performed in four hours. If the time is off by more than two seconds, it’s checked again in two hours. The minimum amount of time between checks is 45 minutes, with a maximum of eight hours. These default checks are also configurable for periods of a week, every three days or every two days by editing the registry. This usually isn’t necessary, as the defaults work fine in most instances.

The most important factor is to make sure the PDC Emulator FSMO in the AD root domain is configured to get its time from an accurate, reliable and authoritative NTP source.

The Windows Time Synchronization service isn’t the most complex service in a Win2K environment, but a mistake here can have irritating and unnecessary repercussions. Take a quick look at your timeserver and make sure the pieces are in place.