Konta usług domenowych

Konta usług domenowych to tożsamości z Active Directory wykorzystywane do uruchamiania komponentów serwera.

Rola kont usług domenowych w Active Directory

Konta usług domenowych to obiekty Active Directory przeznaczone do uruchamiania usług systemowych, procesów aplikacyjnych oraz zadań wykonywanych na serwerach należących do domeny. Usługa działająca pod takim kontem może uwierzytelniać się wobec innych komputerów i zasobów sieciowych bez wykorzystywania konta administratora ani prywatnego konta pracownika. To rozdzielenie tożsamości użytkownika od tożsamości procesu ułatwia kontrolę uprawnień, zmianę właściciela systemu oraz analizę zdarzeń w dziennikach.

W klasycznym modelu konto usługi jest zwykłym kontem użytkownika w domenie, któremu przypisuje się określone prawa, na przykład prawo logowania jako usługa na wskazanym serwerze. Nie powinno ono służyć do interaktywnego logowania pracowników, przeglądania stron ani wykonywania codziennych zadań administracyjnych. Nazwa konta, opis, właściciel techniczny, lista używanych usług i zakres dostępu powinny być udokumentowane, ponieważ samo członkostwo w domenie nie określa jeszcze, do czego konto może sięgać.

Typy tożsamości używanych przez usługi Windows

Najprostszym wariantem jest dedykowane konto domenowe z hasłem przechowywanym w konfiguracji usługi lub w bezpiecznym systemie zarządzania poświadczeniami. Wymaga ono regularnej zmiany hasła oraz zsynchronizowania tej zmiany ze wszystkimi usługami, zadaniami harmonogramu i konfiguracjami, które korzystają z tego konta. Jeżeli hasło zostanie zmienione tylko w Active Directory, a nie w konfiguracji usługi, proces może przestać się uruchamiać albo utracić dostęp do zasobów sieciowych.

W środowiskach Windows Server można używać kont zarządzanych przez system. Group Managed Service Account, czyli gMSA, jest obiektem Active Directory, dla którego system automatycznie zarządza hasłem. Konto może być używane przez wskazane komputery lub grupę komputerów, a administrator nie musi wpisywać jego hasła podczas konfiguracji usługi. Klasyczne sMSA, czyli standalone Managed Service Account, jest przeznaczone dla użycia z jednym komputerem. Przy planowaniu wdrożenia trzeba sprawdzić zgodność konkretnej aplikacji i wersji systemu z kontem zarządzanym, ponieważ nie każdy program potrafi korzystać z tej metody.

Usługa może także działać pod kontem wbudowanym, takim jak LocalSystem, LocalService lub NetworkService. Są to lokalne tożsamości systemowe, a nie dedykowane konta domenowe, choć niektóre z nich mogą uwierzytelniać się w sieci jako konto komputera. Taki model ma inne konsekwencje dla uprawnień i audytu. Nie należy automatycznie zastępować konta domenowego kontem wbudowanym bez sprawdzenia, jak aplikacja uzyskuje dostęp do udziałów, baz danych, certyfikatów i innych zasobów.

Uprawnienia, uwierzytelnianie i nazwy usług

Konto usługowe powinno otrzymać wyłącznie uprawnienia niezbędne do wykonania konkretnej funkcji. Uprawnienia do lokalnych katalogów, kluczy rejestru, certyfikatów, udziałów SMB lub innych usług sieciowych należy nadawać na poziomie wymaganym przez aplikację, zamiast dodawać konto do grup o szerokim zakresie działania. Szczególnie ryzykowne jest wykorzystywanie jednego konta do wielu niezależnych komponentów, ponieważ przejęcie lub błędna konfiguracja jednej usługi może wtedy zapewnić dostęp także do pozostałych.

W domenie Active Directory usługi korzystające z Kerberos mogą być identyfikowane przez Service Principal Name, czyli SPN. Wpis SPN wiąże nazwę usługi z konkretnym kontem i pozwala klientowi uzyskać bilet Kerberos dla właściwej tożsamości. Duplikat SPN albo przypisanie go do niewłaściwego konta może powodować błędy uwierzytelniania, przejście na NTLM lub problemy widoczne jako niedostępność aplikacji. Przy diagnozie warto sprawdzić, czy nazwa DNS, port, nazwa usługi i konto używane przez proces są ze sobą zgodne.

Do sprawdzenia podstawowych właściwości konta można wykorzystać narzędzia administracyjne Active Directory, między innymi Get-ADUser w module PowerShell ActiveDirectory. Dla kont zarządzanych przydatne są polecenia Get-ADServiceAccount oraz Test-ADServiceAccount, które pomagają zweryfikować obecność obiektu i możliwość użycia go na danym komputerze. Listę przypisanych SPN można analizować poleceniem setspn. Wyniki trzeba interpretować razem z konfiguracją konkretnej aplikacji oraz zdarzeniami systemowymi, ponieważ sam brak błędu w katalogu nie potwierdza poprawnego działania procesu.

Objawy błędnej konfiguracji i bezpieczny przegląd

Problemy z kontem usługi często pojawiają się po zmianie hasła, wygaśnięciu konta, zablokowaniu go przez wielokrotne nieudane logowania albo odebraniu prawa logowania jako usługa. W Dzienniku zdarzeń mogą wtedy wystąpić informacje o nieudanym logowaniu, odrzuconym uwierzytelnieniu lub zatrzymaniu usługi. Inną grupę problemów stanowi brak dostępu do zasobu: usługa może uruchamiać się lokalnie, ale nie odczytywać udziału sieciowego, certyfikatu albo endpointu innego serwera, ponieważ konto nie ma wymaganych praw.

Przegląd należy rozpocząć od ustalenia, jaki proces korzysta z konta, na których komputerach jest ono skonfigurowane i jakie zasoby musi osiągać. Następnie sprawdza się stan konta w Active Directory, datę ostatniej zmiany hasła, członkostwo w grupach, delegowane uprawnienia, prawo logowania jako usługa oraz ewentualne wpisy SPN. W przypadku gMSA trzeba dodatkowo potwierdzić, że komputer znajduje się w dozwolonej grupie zabezpieczeń, a system może pobrać aktualne hasło zarządzane przez domenę.

Nieprawidłowości warto usuwać etapami: najpierw potwierdzić zakres wymaganych praw, potem ograniczyć dostęp, przetestować ponowne uruchomienie usługi i sprawdzić komunikację z zależnymi zasobami. Zmiana nazwy konta, jego usunięcie lub ręczne resetowanie hasła bez inwentaryzacji może przerwać działanie kilku komponentów jednocześnie. Dokumentacja powinna wskazywać konto, usługę, serwer, wymagane zasoby, sposób rotacji poświadczeń oraz procedurę odtworzenia konfiguracji po awarii.