Firwat fält SQL Server iwwer eng VPN ëmmer nach op NTLM zréck?

Är Verbindung funktionéiert, d’Umeldung gëtt ugeholl, an SQL Server benotzt NTLM während jiddereen Kerberos erwaart huet. Dat Resultat ass keen VPN-Fehler, well en Tunnel just e Wee gëtt; d’Schema hunn den Numm, deen de Client gefrot huet, de Principal, deen am Verzeechnes registréiert ass, an den Ticket entscheed, deen de Client tatsächlech konnt kréien. Dräi Bedéngungen mussen gläichzäiteg gëllen, an d’Sessioun selwer seet, wéi eng noginn huet. Liest dat, ier een den Numm vum Service Principal ännert.

D’Sessioun nennt d’Schema, dat Dir tatsächlech kritt hutt

D’Authentifikatiounsschema gehéiert zu enger Verbindung an net zu engem Server oder Tunnel, dofir muss d’Préifung an der Sessioun lafen, déi Iech interesséiert. Führt d’Ufro hei drënner vum selwechte Client, Tool an Kont aus, déi de Rapport erstallt hunn, an notéiert den Zilnumm an den Transport niewent dem Resultat.

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

Eng Zeil aus engem lokalen SSMS-Fënster um Datebankhost beschreift eng ganz aner Verbindung, dofir muss d’Ufro vun der Clientsäit lafen. Späichert d’Ausgab mat engem Zäitstempel, well déi nächst Persoun, déi se liest, wäert froen, wéini se geholl gouf. Wann e puer Uwendungen en eenzegen Endpunkt deelen, hëlt eng Probe vun all eenzel, well en Ënnerscheed an der Datequell tëscht zwou Uwendungen dacks déi ganz Geschicht ass.

Éischt Bedéngung: passt den Numm zum SPN?

Kerberos authentifizéiert en benannte Service, dofir freet de Client d’Verzeechnes no engem Ticket fir een spezifesche Principal. Fir den TCP-Provider ass déi dokumentéiert Form MSSQLSvc/ gefollegt vum vollqualifizéierten Hostnumm an, fir eng Standardinstanz, vum Port. Eng benannte Instanz registréiert MSSQLSvc/db01.corp.example:SQLPROD, wou den Suffix den Instanznumm amplaz vun enger Nummer ass. De Listener iwwer en Alias, eng CNAME, déi soss ewou opgeléist gëtt, oder eng blouss IP-Adress z’erreechen ännert den ugefrote Numm, an eng Ufro ouni passende Principal huet keen Ticket fir zréckzeginn.

Dofir funktionéiert eng Uwendung an engem Netz a fält an engem aneren zréck: eng DNS-Antwert, en Alias-Record oder en hosts-Antrag huet den Numm geännert, deen de Client benotzt huet. Vergläicht den ugefrote Numm mat deem, wat d’Verzeechnes huet, ier Dir d’Registrierung beréiert.

Zweet Bedéngung: ass de SPN um richtege Kont?

En SPN muss zu deem Kont gehéieren, deen de SQL-Service bedreift, net zum Kont vum Client an net duerch Zoufall zu engem Computerobjekt. SQL Server kann seng eege SPNen beim Start registréieren, wann säi Servicekont d’Erlaabnes huet se ze schreiwen, wat praktesch ass an och erkläert, wéi en Duplikat no enger Ännerung vum Servicekont entsteet.

Frot d’Verzeechnes no dem Numm, deen Dir erwaart, a lëscht dann op, wat de Kont tatsächlech besëtzt. Wéi en Objekt den Antrag hält, ass méi wichteg wéi ob den Numm iergendwou am Bësch existéiert. Eng Divergeenz heescht, datt d’Umeldung ni de Problem war, an de Microsoft SPN-Guide dokumentéiert d’Formater an d’Fäll, wou en Domainadministrator den Antrag muss erstellen.

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

En aneren Antrag bäizefügen ass keen sécheren Experiment. En Duplikat oder eng konfliktal Registrierung kann Clients briechen, déi funktionéiert hunn, dofir inspectéiert d’Eegentum virun der Ännerung a kontrolléiert et duerno nach eng Kéier.

Drëtt Bedéngung: kann de Client iwwerhaapt en Ticket kréien?

En korrekte SPN ass nëtzlos, wann de Client keen Domaincontroller erreecht oder kee brauchbare Umeldungsinformatiounskontext huet. Den Austausch brauch de KDC an DNS iwwer d’VPN, an en Tunnel, deen nëmmen de SQL-Port routet, fält genee bei dësem Schrëtt. D’Erreechbarkeet muss vun der selwechter Maschinn an dem selwechte Kont getest ginn, net vun der Firewall virun hinnen.

Inspectéiert de Ticketcache op der Maschinn a vum Kont aus, deen d’Uwendung bedreift. Eng maschinnwäit Lëscht aus engem erhéichtem Fënster seet näischt iwwer e Service, deen als aneren Benotzer leeft, an e leere Cache fir dee Benotzer ass eng Entdeckung an net eng Onbequemlechkeet.

klist
klist -li 0x3e7

Duerno entscheet, wat en Zréckfall däerf maachen. Wann d’Politik Kerberos verlaangt, muss NTLM ausdrécklech ofgeleent ginn, well en stille Zréckfall e Konfiguratiounsfehler an eng funktionéierend Verbindung verwandelt, déi d’Ufuerderung verletzt. Wann NTLM fir e puer Uwendungen akzeptabel bleift, nennt se a stoppt domat, all NTLM-Sessioun als Tëschefall ze behandelen.

De Starter z’ännere ass eng Variabel, keng Léisung

SSMS ënner enger anerer Umeldung ze starten kann eng ongewollt erausgänglech Identitéit heelen, wat eng richteg Problemklass ass. Et beweet näischt iwwer den Zilnumm, d’Registrierung oder den Ticketwee, an et ännert net, wat de Server ugeholl huet.

Hält de Verglach kontrolléiert: selwen Endpunkt, selwe Provider, en bekannten Ausféierungskontext, duerno eng frësch Verbindung, deem seng Schema Dir inspectéiert. Bestätegt d’ugehollen Umeldung an hir Datebankberechtegungen getrennt, well Zougang an Authentifikatioun aus verschiddene Grënn feelen.

Wann Kerberos erfuerderlech ass, notéiert firwat deen éischte Wee zréckgefall ass, wendt eng Korrektur un a fuert d’Ufro erëm vum selwechte Client aus. Eng erfollegräich Ufro no enger Ännerung vum Starter ass eng Beweis fir Zougang, an et ass nach keng Beweis datt d’Authentifikatiounsufuerderung erfëllt gouf.