Dlaczego SQL Server przez VPN nadal wraca do NTLM?

Połączenie działa, logowanie jest akceptowane, a SQL Server używa NTLM, podczas gdy wszyscy oczekiwali Kerberos. Ten wynik nie jest defektem VPN, ponieważ tunel dostarcza tylko ścieżkę; schemat określiły nazwa zażądana przez klienta, podmiot zabezpieczeń zarejestrowany w katalogu i bilet, który klient faktycznie mógł uzyskać. Trzy warunki muszą być spełnione jednocześnie, a sama sesja mówi, który ustąpił. Przeczytaj to, zanim ktokolwiek zmodyfikuje nazwę główną usługi.

Sesja nazywa schemat, który faktycznie otrzymałeś

Schemat uwierzytelniania należy do połączenia, a nie do serwera czy tunelu, więc sprawdzenie musi działać wewnątrz sesji, na której ci zależy. Wykonaj poniższe zapytanie z tego samego klienta, narzędzia i konta, które utworzyły raport, i zapisz nazwę celu oraz transport obok wyniku.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Wiersz z lokalnego okna SSMS na hoście bazy danych opisuje zupełnie inne połączenie, dlatego zapytanie musi być wykonane po stronie klienta. Zapisz dane wyjściowe ze znacznikiem czasu, ponieważ następna osoba, która je przeczyta, zapyta, kiedy je pobrano. Gdy kilka aplikacji współdzieli jeden punkt końcowy, pobierz próbkę z każdej, ponieważ różnica źródła danych między dwiema aplikacjami często jest całą historią.

Warunek pierwszy: czy nazwa pasuje do SPN?

Kerberos uwierzytelnia nazwaną usługę, więc klient prosi katalog o bilet dla jednego konkretnego podmiotu. Dla dostawcy TCP udokumentowana forma to MSSQLSvc/, po której następuje w pełni kwalifikowana nazwa hosta, a dla domyślnej instancji port. Nazwana instancja rejestruje MSSQLSvc/db01.corp.example:SQLPROD, gdzie sufiksem jest nazwa instancji zamiast numeru. Osiągnięcie odbiornika przez alias, CNAME rozwiązywany gdzie indziej lub goły adres IP zmienia żądaną nazwę, a żądanie bez pasującego podmiotu nie ma biletu do zwrócenia.

Dlatego jedna aplikacja działa w jednej sieci, a w innej wraca do NTLM: odpowiedź DNS, rekord aliasu lub wpis hosts zmieniły nazwę używaną przez klienta. Porównaj żądaną nazwę z tym, co zawiera katalog, zanim dotkniesz rejestracji.

Warunek drugi: czy SPN jest na właściwym koncie?

SPN musi należeć do konta, które uruchamia usługę SQL, a nie do konta klienta i nie przypadkowo do obiektu komputera. SQL Server może rejestrować własne SPN przy uruchomieniu, gdy jego konto usługi ma uprawnienie do ich zapisywania, co jest wygodne i wyjaśnia, jak po zmianie konta usługi pojawia się duplikat.

Zapytaj katalog o oczekiwaną nazwę, a następnie wylistuj, co konto rzeczywiście posiada. Który obiekt przechowuje wpis, ma większe znaczenie niż to, czy nazwa istnieje gdzieś w lesie. Niezgodność oznacza, że logowanie nigdy nie było problemem, a przewodnik SPN firmy Microsoft dokumentuje formaty i przypadki, w których administrator domeny musi utworzyć wpis.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Dodanie kolejnego wpisu nie jest bezpiecznym eksperymentem. Duplikat lub sprzeczna rejestracja może zepsuć działających klientów, więc sprawdź własność przed zmianą i ponownie po niej.

Warunek trzeci: czy klient w ogóle może uzyskać bilet?

Prawidłowy SPN jest bezużyteczny, jeśli klient nie może dotrzeć do kontrolera domeny lub nie ma użytecznego kontekstu poświadczeń. Wymiana wymaga KDC i DNS przez VPN, a tunel, który trasuje tylko port SQL, zawodzi właśnie na tym kroku. Osiągalność trzeba testować z tej samej maszyny i tego samego konta, a nie z zapory przed nimi.

Sprawdź pamięć podręczną biletów na maszynie i pod kontem uruchamiającym aplikację. Lista obejmująca całą maszynę z okna z podwyższonymi uprawnieniami nic nie mówi o usłudze działającej jako inny użytkownik, a pusty cache tego użytkownika jest ustaleniem, a nie niedogodnością.

klist
klist -li 0x3e7

Następnie zdecyduj, co może robić rezerwowe zachowanie. Jeśli polityka wymaga Kerberos, NTLM musi być jawnie odrzucany, ponieważ ciche przejście zamienia błąd konfiguracji w działające połączenie naruszające wymóg. Jeśli NTLM pozostaje akceptowalny dla niektórych aplikacji, nazwij je i przestań traktować każdą sesję NTLM jako incydent.

Zmiana programu startowego to jedna zmienna, nie poprawka

Uruchomienie SSMS z innymi poświadczeniami może wyleczyć niezamierzoną tożsamość wychodzącą, co jest prawdziwą klasą problemów. Nic nie dowodzi o nazwie celu, rejestracji czy ścieżce biletu i nie zmienia tego, co zaakceptował serwer.

Utrzymaj porównanie pod kontrolą: ten sam punkt końcowy, ten sam dostawca, znany kontekst wykonania, a następnie nowe połączenie, którego schemat sprawdzasz. Potwierdź zaakceptowane logowanie i jego uprawnienia w bazie osobno, ponieważ dostęp i uwierzytelnianie zawodzą z różnych powodów.

Gdy wymagany jest Kerberos, zanotuj, dlaczego pierwsza ścieżka ustąpiła, zastosuj jedną poprawkę i ponownie wykonaj zapytanie z tego samego klienta. Udane zapytanie po zmianie programu startowego jest dowodem dostępu i jeszcze nie jest dowodem spełnienia wymogu uwierzytelniania.