Miks langeb SQL Server VPN-i kaudu ikkagi NTLM-ile tagasi?

Kerberos vajab õiget teenuse nime, õigel kontol olevat SPN-i ja piletit, mille klient saab hankida. Lugege auth_scheme'i enne, kui midagi muudate.

Teie ühendus töötab, sisselogimine võetakse vastu ja SQL Server kasutab NTLM-i, samal ajal kui kõik ootasid Kerberost. See tulemus ei ole VPN-i defekt, sest tunnel annab ainult tee; skeemi määrasid nimi, mille klient küsis, kataloogi registreeritud põhiobjekt ja pilet, mille klient tegelikult sai hankida. Kolm tingimust peavad kehtima korraga ja sessioon ise ütleb, milline järele andis. Lugege seda enne, kui keegi muudab teenuse põhiobjekti nime.

Sessioon nimetab skeemi, mille te tegelikult saite

Autentimisskeem kuulub ühendusele, mitte serverile ega tunnelile, seega peab kontroll jooksma sessiooni sees, mis teid huvitab. Käivitage allolev päring samast kliendist, tööriistast ja kontolt, mis aruande koostasid, ning märkige sihtnimi ja transport tulemuse kõrvale.

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

Rida kohalikust SSMS-aknast andmebaasi hostis kirjeldab hoopis teist ühendust, mistõttu peab päring jooksma kliendi poolelt. Salvestage väljund ajatempliga, sest järgmine inimene, kes seda loeb, küsib, millal see võeti. Kui mitu rakendust jagavad ühte lõpp-punkti, võtke proov igast, sest andmeallika erinevus kahe rakenduse vahel on sageli kogu lugu.

Esimene tingimus: kas nimi vastab SPN-ile?

Kerberos autendib nimetatud teenust, seega küsib klient kataloogist piletit ühe konkreetse põhiobjekti jaoks. TCP-pakkuja jaoks on dokumenteeritud vorm MSSQLSvc/, millele järgneb täielikult kvalifitseeritud hostinimi ja vaikeinstantsi puhul port. Nimetatud instants registreerib MSSQLSvc/db01.corp.example:SQLPROD, kus järelliide on numbri asemel instantsi nimi. Kuulaja poole jõudmine aliase, mujal lahenduva CNAME-i või palja IP-aadressi kaudu muudab küsitud nime ja vastava põhiobjektita päringul ei ole tagastatavat piletit.

Sellepärast töötab üks rakendus ühes võrgus ja langeb teises tagasi: DNS-vastus, alias-kirje või hosts-kirje muutsid nime, mida klient kasutas. Võrrelge küsitud nime sellega, mida kataloog sisaldab, enne kui registreerimist puudutate.

Teine tingimus: kas SPN on õigel kontol?

SPN peab kuuluma kontole, mis käitab SQL-i teenust, mitte kliendi kontole ja mitte kogemata arvutiobjektile. SQL Server saab käivitamisel registreerida oma SPN-id, kui selle teenusekontol on nende kirjutamise luba, mis on mugav ja selgitab ka seda, kuidas teenusekonto muutmise järel tekib duplikaat.

Pärige kataloogist nime, mida ootate, seejärel loetlege, mida konto tegelikult omab. Milline objekt kirjet hoiab, on tähtsam kui see, kas nimi kuskil metsas eksisteerib. Erinevus tähendab, et sisselogimine ei olnud kunagi probleem, ja Microsofti SPN-i juhend dokumenteerib vormingud ja juhtumid, kus domeeniadministraator peab kirje looma.

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

Veel ühe kirje lisamine ei ole ohutu katse. Duplikaat või vastuoluline registreering võib lõhkuda kliente, mis töötasid, seega uurige omandit enne muudatust ja kontrollige seda pärast uuesti.

Kolmas tingimus: kas klient saab üldse pileti?

Õige SPN on kasutu, kui klient ei saa domeenikontrollerini jõuda või tal puudub kasutatav mandaadikontekst. Vahetus vajab KDC-d ja DNS-i läbi VPN-i ning tunnel, mis marsruudib ainult SQL-i pordi, ebaõnnestub täpselt sellel etapil. Kättesaadavust tuleb testida samast masinast ja samalt kontolt, mitte nende ees olevast tulemüürist.

Uurige piletivahemälu masinas ja selle konto all, mis rakendust käitab. Kõrgendatud aknast saadud masinapõhine nimekiri ei ütle midagi teenuse kohta, mis töötab teise kasutajana, ja selle kasutaja tühi vahemälu on leid, mitte ebamugavus.

klist
klist -li 0x3e7

Seejärel otsustage, mida tagasilangus tohib teha. Kui poliitika nõuab Kerberost, tuleb NTLM selgesõnaliselt tagasi lükata, sest vaikne tagasilangus muudab konfiguratsioonivea töötavaks ühenduseks, mis rikub nõuet. Kui NTLM jääb mõne rakenduse jaoks vastuvõetavaks, nimetage need ja lõpetage iga NTLM-sessiooni käsitlemine intsidendina.

Käivitaja muutmine on üks muutuja, mitte parandus

SSMS-i käivitamine teise mandaadiga võib ravida soovimatu väljuva identiteedi, mis on tõeline probleemide klass. See ei tõesta midagi sihtnime, registreerimise ega pileti tee kohta ega muuda seda, mida server vastu võttis.

Hoidke võrdlus kontrolli all: sama lõpp-punkt, sama pakkuja, teadaolev täitmiskontekst, seejärel värske ühendus, mille skeemi uurite. Kinnitage vastuvõetud sisselogimine ja selle andmebaasiõigused eraldi, sest juurdepääs ja autentimine ebaõnnestuvad erinevatel põhjustel.

Kui Kerberos on nõutud, kirjutage üles, miks esimene tee tagasi langes, rakendage üks parandus ja käivitage päring uuesti samast kliendist. Edukas päring pärast käivitaja muutmist on tõend juurdepääsu kohta ja veel mitte tõend selle kohta, et autentimisnõue oli täidetud.

Seotud artiklid