Kvifor fell SQL Server over ein VPN framleis tilbake på NTLM?

Tilkoplinga di verkar, pålogginga vert godteken, og SQL Server brukar NTLM medan alle venta Kerberos. Det resultatet er ikkje ein VPN-feil, fordi ein tunnel berre leverer ein veg; skjemaet vart avgjort av namnet klienten bad om, prinsipalen som er registrert i katalogen, og billetten klienten faktisk kunne skaffe. Tre vilkår må gjelde samstundes, og økta sjølv seier kva for eitt som gav etter. Les det før nokon redigerer eit tenesteprinsipalnamn.

Økta namngjev skjemaet du faktisk fekk

Godkjenningsskjemaet høyrer til ei tilkopling og ikkje til ein tenar eller tunnel, så kontrollen må køyre inne i økta du bryr deg om. Køyr spørjinga nedanfor frå same klient, verktøy og konto som laga rapporten, og noter målrett namn og transport ved sida av resultatet.

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

Ei rad frå eit lokalt SSMS-vindauge på databaseverten skildrar ei heilt anna tilkopling, og difor må spørjinga køyre frå klientsida. Lagre utdataa med tidsstempel, fordi neste person som les dei vil spørje når dei vart tekne. Når fleire program deler eitt endepunkt, ta ein prøve frå kvart, fordi ein skilnad i datakjelde mellom to program ofte er heile historia.

Vilkår ein: passar namnet til SPN-en?

Kerberos godkjenner ein namngjeven teneste, så klienten ber katalogen om ein billett til éin bestemt prinsipal. For TCP-leverandøren er den dokumenterte forma MSSQLSvc/ etterfølgd av det fullt kvalifiserte vertsnamnet og, for ein standardinstans, porten. Ein namngjeven instans registrerer MSSQLSvc/db01.corp.example:SQLPROD, der suffikset er instansnamnet i staden for eit nummer. Når lyttaren vert nådd via eit alias, ein CNAME som vert løyst ut ein annan stad, eller ei bar IP-adresse, vert det etterspurde namnet endra, og ei førespurnad utan samsvarande prinsipal har ingen billett å returnere.

Det er difor eit program verkar på eitt nett og fell tilbake på eit anna: eit DNS-svar, ein aliaspost eller ei hosts-oppføring endra namnet klienten brukte. Samanlikn det etterspurde namnet med det katalogen inneheld før du rører registreringa.

Vilkår to: er SPN-en på riktig konto?

Ein SPN må høyre til kontoen som køyrer SQL-tenesta, ikkje kontoen til klienten og ikkje ved eit uhell eit datamaskinobjekt. SQL Server kan registrere sine eigne SPN-ar ved oppstart når tenestekontoen har løyve til å skrive dei, noko som er praktisk og også forklarer korleis ein duplikat oppstår etter ei endring av tenestekontoen.

Spør katalogen etter namnet du ventar, og list deretter opp kva kontoen faktisk eig. Kva objekt som held oppføringa betyr meir enn om namnet finst ein stad i skogen. Uoverenskomst betyr at pålogginga aldri var problemet, og Microsoft si SPN-rettleiing dokumenterer formata og tilfella der ein domenebehandlar må opprette oppføringa.

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

Å leggje til endå ei oppføring er ikkje eit trygt eksperiment. Ein duplikat eller motstridande registrering kan øydeleggje klientar som verka, så undersøk eigarskapen før endringa og kontroller han på nytt etterpå.

Vilkår tre: kan klienten i det heile få ein billett?

Ein korrekt SPN er ubrukeleg viss klienten ikkje når ein domenekontrollør eller ikkje har ein brukbar påloggingskontekst. Utvekslinga treng KDC og DNS gjennom VPN-en, og ein tunnel som berre ruter SQL-porten feilar nettopp på dette trinnet. Tilgjenge må testast frå same maskin og same konto, ikkje frå brannmuren framfor dei.

Undersøk billettbufferen på maskina og under kontoen som køyrer programmet. Ei maskinomfattande liste frå eit forhøgd vindauge seier ingenting om ei teneste som køyrer som ein annan brukar, og ein tom buffer for den brukaren er eit funn og ikkje eit uhell.

klist
klist -li 0x3e7

Avgjer deretter kva ein tilbakefall kan gjere. Viss policyen krev Kerberos, må NTLM avvisast eksplisitt, fordi eit stille tilbakefall gjer ein konfigurasjonsfeil om til ei fungerande tilkopling som bryt kravet. Viss NTLM blir akseptabelt for nokre program, namngei dei og slutt å handsame kvar NTLM-økt som ei hending.

Å endre oppstartaren er éin variabel, ikkje ei retting

Å starte SSMS under ei anna pålogging kan kurere ein utilsikta utgåande identitet, som er ein reell problemklasse. Det beviser ingenting om målrett namn, registreringa eller billettvegen, og endrar ikkje det tenaren godtok.

Hald samanlikninga kontrollert: same endepunkt, same leverandør, ein kjend køyretidskontekst, deretter ei fersk tilkopling der du undersøkjer skjemaet. Stadfest den godtekne pålogginga og databasetilgangane hennar separat, fordi tilgang og godkjenning feilar av ulike grunnar.

Når Kerberos er påkravd, noter kvifor den første vegen fall tilbake, bruk éi retting og køyr spørjinga på nytt frå same klient. Ei vellukka spørjing etter ei endring av oppstartaren er prov på tilgang, og det er enno ikkje prov på at godkjenningskravet vart oppfylt.