Konto svc_sql powstało razem z serwerem bazy danych i od tamtej pory ma to samo hasło. Znają je dwaj administratorzy, a jego zmiana oznacza ręczną aktualizację trzech serwerów aplikacji i okno serwisowe, na które nikt nie ma czasu. Konto ma zarejestrowaną nazwę SPN, więc każdy zalogowany użytkownik domeny może poprosić kontroler o bilet tej usługi i łamać hasło na własnym komputerze, nie zostawiając w dzienniku ani jednego nieudanego logowania.
Group Managed Service Account (gMSA) usuwa ten problem u źródła: hasło liczy kontroler domeny, jest długie i losowe, a zmienia się samo. Nie jest to jednak przełącznik: gMSA przenosi sekret na listę komputerów, które mogą pobrać hasło, nie obsługuje każdej usługi i wymaga kilku warunków po stronie domeny. Od tych granic zależy, czy migracja kont usługowych podniesie poziom cyberbezpieczeństwa domeny, czy tylko przesunie ryzyko.
Czym jest gMSA i czym różni się od zwykłego konta usługowego?
gMSA to konto domenowe, na którym działają usługi na wielu serwerach, a jego hasłem zarządza system operacyjny, nie administrator. Dokumentacja Microsoft Learn opisuje je jako rozszerzenie standalone Managed Service Account (sMSA), typu konta wprowadzonego w Windows Server 2008 R2 i Windows 7: sMSA działa na jednym serwerze, gMSA na całej farmie.
Konto użytkownika w roli konta usługowego ma hasło ustawione ręcznie, które ktoś musi znać, wpisać w konfiguracji każdej instancji usługi i zmieniać wszędzie naraz. gMSA nie ma hasła znanego człowiekowi: usługa dostaje je od kontrolera domeny, a w jej konfiguracji pole hasła zostaje puste. gMSA nie obsługuje systemów starszych niż Windows Server 2012.
Dla farm serwerów, na przykład za modułem równoważenia obciążenia, gMSA daje jedną tożsamość wszystkim instancjom usługi. Protokoły z wzajemnym uwierzytelnieniem, takie jak Kerberos, działają tylko wtedy, gdy wszystkie instancje usługi używają tego samego podmiotu zabezpieczeń.
Dlaczego konta usługowe ze stałym hasłem przyciągają atakujących?
Bo hasło konta usługowego z nazwą SPN da się łamać offline, a stałe hasło daje atakującemu tyle czasu, ile potrzebuje. Technikę opisuje MITRE ATT&CK jako T1558.003 i nazywa kerberoastingiem: posiadacz ważnego biletu TGT może poprosić kontroler domeny o bilety usług dla dowolnej nazwy SPN, a część takiego biletu bywa zaszyfrowana algorytmem RC4 kluczem wyprowadzonym z hasła konta usługowego.
Dla obrońcy kłopot polega na tym, że żądanie biletu usługi to zwykła operacja protokołu. Atakujący nie wywołuje blokady konta: pobiera bilet i łamie go na własnym sprzęcie, a w domenie zostaje tylko zdarzenie żądania biletu. MITRE wskazuje jako sygnał wykrycia nietypowe żądania biletów TGS (zdarzenie 4769) z szyfrowaniem RC4 oraz nienaturalnie dużą liczbę żądań w krótkim czasie.
Skuteczność ataku zależy od hasła. W opisie tej techniki (wersja 19 bazy ATT&CK) MITRE zaleca dla kont usługowych hasła długie, najlepiej co najmniej 25-znakowe, złożone i okresowo wygasające, a także rozważenie Group Managed Service Accounts albo sejfu haseł oraz szyfrowania AES zamiast RC4. Hasło nadane ręcznie przy instalacji serwera i niezmieniane od lat nie spełnia żadnego z tych warunków.
Migrację kont serwisowych do gMSA wśród działań o wysokim priorytecie wymienia też artykuł o hardeningu Active Directory.
Jak gMSA zarządza hasłem bez udziału administratora?
Hasło gMSA liczy kontroler domeny z klucza dostarczanego przez usługę Microsoft Key Distribution Service (KDS) i z atrybutów konta, a serwery uprawnione do konta pobierają je od kontrolera. Według dokumentacji Microsoft hosty członkowskie mogą uzyskać bieżące i poprzednie hasło, więc moment zmiany nie musi oznaczać przerwy w działaniu usługi.
Parametry podaje przewodnik Microsoft Secure group managed service accounts: hasła mają 240 bajtów i są generowane losowo, a Windows zmienia je co 30 dni. Według Microsoft długość i złożoność takich haseł minimalizują ryzyko złamania atakiem siłowym albo słownikowym.
Interwał zmiany ustala się raz. Parametr -ManagedPasswordIntervalInDays polecenia New-ADServiceAccount można podać tylko przy tworzeniu konta, a bez wartości obowiązuje 30 dni. Kto po utworzeniu konta zechce innego interwału, musi założyć nowe gMSA, dlatego tę decyzję warto podjąć przed migracją.
Cały mechanizm opiera się na kluczu głównym KDS przechowywanym w Active Directory, w kontenerze konfiguracji lasu. Microsoft ostrzega, że usunięcie i ponowne utworzenie klucza głównego może sprawić, że stary klucz będzie nadal używany z pamięci podręcznej, a po ponownym utworzeniu trzeba zrestartować KDC na wszystkich kontrolerach domeny.
Jakie warunki trzeba spełnić przed wdrożeniem gMSA?
Domena i las muszą mieć poziom funkcjonalny co najmniej Windows Server 2012, w domenie musi istnieć klucz główny KDS, a osoba tworząca konta musi należeć do grupy Domain Admins albo Enterprise Admins lub mieć delegowane uprawnienie do tworzenia obiektów msDS-GroupManagedServiceAccount. Tak wymagania opisuje strona Manage group Managed Service Accounts w Microsoft Learn.
Najwięcej niespodzianek daje klucz główny KDS. Po jego utworzeniu kontrolery domeny czekają do 10 godzin, zanim pozwolą utworzyć gMSA, żeby klucz zdążył się zreplikować na wszystkie kontrolery. Parametr -EffectiveImmediately dodaje klucz używany od razu, ale tylko na kontrolerze, na którym go utworzono; pozostałe skorzystają z niego dopiero po replikacji. Cofnięcie czasu efektywności klucza o 10 godzin Microsoft przewiduje wyłącznie dla środowisk testowych z jednym kontrolerem.
Drugi warunek dotyczy szyfrowania Kerberos. Konta zarządzane zależą od obsługiwanych typów szyfrowania, a Microsoft zaleca, by dla kont MSA zawsze konfigurować AES. Wszystkie systemy, które logują się jako gMSA albo je instalują, muszą obsługiwać typy szyfrowania wymagane przez gMSA, inaczej logowanie się nie powiedzie.
Przed oknem migracji warto też sprawdzić pozostałe pozycje z listy Microsoft: 64-bitową architekturę do poleceń PowerShell, zarejestrowane nazwy SPN, rekordy DNS i zsynchronizowany czas na systemach biorących udział w uwierzytelnianiu.
Jak utworzyć i zainstalować gMSA krok po kroku?
Wdrożenie składa się z czterech kroków: klucz główny KDS (operacja jednorazowa), konto gMSA z listą uprawnionych komputerów, instalacja konta na każdym serwerze usługi i przełączenie usługi na nową tożsamość.
# 1. Klucz główny KDS — jednorazowo, na kontrolerze domeny
Add-KdsRootKey -EffectiveImmediately
# 2. Konto gMSA; hasło może pobrać grupa serwerów usługi
New-ADServiceAccount -Name svc-sql -DNSHostName svc-sql.firma.local -PrincipalsAllowedToRetrieveManagedPassword "Serwery-SQL"
# 3. Na każdym serwerze usługi
Install-ADServiceAccount -Identity svc-sql
Test-ADServiceAccount -Identity svc-sqlListę uprawnionych komputerów lepiej prowadzić przez grupę zabezpieczeń: Microsoft radzi dodać konta komputerów hostujących usługę do wyznaczonej grupy i nadać uprawnienia tej grupie. Nowy serwer farmy dostaje wtedy dostęp przez dopisanie do grupy.
Nazwa gMSA musi być unikalna w całym lesie, nie tylko w domenie, a próba utworzenia konta o powtórzonej nazwie kończy się błędem nawet w innej domenie. Test-ADServiceAccount sprawdza, czy dany serwer może pobrać hasło, i to jego wynik warto zachować jako dowód wykonania.
Ostatni krok wykonuje się w konfiguracji usługi. Według przewodnika Microsoft zmienia się tożsamość usługi na gMSA, zostawia puste pole hasła, sprawdza działanie usługi pod nową tożsamością i dopiero potem usuwa stare konto usługowe. Ta kolejność zostawia drogę powrotu, gdyby usługa nie wystartowała.
Których usług nie przeniesiesz na gMSA?
Nie przeniesiesz usług, które nie obsługują kont zarządzanych, ani samych klastrów pracy awaryjnej. Microsoft pisze wprost, że klastry pracy awaryjnej nie obsługują gMSA, ale usługi działające na klastrze mogą używać gMSA albo sMSA, jeśli są usługą Windows, pulą aplikacji, zadaniem harmonogramu albo natywnie obsługują konta zarządzane.
Po stronie hosta gMSA obsługują usługi konfigurowane przez Service Control Manager, pule aplikacji IIS, zadania Harmonogramu zadań oraz produkty obsługujące sMSA, bo gMSA korzysta z tych samych interfejsów API. Aplikację, która przechowuje poświadczenia we własnej konfiguracji albo wymaga wpisania hasła w kreatorze, trzeba sprawdzić w dokumentacji producenta, zanim trafi na listę migracji.
Microsoft zaleca przetestowanie usługi z gMSA w środowisku testowym przed produkcją. Gdy usługa nie obsługuje gMSA, kolejnym wyborem jest sMSA, czyli ta sama funkcjonalność na jednym serwerze. Gdy i to nie wchodzi w grę, zostaje zwykłe konto użytkownika, przy którym trzeba utrzymać silny proces zarządzania hasłem, na przykład przez sejf haseł z rotacją.
Najważniejsze:
- gMSA to konto domenowe dla usług na wielu serwerach, a jego hasło liczy kontroler domeny, nie człowiek.
- Hasło ma 240 bajtów, jest losowe i zmienia się automatycznie; interwał ustala się tylko przy tworzeniu konta.
- Pierwsze gMSA powstanie dopiero po replikacji klucza głównego KDS, a kontrolery czekają na nią do 10 godzin.
- Klastry pracy awaryjnej nie obsługują gMSA, a usługi bez obsługi kont zarządzanych potrzebują innego rozwiązania.
Czy gMSA całkowicie chroni przed kerberoastingiem?
Nie całkowicie. Długie, losowe hasło utrudnia złamanie biletu offline, ale konto można przejąć inną drogą: przez komputer, który ma prawo pobrać hasło.
Lista PrincipalsAllowedToRetrieveManagedPassword staje się nowym sekretem. Każdy komputer z tej listy, a więc także każdy, kto przejmie na nim uprawnienia administratora, może uzyskać hasło konta. Microsoft w opisie dMSA przyznaje to wprost: hasła gMSA są generowane maszynowo i zmieniane automatycznie, ale nie są związane z maszyną i mogą zostać skradzione.
Druga pułapka to uprawnienia. gMSA bezpieczniej zarządza hasłem, ale nie ogranicza tego, co konto może zrobić. Microsoft wymienia dwa ryzyka: gMSA w grupach uprzywilejowanych oraz gMSA z prawem odczytu lub zapisu do wrażliwych zasobów. Zalecenia brzmią: usunąć konto z grup uprzywilejowanych, nadać mu tylko uprawnienia wymagane przez usługę, audytować dostęp do wrażliwych zasobów i odebrać zbędne uprawnienia.
Migracja na gMSA z zachowaniem członkostwa w Domain Admins zamienia słabe hasło na silne, ale zostawia konto, którego przejęcie daje całą domenę, dlatego przegląd uprawnień idzie razem z migracją.
Czym jest dMSA w Windows Server 2025 i kiedy go rozważyć?
dMSA (delegated Managed Service Account) to typ konta wprowadzony w Windows Server 2025, który zastępuje tradycyjne konto usługowe kontem związanym z maszyną i wyłącza hasło pierwotnego konta. Według dokumentacji Microsoft uwierzytelnianie dMSA jest powiązane z tożsamością urządzenia, więc z konta mogą korzystać tylko wskazane maszyny, co ma zapobiegać kradzieży poświadczeń przez kerberoasting.
Zasadnicza różnica wobec gMSA dotyczy miejsca sekretu. Sekret dMSA, wyprowadzony z poświadczeń konta maszyny, jest przechowywany na kontrolerze domeny i według Microsoft nie da się go pobrać ani znaleźć nigdzie indziej; można go dodatkowo chronić funkcją Credential Guard. W gMSA hasło trafia na każdy uprawniony serwer.
dMSA nie jest jednak następnym krokiem po gMSA. Microsoft zaznacza, że migracja z konta zarządzanego ani z gMSA do dMSA nie jest możliwa, bo dMSA zastępuje zwykłe konta usługowe. Wymaga też cierpliwości: po zmianie deskryptora zabezpieczeń trzeba odczekać co najmniej dwa okresy ważności biletów (14 dni) przed zakończeniem migracji, a każda maszyna korzystająca z konta musi obsługiwać dMSA, inaczej po wyłączeniu starego konta straci uwierzytelnianie.
Sam typ konta też miał lukę. W sierpniu 2025 r. Microsoft załatał podatność CVE-2025-53779 w Kerberos: według opisu producenta atakujący z prawem zapisu atrybutów obiektu dMSA, w tym msDS-ManagedAccountPrecededByLink, mógł uzyskać uprawnienia administratora domeny. Badacze Akamai, którzy opisali tę technikę jako BadSuccessor, zalecają najpierw zaktualizować kontrolery domeny z Windows Server 2025, a potem przejrzeć uprawnienia do jednostek organizacyjnych, kontenerów i obiektów dMSA. Prawo tworzenia kont dMSA traktuj jak uprawnienie uprzywilejowane.
Jak znaleźć konta usługowe, które wymagają migracji?
Zacznij od dwóch list: kont zarządzanych, które już istnieją, i kont użytkowników z zarejestrowaną nazwą SPN. Pierwszą zwraca polecenie Get-ADServiceAccount -Filter *, a Microsoft zaznacza, że gMSA rozpoznaje się po klasie obiektu msDS-GroupManagedServiceAccount, sMSA zaś po msDS-ManagedServiceAccount.
# Konta zarządzane (gMSA i sMSA)
Get-ADServiceAccount -Filter * | Select-Object Name, ObjectClass
# Konta użytkowników z nazwą SPN — kandydaci do migracji
Get-ADUser -Filter "ServicePrincipalName -like '*'" -Properties ServicePrincipalName, PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet, ServicePrincipalNameDruga lista jest ważniejsza. Konto użytkownika z nazwą SPN to dokładnie ten cel, o którego bilet prosi atakujący w kerberoastingu, a kolumna PasswordLastSet pokazuje, od kiedy hasło się nie zmieniło. Konta z hasłem ustawionym przed laty i członkostwem w grupach uprzywilejowanych idą na początek kolejki.
Trzecim źródłem są zdarzenia 4769 opisane w sekcji o kerberoastingu.
Jak zaplanować migrację kont usługowych na gMSA?
Migrację planuje się per konto, a nie per serwer: każde konto usługowe dostaje docelowy typ, warunek przejścia i dowód, że usługa działa pod nową tożsamością. Tabela porządkuje decyzje, które wracają przy każdym koncie.
| Sytuacja konta | Docelowy typ | Warunek przejścia | Typowa pułapka | Dowód wykonania |
|---|---|---|---|---|
| Usługa Windows na kilku serwerach (farma, równoważenie obciążenia) | gMSA | grupa serwerów w PrincipalsAllowedToRetrieveManagedPassword, AES na hostach | konto zostaje w grupie uprzywilejowanej | wynik Test-ADServiceAccount na każdym hoście, lista grup konta |
| Usługa na jednym serwerze | gMSA albo sMSA | usługa obsługuje konta zarządzane | interwał hasła ustawiony bez decyzji | wartość msDS-ManagedPasswordInterval konta |
| Pula aplikacji IIS albo zadanie harmonogramu | gMSA | tożsamość ustawiona z pustym hasłem | stare konto usunięte przed testem | dziennik działania usługi pod nową tożsamością |
| Klaster pracy awaryjnej (sam klaster) | bez gMSA | nie dotyczy | próba migracji wbrew dokumentacji | decyzja w rejestrze kont z uzasadnieniem |
| Aplikacja bez obsługi kont zarządzanych | konto użytkownika w sejfie haseł | długie losowe hasło, rotacja, wskazany właściciel | hasło znane kilku osobom | historia rotacji i dostępów w sejfie |
| Zwykłe konto usługowe w środowisku z Windows Server 2025 | dMSA | wszystkie maszyny obsługują dMSA, co najmniej 14 dni na migrację | migracja przy niesprawnej replikacji | msDS-DelegatedMSAState = 2 (migracja zakończona) |
Kolejność migracji wynika z ryzyka: najpierw konta użytkowników z nazwą SPN i uprawnieniami uprzywilejowanymi, potem pozostałe konta z SPN, na końcu konta bez SPN.
Jak nFlo może pomóc w zabezpieczeniu kont usługowych?
nFlo prowadzi Audyt Bezpieczeństwa Active Directory, którego zakres obejmuje konta usługowe, konfigurację Kerberos i ścieżki ataku, w tym kerberoasting. Audyt korzysta z BloodHound, PingCastle i Purple Knight w trybie tylko do odczytu, a jego wynikiem jest mapa ścieżek ataku i priorytetyzowany plan hardeningu, w którym migracja kont usługowych dostaje swoje miejsce w kolejce.
Dla kont, których nie da się przenieść na gMSA, nFlo wdraża One Identity Safeguard for Privileged Passwords: sejf na hasła kont uprzywilejowanych z rotacją, wnioskiem o dostęp z zatwierdzaniem i automatycznym wykrywaniem kont uprzywilejowanych w sieci. Hasło konta przestaje wtedy krążyć między ludźmi, a każdy dostęp zostawia ślad audytowy.
Jeśli chcesz sprawdzić, ile kont usługowych w Twojej domenie ma nazwę SPN i hasło sprzed lat, porozmawiaj z nami.
Co jeszcze warto wiedzieć o gMSA?
Czy administrator musi zmieniać hasło gMSA?
Nie. Hasło liczy kontroler domeny, a Windows zmienia je sam, w interwale ustalonym przy tworzeniu konta. W konfiguracji usługi pole hasła zostaje puste, a serwery uprawnione do konta pobierają bieżące hasło od kontrolera.
Czy gMSA działa w klastrze pracy awaryjnej?
Sam klaster pracy awaryjnej nie obsługuje gMSA. Usługi uruchomione na klastrze mogą jednak używać gMSA albo sMSA, jeśli są usługą Windows, pulą aplikacji, zadaniem harmonogramu albo natywnie obsługują konta zarządzane.
Ile trzeba czekać na pierwsze gMSA po utworzeniu klucza KDS?
Do 10 godzin. Kontrolery domeny czekają tyle po utworzeniu klucza głównego KDS, żeby klucz zdążył się zreplikować. Skrócenie tego czasu Microsoft przewiduje tylko dla środowisk testowych z jednym kontrolerem domeny.
Czy można zmienić interwał zmiany hasła istniejącego gMSA?
Nie. Interwał ustawia parametr -ManagedPasswordIntervalInDays wyłącznie przy tworzeniu konta, a bez podanej wartości obowiązuje 30 dni. Inny interwał wymaga utworzenia nowego gMSA i przełączenia na nie usługi.
Czy konto gMSA można przenieść na dMSA?
Nie. Microsoft zaznacza, że migracja z konta zarządzanego ani z gMSA do dMSA nie jest możliwa. dMSA, wprowadzony w Windows Server 2025, zastępuje zwykłe konta usługowe, a nie konta już zarządzane przez system.
