Fixing Windows Time Sync: Clock Wrong, Can't Log In

Windows Time Sync Fix — automation

date	Nov 29, 2024
status	RESOLVED
time to resolution	under 15 minutes

Incident

Law firm paralegal locked out of everything Monday morning after 2-week vacation. Windows displayed "The trust relationship between this workstation and the primary domain has failed." Domain rejoin failed. Password reset failed. Clock in the corner showed March 14, 2019 - six years in the past.

What We Found

system clock	March 14, 2019 08:47 AM
actual date	September 2, 2025
time drift	6+ years (2,363 days)
Kerberos tolerance	5 minutes maximum
root cause	CMOS battery dead (7 year old laptop)

Dead CMOS battery meant system clock reset to BIOS default every time laptop lost power. Two weeks unplugged = clock reverted to 2019. Kerberos won't authenticate with more than 5 minutes of time skew.

Initial Diagnostics

RMM access still worked (doesn't rely on domain auth). Checked time service:

w32tm /query /status

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Last Successful Sync Time: unspecified
Source: Free-running System Clock

"Free-running System Clock" and "Last Successful Sync Time: unspecified" - Windows Time service had never successfully synced since boot. Trying to sync from DC, but couldn't authenticate to request time because... the time was wrong. Classic chicken-and-egg.

Why Their Attempts Failed

rejoin domain	"network path not found" (can't auth)
reset AD account	didn't help, still can't authenticate
w32tm /resync	"no time data was available"
restart W32Time	service started but still can't sync

Problem: domain-joined machines sync from DC. To talk to DC, need valid Kerberos tickets. To get tickets, time needs to be within 5 minutes. If 6 years off, completely locked out.

Solution

Bypass domain-based time sync and force machine to get time from external NTP servers directly. Deployed via RMM:

Why This Works

NTP servers don't require authentication

pool.ntp.org will tell anyone the time

bypasses Kerberos chicken-and-egg problem

unregister/register w32time	clears corrupted state
service triggers	ensures sync on network connect
/force flag	ignores rate limiting

Outcome

time to resolution	under 15 minutes
time correction	6 years, 171 days
domain rejoin	not required (trust never broken)

Script executed, time synced from pool.ntp.org within 3 seconds. Clock jumped to current date. User logged in immediately with normal credentials.

ordered CMOS battery replacement (CR2032)

added laptop to hardware refresh list

script added to onboarding for machines from storage

time is security infrastructure (Kerberos, certs, MFA all depend on it)

external NTP bypasses domain auth - breaks chicken-and-egg

check clock first - "trust relationship failed" is often time problem

CMOS batteries die - 5+ year old laptops at risk

Get Help

Mysterious authentication failures? We diagnose weird infrastructure problems that waste hours - time sync, Kerberos, certificates. We've seen it all.