El VPN connecta, però SQL Server rebutja l’autenticació de Windows

Els túnels s’aixequen, els servidors responen al ping i l’inici de sessió a la base de dades encara falla amb un error d’autenticació. Aquesta combinació és habitual en enllaços VPN i poques vegades vol dir que la xarxa estigui trencada, perquè un oient accessible i un inici de sessió acceptat són resultats diferents. La identitat que va satisfer la passarel·la no és necessàriament la identitat que ofereix el client de la base de dades. Esbrinar quin compte ha arribat és tota la feina.

El símptoma: servidor accessible, inici de sessió rebutjat

Un temps d’espera us diu que el paquet no va arribar mai a cap oient. Un error d’autenticació us diu que l’oient va respondre i va rebutjar la credencial. Aquests dos missatges us envien a equips diferents, i barrejar-los fa perdre un dia en regles de tallafoc que mai no eren el problema.

Quan l’error és un inici de sessió fallit, deixeu de mirar els ports. La pregunta que queda és quina identitat de Windows ha presentat el client, si el servidor l’ha acceptada i si s’ha resolt en un usuari de la base de dades amb permís.

Dues identitats, un túnel

El compte de VPN s’autentica a la passarel·la i, en la majoria de desplegaments, s’hi acaba. El client de la base de dades presenta per separat un testimoni de Windows, pres del procés que l’executa, o un inici de sessió SQL si la cadena de connexió en demana un. Un usuari de VPN local a la passarel·la no té cap relació amb el domini que allotja SQL Server, i el túnel no en crea cap.

Connectar una màquina personal a una VPN tampoc no la uneix al domini. Canviar el nom d’un compte local i fer que la seva contrasenya coincideixi amb la d’un usuari del domini no és cap procediment d’alta, i produeix un testimoni que el controlador de domini no acceptarà com a aquell usuari.

Alguns clients natius d’accés remot de Windows poden reutilitzar la credencial de VPN per a recursos de xarxa quan el seu perfil està configurat així. Aquest comportament pertany a un client i un perfil concrets, no a les connexions VPN en general, així que verifiqueu-lo per al client en ús en lloc de suposar-lo.

Llegiu el mode que ha demanat el client

La cadena de connexió decideix quin camí d’autenticació pren el client. La seguretat integrada fa servir el testimoni de Windows; una parella d’usuari i contrasenya selecciona un inici de sessió SQL. Són modes separats a la configuració del servidor, i només un d’ells pot estar habilitat per a un intent de connexió determinat.

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

Passar a un inici de sessió SQL perquè l’inici de sessió de Windows ha fallat és una solució provisional que amaga la qüestió de la identitat, i normalment encara cal crear un inici de sessió i una contrasenya nous. Si el desplegament requereix autenticació de Windows, manteniu el mode i arregleu el camí de la identitat. Un inici de sessió SQL també necessita els seus propis permisos, així que la solució provisional compra un segon compte per mantenir.

Confirmeu també quina aplicació es connecta. Un servei que s’executa com a compte de sistema, una tasca programada i una finestra de consulta interactiva poden presentar tres testimonis diferents a la mateixa màquina, i només l’últim coincideix amb el que veu l’usuari quan executa whoami.

Pregunteu al servidor què ha vist realment

El servidor us pot dir quin inici de sessió ha resolt i com s’ha autenticat la connexió. Executeu la consulta dins de la sessió que s’investiga, perquè una connexió correcta separada de l’administrador no demostra res sobre el client 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 distingeix l’inici de sessió que va obrir la sessió del context de seguretat vigent ara, que difereixen sota suplantació. La segona nomena l’esquema d’autenticació, així que KERBEROS, NTLM i SQL esdevenen fets visibles en lloc de conjectures. Una connexió que informa de NTLM on esperàveu Kerberos és un problema de resolució de noms o d’SPN, no un problema de contrasenya.

El número d’error ho acota més. L’estat 5 normalment vol dir que el nom d’inici de sessió no s’ha resolt gens, l’estat 8 normalment vol dir que la contrasenya no coincidia, i l’estat 11 vol dir que la credencial s’ha acceptat però l’accés al servidor ha fallat. Demaneu a l’administrador l’estat en lloc del missatge sencer, perquè el missatge sol és deliberadament vague.

Quan la identitat arriba i Kerberos encara falla

Si el servidor veu la identitat de Windows prevista i l’autenticació integrada encara falla, el problema és l’intercanvi mateix. Kerberos necessita el nom principal de servei registrat per al compte de servei SQL i un client que demani el servei amb un nom que hi coincideixi. Connectar per adreça IP no pot coincidir amb un SPN basat en nom, i un àlies només pot coincidir si també està registrat. Comproveu el nom que ha escrit el client abans que res, perquè una connexió que funciona per nom d’amfitrió i falla per IP descriu exactament aquest problema.

Demaneu a l’administrador que revisi la identitat registrada i el compte de servei en lloc de crear SPN duplicats per assaig i error. Les inscripcions duplicades produeixen fallades intermitents que són més difícils de diagnosticar que el problema original.

Un cop l’autenticació funciona, l’inici de sessió encara necessita un usuari de la base de dades i permisos. Un inici de sessió VPN correcte, un inici de sessió Windows correcte i el permís per llegir una taula concreta són tres resultats separats, i cadascun mereix la seva pròpia comprovació abans de tancar el tiquet.