Uprawnienia do SQL Server Agent kontrolują dostęp do tworzenia i zarządzania zadaniami automatycznymi.
Rola uprawnień w SQL Server Agent
Uprawnienia do SQL Server Agent określają, kto może tworzyć, przeglądać, uruchamiać, modyfikować i usuwać zadania wykonywane przez usługę agenta. SQL Server Agent korzysta w tym celu z ról stałych bazy danych znajdujących się w bazie msdb. Użytkownik, który nie należy do roli serwerowej sysadmin, musi być członkiem co najmniej jednej z ról: SQLAgentUserRole, SQLAgentReaderRole albo SQLAgentOperatorRole. Członkostwo w sysadmin zapewnia pełny dostęp do funkcji SQL Server Agent i nie wymaga dodatkowego członkostwa w tych rolach.
Role agenta mają uprawnienia narastające. SQLAgentUserRole jest przeznaczona dla użytkowników zarządzających własnymi zadaniami i harmonogramami. SQLAgentReaderRole obejmuje możliwości pierwszej roli oraz pozwala przeglądać zadania, harmonogramy, właściwości i historię zadań innych użytkowników. SQLAgentOperatorRole jest najbardziej uprzywilejowaną z tych trzech ról i umożliwia wykonywanie szerszych operacji operatorskich, takich jak uruchamianie i zatrzymywanie zadań oraz przeglądanie ich stanu. Nadanie roli powinno odpowiadać rzeczywistym obowiązkom konta, ponieważ zbyt szeroki dostęp może pozwolić na uruchamianie procesów z niepożądanym poziomem uprawnień.
Role SQLAgentUserRole, SQLAgentReaderRole i SQLAgentOperatorRole
Członek SQLAgentUserRole ma dostęp przede wszystkim do zadań lokalnych i harmonogramów, których jest właścicielem. Taki użytkownik może tworzyć własne zadania oraz własne kroki zadań uruchamiane w jego kontekście. Nie powinien automatycznie uzyskiwać możliwości przeglądania ani zmieniania cudzych zadań. SQLAgentReaderRole rozszerza ten zakres o odczyt wszystkich dostępnych zadań i harmonogramów, ich właściwości oraz historii. Członek tej roli nie może jednak zmienić właściciela zadania wyłącznie po to, aby uzyskać do niego dostęp.
SQLAgentOperatorRole służy do bieżącej obsługi zadań bez nadawania pełnych uprawnień administracyjnych instancji. Operator może monitorować wykonanie zadań, uruchamiać je ręcznie, zatrzymywać działające zadania i sprawdzać wyniki ich działania w zakresie przewidzianym przez SQL Server Agent. Role te obejmują również dostęp do określonych obiektów agenta, takich jak operatorzy, zadania, harmonogramy, alerty i serwery proxy, przy czym zakres zależy od roli oraz konfiguracji konkretnego obiektu. Członkostwo w roli nie zastępuje uprawnień do baz danych, tabel, procedur i innych zasobów, do których odwołuje się krok zadania.
Nadawanie dostępu i kontekst wykonania zadań
Najpierw login serwerowy musi mieć użytkownika w bazie msdb. Przykładowa konfiguracja wykorzystuje polecenia Transact-SQL:
USE [msdb];
CREATE USER [NazwaUzytkownika] FOR LOGIN [NazwaLoginu];
ALTER ROLE [SQLAgentReaderRole] ADD MEMBER [NazwaUzytkownika];
Jeżeli użytkownik ma zarządzać wyłącznie własnymi zadaniami, odpowiednią rolą będzie zwykle SQLAgentUserRole. Dostęp do odczytu zadań całej instancji wymaga zazwyczaj SQLAgentReaderRole, a operacje operatorskie — SQLAgentOperatorRole. Przed dodaniem użytkownika należy sprawdzić, czy nie jest on już członkiem innej roli w msdb, ponieważ role mają hierarchiczny, nakładający się zakres. Usunięcie członkostwa wykonuje się poleceniem ALTER ROLE ... DROP MEMBER, po wcześniejszym potwierdzeniu, że konto nie utraci wymaganej funkcji operacyjnej.
Uprawnienia do zarządzania zadaniem nie są tym samym co uprawnienia potrzebne do wykonania jego kroku. SQL Server Agent obsługuje podsystemy, między innymi kroki Transact-SQL, PowerShell i inne typy zadań dostępne w danej instalacji. Do uruchamiania kroku w określonym kontekście służy konto proxy powiązane z poświadczeniem i odpowiednim podsystemem. Użytkownik niebędący administratorem musi mieć przyznany dostęp do konkretnego proxy, jeżeli zadanie korzysta z typu kroku wymagającego takiej konfiguracji. Samo członkostwo w SQLAgentUserRole, SQLAgentReaderRole lub SQLAgentOperatorRole nie nadaje automatycznie uprawnień do systemu operacyjnego ani do wszystkich baz danych.
Diagnostyka problemów z uprawnieniami
Objawem braku dostępu może być niewidoczny węzeł SQL Server Agent w SQL Server Management Studio, brak zadania na liście, odmowa uruchomienia zadania albo błąd kroku podczas odwołania do tabeli, procedury lub pliku. Diagnostykę należy rozpocząć od ustalenia, z jakim loginem użytkownik łączy się do instancji, czy posiada odpowiadającego mu użytkownika w msdb oraz do jakich ról należy ten użytkownik. Warto również sprawdzić właściciela zadania, ponieważ dostęp do zadań lokalnych w SQLAgentUserRole jest związany z własnością obiektu.
Następnie trzeba rozdzielić błąd autoryzacji SQL Server Agent od błędu samego kroku. Historia zadania może wskazać, czy problem wystąpił podczas wyboru zadania, uruchamiania podsystemu, użycia proxy, połączenia z bazą czy wykonania konkretnego polecenia. Należy zweryfikować, czy usługa SQL Server Agent działa, czy konto proxy jest aktywne, czy ma przypisany właściwy podsystem oraz czy jego poświadczenie nie wygasło. W przypadku kroku Transact-SQL trzeba dodatkowo sprawdzić uprawnienia wykonującego do docelowej bazy i obiektów, do których odwołuje się kod. Zmiana roli użytkownika w msdb nie naprawi braku uprawnień do tabeli lub procedury w bazie aplikacyjnej.
