Teil 1 - Geschützte GruppenDer AdminSDHolderTeil 3 - Anpassungen

Teil 2 - 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.  whoami-Administrator (PDF)

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.

 

© MCSEboard.de, olc

Teil 1 - Geschützte GruppenDer AdminSDHolderTeil 3 - Anpassungen