Zarządzanie kontem usługi

Zarządzanie kontem usługi to konfiguracja tożsamości, w kontekście której działa dany komponent SQL Server.

Tożsamość procesu SQL Server i zakres konta usługi

Zarządzanie kontem usługi SQL Server obejmuje wybór oraz konfigurację tożsamości systemu Windows, pod którą uruchomiona jest usługa aparatu bazy danych. Konto to nie jest kontem użytkownika logującego się do aplikacji ani loginem T-SQL. Windows wykorzystuje jego token bezpieczeństwa przy uruchamianiu procesu SQL Server, dostępie do plików baz danych, odczycie konfiguracji oraz komunikacji z innymi zasobami systemu. W jednej instalacji mogą działać odrębne usługi, między innymi SQL Server Database Engine, SQL Server Agent, SQL Server Browser i SQL Server Launchpad. Każda z nich może mieć inną tożsamość i osobny zakres uprawnień.

Do uruchamiania SQL Server można wykorzystać konto domenowe, konto lokalne, wirtualne konto usługi albo grupowe konto zarządzane, czyli gMSA. Wirtualne konto usługi ma nazwę powiązaną z usługą i korzysta z tożsamości komputera podczas dostępu do zasobów sieciowych. gMSA pozwala domenie automatycznie obsługiwać hasło konta, dzięki czemu administrator nie musi wpisywać stałego hasła przy jego okresowej zmianie. Konto lokalne, LocalSystem lub NetworkService może być technicznie wystarczające w określonych scenariuszach, ale ich uprawnienia i sposób uwierzytelniania mają inne konsekwencje niż w przypadku dedykowanego konta domenowego.

Konfiguracja konta przez narzędzia SQL Server

Zmianę konta usługi SQL Server należy wykonywać w SQL Server Configuration Manager, a nie przez przypadkową edycję właściwości usługi w konsoli services.msc. Configuration Manager zapisuje ustawienia w sposób uwzględniający mechanizmy SQL Server i może nadać wybranej tożsamości wymagane lokalne prawa użytkownika. W zależności od wersji oraz typu instalacji administrator wskazuje nazwę konta, sposób logowania oraz hasło. Po zapisaniu zmiany konieczne jest ponowne uruchomienie odpowiedniej usługi, ponieważ już działający proces nadal używa starego tokenu bezpieczeństwa.

Zmiana konta może wpływać na dostęp do katalogów danych, plików dzienników, plików kopii zapasowych, kluczy szyfrowania, certyfikatów oraz udziałów sieciowych. Uprawnienia do lokalnego systemu plików muszą być nadane dokładnie temu kontu, pod którym działa usługa, a nie administratorowi wykonującemu konfigurację. Przy zasobie sieciowym serwer plików widzi konto domenowe albo konto komputera, zależnie od użytej tożsamości. Dlatego dostęp do ścieżki typu \\serwer\udział może działać dla konta domenowego, lecz nie zadziałać po przełączeniu usługi na konto lokalne. Po zmianie należy sprawdzić dziennik SQL Server oraz Windows Event Viewer, zwłaszcza błędy związane z logowaniem usługi, dostępem do plików i inicjalizacją bazy systemowej.

Uprawnienia, hasła i uwierzytelnianie Kerberos

Konto usługi powinno otrzymywać wyłącznie uprawnienia potrzebne do uruchomienia konkretnego komponentu i wykonania zaplanowanych operacji. Nadawanie mu członkostwa w lokalnej grupie Administratorzy nie jest wymagane do standardowej pracy aparatu SQL Server i zwiększa skutki ewentualnego przejęcia poświadczeń. Zakres dostępu trzeba oceniać osobno dla katalogów MDF i NDF, plików LDF, lokalizacji kopii zapasowych, katalogów tymczasowych oraz zasobów używanych przez SQL Server Agent. Uprawnienia SQL Server, takie jak role serwerowe i uprawnienia bazodanowe, nie zastępują uprawnień NTFS. Konto może mieć dostęp do obiektu w SQL Server, ale nadal nie mieć prawa odczytu lub zapisu konkretnego pliku Windows.

W środowisku domenowym konto usługi może być również używane do uwierzytelniania Kerberos. Dla poprawnego działania Kerberos nazwa usługi SQL Server musi być powiązana z właściwym Service Principal Name, czyli SPN, zwykle w postaci MSSQLSvc/nazwa_hosta:port albo MSSQLSvc.w pełnej nazwie DNS:port. Rzeczywisty wpis zależy od instancji, nazwy hosta i portu. SPN powinien być zarejestrowany dla konta, które uruchamia usługę SQL Server, a nie dla przypadkowego użytkownika lub innej usługi. Duplikaty albo brak właściwego SPN mogą spowodować przejście do NTLM, błędy delegowania lub nieudane uwierzytelnianie zintegrowane. Po zmianie konta trzeba więc zweryfikować rejestrację SPN, rozwiązywanie nazwy DNS i sposób uwierzytelnienia aktywnego połączenia.

Weryfikacja po zmianie tożsamości usługi

Kontrolę należy rozpocząć od potwierdzenia, że usługa Database Engine uruchamia się pod właściwym kontem i nasłuchuje na oczekiwanym porcie. Następnie warto sprawdzić dostęp do każdej lokalizacji używanej przez bazy użytkownika oraz bazy systemowe, a także wykonać kontrolowany odczyt i zapis w katalogu przeznaczonym na kopie zapasowe. Jeżeli działa SQL Server Agent, trzeba osobno sprawdzić uruchamianie zadań, operatorów, proxy oraz kroków wykonujących polecenia systemowe. Konto aparatu SQL Server i konto agenta nie muszą być takie same, dlatego poprawny start jednego komponentu nie potwierdza poprawności całej konfiguracji.

Podczas diagnostyki należy rozdzielić problem konta usługi od problemu loginu SQL Server, uprawnień użytkownika bazy i konfiguracji aplikacji. Błąd „Access is denied” w dzienniku Windows wskazuje zwykle na brak uprawnienia systemowego, natomiast odmowa dostępu do obiektu SQL Server może wynikać z mapowania loginu, roli lub uprawnienia T-SQL. Po zmianie hasła konta domenowego trzeba sprawdzić, czy usługa nadal się uruchamia i czy połączenia zintegrowane nie tracą uwierzytelniania Kerberos. W przypadku awarii bezpiecznym krokiem jest przywrócenie udokumentowanej konfiguracji, zebranie identyfikatora zdarzenia oraz porównanie konta usługi, uprawnień NTFS, SPN i parametrów instancji, zamiast nadawania szerokich uprawnień bez ustalenia przyczyny.