Group Managed Service Account
Von Active Directory automatisch verwalteter Service Account mit 120-Zeichen-Passwort und automatischer Rotation — macht Kerberoasting praktisch unmöglich.
Group Managed Service Accounts (gMSA) sind eine von Microsoft in Active Directory integrierte Kontotyp-Klasse, bei der das Passwort automatisch vom Domain Controller generiert und rotiert wird. Das Passwort ist 120 Zeichen lang, kryptografisch zufällig und wird standardmäßig alle 30 Tage gewechselt — ohne manuellen Eingriff und ohne dass ein Administrator das Passwort kennt. gMSAs sind die wirksamste Maßnahme gegen Kerberoasting, da ein Offline-Crack eines 120-Zeichen-Passworts praktisch ausgeschlossen ist.
Das Problem mit klassischen Service Accounts
In den meisten Active-Directory-Umgebungen laufen Dienste wie SQL Server, IIS, Backup-Agenten und Anwendungsserver unter regulären Benutzerkonten, denen ein Service Principal Name (SPN) zugewiesen wurde. Diese Konten haben typischerweise ein manuell gesetztes Passwort, das oft seit Jahren unverändert ist — teils aus Angst, dass eine Passwortänderung den Dienst unterbricht.
In der Praxis finden wir regelmäßig Service Accounts mit einfachen Passwörtern, Domain-Admin-Rechten und Passwörtern, die seit der Einrichtung des Dienstes nicht rotiert wurden. Jeder dieser Accounts ist ein potenzielles Ziel für Kerberoasting: Ein normaler Domänenbenutzer kann das Service Ticket anfordern und den Hash offline knacken. Bei einem schwachen Passwort dauert das Minuten.
Wie gMSA funktioniert
Das Passwort eines gMSA wird vom Key Distribution Service (KDS) auf dem Domain Controller berechnet. Die Berechnung basiert auf einem Root Key, dem Erstellungszeitpunkt des Kontos und dem aktuellen Zeitintervall. Nur die Computer, die in der PrincipalsAllowedToRetrieveManagedPassword-Eigenschaft des gMSA eingetragen sind, können das aktuelle Passwort vom Domain Controller abrufen.
Der Ablauf ist vollständig automatisiert: Der Computer, auf dem der Dienst läuft, ruft das Passwort vom DC ab und konfiguriert den Dienst damit — transparent, ohne Benutzerinteraktion. Bei der nächsten Rotation (alle 30 Tage) wiederholt sich der Vorgang. Es gibt kein Passwort, das ein Administrator verwalten, dokumentieren oder in einem Passwort-Manager ablegen müsste.
gMSA vs. klassische Service Accounts
| Merkmal | Klassischer Service Account | gMSA |
|---|---|---|
| Passwortlänge | Manuell gesetzt (oft 8-16 Zeichen) | 120 Zeichen, kryptografisch zufällig |
| Passwortrotation | Manuell (oft nie) | Automatisch alle 30 Tage |
| Kerberoasting-Risiko | Hoch (offline knackbar) | Praktisch null |
| Passwortverwaltung | Administrator muss Passwort kennen | Niemand kennt das Passwort |
| Mehrere Server | Gleiches Passwort manuell synchronisieren | Automatisch auf allen berechtigten Hosts |
| Voraussetzungen | Beliebiges AD-Konto | Windows Server 2012+ Domain Functional Level |
Voraussetzungen und Einrichtung
gMSAs erfordern mindestens den Domain Functional Level Windows Server 2012 und einen einmalig generierten KDS Root Key. Die Erstellung erfolgt über PowerShell: New-ADServiceAccount -Name "gMSA-SQLServer" -DNSHostName "gmsa-sql.domain.local" -PrincipalsAllowedToRetrieveManagedPassword "SQL-Server-Gruppe$". Anschließend wird der gMSA auf dem Zielserver installiert (Install-ADServiceAccount) und dem Dienst als Anmeldekonto zugewiesen.
Die Migration bestehender Service Accounts auf gMSA erfordert eine Inventarisierung aller SPNs, die Prüfung der Kompatibilität (die meisten Microsoft-Dienste und viele Drittanbieter unterstützen gMSA) und eine koordinierte Umstellung — idealerweise in einem Wartungsfenster, da der Dienst kurzzeitig neu gestartet werden muss.
Einschränkungen
Nicht alle Anwendungen unterstützen gMSA. Insbesondere ältere Software, die das Passwort explizit in einer Konfigurationsdatei erwartet, kann keinen gMSA verwenden. Geplante Aufgaben (Scheduled Tasks) unterstützen gMSA ab Windows Server 2012. Dienste, die auf mehreren Servern mit unterschiedlichen Identitäten laufen müssen, erfordern zusätzliche Konfiguration. Für diese Fälle bleibt ein klassischer Service Account mit langem, zufällig generiertem Passwort und regelmäßiger Rotation über eine PAM-Lösung die Alternative.
Ein weiterer Punkt: Obwohl das gMSA-Passwort kryptografisch stark ist, wird es an alle berechtigten Computer verteilt und kann dort prinzipiell ausgelesen werden. In Windows-Server-2025-Umgebungen bieten Delegated Managed Service Accounts (dMSA) einen noch stärkeren Schutz — deren Credentials sind maschinengebunden und existieren nur auf dem Domain Controller, wodurch eine Extraktion vollständig unterbunden wird.
Relevanz für KMUs
Die Migration auf gMSA ist eine der wirkungsvollsten Einzelmaßnahmen zur Absicherung einer Active-Directory-Umgebung — und gleichzeitig kostenfrei, da gMSA in jeder Windows-Server-Lizenz enthalten ist. Der erste Schritt ist eine Inventarisierung aller Service Accounts mit SPNs (per PowerShell: Get-ADUser -Filter {ServicePrincipalName -ne "$null"}). Erfahrungsgemäß lassen sich in den meisten Umgebungen die kritischsten Service Accounts innerhalb weniger Tage auf gMSA umstellen, was den häufigsten Kerberoasting-Angriffsvektor sofort eliminiert.