Fix SEC_I_NO_LSA_CONTEXT 0x00090323 – Quick & Advanced Fixes

What’s This Error Really About?

You get SEC_I_NO_LSA_CONTEXT (0x00090323) when Windows tries to authenticate something—like a print job, a network share, or a remote desktop session—and the LSA (Local Security Authority) subsystem isn’t talking back. I’ve seen this most often on domain-joined machines running Windows 10 or Server 2016/2019, usually after a Windows Update or a botched security patch.

Had a client last month whose entire accounting department couldn’t print to the shared printer. Every job threw this error. The LSA process had silently crashed after a cumulative update. The fix? A simple restart of the service. But sometimes it’s deeper—Kerberos tickets go stale or security DLLs get corrupted.

Let’s walk through the fixes, starting with the one that works 80% of the time.

The 30-Second Fix: Restart the LSA Process

Don’t overthink this. Open an admin Command Prompt (Win+X, then “Command Prompt (Admin)”) and run:

net stop lsass && net start lsass

Wait—that won’t work. Windows protects the LSA process (lsass.exe). You can’t stop it like a normal service. Instead, just reboot the machine. Yes, a simple restart clears the LSA context cache and resets the security subsystem. I know it sounds too basic, but I’ve seen this fix the error immediately after a restart.

If you can’t reboot right now (say, on a production server), skip to the next fix.

The 5-Minute Fix: Clear Kerberos Tickets & Re-register Security DLLs

Stale Kerberos tickets are the #2 cause of this error. Open an admin Command Prompt and run:

klist purge

This removes all cached Kerberos tickets. Then force a refresh by running:

klist get krbtgt

If that doesn’t clear it, re-register the core security DLLs. Still in the admin prompt, run:

regsvr32 /s secur32.dll
regsvr32 /s schannel.dll
regsvr32 /s crypt32.dll

Each command should return success. I’ve seen corrupted copies of secur32.dll cause this exact error after a patch Tuesday gone wrong. Re-registering them rebuilds the registration in the registry.

After that, test your authentication. If the error persists, move to the advanced fix.

The 15+ Minute Fix: Repair LSA Database & Check Event Logs

This one’s for when the LSA database itself is hosed. Open Event Viewer (eventvwr.msc) and check under Windows Logs > System. Look for Event ID 6038 or 6039—those point to LSA corruption. Also check Applications and Services Logs > Microsoft > Windows > LSA.

If you see Event ID 6038 with a message like “LSA database is corrupt,” you’ll need to rebuild it. Here’s the painful but proven path:

1. Boot into Safe Mode with Networking (press F8 during startup, or use msconfig).
2. Open an admin Command Prompt and run sfc /scannow. Let it finish—it repairs system files.
3. Then run DISM /Online /Cleanup-Image /RestoreHealth. This fixes the component store.
4. Reboot normally.

If that still doesn’t work, you’re looking at a deeper issue with the machine’s trust relationship with the domain. On a domain-joined PC, run:

Reset-ComputerMachinePassword -Server "YourDomainController" -Credential (Get-Credential)

This resets the machine account password in the LSA database. You’ll need domain admin credentials. I’ve done this on Server 2019 boxes that lost their trust after a domain controller migration—fixed the authentication error cold.

Last resort: unjoin from the domain, reboot, rejoin. It’s nuclear, but it rebuilds the LSA context from scratch.

When to Call This Fixed

After each step, test the operation that originally failed. For print jobs, send a test page. For network shares, map a drive. If the error is gone, you’re done. Don’t waste time on extra steps—the 30-second fix works more than you’d think.

One more thing: if you’re on a domain controller itself, be careful. Restarting lsass on a DC can cause replication issues. Stick to the Re-register DLLs fix first, and only reboot during a maintenance window.