VPN sa pripojí, ale SQL Server odmieta overovanie Windows

Tunely sa zdvihnú, servery odpovedajú na ping a prihlásenie do databázy napriek tomu zlyháva s chybou overovania. Táto kombinácia je na VPN spojoch bežná a málokedy znamená, že je sieť pokazená, pretože dostupný poslucháč a prijaté prihlásenie sú dva rôzne výsledky. Identita, ktorá uspokojila bránu, nemusí byť identita, ktorú ponúka databázový klient. Zistiť, ktorý účet dorazil, je celá úloha.

Príznak: dostupný server, odmietnuté prihlásenie

Časový limit vám hovorí, že paket nikdy nedorazil k poslucháčovi. Chyba overovania hovorí, že poslucháč odpovedal a prihlasovacie údaje odmietol. Tieto dve správy vás posielajú k rôznym tímom a ich zámena stojí deň na pravidlách firewallu, ktoré nikdy neboli problémom.

Keď je chybou neúspešné prihlásenie, prestaňte sa pozerať na porty. Zostáva otázka, akú identitu Windows klient predložil, či ju server prijal a či sa preložila na databázového používateľa s oprávnením.

Dve identity, jeden tunel

Účet VPN sa overuje na bráne a vo väčšine nasadení tam aj končí. Databázový klient zvlášť predkladá token Windows, prevzatý z procesu, ktorý ho spúšťa, alebo prihlásenie SQL, ak oň požiada pripojovací reťazec. Lokálny používateľ VPN na bráne nemá žiadny vzťah k doméne, ktorá hostuje SQL Server, a tunel ho nevytvára.

Pripojenie osobného počítača k VPN ho tiež nezapíše do domény. Premenovanie miestneho účtu a zladenie jeho hesla s používateľom domény nie je postup zápisu a vytvára token, ktorý radič domény ako tohto používateľa neprijme.

Niektorí natívni klienti vzdialeného prístupu Windows dokážu znovu použiť prihlasovacie údaje VPN pre sieťové prostriedky, keď je ich profil tak nakonfigurovaný. Také správanie patrí konkrétnemu klientovi a profilu, nie VPN pripojeniam všeobecne, preto ho overte pre používaného klienta, namiesto toho aby ste ho predpokladali.

Prečítajte si režim, ktorý klient požadoval

Pripojovací reťazec rozhoduje, ktorou cestou overovania sa klient vydá. Integrované zabezpečenie používa token Windows; dvojica používateľ a heslo volí prihlásenie SQL. Sú to oddelené režimy v konfigurácii servera a pre daný pokus o pripojenie môže byť povolený len jeden z nich.

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

Prechod na prihlásenie SQL preto, že prihlásenie Windows zlyhalo, je obchádzka, ktorá zakrýva otázku identity, a zvyčajne aj tak vyžaduje vytvoriť nové prihlásenie a heslo. Ak nasadenie vyžaduje overovanie Windows, ponechajte režim a opravte cestu identity. Prihlásenie SQL tiež potrebuje vlastné oprávnenia, takže obchádzka kupuje druhý účet na údržbu.

Overte aj to, ktorá aplikácia sa pripája. Služba bežiaca pod systémovým účtom, naplánovaná úloha a interaktívne okno dotazu môžu na tom istom počítači predložiť tri rôzne tokeny a len posledný zodpovedá tomu, čo používateľ vidí, keď spustí whoami.

Opýtajte sa servera, čo skutočne videl

Server vám môže povedať, ktoré prihlásenie preložil a ako sa pripojenie overilo. Spustite dotaz vnútri skúmanej relácie, pretože samostatné úspešné pripojenie správcu nič nedokazuje o zlyhávajúcom klientovi.

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;

Prvý riadok odlišuje prihlásenie, ktoré otvorilo reláciu, od bezpečnostného kontextu platného práve teraz, a pri zosobnení sa líšia. Druhý uvádza schému overovania, takže KERBEROS, NTLM a SQL sa stanú viditeľnými faktami namiesto dohadov. Pripojenie, ktoré hlási NTLM tam, kde ste čakali Kerberos, je problém prekladu názvov alebo SPN, nie problém hesla.

Číslo chyby to ďalej zužuje. Stav 5 zvyčajne znamená, že prihlasovacie meno nebolo vôbec preložené, stav 8 zvyčajne znamená, že heslo nesedelo, a stav 11 znamená, že údaje boli prijaté, ale prístup na server zlyhal. Požiadajte správcu o stav, nie o celú správu, pretože správa sama je zámerne neurčitá.

Keď identita dorazí a Kerberos stále zlyháva

Ak server vidí zamýšľanú identitu Windows a integrované overovanie stále zlyháva, problémom je samotná výmena. Kerberos potrebuje názov služby (SPN) zaregistrovaný pre servisný účet SQL a klienta, ktorý službu žiada pod zodpovedajúcim názvom. Pripojenie cez IP adresu nemôže zodpovedať SPN založenému na názve a alias môže zodpovedať len vtedy, ak je tiež zaregistrovaný. Najprv skontrolujte názov, ktorý klient zadal, pretože pripojenie, ktoré funguje cez názov hostiteľa a zlyháva cez IP, opisuje presne tento problém.

Požiadajte správcu, aby prešiel zaregistrovanú identitu a servisný účet, namiesto toho aby metódou pokus-omyl vytváral duplicitné SPN. Duplicitné registrácie spôsobujú občasné výpadky, ktoré sa diagnostikujú ťažšie ako pôvodný problém.

Keď overovanie funguje, prihlásenie stále potrebuje databázového používateľa a oprávnenia. Úspešné prihlásenie VPN, úspešné prihlásenie Windows a oprávnenie čítať konkrétnu tabuľku sú tri samostatné výsledky a každý si zaslúži vlastnú kontrolu pred uzavretím tiketu.