Fix SEC_E_KDC_INVALID_REQUEST (0x80090340) Fast

You Get This Error—Here's the Real Fix

That SEC_E_KDC_INVALID_REQUEST (0x80090340) nonsense usually pops up when you try to access a network share, log into an app with Kerberos auth, or run a domain-joined service. It's not a corrupt installation or a missing file—it's almost always a ticket or time problem. Let's kill it.

Step 1: Flush Kerberos Tickets

Open an admin command prompt and run:

klist purge

This wipes all cached Kerberos tickets. Then force a fresh one by locking your workstation (Windows+L) and logging back in. If you're working remotely over VPN, also run:

ipconfig /flushdns

Had a client last month whose entire print queue died because of a stale ticket—flush fixed it in 10 seconds.

Step 2: Sync System Time

Kerberos won't tolerate a clock drift bigger than 5 minutes by default. Check your system time against your domain controller. Run this to force a sync:

w32tm /resync /nowait

If that fails, stop and restart the time service:

net stop w32time && net start w32time

Then resync again. I've seen misconfigured BIOS clocks cause this error on freshly imaged machines—time sync always fixed it.

Step 3: Reset Kerberos Service Account Password

This is for when the error appears on service accounts (like SQL Server, IIS app pools). The computer account's password might be out of sync with the domain. Run this on the affected machine as admin:

netdom resetpwd /s:yourDC /ud:domain\admin /pd:*

Replace yourDC with your domain controller's name. You'll be prompted for the admin password. This forces a password reset on the machine account. Did this for a client's file server that couldn't authenticate to the domain after a restore—worked like a charm.

Why This Error Happens

The KDC (Key Distribution Center) on your domain controller receives a Kerberos request that doesn't make sense. Common triggers:

Stale tickets from a previous session, especially after computer sleep/hibernate.
Clock mismatch between client and DC—Kerberos is paranoid about time.
Corrupted computer account in AD—happens after domain re-joins or restores.
DNS issues where the client can't resolve the DC's FQDN properly. Check with nslookup yourdomain.local.

Less Common Variations

Variation 1: SPN Mismatch

If you're hitting this error on a specific app (like SQL Server, Exchange), the service principal name might be wrong. Check with:

setspn -L computername

Then verify against what the app expects. If missing, add it: setspn -A MSSQLSvc/server.domain.local domain\user

Variation 2: Domain Controller Clock Drift

Sometimes the DC itself has a bad clock. Check all DCs' time against an external source with:

w32tm /query /status

If the DC is off, reconfigure its NTP source. This is rare but nasty when it happens.

Variation 3: Firewall or Proxy Intercepting Kerberos Traffic

Some corporate firewalls or proxy servers mess with Kerberos packets, especially on ports 88 (UDP/TCP). Turn off any proxy in Windows settings temporarily to test. If it works, the proxy is the culprit—add the DC to the bypass list.

Prevention for Next Time

Set automatic time sync via Group Policy: Computer Configuration > Administrative Templates > System > Windows Time Service. Use time.windows.com or your DC's NTP.
Keep DNS healthy—test forward and reverse lookups for your domain controllers regularly.
After domain-joining a machine, always restart it once to secure fresh tickets.
For service accounts, schedule a monthly script to run klist purge on the service host—prevents ticket rot.

If you still get the error after all this, check the Domain Controller's event log (System and Security) for event IDs 4768 or 4769. They'll point you to the exact reason the KDC rejected the request. Most of the time though, it's just a stale ticket or a clock problem—flush and sync, and you're done.