Sichern Ihrer gruppenverwalteten Dienstkonten

Übersicht über Gruppenverwaltete Dienstkonten

Die traditionelle Praxis, reguläre Benutzerkonten als Dienstkonten zu verwenden, legt die Last des Passwortmanagements auf die Benutzer. Infolgedessen bleiben die Passwörter der Konten oft jahrelang gleich — was sie sehr anfällig für Brute-Force-Angriffe und Missbrauch macht. Gruppenverwaltete Dienstkonten (gMSAs) bieten eine sicherere Möglichkeit, automatisierte Aufgaben, Dienste und Anwendungen auszuführen.

gMSA wurden in Windows Server 2016 eingeführt und können auf Windows Server 2012 und höher genutzt werden. gMSA-Passwörter werden vollständig von Windows verwaltet: Sie werden zufällig generiert und automatisch geändert. Darüber hinaus müssen die Passwörter von keinem Benutzer bekannt sein, da die Dienstkonten selbst auf dem Server 'installiert' werden, der zur Abfrage der Passwortinformationen von Active Directory zur Laufzeit dient. Als Ergebnis sind gMSAs weit weniger anfällig für Missbrauch und Kompromittierung als Benutzerkonten, die als Dienstkonten verwendet werden.

Sicherheit von Group Managed Service Accounts

gMSAs sind ein spezifischer Objekttyp in Active Directory: msDS-GroupManagedServiceAccount. Diese Objekte haben spezielle Attribute, die mit ihnen in Verbindung stehen, bezüglich ihres Passworts und dessen Rotation. Ähnlich wie bei LAPS, möchten Sie sicherstellen, dass der Zugriff auf gMSA-Attribute nur auf die Active Directory-Objekte beschränkt ist, die sie benötigen.

gMSA-Attribute und Berechtigungen

gMSAs haben die folgenden Attribute:

• msDS-ManagedPassword— Ein BLOB mit dem Passwort des gMSA
• msDS-ManagedPasswordID— Die Schlüssel-ID, die verwendet wurde, um das aktuelle gMSA-Passwort zu generieren
• msDS-ManagedPasswordPreviousID— Die Schlüssel-ID, die zur Generierung des vorherigen gMSA-Passworts verwendet wurde
• msDS-GroupMSAMembership— Eine Liste der Objekte, die Berechtigung haben, das Passwort für das gMSA abzufragen
• msDS-ManagedPasswordInterval— Das Intervall (Tage), in dem das Passwort geändert wird

Da die Passwortinformationen im msDS-ManagedPassword-Attribut gespeichert sind, werden Sie definitiv wissen wollen, wer in Ihrer Umgebung in der Lage ist, das Passwort abzufragen. Diese Information wird im msDS-GroupMSAMembership-Attribut festgelegt.

Allerdings ist es etwas komplizierter als nur dieses Attribut, da auch die Berechtigungen des Active Directory eine Rolle spielen. Wenn aus irgendeinem Grund ein Benutzer oder Objekt konfiguriert ist, um das Passwort über das msDS-GroupMSAMembership-Konto abzufragen, benötigen sie immer noch 'Lesen'-Berechtigungen für das msDS-ManagedPassword-Attribut des gMSA.

Das bedeutet, es gibt zwei Wege, um gMSA-Passwörter zu sichern:

• Stellen Sie sicher, dass nur die notwendigen Objekte die Berechtigung haben, das Passwort abzufragen und dass sie in der msDS-GroupMSAMembership existieren
• Stellen Sie sicher, dass nur administrative Benutzer, die Zugriff benötigen, und Computerkonten, auf denen gMSAs installiert sind, die Berechtigung zum Lesen des Attributs haben. Außerdem stellen Sie sicher, dass nur Administratoren die Fähigkeit haben, das gMSA und seine Attribute zu ändern, sodass niemand sich selbst zum msDS-GroupMSAMembership-Attribut hinzufügen kann.

Idealerweise würden Sie gMSAs über beide Wege absichern, um einem Angreifer die Möglichkeit zu nehmen, eine der oben genannten Szenarien auszunutzen. Im Folgenden zeigen wir, wie schlecht verwaltete Berechtigungen oder Konfigurationen eines gMSA zu einem Kompromiss des Kontos und Privilege Escalation oder lateraler Bewegung führen können.

Missbrauch des gMSA-Passworts

Das Missbrauchen eines gMSA ist konzeptionell relativ einfach. Zuerst, beschaffe sein Passwort mit einem Tool wie Mimikatz oder durch direktes Abfragen aufgrund unsicherer Konfigurationen in Active Directory. Da gMSAs Dienstkonten sind, sind sie normalerweise ziemlich privilegiert, sodass man dann normalerweise in der Lage ist, sich seitwärts zu bewegen oder zu eskalieren.

Lassen Sie uns ein Beispiel-Szenario durchgehen.

1. Zuerst kompromittieren wir das gewöhnliche Windows-Benutzerkonto ‘notadmin’ durch eine Technik wie Phishing. Dieses Konto hat minimale Privilegien in Active Directory, ist aber ein lokaler Administrator auf dem Computer, auf den wir gelandet sind.

2. Als Nächstes werden wir versuchen herauszufinden, ob gMSA existieren. Das ist sehr einfach zu bewerkstelligen, wenn Sie Zugriff auf das Windows PowerShell-Cmdlet haben. Ein einfaches Skript auszuführen, verschafft uns alle verwalteten Dienstkonten in Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Mit einigen kleinen Änderungen am Skript können wir identifizieren, wer Zugriff hat, um die gMSA-Passwörter abzufragen:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Wie wir sehen können, ist nur das Kevin Joyce-Konto in der Lage, die Passwörter für diese Dienstkonten abzufragen:

4. Wir können den Umfang der Ziele, die wir anstreben, eingrenzen, indem wir überprüfen, ob diese Dienstkonten Mitglied einer der privilegierten Gruppen sind, und von dort aus können wir tiefer in die festgelegten Berechtigungen eines der Objekte eindringen:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Wenn wir uns die Ergebnisse hier ansehen, können wir feststellen, dass das gMSA-Dienstkonto Mitglied der Domain Admins ist, also wird dies dasjenige sein, das wir zu nutzen versuchen werden.

5. Indem wir ein Skript, das in einem Beitrag über Microsoft LAPS modifiziert haben, konnten wir eine Auflistung aller Objekte erhalten, die Berechtigungen über ein verwaltetes Dienstkonto haben, einschließlich Vollzugriff, Alle Eigenschaften schreiben oder Eigenschaft schreiben für das spezifische gMSA-Attribut. Die Ausgabe finden Sie unten, und das Skript ist am Ende verlinkt.

6. Wie Sie sehen können, hat das notadmin-Konto Vollzugriff auf das gMSA-Konto. Dies ermöglicht es uns, das msDS-GroupMSAMembership-Attribut zu ändern, was uns wiederum erlaubt, das Passwort für das verwaltete Dienstkonto abzurufen:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Jetzt, da wir das Passwort tatsächlich abfragen können, schauen wir mal, was wir damit anfangen können:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. Der im Attribut gespeicherte Wert ist ein BLOB, der die Daten für das Passwort enthält, nicht das Passwort selbst, daher müssen wir das Passwort mit einem Tool wie DSInternals dekodieren:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Dies verschafft uns das SecureCurrentPassword und CurrentPassword. Das CurrentPassword scheint auf den ersten Blick nutzlos zu sein, aber das liegt daran, dass alle Zeichen UTF-16 sind. Das SecureCurrentPassword kann in einen NTLM-Hash umgewandelt und verwendet werden in einem Pass-the-Hash-Angriff mit Mimikatz, um unsere Privilegien zu erhöhen.

9. Um das pass the hash-Verfahren durchzuführen, müssen wir einfach mimikatz ausführen und diesen Befehl verwenden:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Jetzt, da wir eine Shell haben, die als gMSA-Dienstkonto ausgeführt wird, welches Mitglied der Domain Admins war, können wir tun, was wir wollen, um Active Directory zu kompromittieren. Eine der schnellsten, aber wahrscheinlich lautesten Methoden, die wir dafür verwenden können, ist die Ausführung eines DCSync attack und das Stehlen des Hashes des krbtgt-Kontos:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

gMSA-Schutz & Überwachung

Es gibt Strategien, die Sie nutzen können, um Missbrauch von gMSA zu verhindern und zu erkennen.

Berechtigungen

Der offensichtlichste und wohl wichtigste Schutz, den Sie einrichten können, ist sicherzustellen, dass angemessene Berechtigungen für Ihre gruppenverwalteten Dienstkonten festgelegt sind. Zu verstehen, wer Schreibzugriff auf diese Objekte hat, ist entscheidend für deren Schutz; jemand, der sich selbst zu dem Attribut hinzufügen kann, das steuert, wer das Passwort abfragen kann, hat theoretisch bereits Zugang, dieses Konto zu übernehmen und seine Privilegien zu missbrauchen.

Das Nächste wäre zu verstehen, wer die Fähigkeit hat, die Passwörter dieser Konten abzufragen und wer genau solchen Zugriff benötigt. In Wirklichkeit sollte das einzige Konto, das das Passwort eines gMSA erhalten kann, das Computerkonto sein, auf dem das gMSA installiert ist.

Ereignisprotokolle

Es gibt ein Ereignis, das Sie in den nativen Ereignisprotokollen suchen können, das Ihnen hilft zu identifizieren, wer die Passwörter von gMSA-Konten abfragt. Wenn Sie die Richtlinie ‘Audit directory service access’ für Ihre Domäne aktivieren und eine SACL für die gMSAs konfigurieren, die Sie überwachen möchten, können Sie Ereignisprotokolle generieren, wenn Personen das Attribut msDS-ManagedPassword abfragen:

Wenn Sie diese Einstellung aktivieren und eine neue SACL erstellen, wird ein Ereignisprotokoll mit der Ereignis-ID 4662 generiert; es sieht so aus:

Wie Sie sehen können, wurde protokolliert, dass das 'notadmin'-Konto eine Eigenschaft auf dem gMSA-Konto gelesen hat. Die gelesenen Eigenschaften sind die in das Schema für Active Directory gespeicherten GUIDs, aber mit ADSI Edit können wir sehen, dass die hervorgehobene GUID dem msDS-ManagedPassword-Attribut entspricht.

Angenommen, Sie haben eine Art von Ereignisprotokoll-Weiterleitung oder eine SIEM-Lösung, wären diese Protokolle äußerst wertvoll, um festzustellen, wer auf diese Attribute zugreift.

Netwrix StealthDEFEND

Eine weitere Option ist ein Tool wie Netwrix StealthDEFEND. Netwrix StealthDEFEND verlässt sich nicht auf native Ereignisprotokolle und kann den Zugriff auf gMSA-Passwörter und die Zuweisung von Hochrisikoberechtigungen direkt nach der Installation erkennen. Zum Beispiel würde das oben gezeigte Szenario folgende Bedrohung generieren, wenn das Konto 'notadmin' das Passwort abfragt:

Darüber hinaus können Sie mit Netwrix StealthDEFEND einfach ein Playbook erstellen, das ausgeführt wird, wenn Missbrauch von gMSA erkannt wird. Das Playbook kann mehrere Schritte umfassen, wie zum Beispiel die Anforderung, dass das Täter-Benutzerkonto auf eine MFA-Anfrage reagiert, das Konto deaktiviert oder ein ServiceNow-Vorfall erstellt wird.

Anhang

gMSA-Berechtigungscodes:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

Ansicht RohdatengMSA_Permissions_Collection.ps1 gehostet von GitHub

FAQ

Was ist ein gMSA?

Ähnlich wie verwaltete Dienstkonten (MSA) sind gruppenverwaltete Dienstkonten (gMSAs) verwaltete Domänenkonten, die dazu dienen, Dienste und Zugriffsmanagement sicherer zu gestalten. Die gMSA-Funktionalität bietet automatisches Passwortmanagement durch den Domänencontroller (DC), vereinfachtes Management des Dienstprinzipalnamens (SPN) und die Möglichkeit, das Management an andere Administratoren zu delegieren, was die Active Directory security verbessert und die Anzahl der Konten mit privilegiertem Zugriff minimiert.

Was ist der Unterschied zwischen MSAs und gMSAs?

Im Gegensatz zu einem MSA kann ein gMSA mit mehreren Computern verknüpft werden.

Wie findet man ein Gruppenverwaltetes Dienstkonto?

Um eine Liste der gMSAs auf Ihrem Domain-Controller zu erhalten, öffnen Sie den Server-Manager > Tools > Active Directory Users and Computers > Verwaltete Dienstkonten.

Kann ein gMSA ein Domain-Admin sein?

Ja, ein gMSA-Konto kann Mitglied von Domain Admins sein, obwohl diese Praxis für die Informationssicherheit gefährlich sein kann.

Wie kann ich ein gMSA erstellen?

Gruppenverwaltete Dienstkonten werden mit dem Cmdlet New-ADServiceAccount erstellt.

Die Objektberechtigungen eines gMSA entscheiden, ob diese Automatisierung sicher bleibt. Wenn ein normales Konto Schreibzugriff auf das Attribut hat, das die Kennwortabrufsteuerung regelt, kann es sich selbst die Berechtigung erteilen, die Anmeldeinformationen zu lesen und dann mit den bestehenden Rechten der Dienstidentität zu handeln, einschließlich aller privilegierten Gruppenmitgliedschaften, die das Konto besitzt.

Diese eine Berechtigung ist oft das Einzige, was eine gehärtete Bereitstellung von einer kompromittierten Domäne trennt.

Servicekonten sind nicht-menschliche Identitäten, und 76 % der Organisationen verwalten oder überwachen sie nicht vollständig, laut dem Netwrix 2026 Data and Identity Security Report. Ein gruppenverwaltetes Servicekonto entfernt das Passwort aus menschlichen Händen, aber jeder, der umschreiben kann, welche Hauptprinzipale es abrufen können, kann die Identität trotzdem übernehmen.

Was ist ein gruppenverwaltetes Dienstkonto (gMSA)?

Wie ein gMSA funktioniert

Das Passwort eines gMSA durchläuft auf jedem Host, der es verwendet, dieselbe Sequenz.

1. Der Key Distribution Service (KDS) auf jedem Domänencontroller hält das Geheimnis, das zur Berechnung der Passwörter für jede gMSA in der Domäne verwendet wird.

Ein gruppenverwaltetes Dienstkonto ist ein verwaltetes Konto in der Active Directory domain, das zum Ausführen von Diensten, Anwendungen und geplanten Aufgaben verwendet wird. Windows generiert ein zufälliges Passwort und rotiert es automatisch, und autorisierte Hosts rufen die Anmeldeinformationen zur Laufzeit aus Active Directory ab, sodass Administratoren das Passwort nie kennen oder in Dateien speichern müssen.

1. Der Host ruft auch das vorherige Passwort ab und hält die Authentifizierung während des kurzen Zeitfensters aufrecht, in dem die Rotation propagiert wird.

gMSAs gelten nicht für Windows-Betriebssysteme vor Windows Server 2012, daher benötigt jeder Host, der einen verwendet, Windows Server 2012 oder neuer. Ein gMSA unterstützt eine Dienstidentität auf mehreren Computern, während ein eigenständiges verwaltetes Dienstkonto nur einen Computer unterstützt, und ein reguläres Benutzerkonto überlässt die Passwortverwaltung den Administratoren.

1. Da jeder autorisierte Host sich als derselbe Domänen-Principal authentifiziert, vereinfacht ein gMSA auch die Verwaltung von Service Principal Names (SPN) für Dienste, die eine Identität über Hosts hinweg teilen.
2. Windows ändert das Passwort automatisch, standardmäßig alle 30 Tage, ohne dass ein Host eine Vorankündigung oder manuelle Eingriffe benötigt.
3. Ein autorisierter Host kontaktiert einen Domänencontroller und ruft das aktuelle Passwort zur Laufzeit ab, das aus diesem Geheimnis berechnet wird, anstatt es lokal zu speichern.

gMSA vs andere Dienstkontotypen

Diese Attribute zusammen sagen einem Host, wie er das Passwort abrufen kann, und msDS-GroupMSAMembershipExpand ist das, was ein Angreifer neu schreiben muss, die Fehlkonfiguration, die im weiteren Verlauf ausgenutzt wird.

Active Directory stellt ein gMSA mit der Objektklasse msDS-GroupManagedServiceAccountExpand, und diese Schemaattribute speichern das Passwort und die Abrufkontrollen.

Windows bietet mehrere Principals zum Ausführen von Diensten an, wobei jeder unterschiedliche Dienste unterstützt und sein Passwort unterschiedlich verwaltet. Wählen Sie den Kontotyp entsprechend den Authentifizierungsanforderungen und dem Bereitstellungsmodell der Anwendung.

Im Gegensatz zu einem sMSA kann ein gMSA auf mehreren Computern gemeinsam genutzt werden, was es für Serverfarmen und Lastenausgleichsdienste geeignet macht. Beide sind verwaltete Dienstkonten, die Windows und Active Directory die Verwaltung von Passwörtern ermöglichen.

Warum gMSAs wichtig sind

Microsoft stellt fest, dass gMSA-Passwörter maschinell generiert und automatisch rotiert werden, aber nicht an die Maschine gebunden sind, sodass sie weiterhin von einem kompromittierten Host gelesen werden können, und eine gMSA nicht direkt auf eine dMSA migriert werden kann.

Windows Server 2025 fügt das delegated managed service account (dMSA), das ein traditionelles Dienstkonto in ein Maschinenkonto mit verwalteten, zufälligen Schlüsseln migriert und die Authentifizierung an die Geräteidentität bindet.

Starke Passwörter, die niemand verwalten muss

Die Verwendung eines regulären Benutzerkontos als Dienstkonto überlässt die Passworterstellung, -verteilung und -rotation den Administratoren, und das Passwort bleibt unverändert, bis jemand es ändert. Ein gMSA ersetzt diesen manuellen Lebenszyklus durch eine domänenverwaltete Erstellung und Abruf.

Das Passwort muss weiterhin jeden Host erreichen, daher werden Host-Autorisierung und Host-Sicherheit Teil des Schutzes der Anmeldeinformationen.

Eine Identität über einen Serverfarm hinweg

Authentifizierungsprotokolle, die gegenseitige Authentifizierung unterstützen, wie Kerberos, erfordern, dass jede Instanz eines farmgehosteten Dienstes denselben Principal verwendet. Ein gMSA stellt allen Mitglieds-Hosts einen Domänenprincipal bereit, und Administratoren verwalten dessen Berechtigungen zentral, ohne ein Passwort zwischen den Hosts zu synchronisieren.

Weniger Anfälligkeit für Brute-Force-Angriffe und Missbrauch

Ein gMSA verwendet ein zufällig generiertes 240-Byte-Passwort, das Windows alle 30 Tage ändert, wodurch das Risiko einer Kompromittierung durch Brute-Force- oder Wörterbuchangriffe. Administratoren konfigurieren das Konto und die autorisierten Hosts und verwalten das Passwort nie, sodass Dienste starke Anmeldeinformationen erhalten, ohne dass jemand sie in Skripte, Bereitstellungsnotizen oder Konfigurationsdateien kopiert.

Windows-Dienste, IIS-Anwendungspools und geplante Aufgaben können als gMSA ausgeführt werden, und Microsofts Kerberoasting-Anleitung nennt auch SQL Server. Die Anwendungsunterstützung bleibt eine Bereitstellungsanforderung, daher testen Sie jeden Dienst unter dem gMSA, bevor er in Produktion geht.

Eine sicherere Standardeinstellung gegen Kerberoasting

Die automatische Generierung nimmt die Passwortauswahl aus menschlicher Hand, und die automatische Rotation beseitigt die wiederkehrende Aufgabe, statische Anmeldeinformationen auf jedem Diensthost zu aktualisieren. Microsoft empfiehlt gMSAs für lokale Dienste, sofern ein Dienst sie nicht verwenden kann.

Die verbleibende Verantwortung liegt bei der Zugriffsverwaltung, denn jemand, der die Berechtigung zur Passwortwiederherstellung ändern kann, kann die Anmeldeinformationen erhalten, ohne jemals an der Passworterstellung beteiligt gewesen zu sein.

Kerberoasting ermöglicht einem Angreifer mit jedem Domänenkonto, Service-Tickets anzufordern und das Passwort eines Servicekontos offline zu knacken, sodass die Passwortstärke bestimmt, ob der Angriff funktioniert.

Microsofts Kerberoasting-Anleitung benennt Konten mit schwachen Passwörtern als die verwundbarsten und empfiehlt, wo immer möglich gMSAs oder dMSAs zu verwenden, da ein generiertes Passwort die menschlich gewählte Schwäche beseitigt, auf die die Technik angewiesen ist.

So richten Sie ein gMSA sicher ein

Netwrix Threat Manager erkennt Diebstahl von Anmeldeinformationen, laterale Bewegungen und Privilegienerweiterungen in hybriden Umgebungen. Fordern Sie eine Demo an.

1. Überprüfen Sie die Anforderungen

Bestätigen Sie die Anforderungen an Domain, Host, Verwaltung und Anwendung, bevor Sie das gMSA bereitstellen.

Erstellen Sie das Konto mit einer expliziten Liste autorisierter Hosts, installieren und validieren Sie es dann auf jedem Host.

• Domänen- und Gesamtstrukturfunktionsebenen auf Windows Server 2012 oder höher gesetzt, die Microsoft als unterstützend für gMSA-Funktionen auf allen Geräten angibt.
• Hosts, die Windows Server 2012 oder neuer ausführen.
• Das Active Directory PowerShell-Modul auf dem Verwaltungssystem, das eine 64-Bit-Architektur benötigt, um die gMSA-Cmdlets auszuführen.
• Ein KDS-Stammschlüssel, der den Domänencontrollern zur Verfügung steht.
• Mitgliedschaft in Domain Admins oder Enterprise Admins oder delegierte Berechtigung zum Erstellen von msDS-GroupManagedServiceAccountExpand Objekten.
• Ein Dienst, der gMSAs unterstützt, wie ein Windows-Dienst, ein IIS-Anwendungspool oder eine geplante Aufgabe.

Delegieren Sie die Erstellung von gMSA an eine dedizierte Verwaltungsgruppe und halten Sie die Dienstidentität selbst aus den Verwaltungsgruppen heraus.

2. Erstellen Sie den KDS-Stammschlüssel

3. Erstellen Sie das gMSA mit New-ADServiceAccount

Failover-Cluster unterstützen keine gMSAs, aber Dienste, die auf dem Cluster-Dienst laufen, können eine verwenden, wenn sie ein Windows-Dienst, ein Anwendungspool oder eine geplante Aufgabe sind oder gMSAs nativ unterstützen. Kerberos muss ebenfalls durchgängig funktionieren, daher registrieren Sie die SPNs für jeden Dienst, halten DNS-Einträge und Uhren genau und erlauben Kerberos-Verkehr zwischen den beteiligten Systemen.

Trotz des Parameternamens überspringt -EffectiveImmediatelyExpand nicht die Replikation. Andere Domänencontroller können den Schlüssel erst verwenden, wenn er repliziert wurde, und Microsofts Schlüssel-Erstellungsverfahren lässt Domänencontroller bis zu 10 Stunden warten, bevor sie die Erstellung eines gMSA erlauben. Berücksichtigen Sie dieses Zeitfenster in der Produktion.

4. Installieren und testen Sie das gMSA auf jedem Host

Erstellen Sie eine dedizierte Sicherheitsgruppe für die Host-Computer-Konten des Dienstes und erstellen Sie dann das gMSA mit New-ADServiceAccountExpand, wobei Sie dessen DNS-Hostnamen und die Sicherheitsgruppe in PrincipalsAllowedToRetrieveManagedPasswordExpand. Microsoft verlangt, dass gMSA-Namen im gesamten Forest eindeutig sind, nicht nur in der Domäne.

Prüfen Sie, ob der Forest bereits einen KDS-Stamm­schlüssel besitzt, bevor Sie einen erstellen, da der Schlüssel eine einmalige Voraussetzung auf Forest-Ebene ist. Erstellen Sie ihn auf einem Windows Server 2012 oder neueren Domänencontroller mit Add-KdsRootKey -EffectiveImmediatelyExpand, und bestätigen Sie dann die Ereignis-ID 4004Expand im KDS-Ereignisprotokoll.

5. Konfigurieren Sie den Dienst so, dass er als gMSA ausgeführt wird

Legen Sie bei Bedarf während der Erstellung ein benutzerdefiniertes Passwortintervall mit -ManagedPasswordIntervalInDaysExpand fest, da das Intervall nur bei der Erstellung eingestellt werden kann. Erfassen Sie den Anwendungsbesitzer des Kontos und die vorgesehenen Hosts zusammen mit der Bereitstellungskonfiguration und schließen Sie allgemeine Serververwaltungsgruppen sowie Gruppen mit normalen Benutzern vom Abrufparameter aus, wie in "Limit who can retrieve the password" erläutert.

Testen Sie jeden Mitgliedsserver einzeln, da ein erfolgreicher Test auf einem Server nichts über die Gruppenmitgliedschaft oder Konnektivität eines anderen Servers aussagt. Beheben Sie fehlgeschlagene Validierungen, bevor Sie die Anmeldeidentität eines Produktionsdienstes ändern.

Legen Sie die Anmeldeidentität des Dienstes über den Service Control Manager, die IIS-Anwendungspool-Identitätseinstellungen oder die geplante Aufgaben-Konfiguration fest und lassen Sie das Passwort leer. Windows ruft die verwalteten Anmeldeinformationen ab.

Wie Angreifer ein gMSA-Passwort missbrauchen

Gewähren Sie dem Konto die erforderlichen Anwendungsberechtigungen und bestätigen Sie dann sowohl den Dienststart als auch den Zugriff auf abhängige Ressourcen. Ein bestandener Kontotest beweist nur die Bereitstellung der Anmeldeinformationen, daher benötigt die Arbeitslast weiterhin eigene Berechtigungen für Dateien, Datenbanken und andere Ressourcen.

Fügen Sie das Computerkonto jedes Hosts zur Sicherheitsgruppe hinzu, und führen Sie dann Install-ADServiceAccountExpand gefolgt von Test-ADServiceAccountExpand auf jedem autorisierten Host aus. Test-ADServiceAccountExpand überprüft, ob der Host das Passwort abrufen kann.

Das folgende Labor verwendet ein normales Konto namens notadminExpand und ein falsch konfiguriertes privilegiertes gMSA. Die Domain- und Kontonamen gehören zu dieser Beispielumgebung.

Finden Sie die gMSAs und wer sie lesen kann

Ein Angreifer kann ein gMSA-Passwort über einen autorisierten Pfad oder unsichere Active Directory-Berechtigungen abrufen und sich dann mit den bestehenden Rechten als das Konto authentifizieren.gMSA-Ausnutzung umfasst die breitere Angriffsklasse, einschließlich Golden gMSA-Angriffe, die einen anderen Weg zu verwalteten Anmeldeinformationen nehmen.

1. Mit dem verfügbaren Active Directory PowerShell-Modul listet der Angreifer die verwalteten Dienstkonten mit Get-ADServiceAccount -Filter *Expand.

Finden Sie ein privilegiertes gMSA und einen Zugang

1. Die Abfrage der Eigenschaft PrincipalsAllowedToRetrieveManagedPasswordExpand zeigt, welche Principals das Passwort jedes Kontos lesen können.

In den Laborergebnissen kann nur ein Administratorkonto die Passwörter abfragen, daher notadminExpand kann sie noch nicht lesen. Diese Konfiguration ist wichtig, sobald der Angreifer prüft, wer das gMSA-Objekt ändern kann.

1. Der Angreifer prüft, ob ein Dienstkonto zu privilegierten Gruppen gehört, indem er die Eigenschaft memberOfExpand abfragt.

Das gMSA des Labors gehört zu Domain Admins, daher wählt der Angreifer es aus. Die bestehende Mitgliedschaft bietet die für die nächsten Schritte benötigten Privilegien.

Passwort abrufen und entschlüsseln

1. Die Überprüfung von Objektberechtigungen identifiziert Hauptprinzipale mit Vollzugriff, Alle Eigenschaften schreiben oder Eigenschaft schreiben auf das Passwort-Wiederherstellungsautorisierungsattribut, mithilfe eines Skripts, das von einem in einem Beitrag zu Microsoft LAPS beschriebenen Ansatz angepasst wurde. Das Berechtigungsskript in „Find and audit every gMSA“ unten führt dieselbe Prüfung durch.
2. Im Labor hat notadminExpand Vollzugriff auf das gMSA-Objekt, was ihm erlaubt, Set-ADServiceAccountExpand zu verwenden, um sich selbst zu PrincipalsAllowedToRetrieveManagedPasswordExpand hinzuzufügen.

Verwenden Sie das Passwort zum Eskalieren

1. Das Attribut enthält einen BLOB mit den Passwortdaten statt des Passworts selbst, daher dekodiert der Angreifer es mit DSInternals, was die aktuellen und vorherigen Passwortwerte offenlegt und das aktuelle Passwort in einen NT-Hash umwandeln kann.
2. Der Angreifer kompromittiert notadminExpand durch eine Technik wie Phishing. Das Konto hat minimale Active Directory-Berechtigungen, besitzt jedoch local administrator rights auf dem kompromittierten Rechner.
3. Nach der Änderung kann notadminExpand das Attribut msDS-ManagedPasswordExpand abfragen und das zurückgegebene Objekt speichern.

So sichern Sie Ihre gMSAs

Eine einzelne zu weit gefasste Berechtigung, Full Control auf ein gMSA-Objekt, ermöglichte den Übergang des Angriffs von einem gewöhnlich kompromittierten Konto zur domänenweiten Anmeldeinformationsfälschung.

Golden-gMSA-Angriffe erreichen das Passwort eines gMSA auf einem anderen Weg und werden auf der Seite gMSA-Ausnutzung behandelt.

Sichern Sie die Abrufberechtigung, Objektberechtigungen und Dienstprivilegien eines gMSA gemeinsam.

1. Mit den wiederhergestellten Anmeldedaten authentifiziert sich der Angreifer als gMSA über pass-the-hash und startet einen Prozess unter der Dienstidentität, wobei er alle Rechte übernimmt, die diese Identität besitzt.

Begrenzen, wer das Passwort abrufen kann

Einschränken, wer das gMSA ändern kann

1. Da das gMSA des Labors zu Domain Admins gehört, kann der Angreifer dessen Replikationsrechte nutzen, um einen DCSync-Angriff gegen das Konto krbtgtExpand durchzuführen. Die Anmeldeinformationen dieses Kontos signieren jedes Kerberos-Ticket in der Domäne, sodass der Angreifer durch deren Wiederherstellung Tickets für jeden Benutzer fälschen kann.

Halten Sie gMSAs aus privilegierten Gruppen heraus

Nur die Computeraccounts, die den Dienst ausführen, sollten normalerweise dessen gMSA-Passwort abrufen. Für eine Multi-Server-Bereitstellung verwenden Sie eine dedizierte Sicherheitsgruppe, die diese Computeraccounts enthält, und konfigurieren Sie sie über PrincipalsAllowedToRetrieveManagedPasswordExpand, und überprüfen Sie deren Mitgliedschaft, wann immer sich die Hostliste des Dienstes ändert.

Gewähren Sie Schreibzugriff nur Administratoren, die das Konto verwalten müssen, und überprüfen Sie die Berechtigungen Vollzugriff, Alle Eigenschaften schreiben und attributspezifische Schreibberechtigungen für jede gMSA. Ein Principal mit der Berechtigung zur Änderung von msDS-GroupMSAMembershipExpand kann die eigene Kennwortabfrage autorisieren, was genau die Fehlkonfiguration ist, die das obige Vorgehen ausnutzt.

Gewähren Sie jedem gMSA nur die Rechte, die sein Dienst benötigt. Ein gMSA kann zu Domain Admins gehören, aber diese Mitgliedschaft gewährt jedem, der seine Anmeldeinformationen erhält, domänenweite Administratorrechte. Microsoft empfiehlt in seinen Maßnahmen, die Berechtigungen von Dienstkonten zu überprüfen und übermäßigen Zugriff zu entfernen.

AES-Verschlüsselung durchsetzen

Schützen Sie das Konto über beide Berechtigungspfade. Beschränken Sie, welche Principals das Attribut msDS-GroupMSAMembershipExpand repräsentiert, und beschränken Sie den Verzeichniszugriff auf das gMSA-Objekt selbst, insbesondere die Berechtigung, das Konto zu ändern oder dessen Abrufberechtigung.

Überprüfen Sie die direkte Gruppenmitgliedschaft und die effektiven Berechtigungen, die verschachtelte Gruppen gewähren, und dokumentieren Sie den erforderlichen Zugriff der Anwendung, bevor Sie Berechtigungen entfernen, damit der Serviceinhaber die überarbeitete Konfiguration validieren kann.

Domänencontroller mit Windows Server 2025 geben keine RC4-Ticket-Granting-Tickets mehr aus, sodass ein Legacy-Gerät, das auf RC4 angewiesen ist, sich nicht authentifizieren kann.

Finden und prüfen Sie jede gMSA

Microsoft stellt standardmäßig die RC4 Kerberos-Verschlüsselung ein, statt sie nur abzuraten. Ein Update von 2022 hat den Standardverschlüsselungstyp bereits auf Advanced Encryption Standard (AES)-SHA1 für alle Konten ohne explizit konfigurierten Verschlüsselungstyp geändert.

Überprüfen Sie das Attribut msDS-SupportedEncryptionTypesExpand jedes gMSA und stellen Sie sicher, dass AES enthalten ist, anstatt sich auf den Fallback-Standard der Domäne zu verlassen, da genau dieser Fallback von Microsoft entfernt wird.

Setzen Sie das Passwort des Kontos nach der Aktivierung der AES-Unterstützung zurück, um neue Schlüssel zu generieren, und testen Sie anschließend die Authentifizierung, da ein gMSA, das nur auf RC4 verbleibt, die Kerberos-Authentifizierung vollständig verlieren kann, anstatt nur mit einem schwächeren Verschlüsselungsverfahren zu arbeiten.

Überwachung von Passwort-Lesevorgängen

Originalskript: gMSA_Permissions_Collection.ps1.

Das resultierende Ereignis identifiziert das Subjektkonto, das Zielverzeichnisobjekt und die zugegriffenen Eigenschaften.

Das untenstehende Berechtigungsskript meldet, welche Konten Vollzugriff oder Schreibzugriff auf die Eigenschaft msDS-GroupMSAMembershipExpand eines gMSA haben, die Überprüfung, die Schritt 5 der obigen Anleitung von der Angreiferseite aus durchführt. Administratoren müssen dennoch Vererbung, Gruppenmitgliedschaft und effektiven Zugriff prüfen, wenn sie entscheiden, wer diese Rechte behalten soll.

Zählen Sie verwaltete Dienstkonten mit Get-ADServiceAccount -Filter *Expand, filtern Sie dann nach Objekten, deren ObjectClassExpand msDS-GroupManagedServiceAccountExpand ist, um gMSAs von eigenständigen verwalteten Dienstkonten zu unterscheiden.

Entfernen Sie gMSAs, die Sie nicht mehr verwenden

Aktivieren Sie die Audit-Verzeichnisdienstzugriffsrichtlinie und konfigurieren Sie eine Systemzugriffskontrollliste (SACL) für die gMSAs zur Überwachung, die die Ereignis-ID 4662Expand generiert, wenn ein Principal msDS-ManagedPasswordExpand liest.

Eigenschaftskennungen erscheinen als Schema-GUIDs im Ereignis, und ADSI Edit kann die entsprechende GUID auflösen, um zu bestätigen, dass sie mit msDS-ManagedPasswordExpand übereinstimmt.

Leiten Sie die Domaincontroller-Protokolle an ein Security Information and Event Management (SIEM)-System weiter, vergleichen Sie Passwortabfragen mit den genehmigten Servicehosts des Kontos und untersuchen Sie Abrufe durch unerwartete Benutzer oder Computer.

Wie Netwrix bei der Sicherung von gMSAs hilft

gMSA-Verwaltung schützen

Die manuelle Überprüfung von Abrufberechtigungen und Audit-Protokollen ist nicht skalierbar, sobald eine Umgebung mehr als einige wenige gMSAs enthält. Diese drei Netwrix-Produkte decken den administrativen Zugriff auf das Konto ab, erkennen Missbrauch von Anmeldeinformationen und bieten fortlaufende Transparenz darüber, welche Konten noch übermäßige Berechtigungen besitzen.

Entfernen Sie ein ungenutztes gMSA von seinen früheren Hosts mit Uninstall-ADServiceAccountExpand. Die Deinstallation des Hosts und die Entfernung des Verzeichnis-Kontos sind getrennte Lebenszyklusaktionen. Stellen Sie sicher, dass alle abhängigen Workloads migriert oder eingestellt wurden, bevor Sie das AD-Objekt löschen, und entfernen Sie veraltete Host-Berechtigungen sowie zugehörige Ressourcenberechtigungen im Rahmen derselben Änderung.

Anomales Verhalten von Dienstkonten erkennen

Mit Netwrix Privilege Secure gewährt der Bezirk Zugriff über temporäre Konten, die nach Abschluss der Aufgabe entfernt werden, und implementierte Privileged Access Management für seine kritischen Systeme in Tagen statt Monaten.

Netwrix Privilege Secure ersetzt dauerhaften Zugriff auf privilegierte Objekte wie gMSAs durch temporäre, auf Aufgaben beschränkte Konten. Eastern Carver County Schools beobachtete, wie Red Teams wiederholt über übermäßigen und unnötigen privilegierten Zugriff auf kritische Systeme zugriffen.

Finden Sie überberechtigte und veraltete Dienstkonten

Netwrix Threat Manager erkennt Diebstahl von Anmeldeinformationen, laterale Bewegungen und Privilegienerweiterungen in hybriden Umgebungen. Untersuchen Sie diese Erkennungen auf Missbrauch von Dienstidentitäten wie gMSAs, bei denen ein Angreifer, der sich mit einem gestohlenen verwalteten Passwort authentifiziert, die bestehenden Rechte der Identität ausübt.

Kombinieren Sie automatische Rotation mit strengen Abrufberechtigungen

Netwrix Access Analyzer löst verschachtelte Gruppenmitgliedschaften auf und analysiert effektive Berechtigungen für Active Directory-Objekte. Seine Berichte kennzeichnen auch veraltete Treuhandkonten. Verwenden Sie diese Erkenntnisse, um die gMSA-Abrufe und Objektberechtigungen zu überprüfen und Kandidaten für die Bereinigung zu identifizieren.

Automatische Passwortrotation und strenge Abrufberechtigungen sind zwei separate Kontrollen, und ein gMSA bleibt nur dann sicher, wenn beide eingehalten werden. Die obige Erläuterung zeigt, was passiert, wenn nur eine Berechtigung versagt: Ein gewöhnliches kompromittiertes Konto erbt eine Domain Admin-Berechtigung und fälscht Tickets für die gesamte Domäne, ohne dass ein Passwort jemals geknackt oder erraten wird.

Behandeln Sie Berechtigungsüberprüfungen als wiederkehrende Aufgabe, nicht als einmaligen Einrichtungsschritt, da jeder neue Host, jede Änderung der Gruppenmitgliedschaft und jede Dienstmigration denselben Pfad wieder öffnen kann.

Fordern Sie eine Demo an und sehen Sie, wie Netwrix Privilege Secure dauerhaften Zugriff auf privilegierte Konten entfernt, Netwrix Threat Manager Missbrauch von Dienstkonten erkennt und Netwrix Access Analyzer überberechtigte Konten identifiziert.