Active Directory Admin Berechtigungen delegieren

Einige Leser dieses Blogs haben sich einen Beitrag über das Delegieren von Admin Berechtigungen gewünscht. Die meisten Anfragen drehen sich darum, dass bestimmte administrative Tätigkeiten, wie das Anlegen von Benutzerkonten oder das Zurücksetzen von Passwörtern, von Benutzern übernommen werden sollen. Diese Benutzer sollen selbstverständlich keine Domain Admin Berechtigungen besitzen, sondern nur die für ihre Tätigkeit erforderlichen Berechtigungen. Oft drehen sich die Anfragen, wie die Verwaltung ganzer Standorte inkl. der Gruppenrichtlinien an andere Administratoren delegiert werden kann, ohne dass diese Mitglied der Gruppe Domain Admins sein müssen.

In diesem Artikel geht es darum, dass die Verwaltung ganzer Standorte einer Firma an unterschiedliche Administratoren delegiert werden soll. Damit Berechtigungen innerhalb des Active Directory delegiert werden können, ist zunächst eine Struktur der Organisationseinheiten des Unternehmens nötig. Eine entsprechende Struktur lässt sich nicht starr vorgeben, sondern richtig sich idealerweise nach den Anforderungen und der Organisation des Unternehmens. Ich persönlich finde es am Einfachsten, wenn es einmal mit einer einfachen und flachen Struktur begonnen wird, je nach Anforderung lässt sich dann die OU-Struktur erweitern oder verändern. Viel wichtiger, als direkt eine perfekt auf das Unternehmen zugeschnittene OU-Struktur, ist es die Sicherheit des Active Directory direkt von Anfang mit zu betrachten und umzusetzen.

Berechtigungen delegieren

Für dieses Beispiel nehmen wir mal ein Unternehmen mit zwei Standorten (Standort A und B) an. Die beiden Standorte sollen von unterschiedlichen Admins verwaltet werden. Ein Standort Admin soll jeweils nur für seinen Standort, Benutzer / Gruppen anlegen und verwalten, Computer ins Active Directory aufnehmen und Gruppenrichtlinien für die Computer erstellen dürfen. Ihr selbst, als Domain Admin, wollt aber die Kontrolle über die Berechtigungen behalten und bestimmte Grundeinstellungen vorgeben können.

Eine sehr flache OU-Struktur des Unternehmens könnte daher etwa wie folgt aussehen:

Zugegeben: Die Struktur ist sehr flach, aber darauf könnte man ja aufbauen. Wie man sieht gibt es zunächst zwei verschiedene OU-„Zweige“: Administration und Standorte, darunter gibt es dann jeweils weitere OUs. Im weiteren Verlauf des Artikels wird klar, warum es Sinn macht, eine separate OU „Administration“ zu erstellen und nicht die Admin-Benutzer und Admin-Gruppen den OUs des jeweiligen Standorts zuzuordnen.

Die Benutzer AdminA und AdminB sind jeweils Mitglieder der Gruppen „Standort A Admins“ oder „Standort B Admins“. Die Gruppen welche die Admin Benutzerkonten enthalten können dann entsprechende Berechtigungen erhalten:

Um der Gruppe „Standort A Admins“ bestimmte Berechtigungen auf dem jeweiligen Standort zu geben, gibt es im Active Directory extra einen Assistenten. Der Assistent „Delegate Control“ findet sich im Kontextmenü der OU:

Im Assistenten wird nun zunächst die Gruppe ausgewählt, welche entsprechende Berechtigungen auf dem Standort erhalten soll. In diesem Beispiel ist es die Gruppe „Standort A Admins“:

Im nächsten Schritt werden die Berechtigungen ausgewählt, welche die Standort-Administratoren erhalten sollen. In diesem Beispiel bekommen die Standort Admins die folgenden Berechtigungen, somit können die Standort Admins beispielsweise selbstständig Benutzer und Gruppen anlegen und löschen:

Wenn Standort Admins auch in der Lage sein sollen, Gruppenrichtlinien für den Standort zu verwalten, sollten auch die Optionen „Manage Group Policy Links“ und „Generate Resultant Set of Policy (Planning / Logging) eingeschaltet werden:

Der Assistent ist nun bereits am abgeschlossen, für weitere OUs kann nach dem gleichen Schema vorgegangen werden:

Da Standort Admins auch in der Lage sein sollen, Computer und Kontakte innerhalb der Standorte anzulegen und zu verwalten, muss der Assistent noch einmal ausgeführt werden. Die „Common Tasks“ decken dies nicht mit ab. Im Assistent kann daher „Create a custon task to delegate“ ausgewählt werden:

Im nächsten Schritt werden die Objekte ausgewählt, welche der Standort Admin verwalten darf, in diesem Beispiel also Computer und Kontakte:

Im letzten Schritt werden dann die Rechte für die zuvor ausgewählten Objekte festgelegt:

Der Benutzer AdminA kann jetzt bereits innerhalb der OU „Standort A“ Gruppen, Benutzer und Computer erstellen und löschen. Auch die Gruppenmitgliedschaften innerhalb seines Standorts kann AdminA verwalten.

Wenn das Recht „Manage Group Policy Links“ ausgewählt wurde, kann AdminA auch bereits vorhandene Gruppenrichtlinien mit dem Standort A verbinden. AdminA kann allerdings selbst keine neuen Gruppenrichtlinien erstellen. Sinnvoll ist dieses Vorgehen, wenn ihr selbst die Gruppenrichtlinien vorgeben wollt und der Standort Admin entscheidet, welche Gruppenrichtlinien für seinen Standort gelten sollen. Der Standort Admin kann somit auf vor eingestellte Richtlinien zugreifen, diese aber nicht verändern.

Soll der Standort Admin zusätzlich in der Lage sein, eigene Gruppenrichtlinien zu erstellen, kann der Admin Gruppe dieses Recht zusätzlich delegiert werden. Dies geschieht entweder über die „Group Policy Management“-MMC oder über das zuweisen der Gruppe „Group Policy Creator Owners“. Hier einmal der Weg via MMC:

Bestimmte Berechtigungen müssen nicht ausgewählt werden, die Gruppen werden nur hinzugefügt:

Alternativ können die Gruppen „Standort A Admins“ und „Standort B Admins“ auch als Mitglieder der Gruppe „Group Policy Creator Owners“ eingetragen werden. Beide Wege führen zum gleichen Ziel. Ich persönlich bevorzuge das Eintragen in die Gruppe „Group Policy Creator Owners“ (lässt sich später einfacher auditieren / reporten).

Arbeiten mit delegierten Berechtigungen

Die Standort Administratoren sind nun in der Lage, den eigenen Standort zu verwalten. Sie können Benutzer / Gruppen erstellen und verwalten, sowie Mitgliedschaften der Gruppen ändern und Computer zum Active Directory hinzufügen. Die Standort Admins müsssen und dürfen sich dafür nicht via RDP am Domain Controller anmelden, sondern arbeiten ausschließlich mit den „Remote Server Administration Tools (RSAT)“. Die Tools lassen sich auf Server und Workstations nachinstallieren:

Innerhalb der MMC „Active Directory Benutzer und Computer“, können die Standortadmins alle OUs und Einstellungen lesen, aber nur innerhalb ihres Standorts bearbeiten. Hier einmal das Beispiel für den Benutzer AdminA, welcher nur den Standort A verwalten darf:

Auf anderen OUs hat AdminA keine Berechtigungen und kann somit beispielsweise keine neuen Benutzer erstellen:

Auch kann der Standort Admin keine Benutzer zu Gruppen außerhalb seines Verwaltungsbereich hinzufügen. Hier ein Beispiel wenn AdminA versucht einen Benutzer zur Gruppe „Domain Admin“ hinzuzufügen:

Ähnlich ist es beim Verwalten der Gruppenrichtlinien, hier kann AdminA vorhandene Gruppenrichtlinien mit seinem Standort verknüpfen und eigene Richtlinien erstellen. Andere OUs können nicht verwaltet werden:

Sofern ein Domain Admin bestimmte Grundeinstellungen für alle Standorte vorgeben möchte, können GPOs an die übergeordnete OU angehangen und erzwungen werden. Ein Standort Admin kann diese Einstellungen dann nicht wieder mit eigenen GPOs aufheben:

Bevor ein Standort Admin neue Computer in das Active Directory auf nimmt, müssen die Computer Objekte zuerst in der jeweiligen OU angelegt werden (Pre-Staged):

Ohne das Pre-Staging der Computerkonten, werden neue Rechner zur Standard OU „Computers“ hinzugefügt, diese OU kann der Standort Admin jedoch nicht verwalten. Alternativ können Rechner mit der PowerShell zum AD hinzugefügt werden, mittels des Befehls „Add-Computer“ und dem Parameter „-“ lässt sie die OU direkt mit angeben:

• Add–Computer