Per què SQL Server a través d’una VPN encara recorre a NTLM?

La teva connexió funciona, l’inici de sessió s’accepta i SQL Server utilitza NTLM mentre tothom esperava Kerberos. Aquest resultat no és un defecte de la VPN, perquè un túnel només proporciona un camí; l’esquema el van decidir el nom que va demanar el client, el principal registrat al directori i el tiquet que el client va poder obtenir realment. Tres condicions han de complir-se alhora, i la mateixa sessió diu quina ha cedit. Llegeix-ho abans que algú editi un nom principal de servei.

La sessió anomena l’esquema que realment has obtingut

L’esquema d’autenticació pertany a una connexió, no a un servidor ni a un túnel, així que la comprovació s’ha d’executar dins de la sessió que t’interessa. Executa la consulta de sota des del mateix client, eina i compte que van produir l’informe, i anota el nom de destinació i el transport al costat del resultat.

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

Una fila d’una finestra local de SSMS a l’amfitrió de la base de dades descriu una connexió completament diferent, i per això la consulta s’ha d’executar des del costat del client. Desa la sortida amb una marca de temps, perquè la propera persona que la llegeixi preguntarà quan es va prendre. Quan diverses aplicacions comparteixen un punt final, mostra’n una de cadascuna, perquè una diferència d’origen de dades entre dues aplicacions sovint és tota la història.

Primera condició: el nom coincideix amb l’SPN?

Kerberos autentica un servei amb nom, així que el client demana al directori un tiquet per a un principal concret. Per al proveïdor TCP, la forma documentada és MSSQLSvc/ seguida del nom d’amfitrió completament qualificat i, per a una instància per defecte, el port. Una instància amb nom registra MSSQLSvc/db01.corp.example:SQLPROD, on el sufix és el nom de la instància en lloc d’un número. Arribar al listener mitjançant un àlies, un CNAME que es resol en un altre lloc o una adreça IP nua canvia el nom sol·licitat, i una petició sense principal coincident no té cap tiquet per retornar.

És per això que una aplicació funciona en una xarxa i recorre a l’altra: una resposta DNS, un registre d’àlies o una entrada hosts van canviar el nom que el client va fer servir. Compara el nom sol·licitat amb el que té el directori abans de tocar el registre.

Segona condició: l’SPN és al compte correcte?

Un SPN ha de pertànyer al compte que executa el servei SQL, no al compte del client ni, per accident, a un objecte d’ordinador. SQL Server pot registrar els seus propis SPN a l’inici quan el seu compte de servei té permís per escriure’ls, cosa que és convenient i també explica com apareix un duplicat després d’un canvi de compte de servei.

Consulta el directori pel nom que esperes i després llista què posseeix realment el compte. Quin objecte té l’entrada importa més que si el nom existeix en algun lloc del bosc. Una discrepància vol dir que l’inici de sessió mai no va ser el problema, i la guia d’SPN de Microsoft documenta els formats i els casos en què un administrador de domini ha de crear l’entrada.

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

Afegir una altra entrada no és un experiment segur. Un duplicat o un registre en conflicte pot trencar clients que funcionaven, així que inspecciona la propietat abans del canvi i torna-la a comprovar després.

Tercera condició: pot el client obtenir cap tiquet?

Un SPN correcte és inútil si el client no pot arribar a un controlador de domini o no té un context de credencials utilitzable. L’intercanvi necessita el KDC i el DNS a través de la VPN, i un túnel que només encamina el port SQL falla precisament en aquest pas. La connectivitat s’ha de provar des de la mateixa màquina i el mateix compte, no des del tallafoc que tenen al davant.

Inspecciona la memòria cau de tiquets a la màquina i sota el compte que executa l’aplicació. Una llista de tota la màquina des d’una finestra elevada no diu res sobre un servei que s’executa com un altre usuari, i una memòria cau buida per a aquest usuari és una troballa, no una incomoditat.

klist
klist -li 0x3e7

Després decideix què pot fer una reculada. Si la política exigeix Kerberos, NTLM s’ha de rebutjar explícitament, perquè una reculada silenciosa converteix un error de configuració en una connexió que funciona i incompleix el requisit. Si NTLM continua sent acceptable per a algunes aplicacions, anomena-les i deixa de tractar cada sessió NTLM com un incident.

Canviar el llançador és una variable, no una solució

Iniciar SSMS amb una altra credencial pot curar una identitat de sortida no desitjada, que és una classe real de problema. No demostra res sobre el nom de destinació, el registre o el camí del tiquet, i no canvia què va acceptar el servidor.

Mantén la comparació controlada: mateix punt final, mateix proveïdor, un context d’execució conegut, i després una connexió nova l’esquema de la qual inspecciones. Confirma l’inici de sessió acceptat i els seus permisos de base de dades per separat, perquè l’accés i l’autenticació fallen per motius diferents.

Quan Kerberos sigui obligatori, anota per què el primer camí va recular, aplica una correcció i torna a executar la consulta des del mateix client. Una consulta correcta després d’un canvi de llançador és evidència d’accés, i encara no és evidència que el requisit d’autenticació s’hagi complert.