VPN lidhet, por SQL Server refuzon vërtetimin Windows

Tunelet ngrihen, serverat përgjigjen ndaj ping, dhe hyrja në bazën e të dhënave vazhdon të dështojë me një gabim vërtetimi. Ky kombinim është i zakonshëm në lidhjet VPN dhe rrallë do të thotë se rrjeti është prishur, sepse një dëgjues i arritshëm dhe një hyrje e pranuar janë dy rezultate të ndryshme. Identiteti që kënaqi portën nuk është domosdoshmërisht identiteti që ofron klienti i bazës së të dhënave. Të zbulosh se cila llogari mbërriti është e gjithë detyra.

Simptoma: server i arritshëm, hyrje e refuzuar

Një afat i skaduar ju thotë se paketa nuk arriti kurrë te një dëgjues. Një gabim vërtetimi ju thotë se dëgjuesi u përgjigj dhe e refuzoi kredencialin. Këto dy mesazhe ju dërgojnë te ekipe të ndryshme, dhe përzierja e tyre harxhon një ditë për rregulla muri të zjarrit që nuk ishin kurrë problemi.

Kur gabimi është një hyrje e dështuar, ndaloni së shikuari portat. Pyetja që mbetet është cili identitet Windows paraqiti klienti, nëse serveri e pranoi atë identitet dhe nëse u zgjidh në një përdorues të bazës së të dhënave me leje.

Dy identitete, një tunel

Llogaria VPN vërtetohet në portë dhe në shumicën e vendosjeve mbaron atje. Klienti i bazës së të dhënave paraqet veçmas një token Windows, marrë nga procesi që e ekzekuton, ose një hyrje SQL nëse vargu i lidhjes kërkon një të tillë. Një përdorues VPN lokal në portë nuk ka asnjë lidhje me domenin që strehon SQL Server, dhe tuneli nuk krijon një të tillë.

Lidhja e një makine personale me një VPN nuk e fut atë në domen gjithashtu. Riemërtimi i një llogarie lokale dhe përputhja e fjalëkalimit të saj me një përdorues domeni nuk është procedurë regjistrimi dhe prodhon një token që kontrolluesi i domenit nuk do ta pranojë si atë përdorues.

Disa klientë vendas të aksesit në distancë të Windows mund të ripërdorin kredencialin VPN për burime rrjeti kur profili i tyre është konfiguruar ashtu. Kjo sjellje i takon një klienti dhe profili të caktuar, jo lidhjeve VPN në përgjithësi, prandaj verifikojeni për klientin në përdorim në vend që ta supozoni.

Lexoni modalitetin që kërkoi klienti

Vargu i lidhjes vendos se cilën rrugë vërtetimi ndjek klienti. Siguria e integruar përdor tokenin Windows; një çift përdoruesi dhe fjalëkalimi zgjedh një hyrje SQL. Këto janë modalitete të veçanta në konfigurimin e serverit, dhe vetëm njëri prej tyre mund të jetë i aktivizuar për një përpjekje të caktuar lidhjeje.

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

Kalimi në një hyrje SQL sepse hyrja Windows dështoi është një zgjidhje e përkohshme që fsheh pyetjen e identitetit, dhe zakonisht kërkon gjithsesi krijimin e një hyrjeje dhe fjalëkalimi të re. Nëse vendosja kërkon vërtetim Windows, mbani modalitetin dhe rregulloni rrugën e identitetit. Hyrja SQL ka nevojë edhe për lejet e veta, kështu që zgjidhja e përkohshme blen një llogari të dytë për t'u mirëmbajtur.

Konfirmoni gjithashtu se cila aplikacion po lidhet. Një shërbim që ekzekutohet si llogari sistemi, një detyrë e planifikuar dhe një dritare interaktive pyetjeje mund të paraqesin tre tokenë të ndryshëm në të njëjtën makinë, dhe vetëm i fundit përputhet me atë që përdoruesi sheh kur ekzekuton whoami.

Pyetni serverin se çfarë pa në të vërtetë

Serveri mund t'ju thotë se cilën hyrje zgjidhi dhe si u vërtetua lidhja. Ekzekutoni pyetjen brenda sesionit që po hetohet, sepse një lidhje e suksesshme e veçantë e administratorit nuk provon asgjë për klientin që dështon.

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;

Rreshti i parë dallon hyrjen që hapi sesionin nga konteksti i sigurisë në fuqi tani, dhe ata ndryshojnë nën personifikim. I dyti emërton skemën e vërtetimit, kështu që KERBEROS, NTLM dhe SQL bëhen fakte të dukshme në vend të supozimeve. Një lidhje që raporton NTLM aty ku prisnit Kerberos është problem zgjidhjeje emrash ose SPN, jo problem fjalëkalimi.

Numri i gabimit e ngushton më tej. Gjendja 5 zakonisht do të thotë se emri i hyrjes nuk u zgjidh fare, gjendja 8 zakonisht do të thotë se fjalëkalimi nuk përputhej, dhe gjendja 11 do të thotë se kredenciali u pranua, por aksesi në server dështoi. Kërkojini administratorit gjendjen në vend të mesazhit të plotë, sepse mesazhi vetëm është qëllimisht i paqartë.

Kur identiteti mbërrin dhe Kerberos vazhdon të dështojë

Nëse serveri sheh identitetin e synuar Windows dhe vërtetimi i integruar vazhdon të dështojë, problemi është vetë shkëmbimi. Kerberos ka nevojë për emrin kryesor të shërbimit të regjistruar për llogarinë e shërbimit SQL dhe një klient që e kërkon shërbimin me një emër që përputhet me të. Lidhja me adresë IP nuk mund të përputhet me një SPN të bazuar në emër, dhe një pseudonim mund të përputhet vetëm nëse është regjistruar gjithashtu. Kontrolloni së pari emrin që shtypi klienti, sepse një lidhje që funksionon me emrin e hostit dhe dështon me IP përshkruan pikërisht këtë problem.

Kërkojini administratorit të rishikojë identitetin e regjistruar dhe llogarinë e shërbimit në vend që të krijojë SPN të dyfishta me provë dhe gabim. Regjistrimet e dyfishta prodhojnë dështime të herëpashershme që janë më të vështira për t'u diagnostikuar sesa problemi origjinal.

Pasi vërtetimi funksionon, hyrja ka ende nevojë për një përdorues të bazës së të dhënave dhe leje. Një hyrje VPN e suksesshme, një hyrje Windows e suksesshme dhe leja për të lexuar një tabelë të caktuar janë tre rezultate të veçanta, dhe secili meriton kontrollin e vet përpara se të mbyllet tiketa.