Rejestracja SPN

Rejestracja SPN w Active Directory jest niezbędna do prawidłowego działania uwierzytelniania Kerberos z SQL Server.

Rola rejestracji SPN w uwierzytelnianiu SQL Server

Rejestracja SPN, czyli Service Principal Name, wiąże nazwę usługi działającej w domenie Active Directory z konkretnym kontem, na którym uruchomiona jest usługa SQL Server. Klient korzystający z uwierzytelniania Kerberos nie identyfikuje serwera wyłącznie po adresie IP. Na podstawie nazwy połączenia tworzy żądanie biletu dla określonego identyfikatora usługi, a kontroler domeny musi znać konto przypisane do tego identyfikatora. Dla SQL Server najczęściej stosuje się wpisy w postaci MSSQLSvc/nazwa-hosta:port.

Przykładowy SPN może mieć postać MSSQLSvc/sql01.example.local:1433, jeżeli klient łączy się z instancją SQL Server przez nazwę sql01.example.local i port TCP 1433. W środowisku, w którym używana jest nazwa krótka, alias DNS albo inny port, odpowiedni wariant nazwy również musi być uwzględniony w konfiguracji. Samo uruchomienie protokołu TCP lub włączenie uwierzytelniania Windows nie tworzy jeszcze poprawnego powiązania SPN.

Jak SQL Server wykorzystuje nazwę MSSQLSvc

Podczas nawiązywania połączenia klient SQL Server ustala nazwę usługi na podstawie użytej nazwy serwera i portu. Następnie Kerberos wyszukuje w Active Directory obiekt, który posiada taki SPN. Jeżeli wpis istnieje tylko raz i wskazuje konto usługi SQL Server, kontroler domeny może wydać bilet Kerberos dla właściwego podmiotu. SQL Server weryfikuje ten bilet przy użyciu poświadczeń swojego konta usługi.

Jeżeli SPN nie istnieje, klient zwykle nie może uzyskać biletu dla SQL Server i może nastąpić przejście na uwierzytelnianie NTLM, o ile dana konfiguracja na to pozwala. Wtedy logowanie może nadal działać, ale zmieniają się właściwości sesji. Problem staje się widoczny między innymi przy wymaganiu Kerberos, delegowaniu poświadczeń do kolejnej usługi albo przy połączeniach wykonywanych przez aplikację pośredniczącą. W diagnostyce trzeba więc odróżnić brak biletu Kerberos od całkowitego braku możliwości zalogowania.

Istotna jest zgodność nazwy użytej przez klienta z nazwą zapisaną w SPN. Połączenie przez adres IP nie dostarcza takiej samej nazwy usługi jak połączenie przez nazwę DNS. Podobnie alias, nazwa wielokrotna DNS i rzeczywista nazwa komputera mogą prowadzić do różnych identyfikatorów. W przypadku instancji nazwanej znaczenie ma także faktyczny port nasłuchiwania, a nie tylko nazwa instancji widoczna w konfiguracji klienta.

Sprawdzanie wpisów i konta usługi

Podstawowym narzędziem do odczytu SPN w domenie jest polecenie setspn. Wyszukiwanie wpisów zawierających nazwę usługi można wykonać na przykład poleceniem setspn -Q MSSQLSvc/sql01.example.local:1433. Parametr -Q sprawdza, który obiekt Active Directory posiada wskazany identyfikator. Do wyświetlenia wpisów przypisanych do konkretnego konta służy między innymi setspn -L DOMAIN\konto_sql, gdzie konto powinno odpowiadać rzeczywistemu kontu usługi SQL Server.

Niebezpieczna jest duplikacja SPN. Ten sam identyfikator przypisany do dwóch różnych obiektów Active Directory nie wskazuje jednoznacznie konta, które powinno obsłużyć bilet. Do wyszukiwania duplikatów można użyć polecenia setspn -X. Wynik należy interpretować razem z konfiguracją usługi SQL Server, ponieważ wpis przypisany do starego konta, komputera albo nieużywanej instancji może powodować konflikt mimo pozornie poprawnego wpisu dla aktywnego serwera.

Rejestracja może być wykonywana automatycznie przez usługę SQL Server, jeżeli konto usługi ma odpowiednie uprawnienia w Active Directory. Przy koncie domenowym o ograniczonych uprawnieniach administrator może zarejestrować wpis jawnie, używając polecenia w rodzaju setspn -S MSSQLSvc/sql01.example.local:1433 DOMAIN\konto_sql. Parametr -S sprawdza występowanie duplikatu przed dodaniem wpisu. Nie należy bez sprawdzenia kopiować wpisów pomiędzy serwerami, ponieważ SPN musi odpowiadać konkretnej nazwie, portowi i kontu usługi.

Diagnostyka nieudanego użycia Kerberos

Analizę należy rozpocząć od ustalenia dokładnego łańcucha połączenia: nazwy serwera wpisanej przez klienta, użytego aliasu, portu TCP oraz konta, na którym działa usługa SQL Server. Następnie trzeba porównać te dane z wpisami MSSQLSvc w Active Directory. Warto także sprawdzić, czy klient należy do właściwej domeny, czy może uzyskać bilet Kerberos oraz czy zegary systemów nie są znacząco rozbieżne, ponieważ Kerberos wymaga poprawnego czasu w komunikacji domenowej.

Stan uwierzytelniania można zweryfikować po stronie SQL Server, sprawdzając metodę używaną przez bieżącą sesję. Przykładowe zapytanie SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID; zwraca schemat uwierzytelniania dla aktualnego połączenia. Wartość KERBEROS potwierdza użycie Kerberos, natomiast NTLM wskazuje, że sesja nie została uwierzytelniona tym mechanizmem. Sam wynik nie wyjaśnia przyczyny, dlatego powinien być zestawiony z nazwą połączenia i wynikiem wyszukiwania SPN.

Usunięcie lub zmiana wpisu SPN wymaga ostrożności, ponieważ błędna modyfikacja może wpłynąć na inne połączenia korzystające z tego samego konta lub nazwy usługi. Po zmianie należy ponownie sprawdzić unikalność wpisu, wyczyścić albo odświeżyć bilety Kerberos po stronie klienta i wykonać nowe połączenie. Jeżeli problem występuje tylko przez alias, a działa przy rzeczywistej nazwie hosta, wskazuje to na niespójność pomiędzy nazwą używaną przez klienta a identyfikatorem zarejestrowanym w Active Directory.