Der AdminSDHolderTeil 2 - Die Auswirkungen

Teil 1 - Geschützte Gruppen

Autor: olc, MCSEboard.de

 

Der AdminSDHolder, frei übersetzt der “Bewahrer des Security Descriptors für Administratoren“, dient dem Schutz administrativer Accounts vor Rechteänderungen ihrer ACLs. Der AdminSDHolder Prozess überprüft dazu standardmäßig jede Stunde auf dem PDC-Emulator einer Domäne alle Benutzerobjekte auf Ihre Gruppenmitgliedschaften und setzt ggf. die Rechte auf ein Benutzerobjekt, welches Gruppenmitglied bestimmter geschützter Gruppen ist, auf einen Standardset von ACLs zurück. Diesen Prozess nennt man „Security Descriptor Propagation“.
Es gibt diverse Gruppen innerhalb einer AD, die standardmäßig als „geschützte Gruppen“ definiert sind, da ihre Mitglieder bestimmte administrative Aufgaben wahrnehmen können.

Folgende Gruppen werden unter Windows Server 2003 vom AdminSDHolder geschützt:

  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Domain Admins
  • Schema Admins
  • Enterprise Admins
  • Cert Publishers

Zusätzlich werden die folgenden Benutzer direkt vom AdminSDHolder geschützt:

  • Administrator
  • Krbtgt

Um die Mitgliedschaften eines Benutzers aufzulösen werden nicht nur die direkten Gruppenmitgliedschaften ausgewertet, vielmehr wird eine Gruppenexpansion vorgenommen, d.h. Gruppen, die wiederum Mitglied in anderen Gruppen sind, werden bis zum Ende expandiert und ausgewertet. Einige Anmerkungen dazu folgen später in diesem HowTo.
Findet der AdminSDHolder Benutzer, die direkt oder verschachtelt Mitglied dieser o.g. standardmäßig vordefinierten Gruppen sind, setzt er das „Inheritance Flag“ der ACL des Benutzer zurück, so dass auf dem Benutzerobjekt keine Vererbung mehr stattfindet. Weiterhin werden die Berechtigungen auf vordefinierte Standardberechtigungen zurückgesetzt. Der Hintergrund dafür ist einleuchtend und soll anhand eines kurzen Beispiels erläutert werden.

In einer Active Directory Umgebung werden verschiedenen Administratoren, Server-Operatoren, Druck-Operatoren, Domänen-Admins oder gar Enterprise-Administratoren Rechte gegeben, um Ihre administrativen Aufgaben wahrnehmen zu können. In vielen Fällen werden die Administrator-Accounts unterhalb einer speziellen OU angesiedelt, deren Verwaltung delegiert werden kann. Aber auch das versehentliche Verschieben eines solchen Accounts in eine bestimmte OU mit delegierten Berechtigungen wäre hier ein gutes Beispiel.
Gehen wir also davon aus, dass der Benutzer oder die Gruppe, die die OU verwalten, die Berechtigungen besitzen, Kennwörter für die Benutzer unterhalb der entsprechenden OU zurückzusetzen. Es wäre einem solchen Benutzer nun problemlos möglich, das Kennwort eines Domänen- oder Enterprise-Admins zurückzusetzen, um sich dann damit anzumelden und eventuell Schaden anzurichten.

Abb. 1

Genau diesen Effekt verhindert der AdminSDHolder, denn er setzt die Berechtigungen auf dem geschützten Objekt auf einen Standard zurück, der im Normalfall eben nicht diese delegierten Berechtigungen umfasst. Außerdem wird durch das Entfernen der Vererbung von ACEs verhindert, dass die delegierten Berechtigungen nach diesem „Bereinigungsprozess“ wieder gesetzt werden.

In der Praxis wird man also bei allen Benutzern, die Mitglied einer geschützten Gruppe sind, folgende Berechtigungen finden (Abb. 1).

Die GUI zeigt jedoch längst nicht alle Details. Daher wurde mit dem Tool DSACLS.EXE eine vollständige Ausgabe der Berechtigungen für den Benutzer "Administrator erstellt:  dsacls-Administrator (PDF)

Vergleicht man diese Berechtigungen mit einem beliebigen anderen Benutzer, der (verschachtelt oder nicht) Mitglied einer geschützten Gruppe ist, stellt man fest, dass die Berechtigungen exakt dieselben sind. Genau das ist der Effekt, den der AdminSDHolder bewirkt.

Abb. 2

Die standardmäßigen Berechtigungen werden auf einem speziellen Objekt innerhalb der AD vordefiniert. Dieses Objekt findet man beispielsweise über „Active Directory User & Computer“, wenn man die erweiterte Ansicht unter „Ansicht“ >> „Erweiterte Funktionen“ aktiviert.
Es erscheint nun, neben anderen in der Normalansicht versteckten Containern, auch der Container „System“. Erweitert man diesen erscheint in der Liste das Objekt „AdminSDHolder“. Überprüft man hier in den Eigenschaften unter dem Reiter „Sicherheit“ die ACL des Objekts, findet man die gleichen Berechtigungen wie bei den oben genannten Benutzern. Das „AdminSDHolder“ Objekt dient also als Template für die ACLs eines geschützten Objekts (Abb. 2).

Vergleicht man die ACL des „AdminSDHolder“ Objekts mit der ACL des Administrators von oben (z.B. mittels WinMerge [3] oder Windiff [4]), lässt sich dies sehr gut nachvollziehen:  dsacls-AdminSDHolder (PDF)

An dieser Stelle ein Hinweis, der für das Verständnis der Thematik sehr wichtig ist: Das Template der ACLs und auch die Sicherheitseinstellungen auf den Benutzerobjekten selbst stellen nicht deren Berechtigungen auf andere Objekte dar. Vielmehr ist die ACL tatsächlich die Zugriffssteuerungsliste auf diese Objekte, d.h. jeder Eintrag auf einem solchen Benutzerobjekt definiert, was der in der ACL aufgeführte Sicherheitsprinzipal für Rechte auf dem Benutzerobjekt hat.
Genau diese Berechtigungen werden verändert, wenn man administrative Aufgaben delegiert. Gibt man beispielsweise einem administrativen Benutzer das Recht Kennwörter für Benutzer unterhalb einer bestimmten OU zurückzusetzen, wird ein Eintrag (ein sogenannter ACE – Access Control Entry) auf allen Benutzerobjekten unterhalb dieser OU gesetzt - genauer gesagt - vererbt. Diese Änderung spiegelt sich also in der ACL eines Benutzerobjekts wieder.

 

© MCSEboard.de, olc

Der AdminSDHolderTeil 2 - Die Auswirkungen