El VPN conecta, pero SQL Server rechaza la autenticación de Windows

Los túneles se levantan, los servidores responden al ping y el inicio de sesión en la base de datos sigue fallando con un error de autenticación. Esa combinación es habitual en enlaces VPN y rara vez significa que la red esté rota, porque un oyente accesible y un inicio de sesión aceptado son resultados distintos. La identidad que satisfizo la puerta de enlace no es necesariamente la identidad que ofrece el cliente de la base de datos. Averiguar qué cuenta llegó es toda la tarea.

El síntoma: servidor accesible, inicio de sesión rechazado

Un tiempo de espera le dice que el paquete nunca llegó a un oyente. Un error de autenticación le dice que el oyente respondió y rechazó la credencial. Esos dos mensajes le envían a equipos distintos, y mezclarlos hace perder un día en reglas de cortafuegos que nunca fueron el problema.

Cuando el error es un inicio de sesión fallido, deje de mirar los puertos. La pregunta que queda es qué identidad de Windows presentó el cliente, si el servidor aceptó esa identidad y si se resolvió en un usuario de la base de datos con permiso.

Dos identidades, un túnel

La cuenta de VPN se autentica en la puerta de enlace y, en la mayoría de los despliegues, termina ahí. El cliente de la base de datos presenta por separado un token de Windows, tomado del proceso que lo ejecuta, o un inicio de sesión SQL si la cadena de conexión pide uno. Un usuario de VPN local en la puerta de enlace no tiene relación alguna con el dominio que aloja SQL Server, y el túnel no la crea.

Conectar una máquina personal a una VPN tampoco la une al dominio. Cambiar el nombre de una cuenta local y hacer que su contraseña coincida con la de un usuario del dominio no es un procedimiento de alta, y produce un token que el controlador de dominio no aceptará como ese usuario.

Algunos clientes nativos de acceso remoto de Windows pueden reutilizar la credencial de VPN para recursos de red cuando su perfil está configurado así. Ese comportamiento pertenece a un cliente y un perfil concretos, no a las conexiones VPN en general, así que verifíquelo para el cliente en uso en lugar de suponerlo.

Lea el modo que pidió el cliente

La cadena de conexión decide qué ruta de autenticación toma el cliente. La seguridad integrada usa el token de Windows; un par de usuario y contraseña selecciona un inicio de sesión SQL. Son modos separados en la configuración del servidor, y solo uno de ellos puede estar habilitado para un intento de conexión dado.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Cambiar a un inicio de sesión SQL porque el inicio de sesión de Windows falló es un apaño que oculta la cuestión de la identidad, y normalmente requiere crear de todos modos un inicio de sesión y una contraseña nuevos. Si el despliegue exige autenticación de Windows, mantenga el modo y arregle la ruta de identidad. Un inicio de sesión SQL también necesita sus propios permisos, así que el apaño compra una segunda cuenta que mantener.

Confirme también qué aplicación se conecta. Un servicio que se ejecuta como cuenta de sistema, una tarea programada y una ventana de consulta interactiva pueden presentar tres tokens distintos en la misma máquina, y solo el último coincide con lo que ve el usuario cuando ejecuta whoami.

Pregunte al servidor qué vio realmente

El servidor puede decirle qué inicio de sesión resolvió y cómo se autenticó la conexión. Ejecute la consulta dentro de la sesión que se investiga, porque una conexión correcta separada del administrador no demuestra nada sobre el cliente que falla.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

La primera fila distingue el inicio de sesión que abrió la sesión del contexto de seguridad vigente ahora, que difieren bajo suplantación. La segunda nombra el esquema de autenticación, así que KERBEROS, NTLM y SQL pasan a ser hechos visibles en lugar de conjeturas. Una conexión que informa de NTLM donde esperaba Kerberos es un problema de resolución de nombres o de SPN, no un problema de contraseña.

El número de error lo acota más. El estado 5 suele significar que el nombre de inicio de sesión no se resolvió en absoluto, el estado 8 suele significar que la contraseña no coincidió, y el estado 11 significa que la credencial se aceptó pero el acceso al servidor falló. Pida al administrador el estado en lugar del mensaje completo, porque el mensaje por sí solo es deliberadamente vago.

Cuando llega la identidad y Kerberos sigue fallando

Si el servidor ve la identidad de Windows prevista y la autenticación integrada sigue fallando, el problema es el intercambio mismo. Kerberos necesita el nombre principal de servicio registrado para la cuenta de servicio SQL y un cliente que solicite el servicio con un nombre que coincida. Conectar por dirección IP no puede coincidir con un SPN basado en nombre, y un alias solo puede coincidir si también está registrado. Compruebe el nombre que escribió el cliente antes que nada, porque una conexión que funciona por nombre de host y falla por IP describe exactamente este problema.

Pida al administrador que revise la identidad registrada y la cuenta de servicio en lugar de crear SPN duplicados por prueba y error. Los registros duplicados producen fallos intermitentes que son más difíciles de diagnosticar que el problema original.

Una vez que la autenticación funciona, el inicio de sesión sigue necesitando un usuario de la base de datos y permisos. Un inicio de sesión VPN correcto, un inicio de sesión Windows correcto y el permiso para leer una tabla concreta son tres resultados separados, y cada uno merece su propia comprobación antes de cerrar el tique.