GPO-Berechtigungen und gPLink-Rechte auditieren

Eine GPO ist Codeausführung auf jedem Computer, auf den sie angewendet wird. Eine geplante Aufgabe, ein Startskript oder ein Eintrag für eingeschränkte Gruppen, verteilt über eine mit der OU Domain Controllers verknüpfte GPO, läuft innerhalb des nächsten Aktualisierungszyklus als SYSTEM auf jedem DC. Damit werden drei Berechtigungen zu Tier 0, sobald sie Tier-0-Systeme berühren: das Recht, eine GPO zu bearbeiten, das Recht, eine GPO mit einer OU, einem Standort oder einer Domäne zu verknüpfen, und das Recht, überhaupt GPOs zu erstellen. Angriffspfad-Werkzeuge wie BloodHound fördern regelmäßig GpoEdit- oder gPLink-Schreibrechte von Helpdesk-Gruppen zutage, und diese gehören zu den häufigsten Wegen zur Domänenkompromittierung, die bei Bewertungen gefunden werden.

Der Leitfaden zu Gruppenrichtlinien und SYSVOL führt die Unterscheidung zwischen Bearbeiten und Verknüpfen mit einer schnellen Prüfung des Domänenstamms und der DC-OU ein. Dieser Leitfaden geht weiter: jede GPO, jede OU und jeder Standort, GPO-Besitz, die Erstellergruppe, WMI-Filter und die Verknüpfung all dessen, die zeigt, welche Befunde tatsächlich Tier 0 sind.

Wie GPO-Berechtigungen gespeichert werden

Eine GPO besteht aus zwei Hälften. Der Gruppenrichtliniencontainer (GPC) ist ein AD-Objekt unter CN={GUID},CN=Policies,CN=System,<domain DN>; die Gruppenrichtlinienvorlage (GPT) ist der Ordner \\<domain>\SYSVOL\<domain>\Policies\{GUID}. Die Gruppenrichtlinien-Verwaltungskonsole (GPMC) und das PowerShell-Modul GroupPolicy schreiben übereinstimmende Berechtigungen in beide Hälften, ausgedrückt in fünf Stufen: GpoRead, GpoApply, GpoEdit, GpoEditDeleteModifySecurity und GpoCustom. Wer Schreibzugriff auf eine der beiden Hälften hat, kann ändern, was die Richtlinie bewirkt.

Verknüpfungsrechte sind davon getrennt und liegen auf dem Ziel: Schreibzugriff auf das Attribut gPLink (Schema-GUID f30e3bbe-9ff0-11d1-b603-0000f80367c1) eines OU-, Domänen- oder Standortobjekts entscheidet, welche GPOs dort gelten. gPOptions (f30e3bbf-9ff0-11d1-b603-0000f80367c1) steuert „Vererbung deaktivieren“. GenericAll, GenericWrite, WriteDacl und WriteOwner auf der OU schließen beides ein.

Messen: GPOs ihrer Reichweite zuordnen

Beginnen Sie mit der Verknüpfung, die über den Schweregrad entscheidet: Welche GPOs gelten für Tier-0-Systeme? Nehmen Sie mindestens die OU Domain Controllers, den Domänenstamm und jede OU mit Tier-0-Servern (AD CS, Entra Connect, Backup, PAM) aus Ihrem Tier-0-Inventar auf.

Import-Module GroupPolicy, ActiveDirectory
$domain = Get-ADDomain
$tier0Targets = @(
    $domain.DomainControllersContainer
    $domain.DistinguishedName
    'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'   # an Ihre Struktur anpassen
)

$tier0Gpos = foreach ($t in $tier0Targets) {
    (Get-GPInheritance -Target $t).InheritedGpoLinks |
        Select-Object @{n='Target';e={$t}}, DisplayName, GpoId, Enforced
}
$tier0Gpos | Sort-Object DisplayName -Unique | Format-Table -AutoSize

InheritedGpoLinks enthält weiter oben verknüpfte GPOs und erzwungene Verknüpfungen und spiegelt damit wider, was tatsächlich gilt. Mit Standorten verknüpfte GPOs gelten auch für die DCs an diesem Standort; listen Sie sie über das Attribut gPLink der Objekte unter CN=Sites,CN=Configuration,... auf (siehe unten).

Auditieren: GPO-Bearbeitungsrechte und Besitz

Listen Sie jeden nicht standardmäßigen Berechtigten mit Bearbeitungszugriff oder Besitz auf und kennzeichnen Sie die GPOs, die Tier 0 erreichen:

$defaultTrustees = 'Domain Admins','Enterprise Admins','SYSTEM','ENTERPRISE DOMAIN CONTROLLERS','Authenticated Users'
$tier0Ids = $tier0Gpos.GpoId | ForEach-Object { $_.ToString() }

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $perms = Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity','GpoCustom' -and
                       $_.Trustee.Name -notin $defaultTrustees }
    foreach ($p in $perms) {
        [pscustomobject]@{
            GPO        = $gpo.DisplayName
            Tier0      = $tier0Ids -contains $gpo.Id.ToString()
            Trustee    = "$($p.Trustee.Domain)\$($p.Trustee.Name)"
            Permission = $p.Permission
            Owner      = $gpo.Owner
        }
    }
} | Sort-Object Tier0, GPO -Descending | Format-Table -AutoSize

GpoCustom erfordert einen manuellen Blick auf den zugrunde liegenden ACE, da sich dahinter ein einzelnes WriteProperty oder WriteDacl verbergen kann. Prüfen Sie außerdem die Spalte Owner separat: Der Besitzer des GPC hat implizit das Recht, dessen Berechtigungen zu ändern. GPOs, die von Mitgliedern von Group Policy Creator Owners erstellt wurden, gehören diesem Mitglied, nicht den Domänen-Admins.

Die GPMC meldet außerdem, wenn AD- und SYSVOL-Berechtigungen nicht übereinstimmen („Die Berechtigungen für dieses GPO im SYSVOL-Ordner sind inkonsistent“). Eine Inkonsistenz bedeutet meist, dass jemand die NTFS-ACL oder die AD-ACL direkt bearbeitet hat; prüfen Sie den GPT-Ordner, wenn der GPC sauber aussieht:

$gpoPath = "\\$($domain.DNSRoot)\SYSVOL\$($domain.DNSRoot)\Policies"
foreach ($id in $tier0Ids) {
    (Get-Acl "$gpoPath\{$id}").Access |
        Where-Object { $_.FileSystemRights -match 'Write|Modify|FullControl|ChangePermissions|TakeOwnership' } |
        Select-Object @{n='GPO';e={$id}}, IdentityReference, FileSystemRights, IsInherited
}

Auditieren: Verknüpfungsrechte auf OUs, der Domäne und Standorten

Ermitteln Sie als Nächstes jeden Nicht-Administrator, der irgendwo gPLink schreiben kann. Filtern Sie bekannte Administrator-SIDs anhand des Suffixes statt anhand des Namens heraus, damit lokalisierte Gruppennamen nicht durchrutschen.

$gpLink  = [guid]'f30e3bbe-9ff0-11d1-b603-0000f80367c1'
$adminRx = '-(512|518|519)$|^S-1-5-18$|^S-1-5-32-544$|^S-1-5-9$'   # DA, Schema Admins, EA, SYSTEM, Administrators, EDCs
$configNC = (Get-ADRootDSE).configurationNamingContext

$targets = @($domain.DistinguishedName) +
           (Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName) +
           (Get-ADObject -SearchBase "CN=Sites,$configNC" -LDAPFilter '(objectClass=site)' |
                Select-Object -ExpandProperty DistinguishedName)

foreach ($t in $targets) {
    (Get-Acl "AD:\$t").Access | Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
            ($_.ActiveDirectoryRights -match 'WriteProperty' -and $_.ObjectType -in $gpLink, [guid]::Empty) -or
            $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner')
    } | ForEach-Object {
        $sid = try { $_.IdentityReference.Translate([Security.Principal.SecurityIdentifier]).Value } catch { $_.IdentityReference.Value }
        if ($sid -notmatch $adminRx) {
            [pscustomobject]@{
                Target    = $t
                Trustee   = $_.IdentityReference.Value
                Rights    = $_.ActiveDirectoryRights
                Inherited = $_.IsInherited
            }
        }
    }
} | Sort-Object Target | Format-Table -AutoSize

Auf Abteilungs-OUs sind einige legitime Delegierungen zu erwarten. Alles auf dem Domänenstamm, der OU Domain Controllers, einem Standort mit DCs oder einer OU mit Tier-0-Servern ist ein Befund. Denken Sie daran, dass mit Standorten verknüpfte GPOs für jeden Computer am Standort gelten, DCs eingeschlossen — Schreibzugriff auf ein Standortobjekt ist also so sensibel wie der Domänenstamm. Zur übergeordneten Frage, welche weiteren ACEs auf diesen OUs relevant sind, siehe AD-ACLs auditieren.

Auditieren: GPO-Erstellung und WMI-Filter

Get-ADGroupMember 'Group Policy Creator Owners' -Recursive | Select-Object Name, objectClass

# Wer GPOs direkt im Policies-Container erstellen darf
$policies = "CN=Policies,CN=System,$($domain.DistinguishedName)"
(Get-Acl "AD:\$policies").Access |
    Where-Object { $_.ActiveDirectoryRights -match 'CreateChild|GenericAll' } |
    Select-Object IdentityReference, ActiveDirectoryRights

# WMI-Filter: Schreibzugriff ändert die Zielauswahl jeder GPO, die sie verwendet
$som = "CN=SOM,CN=WMIPolicy,CN=System,$($domain.DistinguishedName)"
Get-ADObject -SearchBase $som -LDAPFilter '(objectClass=msWMI-Som)' -Properties msWMI-Name |
    ForEach-Object {
        $f = $_
        (Get-Acl "AD:\$($f.DistinguishedName)").Access |
            Where-Object { $_.ActiveDirectoryRights -match 'Write|GenericAll' } |
            Select-Object @{n='Filter';e={$f.'msWMI-Name'}}, IdentityReference, ActiveDirectoryRights
    }

Group Policy Creator Owners sollte leer sein. Ein beschreibbarer WMI-Filter erlaubt seinem Bearbeiter, den Geltungsbereich einer GPO zu erweitern — etwa so, dass eine vom Helpdesk verwaltete Arbeitsstations-GPO auch für Server gilt.

Die Ergebnisse lesen: häufige Befunde

Dieselbe Handvoll Muster macht in realen Domänen die meisten Befunde aus. Wer sie kennt, triagiert schneller.

• Helpdesk oder Serverteam mit GpoEdit auf der Default Domain Policy oder der Default Domain Controllers Policy. Meist vor Jahren gewährt, damit ein Team eine einzelne Einstellung ändern konnte. Beide GPOs erreichen Tier 0, das entspricht also Domänen-Admin-Rechten. Verlagern Sie die benötigte Einstellung in eine GPO für die eigene OU des Teams und entziehen Sie das Recht.
• Ein ehemaliger Administrator als GPO-Besitzer. Der Besitz überdauert Änderungen der Gruppenmitgliedschaft und sogar Kontoumbenennungen. Ist das Konto deaktiviert, ist das Risiko gering, der Besitz verhindert aber saubere Audits; ist es noch aktiviert, hat es implizite Rechte über die Berechtigungen der GPO.
• Authentifizierte Benutzer oder Domänen-Benutzer mit GpoEdit. Fast immer ein Fehler beim Konfigurieren der Sicherheitsfilterung, bei dem jemand die falsche Berechtigungsstufe gewählt hat. Ein kritischer Befund, wenn die GPO irgendwo verknüpft ist.
• Dienstkonten mit Verknüpfungsrechten. Bereitstellungs- und Provisionierungswerkzeuge erhalten mitunter weitreichenden Schreibzugriff auf OUs, um Computer verschieben zu können, was stillschweigend gPLink einschließt. Beschränken Sie ihre Delegierung auf die konkreten Objekttypen und Attribute, die sie benötigen.
• Vererbtes GenericAll auf einem OU-Baum. Eine auf einer übergeordneten OU vorgenommene Delegierung wirkt auf jede untergeordnete OU, auch auf eine Tier-0-OU, die später jemand darunter angelegt hat. Tier-0-OUs sollten die Vererbung delegierter ACEs blockieren oder ganz außerhalb delegierter Bäume liegen.

Behandeln Sie jeden Befund an einer GPO, die in der Tier-0-Zuordnung aus dem Schritt „Messen“ auftaucht, als Tier-0-Befund — unabhängig davon, was der Name der GPO nahelegt.

Erzwingen: entziehen und neu delegieren

Entziehen Sie Nicht-Administratoren die Bearbeitungsrechte an Tier-0-GPOs mit dem Modul GroupPolicy, das GPC und GPT gemeinsam aktualisiert:

Set-GPPermission -Name 'Default Domain Controllers Policy' -TargetName 'CORP\Helpdesk' `
    -TargetType Group -PermissionLevel None -Replace

Entfernen Sie eine gPLink-Delegierung auf einer OU, indem Sie gezielt den betreffenden ACE entfernen statt aller ACEs des Berechtigten:

$ou  = 'OU=Tier0 Servers,OU=Admin,DC=corp,DC=example'
$acl = Get-Acl "AD:\$ou"
$acl.Access | Where-Object { $_.IdentityReference -eq 'CORP\Helpdesk' -and $_.ObjectType -eq $gpLink -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$ou" -AclObject $acl

Ist der ACE vererbt, korrigieren Sie ihn auf der übergeordneten Ebene, auf der er definiert ist. Delegieren Sie dann richtig neu: Abteilungsadministratoren erhalten GpoEdit auf ihren eigenen GPOs und Verknüpfungsrechte nur auf ihrer eigenen OU (GPMC > die OU > Registerkarte „Delegierung“ > GPOs verknüpfen), und Tier-0-GPOs werden ausschließlich von Tier-0-Administratoren an einer Privileged Access Workstation bearbeitet. Übernehmen Sie den Besitz von GPOs ehemaliger Ersteller und übertragen Sie ihn an Domänen-Admins.

Überprüfen

Führen Sie die drei Prüfblöcke erneut aus; die Tier-0-Zeilen sollten nun nur noch die Standard-Administratorberechtigten aufführen. Bestätigen Sie das mit Get-GPPermission -Name '<GPO>' -All für jede Tier-0-GPO und prüfen Sie, dass die GPMC keine Warnungen zu SYSVOL-Inkonsistenzen anzeigt. Machen Sie anschließend Abweichungen sichtbar: Aktivieren Sie „Audit Directory Service Changes“ auf den DCs und fügen Sie SACLs für Schreibzugriffe auf groupPolicyContainer-Objekte und auf gPLink von OUs hinzu. Die Ereignisse 5136 (Attribut geändert, einschließlich gPLink und versionNumber), 5137 (GPO erstellt) und 5141 (GPO gelöscht) protokollieren dann jede Änderung; die Referenz der AD-Ereignis-IDs erläutert, wie man sie liest.

Was dabei ausfallen kann

• Entziehen der Bearbeitungsrechte von Helpdesk- oder Standortadministratoren an gemeinsam genutzten GPOs verhindert Änderungen, die sie bisher selbst vorgenommen haben. Geben Sie ihnen eigene GPOs, beschränkt auf ihre OUs.
• Entziehen von gPLink-Rechten bedeutet, dass delegierte Administratoren keine GPOs mehr an OUs außerhalb ihres Bereichs anhängen können; was sie bereits weiter oben verknüpft hatten, wirkt weiter, bis jemand die Verknüpfung entfernt — prüfen Sie auch die bestehenden Verknüpfungen.
• Leeren von Group Policy Creator Owners blockiert die GPO-Erstellung für diese Mitglieder; die Erstellung muss über die beauftragte Gruppe laufen.
• Übernahme des Besitzes von GPOs entzieht dem bisherigen Besitzer das implizite WriteDacl, was Automatisierungen lahmlegen kann, die unter diesem Konto liefen und Berechtigungen änderten.
• Ändern der Sicherheitsfilterung beim Aufräumen: Seit MS16-072 (Juni 2016) lesen Computer GPOs in ihrem eigenen Sicherheitskontext. Wenn Sie Authentifizierte Benutzer aus der ACL einer GPO entfernen, müssen Sie Read für Domänencomputer (oder die Zielcomputer) belassen, sonst wird die GPO stillschweigend nicht mehr angewendet.
• Verschärfen der ACLs von WMI-Filtern hindert Nicht-Administratoren daran, die Zielauswahl anzupassen, was manche Teams für Rollouts nach Betriebssystemversion nutzen.

Weiterführend: der Themenbereich Gruppenrichtlinien & SYSVOL, Angriffspfad-Management, um GPO-Kanten im Gesamtgraphen zu priorisieren, und GPP-Kennwörter entfernen für den anderen langjährigen GPO-Befund.