SOLVED: Fix Time Drift on a Corporate PC or Domain Controller

Last week we had a client with the Domain Controller that was off by more than three and a half minutes from the PDC. In case you’re not sure yes that is bad. If it gets to five minutes it can be catastrophically bad.

What Happens When DC’s Have Different Times:

New DC’s, member servers and even PC’s automatically be configured to use the “DOMHEIR” (Domain Heirchy) with shows in w32tm /query /status as Stratum: 3 (secondary reference - syncd by (S)NTP). However, it is possible for a computer to have its time sync configuration changed and become out of sync which will cause all manor of problems:

---

---

1. Kerberos Authentication Failures

• The Kerberos authentication protocol relies on time-sensitive tokens called tickets. If the time difference between a client, a DC, or another server exceeds 5 minutes (default threshold), authentication will fail, leading to:
  • Inability for users to log in.
  • Failures in accessing network resources like file shares or printers.
  • Service disruptions for applications relying on Kerberos authentication.

2. Replication Failures

• Active Directory replication between domain controllers depends on timestamps. A time mismatch can cause:
  • Delays or failures in replicating directory changes (e.g., user account creation or password updates).
  • Conflicts where newer changes might be mistakenly overwritten by older ones.

3. Group Policy Failures

• Clients and servers may fail to apply or update Group Policy settings due to authentication failures or mismatched timestamps in GPO processing.

4. Event Log Discrepancies

• System logs and event logs use timestamps for troubleshooting and auditing. A time mismatch across DCs can cause confusion in identifying the sequence of events or correlating logs, complicating incident response.

5. Third-Party Application Issues

• Applications that rely on domain services, such as SQL Server, Exchange, or other enterprise software, might encounter authentication errors or service interruptions due to time mismatches.

6. Security Vulnerabilities

• Time synchronization is vital for securing encrypted communications (e.g., SSL/TLS), certificate validation, and other security protocols. A time mismatch might result in failed certificate validation or leave systems vulnerable to certain attacks.

How to Fix Time Problems on DC’s

The first thing you need to do is ensure that the DC with the PDC emulator role, is set to sync with a reliable time service. To do this run w32tm /query /status and confirm you see the SOURCE being something reliable like time.nist.gov or us.pool.ntp.org .

If it is not, then just open a CMD prompt as an Admin and run these commands:

net stop w32time
w32tm /unregister
w32tm /register
w32tm /config /manualpeerlist:"time.nist.gov,0x8" /syncfromflags:manual /reliable:yes /update
net start w32time
w32tm /resync
w32tm /query /status

On the other DC’s check to make sure they are syncing with the PDC. To do this run w32tm /query /status and confirm you see the SOURCE being listed as your PDC. If it is not, just run these commands.

IN THE COMMANDS BELOW, CHANGE THE “CGYDC03” TO WHATEVER YOUR PDC IS

w32tm /config /manualpeerlist:CGYDC03 /syncfromflags:manual /reliable:no /update
w32tm /resync

then wait 2 or 3 minutes for the time to be corrected. Then run this command to set the your DC to use DOMHEIR (which means DOMAIN HIERARCHY) instead of the specific PDC (in our examples, CGYDC03).

w32tm /config /syncfromflags:domhier /update
w32tm /resync

---