Users connecting over Always On VPN using split tunnel for user and device are unable to connect to Azure SQL Managed Instance using Windows Authentication with Kerberos protocol enabled

Question

Users connecting over Always On VPN using split tunnel for user and device are unable to connect to Azure SQL Managed Instance using Windows Authentication with Kerberos protocol enabled

Cooling, Steve 65

Users connecting remotely over Always On VPN(split tunnel for user and device) are unable to connect to our Azure SQL Managed Instance using Windows Authentication with the kerberos protocol enabled. It's working ok from on premise servers and over Direct Access. The error received is below. I think it maybe to do with the AOVPN user tunnel having a different ip address to my device ip. Any advice would be greatly appreciated thanks.

The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server, Error: 0)

0 comments

Answer accepted by question author

Amira Bedhiafi 43,046 MVP Volunteer Moderator

Hello Steve !

Thank you for posting on MS Learn Q&A.

I think the client tried Windows auth using Kerberos but could not build a valid security context and this is commonly caused by SPN or name resolution problems or Kerberos not falling back successfully.

https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/connect/cannot-generate-sspi-context-error

For Azure SQL Managed Instance with Windows auth, the client should be able to obtain a Kerberos ticket for an SPN like:

MSSQLSvc/<mi-name>.<dns-zone>.database.windows.net:1433

You can test this on an affected VPN client:

klist purge
klist get krbtgt/kerberos.microsoftonline.com
klist get MSSQLSvc/<mi-name>.<dns-zone>.database.windows.net:1433

MSSQLSvc ticket should come from the kerberos.microsoftonline.com and error 0x6fb indicates the SQL SPN was not found or the Kerberos trust flow is incomplete.

https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-troubleshoot?view=azuresql

So try to verify that the SQL MI FQDN resolves the same way over AOVPN as it does on prem or DirectAccess. split tunnel often misses the right DNS suffix, NRPT rule, private DNS zone or route.

The tunnel must allow traffic to:

SQL MI private endpoint/subnet or MI VNet endpoint
Domain Controllers/KDCs, if using the incoming trust-based flow
Microsoft Entra Kerberos endpoints

There is a known Always On VPN pattern where SQL/SSMS Kerberos fails with this exact error unless the VPN profile is configured not to reuse RAS credentials. For Windows 11 24H2+, test adding this to the VPN ProfileXML:

<UseRasCredentials>false</UseRasCredentials>

For older clients, test setting this in rasphone.pbk:

UseRasCredentials=0

This workaround is specifically reported for Always On VPN + SQL target principal name is incorrect scenarios.

https://directaccess.richardhicks.com/2025/02/13/always-on-vpn-and-sql-target-principal-name-incorrect/

Use the exact Azure SQL MI FQDN expected by Kerberos because using an IP address, short name, CNAME or different DNS alias can make the SPN mismatch.

Cooling, Steve 65 Reputation points

2026-06-09T07:41:21.3966667+00:00

Many thanks Amira, the registry entry in the link above fixed it for me.

1 additional answer

Your answer

Cooling, Steve 65 Reputation points

2026-06-09T07:41:21.3966667+00:00

Many thanks Amira, the registry entry in the link above fixed it for me.

Answer 1

Hi @Cooling, Steve

The 'Cannot generate SSPI context' / 'target principal name is incorrect' error usually indicates that cannot obtain a valid Kerberos service ticket for the SQL Managed Instance SPN.

Since authentication works from on-premises networks and through DirectAccess but fails only when connected through Always On VPN (split tunnel), I'd focus first on DNS resolution, VPN routing, and domain controller reachability.

Please verify that the SQL Managed Instance FQDN resolves to the expected private IP address while connected through the VPN. Also confirm that the VPN routes allow connectivity to your domain controllers, DNS servers, and Kerberos services.

On the affected client, you can run:

If the service ticket cannot be obtained, the issue is likely related to DNS resolution, SPN resolution, or connectivity to the KDC over the VPN.

As an additional troubleshooting step, try temporarily testing with a force-tunnel VPN profile. If Kerberos authentication succeeds in that configuration, it would indicate that a required route, DNS path, or domain controller communication is missing from the split-tunnel configuration.

Could you confirm whether all users are affected and whether domain controllers and DNS servers are reachable through the VPN tunnels? That would help narrow down the root cause."

This stays closer to documented Kerberos troubleshooting and avoids making assumptions about the specific Always On VPN settings that may or may not be involved.