VPN się łączy, ale SQL Server odrzuca uwierzytelnianie Windows

Tunele wstają, serwery odpowiadają na ping, a logowanie do bazy nadal kończy się błędem uwierzytelniania. Ten układ jest częsty na łączach VPN i rzadko oznacza, że sieć jest zepsuta, ponieważ osiągalny nasłuchiwacz i zaakceptowane logowanie to dwa różne wyniki. Tożsamość, która zadowoliła bramę, nie musi być tożsamością, którą przedstawia klient bazy. Ustalenie, które konto dotarło, to całe zadanie.

Objaw: osiągalny serwer, odrzucone logowanie

Przekroczenie limitu czasu mówi, że pakiet nigdy nie dotarł do nasłuchiwacza. Błąd uwierzytelniania mówi, że nasłuchiwacz odpowiedział i odrzucił poświadczenie. Te dwa komunikaty kierują cię do różnych zespołów, a mieszanie ich kosztuje dzień na regułach zapory, które nigdy nie były problemem.

Gdy błąd to nieudane logowanie, przestań patrzeć na porty. Pozostaje pytanie, jaką tożsamość Windows przedstawił klient, czy serwer ją przyjął i czy została rozwiązana na użytkownika bazy z uprawnieniem.

Dwie tożsamości, jeden tunel

Konto VPN uwierzytelnia się na bramie i w większości wdrożeń tam się kończy. Klient bazy osobno przedstawia token Windows, pobrany z procesu, który go uruchamia, albo logowanie SQL, jeśli wymaga go ciąg połączenia. Lokalny użytkownik VPN na bramie nie ma żadnego związku z domeną, która hostuje SQL Server, a tunel takiego związku nie tworzy.

Podłączenie prywatnego komputera do VPN również nie włącza go do domeny. Zmiana nazwy konta lokalnego i dopasowanie jego hasła do użytkownika domeny nie jest procedurą przyłączania i daje token, którego kontroler domeny nie zaakceptuje jako tego użytkownika.

Niektóre natywne klienty zdalnego dostępu Windows mogą ponownie użyć poświadczenia VPN dla zasobów sieciowych, gdy ich profil jest tak skonfigurowany. To zachowanie należy do konkretnego klienta i profilu, a nie do połączeń VPN w ogóle, więc sprawdź je dla używanego klienta, zamiast zakładać.

Odczytaj tryb, o który prosił klient

Ciąg połączenia decyduje, którą ścieżkę uwierzytelniania obierze klient. Zintegrowane zabezpieczenia korzystają z tokenu Windows; para użytkownika i hasła wybiera logowanie SQL. To osobne tryby w konfiguracji serwera i dla danej próby połączenia można włączyć tylko jeden z nich.

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

Przejście na logowanie SQL, bo logowanie Windows nie powiodło się, jest obejściem, które ukrywa pytanie o tożsamość, i zwykle i tak wymaga utworzenia nowego logowania i hasła. Jeśli wdrożenie wymaga uwierzytelniania Windows, zachowaj tryb i napraw ścieżkę tożsamości. Logowanie SQL też potrzebuje własnych uprawnień, więc obejście kupuje drugie konto do utrzymania.

Sprawdź też, która aplikacja się łączy. Usługa działająca jako konto systemowe, zadanie zaplanowane i okno zapytania interaktywnego mogą przedstawić trzy różne tokeny na tej samej maszynie, a tylko ostatni odpowiada temu, co użytkownik widzi, uruchamiając whoami.

Zapytaj serwer, co naprawdę widział

Serwer może powiedzieć, które logowanie rozwiązał i jak połączenie zostało uwierzytelnione. Uruchom zapytanie wewnątrz badanej sesji, ponieważ osobne udane połączenie administratora niczego nie dowodzi o zawodzącym kliencie.

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;

Pierwszy wiersz odróżnia logowanie, które otworzyło sesję, od kontekstu zabezpieczeń obowiązującego teraz, a różnią się one przy podszywaniu się. Drugi podaje schemat uwierzytelniania, więc KERBEROS, NTLM i SQL stają się widocznymi faktami zamiast domysłami. Połączenie, które zgłasza NTLM tam, gdzie oczekiwano Kerberos, to problem rozwiązywania nazw lub SPN, a nie problem hasła.

Numer błędu zawęża to dalej. Stan 5 zwykle oznacza, że nazwa logowania w ogóle nie została rozwiązana, stan 8 zwykle oznacza, że hasło nie pasowało, a stan 11 oznacza, że poświadczenie przyjęto, ale dostęp do serwera się nie powiódł. Poproś administratora o stan, a nie o cały komunikat, ponieważ sam komunikat jest celowo niejasny.

Gdy tożsamość dociera, a Kerberos nadal zawodzi

Jeśli serwer widzi zamierzoną tożsamość Windows, a uwierzytelnianie zintegrowane nadal zawodzi, problemem jest sama wymiana. Kerberos wymaga nazwy głównej usługi zarejestrowanej dla konta usługi SQL oraz klienta, który prosi o usługę pod pasującą nazwą. Połączenie przez adres IP nie może pasować do SPN opartego na nazwie, a alias może pasować tylko wtedy, gdy również jest zarejestrowany. Najpierw sprawdź nazwę wpisaną przez klienta, ponieważ połączenie działające po nazwie hosta i zawodzące po IP opisuje dokładnie ten problem.

Poproś administratora o przejrzenie zarejestrowanej tożsamości i konta usługi, zamiast tworzyć zduplikowane SPN metodą prób i błędów. Zduplikowane rejestracje powodują okresowe awarie, które trudniej zdiagnozować niż pierwotny problem.

Gdy uwierzytelnianie działa, logowanie nadal potrzebuje użytkownika bazy i uprawnień. Udane logowanie VPN, udane logowanie Windows i uprawnienie do czytania konkretnej tabeli to trzy odrębne wyniki, a każdy zasługuje na własną kontrolę przed zamknięciem zgłoszenia.