VPN se připojí, ale SQL Server odmítá ověřování Windows

Tunely se zvednou, servery odpovídají na ping a přihlášení k databázi přesto selhává s chybou ověřování. Tahle kombinace je na VPN spojích běžná a málokdy znamená, že je síť rozbitá, protože dostupný posluchač a přijaté přihlášení jsou různé výsledky. Identita, která uspokojila bránu, nemusí být identita, kterou nabízí databázový klient. Zjistit, který účet dorazil, je celý úkol.

Příznak: dostupný server, odmítnuté přihlášení

Časový limit vám říká, že paket nikdy nedorazil k posluchači. Chyba ověřování vám říká, že posluchač odpověděl a přihlašovací údaje odmítl. Tyto dvě zprávy vás posílají k různým týmům a jejich zaměňování stojí den na pravidlech firewallu, která nikdy nebyla problémem.

Když je chybou neúspěšné přihlášení, přestaňte se dívat na porty. Zbývá otázka, jakou identitu Windows klient předložil, zda ji server přijal a zda se přeložila na databázového uživatele s oprávněním.

Dvě identity, jeden tunel

Účet VPN se ověřuje u brány a ve většině nasazení tam skončí. Databázový klient zvlášť předkládá token Windows, převzatý z procesu, který ho spouští, nebo přihlášení SQL, pokud o ně požádá připojovací řetězec. Lokální uživatel VPN na bráně nemá žádný vztah k doméně, která hostuje SQL Server, a tunel ho nevytváří.

Připojení osobního počítače k VPN ho také nepřipojí k doméně. Přejmenování místního účtu a sladění jeho hesla s uživatelem domény není postup zápisu a vytváří token, který řadič domény jako tohoto uživatele nepřijme.

Někteří nativní klienti vzdáleného přístupu Windows umějí znovu použít přihlašovací údaje VPN pro síťové prostředky, když je jejich profil tak nakonfigurovaný. Takové chování patří konkrétnímu klientovi a profilu, ne VPN připojením obecně, takže ho ověřte pro používaného klienta, místo abyste ho předpokládali.

Přečtěte si režim, který klient požadoval

Připojovací řetězec rozhoduje, kterou cestou ověřování se klient vydá. Integrované zabezpečení používá token Windows; dvojice uživatel a heslo volí přihlášení SQL. To jsou oddělené režimy v konfiguraci serveru a pro daný pokus o připojení může být povolen jen jeden z nich.

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

Přechod na přihlášení SQL proto, že přihlášení Windows selhalo, je obchvat, který zakrývá otázku identity, a obvykle stejně vyžaduje vytvořit nové přihlášení a heslo. Pokud nasazení vyžaduje ověřování Windows, ponechte režim a opravte cestu identity. Přihlášení SQL také potřebuje vlastní oprávnění, takže obchvat kupuje druhý účet k údržbě.

Ověřte také, která aplikace se připojuje. Služba běžící pod systémovým účtem, naplánovaná úloha a interaktivní okno dotazu mohou na stejném počítači předložit tři různé tokeny a jen poslední odpovídá tomu, co uživatel vidí, když spustí whoami.

Zeptejte se serveru, co skutečně viděl

Server vám může říct, které přihlášení přeložil a jak se připojení ověřilo. Spusťte dotaz uvnitř zkoumané relace, protože samostatné úspěšné připojení administrátora nic nedokazuje o selhávajícím 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;

První řádek rozlišuje přihlášení, které relaci otevřelo, od bezpečnostního kontextu platného právě teď, a ty se při zosobnění liší. Druhý uvádí schéma ověřování, takže KERBEROS, NTLM a SQL se stanou viditelnými fakty místo dohadů. Připojení, které hlásí NTLM tam, kde jste čekali Kerberos, je problém překladu názvů nebo SPN, ne problém hesla.

Číslo chyby to dále zužuje. Stav 5 obvykle znamená, že přihlašovací jméno nebylo vůbec přeloženo, stav 8 obvykle znamená, že heslo nesouhlasilo, a stav 11 znamená, že údaje byly přijaty, ale přístup na server selhal. Žádejte po administrátorovi stav, ne celou zprávu, protože zpráva sama je záměrně vágní.

Když identita dorazí a Kerberos stále selhává

Pokud server vidí zamýšlenou identitu Windows a integrované ověřování stále selhává, problém je v samotné výměně. Kerberos potřebuje název služby (SPN) zaregistrovaný pro servisní účet SQL a klienta, který službu žádá pod názvem, který mu odpovídá. Připojení přes IP adresu nemůže odpovídat SPN založenému na názvu a alias může odpovídat jen tehdy, je-li také zaregistrovaný. Zkontrolujte nejdřív název, který klient zadal, protože připojení, které funguje přes název hostitele a selhává přes IP, popisuje přesně tento problém.

Požádejte administrátora, aby prošel registrovanou identitu a servisní účet, místo aby metodou pokus-omyl vytvářel duplicitní SPN. Duplicitní registrace způsobují občasné výpadky, které se diagnostikují hůř než původní problém.

Když ověřování funguje, přihlášení stále potřebuje databázového uživatele a oprávnění. Úspěšné přihlášení VPN, úspěšné přihlášení Windows a oprávnění číst konkrétní tabulku jsou tři samostatné výsledky a každý si zaslouží vlastní kontrolu, než se tiket zavře.