Jak na Group Managed Service Accounts (gMSA)

Pozn.: Článek se zaměřuje na Group Managed Service Accounts, ale řada věcí je společná také pro starší (Standalone) Managed Service Accounts.

Stručně vytvoření a použití gMSA

Článek není příliš dlouhý, ale pokud někdo hledá pouze základní praktické kroky, tak jsou uvedeny v této kapitole. Koho zajímá více informací, tak je nalezne dále.

Vytvoření gMSA účtu v Active Directory

New-ADServiceAccount -Name MSA-service1 -DNSHostName service1.firma.local -PrincipalsAllowedToRetrieveManagedPassword server1$ `
 -KerberosEncryptionType AES128, AES256

Instalace gMSA na server pod admin právy

# pokud potřebujeme instalovat AD PowerShell modul
Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeature
# otestování použití gMSA účtu na serveru před instalací
Test-ADServiceAccount -Identity MSA-service1
# instalace účtu na server
Install-ADServiceAccount -Identity MSA-service1

Nastavení gMSA pro naplánovanou úlohu

Příklad použití gMSA pro Scheduled Task, kdy na existující úloze změníme účet pro běh.

$Principal = New-ScheduledTaskPrincipal -UserID firma\MSA-service1$ -LogonType Password -RunLevel Highest
Set-ScheduledTask -TaskName "Muj skript" -Principal $Principal 

Servisní účty (Service Accounts)

Aplikace a služby často potřebují identitu, aby se mohly ověřit u jiných zdrojů (připojit se po síti jako konkrétní uživatel, apod). K tomu se využívají servisní účty (Service Accounts). Abychom zjednodušili správu a zvýšili bezpečnost, tak můžeme využít Managed Service Accounts. Aplikace nebo služba musí tento typ účtu podporovat.

V praxi často používáme nějaké skripty, které necháváme pravidelně spouštět jako Scheduled Task. Řada z nich nemůže běžet pod účtem SYSTEM, protože potřebuje speciální oprávnění. Proto musíme vytvořit servisní účet, pod kterým běží. Ideálně by každá úloha měla mít svůj vlastní. Tuto situaci nám zjednoduší a lépe zabezpečí Managed Service Accounts. Podobná situace jsou určité speciální služby, které potřebují oprávnění v síti.

Oficiální dokumentace

• Group Managed Service Accounts Overview
• Secure group managed service accounts
• Create a group managed service account (gMSA) in Microsoft Entra Domain Services

Managed Service Accounts (MSA)

• Jsou podporovány od Windows Server 2008 R2.

Standalone Managed Service Accounts (sMSA), původně pouze Managed Service Accounts (MSA), jsou spravované doménové účty, které zajišťuje automatickou správu hesel. Zjednodušují správu SPN a umožňují delegovanou správu na jiné správce. Nemusíme ručně vytvářet přihlašovací údaje k účtu a měnit hesla. Účet může být použit pouze na jednom serveru (je vázán na konkrétní počítač).

Group Managed Service Accounts (gMSA)

• Jsou podporovány od Windows Server 2012. Funkční stupeň Active Directory (AD) domény a lesa musí být minimálně Windows Server 2012.

Group Managed Service Accounts (gMSA) poskytují stejnou funkcionalitu jako MSA, ale rozšiřují použití na více serverů. U řešení s vyváženou zátěží (Load Balanced), nebo obecněji služby na serverové farmě, musí všechny instance služby používat stejný účet (principal). gMSA řeší synchronizaci hesel mezi instancemi služby. Failover cluster nepodporuje gMSA, ale služby běžící na něm je podporovat mohou.

Group Managed Service Accounts jsou nástupcem (Standalone) Managed Service Accounts. Microsoft doporučuje primárně využívat gMSA, pokud nefungují (nejsou podporované), tak zkusit sMSA. Pokud ani zde není úspěch, tak standardní (servisní) uživatelský účet.

Pozn.: Windows Server 2025 přináší novinku v podobě Delegated Managed Service Account (dMSA). Mají řešit některé bezpečnostní nedostatky gMSA.

Hlavní vlastnosti gMSA

• silná hesla - používá náhodně generovaná 240 bytů dlouhá komplexní hesla
• pravidelná změna hesel - správu hesel provádí Windows OS, heslo se mění každých 30 dní (nebo dle nastavení)
• podporuje serverové farmy - můžeme je použít na více serverech, kde běží stejná služba
• nemůže provést interaktivní přihlášení
• používá Kerberos, účet nelze zamknout, neuplatňuje se politika hesel

Pozn.: Jestli jsem dobře pochopil některé poznámky, tak mezi gMSA a sMSA je rozdíl ve správě (změně) hesla. sMSA využívá stejnou metodu jako změna hesla na účtu počítače.

Managed Service Accounts můžeme použít pro

• Windows službu (Windows Service)
• naplánovanou úlohu (Scheduled Task)
• IIS Application Pool (App Pool)
• aplikaci (v rámci aplikace) podporující MSA (například Veeam Backup & Replication)

Více detailů o Managed Service Accounts

• MSA má třídu objektu msDS-ManagedServiceAccount
• gMSA má třídu objektu msDS-GroupManagedServiceAccount
• účty se defaultně vytváří v kontejneru CN=Managed Service Accounts, DC=<domain>, DC=<tld>, MS doporučuje je zde ponechat
• vytváří a spravují se pouze pomocí PowerShell
• Active Directory Users and Computers umožňuje pouze prohlížení (musíme mít zapnuté zobrazení Advanced Features)
• využívá se Microsoft Key Distribution Service (kdssvc.dll) na doménovém řadiči (DC)
  • umožňuje bezpečně získat poslední nebo konkrétní klíč s ID pro AD účet
  • klíče se pravidelně mění
  • doménový řadič vypočítá heslo na základě klíče
  • členské počítače mohou získat heslo od DC

Nasazení Group Managed Service Accounts

Obecné kroky konfigurace účtu

• (pouze poprvé) vytvoření KDS Root Key
• vytvoření gMSA v AD s určením serverů, které jej mohou použít
• instalace gMSA na server
• konfigurace služby/úlohy/aplikace na serveru, aby používala gMSA
• ověření, že služba/úloha/aplikace funguje pod gMSA identitou

Pozn.: Pokud chceme použít účet na více počítačích, tak je nejlepší vytvořit bezpečnostní skupinu (Security Group), do které vložíme účty počítačů, které mohou načíst heslo gMSA účtu.

Vytvoření KDS Root Key

• Create the Key Distribution Services KDS Root Key

Aby mohl doménový řadič (DC) generovat gMSA hesla, tak Key Distribution Services (KDS) potřebuje Root Key (kořenový klíč). Pro správnou funkci musí být replikovaný na všechny DC. Standardně je možno vytvořit účet gMSA až 10 hodin po vytvoření klíče (aby byla jistota, že došlo k replikaci).

Kontrola, zda existuje KDS Root Key

Můžeme využít MMC Snap-In Active Directory Sites and Services. Klíče se nachází v Services - Group Key Distribution Service - Master Root Keys.

Nebo můžeme použít PowerShell cmdlet, který vypíše seznam klíčů.

Get-KdsRootKey

Vygenerování nového KDS Root Key

Použijeme PowerShell cmdlet. Musí běžet služba Key Distribution Service.

Add-KdsRootKey -EffectiveImmediately

Smazání KDS Root Key

V dokumentaci PowerShell cmdletů pro KDS se nenachází žádný pro odstranění KDS Root Key. Ale pokud použijeme Active Directory Sites and Services, tak můžeme klíče jednoduše smazat (jako jiné objekty).

Vytvoření a správa Managed Service Account

Pro vytvoření účtu se používá PowerShell cmdlet New-ADServiceAccount. Pro další operace Get-ADServiceAccount, Set-ADServiceAccount, Test-ADServiceAccount, Remove-ADServiceAccount.

Vytvoření Standalone Managed Service Accounts (sMSA)

New-ADServiceAccount -Name Service-sMSA -RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity server -ServiceAccount Service-sMSA

Vytvoření Group Managed Service Accounts (gMSA)

New-ADServiceAccount -Name Service-gMSA -DNSHostName service.firma.local -PrincipalsAllowedToRetrieveManagedPassword server$ `
 -KerberosEncryptionType AES128, AES256

• Name - jméno vytvářeného účtu, maximálně 15 znaků (omezení samAccountName), což omezuje možnosti popisného názvu typu MSA-název-serveru-jméno-služby
• DNSHostName - DNS jméno sužby (FQDN), jde o povinný parametr, ale prý má smysl pouze pro služby používající Kerberos (nenalezl jsem vysvětlení významu a použití tohoto parametru, více účtů jej může mít stejný)
• PrincipalsAllowedToRetrieveManagedPassword - počítač/e, které mohou používat gMSA, můžeme zadat jména počítačů (s $ na konci, jde o sAMAccountName) oddělené čárkou nebo bezpečnostní skupinu, která obsahuje jejich účty
• KerberosEncryptionType - povolené typy šifrování pro Kerberos (dnes bychom neměli používat RC4, viz. Kerberos deaktivace RC4)
• ServicePrincipalNames - určuje SPN pro účet, pokud je chceme ručně definovat
• ManagedPasswordIntervalInDays - pokud chceme, aby se heslo měnilo po jiném počtu dní než 30, může se nastavit pouze při vytváření
• Description - můžeme zadat popis účtu

Změna nastavení gMSA

Set-ADServiceAccount -Identity Service-gMSA -PrincipalsAllowedToRetrieveManagedPassword server1$,server2$

Seznam a informace o Managed Service Accounts

Get-ADServiceAccount -Filter *
Get-ADServiceAccount Service-gMSA -Properties * | Select-Object * 

Smazání Managed Service Account

Remove-ADServiceAccount -Identity Service-gMSA 

Test Managed Service Account

Na počítači, který má povoleno použití gMSA, můžeme otestovat funkčnost (autentizaci). Účet nemusí být na počítači instalovaný (ač různé články uvádí opak).

Test-ADServiceAccount -Identity Service-gMSA 

Pokud sMSA účet není přiřazen k žádnému počítači, tak dostaneme chybu:

WARNING: The Managed Service Account Service-sMSA is not linked with any computer object in the directory.

Pokud test spustíme na jiném počítači, než je přiřazen k účtu, tak dostaneme chybu:

WARNING: Test failed for Managed Service Account Service-gMSA. If standalone Managed Service Account, the account is linked to
 another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission
 to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA
 operational log for more information.

Instalace Managed Service Account na serveru

Abychom mohli MSA účet na serveru využít, tak jej zde musíme nainstalovat/kešovat (v praxi funguje účet i bez instalace, ale asi bude problém se změnou hesla). Využíváme PowerShell cmdlet Install-ADServiceAccount a Uninstall-ADServiceAccount.

Pokud na serveru nemáme Remote Server Administration Tools pro AD DS (stačí Active Directory module for Windows PowerShell), tak musíme nejprve nainstalovat (buď pouze PowerShell module nebo celé AD DS Tools).

Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeature
Install-WindowsFeature RSAT-ADDS -IncludeAllSubFeature

Instalace MSA

Provádí se lokálně na počítači. Cmdlet ověří, že počítač může hostovat daný účet (pokud něco selže, tak vrací obecnou chybu, můžeme použít Test). Provede potřebné lokální úpravy, aby mohlo být spravováno heslo.

Install-ADServiceAccount -Identity Service-gMSA

Odinstalování zadaného MSA

Uninstall-ADServiceAccount Service-gMSA

Zažazení účtu do skupiny

Aby služba/úloha korektně běžela, tak často potřebuje MSA účet určitá oprávnění. Můžeme mu standardně nastavit práva na souborovém systému, zařadit jej do skupin v AD doméně nebo jej zařadit do lokální skupiny. To poslední provedeme také standardně na serveru, buď pomocí GUI nebo PowerShellu.

Add-LocalGroupMember -Group "Administrators" -Member Service-gMSA$ 

Použití Managed Service Accounts

Jméno MSA účtu se zadává s dolarem na konci, stejně jako pro účet počítače. Je to jeho sAMAccountName (NetBIOS místo FQDN). Tedy například Service-gMSA$, můžeme (někdy musíme) použít i s doménou FIRMA\Service-gMSA$ (NetBIOS Logon Name).

Spuštění příkazu pod MSA účtem

Když chceme otestovat (nebo řešit problémy) skript či aplikaci, které budeme spouštět pod MSA účtem (třeba v naplánované úloze), tak se hodí použití RunAs. Tedy spustit například příkazovou řádku (cmd.exe) nebo PowerShell po jiným účtem, abychom viděli výstupy, chyby a chování. To ale pro MSA účty nefunguje. Místo toho můžeme použít PsExec.

PsExec64.exe -i -u firma\Service-gMSA$ -p ~ cmd.exe

MSA pro Windows službu

Účet potřebuje oprávnění Log on as a service. Pokud je v lokální skupině Administrators, tak práva má. Jinak můžeme využít Group Policy nebo Local Security Policy (secpol.msc). Do politiky Log on as a service přidáme náš účet. Nachází se pod [Computer Configuration/Windows Settings/]Security Settings/Local Policies/User Rights Assignment.

Ve vlastnostech služby na záložce Log On zvolíme This account a najdeme/zadáme účet. Heslo necháme prázdné.

MSA pro naplánovanou úlohu (Scheduled Task)

Účet potřebuje oprávnění Log on as a batch job, které můžeme nastavit podobně jako v předchozím bodě.

Task Scheduler GUI nepodporuje zadání MSA jako účtu pro běh úlohy (ani je nenabízí). Proto musíme použít PowerShell. Celou úlohu můžeme vytvořit pomocí PowerShellu nebo ji nejprve vytvořit v Task Scheduler a pak pouze modifikovat účet pro běh.

$Principal = New-ScheduledTaskPrincipal -UserID "firma\Service-gMSA$" -LogonType Password -RunLevel Highest
Set-ScheduledTask -TaskName "CDR" -TaskPath "\SCSM\" -Principal $Principal 

Úlohu poté můžeme zobrazit v Task Scheduler, ale nelze ji upravit (při uložení zobrazí chybu neznámý účet).

Pozn.: Otázka oprávnění může být komplikovaná. Vypadá to, že při určité situaci potřebuje účet také práva Log on as a service, aby se pod ním dala spustit úloha. Pokud je nemá, tak se loguje událost Event ID 101 Task Start Failed a obsahuje chybu Error Value: 2147943785.

Send-MailMessage a chyba net_io_connectionclosed

Narazil jsem na problém, když v naplánované úloze běží PowerShell skript, který má poslat email bez autentizace. Pod běžným uživatelem funguje, ale pod Managed Service Accounts ne a cmdlet Send-MailMessage vrací chybu:

Send-MailMessage : Unable to read data from the transport connection: net_io_connectionclosed.

Až po nějaké době jsem v jedné diskusi nalezl funkční řešení. Musí se explicitně zadat anonymní odeslání.

$cred = New-Object PSCredential -ArgumentList "NT AUTHORITY\ANONYMOUS LOGON",(ConvertTo-SecureString -AsPlainText -Force -String "anon")
Send-MailMessage <naše parametry> -Credential $cred