Why Does SQL Server Over a VPN Still Fall Back to NTLM?

Your connection works, the login is accepted, and SQL Server is using NTLM while everybody expected Kerberos. That outcome is not a VPN defect, because a tunnel only supplies a path; the scheme was decided by the name the client asked for, the principal registered in the directory and the ticket the client could actually obtain. Three conditions have to hold at once, and the session itself says which one gave way. Read that before anyone edits a service principal name.

The session names the scheme you actually got

Authentication scheme belongs to a connection rather than to a server or a tunnel, so the check has to run inside the session you care about. Execute the query below from the same client, tool and account that produced the report, and record the target name and transport beside the result.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

A row from a local SSMS window on the database host describes a different connection entirely, which is why the query has to run from the client side. Save the output with a timestamp, because the next person to read it will ask when it was taken. Where several applications share one endpoint, sample each of them, because a data-source difference between two applications is frequently the whole story.

Condition one: does the name match the SPN?

Kerberos authenticates a named service, so the client asks the directory for a ticket to one specific principal. For the TCP provider the documented form is MSSQLSvc/ followed by the fully qualified hostname and, for a default instance, the port. A named instance registers MSSQLSvc/db01.corp.example:SQLPROD, where the suffix is the instance name instead of a number. Reaching the listener through an alias, a CNAME that resolves elsewhere or a bare IP address changes the requested name, and a request with no matching principal has no ticket to return.

That is why one application works on a network and falls back on another: a DNS answer, an alias record or a hosts entry changed the name the client used. Compare the requested name with what the directory holds before touching registration.

Condition two: is the SPN on the right account?

An SPN has to belong to the account that runs the SQL service, not to the client's account and not to a computer object by accident. SQL Server can register its own SPNs at startup when its service account holds the permission to write them, which is convenient and also how a duplicate appears after a service-account change.

Query the directory for the name you expect, then list what the account actually owns. Which object holds the entry matters more than whether the name exists somewhere in the forest. A mismatch means the login was never the problem, and Microsoft's SPN guide documents the formats and the cases where a domain administrator has to create the entry.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Adding another entry is not a safe experiment. A duplicate or conflicting registration can break clients that were working, so inspect ownership before the change and recheck it afterwards.

Condition three: can the client get a ticket at all?

A correct SPN is useless if the client cannot reach a domain controller or has no usable credential context. The exchange needs the KDC and DNS through the VPN, and a tunnel that routes only the SQL port fails at precisely this step. Reachability has to be tested from the same machine and the same account, not from the firewall in front of them.

Inspect the ticket cache on the machine and under the account that runs the application. A machine-wide list from an elevated window says nothing about a service running as another user, and an empty cache for that user is a finding rather than an inconvenience.

klist
klist -li 0x3e7

Then decide what a fallback may do. If policy requires Kerberos, NTLM has to be refused explicitly, because a silent fallback turns a configuration error into a working connection that violates the requirement. If NTLM stays acceptable for some applications, name them and stop treating every NTLM session as an incident.

Changing the launcher is one variable, not a fix

Starting SSMS under another credential can cure an unintended outgoing identity, which is a real class of problem. It proves nothing about the target name, the registration or the ticket path, and it does not change what the server accepted.

Keep the comparison controlled: same endpoint, same provider, a known execution context, then a fresh connection whose scheme you inspect. Confirm the accepted login and its database permissions separately, since access and authentication fail for different reasons.

When Kerberos is required, record why the first path fell back, apply one correction and re-run the query from the same client. A successful query after a launcher change is evidence of access, and it is not yet evidence that the authentication requirement was met.