Hvorfor faller SQL Server over en VPN fortsatt tilbake på NTLM?

Tilkoblingen din virker, påloggingen godtas, og SQL Server bruker NTLM mens alle forventet Kerberos. Det resultatet er ikke en VPN-feil, fordi en tunnel bare leverer en vei; skjemaet ble bestemt av navnet klienten ba om, prinsipalen som er registrert i katalogen, og billetten klienten faktisk kunne skaffe. Tre betingelser må gjelde samtidig, og økten selv sier hvilken som ga etter. Les det før noen redigerer et tjenesteprinsipalnavn.

Økten navngir skjemaet du faktisk fikk

Godkjenningsskjemaet tilhører en tilkobling og ikke en server eller tunnel, så kontrollen må kjøre inne i økten du bryr deg om. Kjør spørringen nedenfor fra samme klient, verktøy og konto som produserte rapporten, og noter målrettet navn og transport ved siden av resultatet.

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

En rad fra et lokalt SSMS-vindu på databaseverten beskriver en helt annen tilkobling, og derfor må spørringen kjøre fra klientsiden. Lagre utdataene med tidsstempel, fordi neste person som leser dem vil spørre når de ble tatt. Når flere applikasjoner deler ett endepunkt, ta en prøve fra hver, fordi en forskjell i datakilde mellom to applikasjoner ofte er hele historien.

Betingelse en: passer navnet til SPN-en?

Kerberos godkjenner en navngitt tjeneste, så klienten ber katalogen om en billett til én bestemt prinsipal. For TCP-leverandøren er den dokumenterte formen MSSQLSvc/ etterfulgt av det fullt kvalifiserte vertsnavnet og, for en standardinstans, porten. En navngitt instans registrerer MSSQLSvc/db01.corp.example:SQLPROD, der suffikset er instansnavnet i stedet for et nummer. Når lytteren nås via et alias, en CNAME som løses ut et annet sted, eller en bar IP-adresse, endres det etterspurte navnet, og en forespørsel uten samsvarende prinsipal har ingen billett å returnere.

Det er derfor en applikasjon virker på ett nett og faller tilbake på et annet: et DNS-svar, en aliaspost eller en hosts-oppføring endret navnet klienten brukte. Sammenlign det etterspurte navnet med det katalogen inneholder før du rører registreringen.

Betingelse to: er SPN-en på riktig konto?

En SPN må tilhøre kontoen som kjører SQL-tjenesten, ikke klientens konto og ikke ved et uhell et datamaskinobjekt. SQL Server kan registrere sine egne SPN-er ved oppstart når tjenestekontoen har tillatelse til å skrive dem, noe som er praktisk og også forklarer hvordan en duplikat oppstår etter en endring av tjenestekonto.

Spør katalogen etter navnet du forventer, og list deretter opp hva kontoen faktisk eier. Hvilket objekt som holder oppføringen betyr mer enn om navnet finnes et sted i skogen. Uoverensstemmelse betyr at påloggingen aldri var problemet, og Microsofts SPN-veiledning dokumenterer formatene og tilfellene der en domenebehandler må opprette oppføringen.

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

Å legge til nok en oppføring er ikke et trygt eksperiment. En duplikat eller motstridende registrering kan ødelegge klienter som virket, så undersøk eierskapet før endringen og kontroller det på nytt etterpå.

Betingelse tre: kan klienten i det hele tatt få en billett?

En korrekt SPN er ubrukelig hvis klienten ikke når en domenekontroller eller ikke har en brukbar påloggingskontekst. Utvekslingen trenger KDC og DNS gjennom VPN-en, og en tunnel som bare ruter SQL-porten feiler nettopp på dette trinnet. Tilgjengelighet må testes fra samme maskin og samme konto, ikke fra brannmuren foran dem.

Undersøk billettbufferen på maskinen og under kontoen som kjører applikasjonen. En maskinomfattende liste fra et forhøyet vindu sier ingenting om en tjeneste som kjører som en annen bruker, og en tom buffer for den brukeren er et funn og ikke en ulempe.

klist
klist -li 0x3e7

Avgjør deretter hva en tilbakefall kan gjøre. Hvis policyen krever Kerberos, må NTLM avvises eksplisitt, fordi et stille tilbakefall gjør en konfigurasjonsfeil om til en fungerende tilkobling som bryter kravet. Hvis NTLM forblir akseptabelt for noen applikasjoner, navngi dem og slutt å behandle hver NTLM-økt som en hendelse.

Å endre oppstarteren er én variabel, ikke en rettelse

Å starte SSMS under en annen pålogging kan kurere en utilsiktet utgående identitet, som er en reell problemklasse. Det beviser ingenting om målrettet navn, registreringen eller billettveien, og endrer ikke det serveren godtok.

Hold sammenligningen kontrollert: samme endepunkt, samme leverandør, en kjent kjørekontekst, deretter en frisk tilkobling der du undersøker skjemaet. Bekreft den godtatte påloggingen og dens databasetillatelser separat, fordi tilgang og godkjenning feiler av forskjellige grunner.

Når Kerberos er påkrevd, noter hvorfor den første veien falt tilbake, bruk én rettelse og kjør spørringen på nytt fra samme klient. En vellykket spørring etter en endring av oppstarteren er bevis på tilgang, og det er ennå ikke bevis for at godkjenningskravet ble oppfylt.