Fix SEC_E_DECRYPT_FAILURE 0x80090330 Fast

You're staring at 0x80090330 and it's killing your connection.

This SEC_E_DECRYPT_FAILURE error pops up when Kerberos can't decrypt a ticket. It usually means the system clock is off, the service principal name (SPN) is misconfigured, or the Kerberos ticket is corrupt. Let's fix it.

The Real Fix: Clock Sync First

I've seen this more times than I can count. A client last month called me because their SQL Server just stopped accepting connections from one department. Every app threw this 0x80090330 error. Turned out the domain controller's time was 8 minutes off after a power outage. Kerberos has a default tolerance of 5 minutes. Anything beyond that breaks decryption.

Check the system clock on both the client and the server. Run this in Command Prompt as admin:

w32tm /query /status

Look at the Source line — should say a domain controller, not Local CMOS Clock. Then check the offset:

w32tm /stripchart /computer:yourDCname /samples:3 /dataonly

If the offset is more than 5 minutes, force a resync:

w32tm /resync /nowait

Verify time zone on both ends. Had a client once where the server was set to UTC but the client was Eastern — instant decryption failure.
Restart the Kerberos Key Distribution Center service on the domain controller (if you have access). Run:

net stop kdc && net start kdc

SPN Mismatch – The Sneaky Cause

If the clock is fine, the next suspect is a duplicate or missing SPN. This happens a lot when you move a service account or rename a server. For example, if you have SQL Server running under a service account and the SPN for SQL Server (MSSQLSvc/hostname:port) is registered on the wrong account, Kerberos can't decrypt the ticket.

Check SPNs with:

setspn -Q MSSQLSvc/yourserver:1433

If you see duplicate entries, pick one account and delete the duplicates:

setspn -D MSSQLSvc/yourserver:1433 wrongaccount

Then add it to the correct account if missing:

setspn -A MSSQLSvc/yourserver:1433 domain\correctaccount

Corrupt Kerberos Ticket – Quick Cleanup

Sometimes the ticket itself is corrupted. This is rare but happens if you're using cached credentials or an old ticket from a different domain context. Clear the ticket cache on the client:

klist purge

Then request a new ticket:

klist get krbtgt/YOURDOMAIN.COM

If that fails, reboot the client. It forces a fresh authentication.

Less Common Variations

I've run into a few edge cases:

NTLM fallback blocked: Some security policies disable NTLM entirely. If Kerberos fails, the app might try NTLM and get blocked. Check Group Policy under Network Security: Restrict NTLM. Add the server FQDN to the exceptions.
DNS hostname mismatch: If the client resolves the server to a short name (e.g., SRV01) but the SPN expects the FQDN (srv01.domain.com), the ticket won't match. Use FQDN in connection strings.
Network time protocol (NTP) firewall block: Port 123 UDP must be open between client and domain controller. If not, time sync fails silently.

Prevention Going Forward

Set up a scheduled task to sync time every hour on all servers:

schtasks /create /tn "TimeSync" /tr "w32tm /resync /nowait" /sc hourly /st 00:00

Also, monitor SPN duplicates with a PowerShell script that runs weekly and emails you if setspn -X finds conflicts. That'll catch most issues before they cause downtime.

And for the love of all that is holy, make sure your DCs have reliable time sources — either hardware time sources or reliable external NTP pools. Kerberos is unforgiving.