After a SQL Server move, test the actual remote connection’s authentication scheme, then compare its requested SPN with the current service account. Kerberos is attempted first; if a token cannot be obtained, Windows can use NTLM S1. A successful login can therefore conceal a broken Kerberos path, particularly where delegation is required.
This guide uses domain-joined Windows and SQL Server 2022 with a remote TCP connection as its reference. It is source-researched and untested. No directory object, SPN, service identity or authentication policy was changed. The diagnostic SQL example requires approved access and should be rehearsed in a lab.
Draw the connection the application actually makes
Record the client machine, application process, executing Windows identity, configured server name, instance or port, database and driver. Distinguish a direct desktop-to-SQL connection from a browser-to-web-application-to-SQL path.
In the second case, identify which identity the application is intended to use for its database connection. It may use its own service identity rather than pass through the browser user. Do not begin a delegation configuration merely because the architecture contains multiple machines. Establish the intended identity contract first.
Record the old and new SQL service accounts and the actual listening endpoint. An application alias may have remained unchanged while the host, port or service account changed underneath it. That is exactly why a successful DNS lookup is insufficient evidence about Kerberos identity.
Preserve the error and time from the failing client. Compare with the SQL startup/error log and relevant Windows authentication evidence. Avoid collecting complete connection strings or tickets in a general report; they can expose sensitive identity and infrastructure information.
Separate reachability from authentication
Confirm the name resolves to the intended server from the affected client, and that the intended SQL listener is reachable through the approved network path. Use the organisation’s established diagnostic tooling. These checks narrow routing, firewall and listener failures; they do not establish a valid Kerberos exchange.
Then identify whether the failed attempt reached SQL Server at all. A timeout, an SSPI-related authentication error and a database-permission denial describe different boundaries. Repeatedly remapping a database user cannot repair a client that never reaches the service or obtains the wrong service identity.
Check the domain relationship. Microsoft’s SPN guidance requires client and server computers to belong to the same domain or trusted domains for its Kerberos scenario. Record any identity dependency deliberately unavailable in the recovery environment rather than silently connecting an isolated recovery copy to production to make the test pass.
Time synchronisation and domain availability are supporting requirements to investigate through their own runbooks. This article does not change time policy, repair domain controllers or prescribe broad firewall openings. See the related clock-drift article for time evidence; domain repair needs its own supported procedure.
Measure the authentication used by a successful connection
An authorised diagnostic session can inspect its own connection with the following query, documented by Microsoft S1. Run it from a representative remote client using the intended name and transport. It has not been executed for this article.
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
On SQL Server 2022 and later, the DMV reference specifies VIEW SERVER PERFORMANCE STATE for this view. Arrange approved diagnostic access; do not permanently broaden an application account’s rights merely to obtain the result. If the authorised test identity differs from the application identity, state that limitation.
auth_scheme describes the observed connection. A result from an administrator’s separate session does not prove how the application connected. If the application cannot execute the diagnostic itself, have the DBA correlate the actual application connection using approved monitoring and its connection identifiers.
Likewise, a local connection is not a substitute for the remote test. Microsoft’s authentication-defaults table distinguishes local and remote behaviour S1. A local NTLM result cannot by itself establish that a correctly configured remote Kerberos path is broken.
If the required design is Kerberos but the observed remote connection uses NTLM, record that explicitly. A successful login under another mechanism does not demonstrate that the intended Kerberos configuration has been restored.
Read the directory registration before proposing a change
Use the preceding auth_scheme result as the first authentication decision: Kerberos observed, NTLM observed, or no connection to inspect. Microsoft also links Kerberos Configuration Manager for SQL Server as a diagnostic tool S1; confirm its supported release before use.
These untested Windows setspn queries list and search registrations without modifying them R1. Use an authorised directory account with read access and replace the example account, domain and endpoint. -L lists one account; -Q searches for the exact SPN; -X checks duplicates across the named domain and can require a broader directory scan.
setspn -L EXAMPLE\sqlsvc
setspn -T example.test -Q MSSQLSvc/sql01.example.test:1433
setspn -T example.test -X
Compare the returned owner with the Database Engine service identity. No result is inconclusive if access or domain scope is wrong. Forest searches require the directory owner's agreed scope; these examples do not establish cross-forest uniqueness. Preserve the output privately.
Registration failures can appear in both the Windows Application event log and SQL Server error log. Microsoft names Validated write to service principal name, with the documented servicePrincipalName read/write rights, for the directory owner to assess S1. Virtual accounts and managed service accounts can register their own SPNs; record any account-type change during migration rather than assuming the old registration arrangement still applies.
Match the requested SPN to the real service
Microsoft documents the provider-generated TCP form as MSSQLSvc/<FQDN>:<port>. The name, protocol and port matter. For this reference path, do not substitute an instance-name form taken from a different protocol’s example S1.
Have the directory administrator inspect the SPN required by the actual client connection and identify the account on which it is registered. Compare that account with the Database Engine’s current Windows service identity. Record the result privately.
An alias deserves explicit attention. The connection name used by the client can differ from the server’s physical hostname. Review the supported driver’s SPN construction and any explicitly configured SPN rather than assuming that an entry for the physical host also covers every alias.
Do not add every conceivable name to every service account. Define the exact supported endpoint and intended owner, and check existing registrations before any write. An incorrect registration can direct authentication to the wrong identity and affect other clients.
Availability-group listeners and clustered configurations need their specific supported SPN design. Microsoft links those as related configurations S1. This single-service diagnostic does not supply a universal listener repair recipe.
Check registration rather than assuming service startup proves it
SQL Server attempts SPN registration at service startup. Microsoft states that registration failure is logged while startup continues S1. A running Database Engine therefore does not establish that the directory registration succeeded.
Review the relevant startup interval and determine whether automatic registration was attempted and rejected. Compare the current service identity and its intended directory rights. A migration may have changed the account without updating the registration design.
The remedy may be a narrowly scoped directory-permission correction or a deliberate manual registration performed by the directory owner. Microsoft discourages using a domain administrator account to register SPNs in production S1. Do not broaden the SQL service account’s privileges to solve registration.
This guide withholds setspn mutation commands. Registration, deletion and movement of an SPN are directory changes that need exact ownership, duplicate/related-registration review, affected-client assessment and a reversal plan. A public example containing a placeholder hostname cannot establish those prerequisites.
Preserve the prior registration state. If an old server still serves other clients, removing its entry without reconciling those dependencies can create a second outage. The migration plan must decide when each endpoint and service identity stops being authoritative.
Verify the corrected path without broad resets
After the approved directory or service change, create a fresh test connection through the actual remote application path. Do not rely on a pooled connection that was established before the change. Have the application owner use a supported reconnect or controlled service lifecycle within the agreed change window.
Confirm the observed authentication scheme and destination. Then verify the application’s expected database operation under the intended identity. Correct Kerberos authentication does not grant the required database permissions automatically; the restored-login article covers that separate boundary.
Test each supported connection name and relevant client type. If only one alias was corrected, do not claim all clients are fixed. Record failures and differences in driver, identity, transport or endpoint as separate findings.
Avoid broad ticket purges, service restarts or domain-policy changes across the estate to make one test succeed. Such actions can disrupt unrelated sessions and erase useful evidence. Any required cache/session refresh should be targeted and documented.
Close with an identity map
Retain a compact record linking application endpoint, transport, SQL listener, service identity and registered SPN owner. Include the pre-change evidence, approved correction, remote authentication observation and application acceptance result.
If the path still fails, preserve the exact remaining error and identify which boundary is unresolved. A directory registration problem, a domain trust problem and a SQL authorisation problem require different owners and evidence. Do not combine them under a vague “Windows authentication issue”.
The result should be a demonstrated connection under the required identity and authentication mechanism. No such result is claimed here; these are checks for the authorised operator’s rehearsal and change process.
Limitations
SQL Server 2022, Windows domains and remote TCP are the reference scope. Directory read visibility, trust boundaries, aliases and driver behaviour constrain the result. No SPN write, ticket purge or delegation repair is supplied.
Acceptance checklist
- Actual application endpoint, service identity and transport recorded.
- Remote authentication scheme observed under the representative identity.
- SPN owner, duplicate search scope and both startup logs checked.
- Approved correction followed by a fresh application connection and operation.
Learning notes
- A working TCP connection does not prove the requested service identity is correct.
- SQL service startup can succeed even when SPN registration fails.
- Authentication evidence belongs to the actual connection being tested.
Related reading: The Database Restored, but the Application Cannot Log In; DNS Changed but Users Still Reach the Old Application; Clock Drift in VMware-Hosted Windows: Trace the Source.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Register a Service Principal Name for Kerberos Connections - SQL Server | Microsoft Learn
- sys.dm_exec_connections (Transact-SQL) - SQL Server | Microsoft Learn
Additional revision sources: