Some readers of this blog have requested an article on delegating admin authorizations. Most of the requests revolve around the fact that certain administrative activities, such as creating user accounts or resetting passwords, should be carried out by users. Of course, these users should not have Domain Admin authorizations, but only the authorizations required for their activities. Requests often revolve around how the administration of entire sites, including group policies, can be delegated to other administrators without them having to be members of the Domain Admins group.
This article is about delegating the management of entire company sites to different administrators. In order for permissions to be delegated within the Active Directory, a structure of the company's organizational units is first required. A corresponding structure cannot be rigidly defined, but should ideally be based on the requirements and organization of the company. Personally, I find it easiest to start with a simple and flat structure and then expand or change the OU structure depending on requirements. Much more important than directly creating an OU structure that is perfectly tailored to the company is the Active Directory security to consider and implement right from the start.
Delegate authorizations
For this example, let's assume a company with two locations (location A and B). The two locations are to be managed by different admins. A site admin should only be able to create and manage users/groups for his site, add computers to the Active Directory and create group policies for the computers. However, as the domain admin, you want to retain control over the authorizations and be able to specify certain basic settings.
A very flat OU structure of the company could therefore look something like this:
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“:
The next step is to select the authorizations that the site administrators should receive. In this example, the site admins are given the following authorizations, which means that the site admins can create and delete users and groups independently, for example:
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:
The wizard is now complete and the same procedure can be followed for other OUs:
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:
The next step is to select the objects that the site admin is allowed to manage, in this example computers and contacts:
The rights for the previously selected objects are then defined in the last step:
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:
Certain authorizations do not have to be selected, the groups are only added:
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).
Working with delegated authorizations
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:
AdminA has no authorizations on other OUs and therefore cannot create new users, for example:
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:
Similarly, when managing group policies, AdminA can link existing group policies to its location and create its own policies. Other OUs cannot be managed:
If a Domain Admin wants to specify certain basic settings for all locations, GPOs can be attached to the higher-level OU and enforced. A site admin cannot then override these settings with their own GPOs:
Before a site admin adds new computers to the Active Directory, the computer objects must first be created in the respective OU (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: