In Active Directory, the Kerberos authentication protocol relies on accurate time synchronization between computers in a forest. For this reason, maintaining accurate and reliable time services in a Windows Server 2003 forest is of utmost importance.
When a client accesses a resource on a server on the network, or two domain controllers are authenticating for replication, the two computers' reference clocks must be within a predefined time skew or the action will fail. In Active Directory, this time skew is defined in Group Policy and, by default, it is five minutes.
As noted in my article on Windows time services, each computer has a reference clock that operates independent of the time zone adjustment. The Network Time Protocol (NTP) is responsible for synchronizing all the reference clocks in the domain. This permits the clocks to be accurately synchronized to keep them within the five-minute time skew. It is important to note also that there is a hierarchy to define time services in the domain. The PDC is the authoritative time server in the domain, so all DCs will sync time with the PDC, and servers and workstations will use their authenticating DC to sync their time.
Possible errors, failures and troubleshooting tips
Time sync events produce an event log entry with W23time as the source. These events are fairly rare and will mostly be warnings produced when the authoritative time server can't be contacted. This is usually a non-issue, since the server may be down or unavailable due to network issues, and another time server will be found.
The following are three events showing a gradual progression of the time sync problem from an informational event that the time server can't be reached, to a warning that this has been going on for a while, to an error.
By the time you get to the error event, you will see serious problems in authentication. For...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
example, a user trying to log on to a computer in the domain will be denied, but a very descriptive error will be displayed saying that the time is out of sync.
If DCs are out of sync, you will see events in the Directory Services event log with an "Access Denied" description, or a Repadmin /showrepl will show "Access Denied" on the out of sync DCs.
The W32tm.exe tool
Of course, searching events for time sync errors and trying to compare the time differences can be very tedious. You may also wonder if there is an easier way of forcing synchronization than by changing the system time in the UI on each machine or with the Net Time command. Fortunately, the W32tm.exe command line tool will do all of this quite easily.
The /Monitor option
The W32tm/Monitor /domain: will provide a list of all DCs in the domain and the offset in seconds from the PDC. Note the two examples here. The first shows a healthy scenario, while the second shows a several hour offset on one DC.
Note that the NTP: label shows the offset in seconds. Here WTEC-DC2 is only a fraction of a second off of the PDC, WTEC-DC1. In the output below from the /monitor command, you can see that WTEC-DC2 has an offset of 81,207 seconds, more than 22 hours. Admittedly, I forced it, but you can see how this can be a great way to see the time sync between DCs.
The next challenge is to force a computer to synchronize its time once you see event ID 38, 36, 24 and the error, Event ID 29. Again, using W32tm.exe, there are two significant options that can help you:
W32tm/resync
This command will force a local computer to re-sync its clock immediately, disregarding previous errors. The description isn't very thorough -- just remember that this is the first step and will usually fix the problem for a client. You can execute this command remotely.
W32tm/config/syncfromFlags:domHier
If the /resync command doesn't work, try this one. It forces the computer to find its authoritative time server using the domain hierarchy (as I described in the beginning of this article). Even if the client's normal authoritative time server is unavailable, this will force it to find a new DC.
Be aware of the time skew
Of course there are many other options for the W32tm command, but these are the ones I find work well when fixing time sync problems.
Time skew settings and Group Policy
Finally, there is one last thing I'd like to mention. Though this isn't particularly related to time sync as I have described it here, it does define the time skew that provides the boundaries for the time sync. This is a Group Policy setting located at Computer Configuration → Windows Settings → Account Policies → Kerberos Policy → Maximum tolerance for computer clock synchronization, and it is five minutes by default. On one occasion, we found a number of authentication errors in the domain -- a couple of DCs were logging Access Denied errors, and a number of users were unable to logon, getting an obvious time sync error at logon.
After investigating this, I discovered that this time skew setting in Group Policy was defined as "0." Of course, with a zero-second time skew, you have to be pretty close!
In the first output for the monitor command shown in this article, you can see that most of the DCs were below one second, so perhaps there is a round off that allows a small offset to be read as zero. Otherwise, I couldn't see how anything would authenticate in the domain. Basically, someone had to have set this. While it is pretty unusual, it is possible, so don't forget to check that value.
Time synchronization isn't a frequent problem, but when computers get out of sync, authentication fails and breaks a lot of things. Be aware of these tips, and you'll have a much easier time fixing these problems when they occur.
Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at glo11749@yahoo.com. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.
