O VPN conéctase, pero SQL Server rexeita a autenticación de Windows

Os túneles levantan, os servidores responden ao ping e o inicio de sesión na base de datos segue fallando cun erro de autenticación. Esa combinación é habitual nas ligazóns VPN e rara vez significa que a rede estea rota, porque un oínte accesible e un inicio de sesión aceptado son resultados distintos. A identidade que satisfixo a pasarela non é necesariamente a identidade que ofrece o cliente da base de datos. Aclarar que conta chegou é toda a tarefa.

O síntoma: servidor accesible, inicio de sesión rexeitado

Un tempo de espera dille que o paquete nunca chegou a un oínte. Un erro de autenticación dille que o oínte respondeu e rexeitou a credencial. Esas dúas mensaxes envíano a equipos distintos, e mesturalas fai perder un día en regras de devasas que nunca foron o problema.

Cando o erro é un inicio de sesión fallido, deixe de mirar os portos. A pregunta que queda é que identidade de Windows presentou o cliente, se o servidor aceptou esa identidade e se se resolveu nun usuario da base de datos con permiso.

Dúas identidades, un túnel

A conta de VPN autentícase na pasarela e, na maioría dos despregamentos, remata aí. O cliente da base de datos presenta por separado un token de Windows, tomado do proceso que o executa, ou un inicio de sesión SQL se a cadea de conexión pide un. Un usuario de VPN local na pasarela non ten relación ningunha co dominio que aloxa SQL Server, e o túnel non a crea.

Conectar unha máquina persoal a unha VPN tampouco a une ao dominio. Cambiar o nome dunha conta local e facer que o seu contrasinal coincida co dun usuario do dominio non é un procedemento de alta, e produce un token que o controlador de dominio non aceptará como ese usuario.

Algúns clientes nativos de acceso remoto de Windows poden reutilizar a credencial de VPN para recursos de rede cando o seu perfil está configurado así. Ese comportamento pertence a un cliente e un perfil concretos, non ás conexións VPN en xeral, así que verifíqueo para o cliente en uso en lugar de supoñelo.

Lea o modo que pediu o cliente

A cadea de conexión decide que ruta de autenticación toma o cliente. A seguridade integrada usa o token de Windows; un par de usuario e contrasinal selecciona un inicio de sesión SQL. Son modos separados na configuración do servidor, e só un deles pode estar habilitado para un intento de conexión dado.

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

Pasar a un inicio de sesión SQL porque o inicio de sesión de Windows fallou é unha solución provisional que agocha a cuestión da identidade, e normalmente require crear de todos os xeitos un inicio de sesión e un contrasinal novos. Se o despregamento esixe autenticación de Windows, manteña o modo e arranxe a ruta de identidade. Un inicio de sesión SQL tamén necesita os seus propios permisos, así que a solución provisional compra unha segunda conta que manter.

Confirme tamén que aplicación se conecta. Un servizo que se executa como conta de sistema, unha tarefa programada e unha xanela de consulta interactiva poden presentar tres tokens distintos na mesma máquina, e só o último coincide co que ve o usuario cando executa whoami.

Pregunte ao servidor que viu realmente

O servidor pode dicirlle que inicio de sesión resolveu e como se autenticou a conexión. Execute a consulta dentro da sesión que se investiga, porque unha conexión correcta separada do administrador non demostra nada sobre o 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;

A primeira fila distingue o inicio de sesión que abriu a sesión do contexto de seguridade vixente agora, que difiren baixo suplantación. A segunda nomea o esquema de autenticación, así que KERBEROS, NTLM e SQL pasan a ser feitos visibles en lugar de conxecturas. Unha conexión que informa de NTLM onde esperaba Kerberos é un problema de resolución de nomes ou de SPN, non un problema de contrasinal.

O número de erro acótao máis. O estado 5 adoita significar que o nome de inicio de sesión non se resolveu en absoluto, o estado 8 adoita significar que o contrasinal non coincidiu, e o estado 11 significa que a credencial se aceptou pero o acceso ao servidor fallou. Pida ao administrador o estado en lugar da mensaxe completa, porque a mensaxe por si soa é deliberadamente vaga.

Cando chega a identidade e Kerberos segue fallando

Se o servidor ve a identidade de Windows prevista e a autenticación integrada segue fallando, o problema é o intercambio mesmo. Kerberos necesita o nome principal de servizo rexistrado para a conta de servizo SQL e un cliente que solicite o servizo cun nome que coincida. Conectar por enderezo IP non pode coincidir cun SPN baseado en nome, e un alias só pode coincidir se tamén está rexistrado. Comprobe o nome que escribiu o cliente antes que nada, porque unha conexión que funciona por nome de host e falla por IP describe exactamente este problema.

Pida ao administrador que revise a identidade rexistrada e a conta de servizo en lugar de crear SPN duplicados por proba e erro. Os rexistros duplicados producen fallos intermitentes que son máis difíciles de diagnosticar que o problema orixinal.

Unha vez que a autenticación funciona, o inicio de sesión segue necesitando un usuario da base de datos e permisos. Un inicio de sesión VPN correcto, un inicio de sesión Windows correcto e o permiso para ler unha táboa concreta son tres resultados separados, e cada un merece a súa propia comprobación antes de pechar o tícket.