Kāpēc SQL Server caur VPN joprojām atkrīt uz NTLM?

Jūsu savienojums darbojas, pieteikšanās tiek pieņemta, un SQL Server izmanto NTLM, kamēr visi gaidīja Kerberos. Šis rezultāts nav VPN defekts, jo tunelis nodrošina tikai ceļu; shēmu noteica klienta pieprasītais nosaukums, direktorijā reģistrētais galvenais subjekts un biļete, ko klients faktiski varēja iegūt. Trim nosacījumiem jāizpildās vienlaikus, un sesija pati pasaka, kurš piekāpās. Izlasiet to, pirms kāds rediģē pakalpojuma galveno nosaukumu.

Sesija nosauc shēmu, ko jūs faktiski saņēmāt

Autentifikācijas shēma pieder savienojumam, nevis serverim vai tunelim, tāpēc pārbaude jāveic sesijā, kas jūs interesē. Izpildiet zemāk esošo vaicājumu no tā paša klienta, rīka un konta, kas sagatavoja ziņojumu, un blakus rezultātam pierakstiet mērķa nosaukumu un transportu.

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

Rinda no lokāla SSMS loga datubāzes resursdatorā apraksta pavisam citu savienojumu, tāpēc vaicājums jāizpilda klienta pusē. Saglabājiet izvadi ar laika zīmi, jo nākamais lasītājs jautās, kad tā iegūta. Ja vairākas lietotnes koplieto vienu galapunktu, paņemiet paraugu no katras, jo datu avota atšķirība starp divām lietotnēm bieži ir viss stāsts.

Pirmais nosacījums: vai nosaukums atbilst SPN?

Kerberos autentificē nosauktu pakalpojumu, tāpēc klients direktorijam pieprasa biļeti vienam konkrētam galvenajam subjektam. TCP pakalpojumu sniedzējam dokumentētā forma ir MSSQLSvc/, kam seko pilnībā kvalificēts resursdatora nosaukums un noklusējuma instancē arī ports. Nosaukta instance reģistrē MSSQLSvc/db01.corp.example:SQLPROD, kur sufikss ir instances nosaukums skaitļa vietā. Sasniegt klausītāju ar aizstājvārdu, CNAME, kas atrisinās citur, vai kailu IP adresi maina pieprasīto nosaukumu, un pieprasījumam bez atbilstoša galvenā subjekta nav biļetes, ko atgriezt.

Tāpēc viena lietotne darbojas vienā tīklā un pārslēdzas citā: DNS atbilde, aizstājvārda ieraksts vai hosts ieraksts mainīja nosaukumu, ko izmantoja klients. Salīdziniet pieprasīto nosaukumu ar to, kas ir direktorijā, pirms aiztikt reģistrāciju.

Otrais nosacījums: vai SPN ir pareizajā kontā?

SPN jāpieder kontam, kas izpilda SQL pakalpojumu, nevis klienta kontam un nevis nejauši datora objektam. SQL Server var reģistrēt savus SPN palaišanas laikā, ja tā pakalpojuma kontam ir atļauja tos rakstīt, kas ir ērti un arī izskaidro, kā pēc pakalpojuma konta maiņas parādās dublikāts.

Pajautājiet direktorijam par gaidīto nosaukumu, pēc tam uzskaitiet, ko konts faktiski pārvalda. Kurš objekts tur ierakstu, ir svarīgāk par to, vai nosaukums kaut kur mežā pastāv. Neatbilstība nozīmē, ka pieteikšanās nekad nav bijusi problēma, un Microsoft SPN rokasgrāmata dokumentē formātus un gadījumus, kad domēna administratoram ieraksts ir jāizveido.

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

Vēl viena ieraksta pievienošana nav drošs eksperiments. Dublikāts vai pretrunīga reģistrācija var salauzt klientus, kas darbojās, tāpēc pirms izmaiņām pārbaudiet īpašumtiesības un pēc tam vēlreiz.

Trešais nosacījums: vai klients vispār var iegūt biļeti?

Pareizs SPN ir bezjēdzīgs, ja klients nevar sasniegt domēna kontrolieri vai tam nav izmantojama akreditācijas datu konteksta. Apmaiņai caur VPN vajag KDC un DNS, un tunelis, kas maršrutē tikai SQL portu, cieš neveiksmi tieši šajā solī. Sasniedzamība jāpārbauda no tās pašas mašīnas un tā paša konta, nevis no ugunsmūra viņu priekšā.

Pārbaudiet biļešu kešatmiņu mašīnā un zem konta, kas izpilda lietotni. Mašīnas līmeņa saraksts no paaugstināta loga neko nepasaka par pakalpojumu, kas darbojas kā cits lietotājs, un tukša kešatmiņa šim lietotājam ir atradums, nevis neērtība.

klist
klist -li 0x3e7

Pēc tam izlemiet, ko atkāpšanās drīkst darīt. Ja politika prasa Kerberos, NTLM ir skaidri jānoraida, jo klusa atkāpšanās pārvērš konfigurācijas kļūdu darbīgā savienojumā, kas pārkāpj prasību. Ja NTLM dažām lietotnēm paliek pieņemams, nosauciet tās un pārtrauciet katru NTLM sesiju uzskatīt par incidentu.

Startētāja maiņa ir viens mainīgais, nevis labojums

SSMS palaišana ar citiem akreditācijas datiem var izārstēt nevēlamu izejošo identitāti, kas ir reāla problēmu klase. Tas neko nepierāda par mērķa nosaukumu, reģistrāciju vai biļetes ceļu un nemaina to, ko serveris pieņēma.

Saglabājiet salīdzinājumu kontrolētu: tas pats galapunkts, tas pats pakalpojumu sniedzējs, zināms izpildes konteksts, tad jauns savienojums, kura shēmu pārbaudāt. Apstipriniet pieņemto pieteikšanos un tās datubāzes atļaujas atsevišķi, jo piekļuve un autentifikācija cieš neveiksmi dažādu iemeslu dēļ.

Kad Kerberos ir obligāts, pierakstiet, kāpēc pirmais ceļš piekāpās, piemērojiet vienu labojumu un izpildiet vaicājumu vēlreiz no tā paša klienta. Veiksmīgs vaicājums pēc startētāja maiņas ir piekļuves pierādījums, un tas vēl nav pierādījums, ka autentifikācijas prasība ir izpildīta.