VPN se poveže, a SQL Server zavrne preverjanje pristnosti Windows

Tuneli se dvignejo, strežniki odgovarjajo na ping, prijava v zbirko podatkov pa še vedno ne uspe z napako preverjanja pristnosti. Ta kombinacija je na povezavah VPN pogosta in le redko pomeni, da je omrežje pokvarjeno, saj sta dosegljiv poslušalec in sprejeta prijava dva različna izida. Identiteta, ki je zadovoljila prehod, ni nujno identiteta, ki jo ponuja odjemalec zbirke podatkov. Ugotoviti, kateri račun je prispel, je cela naloga.

Simptom: dosegljiv strežnik, zavrnjena prijava

Časovna omejitev vam pove, da paket ni nikoli dosegel poslušalca. Napaka preverjanja pristnosti pove, da je poslušalec odgovoril in zavrnil poverilnico. Ti dve sporočili vas pošljeta k različnim ekipam, njuno mešanje pa stane dan na pravilih požarnega zidu, ki nikoli niso bila težava.

Ko je napaka neuspešna prijava, prenehajte gledati vrata. Ostaja vprašanje, katero identiteto Windows je odjemalec predstavil, ali jo je strežnik sprejel in ali se je razrešila v uporabnika zbirke podatkov z dovoljenjem.

Dve identiteti, en tunel

Račun VPN se preveri na prehodu in se v večini uvedb tam tudi konča. Odjemalec zbirke podatkov ločeno predstavi žeton Windows, vzet iz procesa, ki ga izvaja, ali prijavo SQL, če jo zahteva povezovalni niz. Krajevni uporabnik VPN na prehodu nima nobene povezave z domeno, ki gosti SQL Server, in tunel je ne ustvari.

Povezava osebnega računalnika z VPN ga tudi ne vpiše v domeno. Preimenovanje krajevnega računa in uskladitev njegovega gesla z uporabnikom domene ni postopek vpisa in ustvari žeton, ki ga krmilnik domene ne bo sprejel kot tega uporabnika.

Nekateri izvorni odjemalci oddaljenega dostopa Windows lahko znova uporabijo poverilnico VPN za omrežne vire, ko je njihov profil tako konfiguriran. To vedenje pripada določenemu odjemalcu in profilu, ne povezavam VPN na splošno, zato ga preverite za uporabljeni odjemalec, namesto da bi ga predpostavili.

Preberite način, ki ga je zahteval odjemalec

Povezovalni niz odloči, katero pot preverjanja pristnosti ubere odjemalec. Integrirana varnost uporablja žeton Windows; par uporabniškega imena in gesla izbere prijavo SQL. To sta ločena načina v konfiguraciji strežnika in za določen poskus povezave je lahko omogočen le eden od njiju.

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

Prehod na prijavo SQL, ker prijava Windows ni uspela, je obhod, ki skrije vprašanje identitete, in običajno vseeno zahteva ustvarjanje nove prijave in gesla. Če uvedba zahteva preverjanje pristnosti Windows, obdržite način in popravite pot identitete. Prijava SQL potrebuje tudi lastna dovoljenja, zato obhod kupi drugi račun za vzdrževanje.

Preverite tudi, katera aplikacija se povezuje. Storitev, ki teče kot sistemski račun, načrtovana opravila in interaktivno okno poizvedbe lahko na istem računalniku predstavijo tri različne žetone, in le zadnji ustreza temu, kar uporabnik vidi, ko zažene whoami.

Vprašajte strežnik, kaj je v resnici videl

Strežnik vam lahko pove, katero prijavo je razrešil in kako se je povezava preverila. Zaženite poizvedbo znotraj preiskovane seje, ker ločena uspešna povezava skrbnika ne dokaže ničesar o odjemalcu, ki ne uspeva.

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;

Prva vrstica loči prijavo, ki je odprla sejo, od varnostnega konteksta, ki velja zdaj, in ta dva se pod prevzemanjem identitete razlikujeta. Druga navaja shemo preverjanja pristnosti, zato KERBEROS, NTLM in SQL postanejo vidna dejstva namesto ugibanj. Povezava, ki poroča NTLM tam, kjer ste pričakovali Kerberos, je težava razreševanja imen ali SPN, ne težava gesla.

Številka napake to še zoži. Stanje 5 običajno pomeni, da prijavno ime sploh ni bilo razrešeno, stanje 8 običajno pomeni, da se geslo ni ujemalo, stanje 11 pa pomeni, da je bila poverilnica sprejeta, a dostop do strežnika ni uspel. Od skrbnika zahtevajte stanje namesto celotnega sporočila, ker je sporočilo samo po sebi namenoma nejasno.

Ko identiteta prispe in Kerberos še vedno ne uspe

Če strežnik vidi predvideno identiteto Windows in integrirano preverjanje pristnosti še vedno ne uspe, je težava v sami izmenjavi. Kerberos potrebuje registrirano glavno ime storitve (SPN) za račun storitve SQL in odjemalca, ki storitev zahteva z imenom, ki se z njim ujema. Povezava prek naslova IP se ne more ujemati z SPN, ki temelji na imenu, vzdevek pa se lahko ujema le, če je tudi registriran. Najprej preverite ime, ki ga je odjemalec vtipkal, ker povezava, ki deluje prek imena gostitelja in ne uspe prek IP, opisuje natanko to težavo.

Prosite skrbnika, naj pregleda registrirano identiteto in račun storitve, namesto da bi s poskusi in napakami ustvarjal podvojene SPN. Podvojene registracije povzročajo občasne okvare, ki jih je težje diagnosticirati kot prvotno težavo.

Ko preverjanje pristnosti deluje, prijava še vedno potrebuje uporabnika zbirke podatkov in dovoljenja. Uspešna prijava VPN, uspešna prijava Windows in dovoljenje za branje določene tabele so trije ločeni izidi in vsak si zasluži svoje preverjanje, preden se zahtevek zapre.