¿Por qué SQL Server a través de una VPN sigue recurriendo a NTLM?

Su conexión funciona, el inicio de sesión se acepta y SQL Server usa NTLM mientras todos esperaban Kerberos. Ese resultado no es un defecto de la VPN, porque un túnel solo proporciona una ruta; el esquema lo decidieron el nombre que pidió el cliente, el principal registrado en el directorio y el vale que el cliente pudo obtener realmente. Tres condiciones deben cumplirse a la vez, y la propia sesión dice cuál cedió. Léalo antes de que alguien edite un nombre principal de servicio.

La sesión nombra el esquema que realmente obtuvo

El esquema de autenticación pertenece a una conexión y no a un servidor o un túnel, así que la comprobación debe ejecutarse dentro de la sesión que le interesa. Ejecute la consulta de abajo desde el mismo cliente, herramienta y cuenta que produjeron el informe, y anote el nombre de destino y el transporte junto al resultado.

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

Una fila de una ventana local de SSMS en el host de la base de datos describe una conexión completamente distinta, por lo que la consulta debe ejecutarse desde el lado del cliente. Guarde la salida con una marca de tiempo, porque la siguiente persona que la lea preguntará cuándo se tomó. Cuando varias aplicaciones comparten un extremo, tome una muestra de cada una, porque una diferencia de origen de datos entre dos aplicaciones suele ser toda la historia.

Condición uno: ¿coincide el nombre con el SPN?

Kerberos autentica un servicio con nombre, así que el cliente pide al directorio un vale para un principal concreto. Para el proveedor TCP, la forma documentada es MSSQLSvc/ seguida del nombre de host totalmente cualificado y, para una instancia predeterminada, el puerto. Una instancia con nombre registra MSSQLSvc/db01.corp.example:SQLPROD, donde el sufijo es el nombre de la instancia en lugar de un número. Llegar al agente de escucha mediante un alias, un CNAME que se resuelve en otro lugar o una dirección IP desnuda cambia el nombre solicitado, y una solicitud sin un principal coincidente no tiene vale que devolver.

Por eso una aplicación funciona en una red y recurre a otra: una respuesta DNS, un registro de alias o una entrada de hosts cambiaron el nombre que usó el cliente. Compare el nombre solicitado con lo que contiene el directorio antes de tocar el registro.

Condición dos: ¿está el SPN en la cuenta correcta?

Un SPN debe pertenecer a la cuenta que ejecuta el servicio SQL, no a la cuenta del cliente ni, por accidente, a un objeto de equipo. SQL Server puede registrar sus propios SPN al iniciarse cuando su cuenta de servicio tiene permiso para escribirlos, lo que resulta cómodo y también explica cómo aparece un duplicado tras un cambio de cuenta de servicio.

Consulte el directorio por el nombre que espera y luego enumere lo que la cuenta posee realmente. Qué objeto contiene la entrada importa más que si el nombre existe en algún lugar del bosque. Una discrepancia significa que el inicio de sesión nunca fue el problema, y la guía de SPN de Microsoft documenta los formatos y los casos en que un administrador de dominio debe crear la entrada.

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

Añadir otra entrada no es un experimento seguro. Un duplicado o un registro en conflicto puede romper clientes que funcionaban, así que inspeccione la propiedad antes del cambio y vuelva a comprobarla después.

Condición tres: ¿puede el cliente obtener un vale siquiera?

Un SPN correcto es inútil si el cliente no puede llegar a un controlador de dominio o no tiene un contexto de credenciales utilizable. El intercambio necesita el KDC y el DNS a través de la VPN, y un túnel que solo enruta el puerto SQL falla justo en este paso. La accesibilidad debe probarse desde la misma máquina y la misma cuenta, no desde el cortafuegos que tienen delante.

Inspeccione la caché de vales en la máquina y bajo la cuenta que ejecuta la aplicación. Una lista de toda la máquina desde una ventana elevada no dice nada sobre un servicio que se ejecuta como otro usuario, y una caché vacía para ese usuario es un hallazgo y no una incomodidad.

klist
klist -li 0x3e7

Luego decida qué puede hacer un retroceso. Si la política exige Kerberos, NTLM debe rechazarse explícitamente, porque un retroceso silencioso convierte un error de configuración en una conexión que funciona y que infringe el requisito. Si NTLM sigue siendo aceptable para algunas aplicaciones, nómbrelas y deje de tratar cada sesión NTLM como un incidente.

Cambiar el lanzador es una variable, no una solución

Iniciar SSMS con otra credencial puede curar una identidad de salida no deseada, que es una clase real de problema. No demuestra nada sobre el nombre de destino, el registro o la ruta del vale, y no cambia lo que el servidor aceptó.

Mantenga la comparación controlada: mismo extremo, mismo proveedor, un contexto de ejecución conocido y luego una conexión nueva cuyo esquema inspecciona. Confirme el inicio de sesión aceptado y sus permisos de base de datos por separado, porque el acceso y la autenticación fallan por motivos distintos.

Cuando Kerberos sea obligatorio, anote por qué retrocedió la primera ruta, aplique una corrección y vuelva a ejecutar la consulta desde el mismo cliente. Una consulta correcta tras cambiar el lanzador es evidencia de acceso, y todavía no es evidencia de que se cumpliera el requisito de autenticación.