Zašto SQL Server preko VPN-a i dalje pada na NTLM?

Vaša veza radi, prijava je prihvaćena, a SQL Server koristi NTLM dok su svi očekivali Kerberos. Taj ishod nije VPN defekt, jer tunel samo daje put; šemu su odredili naziv koji je klijent tražio, principal registrovan u direktoriju i tiket koji je klijent zaista mogao dobiti. Tri uslova moraju vrijediti istovremeno, a sama sesija kaže koji je popustio. Pročitajte to prije nego što bilo ko izmijeni naziv servisnog principala.

Sesija imenuje šemu koju ste zaista dobili

Šema provjere identiteta pripada vezi, a ne serveru ili tunelu, pa se provjera mora izvršiti unutar sesije koja vas zanima. Izvršite upit ispod sa istog klijenta, alata i računa koji su proizveli izvještaj, i zabilježite naziv cilja i transport pored rezultata.

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

Red iz lokalnog SSMS prozora na hostu baze podataka opisuje potpuno drugu vezu, zbog čega se upit mora izvršiti sa klijentske strane. Sačuvajte izlaz sa vremenskom oznakom, jer će sljedeća osoba koja ga pročita pitati kada je snimljen. Kada više aplikacija dijeli jednu krajnju tačku, uzmite uzorak iz svake, jer je razlika u izvoru podataka između dvije aplikacije često cijela priča.

Prvi uslov: da li se naziv poklapa sa SPN-om?

Kerberos autentificira imenovanu uslugu, pa klijent traži od direktorija tiket za jedan konkretan principal. Za TCP provajdera dokumentovani oblik je MSSQLSvc/ nakon čega slijedi potpuno kvalificirani naziv hosta i, za zadanu instancu, port. Imenovana instanca registruje MSSQLSvc/db01.corp.example:SQLPROD, gdje je sufiks naziv instance umjesto broja. Dolazak do listenera preko aliasa, CNAME-a koji se razrješava negdje drugo ili golog IP-a mijenja traženi naziv, a zahtjev bez odgovarajućeg principala nema tiket koji bi vratio.

Zato jedna aplikacija radi na jednoj mreži, a na drugoj pada na rezervu: DNS odgovor, alias zapis ili hosts unos promijenili su naziv koji je klijent koristio. Uporedite traženi naziv sa onim što direktorij sadrži prije nego što dirnete registraciju.

Drugi uslov: da li je SPN na pravom računu?

SPN mora pripadati računu koji pokreće SQL uslugu, ne klijentskom računu i ne slučajno kompjuterskom objektu. SQL Server može registrovati vlastite SPN-ove pri pokretanju kada njegov servisni račun ima dozvolu da ih piše, što je zgodno i objašnjava kako se duplikat pojavi nakon promjene servisnog računa.

Pitajte direktorij za naziv koji očekujete, zatim navedite šta račun zapravo posjeduje. Koji objekat drži unos važnije je od toga postoji li naziv negdje u šumi. Neusklađenost znači da prijava nikada nije bila problem, a Microsoftov vodič za SPN dokumentuje formate i slučajeve u kojima administrator domena mora kreirati unos.

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

Dodavanje još jednog unosa nije siguran eksperiment. Duplikat ili konfliktna registracija može pokvariti klijente koji su radili, pa pregledajte vlasništvo prije promjene i ponovo ga provjerite nakon nje.

Treći uslov: može li klijent uopšte dobiti tiket?

Ispravan SPN je beskoristan ako klijent ne može doći do kontrolera domena ili nema upotrebljiv kontekst vjerodajnica. Razmjena zahtijeva KDC i DNS kroz VPN, a tunel koji rutira samo SQL port pada upravo na ovom koraku. Dostupnost se mora testirati sa iste mašine i istog računa, ne sa firewall-a ispred njih.

Pregledajte keš tiketa na mašini i pod računom koji pokreće aplikaciju. Lista na nivou cijele mašine iz podignutog prozora ne govori ništa o usluzi koja radi kao drugi korisnik, a prazan keš za tog korisnika je nalaz, a ne neugodnost.

klist
klist -li 0x3e7

Zatim odlučite šta rezerva smije da radi. Ako politika zahtijeva Kerberos, NTLM se mora izričito odbiti, jer tiha rezerva pretvara grešku u konfiguraciji u radnu vezu koja krši zahtjev. Ako NTLM ostaje prihvatljiv za neke aplikacije, imenujte ih i prestanite svaku NTLM sesiju tretirati kao incident.

Promjena pokretača je jedna varijabla, a ne popravka

Pokretanje SSMS-a pod drugim vjerodajnicama može izliječiti neželjeni odlazni identitet, što je stvarna klasa problema. To ništa ne dokazuje o nazivu cilja, registraciji ili putanji tiketa i ne mijenja ono što je server prihvatio.

Držite poređenje kontrolisanim: ista krajnja tačka, isti provajder, poznat kontekst izvršavanja, zatim nova veza čiju šemu pregledate. Potvrdite prihvaćenu prijavu i njene dozvole na bazi odvojeno, jer pristup i autentifikacija padaju iz različitih razloga.

Kada je Kerberos obavezan, zabilježite zašto je prvi put pao na rezervu, primijenite jednu ispravku i ponovo izvršite upit sa istog klijenta. Uspješan upit nakon promjene pokretača dokaz je pristupa i još nije dokaz da je zahtjev za autentifikacijom ispunjen.