VPN kobler til, men SQL Server avviser Windows-godkjenning

Tunneler kommer opp, servere svarer på ping, og databasepåloggingen feiler fortsatt med en godkjenningsfeil. Den kombinasjonen er vanlig på VPN-forbindelser, og den betyr sjelden at nettverket er ødelagt, fordi en nåbar lytter og en akseptert pålogging er to forskjellige resultater. Identiteten som tilfredsstilte gatewayen, er ikke nødvendigvis identiteten databaseklienten tilbyr. Å finne ut hvilken konto som ankom, er hele oppgaven.

Symptomet: nåbar server, avvist pålogging

En tidsavbrudd forteller deg at pakken aldri nådde en lytter. En godkjenningsfeil forteller deg at lytteren svarte og avviste legitimasjonen. De to meldingene sender deg til forskjellige team, og å blande dem kaster bort en dag på brannmurregler som aldri var problemet.

Når feilen er mislykket pålogging, slutt å se på porter. Det gjenstående spørsmålet er hvilken Windows-identitet klienten presenterte, om serveren godtok den identiteten, og om den ble løst opp til en databasebruker med tillatelse.

To identiteter, én tunnel

VPN-kontoen godkjennes ved gatewayen og slutter i de fleste utrullinger der. Databaseklienten presenterer separat et Windows-token, hentet fra prosessen som kjører den, eller en SQL-pålogging hvis tilkoblingsstrengen ber om det. En gateway-lokal VPN-bruker har ingen relasjon til domenet som er vert for SQL Server, og tunnelen oppretter ingen.

Å koble en personlig maskin til en VPN melder den heller ikke inn i domenet. Å gi en lokal konto nytt navn og tilpasse passordet til en domenebruker er ikke en innmeldingsprosedyre, og det gir et token som domenekontrolleren ikke godtar som den brukeren.

Noen innebygde Windows-klienter for ekstern tilgang kan gjenbruke VPN-legitimasjonen for nettverksressurser når profilen deres er konfigurert slik. Den oppførselen tilhører en bestemt klient og profil, ikke VPN-forbindelser generelt, så verifiser det for klienten som brukes i stedet for å anta det.

Les modusen klienten ba om

Tilkoblingsstrengen avgjør hvilken godkjenningsvei klienten tar. Integrert sikkerhet bruker Windows-tokenet; et par av brukernavn og passord velger en SQL-pålogging. Dette er separate moduser i serverkonfigurasjonen, og bare én av dem kan være aktivert for et gitt tilkoblingsforsøk.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Å bytte til en SQL-pålogging fordi Windows-påloggingen mislyktes, er en omvei som skjuler identitetsspørsmålet, og det krever vanligvis at det opprettes ny pålogging og nytt passord likevel. Hvis utrullingen krever Windows-godkjenning, behold modusen og reparer identitetsveien. En SQL-pålogging trenger også egne tillatelser, så omveien kjøper en ekstra konto å vedlikeholde.

Bekreft også hvilken applikasjon som kobler til. En tjeneste som kjører som systemkonto, en planlagt oppgave og et interaktivt spørrevindu kan presentere tre forskjellige tokens på samme maskin, og bare det siste samsvarer med det brukeren ser når den kjører whoami.

Spør serveren hva den faktisk så

Serveren kan fortelle deg hvilken pålogging den løste opp, og hvordan forbindelsen ble godkjent. Kjør spørringen inne i økten som undersøkes, fordi en administrators separate vellykkede forbindelse ikke beviser noe om klienten som feiler.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Den første raden skiller påloggingen som åpnet økten, fra sikkerhetskonteksten som gjelder nå, og de er forskjellige under personifisering. Den andre angir godkjenningsskjemaet, slik at KERBEROS, NTLM og SQL blir synlige fakta i stedet for gjetninger. En forbindelse som rapporterer NTLM der du forventet Kerberos, er et navneoppløsnings- eller SPN-problem, ikke et passordproblem.

Feilnummeret snevrer det ytterligere inn. Tilstand 5 betyr vanligvis at påloggingsnavnet ikke ble løst opp i det hele tatt, tilstand 8 betyr vanligvis at passordet ikke stemte, og tilstand 11 betyr at legitimasjonen ble godtatt, men tilgangen til serveren mislyktes. Be administratoren om tilstanden i stedet for hele meldingen, fordi meldingen alene er bevisst vag.

Når identiteten ankommer, og Kerberos fortsatt feiler

Hvis serveren ser den tiltenkte Windows-identiteten og integrert godkjenning fortsatt mislykkes, er utvekslingen selv problemet. Kerberos trenger tjenesteprinsipalnavnet som er registrert for SQL-tjenestekontoen, og en klient som ber om tjenesten med et navn som samsvarer med det. Å koble til via IP-adresse kan ikke samsvare med et navnebasert SPN, og et alias kan bare samsvare hvis det også er registrert. Kontroller navnet klienten skrev inn først av alt, fordi en forbindelse som virker via vertsnavn og feiler via IP, beskriver nettopp dette problemet.

Be administratoren gjennomgå den registrerte identiteten og tjenestekontoen i stedet for å opprette dupliserte SPN-er ved prøving og feiling. Dupliserte registreringer gir periodiske feil som er vanskeligere å diagnostisere enn det opprinnelige problemet.

Når godkjenningen virker, trenger påloggingen fortsatt en databasebruker og tillatelser. En vellykket VPN-pålogging, en vellykket Windows-pålogging og tillatelse til å lese en bestemt tabell er tre separate resultater, og hvert av dem fortjener sin egen kontroll før saken lukkes.