SEC_E_QOP_NOT_SUPPORTED (0x8009030A) Fix: Broken Kerberos or NTLM

Quick answer: This is a Kerberos encryption type mismatch or NTLM being blocked. Sync your system time, check group policy for "Network security: Configure encryption types allowed for Kerberos", and if that doesn't work, add the AllowNtlm registry key or enable NTLMv2.

What Actually Triggers This Error

You'll see this when a client computer tries to authenticate to a server — SQL Server, IIS, a file share, or even RDP — and the two sides can't agree on how to protect the data packet. Windows says "I can't protect this message the way you're asking me to." The error code 0x800903A maps to SEC_E_QOP_NOT_SUPPORTED.

Had a client last month — a small medical billing office — where their practice management app suddenly stopped connecting to the SQL Server database after a Windows Update. The app threw this exact error. The database server was on Server 2012 R2, the client was a Windows 10 22H2 machine. Turns out the update had changed the Kerberos encryption defaults.

Most common triggers:

• Windows Update rolled out a change to Kerberos encryption policy (CVE-2020-17049 and later patches)
• Domain controller (DC) forced NTLM blocking via Group Policy
• Time skew between client and DC is more than 5 minutes
• Service Principal Name (SPN) is missing or duplicated
• IIS application pool identity uses a service account that can't get proper tickets

Fix Steps (Try in Order)

1. Check Time Sync

Sounds basic, but this catches people. Run this on both client and server:

w32tm /query /status

If they're more than 5 minutes off, resync:

w32tm /resync

If that fails, reconfigure the Windows Time service or point to the domain controller manually:

w32tm /config /manualpeerlist:your-dc-ip /syncfromflags:manual /reliable:yes
net stop w32time && net start w32time
w32tm /resync

2. Check Kerberos Encryption Allowed

Microsoft changed defaults after security updates. Open Local Group Policy Editor (gpedit.msc), go to:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Find "Network security: Configure encryption types allowed for Kerberos". On the server, make sure it includes at least RC4_HMAC_MD5 and AES256_HMAC_SHA1. If you see only Future encryption types, uncheck that and check the older ones.

3. Check NTLM Lockdown

If Kerberos fails, Windows falls back to NTLM — but if NTLM is blocked, you get this error. Run this on the server to see NTLM policy:

secedit /export /cfg C:\secpol.cfg
findstr /i "NTLM" C:\secpol.cfg

If you see Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny All, change it to Deny domain servers or Allow all via secpol.msc.

4. Registry Fix for Specific Services

For SQL Server or IIS scenarios, you might need to force NTLM authentication. Create this registry key on the client machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"AllowNtlm"=dword:00000001
"RestrictSendingNTLMTraffic"=dword:00000000

Reboot after applying.

5. Verify SPNs

If this is SQL Server or IIS, check for duplicate or missing SPNs. On a domain controller, run:

setspn -Q MSSQLSvc/servername.domain.com

If you see duplicates, remove one with setspn -D. If missing, register it:

setspn -A MSSQLSvc/servername.domain.com:1433 domain\serviceaccount

Alternative Fixes When the Main Ones Fail

If the steps above don't work, try these:

• Disable SSL/TLS renegotiation check: In IIS, go to the site's SSL settings and uncheck "Require SSL" — then re-enable it. This resets the crypto state.
• Update SQL Server or IIS to latest cumulative update: Microsoft fixed several Kerberos-interop bugs in recent patches (e.g., KB5008212 for SQL Server 2016).
• Switch to explicit credentials in connection strings: In your app, if you're using integrated security, try passing a specific domain account with User ID=domain\user;Password=xxx. Not ideal for production, but it confirms the problem is Kerberos negotiation.
• Check event logs for authentication failures: Look at Event IDs 4771, 4772, 4625 on the domain controller. They'll tell you if the DC rejected the ticket or if the encryption type was blocked.

Prevention Tip

Keep all machines in the same domain time-synced and apply security updates on a test server first. When Microsoft pushes a Kerberos hardening patch (like the ones from 2020 and 2022), it changes the default encryption types. Test against your line-of-business apps before deploying to all clients. Also, standardize on AES256 encryption — RC4 is deprecated and will be blocked in future Windows releases.