SQL Server Configuration Manager i konta AD

Konta AD w Configuration Manager konfiguruje się jako tożsamość, w kontekście której działają usługi serwera.

Rola kont AD w SQL Server Configuration Manager

SQL Server Configuration Manager służy między innymi do ustawiania tożsamości, pod którą działają usługi należące do instalacji Microsoft SQL Server. W przypadku konta Active Directory jest to zwykle konto domenowe wskazane dla usługi aparatu bazy danych SQL Server, SQL Server Agent albo innej zainstalowanej usługi. Konto nie jest użytkownikiem bazy danych tylko dlatego, że zostało wybrane w Configuration Manager. Najpierw jest to tożsamość systemowa usługi Windows, a dopiero później można nadać jej odpowiednie uprawnienia w instancji SQL Server lub w systemie operacyjnym.

W konfiguracji usługi podaje się nazwę konta w postaci domena\użytkownik oraz jego hasło, jeżeli używane jest klasyczne konto domenowe. Configuration Manager zapisuje ustawienia w sposób właściwy dla usługi i może nadać lub zaktualizować wymagane prawa systemowe. Zmiana konta poza tym narzędziem, na przykład bezpośrednio w konsoli usług Windows, może spowodować niespójność konfiguracji i brak przypisania uprawnień wymaganych przez SQL Server. Przy zmianie tożsamości należy również sprawdzić dostęp do katalogów danych, plików dziennika, kopii zapasowych, kluczy certyfikatów oraz zasobów sieciowych używanych przez daną usługę.

Dobór tożsamości usługi i zakres jej uprawnień

Konto domenowe powinno mieć wyłącznie uprawnienia potrzebne do pracy konkretnej usługi. Dla aparatu SQL Server istotne są między innymi prawa do plików danych i dzienników transakcji oraz do katalogów wskazanych w konfiguracji instancji. SQL Server Agent może dodatkowo wykonywać zadania, które korzystają z udziałów sieciowych, podsystemów systemu operacyjnego lub innych usług. Nie oznacza to jednak, że konto usługi powinno należeć do administratorów domeny albo lokalnej grupy Administratorzy. Takie rozszerzenie uprawnień zwiększa zakres skutków przejęcia konta i nie jest wymagane do standardowego uruchomienia silnika.

W środowiskach domenowych można stosować także konta zarządzane, jeżeli są obsługiwane przez daną wersję systemu Windows, konfigurację domeny i używaną wersję SQL Server. Konto gMSA korzysta z automatycznego zarządzania hasłem przez Active Directory, dlatego administrator nie wpisuje w Configuration Manager stałego hasła użytkownika. Trzeba jednak wcześniej przygotować konto w domenie, zezwolić konkretnemu komputerowi lub grupie komputerów na pobieranie hasła i potwierdzić zgodność z wymaganiami wdrożenia. Konto lokalne, konto wirtualne lub Local System to odrębne typy tożsamości i nie należy utożsamiać ich z kontem AD.

Po zmianie konta mogą pojawić się błędy, jeżeli w SQL Server pozostały uprawnienia przypisane do poprzedniej tożsamości. Dotyczy to także dostępu do zaszyfrowanych zasobów, certyfikatów i kluczy prywatnych. Samo dodanie nowego konta do grupy domenowej nie zawsze rozwiązuje problem, ponieważ usługa może wymagać bezpośredniego dostępu do określonej ścieżki lub zasobu. Uprawnienia powinny być sprawdzane na rzeczywistym koncie usługi, z uwzględnieniem dziedziczenia oraz lokalizacji plików używanych przez instancję.

Powiązanie konta AD z usługami SQL Server

W Configuration Manager należy rozróżniać usługę aparatu SQL Server od SQL Server Agent, SQL Server Browser i innych składników. Każda usługa może działać w innym kontekście zabezpieczeń. Konto używane przez aparat nie staje się automatycznie kontem SQL Server Agent, a uprawnienia nadane jednej usłudze nie powinny być traktowane jako wspólne dla całej instalacji. Po zmianie tożsamości usługi trzeba sprawdzić jej stan, typ uruchamiania oraz zależności, a następnie uruchomić ją ponownie, ponieważ nowy kontekst jest stosowany przy starcie procesu usługi.

Jeżeli konto AD ma być używane do uwierzytelniania użytkowników w SQL Server, jest to osobna czynność administracyjna. Konto usługi uruchamia proces i uzyskuje dostęp do zasobów, natomiast loginy i role w silniku SQL Server określają, jakie operacje może wykonywać dana tożsamość podczas połączenia z instancją. Konto domenowe można dodać jako login Windows, używając nazwy domenowej, a następnie przypisać je do odpowiednich ról lub użytkowników baz danych. Nie należy nadawać mu automatycznie roli sysadmin tylko dlatego, że działa jako konto usługi.

Przy diagnostyce warto porównać wpis w SQL Server Configuration Manager z nazwą konta widoczną dla działającego procesu oraz z komunikatami w Podglądzie zdarzeń i dzienniku SQL Server. Błąd logowania usługi może oznaczać niepoprawne hasło, zablokowane konto, wygasłe hasło, brak prawa „Log on as a service”, niedostępność kontrolera domeny albo odmowę dostępu do plików. Błąd po uruchomieniu silnika może natomiast wskazywać na brak praw do katalogu danych, certyfikatu lub udziału sieciowego. Te przypadki wymagają różnych działań i nie powinny być sprowadzane do samej zmiany hasła.

Kontrola konfiguracji przed uruchomieniem instancji

Bezpieczna weryfikacja powinna rozpocząć się od ustalenia, której instancji i której usługi dotyczy problem. Należy sprawdzić nazwę konta w zakładce właściwości usługi w SQL Server Configuration Manager, potwierdzić, czy konto istnieje w Active Directory, oraz zweryfikować, czy komputer serwera może skontaktować się z domeną. Następnie trzeba potwierdzić prawa do katalogów używanych przez SQL Server, poprawność uprawnień do zasobów sieciowych i możliwość uruchomienia usługi po kontrolowanym restarcie. W przypadku gMSA warto dodatkowo sprawdzić, czy system potrafi pobrać aktualne hasło zarządzane przez domenę.

Nie należy przechowywać hasła konta domenowego w skryptach, dokumentacji wdrożeniowej ani parametrach poleceń dostępnych dla innych użytkowników. Jeżeli hasło zostało zmienione w Active Directory, usługa musi otrzymać aktualne dane uwierzytelniające albo korzystać z mechanizmu konta zarządzanego. Po każdej zmianie powinno się sprawdzić zdarzenia systemowe, stan usługi i log SQL Server, a także wykonać test operacji charakterystycznej dla danego środowiska, na przykład otwarcia bazy, utworzenia kopii zapasowej lub dostępu do wymaganego udziału. Test musi odpowiadać rzeczywistemu zastosowaniu, ponieważ samo pomyślne uruchomienie usługi nie potwierdza dostępu do wszystkich zasobów.

Jeżeli konfiguracja dotyczy komputera używanego przez administratorów lub aplikacje biurowe, trzeba oddzielić problemy konta AD od usterek samego systemu Windows, sieci i dysku. Warto zebrać dokładną nazwę usługi, nazwę instancji, czas wystąpienia błędu oraz identyfikator zdarzenia, a następnie porównać je z historią zmian kont i haseł w domenie. Taka dokumentacja ułatwia odtworzenie prawidłowego kontekstu uruchomienia bez przypadkowego nadawania zbyt szerokich uprawnień.