SQL Server Active Directory Helper

SQL Server Active Directory Helper to usługa wspierająca rejestrację SPN i integrację z usługą katalogową.

Rola usługi SQL Server Active Directory Helper

SQL Server Active Directory Helper to składnik instalowany wraz z Microsoft SQL Server, którego zadaniem jest wspieranie współpracy instancji silnika z usługą Active Directory Domain Services. Nie jest to osobny silnik bazy danych ani narzędzie do wykonywania zapytań SQL. Usługa działa w systemie Windows jako element pomocniczy dla scenariuszy, w których SQL Server korzysta z uwierzytelniania Windows, kont domenowych oraz mechanizmu Kerberos.

Najważniejszym obszarem jej działania jest obsługa nazw głównych usług, czyli SPN (Service Principal Name). SPN pozwala klientowi jednoznacznie powiązać usługę SQL Server z kontem, na którym działa dana instancja. Dzięki temu klient może uzyskać bilet Kerberos dla właściwej usługi, zamiast przechodzić do uwierzytelniania NTLM. SQL Server Active Directory Helper nie zastępuje kontrolera domeny, serwera DNS ani usługi Kerberos; pomaga natomiast w rejestracji i utrzymaniu informacji potrzebnych do ich współdziałania.

SPN, konto usługi i uwierzytelnianie Kerberos

Podczas uruchamiania instancja SQL Server może próbować zarejestrować w Active Directory SPN odpowiadający używanej nazwie sieciowej i portowi TCP. Dla usługi SQL Server spotykany jest typ SPN MSSQLSvc, a pełna wartość może zawierać w pełni kwalifikowaną nazwę domenową serwera oraz numer portu, na przykład MSSQLSvc/sql01.example.local:1433. W środowisku z nazwanymi instancjami lub alternatywnymi nazwami połączeń mogą występować również dodatkowe wpisy odpowiadające konkretnej konfiguracji. Ostateczna wartość musi być zgodna z nazwą, której klient rzeczywiście używa do połączenia, oraz z kontem usługi SQL Server.

Automatyczna rejestracja SPN zależy od uprawnień konta uruchamiającego usługę. Konto usługi musi mieć w Active Directory prawo do zapisu odpowiednich atrybutów swojego obiektu albo administrator domeny musi zarejestrować SPN ręcznie. Jeżeli wpis nie powstanie, zostanie przypisany do niewłaściwego konta albo będzie występował więcej niż raz, Kerberos może nie działać prawidłowo. Duplikat SPN jest szczególnie istotnym błędem, ponieważ kontroler domeny nie może wtedy jednoznacznie ustalić, dla którego konta ma wystawić bilet.

Objawy nieprawidłowej konfiguracji w SQL Server

Awaria lub nieprawidłowa konfiguracja SQL Server Active Directory Helper nie musi zatrzymać samego silnika bazy danych. Instancja SQL Server może nadal przyjmować połączenia, ale klienci domenowi mogą korzystać z NTLM zamiast Kerberos. W praktyce wpływa to na dostępne mechanizmy uwierzytelniania i może mieć znaczenie dla środowisk używających delegowania poświadczeń, połączeń wielowarstwowych albo usług zależnych od poprawnej identyfikacji serwera w domenie.

Podczas diagnozy należy porównać kilka niezależnych informacji: konto usługi SQL Server, nazwę hosta używaną przez klienta, konfigurację protokołu TCP, numer portu nasłuchu oraz wpisy SPN w Active Directory. Do odczytu wpisów przypisanych do konta można użyć narzędzia systemowego setspn, na przykład polecenia setspn -L domena\konto_sql. W dziennikach SQL Server i Podglądzie zdarzeń Windows warto sprawdzić komunikaty dotyczące rejestracji SPN, braku uprawnień oraz problemów z rozpoznaniem nazwy. Sam fakt, że usługa pomocnicza jest uruchomiona, nie potwierdza jeszcze poprawności Kerberos; konieczna jest zgodność wpisów SPN z rzeczywistą ścieżką połączenia.

Bezpieczna diagnostyka usługi i wpisów domenowych

Sprawdzanie należy rozpocząć od ustalenia, czy usługa SQL Server Active Directory Helper jest obecna w danej instalacji oraz jaki ma stan w konsoli usług Windows. Następnie trzeba potwierdzić, czy główna usługa SQL Server działa na koncie lokalnym, wbudowanym koncie systemowym czy koncie domenowym. Każda zmiana konta usługi, nazwy komputera, aliasu DNS, portu TCP lub konfiguracji instancji może wymagać ponownej weryfikacji SPN. Szczególnej ostrożności wymaga ręczne usuwanie wpisów, ponieważ skasowanie SPN należącego do innej instancji może zakłócić jej uwierzytelnianie.

W przypadku problemu należy najpierw zebrać dane konfiguracyjne i komunikaty diagnostyczne, a dopiero potem modyfikować Active Directory. Trzeba sprawdzić, czy nazwa DNS rozwiązuje się na właściwy adres, czy klient łączy się z oczekiwanym portem oraz czy wpisy MSSQLSvc są unikatowe i przypisane do właściwego konta. Po korekcie uprawnień lub SPN zwykle konieczne jest ponowne uruchomienie usługi SQL Server oraz odtworzenie połączenia klienta, aby uzyskać nowy bilet Kerberos. W środowisku produkcyjnym operacje na kontach domenowych i SPN powinny być wykonywane przez administratora posiadającego odpowiednie uprawnienia, z zachowaniem istniejącej konfiguracji instancji i kontrolą skutków zmiany.