SQL Server Kerberos Falls Back to NTLM Due to Duplicate SPN After Server Rename or Migration
Following a SQL Server migration where the new server was renamed to match the old one, Kerberos authentication silently falls back to NTLM because a conflicting MSSQLSvc SPN remains registered under the old domain service account. The duplicate SPN causes Active Directory to be unable to uniquely resolve the Kerberos principal, forcing NTLM. Removing the stale SPN from the old account and allowing AD replication to propagate restores Kerberos authentication.
Indicators
- sys.dm_exec_connections returns auth_scheme = 'NTLM' instead of 'KERBEROS' for TCP connections
- SetSPN -Q MSSQLSvc/* reveals the same SPN registered under more than one domain account
- SQL Server error log reports SPN registration success yet Kerberos authentication still fails
- Linked Server queries or delegation scenarios fail or behave unexpectedly due to NTLM double-hop limitations
- Issue onset correlates with a server rename, SQL Server upgrade, or service account change
- Predecessor SQL Server instance (e.g. SQL 2005) authenticated via Kerberos successfully under the same network conditions
Likely causes
- Duplicate MSSQLSvc SPN registered under both an old and a new domain account following a server rename or migration, preventing AD from uniquely resolving the Kerberos principal
- Single domain service account previously shared across multiple SQL Server instances, leaving stale SPNs on the old account when a new account was introduced
- SPN not cleaned up from the old domain account when the SQL Server service account was changed during migration
- Active Directory replication delay causing stale SPN data to persist on one or more domain controllers after a partial cleanup
Diagnostic steps
-
Confirm the authentication scheme in use by running the following query on the affected SQL Server instance: SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID; — a result of 'NTLM' over TCP confirms Kerberos is not being used.
-
Enumerate all MSSQLSvc SPNs registered in the domain to detect duplicates: SetSPN -Q MSSQLSvc/* — look for the same SPN value appearing under more than one account.
-
List SPNs registered under both the old and new service accounts individually to identify which account holds the conflicting entry: SetSPN -L DOMAIN\OldAccount and SetSPN -L DOMAIN\NewAccount
-
Cross-reference the output of SetSPN -L with SetSPN -Q MSSQLSvc/Machine.domain.inet:1433 to confirm exactly which account holds the duplicate SPN that should have been removed.
-
Review the SQL Server error log for SPN-related entries (search for 'Service Principal Name') to confirm whether SQL Server itself attempted and reported successful SPN registration, which would indicate the conflict is on the AD side rather than in SQL Server configuration.
-
Remove the conflicting SPN from the old domain account for both the named and port-specific SPN formats: SetSPN -D MSSQLSvc/Machine.domain.inet DOMAIN\OldAccount and SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\OldAccount
-
Wait approximately 30 minutes for Active Directory replication to propagate the SPN deletion across all domain controllers, then re-run the auth_scheme query from step 1 to confirm auth_scheme now returns 'KERBEROS'.
Resolution path
- Run SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID on the affected instance to confirm NTLM fallback over TCP.
- Run SetSPN -Q MSSQLSvc/* to enumerate all MSSQLSvc SPNs domain-wide and identify any duplicate entries.
- Run SetSPN -L DOMAIN\OldAccount and SetSPN -L DOMAIN\NewAccount to determine which account holds the conflicting SPN.
- Delete the conflicting bare-hostname SPN from the old account: SetSPN -D MSSQLSvc/Machine.domain.inet DOMAIN\OldAccount
- Delete the conflicting port-specific SPN from the old account: SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\OldAccount
- Re-run SetSPN -Q MSSQLSvc/* to confirm no duplicate entries remain.
- Allow up to 30 minutes for Active Directory replication to propagate the SPN deletion to all domain controllers.
- Re-run the auth_scheme query and confirm the result is now 'KERBEROS' to verify resolution.
Prevention
- Assign a dedicated, unique domain service account per SQL Server instance; never share a single account across multiple SQL Server servers.
- Before renaming a server or changing a service account, audit all existing SPNs with SetSPN -Q MSSQLSvc/* and SetSPN -L DOMAIN\Account, and remove any SPNs that will become stale.
- Document all SPNs registered at initial deployment so conflicts can be rapidly identified during future migrations or upgrades.
- After any server rename, service account change, or SQL Server migration, explicitly verify SPN state with SetSPN -Q and SetSPN -L before declaring the environment production-ready.
- When troubleshooting SPN-related Kerberos failures, account for AD replication latency; wait at least 30 minutes after making SPN changes before concluding that a fix has not taken effect.
- Consider using Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) for SQL Server services, as these automatically manage SPN registration and reduce manual SPN lifecycle errors.
Tools
- SetSPN.exe (SetSPN -Q to query all SPNs, SetSPN -L to list by account, SetSPN -D to delete a specific SPN)
- sys.dm_exec_connections DMV (SQL Server) — confirms active authentication scheme per session
- Active Directory Users and Computers — review and edit service account attributes
- SQL Server Error Log — identifies SPN registration attempts and conflicts