Obsługa SPN

Obsługa SPN to rejestracja nazwy usługi w Active Directory, niezbędna do działania uwierzytelniania Kerberos.

SPN jako identyfikator usługi w Active Directory

SPN, czyli Service Principal Name, jest atrybutem obiektu w usłudze Active Directory używanym przez protokół Kerberos do powiązania nazwy usługi z kontem, które ją uruchamia. Nie jest to osobne konto ani hasło. Jest to nazwa rozpoznawana przez kontroler domeny podczas wyszukiwania podmiotu uprawnionego do odebrania biletu Kerberos dla konkretnej usługi. Dzięki temu klient może poprosić o bilet dla usługi działającej pod określonym kontem, zamiast uwierzytelniać się wyłącznie na podstawie nazwy komputera.

Typowy SPN ma postać złożoną z klasy usługi oraz nazwy hosta, na przykład HTTP/app01.example.local albo MSSQLSvc/db01.example.local:1433. Pierwsza część wskazuje rodzaj usługi, natomiast dalsza część identyfikuje host i, zależnie od usługi, numer portu lub dodatkowy parametr. Dokładny format zależy od aplikacji korzystającej z Kerberos. Wpis SPN jest przechowywany najczęściej w atrybucie servicePrincipalName obiektu użytkownika, konta usługi zarządzanego przez gMSA albo obiektu komputera.

Podczas uwierzytelniania klient ustala nazwę SPN wymaganą przez aplikację i przekazuje ją do kontrolera domeny w żądaniu biletu usługowego. Kontroler odszukuje obiekt posiadający taki wpis i wystawia bilet zaszyfrowany z użyciem klucza powiązanego z tym obiektem. Jeżeli SPN wskazuje niewłaściwe konto, usługa może nie być w stanie odszyfrować biletu. Jeżeli wpisu brakuje, klient często przechodzi do innego mechanizmu uwierzytelniania albo otrzymuje błąd logowania.

Rejestracja i przypisanie nazwy usługi

Rejestracja SPN polega na dodaniu konkretnej nazwy do atrybutu odpowiedniego obiektu Active Directory. W środowisku Windows można do tego użyć narzędzia setspn.exe. Przykładowa składnia przypisania nazwy HTTP do konta usługi wygląda następująco: setspn -S HTTP/app01.example.local EXAMPLE\svc-web. Parametr -S dodaje wpis i sprawdza, czy identyczny SPN nie występuje już w katalogu. W nazwie konta należy użyć rzeczywistej nazwy domeny oraz konta, a sam SPN musi odpowiadać nazwie używanej przez klientów.

W przypadku usług powiązanych z portem port jest częścią identyfikatora. Dla usługi SQL Server przykładowa nazwa ma format MSSQLSvc/db01.example.local:1433, ale jej zastosowanie powinno odpowiadać rzeczywistej konfiguracji instancji i konta usługi. Nie można zastępować nazwy hosta przypadkowym aliasem ani pomijać numeru portu, jeżeli aplikacja tworzy właśnie taki identyfikator. W przeciwnym razie klient może żądać biletu dla innego SPN niż ten, który został zarejestrowany.

Do sprawdzenia wpisów przypisanych do konta służy polecenie setspn -L EXAMPLE\svc-web. Wyszukiwanie powtórzonych nazw można wykonać poleceniem setspn -X, a sprawdzenie konkretnego identyfikatora poleceniem setspn -Q HTTP/app01.example.local. Wynik należy interpretować razem z konfiguracją aplikacji, nazwą DNS używaną przez klienta oraz kontem, pod którym działa proces. Sam fakt obecności wpisu nie dowodzi jeszcze, że aplikacja korzysta z niego poprawnie.

Duplikaty SPN i błędy uwierzytelniania Kerberos

SPN powinien być jednoznaczny w obrębie katalogu. Duplikat oznacza, że ten sam identyfikator został przypisany do więcej niż jednego obiektu. Kontroler domeny nie ma wtedy wiarygodnej informacji, z którym kontem należy powiązać bilet usługowy. Objawem może być nieudane logowanie Kerberos, komunikat o błędzie zabezpieczeń, użycie NTLM zamiast Kerberos albo różne zachowanie zależnie od kontrolera domeny i użytej nazwy hosta.

Częstą przyczyną problemu jest ręczne przeniesienie usługi na inne konto bez usunięcia starego SPN. Podobna sytuacja występuje po zmianie nazwy komputera, wdrożeniu aliasu DNS albo skopiowaniu konfiguracji między środowiskami. Do usunięcia nieaktualnego wpisu używa się polecenia setspn -D HTTP/app01.example.local EXAMPLE\old-service, natomiast poprawny wpis można dodać do właściwego konta poleceniem setspn -S. Usuwanie powinno obejmować wyłącznie potwierdzoną, nieużywaną nazwę, ponieważ skasowanie aktywnego SPN może przerwać uwierzytelnianie.

Na wynik wpływa również dokładna forma nazwy. HTTP/app01, HTTP/app01.example.local oraz wpis odnoszący się do aliasu nie są automatycznie tym samym tekstem. Kerberos korzysta z SPN przekazanego przez klienta, dlatego diagnostyka powinna ustalić, jaką nazwę usługi rzeczywiście generuje aplikacja. Przydatne są także bilety zapisane na komputerze klienta. Polecenie klist pokazuje bilety Kerberos w bieżącej sesji, a klist purge usuwa bilety z pamięci użytkownika, aby po zmianie konfiguracji wymusić ponowne ich pobranie.

Zakres sprawdzenia konfiguracji SPN

Rzetelna weryfikacja zaczyna się od ustalenia konta procesu, nazwy usługi widocznej dla klienta oraz pełnej nazwy hosta używanej w połączeniu. Następnie porównuje się te informacje z wpisami servicePrincipalName w Active Directory. Należy sprawdzić, czy istnieje dokładnie jeden pasujący SPN, czy nie ma jego kopii na innym obiekcie oraz czy wpis wskazuje konto posiadające klucz odpowiadający aktualnym poświadczeniom usługi.

Warto rozdzielić problem katalogowy od problemu aplikacji. Brak lub duplikat SPN może uniemożliwiać poprawne uzyskanie biletu, ale podobny objaw może powodować błędny DNS, niezgodna nazwa hosta, różnica czasu między komputerem a kontrolerem domeny albo wyłączona obsługa Kerberos po stronie aplikacji. Samo dodanie wpisu nie naprawi sytuacji, w której klient łączy się pod inną nazwą niż ta zarejestrowana w katalogu. Po zmianach należy ponowić test z rzeczywistego klienta i sprawdzić, czy pojawił się bilet dla właściwego SPN.

Obsługa SPN wymaga dostępu administracyjnego do odpowiednich obiektów Active Directory oraz znajomości zależności między usługą, kontem i nazwą używaną w sieci. Zmiana wpisów bez wcześniejszego sprawdzenia może spowodować konflikt z inną usługą. Jeżeli problem z Kerberos występuje na laptopie lub komputerze PC, można rozpocząć od zebrania informacji o nazwie hosta, koncie logowania, komunikacie błędu i wyniku poleceń diagnostycznych, a następnie zweryfikować spójność konfiguracji z działaniem konkretnej aplikacji.