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: 
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:
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.
Die Auswirkungen
Autor: olc, MCSEboard.de
Vermutet man den AdminSDHolder hinter nicht geplanten Rechteänderungen an einem Objekt, gibt es die Möglichkeit nachzuvollziehen, ob der Benutzer vom AdminSDHolder geschützt wird.
-
- Abb. 3
Beim Durchlaufen der Benutzer und Ihrer Gruppenmitgliedschaften setzt der AdminSDHolder ein Attribut auf den Benutzerobjekten, deren ACL er verändert hat, da sie Mitglied geschützter Gruppen sind. Dieses Attribut heißt „adminCount“.
Ist der Wert des „adminCount“ auf „0“ gesetzt, also FALSE, hat der AdminSDHolder das Benutzerobjekt nicht bearbeitet und damit auch nicht die ACL des Objekts verändert bzw. zurückgesetzt. Ist dieses Attribut jedoch bei einem Benutzerobjekt auf „1“ gesetzt, also TRUE, wurde das Objekt vom AdminSDHolder irgendwann einmal bearbeitet.
Der aufmerksame Leser fragt sich gerade: „Irgendwann einmal, was heißt das?“
Die Antwort ist eindeutig und leider auch nicht wirklich zufriedenstellend: „Irgendwann einmal“, da der AdminSDHolder diesen adminCount nicht mehr zurücksetzt, wenn das Objekt nicht mehr Mitglied einer geschützten Gruppe ist. D.h. ist das Attribut ein Mal gesetzt, wird es nicht mehr (automatisch) zurückgesetzt.
Das bedeutet allerdings nicht, dass für immer die Berechtigungen des Benutzerobjekts beim Durchlauf des AdminSDHolders auf die Standardeinstellungen zurückgesetzt werden. Wird ein Benutzer aus der oder den entsprechenden geschützten Gruppen entfernt, werden seine Berechtigungen zukünftig nicht mehr vom AdminSDHolder zurückgesetzt. Sie bleiben ab diesem Zeitpunkt so, wie sie der AdminSDHolder beim letzten Durchlauf für diesen Benutzer gesetzt hat. Man kann die Berechtigungen danach wieder normal bearbeiten, so z.B. die Vererbung auf das Objekt wieder aktivieren.
Manch ein Administrator findet dieses Verhalten negativ und fragt sich, warum denn nicht die ACLs wiederhergestellt werden, die vor dem Hinzufügen des Objekts in eine geschützte Gruppe gesetzt waren.
Dieses Verhalten wurde von Microsoft bewusst so gewählt. Die Mehrzahl von befragten Kunden begrüßen diese Designentscheidung, da Benutzer, die keine administrativen Tätigkeiten mehr ausführen sollen, meist aus Sicherheitsgründen gelöscht werden oder deren Berechtigungen nach dem Entfernen aus den administrativen Gruppen sowieso noch einmal neu gesetzt werden.
Auch aus Performancegründen ist es nicht sinnvoll, mehrere Historien von ACLs eines Benutzerobjekts zu speichern, um sie ggf. wieder zurückzusetzen.
Wir können also, um auf den adminCount zurückzukommen, durch eine Überprüfung des Attributwertes sehen, ob ein Benutzer vom AdminSDHolder bearbeitet wurde oder nicht. Dies kann manuell z.B. über ADSIEdit oder LDP.EXE erfolgen oder – da der gemeine Administrator ja ein wenig „faul“ ist ;-) – über einen LDIFDE Export:
C:\>ldifde –d DC=testdom,DC=intern –f C:\TEMP\admincount_export.ldf -r "(&(objectcategory=person)(objectclass=user)(admincount=1))"
Es werden mit dieser Abfrage alle Benutzer exportiert, deren adminCount gleich „1“ ist. Hier hat man nun den Ansatzpunkt zu prüfen, ob der betroffene Benutzer (unerwünscht) dabei ist.
Da jedoch wie oben beschrieben der Benutzer schon seit längerer Zeit nicht mehr geschützt sein muss und dessen adminCount Wert trotzdem auf „1“ gesetzt bleibt, muss dieser Wert zuerst verifiziert werden.
Microsoft stellt unter [1] ein VBScript zur Verfügung, welches zwei Aufgaben übernimmt: zum einen werden bei allen Benutzern der Domäne, unabhängig davon ob sie derzeit in geschützten Gruppen sind oder nicht, mit dem adminCount von „0“ versehen. Zum anderen wird das „Inheritance Flag“, also die Vererbung, beim Scriptdurchlauf ggf. wieder aktiviert. Da der AdminSDHolder standardmäßig stündlich alle Accounts durchläuft, werden die derzeit geschützten Accounts nach ca. einer Stunde plus ein wenig Zeit zum Setzen der Einstellungen, also sagen wir nach ca. 1 ½ Stunden, wieder mit den Standard-ACLs „versorgt“ und der adminCount wird bei diesen Accounts wieder auf „1“ gesetzt. Vergleicht man nun den oben angefertigten LDIFDE Export mit einem neuen LDIFDE Export, werden nur noch die Benutzer aufgeführt werden, die aktuell in geschützten Gruppen liegen.Ungeduldigen Zeitgenossen dauert dieser Vorgang zu lange, daher können Sie das Intervall des AdminSDHolder verkürzen. Dazu muss folgender Registry Key auf dem PDC-Emulator der Domäne neu erzeugt werden.
- Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
- Key: “AdminSDProtectFrequency” als REG_DWORD (ohne Anführungszeichen)
- Wert in Sekunden: 60 bis 7200
Die Zeitspanne des AdminSDHolder Intervalls kann lediglich von 1 Minute (60 Sekunden) bis 2 Stunden (7200 Sekunden) gewählt werden. Eine kürzere Zeitspanne als 1 Stunde wird jedoch nur in Testumgebungen empfohlen, da es bei kürzeren Zeiten zu einem massiven Performanceproblem des PDC-Emulators kommen kann.
Um festzustellen, ob ein Benutzer Mitglied einer der oben aufgeführten Gruppen ist, ohne den adminCount zu prüfen, kann man sich die (expandierten) Gruppenmitgliedschaften eines Benutzers mittels „whoami /all“ anzeigen lassen, während der entsprechende Benutzer angemeldet ist. Im folgenden Beispiel ist der Standard-Account „Administrator“ am System angemeldet.
Anmerkung: die Ausgabe wurde auf die in diesem Beispiel interessanten Punkte verkürzt.
Aber Achtung: Es werden bei dieser Ausgabe lediglich die Gruppenmitgliedschaften in Sicherheitsgruppen angezeigt, nicht die Mitgliedschaften in Verteilergruppen. Da es jedoch seit Windows Server 2003 auch möglich ist, Sicherheitsgruppen und Verteilergruppen zu verschachteln, können hier unter Umständen die interessanten Gruppen gar nicht angezeigt werden, wenn diese über Verteilergruppen verschachtelt sind. Das adminCount Attribut bzw. dessen Wert liefert hier also ggf. genauere Erkenntnisse.
Aus diesem Grunde jedoch auch an dieser Stelle noch einmal der allgemeine Hinweis, Verteilergruppen und Sicherheitsgruppen nach Möglichkeit stets zu trennen, auch wenn es theoretisch anders möglich wäre.
Anpassungen
Autor: olc, MCSEboard.de
Nun liegt es mit Kenntnis der Vorgehensweise des AdminSDHolders und dessen Template nahe, bei Bedarf das Template zu verändern. Hiervon ist im Normalfall abzuraten, da es schwerwiegende Funktionsstörungen innerhalb einer AD nach sich ziehen kann, wenn hier falsche Änderungen gemacht werden. Hier sollte man nur Hand anlegen, wenn man genau weiß, was man tut.
Im Kern gibt es für den Fall der Fälle verschiedene Möglichkeiten, das gewünschte ACL-Ziel für ein Benutzerobjekt zu erreichen:
-
Man entfernt den Benutzer aus den geschützten Gruppen (Methode 1 in [1]).
-
Man ändert das Recht „Allow inheritable permissions from the parent …“ auf den Standard-ACLs des System\AdminSDHolder Objekts derjenigen Benutzer und Gruppen, die vom AdminSDHolder geschützt werden (Methode 2 in [1]).
Dieses Vorgehen sollte jedoch nach Möglichkeit nicht gewählt werden, da es bei versehentlichen Rechteänderungen auf dem übergeordneten Objekt zu massiven Funktionsstörungen in der AD kommen kann.
-
Man fügt den betroffenen Benutzer in eine neu angelegte Sicherheitsgruppe ein und gibt dieser Gruppe die entsprechenden Rechte auf dem AdminSDHolder Container.
Dieses Vorgehen ist in den meisten Fällen zu empfehlen, sollte man die ACLs auf dem „AdminSDHolder“ Template tatsächlich ändern müssen.
Noch einmal also der gut gemeinte Rat, am besten die Finger davon zu lassen.
Weiterhin gibt es, wie in [1] beschrieben auch die Möglichkeit, bestimmte Gruppen aus den geschützten Gruppen zu entfernen. Dies ist jedoch nicht Teil des HowTos.
Ein Hinweis noch zum Schluss: nicht alle ACEs werden in „Active Directory User & Computer“ oder in ADSIEdit angezeigt (z.B. nicht „Change Password“ oder „Reset Password“). Dies lässt sich zwar erzwingen, jedoch ist das dafür notwendige Vorgehen ein Thema für ein anderes HowTo ;-). Es kann allerdings DSACLS verwendet werden, um die entsprechenden ACLs anzusehen bzw. zu bearbeiten, siehe [2].
Quellen:
[1] „Delegated permissions are not available and inheritance is automatically disabled”
[2] „Security tab of the AdminSDHolder object does not display all properties“
[3] WinMerge:
[4] Windiff:
[5] “Modify the AdminSDHolder container”