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 a pomocą 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).
Group Managed Service Accounts (gMSA) czyli Konto Usług Zarządzanych Grupowo może być używane jednocześnie na wielu hostach, 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ólna 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 jeszcze czy możemy już używać klucza poleceniem Test-KdsRootKey
Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
Mamy już klucz teraz możemy już utworzyć konto MSA – posłużymy się komandletem New-ADServiceAccount – uwaga nazwa konta nie może być dłuższa niż 15znakow!:
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 go jednak użyć na maszynie docelowej – należy je tam wcześniej zainstalować.
Proces ten jest niezbędny do użycia MSA – inaczej nawet przy próbie wskazania go otrzymamy komunikat błędu:
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 RSAT-AD-PowerShell
Spróbujmy jeszcze raz zainstalować konto MSA:
Sprawdźmy czy możemy go użyć, test przeprowadzamy poleceniem: Test-ADServiceAccount
W przypadku 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 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ę zabardzo on 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 gMSA. W moim wypadku będą to 3 maszyn.
Dopiero mając taką grupę możemy przejść do tworzenia gMSA. Użyjemy w tym celu również 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 aby móc skorzystać z polecenia Install-ADServiceAccount)
Install-ADServiceAccount account_gMSAPo przeprowadzeniu instalacji jedno konto może być używane na wszystkich maszynach w grupie AD – to jest główna różnica pomiędzy MSA a gMSA.
Pamiętajcie aby po instalacji wykonać odrazu test: Test-ADServiceAccount
Stosując konta MSA i gMSA należy również uwzględniać stosowne uprawnienia dla nich!
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 – głównie gMSA, automatycznie zarządza kontami usług SQL i zmienia je bez ponownego uruchamiania usług SQL. Eliminuje również ryzyko zhakowania hasła lub niewłaściwego użycia do łączenia się z SQL.
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
