Fix SEC_E_UNSUPPORTED_PREAUTH (0x80090343) Kerberos Error

What's Actually Happening Here

You're seeing SEC_E_UNSUPPORTED_PREAUTH (0x80090343) when trying to authenticate to a domain resource — a network drive, remote desktop, or Outlook connecting to Exchange. The Kerberos package is saying: "I got a pre-authentication request, but I can't handle it."

Kerberos pre-authentication is the first handshake step. Your client sends a timestamp encrypted with your password hash. If the domain controller can't decrypt it — because your system clock is off, or the encryption algorithm doesn't match — you get this error.

This happens a lot after Windows updates that disable old encryption types (like RC4). Or when a laptop sits in sleep mode for days and its clock drifts.

Fix #1: Sync System Time — 30 seconds

Kerberos is brutally strict about time. It allows a 5-minute difference by default. But I've seen it fail with just 30 seconds of drift. Why? The encrypted timestamp is supposed to be within the skew window. If it's not, the DC rejects it.

1. Press Win + R, type cmd, hit Enter.
2. Run: w32tm /resync
3. If you see "The computer did not resync because no time data was available", force it: w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org" then w32tm /resync again.

Check your time zone while you're at it. Right-click the clock, select "Adjust date/time". Make sure "Set time zone automatically" is off and the correct zone is selected.

Test: Try connecting again. If it works, you're done. If not, move on.

Fix #2: Flush Kerberos Tickets and Re-authenticate — 2 minutes

Stale tickets can hold bad settings. This clears them.

1. Open Command Prompt as Administrator.
2. Run: klist purge — this deletes all cached Kerberos tickets.
3. Force a new ticket: klist get krbtgt/YOURDOMAIN.COM (replace YOURDOMAIN.COM with your actual domain in uppercase).
4. If that fails, the problem isn't tickets. Go to Fix #3.

When this works, the klist get command returns a new ticket without error. You don't even need to reboot — just try the action that failed before.

Fix #3: Check Kerberos Encryption Types — 5 minutes

The most common real cause. Windows 10 version 2004 and later, plus Windows Server 2022, disable RC4 by default. Old domain controllers or apps might still need it. The error shows up because the client offers only AES, but the server expects RC4 (or vice versa).

Here's what to check:

1. Open Group Policy Editor (gpedit.msc).
2. Go to: Computer Configuration > Administrative Templates > System > Kerberos.
3. Find "Encryption types" setting. It's called "Set encryption types for Kerberos".
4. Enable it, then check these boxes: RC4_HMAC_MD5, AES128_HMAC_SHA1, AES256_HMAC_SHA1.
5. Click OK, close GP Editor.
6. Run gpupdate /force in CMD.

Why this works: By enabling all three, both sides can negotiate the strongest shared encryption. If your domain controller still runs on Windows Server 2012 R2 or earlier, it might not support AES256. Enabling RC4 covers that gap.

If you're on a domain-joined machine and can't modify local policy (because domain policy overrides it), talk to your domain admin. They need to check the domain controller's encryption configuration.

Fix #4: Domain Controller Side — Advanced, 15+ minutes

This is for the people who hit the error on multiple machines, or after a DC upgrade. The problem is likely on the server side.

Check Domain Controller Encryption:

1. Remote into your domain controller.
2. Open Active Directory Users and Computers.
3. Find the user account that's failing.
4. Right-click → Properties → Account tab.
5. Look at Account options. Check if "This account supports Kerberos AES 256 bit encryption" is unchecked. If the user was created on an old DC, it might be disabled.
6. Enable it for AES256, or disable it if your clients don't support it. Match what you set in Fix #3.

Registry Fix on DC (if needed):

Some domains have a registry key that restricts encryption. On the DC, open regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Look for SupportedEncryptionTypes (DWORD). If it's missing, the DC allows all types. If it exists, its value controls what's allowed. Common values:

• 0x7FFFFFFF — allow everything
• 0x8 — AES256 only
• 0x4 — AES128 only
• 0x2 — RC4 only

Set it to 0x7FFFFFFF (hex) temporarily, reboot the DC, and test. If the error goes away, narrow it down from there.

When to Give Up and Use NTLM Fallback

Sometimes you just need access now. You can force the client to fall back to NTLM instead of Kerberos. It's less secure, but works when Kerberos is broken.

In Group Policy (same place as encryption types), enable "Kerberos client supports NTLM fallback". This tells Windows: "If Kerberos says unsupported pre-auth, try NTLM."

Don't leave this on forever. Use it as a temporary bridge while you fix the root cause.

Summary of the Real Fix

9 out of 10 times, it's time sync or encryption type mismatch. Fix #1 then Fix #3. If you run a mixed environment with old and new Windows versions, pre-enable all encryption types on both client and server before you see this error.

The error message is opaque, but the fix chain is straightforward. Start fast, go deep only if you must.