Konta usług MSA, gMSA i dMSA w Active Directory — tworzenie i zarządzanie w PowerShell

Zarządzane konta usług (Managed Service Accounts) to specjalne konta Active Directory do uruchamiania usług, zadań harmonogramu i pul aplikacji IIS, których hasło generuje i regularnie zmienia sam kontroler domeny. Standalone MSA (sMSA) działa na jednym serwerze, group MSA (gMSA) na wielu, a w Windows Server 2025 doszło delegowane dMSA. Dzięki nim nie musisz trzymać haseł kont serwisowych w arkuszu ani zmieniać ich ręcznie na każdym serwerze.

Poniżej pokazuję, czym się różnią poszczególne typy, jak je utworzyć w PowerShellu, jak przypisać do usług i zadań oraz na co uważać z punktu widzenia bezpieczeństwa.

Dlaczego zwykłe konto użytkownika to zły wybór dla usługi

Przez lata standardem było zakładanie konta użytkownika svc_sql czy svc_backup z hasłem ustawionym na „nigdy nie wygasa”. Takie podejście ma trzy wady:

• hasło zna kilka osób i często trafia do dokumentacji, skryptów lub plików konfiguracyjnych,
• hasło się nie zmienia, bo zmiana wymaga aktualizacji na każdym serwerze i grozi przestojem,
• konto z SPN jest podatne na Kerberoasting — każdy uwierzytelniony użytkownik domeny może pobrać bilet usługi i łamać hasło offline. Mechanizm opisujemy w tekście o protokole Kerberos.

Zarządzane konta usług rozwiązują wszystkie trzy problemy: hasło ma 240 bajtów, jest losowe, nikt go nie zna, a Active Directory zmienia je automatycznie (domyślnie co 30 dni) bez przerywania pracy usług.

sMSA, gMSA i dMSA — porównanie

W praktyce gMSA stało się domyślnym wyborem — działa także na jednym serwerze, a w razie rozbudowy wystarczy dodać kolejny komputer do grupy. sMSA ma dziś znaczenie głównie historyczne.

Krok 1: utworzenie klucza głównego KDS

Hasła gMSA wylicza usługa Microsoft Key Distribution Service na kontrolerach domeny. Potrzebuje do tego klucza głównego, który tworzy się raz dla całego lasu. Uruchom na kontrolerze domeny, jako administrator domeny głównej lasu:

Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately

Mimo nazwy parametru klucz staje się użyteczny dopiero po ok. 10 godzinach — to zabezpieczenie dające czas na replikację między kontrolerami. W środowisku testowym z jednym kontrolerem możesz to obejść:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Uwaga: Nie stosuj obejścia z cofniętą datą w produkcji z wieloma kontrolerami domeny. Jeśli któryś kontroler nie otrzyma jeszcze klucza, serwery mogą nie pobrać hasła gMSA i usługi nie wystartują.

Krok 2: utworzenie konta gMSA

1. Utwórz grupę zabezpieczeń, do której dodasz serwery uprawnione do używania konta:

New-ADGroup -Name "GMSA-WEB-Hosts" -GroupScope Global -GroupCategory Security -Path "OU=Grupy,DC=firma,DC=local"
Add-ADGroupMember -Identity "GMSA-WEB-Hosts" -Members "WEB01$","WEB02$"

2. Utwórz konto gMSA:

New-ADServiceAccount -Name "gmsa-web" `
  -DNSHostName "gmsa-web.firma.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "GMSA-WEB-Hosts" `
  -ServicePrincipalNames "HTTP/intranet.firma.local"

Nazwa konta może mieć maksymalnie 15 znaków (ograniczenie nazwy sAMAccountName dla kont komputerów, do których należy gMSA). Parametr -ServicePrincipalNames jest potrzebny tylko wtedy, gdy usługa korzysta z uwierzytelniania Kerberos pod własną nazwą (np. SQL Server, aplikacja webowa z Windows Authentication).

3. Konto pojawi się w kontenerze Managed Service Accounts w konsoli „Użytkownicy i komputery usługi Active Directory” (aby go zobaczyć, włącz Widok → Funkcje zaawansowane).

Krok 3: przygotowanie serwera i test konta

Na każdym serwerze z grupy:

1. Zainstaluj moduł Active Directory dla PowerShella (jeśli go nie ma):

Install-WindowsFeature RSAT-AD-PowerShell

2. Odśwież członkostwo komputera w grupach — najprościej restartem serwera. Bez restartu możesz wyczyścić bilety Kerberos konta komputera: klist purge -li 0x3e7.
3. Przetestuj konto:

Install-ADServiceAccount -Identity "gmsa-web"
Test-ADServiceAccount -Identity "gmsa-web"

Wynik True oznacza, że serwer może pobrać hasło. Dla gMSA polecenie Install-ADServiceAccount nie jest ściśle wymagane, ale dobrze od razu pokazuje problemy z uprawnieniami.

Krok 4: użycie konta gMSA w usługach, zadaniach i IIS

Usługa Windows

1. Otwórz services.msc, kliknij usługę prawym przyciskiem → Właściwości → karta Logowanie.
2. Zaznacz To konto i wpisz FIRMA\gmsa-web$ — znak $ na końcu jest obowiązkowy.
3. Pola hasła zostaw puste i zatwierdź. Konsola sama nada kontu uprawnienie Logowanie w trybie usługi.

To samo z wiersza poleceń:

sc.exe config "NazwaUslugi" obj= "FIRMA\gmsa-web$"

Zadanie Harmonogramu zadań

Interfejs graficzny Harmonogramu nie pozwala wskazać konta gMSA, więc użyj PowerShella:

$principal = New-ScheduledTaskPrincipal -UserId "FIRMA\gmsa-web$" -LogonType Password
Set-ScheduledTask -TaskName "RaportNocny" -Principal $principal

Konto potrzebuje uprawnienia Logowanie w trybie wsadowym (Log on as a batch job) — nadaj je lokalnie lub przez GPO.

Pula aplikacji IIS

W Menedżerze IIS: Pule aplikacji → wybrana pula → Ustawienia zaawansowane → Tożsamość → Konto niestandardowe. Wpisz FIRMA\gmsa-web$, pola hasła pozostaw puste.

Standalone MSA i nowe dMSA

sMSA — jeden serwer

Jeśli z jakiegoś powodu potrzebujesz klasycznego konta sMSA (np. bardzo stare środowisko):

New-ADServiceAccount -Name "msa-app01" -RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity "APP01" -ServiceAccount "msa-app01"
# na serwerze APP01:
Install-ADServiceAccount -Identity "msa-app01"

sMSA nie wymaga klucza KDS — jego hasło zmienia sam komputer, do którego jest przypisane, podobnie jak hasło konta komputera.

dMSA — Windows Server 2025

Delegated Managed Service Account to typ wprowadzony w Windows Server 2025. Jego głównym celem jest migracja: możesz „podpiąć” dMSA w miejsce istniejącego klasycznego konta usługi, a po zakończeniu migracji wyłączyć stare konto i jego hasło. Uwierzytelnianie dMSA jest powiązane z tożsamością konkretnego komputera. Do tworzenia służą parametry i polecenia modułu ActiveDirectory, m.in. New-ADServiceAccount -CreateDelegatedServiceAccount, Start-ADServiceAccountMigration i Complete-ADServiceAccountMigration. Wymagany jest kontroler domeny z Windows Server 2025.

Ważne: W 2025 roku opisano technikę ataku nazwaną BadSuccessor, w której użytkownik z prawem tworzenia obiektów w dowolnej jednostce organizacyjnej mógł nadużyć dMSA do przejęcia uprawnień innego konta. Microsoft załatał lukę (CVE-2025-53779) w aktualizacjach z sierpnia 2025 r. Jeśli masz kontrolery z Windows Server 2025, zainstaluj bieżące aktualizacje i sprawdź, kto może tworzyć obiekty w OU.

Bezpieczeństwo kont usług i audyt Active Directory

gMSA znacząco podnosi bezpieczeństwo, ale nie jest „magiczne”. Podczas audytu bezpieczeństwa Active Directory sprawdź:

1. Kto może odczytać hasło gMSA — atrybut msDS-ManagedPassword mogą czytać członkowie grupy z PrincipalsAllowedToRetrieveManagedPassword. Przejęcie jednego z tych serwerów oznacza dostęp do konta. Do grupy dodawaj tylko komputery, nigdy użytkowników.

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

2. Uprawnienia samych kont gMSA — konto usługi powinno mieć minimalne uprawnienia. gMSA z członkostwem w „Domain Admins” to wciąż konto, którego przejęcie oznacza przejęcie domeny.
3. Ochronę kontrolerów domeny — kto ma klucz główny KDS (czyli dostęp administracyjny do DC), może wyliczyć hasła wszystkich gMSA offline (atak znany jako Golden gMSA). To kolejny powód, by dostęp do kontrolerów traktować jak dostęp uprzywilejowany — więcej w artykule o Privileged Access Management.
4. Pozostałe klasyczne konta usług — znajdź konta użytkowników z SPN i starym hasłem, bo to pierwsi kandydaci do migracji na gMSA:

Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires |
  Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires

Jeśli nie możesz od razu zmigrować wszystkich kont, nadaj im długie, losowe hasła (25+ znaków), włącz dla nich tylko szyfrowanie AES w Kerberos i ogranicz miejsca logowania przez GPO — przykłady przydatnych ustawień znajdziesz w zestawieniu obiektów GPO dla bezpieczeństwa.

Najczęstsze problemy z gMSA

• Test-ADServiceAccount zwraca False — komputer nie jest w grupie uprawnionej albo nie odświeżył członkostwa (zrestartuj serwer), ewentualnie klucz KDS nie jest jeszcze aktywny.
• „Key does not exist” przy tworzeniu konta — brak klucza KDS lub nie minęło 10 godzin od jego utworzenia.
• Usługa nie startuje po wpisaniu konta — brak uprawnienia „Logowanie w trybie usługi” nadanego przez GPO, które nadpisuje lokalne ustawienia, albo literówka w nazwie (brak $).
• Aplikacja nie obsługuje gMSA — niektóre programy wymagają wpisania hasła w swoim kreatorze. Sprawdź dokumentację producenta; Microsoft wspiera gMSA m.in. w SQL Server, IIS i Harmonogramie zadań.
• Problemy z kontrolerem domeny — jeśli serwer w ogóle nie może się połączyć z DC, zacznij od poradnika nie można skontaktować się z kontrolerem domeny Active Directory.

Jeśli dopiero porządkujesz wiedzę o samej usłudze katalogowej, zacznij od tekstu czym jest Active Directory Domain Services — konta usług to jeden z elementów, które warto uporządkować na samym początku.