VPN koplar til, men SQL Server avviser Windows-godkjenning

Tunnelar kjem opp, tenarar svarar på ping, og databasepålogginga feilar framleis med ein godkjenningsfeil. Den kombinasjonen er vanleg på VPN-samband, og han tyder sjeldan at nettet er øydelagt, fordi ein nåbar lyttar og ei godteken pålogging er to ulike resultat. Identiteten som gjorde porten nøgd, er ikkje nødvendigvis identiteten databaseklienten byd fram. Å finne ut kva konto som kom, er heile oppgåva.

Symptomet: nåbar tenar, avvist pålogging

Ein tidsavbrot seier at pakken aldri nådde ein lyttar. Ein godkjenningsfeil seier at lyttaren svara og avviste legitimasjonen. Dei to meldingane sender deg til ulike team, og å blande dei sløsar bort ein dag på brannmurreglar som aldri var problemet.

Når feilen er mislukka pålogging, slutt å sjå på portar. Det gjenståande spørsmålet er kva Windows-identitet klienten la fram, om tenaren godtok den identiteten, og om han vart løyst opp til ein databasebrukar med løyve.

To identitetar, éin tunnel

VPN-kontoen godkjennast ved porten og sluttar i dei fleste utrulleringar der. Databaseklienten legg fram eit Windows-token separat, henta frå prosessen som køyrer han, eller ei SQL-pålogging om tilkoplingsstrengen ber om det. Ein portlokal VPN-brukar har inga relasjon til domenet som er vert for SQL Server, og tunnelen opprettar ingen.

Å kople ein personleg maskin til ein VPN melder han heller ikkje inn i domenet. Å gje ein lokal konto nytt namn og tilpasse passordet til ein domenebrukar er ikkje ein innmeldingsprosedyre, og det gjev eit token som domenekontrolløren ikkje godtek som den brukaren.

Nokre innebygde Windows-klientar for fjernåtkomst kan gjenbruke VPN-legitimasjonen for nettverksressursar når profilen deira er konfigurert slik. Den åtferda høyrer til ein bestemd klient og profil, ikkje VPN-samband generelt, så stadfest det for klienten som vert brukt i staden for å gå ut frå det.

Les modusen klienten bad om

Tilkoplingsstrengen avgjer kva godkjenningsveg klienten tek. Integrert tryggleik brukar Windows-tokenet; eit par av brukarnamn og passord vel ei SQL-pålogging. Dette er separate modusar i tenarkonfigurasjonen, og berre éin av dei kan vere slått på for eit gjeve tilkoplingsforsøk.

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

Å byte til ei SQL-pålogging fordi Windows-pålogginga mislukkast, er ein omveg som skjuler identitetsspørsmålet, og det krev vanlegvis at det vert oppretta ny pålogging og nytt passord likevel. Om utrulleringa krev Windows-godkjenning, hald på modusen og reparer identitetsvegen. Ei SQL-pålogging treng også eigne løyve, så omvegen kjøper ein ekstra konto å vedlikehalde.

Stadfest òg kva program som koplar til. Ein teneste som køyrer som systemkonto, ei planlagd oppgåve og eit interaktivt spørjevindauge kan leggje fram tre ulike token på same maskin, og berre det siste svarar til det brukaren ser når han køyrer whoami.

Spør tenaren kva han faktisk såg

Tenaren kan fortelje kva pålogging han løyste opp, og korleis sambandet vart godkjent. Køyr spørjinga inne i økta som vert granska, fordi eit separat vellukka samband frå ein administrator ikkje provar noko om klienten som feilar.

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 rada skil pålogginga som opna økta, frå tryggleikskonteksten som gjeld no, og dei er ulike under personifisering. Den andre nemner godkjenningsskjemaet, slik at KERBEROS, NTLM og SQL vert synlege fakta i staden for gjettingar. Eit samband som rapporterer NTLM der du venta Kerberos, er eit namneoppløysings- eller SPN-problem, ikkje eit passordproblem.

Feilnummeret snevrar det ytterlegare inn. Tilstand 5 tyder vanlegvis at påloggingsnamnet ikkje vart løyst opp i det heile, tilstand 8 tyder vanlegvis at passordet ikkje stemde, og tilstand 11 tyder at legitimasjonen vart godteken, men tilgangen til tenaren mislukkast. Be administratoren om tilstanden i staden for heile meldinga, fordi meldinga åleine er medvite vag.

Når identiteten kjem, og Kerberos framleis feilar

Om tenaren ser den tiltenkte Windows-identiteten og integrert godkjenning framleis mislukkast, er utvekslinga sjølv problemet. Kerberos treng tenesteprinsipalnamnet som er registrert for SQL-tenestekontoen, og ein klient som ber om tenesta med eit namn som svarar til det. Å kople til via IP-adresse kan ikkje svare til eit namnebasert SPN, og eit alias kan berre svare til det om det òg er registrert. Kontroller namnet klienten skreiv inn først av alt, fordi eit samband som virkar via vertsnamn og feilar via IP, skildrar nettopp dette problemet.

Be administratoren gå gjennom den registrerte identiteten og tenestekontoen i staden for å opprette dupliserte SPN-ar ved prøving og feiling. Dupliserte registreringar gjev periodiske feil som er vanskelegare å diagnostisere enn det opphavlege problemet.

Når godkjenninga virkar, treng pålogginga framleis ein databasebrukar og løyve. Ei vellukka VPN-pålogging, ei vellukka Windows-pålogging og løyve til å lese ein bestemd tabell er tre separate resultat, og kvart av dei fortener si eiga kontroll før saka vert lukka.