Zergatik erortzen da SQL Server VPN baten bidez NTLM-ra oraindik?

Zure konexioa funtzionatzen ari da, saioa onartzen da eta SQL Serverrek NTLM erabiltzen du denek Kerberos espero zutenean. Emaitza hori ez da VPNaren akatsa, tunel batek bide bat soilik ematen duelako; eskema bezeroak eskatu zuen izenak, direktorioan erregistratutako principalak eta bezeroak benetan lortu zuen txartelak erabaki zuten. Hiru baldintzak aldi berean bete behar dira, eta sesioak berak esaten du zein amore eman zuen. Irakurri hori inork zerbitzu-principal izen bat editatu aurretik.

Sesioak benetan lortu duzun eskema izendatzen du

Autentifikazio-eskema konexio bati dagokio, ez zerbitzari edo tunel bati, beraz egiaztapena axola zaizun sesioaren barruan exekutatu behar da. Exekutatu beheko kontsulta txostena sortu zuten bezero, tresna eta kontu beretik, eta idatzi helburu-izena eta garraioa emaitzaren ondoan.

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

Datu-basearen ostalarian SSMS leiho lokal bateko errenkada batek erabat desberdina den konexio bat deskribatzen du, eta horregatik kontsulta bezeroaren aldetik exekutatu behar da. Gorde irteera denbora-markarekin, irakurriko duen hurrengo pertsonak noiz hartu zen galdetuko baitu. Hainbat aplikaziok mutur berdin bat partekatzen dutenean, hartu lagin bat bakoitzetik, bi aplikazioren arteko datu-iturri desberdintasunak sarritan istorio osoa baita.

Lehen baldintza: bat dator izena SPNarekin?

Kerberosek izendatutako zerbitzu bat autentifikatzen du, beraz bezeroak direktorioari txartel bat eskatzen dio principal zehatz baterako. TCP hornitzailearentzat dokumentatutako forma MSSQLSvc/ da, eta ondoren ostalari-izen erabat kualifikatua eta, instantzia lehenetsi baterako, portua. Instantzia izendatuak MSSQLSvc/db01.corp.example:SQLPROD erregistratzen du, non atzizkiak zenbaki baten ordez instantziaren izena den. Entzulearengana alias baten, beste nonbait ebazten den CNAME baten edo IP helbide biluzi baten bidez iristeak eskatutako izena aldatzen du, eta principal egokirik ez duen eskaerak ez du itzultzeko txartelik.

Horregatik funtzionatzen du aplikazio batek sare batean eta beste batean atzera egiten du: DNS erantzun batek, alias erregistro batek edo hosts sarrera batek bezeroak erabilitako izena aldatu zuten. Konparatu eskatutako izena direktorioak duenarekin erregistroa ukitu aurretik.

Bigarren baldintza: SPNa kontu egokian dago?

SPN batek SQL zerbitzua exekutatzen duen kontuari pertenezu behar dio, ez bezeroaren kontuari eta ez, ustekabean, ordenagailu-objektu bati. SQL Serverrek bere SPNak abiaraztean erregistra ditzake bere zerbitzu-kontuak horiek idazteko baimena duenean, eta hori erosoa da eta zerbitzu-kontua aldatu ondoren nola agertzen den bikoiztu bat ere azaltzen du.

Galdetu direktorioari espero duzun izena, eta gero zerrendatu kontuak benetan duena. Zein objektuk duen sarrera garrantzitsuagoa da izena basoan nonbait badagoen baino. Desadostasunak esan nahi du saioa ez zela inoiz arazoa izan, eta Microsoften SPN gidak formatuak eta domeinu-administratzaile batek sarrera sortu behar dituen kasuak dokumentatzen ditu.

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

Beste sarrera bat gehitzea ez da esperimentu segurua. Bikoiztu edo gatazkatsua den erregistro batek funtzionatzen zuten bezeroak hauts ditzake, beraz aztertu jabetza aldaketaren aurretik eta egiaztatu berriro ondoren.

Hirugarren baldintza: lor dezake bezeroak txartel bat?

SPN zuzen bat alferrikakoa da bezeroak domeinu-kontroladore batera iristen ez bada edo erabil dezakeen kredentzialen testuingururik ez badu. Trukeak KDC eta DNS behar ditu VPNaren bidez, eta SQL portua soilik bideratzen duen tunel batek huts egiten du urrats honetan bertan. Irisgarritasuna makinaren eta kontu beretik probatu behar da, ez haien aurrean dagoen suebakitik.

Aztertu txartel katxea makinan eta aplikazioa exekutatzen duen kontuaren pean. Baimen altuko leiho batetik lortutako makina osoko zerrendak ez dio ezer esaten beste erabiltzaile gisa exekutatzen den zerbitzu bati, eta erabiltzaile horrentzako katxea hutsa izatea aurkikuntza da, ez eragozpena.

klist
klist -li 0x3e7

Gero erabaki zer egin dezakeen atzerako bideak. Politikek Kerberos eskatzen badute, NTLM modu esplizituan ukatu behar da, isilpeko atzerapenak konfigurazio-errore bat baldintza hausten duen konexio funtzional bihurtzen baitu. NTLM aplikazio batzuentzat onargarria bada, izenda itzazu eta utzi NTLM saio bakoitza gorabehera gisa tratatzeari.

Abiarazlea aldatzea aldagai bat da, ez konponbidea

SSMS beste kredentzial batekin abiarazteak nahi gabeko irteerako identitatea senda dezake, eta hori benetako arazo-mota bat da. Ez du ezer frogatzen helburu-izenari, erregistroari edo txartelaren bideari buruz, eta ez du aldatzen zerbitzariak onartu zuena.

Mantendu konparaketa kontrolatuta: mutur bera, hornitzaile bera, exekuzio-testuinguru ezagun bat, eta gero zuk aztertzen duzun eskema duen konexio berri bat. Berretsi onartutako saioa eta haren datu-base baimenak bereizita, sarbideak eta autentifikazioak arrazoi desberdinengatik huts egiten baitute.

Kerberos beharrezkoa denean, idatzi lehen bidea zergatik erori zen, aplikatu konponketa bat eta exekutatu berriro kontsulta bezero beretik. Abiarazlea aldatu ondorengo kontsulta arrakastatsua sarbidearen froga da, eta oraindik ez da autentifikazio-baldintza bete zela frogatzen duen froga.