VPN forbinder, men SQL Server afviser Windows-godkendelse

Tunneler kommer op, servere svarer på ping, og databaselogin fejler stadig med en godkendelsesfejl. Den kombination er almindelig på VPN-forbindelser, og den betyder sjældent, at netværket er i stykker, fordi en nåbar lytter og et accepteret login er to forskellige resultater. Den identitet, der tilfredsstillede gatewayen, er ikke nødvendigvis den identitet, databaseklienten tilbyder. At finde ud af, hvilken konto der ankom, er hele opgaven.

Symptomet: nåbar server, afvist login

En timeout fortæller dig, at pakken aldrig nåede en lytter. En godkendelsesfejl fortæller dig, at lytteren svarede og afviste legitimationsoplysningerne. De to beskeder sender dig til forskellige teams, og at blande dem spilder en dag på firewallregler, der aldrig var problemet.

Når fejlen er et mislykket login, skal du holde op med at kigge på porte. Det resterende spørgsmål er, hvilken Windows-identitet klienten præsenterede, om serveren accepterede den identitet, og om den blev opløst til en databasebruger med tilladelse.

To identiteter, én tunnel

VPN-kontoen godkendes ved gatewayen og slutter i de fleste installationer der. Databaseklienten præsenterer separat et Windows-token, taget fra den proces, der kører den, eller et SQL-login, hvis forbindelsesstrengen beder om det. En gateway-lokal VPN-bruger har ingen relation til det domæne, der hoster SQL Server, og tunnelen opretter ikke en.

At forbinde en personlig maskine til en VPN melder den heller ikke ind i domænet. At omdøbe en lokal konto og matche dens adgangskode med en domænebruger er ikke en indmeldelsesprocedure, og det giver et token, som domænecontrolleren ikke accepterer som den bruger.

Nogle native Windows-fjernadgangsklienter kan genbruge VPN-legitimationsoplysningerne til netværksressourcer, når deres profil er konfigureret sådan. Den adfærd tilhører en bestemt klient og profil, ikke VPN-forbindelser generelt, så verificer det for den anvendte klient i stedet for at antage det.

Læs den tilstand, klienten bad om

Forbindelsesstrengen afgør, hvilken godkendelsesvej klienten tager. Integreret sikkerhed bruger Windows-tokenet; et par af brugernavn og adgangskode vælger et SQL-login. Det er separate tilstande i serverkonfigurationen, og kun én af dem kan være aktiveret for et givet forbindelsesforsøg.

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

At skifte til et SQL-login, fordi Windows-loginet fejlede, er en omvej, der skjuler identitetsspørgsmålet, og det kræver normalt alligevel, at der oprettes et nyt login og en ny adgangskode. Hvis installationen kræver Windows-godkendelse, skal du beholde tilstanden og rette identitetsvejen. Et SQL-login har også brug for sine egne tilladelser, så omvejen køber en ekstra konto at vedligeholde.

Bekræft også, hvilket program der forbinder. En tjeneste, der kører som systemkonto, en planlagt opgave og et interaktivt forespørgselsvindue kan præsentere tre forskellige tokens på samme maskine, og kun det sidste svarer til det, brugeren ser, når de kører whoami.

Spørg serveren, hvad den faktisk så

Serveren kan fortælle dig, hvilket login den opløste, og hvordan forbindelsen blev godkendt. Kør forespørgslen inde i den session, der undersøges, fordi en administrators separate vellykkede forbindelse ikke beviser noget om den fejlende klient.

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 række skelner det login, der åbnede sessionen, fra den sikkerhedskontekst, der gælder lige nu, og de er forskellige under personificering. Den anden angiver godkendelsesskemaet, så KERBEROS, NTLM og SQL bliver synlige fakta i stedet for gæt. En forbindelse, der rapporterer NTLM, hvor du forventede Kerberos, er et navneopløsnings- eller SPN-problem, ikke et adgangskodeproblem.

Fejlnummeret indsnævrer det yderligere. Tilstand 5 betyder normalt, at login-navnet slet ikke blev opløst, tilstand 8 betyder normalt, at adgangskoden ikke passede, og tilstand 11 betyder, at legitimationsoplysningerne blev accepteret, men adgangen til serveren fejlede. Bed administratoren om tilstanden i stedet for hele meddelelsen, fordi meddelelsen alene er bevidst vag.

Når identiteten ankommer, og Kerberos stadig fejler

Hvis serveren ser den tilsigtede Windows-identitet, og integreret godkendelse stadig fejler, er udvekslingen selv problemet. Kerberos kræver det tjenesteprincipalnavn, der er registreret for SQL-tjenestekontoen, og en klient, der anmoder om tjenesten med et navn, der matcher det. Forbindelse via IP-adresse kan ikke matche et navnebaseret SPN, og et alias kan kun matche, hvis det også er registreret. Kontroller navnet, klienten skrev, før alt andet, fordi en forbindelse, der virker via værtsnavn og fejler via IP, beskriver præcis dette problem.

Bed administratoren gennemgå den registrerede identitet og tjenestekontoen i stedet for at oprette duplikerede SPN’er ved at prøve sig frem. Duplikerede registreringer giver periodiske fejl, der er sværere at diagnosticere end det oprindelige problem.

Når godkendelsen virker, har login stadig brug for en databasebruger og tilladelser. Et vellykket VPN-login, et vellykket Windows-login og tilladelse til at læse en bestemt tabel er tre separate resultater, og hvert af dem fortjener sit eget tjek, før sagen lukkes.