Windows Time Service : Algorithm

Keeping the Domain On Time

Ryan Sizemore — Tue, 04 Sep 2007 21:03:00 GMT

Windows Time Service on a domain (referred to as 'Domain Synchronization' or 'Domain Sync' for short) is a huge topic. I will do my best to cover all of its aspects in this article, but some concepts won't be covered until a later date, and others still relate directly to the original RFC for NTP.

Background

As I stated in my previous post, the original reasons for developing w32time stemmed from the requirements imposed by Kerberos. In order for Kerberos to function securely, the time difference between the participating machines needs to be less than five minutes. In time, other components have come to rely on w32time, including Active Directory Replication and Windows Update. In a Windows domain, w32time needs to keep machines synchronized, and it needs to do so in a quick, efficient, and quiet manner.

Beyond NTP

The NTP protocol described in the RFC goes a long way toward designing a robust time synchronization solution. But in the end, what we are really interested in is just that: the solution. Keeping time synchronized between two machines is possible, but the solution needs to be more robust to deal with computers belonging to a domain. In particular, w32time works to answer these questions (just to name a few):

How do we ensure that in a large network of computers, an efficient chain of time sources is picked?
How do we auto-configure so that an administrator has to do a minimal amount of work to set it up?
How do we keep it secure and still auto-configurable?
How do we allow administrators to get a look at what is happening?
How do we alert the administrators when something goes wrong?

These questions are important, specifically in the domain scenario (as opposed to the home user scenario), since the needs of the home user and the needs of the domain user are quite different.

Designing Inside the Box

Because many components within Windows depend on w32time to keep the clock synchronized, w32time cannot take (hardly) any dependencies itself. If w32time relied on component X to do something fancy, and component X relied on Kerberos, then we would have a problem, since Kerberos relies on w32time. This would create a circular dependency and, well, that's a bad thing.

For this reason, w32time has a simplified mechanism to authenticate time syncs. More information on the authentication mechanism will be covered in a future post.

Intelligent Design

The first issue to address is finding someone to synchronize with. Each machine needs to sync with another machine to get its time. To do this efficiently and automatically, w32time uses the domain hierarchy created with the domain itself. In the simplest frame of mind, a domain consists of the following distinct entities (aka computers):

Exactly one primary domain controller (or PDC-emulator)
Zero or more replica domain controllers (DCs)
Zero or more member computer (either server or workstations)

The inner working of what a domain is and how it operates is beyond the scope of this post, but this should be enough to provide the groundwork for our discussion.

Time Source Selection

Each member of the domain follows a different set of requirements, based on its role. Lets take a look at those roles:

Primary Domain Controller - This machine is the authoritative time source for a domain. It will have the most accurate time available in the domain, and must sync with a DC in the parent domain (except in special cases).
Replica Domain Controller - This machine will act as a time source for clients and member servers in the domain. A DC can sync with the PDC of its own domain, or a DC or PDC in the parent domain.
Clients/Member Servers - This machine can sync with any DC or PDC of its own domain, or a DC or PDC in the parent domain

These are the default rules of where a machine can go looking for a time source. Keep in mind that there are corner cases where the rules can be bent a little. A few additional rules:

A machine can only look for a time source in its own domain or the parent domain. A machine will never go to a domain on a parallel level, or a "skip-level" parent domain.
Within a domain, a machine cannot sync with its own kind. A DC cannot sync with another DC. A client cannot sync with another client.

Also, you may have noticed that a PDC can only sync from a DC or PDC in the parent domain. Well, what if you are in the parent domain already? This is a special case, which is detailed below in the section "Special Case: The Root PDC".

The time source selection mechanism works great to enumerate the possible machines to sync from. The problem is that this usually leaves more than one machine as a possible partner. We need a way to pick the "best" one of the group, and that is what scoring does for us.

Score!

Each possible machine is given a score, based on certain criteria. Once all of the candidates have a score, w32time simply chooses the machine with the highest score. Here is what the scoring looks like:

8 points if the machine is in-site
4 points if the machine is "reliable"
2 points if the machine is in the parent domain
1 point if the machine is a PDC (or PDC emulator)

So why are these points given? Let's look at the rules individually. Machines that are in the same site as the one in question have the best chance of providing us with good time.

Machines that are out of site probably are disconnected physically in one way or another, and would likely introduce delay.
A machine that is "reliable" is pre-configured to be directly connected to a reliable time source, such as a GPS or atomic clock. These devices provide very accurate, very stable time samples. If a machine is configured to sync directly with one of these devices, a registry value can be changed to indicate that this machine will be a source of reliable time.
A machine higher in the forest will be closer to the root, and hence will have more accurate time than a machine in the current domain.
A PDC (or PDC-emulator) will be more accurate than a DC in the same domain because it is guaranteed to sync with a machine in the parent domain.

From this, we can derive a score for each machine, and then choose the machine with the highest score.

Examples

When a machine boots up, it will go looking for a time source. Depending on its role, it will be required to choose from a subset of possible machines to sync with. But how do we prioritize between the available choices? Lets take a look at the following example:

Example 1:

This example utilized the graphic above. The domains will be referred to as the "Left Domain", the "Right Domain", and the "Parent Domain".

Computer foo has just been joined to the Left Domain as a regular client (not a DC), and it booting up for the first time on a domain. First, we need to enumerate which machines are possible as partners to sync with. We will look at each machine to see if it is a possible sync partner.

"Domain Controller" [Left Domain] is a DC in the same domain, so it is a valid choice
"PDC Emulator" [Left Domain] is a PDC in the same domain, so it is a valid choice
"Domain Controller" [Parent Domain] is a DC in the parent domain, so it is a valid choice
"PDC Emulator" [Parent Domain] is a PDC in the parent domain, so it is a valid choice

Which machines aren't valid? Let's take a look (and find out why)

"Workstation" [Left Domain] is not a DC, so it is not a valid choice
"Server" [Left Domain] is not a DC, so it is not a valid choice
"Workstation" [Parent Domain] is not a DC, so it is not a valid choice
"Server" [Parent Domain] is not a DC, so it is not a valid choice
Anything in the [Right Domain] is not in the same domain, and not in the parent domain, so it is not a valid choice

Ok, so we have our possible choices, but now we need to prioritize them to pick the best one. To do this, we will utilize the scoring system. Assuming that our entire forest is in one site, and we don't have any machines configured as "reliable":

"Domain Controller" [Left Domain] Score = 8
"PDC Emulator" [Left Domain] Score = 8 + 1 = 9
"Domain Controller" [Parent Domain] Score = 8 + 2 = 10
"PDC Emulator" [Parent Domain] Score = 8 + 2 + 1 = 11

So there we have it. The PDC in the parent domain will be our time source. But what if the [Left Domain] was put into a separate site?

Example 2:

Assume the same scenario as the above example, except that [Left Domain] exists in a different site from the rest of the forest. We will use the same logic applied above to determine a time source.

So the [Left Domain] is in a different site. Since the first part of time source selection does not take site location into consideration, we will get the same possible machines to sync with. However, the scoring system will provide us with a different machine when all is said and done. Lets look at how the scoring would now occur:

"Domain Controller" [Left Domain] Score = 8
"PDC Emulator" [Left Domain] Score = 8 + 1 = 9
"Domain Controller" [Parent Domain] Score = 2 = 2
"PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

Because the DC and PDC in the [Parent Domain] are in a different site, they don't get the +8 to their score. This leaves us with the PDC of the current domain, with a score of 9. But what about the PDC of the [Left Domain]?

Example 3:

Assume the same scenario as Example 2, Again, we will use the same logic applied above to determine a time source.

With the left domain in a different site from the rest of the forest, and with the PDC of the [Left Domain] being the authoritative time source for the [Left Domain], we will need to go out of site for a time source - we have no other choice. So we will look at the scores for the various eligible time sources:

"Domain Controller" [Parent Domain] Score = 2 = 2

"PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

We cannot sync with any time sources in our own domain, so we only have the time sources from the [Parent Domain]. The scoring will give us the PDC of the [Parent Domain].

Plan B: Fail over

So what happens when things don't go as planned? Windows Time Service has been built to handle fail over situations from the beginning. For a generic example, assume that a client is currently synchronizing with a time source. If the time source goes away for one reason or another, the client will need to go looking for another time source.

For this reason, we use the scoring system illustrated above. The client will reassess the available time sources, score each of them, and choose the best one. Since the previous time source (which was probably the best first choice) has gone away, w32time will pick the next highest scoring time source.

Special Case: The Root PDC

The PDC for the domain at the root of the forest (the root PDC) poses a problem. Since it has no time sources that are more authoritative than it, it cannot choose a time source automatically. Thus, the administrator will need to set one up manually, or the domain will operate in a "standalone" mode. In the case of a standalone domain, the root PDC will still be the authoritative time source, but its time will come from its own clock.

Wrap Up

We have taken a look at how w32time operates in a domain at a very high level. Future posts will dive deeper into specific areas of w32time, and this will provide a groundwork for those other articles. If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Windows Vista Applications section of the Microsoft Technet forums. One way or another, questions posted there should make their way to my inbox, and I will do my very best to answer them.

References

http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true

What is Windows Time Service?

Ryan Sizemore — Sun, 08 Jul 2007 05:40:00 GMT

Welcome to the Windows Time Service blog. This blog is here to answer some of the questions about the service and show off some of the useful features that it has. Every week, I will try to cover a new topic surrounding Windows Time Service (w32time for short). If anyone has any requests/suggestions for topics, please feel free to let me know. This blog is for you.

So what is Windows Time Service?

In short, it is a Windows service that keeps your computer clock accurate. Of course, the "how" is much more interesting than the "why", but for the sake of being the initial post, I will start with why time service exists; and for that, we require a bit of history. NOTE: Most of the information about the history of w32time comes from previous knowledge, which is not very extensive. If you find a mistake, please let me know.

In the days of Windows NT 4.0 and prior, there actually wasn't NTP support, but rather SNTP. This was an initial version of the time service that focused on basic time synchronization (I believe the service was called TimeServ). SNTP doesn't support most of the features of the full NTP protocol, which would be needed in future versions of Windows.

Windows 2000 brought about a wealth of new features, including Kerberos authentication. As part of the Kerberos protocol (section 1.6, 4th bullet of the RFC), computers using Kerberos authentication need to have clocks that are "loosely synchronized", which is defined as 5 minutes by default. To meet this need, SNTP was abandoned and w32time was born. From Windows 2003 though Vista/Windows Server 2008, w32time has been upgraded & retrofitted to support more features, differing environments, and basically meet whatever needs customers and other internal components have.

How does Windows Time Service work?

Well, without getting into some of the messy details, w32time communicates with other computers in your network to keep the time on your local computer accurate. The overreaching goal is to keep your local clock in step with a remote clock. In this way, w32time is synchronizing your computer's clock to that of your time source. (Keep in mind that most of this information can also found in the NTP v3.0 RFC, which w32time is based on). This is done by sampling the time on a remote system (known as the time source). The communication between a time client and a time source looks something like this:

The time client makes a request for a timestamp at time t1
The time source receives the request a time t2
The time source sends back a response a time t3
The time client receives the response a time t4

This is the fundamental interaction between a time client and a time source. The astute reader would first ask the following question:

Well, if the 2 computers are not currently synchronized (which is the point of this communication in the first place), then how can those time values (t1 - t4) be useful at all?

This is a great question because it demonstrates the ingenious design of NTP to be computer independent. Without making assumptions about the relationship of the time source and time client, we can make these initial observations:

(t4 - t1) is the total time that is took for the time source to send out a request and get back a response (transit time)
(t3 - t2) is the total time that the time source spent processing the request (processing time)
((t4 - t1) - (t3 - t2)) is the total transit time of the request (transit time - processing time)

Using this, we can make the following additional observation:

((t2 - t1) + (t3 - t4)) / 2 is the clock offset between the two computers

[EDIT: The above formula has been corrected. Thanks occulations]

Now that we have the clock offset, we can start to correct the clock on the local computer (the time client). Correcting the time on a computer can be done in two ways: skewing and setting. If the time difference is small enough*, we can adjust the clock gradually over time. However, if the time difference is too large* (such as hours or days), it is better to simply set the local clock to the desired time.

* The concept of "too large" or "too small" is relative. These values are adjustable in the registry so that you can control when w32time skews, sets or does nothing at all.

The relationship between w32time and local clock (yes, they are two distinct entities) is complicated and will be explained in a later post.

Time source selection

Aside from how the service determines the time difference, the next most common question is: How does w32time choose a time source (known as a peer)? The service can operate in one of two possible modes:

NTP (as defined in the original RFC)
NT5DS (using domain lookup mechanisms)

The NTP mode is straight-forward: Try to sync with the peer specified. If you can't, wait until you can. This is the mode that non-domain joined computers use. The DNS name or IP address of the peer can be changed in the registry, but it comes as 'time.windows.com' by default. Microsoft hosts its own NTP server, which is how your computer gets correct time "out of the box".

Domain joined computers utilize the NT5DS mode. This mode uses netlogon API calls to find an eligible peer to sync with. Because domains can become both large and deep, and w32time needs to operate in an optimal fashion either way, there is a complex algorithm that is used to find a peer. I will be covering this later in a seperate post (since it is such a large and involved topic), but you can find a reasonable explaination at TechNet for Windows Server 2003. Here is the quick overview:

Computers sync with DCs, preferably from their own site/domain
DC sync with local PDC, but will go out of site/domain if needed
PDCs sync with other PDC, but possible DCs higher up in the forest if needed

At the top of the forest (at the root domain), there needs to be either a local time source or a link to an external peer that provides reliable time data. Again, this really needs a long discussion to make proper sense, but in essence the domain needs to get its time data from somewhere. The w32time service is responsible for distributing the time throughout the domain, but it needs to go to another source to get the data to distribute in the first place.

Wrap Up

This should give you a brief look at the Windows Time Service and how it works. If you have topic ideas, please let me know. I'm only one man, and this isn't the Shell Blog. I have a list (and it is growing) for future topics, but if the community feels that one or more issues are more important, I will do my best to cover them first. As I said in the beginning, this blog is for you.