AdminSDHolder und SDProp: Bereinigung und Überwachung

AdminSDHolder ist die Vorlage-ACL für jedes privilegierte Konto einer Domäne. Einmal pro Stunde kopiert der SDProp-Prozess auf dem PDC-Emulator sie auf jedes Mitglied der geschützten Gruppen. Das macht sie zu einem der wirksamsten Persistenzorte in Active Directory. Ein Angreifer, der einen einzigen ACE zu CN=AdminSDHolder,CN=System hinzufügt, bekommt dieses Recht für immer auf jeden Domänen-Admin neu angewendet – selbst nachdem die Verteidiger die einzelnen Konten bereinigt haben. Derselbe Mechanismus hinterlässt zudem eine Spur verwaister adminCount=1-Konten mit deaktivierter Vererbung und veralteten privilegierten ACLs.

Der ACL-Grundlagenleitfaden erklärt, was SDProp tut, und liefert eine erste Abfrage für veraltetes adminCount. Dieser Leitfaden ist die operative Fortsetzung. Er behandelt die genaue Menge geschützter Objekte, eine Baseline der AdminSDHolder-ACL, ein sicheres Bereinigungsverfahren, das Ausführen von SDProp bei Bedarf und Alarme, die Manipulationen erkennen.

Was SDProp schützt

In Domänen ab Windows Server 2016 schützt SDProp diese Objekte sowie die transitiven Mitglieder dieser Gruppen:

• Gruppen: Account Operators, Administrators, Backup Operators, Domain Admins, Domain Controllers, Enterprise Admins, Enterprise Key Admins, Key Admins, Print Operators, Read-only Domain Controllers, Replicator, Schema Admins, Server Operators.
• Benutzer: Administrator (RID 500) und krbtgt.

Jeder SDProp-Durchlauf:

1. Liest den Sicherheitsdeskriptor von CN=AdminSDHolder,CN=System,<domain>.
2. Vergleicht für jedes geschützte Objekt und jedes transitive Mitglied die ACL und überschreibt sie bei Abweichung. Die Vererbung am Objekt wird deaktiviert.
3. Setzt adminCount=1.

Die Schritte 2 und 3 werden nie rückgängig gemacht, wenn ein Konto eine geschützte Gruppe verlässt. Der PDC-Emulator führt den Prozess standardmäßig alle 60 Minuten aus. Das Intervall wird durch AdminSDProtectFrequency (Sekunden) unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters festgelegt.

Verschachtelung spielt eine Rolle. Eine in Domain Admins verschachtelte Sicherheitsgruppe ist geschützt, ebenso ihre Mitglieder. Ein Benutzer, der nur über die Zuweisung als primäre Gruppe Mitglied ist, ist ein bekannter Sonderfall. Prüfen Sie immer die effektive Mitgliedschaft, nicht nur das Attribut member.

Messen: eine Baseline der AdminSDHolder-ACL erstellen

Exportieren Sie die aktuelle ACL und bewahren Sie sie als signiertes, datiertes Artefakt auf:

$dn  = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
$acl = Get-Acl -Path "AD:\$dn"
$acl.Sddl | Out-File "C:\Tier0\Baseline\AdminSDHolder-$(Get-Date -f yyyyMMdd).sddl"

$acl.Access | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType,
    InheritedObjectType, AccessControlType, IsInherited |
    Sort-Object IdentityReference | Format-Table -AutoSize
$acl.Owner

Vergleichen Sie sie mit einer frisch aufgebauten Labordomäne auf derselben Funktionsebene und mit denselben optionalen Produkten (Exchange etwa fügt eigene ACEs hinzu). Zu erwarten sind ACEs für SYSTEM, Administrators, Domain Admins und Enterprise Admins, Lesezugriff für Authenticated Users und Pre-Windows 2000 Compatible Access, Change Password für Everyone und SELF sowie eng gefasste Eigenschaftsrechte für Cert Publishers, Windows Authorization Access Group und Terminal Server License Servers. Besitzer sollte Domain Admins sein.

Prüfen Sie außerdem zwei strukturelle Eigenschaften. Beim AdminSDHolder-Objekt ist die Vererbung normalerweise deaktiviert, sodass ACEs am Container System oder am Domänenstamm nicht hineinfließen. Wurde die Vererbung eingeschaltet, wird jede breite Delegierung am Domänenstamm Teil der Vorlage für Ihre Admins. Prüfen Sie auch den Besitzer. Ein Besitzer kann die DACL immer neu schreiben; ein nicht standardmäßiger Besitzer ist daher so ernst wie ein WriteDacl-ACE. Halten Sie beides in der Baseline neben der SDDL fest, damit der wöchentliche Vergleich es abdeckt.

Alles außerhalb dieser Menge – insbesondere GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty auf member oder ResetPassword (00299570-246d-11d0-a768-00aa006e0529) – braucht eine Erklärung. Ein Benutzerkonto oder eine unbekannte Gruppe mit Schreibrechten auf AdminSDHolder ist bis zum Beweis des Gegenteils als Kompromittierung zu behandeln.

Auditieren: die Verwaisten finden

Erstellen Sie die Liste der Objekte, die SDProp aktuell schützt, und vergleichen Sie sie mit allem, was adminCount=1 trägt. Der Grundlagenleitfaden prüft nur Benutzer. Hier werden Gruppen und Computer einbezogen, und die geschützten Gruppen werden über bekannte SIDs aufgelöst, damit die Abfrage in jeder Sprache funktioniert:

$domSid = (Get-ADDomain).DomainSID.Value
$protectedGroupSids = @(
    'S-1-5-32-544','S-1-5-32-548','S-1-5-32-549','S-1-5-32-550','S-1-5-32-551','S-1-5-32-552',
    "$domSid-512","$domSid-516","$domSid-521","$domSid-526"
)
$forestRootSid = (Get-ADDomain (Get-ADForest).RootDomain).DomainSID.Value
$protectedGroupSids += "$forestRootSid-518","$forestRootSid-519","$forestRootSid-527"

$protected = [System.Collections.Generic.HashSet[string]]::new()
foreach ($sid in $protectedGroupSids) {
    $g = Get-ADGroup -Filter "objectSid -eq '$sid'" -ErrorAction SilentlyContinue
    if (-not $g) { continue }
    [void]$protected.Add($g.DistinguishedName)
    Get-ADGroupMember $g -Recursive | ForEach-Object { [void]$protected.Add($_.distinguishedName) }
    # verschachtelte Gruppen sind ebenfalls geschützt
    Get-ADGroup -LDAPFilter "(memberOf:1.2.840.113556.1.4.1941:=$($g.DistinguishedName))" |
        ForEach-Object { [void]$protected.Add($_.DistinguishedName) }
}

Get-ADObject -LDAPFilter '(adminCount=1)' -Properties adminCount, objectClass, whenChanged, nTSecurityDescriptor |
    Where-Object { -not $protected.Contains($_.DistinguishedName) -and $_.Name -notin 'Administrator','krbtgt' } |
    Select-Object Name, objectClass, whenChanged,
        @{ n = 'InheritanceBlocked'; e = { $_.nTSecurityDescriptor.AreAccessRulesProtected } },
        DistinguishedName

Enterprise Admins, Schema Admins und Enterprise Key Admins befinden sich in der Stammdomäne der Gesamtstruktur; deshalb verwenden ihre SIDs die SID der Stammdomäne. In einer untergeordneten Domäne sind Mitglieder von Enterprise Admins dennoch geschützt, weil Enterprise Admins Mitglied der dortigen Gruppe Administrators ist.

Typische Verwaiste sind ehemalige Admins mit neuer Rolle, Dienstkonten, die einmal „vorübergehend“ zu Domain Admins hinzugefügt wurden, Gruppen, die verschachtelt und später wieder entfernt wurden, und in älteren Domänen Konten, die früher in Account Operators oder Print Operators waren.

Warum adminCount kein verlässliches Admin-Inventar ist

Es ist verlockend, adminCount=1 als Liste der privilegierten Konten zu verwenden. Das ist in beide Richtungen falsch. Die Liste enthält Verwaiste, wie oben gezeigt. Sie übersieht aber auch echte Privilegien. Ein Konto mit GenericAll auf Domain Admins, ein Benutzer mit DCSync-Rechten, ein Mitglied einer Gruppe, die eine mit der OU Domain Controllers verknüpfte GPO kontrolliert, und das Entra-Connect-Connector-Konto können alle die volle Kontrolle über die Domäne haben, ohne je in einer geschützten Gruppe gewesen zu sein. SDProp berührt sie nie; bei ihnen ist adminCount also nicht gesetzt, die Vererbung aktiv, und sie erhalten die Delegierungen, die ihre OU vergibt.

Verwenden Sie adminCount für das, was es ist: ein Hinweis auf frühere Mitgliedschaft in geschützten Gruppen und eine Bereinigungswarteschlange. Ihr tatsächliches Tier-0-Inventar ergibt sich aus Kontrollbeziehungen – genau das misst die Angriffspfadanalyse.

Durchsetzen: Verwaiste richtig bereinigen

Bestätigen Sie für jedes verwaiste Objekt mit dessen Verantwortlichem, dass es keine Privilegien mehr benötigt. Erledigen Sie dann drei Dinge zusammen, denn wer nur eines davon tut, löst das Problem nur zur Hälfte:

1. Die explizite ACL auf den Schema-Standard der Objektklasse zurücksetzen. Das entfernt die kopierten AdminSDHolder-ACEs.
2. Die Vererbung wieder aktivieren, damit Delegierungen auf OU-Ebene und Ihre Tiering-ACLs wieder greifen.
3. adminCount löschen.

$dn = (Get-ADUser 'j.smith-old-admin').DistinguishedName

# 1. Sichern, dann auf den Standard-Sicherheitsdeskriptor des Schemas zurücksetzen
(Get-Acl "AD:\$dn").Sddl | Out-File "C:\Tier0\Backup\$(Get-Date -f yyyyMMdd)-j.smith.sddl"
dsacls $dn /S

# 2. Sicherstellen, dass die Vererbung aktiv ist (dsacls /S lässt sie normalerweise aktiv; trotzdem erzwingen)
$acl = Get-Acl "AD:\$dn"
$acl.SetAccessRuleProtection($false, $false)
Set-Acl "AD:\$dn" -AclObject $acl

# 3. Die Markierung löschen
Set-ADObject $dn -Clear adminCount

Ändern Sie außerdem das Kennwort des Kontos. Es war privilegiert, und seine Anmeldeinformationen könnten auf Systemen außerhalb von Tier 0 zwischengespeichert sein. Überlegen Sie, ob das Konto überhaupt noch existieren sollte.

Zwei weitere Härtungsschritte verringern künftige Verwaiste:

• Leeren Sie die Operatorgruppen. Account Operators, Server Operators, Print Operators und Backup Operators verleihen weitreichende Rechte auf DCs und sind geschützt. Ersetzen Sie sie durch eingegrenzte Delegierung auf OUs. Das ist besser, als sie über die Maske in dSHeuristics von SDProp auszunehmen.
• Verwenden Sie keine geschützten Gruppen mehr für Dienstkonten. Gewähren Sie stattdessen die konkret benötigten Rechte, wie in Tier 0 definieren beschrieben.

SDProp bei Bedarf ausführen

Lösen Sie nach einer Änderung an AdminSDHolder oder einer Bereinigung einen Durchlauf auf dem PDC-Emulator aus, statt bis zu einer Stunde zu warten. Ab Windows Server 2008 R2 schreiben Sie dazu das operative Attribut runProtectAdminGroupsTask am rootDSE:

$pdc = (Get-ADDomain).PDCEmulator
$root = [ADSI]"LDAP://$pdc/RootDSE"
$root.Put('runProtectAdminGroupsTask', 1)
$root.SetInfo()

Dazu sind Domänen-Admin-Rechte nötig; der Vorgang läuft asynchron.

Überprüfen und überwachen

Führen Sie die Abfrage nach Verwaisten erneut aus. Sie sollte nur Konten zurückgeben, die Sie ausdrücklich akzeptiert haben. Richten Sie dann eine kontinuierliche Überwachung ein:

• SACL auf AdminSDHolder. Fügen Sie am AdminSDHolder-Objekt einen Überwachungseintrag für Everyone, Erfolg, für Write all properties, Modify permissions und Modify owner hinzu. Ist Audit Directory Service Changes auf den DCs aktiviert, erzeugt jede Änderung Ereignis 5136 mit dem Attribut nTSecurityDescriptor. Alarmieren Sie mit hoher Priorität. Legitime Änderungen sollten selten sein und über ein Ticket laufen.
• Geplanter Vergleich. Ein wöchentlicher Job vergleicht die aktuelle SDDL mit der Baseline-Datei und eröffnet bei jeder Abweichung ein Ticket. Das erfasst auch Änderungen, die bei ausgeschalteter Überwachung vorgenommen wurden.
• adminCount-Abweichungen. Alarmieren Sie bei Ereignis 5136, wenn adminCount an einem Objekt außerhalb Ihrer genehmigten Tier-0-Liste gesetzt wird. Das zeigt, dass jemand – wenn auch nur kurz – zu einer geschützten Gruppe hinzugefügt wurde, und ergänzt die Gruppenänderungsereignisse 4728, 4732 und 4756.

Microsoft Defender for Identity und PingCastle melden ebenfalls AdminSDHolder-Anomalien. Nutzen Sie sie als Gegenprobe, nicht als einzige Kontrolle.

Was dabei kaputtgeht

• Helpdesk-Kennwortrücksetzungen bei ehemaligen Admins. Solange ein Konto geschützt ist, blockiert SDProp geerbte OU-Delegierungen, sodass der Helpdesk sein Kennwort nicht zurücksetzen kann. Das ist beabsichtigt. Die Bereinigung kehrt das um: Sobald die Vererbung wieder aktiviert ist, greifen die OU-Delegierungen erneut, und der Helpdesk kann das Kennwort des ehemaligen Admins zurücksetzen. Prüfen Sie, ob Sie das wollen, bevor Sie die ACL eines sensiblen Kontos zurücksetzen.
• Benutzerdefinierte ACEs direkt an Admin-Konten. SDProp hat sie bereits überschrieben; Werkzeuge, die sich darauf verließen, waren also schon kaputt. Das Zurücksetzen macht das nur sichtbar.
• Anwendungen, die sich über AdminSDHolder selbst Rechte gewährt haben, etwa einige ältere Identity-Management- oder PAM-Produkte. Das Entfernen unerklärter ACEs von AdminSDHolder entzieht diese Rechte beim nächsten SDProp-Durchlauf jedem Admin. Klären Sie das vorher mit dem Hersteller.
• Änderungen an dSHeuristics. Hat jemand früher die Ausschlussmaske gesetzt, schützt ihr Entfernen die Operatorgruppen und ihre Mitglieder wieder, und Delegierungen, die auf dem Ausschluss beruhen, funktionieren nicht mehr.

Weiterführende Lektüre: der ACL-Grundlagenleitfaden, DCSync-Rechte finden für die ACL des Domänenstamms, Angriffspfadmanagement, um zu sehen, wohin verwaiste Rechte noch führen, und der Tier-0-Grundlagenleitfaden dazu, wie geschützte Konten genutzt werden sollten.