VPNa konektatzen da, baina SQL Serverrek Windows autentifikazioa baztertzen du

Tunelak altxatzen dira, zerbitzariek ping-ari erantzuten diote, eta datu-basearen saio-hasierak huts egiten jarraitzen du autentifikazio-errore batekin. Konbinazio hori ohikoa da VPN loturetan eta gutxitan esan nahi du sareak huts egin duenik, entzule eskuragarri bat eta onartutako saio-hasiera bi emaitza desberdinak baitira. Pasabidea asetu zuen identitatea ez da nahitaez datu-baseko bezeroak eskaintzen duen identitatea. Zein kontu iritsi den argitzea da lan osoa.

Sintoma: zerbitzari eskuragarria, saio-hasiera baztertua

Denbora-muga batek esaten dizu paketea ez zela inoiz entzule batera iritsi. Autentifikazio-errore batek esaten dizu entzuleak erantzun zuela eta kredentziala baztertu zuela. Bi mezu horiek talde desberdinetara bidaltzen zaituzte, eta nahasteak egun oso bat galtzen du inoiz arazoa izan ez ziren suebaki-arauetan.

Errorea saio-hasiera hutsa denean, utzi atakak begiratzeari. Gainerako galdera hau da: zein Windows identitate aurkeztu zuen bezeroak, zerbitzariak identitate hori onartu ote zuen, eta baimena duen datu-baseko erabiltzaile bihurtu ote zen.

Bi identitate, tunel bat

VPN kontua pasabidean autentifikatzen da eta, inplementazio gehienetan, hor amaitzen da. Datu-baseko bezeroak bereizita aurkezten du Windows token bat, exekutatzen duen prozesutik hartua, edo SQL saio-hasiera bat konexio-kateak hala eskatzen badu. Pasabideko VPN erabiltzaile lokalak ez du zerikusirik SQL Server ostatatzen duen domeinuarekin, eta tunelak ez du halakorik sortzen.

Makina pertsonal bat VPN batera konektatzeak ere ez du domeinura gehitzen. Kontu lokal bati izena aldatzea eta haren pasahitza domeinuko erabiltzaile batenarekin bat etortzea ez da izen-emate prozedura bat, eta domeinu-kontrolatzaileak erabiltzaile hori bezala onartuko ez duen token bat sortzen du.

Windows-en urruneko sarbideko bezero natibo batzuek VPN kredentziala berrerabil dezakete sare-baliabideetarako, haien profila horrela konfiguratuta badago. Jokabide hori bezero eta profil jakin bati dagokio, ez VPN konexioei oro har, beraz, egiaztatu erabiltzen ari den bezeroarentzat, suposatu beharrean.

Irakurri bezeroak eskatu zuen modua

Konexio-kateak erabakitzen du zein autentifikazio-bide hartzen duen bezeroak. Segurtasun integratuak Windows tokena erabiltzen du; erabiltzaile eta pasahitz bikote batek SQL saio-hasiera hautatzen du. Zerbitzariaren konfigurazioan modu bereiziak dira, eta konexio-saiakera jakin baterako haietako bat soilik egon daiteke gaituta.

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

Windows saio-hasierak huts egin duelako SQL saio-hasierara aldatzea identitatearen galdera ezkutatzen duen irtenbide bat da, eta normalean saio-hasiera eta pasahitz berriak sortzea eskatzen du hala ere. Inplementazioak Windows autentifikazioa eskatzen badu, mantendu modua eta konpondu identitatearen bidea. SQL saio-hasierak bere baimenak ere behar ditu, beraz irtenbideak mantentzeko bigarren kontu bat erosten du.

Egiaztatu ere zein aplikazio ari den konektatzen. Sistema-kontu gisa exekutatzen den zerbitzu batek, programatutako zeregin batek eta kontsulta-leiho interaktibo batek hiru token desberdin aurkez ditzakete makina berean, eta azkenak soilik bat egiten du erabiltzaileak whoami exekutatzen duenean ikusten duenarekin.

Galdetu zerbitzariari zer ikusi zuen benetan

Zerbitzariak esan diezazuke zein saio-hasiera ebatzi zuen eta nola autentifikatu zen konexioa. Exekutatu kontsulta ikertzen ari den saioaren barruan, administratzailearen beste konexio arrakastatsu batek ez baitu ezer frogatzen huts egiten ari den bezeroari buruz.

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;

Lehen errenkadak saioa ireki zuen saio-hasiera orain indarrean dagoen segurtasun-testuingurutik bereizten du, eta horiek desberdinak dira nortasun-bereganatzean. Bigarrenak autentifikazio-eskemari izena ematen dio, beraz KERBEROS, NTLM eta SQL susmoak beharrean gertaera ikusgai bihurtzen dira. Kerberos espero zenuen tokian NTLM jakinarazten duen konexioa izen-ebazpen edo SPN arazo bat da, ez pasahitz arazo bat.

Errore-zenbakiak gehiago mugatzen du. 5 egoerak normalean esan nahi du saio-hasierako izena ez zela batere ebatzi, 8 egoerak normalean pasahitzak bat ez zuela egin, eta 11 egoerak kredentziala onartu zela baina zerbitzarirako sarbideak huts egin zuela. Eskatu administratzaileari egoera, mezu osoa beharrean, mezua bera nahita lausoa baita.

Identitatea iristen denean eta Kerberosek huts egiten jarraitzen duenean

Zerbitzariak nahi den Windows identitatea ikusten badu eta autentifikazio integratuak huts egiten jarraitzen badu, trukea bera da arazoa. Kerberosek SQL zerbitzu-konturako erregistratutako zerbitzu-izen nagusia behar du, eta harekin bat datorren izen batez zerbitzua eskatzen duen bezero bat. IP helbide bidez konektatzeak ezin du izenetan oinarritutako SPN batekin bat egin, eta alias batek soilik egin dezake bat erregistratuta badago ere. Egiaztatu bezeroak idatzitako izena lehenengo, host-izenaz funtzionatzen duen eta IPz huts egiten duen konexio batek arazo hau deskribatzen baitu zehazki.

Eskatu administratzaileari erregistratutako identitatea eta zerbitzu-kontua berrikustea, proba eta hutsez SPN bikoiztuak sortu beharrean. Erregistro bikoiztuek tartekako hutsegiteak sortzen dituzte, jatorrizko arazoa baino zailagoak direnak diagnostikatzen.

Autentifikazioa funtzionatzen duenean, saio-hasierak datu-baseko erabiltzaile bat eta baimenak behar ditu oraindik. VPN saio-hasiera arrakastatsu bat, Windows saio-hasiera arrakastatsu bat eta taula jakin bat irakurtzeko baimena hiru emaitza bereiziak dira, eta bakoitzak bere egiaztapena merezi du tiketak itxi aurretik.