Jeder soll die Berechtigungen für den Zeitraum erhalten, um die richtigen Aufgaben ausführen zu können, die der Job erfordert – nicht mehr und nicht weniger. Um den richtigen Zugriff für die richtigen Leute zum passenden Zeitpunkt besser steuern zu können, existieren Delegationsmodelle in allen ausgereiften IT-Systemen und Cloudanwendungen. Für die Risikominimierung nutzen Admins bereits feiner herausgeschnittene Rollen und selten den Über-Admin, der als Startbenutzer bei der Neuinstallation oder der Ersteinrichtung angelegt wird.

Entra ID kennt dabei einige Standardrollen, die für Enterprise-Zwecke oft zu weitläufig, zumindest aber besser auf verschiedene Aufgabenfelder heruntergebrochen sind – wie etwa den "User Admin", "Helpdesk Administrator" oder "Windows 365 Administrator". Die Rollen sind zumeist für das gesamte Entra oder einen Großteil eines anderen M365-Services zugeschnitten. Wer "Group Administrator" ist, darf alle Gruppen im Mandanten verwalten. Die existierenden Rollen sind im Entra Portal in "Entra ID" – "Roles & Admins" – "All roles" zu sehen.

Passen die Built-in-Rollen für die ersten Schritte, können Sie diese zusätzlich in Privileged Identity Management (PIM) aktivieren, um permanenten Zugriff auf die Rolle zu minimieren und die Aktivierung an Zeitgrenzen, MFA oder Vier-Augen-Prinzip zu binden. PIM ist eine Funktion, die eine Entra-ID-P2 oder Microsoft-M365-E5-Lizenz erfordert. Im Entra-Portal in "ID Governance" – "Privileged Identity Management" wählen Sie "Microsoft Entra Roles / Assign Eligibility". In der Übersicht aller Rollen selektieren Sie nun die Rolle, für die Sie neue Rollenzuweisungen konfigurieren wollen.

PIM unterscheidet zwischen "Eligible Assignments" für Rolleninhaber, die eine Rolle bei Bedarf aktivieren dürfen, und "Active Assignments" für ständige Rolleninhaber, die ständig mit den jeweiligen Rollenberechtigungen unterwegs sind. Die Zuweisungen zu Eligible und Active bestimmen Sie via "+ Add assignments". In "Membership" konfigurieren Sie neue Rolleninhaber, die entweder aus einzelnen Benutzern oder Gruppen und deren Mitgliedern bestehen können. Im zweiten Reiter namens "Setting" schalten Sie zwischen "Eligible"- und "Active"-Assignment um, und definieren, ob die Rollenzuweisung permanent oder zeitlich gebunden und mit einem Ablaufdatum versehen ist.

Für jede Rolle sind via "Settings" Anpassungen möglich, die die Aktivierung der Rolle, eine Multifaktor-Authentifizierung (MFA) und Benachrichtigungen betreffen. Hier definieren Sie auch, wie lange eine aktivierte Rolle genutzt werden darf, ob MFA oder eine Business Justification erforderlich ist und wer die Genehmiger der Aktivierung sind.

Für die weitere Verringerung des "Blast Radius" erlaubt Entra ID das Definieren eigener Rollen. Selbst wenn der "User Administrator" schon weniger Schaden anrichtet als der „Global Admin“, mag das Ändern und potenzielle Löschen von Benutzerkonten weiterhin deutlich zu großzügig möglich sein. Nahezu alle Aktionen auf den gängigsten Entra-ID-Objekten sind als Berechtigungen definiert.

So bezeichnet "microsoft.directory/applications/credentials/update" die Berechtigung, auf Applikationsobjekten die Anmeldeoptionen zu aktualisieren. Der Be- rechtigungsname enthält alle wichtigen Details für eine erfolgreiche Suche – das letzte Segment trägt die Aktion, die auf dem Objekt berechtigt werden soll: "add", "remove" oder "update". Durch die Definition eigener Rollen mit zugeschnittenen Berechtigungen erhalten die entsprechenden Mitarbeiter exakte Befugnisse für ihre Anwendungsfälle und laufen somit nicht Gefahr, ungewollte Aktionen auszuführen.

Neue Rollen definieren Sie im Entra Portal unter "Entra ID / Roles & admins / All roles". Die Übersicht zeigt alle in Entra ID definierten Rollen – von Microsoft vordefinierte sind als Typ "Built-in" geführt, neu erstellte tauchen als "Custom" auf. Für alle Rollen führt Microsoft im Falle hochprivilegierter Berechtigungen die Plakette "Privileged". Außerdem ist die Anzahl der Rollenzuweisungen zu Benutzern und Computern zu sehen. Mit "+ New custom roles" starten Sie den Miniprozess für die Rollenerstellung: Name und Beschreibung sollten den Anwendungsfall und die erteilten Berechtigungen widerspiegeln, damit die neue Rolle sowohl in der Übersicht, als auch in PIM entsprechend konfiguriert und geschützt werden kann.

Im Schritt "Permissions" suchen Sie aus der langen Liste der bekannten Berechtigungen in Entra die Berechtigungen aus, die Sie für die neue Rolle benötigen. Für eine Beispielkonfiguration erstellen wir eine Rolle, die eine grundlegende Administration für bestehende Gruppen übernehmen darf, aber weder neue Gruppen erstellen noch bestehende löschen darf. Mitgliedschaften verändern ist ebenfalls tabu. Für die Berechtigungen wählen wir:

- "microsoft.directory/groups/ basic/update",

- "/groups/members/read",

- "/groups/owners/read" und

- "/groups/standard/read".

Neben zusätzlichen Rollen, die einen kleineren Einflussbereich durch das Einschränken der Berechtigungen verringern, ist für komplexere Szenarien auch die Reduktion des Anwendungsbereichs notwendig. Selbst wenn "User Administrator" die Berechtigungen auf Benutzerobjekte einschränkt, umfasst der potentielle Schadensbereich weiterhin alle Benutzerkonten in Entra ID. Sollen Helpdesk-Mitarbeiter oder delegierte Admin-Kollegen nur einen Teil der Benutzerkonten, gemäß ihres Einflussbereiches verwalten können, müssen Sie den Scope anpassen. Entra kennt dafür "Administrative Units" (AU).

Die Idee ist dabei: In einer AdminUnit sind Objekte zusammengefasst, die in einen logischen Verwaltungsbereich gehören. Für die Objekte in diesem Verwaltungsbereich lassen sich dann Berechtigungen an Mitarbeiter delegieren, die exklusiv für die AdminUnit gelten. Das AdminUnit-Konzept ist dabei nicht zu verwechseln mit den "Organizational Units" (OUs) aus dem Active Directory (AD). Während Sie beide Konzepte für das Delegieren von Berechtigungen nutzen, sind AUs deutlich agiler: Ein Objekt wird in mehreren AUs logisch vertreten sein und AUs werden mit einem Filter definiert, dessen Scope die Objekte im Verwaltungsbereich definiert. So kann ein Benutzerkonto sowohl in der AU "Employees in Munich" und in der AU "Employees with Strong Credentials" gleichzeitig im Scope sein – und von unterschiedlichen Teams verwaltet werden. Wer also ein Delegationskonzept mit AUs erstellen möchte, kann nicht alle Ideen dem OU-Konzept aus dem Windows-AD entleihen, sondern kann freier und flexibler planen.

Mit der AU definieren Admins, wer welche Berechtigungen auf welchem Scope erhält. Die möglichen Berechtigungen sind alle Rollen, die im Entra-Tenant konfiguriert sind; sowohl Built-in-Rollen wie "Groups Administrator", aber auch selbsterstellte Rollen sind möglich. Mit den Rollen werden Benutzer und Gruppen zugewiesen, die auf die Mitarbeiter im Scope Zugriff erlangen sollen.

Der "Scope" der AdminUnit ist entweder fest bestimmt oder über eine dynamische Regel definiert. Wer den Scope fest bestimmt, selektiert nach der AU-Erstellung einzeln die Benutzer, Gruppen oder Geräte, die im Wirkungsbereich der AU liegen sollen. Für eine dynamische Berechnung definieren Sie einen Filter, ähnlich dem für dynamische Gruppen, mit dem Sie beschreiben, wie der Scope aussehen soll – etwa "Alle Benutzer am Standort Wien" oder "Mitarbeiter mit einem gewissen Jobtitel", "Geräte eines bestimmten Modelltyps" oder "Geräte mit einem bestimmten Betriebssystem" sind möglich – inklusive der Filterung nach Werten in den "extensionAttributes". Der Scope wird dabei vom System im Hintergrund stets neu berechnet, sodass Attributänderungen flexibel den Wirkungsbereich bestimmen können.

Für ein einfaches Beispiel wollen wir Mitarbeiter in eine AU bringen, die in Wien arbeiten, um dann Helpdesk-Berechtigungen an das IT-Team in Wien zu delegieren. Die dortigen Verantwortlichen sollen dabei nur die anässigen Kollegen verwalten dürfen. Im Schritt "Assign Roles" wählen Sie "User Administrator" aus und wählen die Mitglieder des Wiener IT-Teams aus. Ihnen wird dann das Recht zugesprochen. Sollen weitere Rollenzuweisungen geschehen, können Sie diese gleich im selben Dialog durchführen.

Nachdem die AU erstellt wurde, editieren Sie diese im Entra-Portal und fügen Mitglieder als Scope hinzu. In "Properties" wählen Sie für "Membership type" nun "Dynamic User" aus – wonach eine neue Option, "Add dynamic query" erscheint. Den dynamischen Filterausdruck bauen Sie mit dem Editor zusammen. Als Attribut wählen Sie "city", als Operator "equals", mit dem Value "Vienna". Das Regelfeld übersetzt die Regel in "(user.city -eq "Vienna")", was auch dem entspricht, was im System abgelegt und via Graph-API gelesen und geschrieben wird. Sie können den Regeleditor auch dazu benutzen, den gewünschten Filter zu erstellen und die Übersetzung dann in Graph API oder der Automation zu nutzen.

Erstellen Sie eine AU und delegieren darauf für die Helpdesk-Mitarbeiter "User Administrator"-Berechtigungen, dann klappt das natürlich – aber die Tenant-weiten User-Admins können ebenfalls AU-Objekte administrieren. Möchten Sie die Tenant-weiten Admin-Rollen von der Administration der AU ausschließen, sind "Restricted Management Administrative Units" (RMAUs) der Schlüssel. Diese sind eine Erweiterung der AUs für komplexere Szenarien. Sie kommen zum Einsatz, wenn Berechtigungen auf Zielobjekten im Scope exklusiv anzuwenden sind, um andere Admins wie "User Administrator" oder "Global Administrator" mit Tenant-weiten Berechtigungen auszuschließen.

Das ist vor allem dann interessant, wenn andere Admins sensitive Benutzer, Gruppen, Computer oder Service Principals für Anwendungen nicht administrieren können sollen, wie etwa Gruppen zur Fallbearbeitung in Purview, Zugriff auf kritische HR-Anwendungen oder Label-Berechtigungen für Verschlüsselung – also da, wo Gewaltenteilung sinnvoll ist.

Global Admins bilden eine schwierige Ausnahme: Auch wenn Sie Global Admins zwar formell durch RMAUs ausschließen, können sich diese per Rekonfiguration der Berechtigungen direkt auf der RMAU Zugang zu den Zielobjekten verschaffen. Das wiederum taucht aber wieder im Audit-Trail auf, weshalb Objekte, die besonderen Schutz durch RMAUs benötigen, auch aktiv ins Monitoring gehören. Einschränkend muss zudem erwähnt werden, dass das "Restricted Management" auf einer AU zum Erstellzeitpunkt der AU zu konfigurieren ist. Eine bestehende AU lässt sich nicht nachträglich umkonfigurieren. In unserem Beispiel möchten wir Gruppen von ungewollten Änderungen abschirmen. Die Gruppen definieren Complianceeinstellungen in Purview, die nicht von allen Administratoren geändert werden sollen.

Die Automatisierung von AUs und Custom Roles ist über den Microsoft Graph möglich. Für Testzwecke und zum Kennenlernen des Schemas eignet sich der Graph Explorer [1].

Als Admin mit ausreichenden Berechtigungen untersuchen Sie eine Übersicht der AUs, indem Sie folgende Anfrage nutzen:

Die erforderlichen OAuth-Berechtigungen für die Anfrage sind mindestens "AdministrativeUnit.Read.All". Wenn Sie Objekte zu AUs hinzufügen möchten, sind weitere Berechtigungen erforderlich: "AdministrativeUnit.ReadWrite.All", "Directory.Read.All" sowie "Directory.ReadWrite.All" zusätzlich zu administrativen Rollenberechtigungen.

Im "Response Preview"-Feld sehen Sie dann eine lange Liste der AUs des Tenants. Mit der jeweiligen "id" der Admin Units können Sie Lese- sowie Schreiboperationen auf der richtigen AU durchführen:

Um eine existierende AU anzupassen und einen Filter für dynamische Mitgliedschaft zu definieren, nutzen Sie die PATCH-Funktion auf dem Objekt, und ändern die drei Attribute in "Request Body":

Eine Übersicht aller Restricted Management Administrative Units erhalten Sie, wenn Sie den Graphen nach "isMemberManagementRestricted" filtern lassen. Zudem können Sie den Attributsatz der Antwort verringern:

Das Erstellen einer eigenen Rolle besteht aus deren Namen und Beschreibung sowie der Liste an zugehörigen Berechtigungen. Das Neuerstellen funktioniert über die POST-Funktion, die Details, wie etwa die Rollenliste, sind etwas verschachtelt, aber gut strukturiert:

Im mehrwertigen Feld "allowedResourceActions" listen Sie alle Berechtigungen auf, die den Rolleninhabern zur Verfügung stehen sollten. Oft gilt: weniger ist mehr. Wenn Sie große Blöcke von Berechtigungen bearbeiten wollen, lohnt es sich möglicherweise, die Nur-Lese- von den Schreibberechtigungen zu trennen.

Um die beiden Konzepte jetzt zu verheiraten, existiert ein dritter Objekttyp: "RoleAssignments". Diese Objekte definieren in Entra, wer (Benutzer oder Gruppen) mit welchen Berechtigungen (die in der Rolle definiert sind) welchen Scope (ganz Entra oder eine AU) verwalten dürfen. Alle drei Objekte, Security Principal, Scope und Rollendefinition, sind über ihre eindeutige Objekt-ID oder eine im Falle des Scopes in einer Pfadangabe mit dem Graph zu nutzen:

In unserem Beispiel erhält die Gruppe, deren Objekt-ID in "principalId" definiert ist, die Rollenmitgliedschaft für die im vorherigen Beispiel erstellte eigene Rolle zur Erstellung und Lösung von Benutzerkonten (definiert durch "roleDefinitionId"). Der Scope der Berechtigung ist dabei die AU mit der ID "ef0e5a4f-dcd5-47f4-b749-066dff7afcc7". Die Objekt-IDs sind entweder im Feld "ID" über eine Graph-Abfrage oder im Entra-Portal in der Objektübersicht auf dem Tab "Properties" auszulesen. Soll der Scope keine AU sein, sondern eine Rollenmitgliedschaft für ganz Entra nutzen, tragen Sie "/" ins Feld ein.

Rollenberechtigungen wirken auch auf Applikationsobjekte in Entra – wollen Sie den Scope dafür delegieren, nutzen Sie die Objekt-ID der Applikationen in Entra ID. Für jede neue Rollenzuweisung definieren Sie ein neues RoleAssignments-Objekt, das "wer, mit welchen Berechtigungen, worauf?" festlegt. So lesen Sie auch zentral alle Rollenberechtigungen mit dem Graph-API aus – die Objekt-IDs können Sie dann mit weiteren Graph-Anfragen aufschlüsseln und in Klarnamen wie Benutzer oder Gruppennamen, sowie AU-Bezeichnungen übersetzen lassen.

Als Basis für ein gutes Berechtigungsmodell dient Privileged Identity Management, das mit einer Premium 2- oder E5-Lizenz zwar nicht günstig ist, aber gerade für privilegierte Konten deutliche Sicherheitsmehrwerte schafft. Die Konzepte zur Verringerung des administrativen Risikos ergänzen sich dann gut: Mit Administrative Units schneiden Sie dezentralen Teams, Länderorganisationen oder Abteilungen eigene Bereiche zur Selbstverwaltung von Benutzer-, Computer- oder gar Service Principalobjekten heraus, mit selbstdefinierten Rollen reduzieren Sie die breit gefassten Standardrollen auf die wesentlichen, relevanten Aktionen, die zu ihrem Delegationsmodell passen. Die Konfiguration der Komponenten und die Strategie, mit der delegiert wird, sollte jedoch an zentraler Stelle erfolgen – denn ein Delegationsmodell, um das Delegationsmodell zu verwalten, gibt es leider noch nicht.