VPN se povezuje, ali SQL Server odbija Windows autentifikaciju

Tuneli se podižu, serveri odgovaraju na ping, a prijava u bazu i dalje ne uspijeva s greškom autentifikacije. Ta kombinacija je česta na VPN vezama i rijetko znači da je mreža pokvarena, jer dostupan slušalac i prihvaćena prijava su različiti rezultati. Identitet koji je zadovoljio gateway nije nužno identitet koji nudi klijent baze. Utvrditi koji je račun stigao cijeli je zadatak.

Simptom: dostupan server, odbijena prijava

Istek vremena kaže da paket nikada nije stigao do slušaoca. Greška autentifikacije kaže da je slušalac odgovorio i odbio akreditive. Te dvije poruke vode vas različitim timovima, a njihovo miješanje troši dan na pravila vatrozida koja nikada nisu bila problem.

Kada je greška neuspjela prijava, prestanite gledati portove. Ostaje pitanje koji je Windows identitet klijent predstavio, je li server taj identitet prihvatio i je li se razriješio u korisnika baze s dozvolom.

Dva identiteta, jedan tunel

Račun za VPN autentificira se na gatewayu i u većini instalacija tu završava. Klijent baze odvojeno predstavlja Windows token, uzet iz procesa koji ga pokreće, ili SQL prijavu ako je traži niz za povezivanje. Lokalni VPN korisnik na gatewayu nema nikakve veze s domenom koja hosta SQL Server, a tunel je ne stvara.

Povezivanje ličnog računara na VPN također ga ne pridružuje domeni. Preimenovanje lokalnog računa i usklađivanje njegove lozinke s korisnikom domene nije postupak upisa i stvara token koji kontroler domene neće prihvatiti kao tog korisnika.

Neki izvorni Windows klijenti za daljinski pristup mogu ponovno upotrijebiti VPN akreditive za mrežne resurse kada je njihov profil tako konfiguriran. Takvo ponašanje pripada određenom klijentu i profilu, ne VPN vezama općenito, pa to provjerite za klijent koji se koristi umjesto da to pretpostavljate.

Pročitajte način koji je klijent zatražio

Niz za povezivanje odlučuje kojim putem autentifikacije klijent ide. Integrirana sigurnost koristi Windows token; par korisnik i lozinka bira SQL prijavu. To su odvojeni načini u konfiguraciji servera i samo jedan od njih može biti omogućen za određeni pokušaj povezivanja.

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

Prelazak na SQL prijavu zato što je Windows prijava neuspjela je zaobilazno rješenje koje skriva pitanje identiteta i obično ipak zahtijeva stvaranje nove prijave i lozinke. Ako instalacija zahtijeva Windows autentifikaciju, zadržite način i popravite put identiteta. SQL prijava također treba vlastite dozvole, pa zaobilazno rješenje kupuje drugi račun za održavanje.

Također potvrdite koja se aplikacija povezuje. Servis koji radi pod sistemskim računom, zakazani zadatak i interaktivni prozor upita mogu predstaviti tri različita tokena na istom računaru, a samo zadnji odgovara onome što korisnik vidi kada pokrene whoami.

Pitajte server što je zapravo vidio

Server vam može reći koju je prijavu razriješio i kako se veza autentificirala. Pokrenite upit unutar sesije koja se istražuje, jer administratorova odvojena uspješna veza ništa ne dokazuje o klijentu koji ne uspijeva.

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;

Prvi red razlikuje prijavu koja je otvorila sesiju od sigurnosnog konteksta koji sada vrijedi, a oni se razlikuju pod personifikacijom. Drugi navodi shemu autentifikacije, pa KERBEROS, NTLM i SQL postaju vidljive činjenice umjesto nagađanja. Veza koja prijavljuje NTLM tamo gdje ste očekivali Kerberos je problem razrješavanja imena ili SPN-a, a ne problem lozinke.

Broj greške dodatno sužava stvari. Stanje 5 obično znači da ime prijave uopće nije razriješeno, stanje 8 obično znači da se lozinka nije poklopila, a stanje 11 znači da su akreditivi prihvaćeni, ali pristup serveru nije uspio. Tražite od administratora stanje, a ne cijelu poruku, jer je sama poruka namjerno neodređena.

Kada identitet stigne, a Kerberos i dalje ne uspijeva

Ako server vidi željeni Windows identitet, a integrirana autentifikacija i dalje ne uspijeva, problem je u samoj razmjeni. Kerberos traži ime servisnog principala registrirano za račun SQL servisa i klijenta koji traži servis po imenu koje mu odgovara. Povezivanje po IP adresi ne može odgovarati SPN-u zasnovanom na imenu, a alias može odgovarati samo ako je i on registriran. Provjerite ime koje je klijent upisao prije svega ostalog, jer veza koja radi po imenu hosta i ne uspijeva po IP-u opisuje upravo taj problem.

Zamolite administratora da pregleda registrirani identitet i račun servisa umjesto da stvara duplikate SPN-a metodom pokušaja i pogreške. Duplicirane registracije stvaraju povremene kvarove koje je teže dijagnosticirati od izvornog problema.

Nakon što autentifikacija proradi, prijava još treba korisnika baze i dozvole. Uspješna VPN prijava, uspješna Windows prijava i dozvola za čitanje određene tabele tri su odvojena rezultata i svaki zaslužuje vlastitu provjeru prije nego se tiket zatvori.