Group Managed Service Accounts (gMSA)

Ich stelle immer häufiger fest, dass Group Managed Service Accounts, kurz gMSA, nur selten in den Kundenprojekten bekannt sind oder berücksichtigt werden. Die häufigsten Gründe hierfür sind oft die Argumente, dass es zu komplex sei, einen gMSA anzulegen bzw. zu verwenden. Dabei überwiegen die Vorteile eines gMSA- Kontos gegenüber dem effektivem, administrativen Aufwand im Betrieb!

Erläuterung

Group Managed Service Accounts sind im Active Directory hinterlegte Systemkonten, ohne deren aktuelles Kennwort jemals kennen zu müssen. gMSA- Konten werden meist für einzelne Windows Dienste (services.msc) oder einzelne Aufgaben in der Windows Aufgabenplanung (taskschd.msc) verwendet, und bei modernen Anwendungen können diese Systemkonten hin und wieder ebenfalls Anwendung finden.

Vorteile

• Group Managed Service Accounts erhöhen in erster Linie das Sicherheitsniveau in der Windows Domäne.
• Keine Kenntnis der Kennwörter notwendig.
• Kennwörter werden durch das Active Directory nach 30 Tagen standardmäßig geändert, ohne jegliche Auswirkung auf den Betrieb. Der Standardwert lässt sich via PowerShell natürlich abändern.
• gMSA- Konten sind nur auf berechtigten Hostsystemen installier- und verwendbar!
• gMSA- Konten lassen sich in bestehende „Rollen- und Berechtigungskonzepte (RUB)“ integrieren.
• BSI- Konform (APP.2.2.A5).

Nachteile

• Administration eines gMSA- Kontos ist nicht GUI basiert, ausschließlich via PowerShell möglich!
• Die Windows Aufgabenplanung ist in Verbindung mit gMSA- Konten etwas umständlich zu implementieren.
• In Verbindung mit den Windows Diensten ist nach Abänderung auf einen gMSA- Kontos, per Standard ein erneutes abändern der auszuführenden Benutzerkonten nicht mehr über die GUI möglich. Das lässt sich aber leicht umgehen (siehe unten)!

Abhängigkeiten

• Das Active Directory (je Forest) muss für Group Managed Service Accounts vorbereitet werden!
• Group Managed Accounts sind grundsätzlich nur verwendbar, wenn diese Systemkonten den entsprechenden Hostsystemen zugewiesen werden. Hierzu ist es stets empfehlenswert, entsprechende AD- Gruppen anzulegen und die Mitglieder aufzunehmen!
• Die Hostsysteme sollten nach Möglichkeit via PowerShell Remoting administrierbar sein, ist jedoch nicht zwingend erforderlich. Hierzu notfalls die Befehle je Hostsystem lokal ausführen, sobald die Vorbereitungen erfüllt sind!

Vorbereitungen

# gMSA- Erstellung je Forest nur 1x notwendig - initial (10 Std. warten - Replikation)
Add-KdsRootKey -EffectiveImmediately

Erstellung

# Neue gMSA- Gruppe erstellen
New-ADGroup `
-Path "CN=<OU>,DC=<DOMAIN>,DC=<TLD>" `
-Name <NEWGROUPNAME> `
-GroupScope DomainLocal `
-Description "Beschreibung" `
-DisplayName "<NEWGROUPNAME>" `
-GroupCategory Security `
-SamAccountName <NEWGROUPNAME> `
-PassThru

# gMSA- Gruppenmitglieder hinzufügen
Add-ADGroupMember `
-Identity <NEWGROUPNAME> `
-Members "SERVER01$","SERVER02$" `
-PassThru

# Kontrolle
Get-ADGroupMember -Identity <NEWGROUPNAME>

# Neuen ServiceAccount anlegen
New-ADServiceAccount `
-Name <SRVNAME$> `
-DNSHostname <SRVNAME>.<DOMAIN>.<TLD> `
-PassThru

# Neuen ServiceAccount bearbeiten
Set-AdServiceAccount `
-Identity <SRVNAME$> `
-KerberosEncryptionType "AES128, AES256" `
-PrincipalsAllowedToRetrieveManagedPassword <NEWGROUPNAME> `
-PrincipalsAllowedToDelegateToAccount <NEWGROUPNAME> `
-PassThru

# Kontrolle der Propertie- Übersicht des ServiceAccounts
Get-ADServiceAccount <SRVNAME$> -Properties *

Sollten in den nächsten Zeilen Verbindungsprobleme zu den Hostsystemen in der PowerShell auftreten, sind die Befehle zwischen den geschweiften Klammern {} jeweils auf den Hostsystemen lokal auszuführen!

# Neustarten der Hostsysteme (Übernahme der Gruppenzugehörigkeit)
Invoke-Command `
-ComputerName <SERVER01>, <SERVER02> `
-ScriptBlock {Restart-Computer -Force}

# RSAT-AD-PowerShell auf Hostsystemen installieren
Invoke-Command `
-ComputerName <SERVER01>, <SERVER02> `
-ScriptBlock {Add-WindowsFeature RSAT-AD-PowerShell}

# ServiceAccount auf Hostsystemen installieren
Invoke-Command `
-ComputerName <SERVER01>, <SERVER02> `
-ScriptBlock {Install-ADServiceAccount -Identity <SRVNAME$>}

# Kontrolle
Invoke-Command `
-ComputerName <SERVER01>, <SERVER02> `
-ScriptBlock {Test-AdServiceAccount -Identity <SRVNAME$>}

Das ist es auch schon gewesen! Die Computergruppe mit den Mitgliedern (Computerobjekte) und das gMSA- Konto sind angelegt… und einsatzbereit! Das gMSA- Konto kann jetzt überall dort verwendet werden, wo es gebraucht wird.

Mögliche Einsatzszenarien

• Windows Aufgabenplanung
• Windows Dienste
• Windows Dateiberechtigungen
• Windows Monitoring
• …

Windows Aufgabe in der Aufgabenplanung erstellen

$TaskAction = New-ScheduledTaskAction "<Program|Script>"
$TaskTrigger = New-ScheduledTaskTrigger -At <Time-24h> -Daily|Weekly|Monthly
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID <DOMAIN>\<SRVNAME$> -LogonType Password

Register-ScheduledTask <TASKNAME> –Action $TaskAction –Trigger $TaskTrigger –Principal $TaskPrincipal

Alternativ kann eine Aufgabe auf dem herkömmlichen Wege eingerichtet werden, jedoch muss das auszuführende Konto (gMSA) entsprechend hinterlegt werden und hierbei ist stets eine bestimmte Reihenfolge zu berücksichtigen:

(im Editormodus!)

• Benutzer und Gruppe ändern…
• Pfade…
• Gesamtes Verzeichnis
• Objekttypen…
• Alles bis auf „Dienstkonten“ deaktivieren!
• gMSA- Konto suchen und verifizieren
• Aufgabe abschließen!

Hinweis:
Diese Prozedur muss auch bei jeglichen Änderungen an den bestehenden Aufgaben erneut durchgeführt werden, in derselben Reihenfolge!

Windows Dienst umstellen

$ADDomain = '<DOMAIN>.<TLD>'
$ServiceName = 'SVCNAME'
$gMSA = 'SRVNAME$'

$Account = $ADDomain + "\" + (Get-ADServiceAccount -Identity $gMSA).SAMAccountName
$Service = Get-WmiObject Win32_Service -Filter "Name='$ServiceName'"

$Service.Change($null,$null,$null,$null,$null,$null,$Account,$null,$null,$null,$null)

Troubleshooting

Es kann natürlich passieren, dass der Einsatz eines gMSA- Kontos nicht auf anhieb funktioniert. Bitte bedenkt, welche Berechtigungen das gMSA- Konto am Ende tatsächlich benötigt. Sprich, auch mit der entsprechend, hinterlegten Berechtigung, kann noch immer das User Account Control, kurz UAC, zuschlagen und die Ausführung von Skripten / Aufgaben verhindern. Diese Tatsache muss stets berücksichtigt werden!

Abgeänderte Windows Dienste lassen sich GUI basiert nicht mehr ändern (Anmelden Als)

# "Anmelden als" für Windows-Dienst auf lokale Systemkonten zurücksetzen
sc.exe config "SVCNAME" obj= "NT AUTHORITY\NetworkService" password= " "
sc.exe config "SVCNAME" obj= "NT AUTHORITY\SYSTEM" password= " "

# Aktivieren der "Anmelden als"- Felder 
# (falls Administration deaktiviert ist - ausgegraut)
sc.exe ManagedAccount "SVCNAME" false

# Deaktivieren der "Anmelden als"- Felder 
# (ausschließlich in der GUI gesperrt)
sc.exe ManagedAccount "SVCNAME" true

Fazit

Ich hoffe ich kann etwas dazu beitragen, dass einem von Euch der „Schrecken“ genommen werden konnte und dem einen oder anderen hiermit klar gezeigt werden kann, dass der Umgang mit Group Managed Service Accounts (gMSA) nicht sehr kompliziert ist! Frei nach dem Motto: Gewusst wie!

Probierts am besten einfach selbst aus und berichtet gerne, ob die Umsetzung von Erfolg „gekrönt“ gewesen ist… oder ob es hier und da noch Optimierungsbedarf an meinen Codezeilen zu geben scheint. 😉

---