Konfiguracja konta SQL Server Agent

Konfiguracja konta SQL Server Agent określa, z jakimi uprawnieniami usługa uruchamia zaplanowane zadania.

Rola konta usługi SQL Server Agent

SQL Server Agent jest składnikiem Microsoft SQL Server odpowiedzialnym za wykonywanie zadań zaplanowanych, reakcji na alerty oraz harmonogramów. Konto skonfigurowane dla usługi SQL Server Agent określa tożsamość systemu Windows, pod którą usługa działa po uruchomieniu. W praktyce wpływa ono na dostęp do plików, udziałów sieciowych, kluczy rejestru, zasobów systemowych oraz innych usług, z których korzystają kroki zadań.

Nie należy utożsamiać konta usługi z właścicielem konkretnego zadania ani z loginem używanym przez aplikację łączącą się z bazą danych. Właściciel zadania jest obiektem w SQL Server, natomiast konto usługi jest tożsamością procesu działającego w systemie Windows. Jeżeli zadanie wykonuje polecenie T-SQL, jego kontekst wykonania w wielu typowych przypadkach wynika z uprawnień konta usługi oraz konfiguracji zabezpieczeń SQL Server. Zmiana tego konta może więc zmienić zachowanie istniejących zadań, nawet jeśli ich harmonogramy i treść pozostaną bez zmian.

Dobór tożsamości i zakresu uprawnień

Konto SQL Server Agent powinno mieć wyłącznie uprawnienia wymagane przez zadania wykonywane w danej instancji. W środowisku domenowym może to być dedykowane konto użytkownika domenowego albo konto zarządzane, jeżeli organizacja stosuje taką konfigurację. Konto nie powinno być współdzielone z administratorem, aplikacją biznesową ani inną usługą. Należy także określić, czy zadania muszą korzystać z zasobów sieciowych, ponieważ konto lokalne komputera lub lokalny użytkownik nie zapewni takiego samego dostępu do zdalnych udziałów jak konto domenowe.

Wybór konta o szerokich prawach, na przykład lokalnego administratora, zwiększa skutki ewentualnego błędu w skrypcie lub przejęcia zadania. Ograniczenie praw systemu Windows nie zastępuje jednak konfiguracji uprawnień w SQL Server. Konto usługi musi mieć odpowiedni login w instancji, dostęp do wymaganych baz oraz uprawnienia do obiektów używanych przez zadania. W bazie msdb istnieją stałe role SQL Server Agent: SQLAgentUserRole, SQLAgentReaderRole i SQLAgentOperatorRole. Role te dotyczą głównie zarządzania zadaniami przez użytkowników, a nie pełnego zastępstwa dla praw samej usługi.

Konfiguracja usługi, zadań i proxy

Konto usługi SQL Server Agent konfiguruje się dla konkretnej instancji SQL Server, korzystając z SQL Server Configuration Manager albo odpowiednich mechanizmów systemowych przewidzianych dla tej usługi. Po zmianie poświadczeń należy sprawdzić, czy usługa może się uruchomić, czy konto ma wymagane prawa systemowe oraz czy SQL Server Agent poprawnie łączy się z instancją. Warto przejrzeć dziennik SQL Server Agent i historię zadań, ponieważ sam fakt uruchomienia usługi nie potwierdza poprawnego działania wszystkich kroków.

Nie każdy krok zadania powinien być wykonywany bezpośrednio jako konto usługi. Dla podsystemów takich jak PowerShell, system operacyjny, SQL Server Analysis Services lub SQL Server Integration Services można skonfigurować konto proxy. Proxy jest powiązane z poświadczeniem oraz konkretnym podsystemem i pozwala nadać krokowi węższy zakres uprawnień niż pełne prawa konta usługi. Trzeba również sprawdzić ustawienie „Run as” dla kroków oraz właściciela zadania. W przypadku dostępu do plików lub udziałów sieciowych należy testować dokładnie ten sam kontekst, który będzie użyty podczas automatycznego uruchomienia, a nie wyłącznie ręczne wykonanie skryptu z konta administratora.

Do diagnostyki można wykorzystać widoki systemowe w bazie msdb, między innymi dbo.sysjobs, dbo.sysjobsteps, dbo.sysjobhistory i dbo.sysjobactivity. Pozwalają one porównać właściciela zadania, rodzaj kroku, ostatni rezultat oraz czas rozpoczęcia i zakończenia. Przydatne jest także sprawdzenie, czy zadanie nie korzysta z nieistniejącego proxy, wygasłego poświadczenia albo ścieżki dostępnej tylko dla interaktywnego użytkownika.

Weryfikacja po zmianie konta SQL Server Agent

Po zmianie konta należy wykonać kontrolowany test każdego rodzaju zadania używanego w instancji. Obejmuje to zadania T-SQL, kopie zapasowe, operacje na plikach, polecenia systemu operacyjnego oraz ewentualne kroki korzystające z proxy. Trzeba zweryfikować dostęp do baz, katalogów lokalnych i udziałów sieciowych, a także uprawnienia do certyfikatów, kluczy i innych zasobów wymaganych przez konkretne skrypty. Błąd „Access is denied” może oznaczać brak prawa systemu Windows, natomiast błąd logowania do SQL Server może wskazywać na brak loginu, mapowania użytkownika lub uprawnienia do obiektu.

Ważne jest sprawdzenie harmonogramu po restarcie usługi i po ponownym uruchomieniu systemu. Należy przejrzeć historię wykonania w SQL Server Agent, komunikaty w dzienniku agenta oraz wpisy w Podglądzie zdarzeń systemu Windows. Jeżeli zadanie korzysta z konta domenowego, trzeba uwzględnić zmianę hasła, blokadę konta, wygaśnięcie poświadczeń i problemy z komunikacją z kontrolerem domeny. W przypadku kont zarządzanych należy potwierdzić, że host i usługa są objęte właściwą konfiguracją zarządzania hasłem.

Diagnostyka powinna kończyć się udokumentowaniem mapy zależności: konto usługi, login w SQL Server, role w msdb, używane proxy, bazy docelowe oraz zasoby systemu Windows. Taki zapis ułatwia odróżnienie problemu z uprawnieniami od błędu samego skryptu, harmonogramu lub połączenia. Przy naprawie komputera pełniącego funkcję stacji administracyjnej warto dodatkowo sprawdzić, czy narzędzia SQL Server Management Studio i SQL Server Configuration Manager łączą się z właściwą instancją oraz czy zmiana nie została wykonana w innej instancji niż ta, która uruchamia zadania.