Windows & Server

Group Managed Service Account (gMSA)

Allgemeine Infos

Ein Group Managed Service Account (gMSA) ist ein Kontotyp in Active Directory für Windows-Dienste, geplante Aufgaben und IIS-Anwendungspools. Windows erzeugt und wechselt das Kennwort selbst, kein Admin muss es kennen. Anders als beim älteren Standalone Managed Service Account (sMSA) aus Windows Server 2008 R2, das an einen einzelnen Server gebunden ist, können beim gMSA mehrere Server dasselbe Konto nutzen, etwa in einer Serverfarm hinter Network Load Balancing.

gMSAs gibt es seit Windows Server 2012, Microsoft Learn führt sie für Windows Server 2016 bis 2025. Der Microsoft Key Distribution Service (KDS) liefert die Schlüssel, aus denen der Domain Controller das Kennwort berechnet; berechtigte Server holen aktuelles und vorheriges Kennwort beim DC ab. Wer das darf, steht in PrincipalsAllowedToRetrieveManagedPassword, meist eine Gruppe mit den Computerkonten der Server.

Abgrenzung: Der Delegated Managed Service Account (dMSA, eigener Eintrag) aus Windows Server 2025 bindet das Geheimnis zusätzlich an bestimmte Computer und hält es nur auf dem DC vor; ein gMSA-Kennwort ist nicht maschinengebunden und kann gestohlen werden. Eine Migration von gMSA zu dMSA unterstützt Microsoft nicht. Der Glossareintrag Managed Service meint ausgelagerte IT-Dienstleistungen, nicht diesen Kontotyp.

Funktionsweise & Details

Einrichtung und Betrieb in fünf Schritten:

  1. Einen KDS-Root-Key anlegen (Add-KdsRootKey) und das Ereignis 4004 im KdsSvc-Log abwarten. Microsoft sieht rund zehn Stunden vor, damit der Schlüssel auf alle DCs repliziert ist; die Rückdatierung mit -EffectiveTime ((Get-Date).AddHours(-10)) ist nur für Testumgebungen mit einem einzigen DC gedacht.
  2. gMSA anlegen: New-ADServiceAccount -Name <Name> -DNSHostName <Name>.<Domäne> -PrincipalsAllowedToRetrieveManagedPassword <Gruppe>. Das Kennwortintervall ManagedPasswordIntervalInDays (Standard 30 Tage) lässt sich nur beim Anlegen festlegen.
  3. Auf jedem Server, der das Konto nutzt, Install-ADServiceAccount ausführen und mit Test-ADServiceAccount kontrollieren, ob der Server das Kennwort abrufen kann.
  4. Windows-Dienst, geplante Aufgabe oder IIS-Anwendungspool auf das gMSA umstellen.
  5. Der DC berechnet nach Ablauf des Intervalls ein neues Kennwort, die Mitgliedsserver holen es automatisch ab.

Voraussetzungen sind eine Domänen- und Gesamtstrukturfunktionsebene ab Windows Server 2012, eine 64-Bit-Umgebung für die PowerShell-Cmdlets sowie korrekt registrierte SPNs, DNS-Einträge und synchrone Uhren für Kerberos. Der Name muss in der gesamten Gesamtstruktur eindeutig sein. Die Verschlüsselung wählt der DC anhand von msDS-SupportedEncryptionTypes.

Vorteile & Nutzen

  • Keine Kennwörter mehr in Dokumentationen oder Skripten, weil Windows sie erzeugt und standardmäßig alle 30 Tage wechselt.
  • Ein Konto für mehrere Server: Farmen und lastverteilte Dienste authentifizieren sich mit demselben Prinzipal, das vereinfacht Kerberos-Konfiguration und SPN-Pflege.
  • Kerberoasting wird deutlich schwerer, weil das maschinell erzeugte Kennwort nicht erraten werden kann und regelmäßig wechselt.
  • Keine Zusatzsoftware und keine Lizenzkosten, da Bestandteil von AD DS.
  • Die Verwaltung lässt sich delegieren, ohne dass jemand das Kennwort sehen muss.

Praxisbeispiel

Ein Kunststoffverarbeiter mit 300 Mitarbeitenden betreibt eine Webanwendung auf drei IIS-Servern hinter einem Load Balancer, bisher unter einem Domänen-Benutzerkonto, dessen Kennwort seit Jahren nicht geändert wurde. Die IT legt eine Gruppe mit den drei Computerkonten an, erstellt ein gMSA mit dieser Gruppe als berechtigtem Prinzipal und installiert es auf allen Servern. Die Anwendungspools laufen anschließend unter dem gMSA, das alte Benutzerkonto wird deaktiviert. Seitdem wechselt das Kennwort automatisch alle 30 Tage, ohne dass ein Wartungsfenster nötig ist.

Worauf sollte man achten?

  • Konfiguriere AES ausdrücklich für das gMSA: Fehlt msDS-SupportedEncryptionTypes, geht der DC von schwächerer Verschlüsselung aus, und auf Hosts mit abgeschaltetem RC4 scheitert die Anmeldung.
  • Halte die Gruppe in PrincipalsAllowedToRetrieveManagedPassword klein, denn jeder Server darin kann das Kennwort abrufen und legt es bei einer Kompromittierung offen.
  • Failovercluster unterstützen gMSA nicht direkt, nur Dienste auf dem Cluster (Windows-Dienst, Anwendungspool, geplante Aufgabe) können es nutzen.
  • Lege den KDS-Root-Key nicht unnötig neu an; nach einer Neuerstellung kann der alte Schlüssel aus dem Cache weiterverwendet werden, dann hilft ein Neustart des KDC-Dienstes auf allen DCs.
  • In Domänen mit Windows Server 2025 lohnt für Benutzerkonten, unter denen Dienste laufen, der Umstieg auf dMSA, weil es das Geheimnis zusätzlich an Maschinen bindet.

Lizenz & Verfügbarkeit

gMSA ist Bestandteil von Active Directory Domain Services ab Windows Server 2012 und in Windows Server 2016 bis 2025 enthalten, eine eigene Lizenz gibt es nicht. Es gilt die normale Windows-Server-Lizenzierung pro Kern mit CALs. Stand: Oktober 2026.

Fazit

gMSA ist der bewährte Standard für Dienstkonten in AD-Domänen und sollte jedes von mehreren Servern geteilte Dienstkonto mit statischem Kennwort ersetzen. In Domänen mit Windows Server 2025 kommt dMSA als stärker gebundene Alternative für bestehende Dienstkonten hinzu.

Weiterführende Links

Verwandte Artikel