Zakaj SQL Server prek VPN še vedno pade nazaj na NTLM?

Vaša povezava deluje, prijava je sprejeta in SQL Server uporablja NTLM, medtem ko so vsi pričakovali Kerberos. Ta izid ni napaka VPN, ker tunel zagotavlja le pot; shemo so določili ime, ki ga je zahteval odjemalec, principal, registriran v imeniku, in vstopnica, ki jo je odjemalec dejansko lahko pridobil. Trije pogoji morajo veljati hkrati, seja pa sama pove, kateri je popustil. Preberite to, preden kdo uredi ime glavne storitve.

Seja poimenuje shemo, ki ste jo dejansko dobili

Shema preverjanja pristnosti pripada povezavi, ne strežniku ali tunelu, zato mora preverjanje teči znotraj seje, ki vas zanima. Izvedite spodnjo poizvedbo iz istega odjemalca, orodja in računa, ki so ustvarili poročilo, in ob rezultatu zabeležite ciljno ime ter transport.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Vrstica iz lokalnega okna SSMS na gostitelju zbirke podatkov opisuje povsem drugo povezavo, zato mora poizvedba teči s strani odjemalca. Shranite izhod s časovnim žigom, ker bo naslednja oseba, ki ga bo prebrala, vprašala, kdaj je bil zajet. Ko si več aplikacij deli eno končno točko, vzemite vzorec iz vsake, ker je razlika v viru podatkov med dvema aplikacijama pogosto cela zgodba.

Prvi pogoj: ali se ime ujema s SPN?

Kerberos preverja pristnost imenovane storitve, zato odjemalec od imenika zahteva vstopnico za enega določenega principala. Za ponudnika TCP je dokumentirana oblika MSSQLSvc/, ki ji sledi popolnoma kvalificirano ime gostitelja in za privzeti primerek vrata. Imenovani primerek registrira MSSQLSvc/db01.corp.example:SQLPROD, kjer je pripona ime primerka namesto številke. Dostop do poslušalca prek vzdevka, CNAME, ki se razreši drugje, ali golega naslova IP spremeni zahtevano ime, zahteva brez ustreznega principala pa nima vstopnice za vračilo.

Zato ena aplikacija deluje v enem omrežju, v drugem pa pade nazaj: odgovor DNS, zapis vzdevka ali vnos hosts so spremenili ime, ki ga je uporabil odjemalec. Primerjajte zahtevano ime s tem, kar vsebuje imenik, preden se dotaknete registracije.

Drugi pogoj: je SPN na pravem računu?

SPN mora pripadati računu, ki izvaja storitev SQL, ne računu odjemalca in ne po naključju računalniškemu objektu. SQL Server lahko ob zagonu registrira svoje SPN, ko ima njegov servisni račun dovoljenje, da jih zapiše, kar je priročno in tudi pojasni, kako po spremembi servisnega računa nastane dvojnik.

Imenik vprašajte za ime, ki ga pričakujete, nato naštejte, kaj račun dejansko ima. Kateri objekt hrani vnos, je pomembnejše od tega, ali ime kje v gozdu obstaja. Neujemanje pomeni, da prijava nikoli ni bila težava, in vodnik po SPN podjetja Microsoft dokumentira oblike in primere, ko mora skrbnik domene ustvariti vnos.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Dodajanje še enega vnosa ni varen poskus. Dvojnik ali konfliktna registracija lahko pokvari delujoče odjemalce, zato pred spremembo preglejte lastništvo in ga po njej znova preverite.

Tretji pogoj: lahko odjemalec sploh dobi vstopnico?

Pravilen SPN je neuporaben, če odjemalec ne doseže krmilnika domene ali nima uporabnega konteksta poverilnic. Izmenjava potrebuje KDC in DNS prek VPN, tunel, ki usmerja samo vrata SQL, pa spodleti prav na tem koraku. Dosegljivost je treba preizkusiti z istega računalnika in istega računa, ne z požarnega zidu pred njima.

Preglejte predpomnilnik vstopnic v računalniku in pod računom, ki izvaja aplikacijo. Seznam za celoten računalnik iz povišanega okna ne pove ničesar o storitvi, ki teče kot drug uporabnik, prazen predpomnilnik za tega uporabnika pa je ugotovitev in ne neprijetnost.

klist
klist -li 0x3e7

Nato odločite, kaj sme narediti rezerva. Če politika zahteva Kerberos, je treba NTLM izrecno zavrniti, ker tiha rezerva spremeni konfiguracijsko napako v delujočo povezavo, ki krši zahtevo. Če NTLM ostane sprejemljiv za nekatere aplikacije, jih poimenujte in prenehajte vsako sejo NTLM obravnavati kot incident.

Sprememba zagonskega programa je ena spremenljivka, ne popravek

Zagon SSMS pod drugimi poverilnicami lahko odpravi nenamerno odhodno identiteto, kar je resničen razred težav. Ničesar ne dokazuje o ciljnem imenu, registraciji ali poti vstopnice in ne spremeni tega, kar je strežnik sprejel.

Naj bo primerjava nadzorovana: ista končna točka, isti ponudnik, znan kontekst izvajanja, nato nova povezava, katere shemo pregledate. Ločeno potrdite sprejeto prijavo in njena dovoljenja v zbirki podatkov, ker dostop in preverjanje pristnosti spodletita iz različnih razlogov.

Ko je Kerberos obvezen, zabeležite, zakaj je prva pot popustila, uporabite en popravek in znova izvedite poizvedbo z istega odjemalca. Uspešna poizvedba po spremembi zagonskega programa je dokaz dostopa in še ni dokaz, da je bila zahteva po preverjanju pristnosti izpolnjena.