AdminSDHolder

AdminSDHolder ist ein spezielles Container-Objekt in Active Directory mit dem Distinguished Name CN=AdminSDHolder,CN=System,DC=<domain>,DC=<tld>. Es enthält einen Security Descriptor — eine Zugriffssteuerungsliste (ACL) — der als verbindliche Vorlage für alle Mitglieder geschützter privilegierter Gruppen gilt. Ändert ein Administrator manuell die Berechtigungen auf einem privilegierten Konto, werden diese Änderungen automatisch und regelmäßig überschrieben, weil ein Hintergrundprozess die ACL des AdminSDHolder-Objekts auf alle betroffenen Konten kopiert. Genau dieses Verhalten macht AdminSDHolder zu einem der wirkungsvollsten — und gleichzeitig am häufigsten unterschätzten — Persistenzmechanismen in Active-Directory-Umgebungen.

SDProp: Der unsichtbare Hintergrundprozess

Das Herzstück des AdminSDHolder-Mechanismus ist der Security Descriptor Propagator (SDProp). Dieser Prozess läuft standardmäßig alle 60 Minuten auf dem PDC-Emulator (Primary Domain Controller Emulator) und führt eine einfache, aber weitreichende Aufgabe aus: Er vergleicht die ACL aller Mitglieder geschützter Gruppen mit der ACL des AdminSDHolder-Objekts und überschreibt abweichende Einträge. Das Intervall ist über den Registrierungsschlüssel HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency konfigurierbar — in der Praxis wird dieser Wert selten angepasst.

Die Konsequenz dieses Mechanismus ist gravierend: Jede manuelle ACL-Änderung an einem geschützten Konto lebt maximal 60 Minuten. Danach stellt SDProp den ursprünglichen Zustand wieder her. Für legitime Administratoren ist das schlicht lästig — ein versehentlich entferntes Leserecht ist nach einer Stunde wieder vorhanden. Für einen Angreifer, der die ACL des AdminSDHolder-Objekts selbst manipuliert hat, ist es ein zuverlässiger Persistenzmechanismus: SDProp sorgt dafür, dass die hinterlegte Hintertür nach jeder Bereinigung innerhalb einer Stunde automatisch erneut auf alle privilegierten Konten propagiert wird.

Welche Gruppen sind betroffen?

SDProp schützt alle Mitglieder einer fest definierten Liste privilegierter Gruppen. Diese Liste ist in Active Directory hartcodiert und umfasst:

• Domain Admins — die bekannteste privilegierte Gruppe
• Enterprise Admins — Rechte über alle Domänen der Gesamtstruktur
• Schema Admins — Schreibzugriff auf das AD-Schema
• Administrators (Built-in) — lokale Administratoren des Domain Controllers
• Account Operators — können Benutzerkonten und Gruppen verwalten
• Backup Operators — können Systemsicherungen erstellen und Dateien wiederherstellen
• Server Operators — können Dienste starten/stoppen und Dateien auf Servern verwalten
• Print Operators — können Drucker verwalten und sich lokal an Domain Controllern anmelden
• Domain Controllers — alle Domain Controller der Domäne
• Read-only Domain Controllers — RODCs (ab Windows Server 2008)
• Replicator — steuert die Dateireplikation
• Krbtgt — das Dienstkonto für die Kerberos-Ticket-Ausstellung

Historisch schützte SDProp ausschließlich direkte Mitglieder dieser Gruppen. Bei verschachtelten Gruppen (nested groups) hängt das genaue Verhalten von der Windows-Server-Version ab. In modernen Active-Directory-Umgebungen gilt: Wer auch nur temporär Mitglied einer dieser Gruppen war, trägt dauerhaft die Spuren davon — das adminCount-Attribut.

Das adminCount-Attribut und seine Fallstricke

Jedes Konto, das jemals Mitglied einer geschützten Gruppe war, erhält durch SDProp das Attribut adminCount=1. Dieses Attribut zeigt an, dass das Konto unter der Kontrolle des AdminSDHolder-Mechanismus steht oder stand — und es hat eine entscheidende Eigenschaft: Es wird nicht automatisch zurückgesetzt, wenn das Konto aus der geschützten Gruppe entfernt wird.

Das bedeutet in der Praxis: Ein Dienstkonto, das vor drei Jahren vorübergehend Mitglied der Domain-Admins-Gruppe war und längst wieder entfernt wurde, trägt immer noch adminCount=1. Es unterliegt nicht mehr dem SDProp-Schutz, aber sein adminCount-Attribut suggeriert das Gegenteil — und es hat möglicherweise eine restriktivere ACL-Vererbungskonfiguration, da SDProp die Vererbung auf geschützten Objekten deaktiviert (AdminSDHolder setzt Allow inheritable permissions from the parent to propagate to this object and all child objects auf deaktiviert).

In Penetrationstests und Security-Assessments ist eine erhöhte Anzahl von Konten mit adminCount=1 außerhalb privilegierter Gruppen ein zuverlässiger Indikator für mangelhafte Berechtigungshygiene. Diese Konten können verwaiste Privilegien besitzen, und ihre abweichende ACL-Konfiguration kann unbeabsichtigte Angriffspfade eröffnen. Eine einfache LDAP-Abfrage liefert alle betroffenen Konten:

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount |
  Select-Object SamAccountName, DistinguishedName, Enabled |
  Where-Object { $_.DistinguishedName -notmatch "OU=Privileged" }

Ähnlich für Computerkonten und Gruppen:

Get-ADObject -LDAPFilter "(&(adminCount=1)(!(objectClass=user)))" -Properties adminCount, objectClass |
  Select-Object SamAccountName, objectClass, DistinguishedName

AdminSDHolder als Persistenzmechanismus

Der Missbrauch von AdminSDHolder ist eine etablierte Technik in der Angreiferpraxis. Der Ablauf ist konzeptionell einfach: Ein Angreifer, der bereits Domain-Admin-Rechte erlangt hat — etwa über DCSync, Kerberoasting oder Ausnutzung eines unsicheren Service Accounts — fügt ein eigenes Konto oder eine eigene Gruppe als ACE (Access Control Entry) in die ACL des AdminSDHolder-Objekts ein. Er gibt diesem ACE weitreichende Rechte, etwa GenericAll, WriteDACL oder ResetPassword.

Ab diesem Moment übernimmt SDProp die Arbeit: Alle 60 Minuten propagiert der Prozess diesen Backdoor-ACE auf alle Mitglieder der geschützten Gruppen — also auf sämtliche Domain Admins, Enterprise Admins und weitere privilegierte Konten. Der Angreifer kann nun, auch nachdem das ursprünglich kompromittierte Konto bereinigt wurde, die Passwörter aller privilegierten Konten zurücksetzen oder deren Berechtigungen direkt modifizieren.

Dieser Mechanismus ist deshalb so tückisch, weil Incident-Response-Teams häufig das kompromittierte Konto sperren, Passwörter zurücksetzen und Malware entfernen — aber den AdminSDHolder nicht prüfen. Nach spätestens einer Stunde hat SDProp die Hintertür auf alle privilegierten Konten erneut propagiert, und der Angreifer behält den vollständigen Domänenzugang.

In der Praxis begegnet uns dieses Muster regelmäßig bei der Analyse von Sicherheitsvorfällen: Die initiale Kompromittierung wurde zwar erkannt, aber die Persistenz über AdminSDHolder erst Wochen später entdeckt — nachdem das Unternehmen mehrfach vergeblich versucht hatte, die Umgebung zu bereinigen.

Erkennung

Die wichtigste Erkennungsmaßnahme ist die Überwachung von Änderungen am AdminSDHolder-Objekt selbst. Windows protokolliert ACL-Änderungen an AD-Objekten über Event ID 5136 (Directory Service Object Modified) im Security-Log des Domain Controllers. Für eine zuverlässige Erkennung muss die SACL (System Access Control List) des AdminSDHolder-Objekts so konfiguriert sein, dass Schreibzugriffe auditiert werden — in vielen Standardinstallationen fehlt diese Konfiguration.

Ein SIEM-System sollte folgende Indikatoren überwachen:

• Event ID 5136 auf dem Objekt CN=AdminSDHolder,CN=System — jede Änderung ist ein kritisches Ereignis
• Korrelation mit SDProp-Propagation — Massen-ACL-Änderungen auf privilegierten Konten kurz nach einer AdminSDHolder-Modifikation
• Ungewöhnliche SDProp-Aktivität — wenn nach einem Security Event plötzlich viele ACL-Änderungen auf privilegierten Konten auftreten, ist das ein Hinweis auf eine frische Propagation

Ergänzend sollten im Rahmen regelmäßiger Audits alle Konten mit adminCount=1 inventarisiert werden, die sich nicht in privilegierten Organisationseinheiten befinden. Ein signifikanter Bestand solcher Konten deutet auf historische Berechtigungsfehler hin und erhöht die Angriffsfläche.

Beziehung zum Tiering-Modell

Im Kontext des Tiering-Modells ist AdminSDHolder eindeutig Tier 0 — es gehört zur Identitätssteuerungsebene und ist gleichrangig mit den Domain Controllern selbst. Jede Modifikation des AdminSDHolder-Objekts ist ein kritisches Sicherheitsereignis, das dieselbe Reaktion erfordert wie eine direkte Kompromittierung eines Domain Controllers.

Diese Einordnung hat praktische Konsequenzen: Lesezugriff auf AdminSDHolder darf ausschließlich Tier-0-Konten vorbehalten sein. Änderungsrechte gehören in die engste privilegierte Gruppe und müssen durch Just-in-Time-Zugriff (PAM) abgesichert werden. Dedizierte Privileged Access Workstations (PAWs) für die Tier-0-Verwaltung stellen sicher, dass keine Credentials für AdminSDHolder-Änderungen auf niedriger eingestuften Systemen kompromittiert werden können.

Die Protected Users-Sicherheitsgruppe bietet einen ergänzenden Schutz für Tier-0-Konten, indem sie bestimmte Authentifizierungsmethoden (NTLM, RC4, Kerberos-Delegierung) für Mitglieder dieser Gruppe deaktiviert. Sie ist jedoch kein Ersatz für eine saubere AdminSDHolder-Konfiguration.

Härtungsmaßnahmen

Die Absicherung des AdminSDHolder-Mechanismus umfasst mehrere Maßnahmen, die in jedem Active-Directory-Härtungsprogramm verankert sein sollten.

ACL-Audit des AdminSDHolder-Objekts: Die aktuelle ACL sollte regelmäßig gegen einen bekannten guten Zustand verglichen werden. Mit PowerShell lassen sich alle ACEs ausgeben:

$adminSDHolder = [ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=domain,DC=local"
$adminSDHolder.ObjectSecurity.Access |
  Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType |
  Sort-Object IdentityReference

Jeder ACE, der nicht explizit dokumentiert und genehmigt ist, sollte als Anomalie behandelt werden.

Bereinigung verwaister adminCount-Attribute: Für alle Konten mit adminCount=1, die sich nicht mehr in geschützten Gruppen befinden, sollte das Attribut zurückgesetzt und die ACL-Vererbung wiederhergestellt werden. Das erfordert manuelle Arbeit pro Konto oder ein dediziertes Skript — automatisierte Tools wie Microsoft Identity Manager oder Skripte auf Basis des Active Directory-Moduls können diesen Prozess skalieren.

Audit-Richtlinien aktivieren: GPO-Einstellungen unter Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > DS Access > Audit Directory Service Changes müssen aktiviert sein, damit Event ID 5136 generiert wird. Zusätzlich sollte die SACL des AdminSDHolder-Objekts so konfiguriert sein, dass alle Schreiboperationen auditiert werden.

SDProp-Intervall nicht reduzieren: Eine Verkürzung des SDProp-Intervalls (unter 60 Minuten) erhöht die Domänenlast und löst das eigentliche Problem nicht. Die korrekte Maßnahme ist die Überwachung von Änderungen, nicht die Beschleunigung der Propagation.

Relevanz für KMUs

In mittelständischen Umgebungen wird AdminSDHolder selten aktiv überwacht. Die ACL enthält häufig Einträge, die auf frühere Administratoren, gelöschte Service Accounts oder längst verlassene Berechtigungskonzepte zurückgehen. Gleichzeitig fehlt das Monitoring, das eine Modifikation dieses Objekts als kritisches Ereignis einstuft.

Wir finden in Assessments regelmäßig AdminSDHolder-Konfigurationen, die seit der ursprünglichen Domäneneinrichtung nie auditiert wurden — und vereinzelt ACEs, die keinem aktuell bekannten Konto mehr zuzuordnen sind. Schon eine einmalige Inventarisierung der AdminSDHolder-ACL und der Konten mit adminCount=1 liefert wertvolle Erkenntnisse über den tatsächlichen Berechtigungsstand einer Umgebung und deckt oft Überreste früherer Kompromittierungen oder Konfigurationsfehler auf.