Logon as service – uprawnienia

Uprawnienie „Log on as a service” pozwala kontu uruchamiać usługi Windows — jego brak uniemożliwia start SQL Server.

Rola uprawnienia „Log on as a service” w systemie Windows

„Log on as a service” to angielska nazwa prawa użytkownika w systemie Windows, które pozwala wskazanemu kontu uruchamiać proces jako usługę systemową. Usługa Windows nie działa w zwykłym kontekście interaktywnego logowania użytkownika. Podczas startu system lub Menedżer kontroli usług przekazuje jej dane konta, a lokalny mechanizm zabezpieczeń sprawdza, czy konto ma prawo logowania jako usługa. Jeżeli weryfikacja zakończy się odmową, usługa nie otrzyma kontekstu wykonania i nie rozpocznie pracy.

Prawo to nie jest tym samym co członkostwo w grupie Administratorzy, pozwolenie na zdalne logowanie ani prawo „Log on locally”. Konto może mieć poprawne hasło i wystarczające uprawnienia do plików, rejestru lub bazy danych, a mimo tego nie będzie mogło uruchomić usługi bez odpowiedniego prawa logowania. Windows uwzględnia również ewentualne prawo „Deny log on as a service”, które ma pierwszeństwo nad zezwoleniem. W praktyce oznacza to, że samo dodanie konta do listy dozwolonych nie rozwiąże problemu, jeśli to samo konto znajduje się na liście odmowy.

Dlaczego brak prawa zatrzymuje usługę SQL Server

Podczas instalacji lub konfiguracji SQL Server wybiera się konto usługi, na przykład dedykowane konto domenowe albo konto zarządzane przeznaczone do pracy usługi. Usługa SQL Server korzysta z tego konta przy uruchamianiu procesu silnika bazy danych. Konto musi mieć możliwość zalogowania się jako usługa, a następnie musi otrzymać także wymagane uprawnienia do zasobów systemowych używanych przez konkretną instalację SQL Server, w tym do plików programu, plików danych, dzienników transakcyjnych i ustawień zapisanych w rejestrze.

Odmowa startu może pojawić się po zmianie konta usługi, odtworzeniu zasad zabezpieczeń, zastosowaniu obiektu zasad grupy albo przeniesieniu komputera do innej jednostki organizacyjnej w domenie. Typowym objawem jest nieuruchamianie się usługi SQL Server po restarcie systemu lub błąd zgłaszany przez Menedżera kontroli usług, wskazujący na brak wymaganego prawa logowania. Należy odróżnić taki przypadek od błędnego hasła konta, wyłączonego konta domenowego, braku dostępu do katalogów danych, problemu z zależnością usługi albo uszkodzenia samego silnika SQL Server. Sam komunikat o nieudanym starcie nie przesądza jeszcze, która z tych przyczyn wystąpiła.

Sprawdzanie lokalnych zasad i zasad domenowych

Na komputerze zarządzanym lokalnie prawo można sprawdzić w konsoli Lokalna zasada zabezpieczeń, w obszarze przypisanym do praw użytkownika. Interesująca pozycja to „Log on as a service”, a kontrolnie należy przejrzeć także „Deny log on as a service”. W systemach, w których dostępna jest odpowiednia konfiguracja zasad, można wykorzystać również narzędzia administracyjne systemu Windows do odczytu efektywnych ustawień. Ważne jest sprawdzenie nazwy konta w dokładnej postaci używanej przez usługę, na przykład z prefiksem domeny lub nazwą komputera.

W środowisku domenowym ustawienie lokalne może zostać nadpisane przez zasady grupy. Dlatego po zmianie konfiguracji trzeba ustalić, która zasada dostarcza obowiązującą wartość, oraz sprawdzić wynik zastosowania polityk na konkretnym komputerze. Pomocne są dzienniki systemowe oraz wpisy dotyczące Service Control Managera, logowania i zasad zabezpieczeń. Jeżeli konto ma prawo „Log on as a service”, lecz nadal występuje odmowa, należy zweryfikować, czy nie ma go jednocześnie na liście „Deny log on as a service”, czy hasło zapisane w konfiguracji usługi jest aktualne oraz czy konto nie zostało zablokowane.

Zmiana prawa powinna być wykonana z użyciem konta administracyjnego i zgodnie z przyjętym modelem zarządzania. Nie należy automatycznie nadawać tego prawa wszystkim użytkownikom ani zastępować dedykowanego konta kontem o szerokich uprawnieniach. Po korekcie zasad warto ponownie uruchomić usługę SQL Server i sprawdzić zarówno jej stan, jak i dzienniki. Pomyślny start potwierdza usunięcie jednej z możliwych blokad, ale nie zastępuje kontroli połączenia z instancją oraz dostępu do właściwych baz danych.

Diagnostyka konfiguracji usługi i dalsze kroki

Pełna diagnostyka wymaga porównania kilku elementów: nazwy konta przypisanego do usługi SQL Server, stanu tego konta, jego hasła, efektywnych praw użytkownika, wpisów w dziennikach systemowych oraz uprawnień do katalogów używanych przez instancję. Jeżeli problem wystąpił po zmianie polityki domenowej, należy ustalić moment zastosowania zmiany i sprawdzić, czy dotyczy ona jednego komputera, czy większej grupy urządzeń. Gdy usługa uruchamia się ręcznie, ale nie startuje po ponownym uruchomieniu systemu, trzeba dodatkowo przeanalizować kolejność startu, zależności i dostępność zasobów w chwili uruchamiania.

Nie powinno się usuwać plików SQL Server, zmieniać lokalizacji baz ani resetować wszystkich zasad zabezpieczeń wyłącznie na podstawie komunikatu o braku prawa „Log on as a service”. Takie działania mogą utrudnić ustalenie przyczyny i doprowadzić do kolejnych problemów z dostępem. Bezpieczniejsza jest identyfikacja konkretnego konta, odczyt efektywnej konfiguracji, korekta tylko właściwego prawa, a następnie kontrolowany test uruchomienia usługi i połączenia z instancją SQL Server. Jeżeli konto jest zarządzane centralnie, trwała zmiana wymaga aktualizacji odpowiedniej zasady, ponieważ lokalna poprawka może zostać później cofnięta.

W przypadku komputera, na którym nie uruchamia się usługa SQL Server, diagnostyka powinna obejmować również podstawowy stan systemu Windows, usług, kont użytkowników i lokalnych uprawnień do plików. Pozwala to odróżnić błąd polityki zabezpieczeń od problemu z konfiguracją konkretnej instancji lub z systemem plików. Wnioski należy opierać na rzeczywistych komunikatach i ustawieniach danego komputera, a nie wyłącznie na nazwie błędu widocznej w panelu usług.