W tradycyjnym podejściu do kont dla usług administrator Active Directory zakładał konto użytkownika – rezygnował ze wymuszenia zmiany hasła i z użyciem takiego konta instalował np MS SQL Server.
Nie jest to bezpieczne rozwiązanie (hasło ktoś zna, ktość zapisuje, samo nie podlega zmianie) a już na pewno nie jest to tradycyjne rozwiązanie ponieważ Zarządzane Konto Usługi MSA (Managed Service Account) i Konto Usług Zarządzane Grupowo gMSA (Group Managed Service Accounts) są z nami od Windows Server 2008 R2 (MSA) i Windows Server 2012 (gMSA). Zatem jak ich używać?
Managed Service Account (MSA) to specjalny typ konta w usłudze Active Directory, którego można używać do bezpiecznego uruchamiania usług, aplikacji oraz zaplanowanych zadań. Podstawową ideą MSA i gMSA jest to, że hasła do tych kont są całkowicie zarządzane przez usługę Active Directory.
Hasło jest automatycznie generowane (o długości 240 znaków) i ulega automatycznej zmianie co 30 dni (ustawienie domyślne).
Zablokowane jest interaktywne logowanie, a samo hasło nie jest nikomu znane! Hasło nie jest też przechowywane w systemie lokalnym (nie można wyodrębnić go z procesu systemu LSASS np z użyciem narzędzia mimikatz).
Głównym ograniczeniem MSA jest to, że może być używane tylko na jednym serwerze (nie można ich współdzielić z innymi maszynami czy używać w klastrze).
Aby pozbyć się powyższego ograniczenia możemy użyć Group Managed Service Accounts (gMSA) czyli Konto Usług Zarządzanych Grupowo. gMSA może być używane jednocześnie na wielu hostach i zostało wprowadzone wraz z Windows Server 2012. Dlatego według dokumentacji do poprawnego działania poziom funkcjonalności domeny Active Directory powinien mieć wartość minimum 2012.
Przed użyciem MSA / gMSA musimy w naszej domenie wdrożyć Usługę Dystrybucji Klucza KDS (Key Distribution Service). Usługa ta będzie służyć w kontrolerach domeny do generowania haseł dla MSA / gMSA. Proces ten przeprowadzamy tylko raz dla danego lasu.
Używamy do tego polecenia PowerShell Add-KdsRootKey. Zwróćcie jednak szczególną uwagę na parametry ponieważ domyślnie klucz główny można będzie użyć dopiero po 10 dniach:
# generowanie klucza - domyślna ustawiona data użycia to 10 dni po bieżącej dacie.
Add-KdsRootKey
# generowanie klucza z określoną datą użycia - uwaga wprowadzając bieżącą date nie oznacza to że klucz będzie można używać odrazu - użyj formatu mm/dd/yyyy
Add-KdsRootKey -EffectiveTime <DateTime>
#generowanie klucza który co prawda pojawi się w AD błyskawicznie ale będzie można go użyć po 10h
Add-KdsRootKey -EffectiveImmediately
#natychmiastowe generowanie klucza
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Po wygenerowaniu klucza możemy dokonać jego weryfikacji używając polecenia Get-KdsRootKey
Klucz możemy też podejrzeć w przystawce Active Directory Sites and Services (dssite.msc) (po uprzedniej konfiguracji widoku):
Sprawdźmy czy możemy już używać naszego klucza poleceniem Test-KdsRootKey
Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
Mamy już klucz, teraz możemy utworzyć konto MSA – posłużymy się komandletem New-ADServiceAccount UWAGA: nazwa konta nie może być dłuższa niż 15 znaków!:
New-ADServiceAccount -Name account_MSA –RestrictToSingleComputer -Enabled $True
Sprawdźmy jego status z użyciem polecenia Get-ADServiceAccount
Get-ADServiceAccount account_MSA
Jak widzicie konto zostało utworzone w domyślnym OU Managed Service Accounts
Mamy już utworzone i aktywne kont MSA aby je użyć na maszynie docelowej należy je tam jeszcze „zainstalować”. Proces ten jest niezbędny do użycia samego MSA – inaczej nawet przy próbie wskazania go otrzymamy komunikat błędu:
Aby wykonać instalacje przechodzimy na maszynę docelową i wywołujemy polecenie:
Install-ADServiceAccount -Identity account_MSA
Błąd mówi nam o braku zainstalowanej funkcji RSAT, możemy ją dodać ręcznie z użyciem Add Roles and Features Wizard:
lub dużo szybciej poleceniem PowerShell Add-WindowsFeature
Add-WindowsFeature RSAT-AD-PowerShell
Spróbujmy zatem jeszcze raz zainstalować nasze konto MSA:
Sprawdźmy czy możemy go użyć, test przeprowadzamy poleceniem: Test-ADServiceAccount
W przypadku otrzymania wartości false zazwyczaj oznacza to że konto zostało użyte już gdzieś wcześniej (zainstalowane na innej maszynie). Pamiętajcie że MSA w przeciwieństwie do gMSA może być używane tylko na jednym hoście.
Spróbujmy użyć takiego konta MSA do uruchamiania zadania w Menedżerze Zadań (Task Scheduler):
Prawda że proste łatwe i przyjemne?
Jeżeli będziecie musieli użyć takiego konta gdzieś gdzie GUI będzie miało problem z wyszukaniem MSA – możecie wprowadzić nazwę ręcznie, pamiętając aby poprzedzić ją domeną a na końcu dodać znak $:
TEST\account_MSA$
Hasło powinno uzupełnić się automatycznie.
Przypomnę również że nie mamy w przypadku MSA interaktywnego logowania, zatem nie możemy użyć opcji RunAs w CMD np do wywołania notatnika.
Źródła internetowe wskazują jednak na możliwość użycia narzędzia PsExec z pakietu System Internals. Przy wywołaniu polecenia nazwę użytkownika podajemy według powyższego wzoru z $ a zamiast hasła wprowadzamy znak tyldy ~
.\PsExec64.exe -i -u TEST\account_MSA$ -p ~ cmd.exe
i sprawdzamy kim jesteśmy w CMD:
MSA mamy już opanowane i działające – wróćmy do gMSA.
Utworzenie Group Managed Service Account (gMSA) – nie różni się za bardzo od MSA. Przypominam, że możemy ich używać na kilku hostach jednocześnie i dlatego dla porządku przed utworzeniem gMSA utworzymy grupę security w Active Directory w której będziemy mieli obiekty typu komputer. Obiekty te będą w zamyśle współdzielić używane konto gMSA. W moim wypadku będą to trzy maszyn (serwery MS SQL).
Dopiero mając taką grupę możemy przejść do tworzenia gMSA. Użyjemy w tym celu polecenia New-ADServiceAccount ale z dodatkowymi parametrami:
#tworzenie gMSA dla grupy sql_servers w domenie test.local
New-ADServiceAccount -name account_gMSA -DNSHostName account_gMSA.test.local -PrincipalsAllowedToRetrieveManagedPassword sql_servers
Tak utworzone konto gMSA możemy już instalować na serwerach które mają go używać (powtarzamy kroki jak w przypadku MSA). Skorzystamy z polecenia Install-ADServiceAccount
Install-ADServiceAccount account_gMSAPo przeprowadzeniu instalacji jedno konto może być używane na wszystkich maszynach w grupie AD i to jest główna różnica pomiędzy MSA a gMSA.
Pamiętajcie aby po instalacji wykonać od razu test: Test-ADServiceAccount
Stosując konta MSA i gMSA należy również uwzględniać stosowne uprawnienia – tak jak w przypadku zwykłych kont użytkowników.
Przykładowo jeżeli będziecie chcieli użyć gMSA dla instalacji MS SQL Server należy zezwolić takiemu kontu na zarejestrowanie service principal name (SPN) na potrzeby uwierzytelniania Kerberos. Można to zrobić tą komendą:
dsacls (Get-ADServiceAccount -Identity account_gMSA).DistinguishedName /G "SELF:RPWP;servicePrincipalName" 
O ile na początku cały proces wdrożenia może wydać się wam skomplikowany o tyle zalety i bezpieczeństwo jego zastosowania wygrywa z „tradycyjnym kontem dla usługi”.
Pokazywaliśmy wam jak szyfrować hasło w skryptach ale może zamiast tego użyć MSA i gMSA. Osobiście używam tego rozwiązania w instalacjach MS SQL Server. To własnie gMSA automatycznie zarządza kontami usług SQL i zmienia je bez ponownego uruchamiania. Eliminuje również ryzyko zhakowania hasła lub niewłaściwego użycia do łączenia się z SQL.
Kolejny sprawdzony sposób!
Jeżeli mój wpis Ci się spodobał, pomógł w pracy? Chcesz mnie wspierać? Postaw kawę! To dzięki waszemu wsparciu nie ma reklam! Poniżej kod QR do płatności który jest jednocześnie linkiem do PayPal
