Varför faller SQL Server över en VPN fortfarande tillbaka på NTLM?

Din anslutning fungerar, inloggningen accepteras och SQL Server använder NTLM medan alla förväntade sig Kerberos. Resultatet är inte en VPN-defekt, eftersom en tunnel bara ger en väg; schemat bestämdes av namnet klienten begärde, den principal som är registrerad i katalogen och den biljett som klienten faktiskt kunde få. Tre villkor måste gälla samtidigt, och sessionen själv säger vilket som gav vika. Läs det innan någon redigerar ett tjänsteprincipalnamn.

Sessionen namnger schemat du faktiskt fick

Autentiseringsschemat tillhör en anslutning och inte en server eller tunnel, så kontrollen måste köras inne i den session du bryr dig om. Kör frågan nedan från samma klient, verktyg och konto som tog fram rapporten, och notera målname och transport bredvid resultatet.

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

En rad från ett lokalt SSMS-fönster på databashosten beskriver en helt annan anslutning, och därför måste frågan köras från klientsidan. Spara utdata med en tidsstämpel, eftersom nästa person som läser dem kommer att fråga när de togs. När flera program delar en slutpunkt ska du ta ett prov från varje, eftersom en skillnad i datakälla mellan två program ofta är hela historien.

Villkor ett: passar namnet med SPN?

Kerberos autentiserar en namngiven tjänst, så klienten ber katalogen om en biljett för en specifik principal. För TCP-providern är den dokumenterade formen MSSQLSvc/ följd av det fullständigt kvalificerade värdnamnet och, för en standardinstans, porten. En namngiven instans registrerar MSSQLSvc/db01.corp.example:SQLPROD, där suffixet är instansnamnet i stället för ett nummer. Att nå lyssnaren via ett alias, en CNAME som löses ut någon annanstans eller en bar IP-adress ändrar det begärda namnet, och en begäran utan matchande principal har ingen biljett att returnera.

Det är därför ett program fungerar i ett nät och faller tillbaka i ett annat: ett DNS-svar, en aliaspost eller en hosts-post ändrade namnet klienten använde. Jämför det begärda namnet med det katalogen innehåller innan du rör registreringen.

Villkor två: är SPN på rätt konto?

En SPN måste tillhöra kontot som kör SQL-tjänsten, inte klientens konto och inte av misstag ett datorobjekt. SQL Server kan registrera sina egna SPN vid start när dess tjänstekonto har behörighet att skriva dem, vilket är praktiskt och också förklarar hur en dubblett uppstår efter ett byte av tjänstekonto.

Fråga katalogen efter det namn du förväntar dig och lista sedan vad kontot faktiskt äger. Vilket objekt som håller posten spelar större roll än om namnet finns någonstans i skogen. En avvikelse betyder att inloggningen aldrig var problemet, och Microsofts SPN-guide dokumenterar formaten och fallen där en domänadministratör måste skapa posten.

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

Att lägga till ytterligare en post är inte ett säkert experiment. En dubblett eller motstridig registrering kan bryta klienter som fungerade, så granska ägandet före ändringen och kontrollera det igen efteråt.

Villkor tre: kan klienten överhuvudtaget få en biljett?

En korrekt SPN är värdelös om klienten inte når en domänkontrollant eller saknar en användbar autentiseringskontext. Utbytet behöver KDC och DNS genom VPN, och en tunnel som bara dirigerar SQL-porten misslyckas just i detta steg. Tillgängligheten måste testas från samma maskin och samma konto, inte från brandväggen framför dem.

Granska biljettcachen på maskinen och under kontot som kör programmet. En maskinövergripande lista från ett förhöjt fönster säger ingenting om en tjänst som körs som en annan användare, och en tom cache för den användaren är ett fynd och inte en olägenhet.

klist
klist -li 0x3e7

Bestäm sedan vad en återgång får göra. Om policyn kräver Kerberos måste NTLM avvisas uttryckligen, eftersom en tyst återgång förvandlar ett konfigurationsfel till en fungerande anslutning som bryter mot kravet. Om NTLM förblir acceptabelt för vissa program, namnge dem och sluta behandla varje NTLM-session som en incident.

Att byta startprogram är en variabel, inte en rättelse

Att starta SSMS under en annan autentiseringsuppgift kan bota en oavsiktlig utgående identitet, vilket är en verklig problemklass. Det bevisar ingenting om målname, registreringen eller biljettvägen och ändrar inte vad servern accepterade.

Håll jämförelsen kontrollerad: samma slutpunkt, samma leverantör, en känd körningskontext och sedan en ny anslutning vars schema du granskar. Bekräfta den accepterade inloggningen och dess databasbehörigheter separat, eftersom åtkomst och autentisering misslyckas av olika skäl.

När Kerberos krävs, notera varför den första vägen föll tillbaka, tillämpa en rättelse och kör frågan igen från samma klient. En lyckad fråga efter ett byte av startprogram är bevis på åtkomst och är ännu inte bevis för att autentiseringskravet uppfylldes.