Security

Get IT Done: Keep perfect time to avoid Active Directory failure

Troubleshoot synchronization problems in Active Directory


Timing is everything, and when it comes to Active Directory, that age-old cliché is especially true. Accurate time synchronization is absolutely necessary for Active Directory to work properly. Therefore, if you’re having Active Directory problems, you need to consider whether an out-of-sync server could be to blame. In this Daily Feature, I’ll show you how time affects the Active Directory and how to keep perfect time on your network.

Addressing the time sync issue
All of the servers that are involved in the Active Directory must have their clocks set within five minutes of each other. For example, if Server A is displaying a time of 9:00 A.M., then Server B’s clock must fall somewhere between 8:55 A.M. and 9:05 A.M. Now, suppose that Server A’s clock was set to 9:00 A.M. and Server B’s clock was set to 9:05 A.M. You might assume that Server C’s clock could be set to 9:10 A.M. because that time would fall within five minutes of the time on Server B. That incorrect assumption could lead to trouble. Remember that all servers’ clocks need to be set to within five minutes of each other, which means that Server C must meet the same time constraints as Server B.

The reason that mismatched times can cause such chaos has to do with the way Windows 2000 machines communicate with each other. As you probably know, Windows 2000 uses Kerberos 5 as its default authentication protocol. Any time that a Kerberos client authenticates with a server, the client will attempt to prove its identity by presenting a Kerberos ticket to the server.

This authentication process sounds almost too simple—and that’s exactly the problem with it. A hacker who’s monitoring the network could intercept a Kerberos ticket and then use a replay attack to gain access to unauthorized resources. A replay attack involves sending a copy of the ticket to the server at a later time. To prevent the possibility of a replay attack, Kerberos 5 tickets include a time stamp.

Therefore, if a hacker were to replay a ticket and the ticket’s time stamp was expired, then the server would know that the ticket was invalid.

Of course, there’s always the possibility that a hacker could find a way to monkey around with the ticket’s time stamp. Fortunately, Windows 2000 takes precautions against that as well. Suppose that a server receives a legitimate packet from a client. If the server receives another packet from that client with a time stamp that’s the same or earlier, the packet is assumed to be fraudulent.

It’s easy to see how a client who’s clock has been set incorrectly could have trouble authenticating, but what does all of this have to do with Active Directory problems? A lot, actually. In Windows 2000, it isn’t just the users who must authenticate into a domain; each computer has a computer account and password that’s associated with it as well. Any time that a computer comes online, it must authenticate into the domain.

Now, suppose for a moment that a domain controller has been taken offline and is brought back online. If the clock falls outside of the acceptable time skew, the computer won’t be allowed to participate in the domain. Likewise, if a domain controller is online, but the clock drifts outside of the acceptable time skew of five minutes, then any Kerberos tickets that the server might generate will be assumed by the other domain controllers to be invalid.

Maintaining proper protocol
Now that I’ve established the importance of accurate time, it’s time to look at what Windows does to help your servers maintain an accurate clock setting. Windows 2000 attempts to keep server clocks synchronized through the use of the Simple Network Time Protocol. I use the word “attempts” because, of course, there is no such thing as perfectly synced clocks. This being the case, the protocol designates a particular server as having an accurate clock. The other servers communicate with the time server and adjust their time to reflect the time server’s time.

The Simple Network Time Protocol allows every server in the entire enterprise to have its clocks synced within about 20 seconds of each other. The Simple Network Time Protocol provides greater accuracy for servers that exist within a common site. These servers are synchronized within two seconds of each other.

Fixing a time server problem
If you look at your servers and discover that you’ve got a time skew of more than five minutes, you’ll obviously need to fix the problem. However, there are several questions that you’ll need to answer before attempting the fix. These are:
  • Which server should the time be synchronized to?
  • How do you reset the time?
  • Why did the servers fall out of sync in the first place?

Which server should the computer be synchronized to?
At first, the question of which server you should synchronize a computer to may seem like a nonissue. After all, the synchronization process is supposed to be automatic, right? You should be able to simply look at the time on your other servers. Since they are all supposed to be in sync, it should be a fairly safe assumption that if the clocks on a few servers match each other, then that is the time you should set on the problem server. That’s a good option in theory, but it doesn’t take into account that you could have multiple servers out of sync.

So how do you figure out which time is the right time? The trick is to figure out which server Windows is using as its point of reference. Unfortunately, Windows doesn’t allow you to simply look up the name of the time server that it’s using. Instead, Windows uses an algorithm to calculate the preferred time server. The algorithm looks at criteria such as a server’s place within the Active Directory and whether it thinks that the server is a reliable time source. Below, I’ve listed the eight criteria that Windows looks at when deciding which time server to use.

These criteria are arranged in order of preference. A server that meets the criteria at the top of the list is more likely to be chosen than a server at the bottom of the list, although there are situations in which Windows may deviate slightly from this order:
  1. A reliable parent domain controller within the local site
  2. A reliable local domain controller within the site
  3. An unreliable parent domain controller within the site
  4. An unreliable local PDC emulator within the site
  5. A reliable parent domain controller from a different site
  6. A reliable local domain controller from a different site
  7. An unreliable parent domain controller from another site
  8. An unreliable local PDC emulator from a different site

How do you reset the time?
Once you’ve figured out which domain controller Windows is most likely to use as a time reference, you’ll need to reset the malfunctioning machine’s clock. You may at first be inclined to reset the clock by double-clicking on the clock and specifying the date and time. While you probably will have to use this technique initially to get the machines to begin talking again, resetting the clock from the desktop is only half of the process.

Typing in the new time will set the time to about the same as it is on the original time server, but it won’t synchronize the two machines. However, because the time is used so heavily in the authentication process, a computer must go through an authentication process before it can request a time sync. Therefore, you must manually adjust the time in order for the Active Directory to be able to process the authentication that’s necessary for a true time sync.

To actually synchronize the servers, open a command prompt window and enter the following command (from the machine that’s out of sync):
NET TIME /DOMAIN:domain name /SET

Why did the servers fall out of sync?
There are many reasons why time could fall out of sync. The most common problems are communications failures, a time service failure, or a server that has been set to look at a different time source. To make sure that the time doesn’t fall out of sync again, check your time server and the server that’s having the problem to make sure that the Windows time service is running and is set to run automatically. (This service is also sometimes referred to as the W32Time service.) To do this, click Start | Programs | Administrative Tools | Services. Scroll through the list of services until you see the Windows time service. Check the Status column to make sure it shows Started. If not, select Start from the Action menu to start it.

Once you’ve verified the service’s functionality, you should reset which time source the ailing machine looks at by entering the following command:
NET TIME /SETSNTP

This command clears any time source that may have been manually specified and then uses the algorithm that I mentioned above to recalculate the time server. You can also manually specify a time server for the system to use by entering this command:
NET TIME /SETSNTP:servername

Conclusion
The clock is an essential component for Active Directory functionality and for network security. Without proper time, Active Directory fails to work. Fortunately, with the Windows time service and the net time command, you can quickly get your servers synchronized again.

Editor's Picks