Tip

When authentication fails: Troubleshooting Windows time services

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

Requires Free Membership to View

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.

Note: Remember that all of this works out of the box. You do not have to configure time services. You don't have to define time servers, set policy or turn anything on or off. Leave it alone and it will work.

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.

4/25/2007   12:28:09 PM W32Time   Error None
      29 N/A WTEC-DC2 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.

4/25/2007   12:28:09 PM W32Time   Warning None
      24 N/A WTEC-DC2 Time Provider NtpClient: No valid response has been received from domain controller WTEC-DC1.Wtec.adapps.hp.com after 8 attempts to contact it. This domain controller will be discarded as a time source and NtpClient will attempt to discover a new domain controller from which to synchronize.

4/24/2007   12:22:48 AM W32Time   Warning None
      36 N/A WTEC-DC2 The time service has not synchronized the system time for 86400 seconds because none of the time service providers provided a usable time stamp. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. Monitor the system events displayed in the Event Viewer to make sure that a more serious problem does not exist.

4/22/2007   12:11:37 PM W32Time   Information None
      38 N/A WTEC-DC2 The time provider NtpClient cannot reach or is currently receiving invalid time data from WTEC-DC1.Wtec.adapps.hp.com (ntp.d|16.56.172.105:123->16.113.26.95:123).

By the time you get to the error event, you will see serious problems in authentication. For 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.

WTEC-DC1.Wtec.adapps.hp.com *** PDC ***
[16.113.26.95]:    ICMP: 169ms delay.
   NTP: +0.0000000s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: 'LOCL' [76.79.67.76]
WTEC-DC2.Wtec.adapps.hp.com [16.56.172.105]:
   ICMP: 0ms delay.
   NTP: -0.0001403s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]
WTEC-DC3.Wtec.adapps.hp.com [15.31.56.61]:
   ICMP: 216ms delay.
   NTP: +0.0028781s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]
wtec-dc4.Wtec.adapps.hp.com [16.144.206.141]:
   ICMP: 373ms delay.
   NTP: +0.0015754s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]

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.

WTEC-DC1.Wtec.adapps.hp.com *** PDC ***
[16.113.26.95]:
   ICMP: 181ms delay.
   NTP: +0.0000000s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: 'LOCL' [76.79.67.76]
WTEC-DC2.Wtec.adapps.hp.com [16.56.172.105]:
   ICMP: 0ms delay.
 NTP: -81207.5536511s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]
WTEC-DC3.Wtec.adapps.hp.com [15.31.56.61]:
   ICMP: 218ms delay.
   NTP: -0.0133719s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]
wtec-dc4.Wtec.adapps.hp.com [16.144.206.141]:
   ICMP: 410ms delay.
 NTP: -0.0117120s offset from WTEC-
DC1.Wtec.adapps.hp.com
     RefID: WTEC-DC1.Wtec.adapps.hp.com
[16.113.26.95]

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.

You can follow SearchWindowsServer.com on Twitter @WindowsTT.

ABOUT THE AUTHOR
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 Directory Services and formerly for Windows File Systems.

This was first published in May 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.