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

LIMEHAWK - Managed IT

Home>Incident Reports>Fixing Windows Time Sync: Clock Wrong, Can't Log In

Time to resolution

under 15 minutes

Incident

Monday morning, law firm. Paralegal back from a two-week vacation tries to log in and gets "The trust relationship between this workstation and the primary domain has failed." Their internal IT had already tried rejoining the domain (failed), resetting her AD computer account (no change), and resetting her password (also no change). By the time it landed with us, she'd been locked out most of the morning.

The clock in the bottom-right corner of Windows read March 14, 2019, 08:47 AM. Actual date was September 2, 2025. That's the whole story — everything after this is just untangling what six years of time drift does to a domain-joined machine.

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, per default domain policy
- root cause: dead CMOS battery on a 7-year-old laptop

The laptop had been powered off and unplugged the entire vacation. With a dead CMOS battery, every power loss resets the RTC to its BIOS default — which, on this particular Lenovo, is March 2019. Plug in, boot up, and Windows sees itself as six years in the past. Kerberos will not authenticate outside a 5-minute window. Six years is outside that window.

Initial diagnostics

Our RMM agent still worked — it doesn't rely on domain auth, so the broken time didn't break our channel into the box. First thing we checked was the time service:

w32tm /query /status

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

"Free-running System Clock" and "Last Successful Sync Time: unspecified" are the flags. The Windows Time service had never successfully synced since boot. It was trying to pull time from the DC, but it couldn't Kerberos-authenticate to make the request, because... the time was wrong. Classic chicken-and-egg.

Why their attempts failed

Every standard fix assumes the domain trust is the problem. None of them work when the real problem is time:

- rejoin domain: "network path not found" — the machine can't even authenticate to find the DC
- reset AD computer account: no effect, the machine still can't present a valid ticket
- w32tm /resync: "the computer did not resync because no time data was available"
- restart W32Time: service comes back up but can't sync from a source it can't authenticate to

Domain-joined machines sync time from the DC. To talk to the DC you need a Kerberos ticket. To get a ticket, time has to be within 5 minutes. If your clock is off by six years, you are completely locked out of the domain and out of every domain-mediated fix for the domain lockout.

Resolution

Break the loop by taking the DC out of the time-sync picture entirely. Point the machine at external NTP, force the sync, and let everything else catch up once the clock is right. We deployed this script via RMM:

Why this works

- NTP servers don't require authentication — pool.ntp.org will tell anyone what time it is
- that bypasses Kerberos, which bypasses the chicken-and-egg entirely
- unregister/register w32time clears any corrupted service state from years of failed sync attempts
- service triggers (start/networkon) make sure the laptop re-syncs whenever it gets a network, which is the pattern you want on a mobile device
- /force ignores the rate limiter — when you're six years off, that's not your concern

Outcome

Script ran, time synced from pool.ntp.org in about 3 seconds. Clock jumped from March 2019 to September 2025. She logged in on the next try with her normal credentials — cached creds worked because the trust relationship was never actually broken, the machine just couldn't authenticate to prove it.

- time to resolution: under 15 minutes from escalation
- time correction: 6 years, 171 days
- domain rejoin: not required
- user productivity lost: about 2 hours

Follow-up actions:

- ordered CMOS battery replacement (CR2032, ~$3)
- added the laptop to the hardware refresh list — it's 7 years old, this isn't the last thing going wrong
- added the script to our onboarding checklist for machines coming out of storage, since they tend to hit the same failure

Key takeaways

Takeaway

time is security infrastructure — Kerberos, certificates, and MFA all depend on accurate time.

Takeaway

external NTP is how you escape domain auth when domain auth is what's broken.

Takeaway

"trust relationship failed" is often not actually a trust problem — check the clock first before you rejoin anything.

Takeaway

dead CMOS batteries are routine on 5+ year old laptops; if a machine loses time whenever it's unplugged, it's a $3 part, not a software problem.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)