VPN ühendub, kuid SQL Server lükkab Windowsi autentimise tagasi

Tunnelid tõusevad, serverid vastavad pingile ja andmebaasi sisselogimine ebaõnnestub ikka autentimisveaga. See kombinatsioon on VPN-i ühendustel tavaline ja tähendab harva, et võrk on katki, sest kättesaadav kuulaja ja vastuvõetud sisselogimine on kaks erinevat tulemust. Identiteet, mis lüüsi rahuldas, ei ole tingimata identiteet, mida andmebaasiklient pakub. Välja selgitada, milline konto kohale jõudis, ongi kogu ülesanne.

Sümptom: kättesaadav server, tagasilükatud sisselogimine

Aegumine ütleb, et pakett ei jõudnud kunagi kuulajani. Autentimisviga ütleb, et kuulaja vastas ja lükkas volitused tagasi. Need kaks sõnumit saadavad teid eri meeskondade juurde ja nende segamini ajamine raiskab päeva tulemüürireeglitele, mis ei olnud kunagi probleem.

Kui viga on ebaõnnestunud sisselogimine, lõpetage portide vaatamine. Järele jääb küsimus, millise Windowsi identiteedi klient esitas, kas server selle identiteedi vastu võttis ja kas see lahenes andmebaasikasutajaks, kellel on luba.

Kaks identiteeti, üks tunnel

VPN-i konto autendib end lüüsis ja enamikus juurutustes lõpeb sellega. Andmebaasiklient esitab eraldi Windowsi märgise, mis on võetud protsessist, mis teda käivitab, või SQL-i sisselogimise, kui ühendusstring seda nõuab. Lüüsi kohalikul VPN-i kasutajal pole mingit seost domeeniga, mis majutab SQL Serverit, ja tunnel ei loo seda.

Isikliku masina VPN-iga ühendamine ei liida seda ka domeeniga. Kohaliku konto ümbernimetamine ja selle parooli domeeni kasutajaga kohandamine ei ole liitumisprotseduur ja tekitab märgise, mida domeenikontroller selle kasutajana vastu ei võta.

Mõned Windowsi omased kaugjuurdepääsukliendid saavad VPN-i volitusi võrguressursside jaoks uuesti kasutada, kui nende profiil on nii seadistatud. See käitumine kuulub kindlale kliendile ja profiilile, mitte VPN-i ühendustele üldiselt, seega kontrollige seda kasutatava kliendi puhul, selle asemel et seda eeldada.

Lugege režiimi, mida klient küsis

Ühendusstring otsustab, millise autentimistee klient valib. Integreeritud turvalisus kasutab Windowsi märgist; kasutaja ja parooli paar valib SQL-i sisselogimise. Need on serveri seadistuses eraldi režiimid ja antud ühenduskatse jaoks saab lubada ainult ühte neist.

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

Üleminek SQL-i sisselogimisele seetõttu, et Windowsi sisselogimine ebaõnnestus, on ajutine lahendus, mis peidab identiteediküsimuse, ja tavaliselt nõuab see ikkagi uue sisselogimise ja parooli loomist. Kui juurutus nõuab Windowsi autentimist, jätke režiim alles ja parandage identiteeditee. SQL-i sisselogimine vajab ka oma õigusi, nii et ajutine lahendus ostab teise konto, mida hooldada.

Kinnitage ka, milline rakendus ühendub. Süsteemikontona töötav teenus, ajastatud ülesanne ja interaktiivne päringuaken võivad samas masinas esitada kolm erinevat märgist ja ainult viimane vastab sellele, mida kasutaja näeb, kui ta käivitab whoami.

Küsige serverilt, mida see tegelikult nägi

Server oskab öelda, millise sisselogimise see lahendas ja kuidas ühendus autentis. Käivitage päring uuritava sessiooni sees, sest administraatori eraldi õnnestunud ühendus ei tõesta ebaõnnestuva kliendi kohta midagi.

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;

Esimene rida eristab sisselogimise, mis sessiooni avas, praegu kehtivast turbekontekstist, ja need erinevad kehastamise korral. Teine nimetab autentimisskeemi, nii et KERBEROS, NTLM ja SQL muutuvad nähtavateks faktideks, mitte oletusteks. Ühendus, mis teatab NTLM-ist seal, kus ootasite Kerberost, on nime lahendamise või SPN-i probleem, mitte parooli probleem.

Veakood kitsendab seda veelgi. Olek 5 tähendab tavaliselt, et sisselogimisnime ei lahendatud üldse, olek 8 tähendab tavaliselt, et parool ei sobitunud, ja olek 11 tähendab, et volitused võeti vastu, kuid serverile juurdepääs ebaõnnestus. Küsige administraatorilt olekut, mitte tervet sõnumit, sest sõnum ise on meelega ebamäärane.

Kui identiteet saabub ja Kerberos ikka ebaõnnestub

Kui server näeb kavandatud Windowsi identiteeti ja integreeritud autentimine ikka ebaõnnestub, on probleem vahetuses endas. Kerberos vajab SQL-i teenusekonto jaoks registreeritud teenuse põhinime (SPN) ja klienti, kes küsib teenust sellele vastava nimega. IP-aadressi kaudu ühendamine ei saa vastata nimel põhinevale SPN-ile ja alias saab sobida ainult siis, kui see on samuti registreeritud. Kontrollige kõigepealt nime, mille klient sisestas, sest ühendus, mis töötab hostinimega ja ebaõnnestub IP-ga, kirjeldab täpselt seda probleemi.

Paluge administraatoril registreeritud identiteet ja teenusekonto üle vaadata, selle asemel et proovimise teel dubleerivaid SPN-e luua. Dubleeritud registreeringud tekitavad katkendlikke tõrkeid, mida on raskem diagnoosida kui algset probleemi.

Kui autentimine töötab, vajab sisselogimine endiselt andmebaasikasutajat ja õigusi. Õnnestunud VPN-i sisselogimine, õnnestunud Windowsi sisselogimine ja luba lugeda kindlat tabelit on kolm eraldi tulemust ja igaüks neist väärib oma kontrolli enne pileti sulgemist.