VPN prisijungia, bet SQL Server atmeta Windows autentifikaciją

Tuneliai pakyla, serveriai atsako į ping, o prisijungimas prie duomenų bazės vis tiek nepavyksta su autentifikacijos klaida. Šis derinys dažnas VPN jungtyse ir retai reiškia, kad tinklas sugedęs, nes pasiekiamas klausytojas ir priimtas prisijungimas yra du skirtingi rezultatai. Tapatybė, kuri patenkino šliuzą, nebūtinai yra tapatybė, kurią siūlo duomenų bazės klientas. Išsiaiškinti, kuri paskyra atvyko, yra visas darbas.

Simptomas: pasiekiamas serveris, atmestas prisijungimas

Skirtasis laikas rodo, kad paketas niekada nepasiekė klausytojo. Autentifikacijos klaida rodo, kad klausytojas atsakė ir atmetė prisijungimo duomenis. Šie du pranešimai nukreipia jus į skirtingas komandas, o jų painiojimas kainuoja dieną ugniasienės taisyklėms, kurios niekada nebuvo problema.

Kai klaida yra nepavykęs prisijungimas, nustokite žiūrėti į prievadus. Lieka klausimas, kokią Windows tapatybę pateikė klientas, ar serveris tą tapatybę priėmė ir ar ji buvo išspręsta į duomenų bazės naudotoją su leidimu.

Dvi tapatybės, vienas tunelis

VPN paskyra autentifikuojasi šliuze ir daugumoje diegimų ten baigiasi. Duomenų bazės klientas atskirai pateikia Windows žetoną, paimtą iš proceso, kuris jį vykdo, arba SQL prisijungimą, jei to reikalauja prisijungimo eilutė. Šliuze esantis vietinis VPN naudotojas neturi jokio ryšio su domenu, kuriame veikia SQL Server, ir tunelis tokio ryšio nesukuria.

Asmeninio kompiuterio prijungimas prie VPN taip pat neįtraukia jo į domeną. Vietinės paskyros pervadinimas ir jos slaptažodžio priderinimas prie domeno naudotojo nėra registracijos procedūra, ir tai sukuria žetoną, kurio domeno valdiklis nepriims kaip to naudotojo.

Kai kurie savieji Windows nuotolinės prieigos klientai gali pakartotinai naudoti VPN prisijungimo duomenis tinklo ištekliams, kai jų profilis taip sukonfigūruotas. Toks elgesys priklauso konkrečiam klientui ir profiliui, o ne VPN jungtims apskritai, todėl patikrinkite jį naudojamam klientui, o ne darykite prielaidą.

Perskaitykite režimą, kurio paprašė klientas

Prisijungimo eilutė nusprendžia, kokį autentifikacijos kelią pasirinks klientas. Integruota sauga naudoja Windows žetoną; naudotojo ir slaptažodžio pora pasirenka SQL prisijungimą. Tai atskiri režimai serverio konfigūracijoje, ir tam tikram prisijungimo bandymui gali būti įjungtas tik vienas iš jų.

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

Perėjimas prie SQL prisijungimo dėl to, kad nepavyko Windows prisijungimas, yra apėjimo sprendimas, slepiantis tapatybės klausimą, ir paprastai vis tiek reikia sukurti naują prisijungimą ir slaptažodį. Jei diegimas reikalauja Windows autentifikacijos, palikite režimą ir sutvarkykite tapatybės kelią. SQL prisijungimui taip pat reikia savo leidimų, todėl apėjimas nusiperka antrą paskyrą, kurią reikės prižiūrėti.

Taip pat patikrinkite, kuri programa jungiasi. Paslauga, veikianti kaip sistemos paskyra, suplanuota užduotis ir interaktyvus užklausos langas tame pačiame kompiuteryje gali pateikti tris skirtingus žetonus, ir tik paskutinis atitinka tai, ką naudotojas mato paleisdamas whoami.

Paklauskite serverio, ką jis iš tikrųjų matė

Serveris gali pasakyti, kurį prisijungimą jis išsprendė ir kaip jungtis autentifikavosi. Vykdykite užklausą tiriamoje sesijoje, nes atskiras sėkmingas administratoriaus prisijungimas nieko neįrodo apie nepavykstantį klientą.

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;

Pirmoji eilutė atskiria prisijungimą, kuris atidarė sesiją, nuo dabar galiojančio saugos konteksto, ir apsimetimo atveju jie skiriasi. Antroji nurodo autentifikacijos schemą, todėl KERBEROS, NTLM ir SQL tampa matomais faktais, o ne spėjimais. Ryšys, kuris praneša NTLM ten, kur tikėjotės Kerberos, yra vardų sprendimo arba SPN problema, o ne slaptažodžio problema.

Klaidos numeris dar labiau susiaurina. 5 būsena paprastai reiškia, kad prisijungimo vardas visiškai neišspręstas, 8 būsena paprastai reiškia, kad slaptažodis nesutapo, o 11 būsena reiškia, kad prisijungimo duomenys priimti, bet prieiga prie serverio nepavyko. Prašykite administratoriaus būsenos, o ne viso pranešimo, nes pranešimas vienas yra sąmoningai neaiškus.

Kai tapatybė atvyksta, o Kerberos vis tiek nepavyksta

Jei serveris mato numatytą Windows tapatybę, o integruota autentifikacija vis tiek nepavyksta, problema yra pats mainai. Kerberos reikia užregistruoto paslaugos pagrindinio vardo (SPN) SQL paslaugos paskyrai ir kliento, kuris prašo paslaugos jį atitinkančiu vardu. Jungiantis IP adresu negalima atitikti vardu pagrįsto SPN, o pseudonimas gali atitikti tik jei jis taip pat užregistruotas. Pirmiausia patikrinkite vardą, kurį įvedė klientas, nes ryšys, kuris veikia pagal mazgo vardą ir nepavyksta pagal IP, apibūdina būtent šią problemą.

Paprašykite administratoriaus peržiūrėti užregistruotą tapatybę ir paslaugos paskyrą, o ne kurti dubliuotus SPN bandymų ir klaidų būdu. Dubliuotos registracijos sukelia periodiškus gedimus, kuriuos diagnozuoti sunkiau nei pradinę problemą.

Kai autentifikacija veikia, prisijungimui vis tiek reikia duomenų bazės naudotojo ir leidimų. Sėkmingas VPN prisijungimas, sėkmingas Windows prisijungimas ir leidimas skaityti konkrečią lentelę yra trys atskiri rezultatai, ir kiekvienas jų nusipelno savo patikros prieš uždarant bilietą.