VPN-ul se conectează, dar SQL Server refuză autentificarea Windows

Tunelurile urcă, serverele răspund la ping, iar autentificarea la baza de date eșuează în continuare cu o eroare de autentificare. Această combinație este obișnuită pe legăturile VPN și rareori înseamnă că rețeaua este stricată, deoarece un ascultător accesibil și o autentificare acceptată sunt două rezultate diferite. Identitatea care a satisfăcut poarta nu este neapărat identitatea pe care o oferă clientul bazei de date. A stabili ce cont a ajuns este întreaga sarcină.

Simptomul: server accesibil, autentificare refuzată

Un timeout vă spune că pachetul nu a ajuns niciodată la un ascultător. O eroare de autentificare vă spune că ascultătorul a răspuns și a refuzat acreditarea. Aceste două mesaje vă trimit la echipe diferite, iar amestecarea lor costă o zi pe reguli de firewall care nu au fost niciodată problema.

Când eroarea este o autentificare eșuată, opriți-vă din a vă uita la porturi. Întrebarea rămasă este ce identitate Windows a prezentat clientul, dacă serverul a acceptat acea identitate și dacă s-a rezolvat într-un utilizator al bazei de date cu permisiune.

Două identități, un tunel

Contul VPN se autentifică la poartă și, în majoritatea implementărilor, se termină acolo. Clientul bazei de date prezintă separat un token Windows, luat din procesul care îl execută, sau o autentificare SQL dacă șirul de conexiune cere una. Un utilizator VPN local la poartă nu are nicio relație cu domeniul care găzduiește SQL Server, iar tunelul nu creează una.

Conectarea unui calculator personal la un VPN nu îl înscrie nici în domeniu. Redenumirea unui cont local și potrivirea parolei lui cu cea a unui utilizator de domeniu nu este o procedură de înscriere și produce un token pe care controlerul de domeniu nu îl va accepta ca acel utilizator.

Unii clienți nativi de acces la distanță din Windows pot reutiliza acreditarea VPN pentru resurse de rețea atunci când profilul lor este configurat astfel. Acest comportament aparține unui client și unui profil anume, nu conexiunilor VPN în general, așa că verificați-l pentru clientul folosit în loc să îl presupuneți.

Citiți modul cerut de client

Șirul de conexiune decide ce cale de autentificare urmează clientul. Securitatea integrată folosește tokenul Windows; o pereche de utilizator și parolă selectează o autentificare SQL. Acestea sunt moduri separate în configurația serverului și doar unul dintre ele poate fi activat pentru o anumită încercare de conectare.

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

Trecerea la o autentificare SQL pentru că autentificarea Windows a eșuat este o soluție ocolitoare care ascunde întrebarea identității și de obicei cere oricum crearea unei autentificări și a unei parole noi. Dacă implementarea cere autentificare Windows, păstrați modul și reparați calea identității. O autentificare SQL are nevoie și de propriile permisiuni, așa că soluția ocolitoare cumpără un al doilea cont de întreținut.

Confirmați și ce aplicație se conectează. Un serviciu care rulează ca cont de sistem, o sarcină planificată și o fereastră de interogare interactivă pot prezenta trei tokenuri diferite pe același calculator, iar doar ultimul corespunde cu ceea ce vede utilizatorul când rulează whoami.

Întrebați serverul ce a văzut de fapt

Serverul vă poate spune ce autentificare a rezolvat și cum s-a autentificat conexiunea. Rulați interogarea în interiorul sesiunii investigate, deoarece o conexiune reușită separată a administratorului nu dovedește nimic despre clientul care eșuează.

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;

Primul rând distinge autentificarea care a deschis sesiunea de contextul de securitate valabil acum, iar acestea diferă sub impersonare. Al doilea numește schema de autentificare, astfel încât KERBEROS, NTLM și SQL devin fapte vizibile în loc de presupuneri. O conexiune care raportează NTLM acolo unde așteptați Kerberos este o problemă de rezolvare a numelor sau de SPN, nu o problemă de parolă.

Numărul erorii restrânge mai mult. Starea 5 înseamnă de obicei că numele de autentificare nu a fost rezolvat deloc, starea 8 înseamnă de obicei că parola nu s-a potrivit, iar starea 11 înseamnă că acreditarea a fost acceptată, dar accesul la server a eșuat. Cereți administratorului starea în loc de mesajul întreg, deoarece mesajul singur este în mod deliberat vag.

Când identitatea ajunge și Kerberos tot eșuează

Dacă serverul vede identitatea Windows dorită și autentificarea integrată tot eșuează, problema este schimbul în sine. Kerberos are nevoie de numele principal de serviciu înregistrat pentru contul de serviciu SQL și de un client care solicită serviciul cu un nume care îi corespunde. Conectarea prin adresă IP nu poate corespunde unui SPN bazat pe nume, iar un alias poate corespunde doar dacă este și el înregistrat. Verificați mai întâi numele tastat de client, deoarece o conexiune care funcționează prin numele gazdei și eșuează prin IP descrie exact această problemă.

Rugați administratorul să revizuiască identitatea înregistrată și contul de serviciu în loc să creeze SPN-uri duplicate prin încercări. Înregistrările duplicate produc defecțiuni intermitente care sunt mai greu de diagnosticat decât problema inițială.

După ce autentificarea funcționează, autentificarea are în continuare nevoie de un utilizator al bazei de date și de permisiuni. O autentificare VPN reușită, o autentificare Windows reușită și permisiunea de a citi un anumit tabel sunt trei rezultate separate, iar fiecare merită propria verificare înainte de închiderea tichetului.