Clocks Skewed

I found an entry in the application event log on the Windows XP system stating "Windows cannot find the machine account, The clocks on the client and server machines are skewed."

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1097
Date: 4/17/2005
Time: 5:03:33 PM
User: NT AUTHORITY\SYSTEM
Computer: THELMALOU
Description:

Windows cannot find the machine account, The clocks on the client and server machines are skewed.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There was an entry following that stating "Windows cannot query for the list of Group Policy objects."

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 4/17/2005
Time: 5:03:33 PM
User: NT AUTHORITY\SYSTEM
Computer: THELMALOU
Description:

Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Looking through the application log, I see that these two errors have been occurring periodically with the second one always following the first one. Checking the clocks on the client Windows XP system and the server Windows SBS 2003 server, I see that the time on the server is 6 minutes ahead of the time on the client.

On the Windows SBS 2003 server, which is the domain controller, I see the entries similar to the following occurring periodically, referencing not just the one XP system, but sometimes another as well.

Event Type:     Error
Event Source:   Kerberos
Event Category: None
Event ID:       5
Date:           4/17/2005
Time:           5:38:14 PM
User:           N/A
Computer:       ANDY
Description:

The kerberos client received a KRB_AP_ERR_TKT_NYV error from the server THELMALOU$. This indicates that the ticket used against that server is not yet valid (in relationship to that server time). Contact your system administrator to make sure the client and server times are in sync, and that the KDC in realm MAYBERRY.LAN is in sync with the KDC in the client realm.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I also see the following entry occurring periodically in the XP system's application log.

Event Type:     Error
Event Source:   AutoEnrollment
Event Category: None
Event ID:       15
Date:           4/15/2005
Time:           7:24:46 AM
User:           N/A
Computer:       THELMALOU
Description:

Automatic certificate enrollment for local system failed to contact the active directory (0x8007054b). The specified domain either does not exist or could not be contacted.
   Enrollment will not be performed.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Clicking on the link in the last entry takes one to a Microsoft webpage with the following information:

Explanation

Autoenrollment starts every time Group Policy is updated or when a user logs on to Windows. Each time autoenrollment starts, it tries to contact the Active Directory directory service. This event, Autoenrollment 15, is logged when autoenrollment fails to contact Active Directory. If the computer cannot contact Active Directory, for example when a laptop computer is not connected to the corporate network, this event appears in the Event Viewer. This is expected and normal.

User Action

If the computer does not currently have connectivity to Active Directory, then no user action is required. If the event is repeatedly generated after the computer has established a connection to Active Directory, verify that the computer can receive Group Policy updates by using the Gpupdate.exe command-line utility. For more information about the Gpupdate.exe command-line utility, see Help and Support.

Related Knowledge Base articles

You can find additional information on this topic in the following Microsoft Knowledge Base articles:

• Problems occur when the Autoenrollment feature cannot reach an Active Directory domain controller

Explains why you may receive "Error 15" error messages that are related to the Autoenrollment feature, and provides a workaround.

The Knowledge Base article Problems occur when the Autoenrollment feature cannot reach an Active Directory domain controller suggests that the problem may be a DNS problem, if this error occurs on systems that are part of a Windows 2000 or later domain. This Windows XP system is part of a domain with a Windows SBS 2003 controller and the DNS server listed on the XP system is the domain controller. The nslookup command shows that the system can get the correct IP addresses for itself and the domain controller, so that doesn't appear to be the source of the problem.

I tried to resynchronize the system's time with that of the domain controller by running the command w32tm /resync rediscover, but that didn't work.

C:\Documents and Settings\Administrator>w32tm /resync /rediscover
Sending resync command to local computer...
The computer did not resync because no time data was available.

Nor was the net time command successful on either the Windows XP workstation or Windows SBS 2003 server when I tried it.

C:\Documents and Settings\Administrator>net time
Could not locate a time-server.

More help is available by typing NET HELPMSG 3912.

And net time /querysntp produced the same results on both systems.

C:\Documents and Settings\Administrator>net time /querysntp
The current SNTP value is: time.windows.com,0x1

The command completed successfully.

When I checked the services running on the SBS 2003 server (Start, Administrative Tools, Services), I found the Windows Time service disabled.

The description for the service stated "Maintains date and time synchronization on all clients and servers in the network. If this service is stopped, date and time synchronization will be unavailable. If this service is disabled, any services that explicitly depend on it will fail to start.

I changed the startup type from "disabled" to "automatic" and clicked on Apply. I then clicked on the Start button and then OK and the service started successfully. After starting the time service on the domain controller, I was able to successfully run the w32tm /resync /rediscover command on the Windows XP system.

C:\Documents and Settings\Administrator>w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

The time on the Windows XP system then changed to match the time on the domain controller, except it was off exactly one hour. The timezone was set correctly to Eastern time on the Windows XP system, so I suspected the timezone was incorrectly set on the domain controller. When I checked the time on the domain controller by using the w32tm /tz command on that system, I saw it was set to Central time, even though both systems are in the Eastern timezone.

C:\Documents and Settings\Administrator>w32tm /tz
Time zone: Current:TIME_ZONE_ID_DAYLIGHT Bias: 360min (UTC=LocalTime+Bias)
  [Standard Name:"Central Standard Time" Bias:0min Date:(M:10 D:5 DoW:0)]
  [Daylight Name:"Central Daylight Time" Bias:-60min Date:(M:4 D:1 DoW:0)]

I reset the timezone on the domain controller to Eastern time by double-clicking on the time in the lower right-hand corner of the screen and then clicking on the timezone tab.

When I then reset the time on the Windows XP system with w32tm /resync /rediscover, it immediately adjusted to the correct time.

The reason it is important for the clocks on each system in a domain to have times that are very close to one another is that Windows relys on the Kerberos network authentication protocol for securing communications between clients and servers. The Kerberos protocol was created by MIT as a mechanism to ensure the security of communications between systems. The Kerberos protocol allows a client to prove its identity to a server and vice versa over an insecure network connection. After the systems have authenticated one another, they can also encrypt the transmissions between them for privacy and to ensure data integrity.

As part of the Kerberos exchange between systems, a client and server will exchange encryted "tickets" with one another. Time stamp information is included in the tickets to prevent someone from fraudulently attempting to reuse a previous ticket. In order for the exchange to work reliably, clients and servers must thus have system times that don't differ by more than a small amount. According to the article, Configuring the Windows Time Service by Mitch Tulloch, the clocks of all Windows 2000, XP, or 2003 systems in a forest should agree within 20 seconds of one another or within 2 seconds for a particular site.

References:

1. ITT: The clocks on the client and server machines are skewed (solved)
   Robert's Blog
   March 16, 2005
2. Configuring the Windows Time Service
   By Mitch Tulloch
   November 18, 2004
3. How to configure an authoritative time server in Windows XP
   Microsoft Corporation
   November 5, 2004
4. Dealing with W32 Time errors in SBS2003
   KWSUPPORT - SBS MVP Blog for Kevin Weilbacher
   October 29, 2004
5. Registry entries for the W32Time service
   Microsoft Corporation
   March 10, 2005
6. time sync
   WinDrivers Computer Tech Support Forums
   June 29, 2004
7. How to configure an authoritative time server in Windows Server 2003
   Microsoft Corporation
   November 10, 2004
8. Keeping Time with Win2K
   Microsoft Corporation
   2002
9. Problems occur when the Autoenrollment feature cannot reach an Active Directory domain controller
   Microsoft Corporation
   May 26, 2004
10. Kerberos: The Network Authentication Protocol
    Massachusetts Institute of Technology
11. An Overview of a Kerberos Infrastructure
    Linux.com - The Enterprise Linux Resource