SSPI Error 0x00003620: Fix SQL Server Auth Failure

You're connecting to SQL Server from a .NET app or SSMS and it throws SSPI (0x00003620) or "The target principal name is incorrect. Cannot generate SSPI context." It usually happens right after someone swaps the SQL service account, renames the server, or moves the database to a new VM without re-registering the SPN. The client can reach the server on port 1433 — ping works, telnet works — but the Windows authentication handshake dies before a login is even attempted.

What's actually happening here

SSPI (Security Support Provider Interface) is the Windows API that sits under Kerberos and NTLM. When your client asks SQL Server to authenticate with integrated security, SSPI tries Kerberos first. Kerberos needs a Service Principal Name (SPN) that matches the host the client thinks it's talking to. If MSSQLSvc/sql01.corp.local:1433 isn't registered on the correct service account, or it's registered on the wrong one, the domain controller can't issue a ticket. SSPI falls back to NTLM — and if NTLM is disabled by policy, or the fallback also fails, you get 0x00003620.

The reason this is so confusing is the error message points at the client. It's almost never the client. It's the SPN-to-account mapping on the DC, or the SQL service account itself.

Common trigger: someone ran sp_dropserver/sp_addserver during a migration, or changed the SQL service account from LocalSystem to a domain user without running setspn. NTLM kept it working for weeks until someone rebooted the DC.

Fix it

Confirm it's actually a Kerberos problem. Enable Kerberos event logging on the client and server, then reproduce. On the client, check the System event log for KRB5 errors (Event ID 4, "The kerberos client received a KRB_AP_ERR_MODIFIED error"). That tells you the SPN is registered to the wrong account.
```
# On client and SQL server
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v LogLevel /t REG_DWORD /d 1 /f
# Reboot, reproduce the error, then check Event Viewer
```
Find the SQL service account. On the SQL Server, open services.msc and check the Log On As for "SQL Server (MSSQLSERVER)" or the named instance. If it's a domain account, note the full UPN. If it's a virtual account (NT SERVICE\MSSQLSERVER), that's fine too — Microsoft's docs cover the SPN requirements for each.
List the current SPNs. Run this against the SQL server's hostname and any aliases (CNAMEs, clustered names, AG listener names — every name clients connect with).
```
setspn -L sql01
setspn -L corp\svc_sql
setspn -Q MSSQLSvc/*
```
The -Q query is the important one. It shows every MSSQLSvc SPN in the forest and which account owns each. Look for a duplicate — the same SPN registered on two accounts causes KRB_AP_ERR_MODIFIED and then 0x00003620.

Delete duplicates, then register the correct SPN. If you found a duplicate, remove it from the wrong account first. Otherwise setspn will keep complaining about a conflict.

# Remove the incorrect registration (replace with real values)
setspn -D MSSQLSvc/sql01.corp.local:1433 CORP\old_svc_account

# Add the SPN on the account SQL is actually running as
setspn -A MSSQLSvc/sql01.corp.local:1433 CORP\svc_sql
setspn -A MSSQLSvc/sql01.corp.local CORP\svc_sql

# If clients connect via a CNAME or AG listener, register that too
setspn -A MSSQLSvc/sqlprod.corp.local:1433 CORP\svc_sql

Register both the FQDN form and the NetBIOS form. Kerberos is picky: MSSQLSvc/sql01 and MSSQLSvc/sql01.corp.local are different SPNs.

Purge the ticket cache. The client has cached old tickets. On the client machine:
```
klist purge
```
Then reconnect. If it works, you're done. Don't skip this — I've seen people fix the SPN and still chase the error for an hour because the client kept reusing a stale ticket.
Check for unconstrained delegation issues. If your app server connects impersonating a user (double-hop), the SQL service account needs to be trusted for delegation in AD Users and Computers, or constrained delegation configured for MSSQLSvc/sql01.corp.local:1433. Without it, the second-hop Kerberos request fails and SSPI throws the same 0x00003620.
Verify with a Kerberos test. From the client, force Kerberos and see if you can get a service ticket for the SPN.
```
# Linux client
kinit user@CORP.LOCAL
kvno MSSQLSvc/sql01.corp.local:1433

# Windows client
klist get MSSQLSvc/sql01.corp.local:1433
```
If kvno returns a ticket without an error, Kerberos is healthy. If it fails with "Server not found in Kerberos database," the SPN still isn't registered correctly.

If it still fails

Check NTLM policy. Some hardened environments block outbound NTLM via Group Policy (Network security: Restrict NTLM). If Kerberos is broken and NTLM is blocked, you get 0x00003620 with no fallback. Run gpresult /h report.html on the client and look for NTLM audit/deny settings.
Check the time. Kerberos rejects tickets with more than 5 minutes of clock skew. Run w32tm /stripchart /computer:dc01.corp.local from both client and server. Virtual machines that were paused or snapshot-reverted drift badly.
Check DNS. If the client resolves sql01.corp.local to an IP that doesn't match the SQL server's real name (a load balancer, an old A record, a stale CNAME), SPN matching fails. nslookup sql01.corp.local and confirm it points where you think.
Check the SQL error log. The SQL Server log records the actual SSPI reason — often "the target principal name is incorrect" or "There are currently no logon servers available to service the logon request." That last one means the SQL service account can't reach a DC, which is a different fix entirely.
Test with SQL auth. If a SQL login works and Windows auth doesn't, you've confirmed the network is fine and it's purely authentication. That narrows it to SPNs, delegation, or NTLM policy — not firewalls or port issues.

The honest truth: 9 out of 10 of these come down to a missing or duplicate SPN. If you've checked SPNs, purged tickets, and confirmed DNS and time, the remaining 10 percent are delegation misconfigurations or NTLM lockdown policies. Start with setspn -Q MSSQLSvc/* and don't move on until that output looks clean.