Error 17806 – błąd logowania NT AUTHORITY

Error 17806 dotyczy nieudanego logowania z użyciem uwierzytelniania Windows w kontekście tożsamości NT AUTHORITY.

Co oznacza błąd 17806 w SQL Server

Error 17806 jest komunikatem diagnostycznym silnika Microsoft SQL Server związanym z nieudaną próbą ustanowienia połączenia przy użyciu zintegrowanego uwierzytelniania Windows. W takim trybie klient nie przekazuje do serwera niezależnego hasła SQL, lecz korzysta z biletu i kontekstu bezpieczeństwa systemu Windows. SQL Server musi poprawnie rozpoznać konto użytkownika lub usługę, która inicjuje połączenie, a następnie zaakceptować przedstawione dane uwierzytelniające.

W dzienniku SQL Server błąd 17806 często występuje razem z informacją o nieudanym uzgadnianiu SSPI, czyli Security Support Provider Interface. SSPI jest interfejsem systemu Windows używanym między innymi przez protokół Kerberos oraz mechanizmy negocjowania uwierzytelniania. Sam numer 17806 nie wskazuje jeszcze jednej, konkretnej przyczyny. Oznacza, że etap uzgadniania zabezpieczeń nie zakończył się pomyślnie i połączenie z użyciem uwierzytelniania zintegrowanego zostało odrzucone albo zamknięte.

Rola tożsamości NT AUTHORITY

Przedrostek NT AUTHORITY oznacza w systemie Windows przestrzeń nazw używaną dla wbudowanych kont i tożsamości systemowych. W zależności od sposobu uruchomienia aplikacji lub usługi może pojawić się między innymi NT AUTHORITY\SYSTEM, NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE albo NT AUTHORITY\ANONYMOUS LOGON. Nie są to zwykłe konta lokalne tworzone ręcznie przez użytkownika, lecz tożsamości nadawane przez system procesom działającym na komputerze.

Jeżeli w komunikacie pojawia się NT AUTHORITY\ANONYMOUS LOGON, SQL Server otrzymał połączenie, dla którego nie udało się przekazać prawidłowej tożsamości użytkownika z komputera klienckiego do komputera serwera. Taki przypadek może wynikać z nieudanego przekazania poświadczeń pomiędzy komputerami, nieprawidłowej konfiguracji konta usługi, problemu z delegowaniem w domenie albo użycia ścieżki połączenia, przy której Kerberos nie może zostać zastosowany. Sama obecność napisu NT AUTHORITY nie dowodzi jeszcze, że uszkodzone jest konto systemowe. Trzeba ustalić, jaka aplikacja, usługa lub zadanie utworzyło połączenie.

SSPI, Kerberos i przyczyny odrzucenia połączenia

W środowisku domenowym SQL Server może używać Kerberos, gdy klient łączy się z właściwą nazwą usługi, a dla konta uruchamiającego SQL Server istnieje poprawnie zarejestrowany Service Principal Name, czyli SPN. SPN wiąże nazwę usługi z kontem, pod którym działa usługa SQL Server. Jeżeli brakuje wymaganego SPN, SPN wskazuje inne konto, występują duplikaty albo klient używa aliasu i nazwy, której domena nie potrafi jednoznacznie powiązać, negocjowanie Kerberos może się nie udać. W określonych sytuacjach system próbuje wtedy użyć NTLM, lecz nie każdy scenariusz przekazywania tożsamości może zostać przez ten mechanizm obsłużony.

Źródłem problemu może być także zmiana hasła konta usługi bez prawidłowego ponownego uruchomienia usług, różnica czasu między komputerami domenowymi, utrata zaufania do domeny, niedostępność kontrolera domeny, błędna rozdzielczość nazwy DNS lub połączenie wykonywane przez dodatkową warstwę aplikacyjną. Znaczenie ma również sposób uruchomienia programu: aplikacja działająca jako usługa systemowa może przedstawiać inną tożsamość niż ten sam program uruchomiony interaktywnie przez zalogowanego użytkownika. Błąd 17806 należy więc analizować razem z dokładnym komunikatem SSPI, kodem błędu Windows, wpisem logowania SQL Server oraz informacjami z dziennika systemowego.

Metodyka sprawdzenia błędu w konkretnej instalacji

Najpierw należy ustalić, czy problem dotyczy wszystkich klientów, czy tylko jednego komputera albo jednej aplikacji. Warto porównać połączenie wykonywane nazwą hosta, pełną nazwą domenową oraz ewentualnym aliasem, ponieważ różne nazwy mogą prowadzić do odmiennych prób uwierzytelniania. Trzeba również sprawdzić, pod jakim kontem działa usługa SQL Server i pod jakim kontem działa aplikacja kliencka. W przypadku NT AUTHORITY\ANONYMOUS LOGON istotne jest określenie, w którym miejscu przepływu żądania tożsamość użytkownika została utracona.

W dzienniku SQL Server należy odszukać wpisy występujące bezpośrednio przed i po błędzie 17806, zwłaszcza komunikaty dotyczące SSPI, rejestracji SPN, konta usługi oraz nieudanego logowania. Po stronie Windows sprawdza się stan członkostwa komputera w domenie, działanie DNS, synchronizację czasu i dostępność kontrolera domeny. Administrator domeny może zweryfikować, czy SPN dla usługi SQL Server jest przypisany do właściwego konta i czy nie występuje więcej niż jeden wpis dla tej samej nazwy usługi. Nie należy usuwać ani dopisywać SPN na podstawie samego numeru 17806, ponieważ błędna modyfikacja może spowodować kolejne konflikty uwierzytelniania. Po usunięciu przyczyny trzeba ponowić test z tą samą nazwą serwera, tym samym kontem i tą samą aplikacją, która pierwotnie wygenerowała błąd.