Fix SEC_E_TIME_SKEW 0x80090324 Clock Skew Error

What triggers SEC_E_TIME_SKEW (0X80090324)

You're joining a domain, accessing a file share, or authenticating to a web app using Integrated Windows Authentication. The connection drops with a nasty LOGON_FAILURE 0x80090324. Event Viewer shows a Kerberos error with ID 6 or 7. The culprit here is almost always the system clock on the client or server being off by more than 5 minutes. I've seen this after a CMOS battery dies, a VM resumes from suspend with a frozen clock, or a device that's been disconnected from the network for a week.

Root cause: Kerberos hates time travel

Kerberos uses timestamps to prevent replay attacks. It stamps each ticket request with the client's current time. The server compares that to its own clock. If they're more than 5 minutes apart (default tolerance), the server rejects the request. Microsoft set that limit to 5 minutes because it's a reasonable balance between security and flexibility. Push it further and you're begging for replay attacks. The fix is either resync the time or, if you can't, widen the skew tolerance via Group Policy.

The fix: step by step

Check the time difference — Run this on the client and the server you're authenticating to:
```
w32tm /query /status | findstr "Source"
w32tm /query /status | findstr "RootDelay"
```
Compare the output clocks. If they're off by more than 5 minutes, proceed.
Resync the client immediately — On the client, run as admin:
```
w32tm /resync /force
```
If it fails, the client may not have an NTP source configured. Check with:
```
w32tm /query /configuration | findstr "NtpServer"
```
If it's blank, set it manually to a reliable NTP server like pool.ntp.org or your domain controller:
```
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync /force
```
Check the server's time too — Don't assume the server is correct. I've seen domain controllers drift. On the server, run the same resync. If it's a domain controller, make sure it's syncing from an external NTP source, not itself.
Verify the fix — After resync, try the authentication again. If it works, you're done. If not, check the time on both sides again — sometimes a bad sync leaves you still off by seconds.
If you can't resync the client (e.g., locked-down kiosk) — You can widen the Kerberos skew tolerance via Group Policy. Go to:
```
Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy
"Maximum tolerance for computer clock synchronization"
```
Default is 5 minutes. Bump it to 10 or 15. That's a security trade-off, so document it.

What to check if it still fails

Time zone mismatch — Kerberos uses UTC internally, but a wrong time zone can throw off display times. Still, double-check both boxes are on the same time zone and DST settings. Run tzutil /g on both.
Firewall blocking NTP — UDP port 123 needs to be open between client and NTP source. Check your firewall rules.
VMware or Hyper-V time sync — Virtual machines often fight with the host for time control. Disable time synchronization from the hypervisor integration services. The VM should sync via NTP, not the host.
Hardware clock battery — I've fixed this by replacing a dead CMOS battery on a 5-year-old workstation. The clock resets to 2005 on every boot.
Group Policy overriding manual config — If the machine is domain-joined, GPO may enforce an NTP source. Run gpresult /h gp.html and check the "Windows Time Service" policy. The GPO might point to a dead NTP server.
Last resort: reboot both machines — Yes, it's cliché, but I've seen a hung time service that only clears on reboot. Do it after all other checks.

If you've done all that and the error persists, you're looking at something deeper — possibly a corrupt Kerberos ticket cache. Run klist purge on the client and retry. Still stuck? Check Event Logs for Event ID 3 or Event ID 27 under System with source KDC or Kerberos. That'll point to the real problem.