VPN ansluter, men SQL Server avvisar Windows-autentisering

Tunnlarna kommer upp, servrarna svarar på ping, och databasinloggningen misslyckas fortfarande med ett autentiseringsfel. Den kombinationen är vanlig på VPN-länkar och betyder sällan att nätverket är trasigt, eftersom en nåbar lyssnare och en accepterad inloggning är två olika resultat. Den identitet som tillfredsställde gatewayen är inte nödvändigtvis den identitet som databasklienten erbjuder. Att ta reda på vilket konto som anlände är hela uppgiften.

Symtomet: nåbar server, avvisad inloggning

En timeout berättar att paketet aldrig nådde en lyssnare. Ett autentiseringsfel berättar att lyssnaren svarade och avvisade autentiseringsuppgifterna. De två meddelandena skickar dig till olika team, och att blanda ihop dem kostar en dag på brandväggsregler som aldrig var problemet.

När felet är en misslyckad inloggning, sluta titta på portar. Den återstående frågan är vilken Windows-identitet klienten presenterade, om servern accepterade den identiteten och om den löstes upp till en databasanvändare med behörighet.

Två identiteter, en tunnel

VPN-kontot autentiserar sig mot gatewayen och slutar i de flesta installationer där. Databasklienten presenterar separat en Windows-token, hämtad från processen som kör den, eller en SQL-inloggning om anslutningssträngen begär en. En gateway-lokal VPN-användare har ingen relation till den domän som är värd för SQL Server, och tunneln skapar ingen.

Att ansluta en personlig maskin till en VPN gör den inte heller till medlem i domänen. Att byta namn på ett lokalt konto och matcha dess lösenord mot en domänanvändare är ingen registreringsprocedur, och det ger en token som domänkontrollanten inte accepterar som den användaren.

Vissa inbyggda Windows-klienter för fjärråtkomst kan återanvända VPN-autentiseringsuppgifterna för nätverksresurser när deras profil är konfigurerad så. Det beteendet tillhör en specifik klient och profil, inte VPN-anslutningar i allmänhet, så verifiera det för den klient som används i stället för att anta det.

Läs det läge som klienten bad om

Anslutningssträngen avgör vilken autentiseringsväg klienten tar. Integrerad säkerhet använder Windows-token; ett par av användarnamn och lösenord väljer en SQL-inloggning. Det är separata lägen i serverkonfigurationen, och bara ett av dem kan vara aktiverat för ett givet anslutningsförsök.

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

Att byta till en SQL-inloggning eftersom Windows-inloggningen misslyckades är en kringgående lösning som döljer identitetsfrågan, och den kräver oftast att ett nytt inlogg och lösenord skapas ändå. Om installationen kräver Windows-autentisering, behåll läget och reparera identitetsvägen. En SQL-inloggning behöver också egna behörigheter, så kringgåendet köper ett extra konto att underhålla.

Bekräfta också vilken applikation som ansluter. En tjänst som körs som systemkonto, en schemalagd uppgift och ett interaktivt frågefönster kan presentera tre olika tokens på samma maskin, och bara den sista stämmer med det användaren ser när den kör whoami.

Fråga servern vad den faktiskt såg

Servern kan berätta vilken inloggning den löste upp och hur anslutningen autentiserades. Kör frågan inuti den session som undersöks, eftersom en administratörs separata lyckade anslutning inte bevisar något om den misslyckade klienten.

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örsta raden skiljer den inloggning som öppnade sessionen från den säkerhetskontext som gäller nu, och de skiljer sig under personifiering. Den andra anger autentiseringsschemat, så KERBEROS, NTLM och SQL blir synliga fakta i stället för gissningar. En anslutning som rapporterar NTLM där du förväntade dig Kerberos är ett namnupplösnings- eller SPN-problem, inte ett lösenordsproblem.

Felnumret begränsar det ytterligare. Status 5 betyder oftast att inloggningsnamnet inte löstes upp alls, status 8 betyder oftast att lösenordet inte stämde, och status 11 betyder att autentiseringsuppgifterna accepterades men åtkomsten till servern misslyckades. Be administratören om statusen i stället för hela meddelandet, eftersom meddelandet i sig är avsiktligt vagt.

När identiteten anländer och Kerberos fortfarande misslyckas

Om servern ser den avsedda Windows-identiteten och integrerad autentisering fortfarande misslyckas, är själva utbytet problemet. Kerberos behöver det tjänsteprincipnamn som är registrerat för SQL-tjänstekontot och en klient som begär tjänsten med ett namn som matchar det. Att ansluta via IP-adress kan inte matcha ett namnbaserat SPN, och ett alias kan bara matcha om det också är registrerat. Kontrollera först namnet som klienten skrev in, eftersom en anslutning som fungerar via värdnamn och misslyckas via IP beskriver precis det här problemet.

Be administratören granska den registrerade identiteten och tjänstekontot i stället för att skapa dubblerade SPN:er genom att prova sig fram. Dubblerade registreringar ger återkommande fel som är svårare att diagnostisera än det ursprungliga problemet.

När autentiseringen fungerar behöver inloggningen fortfarande en databasanvändare och behörigheter. En lyckad VPN-inloggning, en lyckad Windows-inloggning och behörighet att läsa en viss tabell är tre separata resultat, och var och en förtjänar sin egen kontroll innan ärendet stängs.