The SQL Server Was Up. Kerberos Was Pointing at the Wrong Account.

Users could not connect to a SQL Server instance with Windows Authentication. SSMS returned:

Cannot generate SSPI context

The first useful split came from changing only how the endpoint was addressed. Connection by hostname failed. Connection by IP address worked.

If the same SQL Server listener is reachable by IP, the problem is unlikely to be a simple “server is down” or “port is blocked” failure. The hostname path introduces name resolution and, for Windows integrated authentication, Kerberos service identity.

1. 01 HOSTNAME + WINDOWS AUTH

   Fails with "Cannot generate SSPI context".

   ↓

2. 02 IP + SAME SQL SERVER OBSERVED

   Connects successfully.

That contrast does not prove every Kerberos problem by itself, but in this incident it was the strongest clue: the server and network path were available, and the identity path tied to the service name was not.

What Kerberos needs§

For SQL Server integrated authentication, the client requests a service ticket for an SPN representing the SQL Server endpoint. A simplified SPN looks like:

MSSQLSvc/sql-fci-01.example.internal:<port>

That SPN must be registered to the Active Directory account under which the SQL Server service is actually running.

The useful evidence step was to query the directory for the exact SQL Server SPN:

setspn -Q MSSQLSvc/sql-fci-01.example.internal:<port>

Sanitised result:

Registered ServicePrincipalNames for
<DOMAIN>\<wrong-account>

The SQL Server service itself was running as:

<DOMAIN>\<sql-service-account>

Those two observations established the mismatch: Active Directory associated the SQL service name with one account, while the SQL Server service actually ran under another.

Root cause§

The failure was an SPN ownership mismatch. The SQL Server listener itself was healthy. The service account was known. But Active Directory said the SQL service name belonged to another account.

Correcting the SPN§

The fix was to remove the SPN from the wrong account and register it on the SQL Server service account. Sanitised example:

setspn -D MSSQLSvc/sql-fci-01.example.internal:<port> <DOMAIN>\<wrong-account>

setspn -S MSSQLSvc/sql-fci-01.example.internal:<port> <DOMAIN>\<sql-service-account>

setspn -S MSSQLSvc/sql-fci-01:<port> <DOMAIN>\<sql-service-account>

-S is useful when adding an SPN because it checks for duplicate SPNs before registration. The production service names, domain, port and accounts are intentionally not reproduced here.

The fix was not instantaneous§

After the directory change, two lifecycles still mattered. First, the SPN change needed to replicate through Active Directory. Second, the client could still hold Kerberos tickets from before the correction.

On the client, the Kerberos ticket cache was purged with:

klist purge

After directory replication completed and the client obtained a fresh ticket, Windows Authentication through the hostname succeeded.

Why the IP test was so useful§

The IP connection did not “fix” Kerberos. It changed the authentication path enough to show that the database listener and basic network connectivity were not the failing layer. An IP-based connection does not use the same hostname-based SQL Server SPN resolution path and may use a different authentication mechanism.

That moved the investigation from SQL Server? firewall? port? cluster? toward service name → SPN → service account → Kerberos ticket.

Production debugging gets much faster when one test changes exactly one meaningful layer.

A practical troubleshooting model§

When I see Cannot generate SSPI context, I avoid treating it as a generic SQL Server error. I think in layers:

1. Can the endpoint be reached?
2. Does behaviour change between IP and hostname?
3. Which service identity should the hostname resolve to?
4. Which account owns that SPN?
5. Which account is SQL Server actually using?
6. Has directory replication completed?
7. Is the client still using an old Kerberos ticket?

In this incident, the SPN owner and service-account identity contained the fault.

Why clusters make this easier to misconfigure§

A Failover Cluster Instance gives clients a stable network identity while the SQL Server service can move between physical nodes. That is exactly what Kerberos should support — service identity belongs to the clustered SQL endpoint, not to the transient node the instance happens to be running on.

It also means an SPN copied from an old service account or previous configuration can survive long after topology changes. The hostname can still resolve. The port can still answer. Only integrated authentication fails.

Takeaway§

The SQL Server was not unavailable. The network was not unavailable. Kerberos had been told that the SQL service name belonged to the wrong identity.

The most useful piece of evidence was the contrast between IP working and hostname failing — one comparison that crossed the boundary from connectivity into service identity and made the actual failure domain visible.