De ce SQL Server prin VPN tot revine la NTLM?

Conexiunea dumneavoastră funcționează, autentificarea este acceptată, iar SQL Server folosește NTLM în timp ce toți se așteptau la Kerberos. Acest rezultat nu este un defect al VPN-ului, pentru că un tunel oferă doar o cale; schema a fost decisă de numele cerut de client, de principalul înregistrat în director și de biletul pe care clientul a putut efectiv să îl obțină. Trei condiții trebuie să fie valabile simultan, iar sesiunea însăși spune care a cedat. Citiți asta înainte ca cineva să editeze un nume principal de serviciu.

Sesiunea numește schema pe care ați obținut-o efectiv

Schema de autentificare aparține unei conexiuni, nu unui server sau unui tunel, așa că verificarea trebuie să ruleze în interiorul sesiunii care vă interesează. Executați interogarea de mai jos de la același client, instrument și cont care au produs raportul, și notați numele țintei și transportul lângă rezultat.

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

Un rând dintr-o fereastră SSMS locală pe gazda bazei de date descrie o conexiune complet diferită, motiv pentru care interogarea trebuie executată din partea clientului. Salvați ieșirea cu o marcă de timp, pentru că următoarea persoană care o citește va întreba când a fost luată. Când mai multe aplicații partajează un singur punct final, luați o mostră din fiecare, pentru că o diferență de sursă de date între două aplicații este adesea toată povestea.

Prima condiție: numele se potrivește cu SPN-ul?

Kerberos autentifică un serviciu cu nume, așa că clientul cere directorului un bilet pentru un anumit principal. Pentru furnizorul TCP, forma documentată este MSSQLSvc/ urmată de numele de gazdă complet calificat și, pentru o instanță implicită, de port. O instanță cu nume înregistrează MSSQLSvc/db01.corp.example:SQLPROD, unde sufixul este numele instanței în loc de un număr. Atingerea ascultătorului printr-un alias, printr-un CNAME care se rezolvă în altă parte sau printr-o adresă IP simplă schimbă numele cerut, iar o cerere fără un principal corespunzător nu are niciun bilet de returnat.

De aceea o aplicație funcționează într-o rețea și revine în alta: un răspuns DNS, o înregistrare alias sau o intrare hosts au schimbat numele folosit de client. Comparați numele cerut cu ceea ce conține directorul înainte de a atinge înregistrarea.

A doua condiție: SPN-ul este pe contul corect?

Un SPN trebuie să aparțină contului care rulează serviciul SQL, nu contului clientului și nu, din greșeală, unui obiect de computer. SQL Server își poate înregistra propriile SPN la pornire atunci când contul său de serviciu are permisiunea de a le scrie, ceea ce este convenabil și explică și modul în care apare un duplicat după o schimbare a contului de serviciu.

Întrebați directorul despre numele pe care îl așteptați, apoi listați ce deține efectiv contul. Care obiect deține intrarea contează mai mult decât dacă numele există undeva în pădure. O nepotrivire înseamnă că autentificarea nu a fost niciodată problema, iar ghidul SPN al Microsoft documentează formatele și cazurile în care un administrator de domeniu trebuie să creeze intrarea.

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

Adăugarea unei alte intrări nu este un experiment sigur. Un duplicat sau o înregistrare conflictuală poate rupe clienți care funcționau, așa că inspectați proprietatea înainte de schimbare și verificați-o din nou după.

A treia condiție: clientul poate obține un bilet?

Un SPN corect este inutil dacă clientul nu poate ajunge la un controler de domeniu sau nu are un context de acreditări utilizabil. Schimbul are nevoie de KDC și DNS prin VPN, iar un tunel care rutează doar portul SQL eșuează exact la acest pas. Accesibilitatea trebuie testată de pe aceeași mașină și din același cont, nu de la firewall-ul din fața lor.

Inspectați memoria cache de bilete de pe mașină și sub contul care rulează aplicația. O listă la nivel de mașină dintr-o fereastră elevată nu spune nimic despre un serviciu care rulează ca alt utilizator, iar un cache gol pentru acel utilizator este o constatare, nu un inconvenient.

klist
klist -li 0x3e7

Apoi decideți ce poate face o revenire. Dacă politica impune Kerberos, NTLM trebuie refuzat explicit, pentru că o revenire silențioasă transformă o eroare de configurare într-o conexiune funcțională care încalcă cerința. Dacă NTLM rămâne acceptabil pentru unele aplicații, numiți-le și încetați să tratați fiecare sesiune NTLM ca pe un incident.

Schimbarea lansatorului este o variabilă, nu o corecție

Pornirea SSMS cu alte acreditări poate vindeca o identitate de ieșire nedorită, ceea ce este o clasă reală de problemă. Nu dovedește nimic despre numele țintei, înregistrare sau calea biletului și nu schimbă ceea ce a acceptat serverul.

Păstrați comparația controlată: același punct final, același furnizor, un context de execuție cunoscut, apoi o conexiune nouă al cărei schemă o inspectați. Confirmați separat autentificarea acceptată și permisiunile ei pe bază de date, pentru că accesul și autentificarea eșuează din motive diferite.

Când Kerberos este obligatoriu, notați de ce a cedat prima cale, aplicați o corecție și rulați din nou interogarea de la același client. O interogare reușită după o schimbare a lansatorului este dovadă de acces și nu este încă dovada că cerința de autentificare a fost îndeplinită.