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. 😉


3 thoughts on “Group Managed Service Accounts (gMSA)”

  1. Hi und vielen Dank für die anschauliche Darstellung. Eines ist mir nicht klar. Welche Berechtigungen hat nun so ein Account. Kann ich diesen Account ganz normal in AD Gruppen Mitglied werden lassen oder funktionieren nur lokale Gruppen?

    1. Hi Stefan,

      es kommt immer darauf an, was Du grundsätzlich erreichen willst. Jedoch, ist es auf dem herkömmlichen Weg möglich, die gMSA-Konten regulär in Gruppen aufzunehmen um z.B. Verzeichnis- oder administrative Berechtigungen zu realisieren. Ich nutze gMSA-Konten meist für die Windows-Aufgabenplanung und/oder innerhalb von den Windows-Gruppenrichtlinien. Auch sind moderne Lösungen in der Lage, sich gegenüber dem Active Directory mittels eines gMSA-Konto zu authentifizieren. Sprich, ein gMSA-Konto kann einen Benutzer mit einem statischen Kennwort ersetzen und so das regelmäßige, manuelle Ändern des Kennwortes in allen hinterlegten Systemen überflüssig machen!

      Grundsätzlich gesagt:
      Ein gMSA-Konto hat per Default keinerlei „mehr“ Berechtigungen wie ein neu erstelltes Benutzerkonto.
      Daher muss ein gMSA-Konto bei Bedarf mit zusätzlichen Berechtigungen ausgestattet werden, um ggf. Aufgaben auf einem Server lokal ausführen zu dürfen, Stichwort „User Account Control (UAC)“.

      1. Danke, also normale AD Gruppen möglich. Ich hatte mir das in „Active Directory Users and Computers“ angesehen – wenn man von einem gMSA Account die Properties öffnet erscheinen keine Gruppenmitgliedschaften. Aus der anderen Richtung AD-Gruppe Member hinzufügen kann man einen gMSA auswählen…

Schreibe einen Kommentar zu Stefan Holzwarth Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Time limit is exhausted. Please reload CAPTCHA.