Por que SQL Server a través dunha VPN segue a recorrer a NTLM?

A súa conexión funciona, o inicio de sesión acéptase e SQL Server usa NTLM mentres todos esperaban Kerberos. Ese resultado non é un defecto da VPN, porque un túnel só fornece unha ruta; o esquema decidiuno o nome que pediu o cliente, o principal rexistrado no directorio e o vale que o cliente puido obter realmente. Tres condicións deben cumprirse á vez, e a propia sesión di cal cedeu. Lea isto antes de que alguén edite un nome principal de servizo.

A sesión nomea o esquema que realmente obtivo

O esquema de autenticación pertence a unha conexión e non a un servidor ou un túnel, así que a comprobación debe executarse dentro da sesión que lle interesa. Execute a consulta de abaixo desde o mesmo cliente, ferramenta e conta que produciron o informe, e anote o nome de destino e o transporte xunto ao resultado.

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

Unha fila dunha ventá local de SSMS no host da base de datos describe unha conexión totalmente distinta, polo que a consulta debe executarse desde o lado do cliente. Garde a saída cunha marca de tempo, porque a seguinte persoa que a lea preguntará cando se tomou. Cando varias aplicacións comparten un extremo, tome unha mostra de cada unha, porque unha diferenza de orixe de datos entre dúas aplicacións adoita ser toda a historia.

Condición un: coincide o nome co SPN?

Kerberos autentica un servizo con nome, así que o cliente pide ao directorio un vale para un principal concreto. Para o provedor TCP, a forma documentada é MSSQLSvc/ seguida do nome de host totalmente cualificado e, para unha instancia predeterminada, o porto. Unha instancia con nome rexistra MSSQLSvc/db01.corp.example:SQLPROD, onde o sufixo é o nome da instancia en lugar dun número. Chegar ao listener mediante un alias, un CNAME que se resolve noutro lugar ou un enderezo IP espido cambia o nome solicitado, e unha solicitude sen un principal coincidente non ten vale que devolver.

Por iso unha aplicación funciona nunha rede e recorre a outra: unha resposta DNS, un rexistro de alias ou unha entrada hosts cambiaron o nome que usou o cliente. Compare o nome solicitado co que contén o directorio antes de tocar o rexistro.

Condición dous: está o SPN na conta correcta?

Un SPN debe pertencer á conta que executa o servizo SQL, non á conta do cliente nin, por accidente, a un obxecto de equipo. SQL Server pode rexistrar os seus propios SPN ao iniciarse cando a súa conta de servizo ten permiso para escribilos, o que é cómodo e tamén explica como aparece un duplicado tras un cambio de conta de servizo.

Consulte o directorio polo nome que espera e logo enumere o que a conta posúe realmente. Que obxecto contén a entrada importa máis que se o nome existe nalgún lugar do bosque. Unha discrepancia significa que o inicio de sesión nunca foi o problema, e a guía de SPN de Microsoft documenta os formatos e os casos en que un administrador de dominio debe crear a entrada.

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

Engadir outra entrada non é un experimento seguro. Un duplicado ou un rexistro en conflito pode romper clientes que funcionaban, así que inspeccione a propiedade antes do cambio e volva comprobala despois.

Condición tres: pode o cliente obter un vale sequera?

Un SPN correcto é inútil se o cliente non pode chegar a un controlador de dominio ou non ten un contexto de credenciais utilizábel. O intercambio necesita o KDC e o DNS a través da VPN, e un túnel que só encamiña o porto SQL falla xustamente neste paso. A accesibilidade debe probarse desde a mesma máquina e a mesma conta, non desde a devasa que teñen diante.

Inspeccione a caché de vales na máquina e baixo a conta que executa a aplicación. Unha lista de toda a máquina desde unha ventá elevada non di nada sobre un servizo que se executa como outro usuario, e unha caché baleira para ese usuario é un achado e non unha incomodidade.

klist
klist -li 0x3e7

Logo decida que pode facer un retroceso. Se a política esixe Kerberos, NTLM debe rexeitarse explicitamente, porque un retroceso silencioso converte un erro de configuración nunha conexión que funciona e que infrinxe o requisito. Se NTLM segue sendo aceptábel para algunhas aplicacións, nómbreas e deixe de tratar cada sesión NTLM como un incidente.

Cambiar o lanzador é unha variable, non unha solución

Iniciar SSMS con outra credencial pode curar unha identidade de saída non desexada, que é unha clase real de problema. Non demostra nada sobre o nome de destino, o rexistro ou a ruta do vale, e non cambia o que o servidor aceptou.

Manteña a comparación controlada: mesmo extremo, mesmo provedor, un contexto de execución coñecido e logo unha conexión nova cuxo esquema inspecciona. Confirme o inicio de sesión aceptado e os seus permisos de base de datos por separado, porque o acceso e a autenticación fallan por motivos distintos.

Cando Kerberos sexa obrigatorio, anote por que retrocedeu a primeira ruta, aplique unha corrección e volva executar a consulta desde o mesmo cliente. Unha consulta correcta tras cambiar o lanzador é evidencia de acceso, e aínda non é evidencia de que se cumprise o requisito de autenticación.