AdminSDHolder – Delegation auf Admin Accounts einrichten?

Hin und wieder kommt es vor, dass Mitarbeiter der Benutzerverwaltung (BV) Gruppen administrieren sollen, für die Domain Admin Rechte erforderlich sind. Die „Admin-Konten“ der BV haben diese Rechte aber in der Regel nicht. Dies führt zu folgenden Fragen:

Was passiert, wenn dennoch Berechtigungen vergeben werden? oder
Warum kann der HelpDesk bei ehemaligen Admins das Passwort nicht zurücksetzen?

Grundlagen und Delegationsproblem

Um das Problem besser zu verstehen, wird einleitend der Ansatz von Benutzern und Administratoren beschrieben. Im Anschluss folgen Eigenheiten, die z.B. den Unterschied zwischen einem Domain Admin und einem „bearbeitenden“ HelpDesk-Admin erläutern. Schließlich wird auf das Verhalten des Active Dirctorys eingegangen: Was passiert, wenn Delegierte Konten oder Gruppen verwalten, für die sie nicht ausreichend berechtigt sind?

Benutzer und Administratoren

Microsoft unterscheidet grundsätzlich zwischen Benutzer und Administrator. Nach Empfehlung von Microsoft soll ein Benutzer, der mit diesem Account produktiv arbeitet (z.B. Outlook oder andere Applikationen), nie Administrationsrechte im AD bekommen. Administrative Vorgänge im AD sollen immer von einem speziellen, personalisierten Admin-Account benutzt werden.

Es ist nicht ratsam jedem Benutzer, der hin und wieder etwas administriert, Domain-Admin-Rechte zu geben. Diese Rechte sind für die meisten Benutzer viel zu weitreichend und auch das Auditing wird dadurch erschwert. Vor allem aber kann mit diesem Account wissentlich und unwissentlich schwerer Schaden angerichtet werden.

Delegation der Verwaltung von High-privileged-Benutzern

Um beispielsweise Benutzer anlegen oder Passwörter zurücksetzen zu können, werden keine Domain Admin-Rechte benötigt. In diesen Fällen ist die Delegation der Aufgabe möglich und sinnvoll.

Anders sieht es mit der Verwaltung von Gruppen und Benutzern aus, für die Domain-Admin-Rechte benötigt werden, die High Privileged Groups und User.

High priviliged sind alle Benutzer oder Gruppen, die das Active Directory administrieren dürfen. Das sind die folgenden Gruppen:

High Privileged Groups:

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

High privileged user accounts:

• Administrator
• Krbtgt

Sollten Sie nun Delegierungen verwenden, um High Priviliged Users oder deren Gruppen zu verwalten, wird der Zugriff auf diese durch den AdminSDHolder verhindert. Dies geschieht allerdings nicht sofort. Die Benutzerkonten, denen diese Änderungs-Berechtigung eingeräumt wird, können für einen begrenzten Zeitraum tatsächlich Änderung durchführen.

• Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
• Key: “AdminSDProtectFrequency” als REG_DWORD (ohne Anführungszeichen)
• Wert in Sekunden: 60 bis 7200

Der Standardwert ist 3600 (60 Minuten). Dieser Wert kann auf dem PDC-Emulator der Domäne geändert werden. Allerdings sollte er nicht zu niedrig gesetzt werden, da es sonst zu Performance-Problemen kommen kann.

Ist der Benutzer Mitglied einer der geschützen Gruppen, wird der Wert des Attributs AdminCount eines Benutzers verändert:

Ist der Wert 0, dann ist der Benutzer in keiner der oben genannten Gruppen.
Ist der Wert 1, dann ist der AdminSDHolder aktiv und verrichtet bei diesem Account seine Arbeit.

Der Wert von AdminCount ist in der „Users and Computers Konsole“ nicht einsehbar.
Nutzen Sie bitte stattdessen ADSI Edit.

Wenn high-privileged Gruppen oder Benutzer auf ein Konto mir AdminCount “1” berechtigt werden, können sie dieses künftig verwalten.

Wird aber eine AD-Objekt, dass selbst nicht high-privileged ist, auf einen Account mit „AdminCount „1“ berechtigt, so erscheint auch dieses zunächst in dessen ACL. Auch in diesem Fall kann das Benutzerkonto bearbeitet werden. Dies ist aber nur bis zum nächsten Zyklus des AdminSDHolder möglich. Nach spätestens einer Stunde (bei Standardwert 3600) wird die ACL des AdminCount “1” – Benutzers bereinigt.

Außerdem wird die Vererbung für diesen Account unterbrochen. 

Befindet sich der Account in einer delegierten OU, so gelten für ihn die delegierten Berechtigungen nicht.

Bearbeitung ehemaliger Domain-Admin-Konten nicht möglich

Ich möchte dies in einem kleinen Beispiel näher erläutern:

Ein HelpDesk-Mitarbeiter (nicht in einer high-privileged group) ist für eine bestimmte OU berechtigt Passwörter zurückzusetzen. Aufgrund von unternehmensinternen Veränderungen befindet sich in dieser OU auch das Konto eines Mitarbeiters, der früher einmal Domain Admin war. Dieses Benutzerkonto hat für AdminCount nach wie vor den Wert 1. Der HelpDesk-Mitarbeiter kann also trotz Berechtigung auf diese OU das Passwort des ehemaligen Domain Admins nicht zurücksetzen.

Weitere Auswirkungen / Zurücksetzen von AdminCount

Ist der Benutzer zu einem früheren Zeitpunkt in einer durch den AdminSDHolder geschützten Gruppen gewesen, ist sein AdminCount immernoch „1“. Der Wert wird nicht automatisch wieder auf „0“ gesetzt. Daher kann es passieren, dass nach einer Umstrukturierung diese früheren „Admin“-Benutzer ebenfalls vom AdminSDHolder geschützt sind.

Microsoft stellt für diesen Fall ein Skript bereit, dass alle AdminCounts auf „0“ setzt und die Vererbung wieder aktiviert. Der AdminSDHolder setzt beim nächsten Durchlauf den AdminCount wieder bei allen Accounts auf „1“, die weiterhin in einer der geschützten Gruppen sind. Auf diese Weise hat man alle Altlasten beseitigt und trotzdem keine Sicherheitslücke.

Um das Ganze nachvollziehbar zu machen, wird auch ein Eventlog Eintrag mit der Event ID 4780 generiert.

AdminSDHolder umgehen

Eine Delegierung für Admin-Konten ist also nicht ohne Weiteres möglich. Grundsätzlich besteht aber die Möglichkeit den AdminSDHolder zu umgehen. Von dieser Möglichkeit wird jedoch dringend abgeraten. Es handelt sich dabei um einen schweren Eingriff in das Active Directory. Dieser kann weitreichende Konsequenzen nach sich ziehen. Aus diesem Grund verzichten wir an dieser Stelle auch auf eine Beschreibung für das Umgehen des AdminSDHolders.