Kodėl SQL Server per VPN vis tiek pasirenka NTLM?

Jūsų ryšys veikia, prisijungimas priimamas, o SQL Server naudoja NTLM, nors visi tikėjosi Kerberos. Šis rezultatas nėra VPN defektas, nes tunelis tiekia tik kelią; schemą nulėmė kliento paprašytas pavadinimas, kataloge užregistruotas pagrindinis subjektas ir bilietas, kurį klientas iš tikrųjų galėjo gauti. Trys sąlygos turi galioti vienu metu, o sesija pati pasako, kuri nusileido. Perskaitykite tai prieš kam nors keičiant paslaugos pagrindinį pavadinimą.

Sesija įvardija schemą, kurią iš tikrųjų gavote

Autentifikavimo schema priklauso ryšiui, o ne serveriui ar tuneliui, todėl patikra turi būti atliekama sesijoje, kuri jus domina. Vykdykite žemiau pateiktą užklausą iš to paties kliento, įrankio ir paskyros, kurie sukūrė ataskaitą, ir šalia rezultato užrašykite tikslo pavadinimą bei transportą.

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

Eilutė iš vietinio SSMS lango duomenų bazės hoste apibūdina visiškai kitą ryšį, todėl užklausa turi būti vykdoma kliento pusėje. Išsaugokite išvestį su laiko žyma, nes kitas ją skaitysiantis žmogus paklaus, kada ji buvo paimta. Kai kelių programų bendrai naudojamas vienas galinis taškas, paimkite pavyzdį iš kiekvienos, nes dviejų programų duomenų šaltinio skirtumas dažnai yra visa istorija.

Pirmoji sąlyga: ar pavadinimas atitinka SPN?

Kerberos autentifikuoja pavadintą paslaugą, todėl klientas katalogo prašo bilieto vienam konkrečiam pagrindiniam subjektui. TCP teikėjui dokumentuota forma yra MSSQLSvc/, po kurios eina visiškai kvalifikuotas pagrindinio kompiuterio vardas, o numatytajai instancijai – prievadas. Pavadinta instancija registruoja MSSQLSvc/db01.corp.example:SQLPROD, kur priesaga yra instancijos pavadinimas, o ne skaičius. Pasiekti klausytoją per pseudonimą, kitur sprendžiamą CNAME ar pliką IP adresą pakeičia prašomą pavadinimą, o užklausa be atitinkančio pagrindinio subjekto neturi bilieto, kurį galėtų grąžinti.

Štai kodėl viena programa veikia viename tinkle, o kitame persijungia: DNS atsakymas, pseudonimo įrašas ar hosts įrašas pakeitė pavadinimą, kurį naudojo klientas. Palyginkite prašomą pavadinimą su tuo, ką turi katalogas, prieš liesdami registraciją.

Antroji sąlyga: ar SPN yra tinkamoje paskyroje?

SPN turi priklausyti paskyrai, kuri vykdo SQL paslaugą, o ne kliento paskyrai ir ne atsitiktinai kompiuterio objektui. SQL Server gali užregistruoti savo SPN paleidimo metu, kai jo paslaugos paskyra turi teisę juos rašyti, o tai patogu ir taip pat paaiškina, kaip po paslaugos paskyros pakeitimo atsiranda dublikatas.

Paklauskite katalogo apie tikėtiną pavadinimą, tada išvardykite, ką paskyra iš tikrųjų valdo. Kuris objektas laiko įrašą, svarbiau nei tai, ar pavadinimas egzistuoja kur nors miške. Neatitikimas reiškia, kad prisijungimas niekada nebuvo problema, o Microsoft SPN vadove dokumentuojami formatai ir atvejai, kai domeno administratorius turi sukurti įrašą.

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

Pridėti dar vieną įrašą nėra saugus eksperimentas. Dublikatas ar prieštaringa registracija gali sugadinti veikusius klientus, todėl prieš pakeitimą patikrinkite nuosavybę, o po jo patikrinkite dar kartą.

Trečioji sąlyga: ar klientas apskritai gali gauti bilietą?

Tinkamas SPN yra bevertis, jei klientas negali pasiekti domeno valdiklio arba neturi tinkamo naudoti kredencialų konteksto. Mainams per VPN reikia KDC ir DNS, o tunelis, maršrutizuojantis tik SQL prievadą, žlunga būtent šiame žingsnyje. Pasiekiamumą reikia tikrinti iš to paties kompiuterio ir tos pačios paskyros, o ne iš priešais esančios užkardos.

Patikrinkite bilietų podėlį kompiuteryje ir paskyroje, kuri vykdo programą. Viso kompiuterio sąrašas iš padidintų teisių lango nieko nesako apie paslaugą, veikiančią kitu naudotoju, o tuščias to naudotojo podėlis yra radinys, o ne nepatogumas.

klist
klist -li 0x3e7

Tada nuspręskite, ką gali daryti atsarginis kelias. Jei politika reikalauja Kerberos, NTLM turi būti aiškiai atmetamas, nes tylus atsarginis kelias konfigūracijos klaidą paverčia veikiančiu ryšiu, kuris pažeidžia reikalavimą. Jei NTLM kai kurioms programoms lieka priimtinas, įvardykite jas ir nustokite kiekvieną NTLM sesiją laikyti incidentu.

Paleidėjo keitimas yra vienas kintamasis, o ne pataisa

SSMS paleidimas su kitais kredencialais gali išgydyti netyčinę išeinančią tapatybę, o tai yra tikra problemų klasė. Tai nieko neįrodo apie tikslo pavadinimą, registraciją ar bilieto kelią ir nekeičia to, ką serveris priėmė.

Išlaikykite palyginimą kontroliuojamą: tas pats galinis taškas, tas pats teikėjas, žinomas vykdymo kontekstas, tada naujas ryšys, kurio schemą tikrinate. Patvirtinkite priimtą prisijungimą ir jo duomenų bazės teises atskirai, nes prieiga ir autentifikavimas žlunga dėl skirtingų priežasčių.

Kai reikalaujama Kerberos, užrašykite, kodėl pirmasis kelias nusileido, pritaikykite vieną pataisą ir iš naujo paleiskite užklausą iš to paties kliento. Sėkminga užklausa po paleidėjo pakeitimo yra prieigos įrodymas ir dar nėra įrodymas, kad autentifikavimo reikalavimas buvo įvykdytas.