Administrative Units in Entra ID: Delegation ohne Mini-Tenants

Administrative Units in Microsoft Entra ID sind eines dieser Features, die auf den ersten Blick erstaunlich langweilig wirken.

Ein Container für Benutzer, Gruppen und Geräte. Ein bisschen Scope für Rollen. Fertig.

In kleinen Tenants kann man das vermutlich auch so sehen. Wenn zwei Admins alles betreuen, alle Benutzer im selben Land sitzen und jeder ohnehin Global Administrator ist, fühlt sich eine Administrative Unit schnell nach unnötiger Strukturpflege an.

In größeren Umgebungen sieht das anders aus.

Sobald ein Tenant mehrere Länder, Tochtergesellschaften, Support-Teams, VIP-Bereiche oder getrennte Betriebsmodelle abbildet, wird die alte Frage wieder unangenehm:

Wie gibst du Admins genug Rechte für ihren Bereich, ohne ihnen den kompletten Tenant in die Hand zu drücken?

Genau dort werden Administrative Units interessant.

Administrative Units sind kein hübscher Ordner

Der wichtigste Punkt zuerst: Eine Administrative Unit ist kein Ordner für Ordnungsliebhaber.

Sie ist ein RBAC-Scope.

Du packst Microsoft-Entra-Objekte in eine Administrative Unit und weist anschließend Rollen mit genau diesem Scope zu. Ein Helpdesk Administrator für AU-DE-Berlin kann dann Benutzer in Berlin verwalten, aber keine Benutzer in Madrid oder New York.

Das klingt simpel, verändert aber die Art, wie man Delegation in Entra ID denkt.

Das ist kein Ersatz für ein sauberes Rollenmodell. Es ist der Teil, der dem Rollenmodell endlich eine organisatorische Grenze gibt.

Ohne Administrative Units hast du oft nur zwei schlechte Optionen:

1. Zu wenig Rechte, dann landet alles beim zentralen Team.
2. Zu viele Rechte, dann kann Local IT plötzlich den halben Tenant anfassen.

Mit Administrative Units kannst du den Mittelweg bauen: lokale Verantwortung, aber mit tenantweiter Leitplanke.

Der typische Use Case: Local IT ohne Tenant-Freiflug

Das naheliegendste Beispiel ist Local IT.

Ein deutsches Support-Team soll deutsche Benutzer betreuen dürfen:

1. Passwort zurücksetzen
2. MFA-Methoden prüfen oder neu registrieren
3. Benutzerattribute korrigieren
4. Gruppenmitgliedschaften für lokale Gruppen verwalten
5. Geräte deaktivieren oder BitLocker Recovery Keys lesen

Dafür braucht dieses Team keine Rechte auf alle Benutzer im Tenant.

Ohne Administrative Units landet man gerne bei Workarounds:

1. Namenskonventionen
2. Support-Prozesse
3. "Bitte nur eure Region anfassen"
4. Audit im Nachgang

Das ist kein Zugriffskonzept. Das ist Vertrauen mit Excel-Beilage.

Administrative Units lösen genau diesen Teil sauberer. Du definierst zuerst den Objektbereich und weist dann Rollen mit diesem Bereich zu.

Ein User Administrator mit AU-Scope bleibt User Administrator, aber nur für die Objekte in dieser AU.

Die Grenzen sind wichtig

Administrative Units begrenzen Management-Rechte.

Sie sind keine Mandantentrennung, kein Datenraum, keine Conditional-Access-Grenze und kein Ersatz für getrennte Tenants.

Microsoft schreibt den Punkt ziemlich klar: Administrative Units wenden Scope nur auf Verwaltungsberechtigungen an. Sie verhindern nicht automatisch, dass Benutzer oder Admins Objekte außerhalb der AU sehen, wenn ihre normalen Benutzerrechte oder ein Dienst das erlauben.

Gerade im Microsoft 365 Admin Center fühlt sich das für scoped Admins oft sauber gefiltert an. In Entra Admin Center, PowerShell, Microsoft Graph oder anderen Diensten sieht die Welt je nach Berechtigung und Feature wieder anders aus.

Das ist wichtig, weil sonst schnell falsche Erwartungen entstehen:

Gerade der Gruppenpunkt ist ein Klassiker.

Wenn du eine Gruppe in eine Administrative Unit packst, darf ein entsprechend berechtigter Admin diese Gruppe verwalten. Das bedeutet aber nicht, dass die Benutzer in dieser Gruppe automatisch auch in der Administrative Unit liegen.

Das fühlt sich im ersten Moment unlogisch an, ist technisch aber konsequent.

Die AU enthält die Gruppe als Objekt. Nicht die aus der Gruppe abgeleitete Personenmenge.

Wenn ein Helpdesk Admin die Eigenschaften eines Benutzers verwalten soll, muss dieser Benutzer selbst Mitglied der Administrative Unit sein.

Dynamische Administrative Units klingen besser, als sie manchmal sind

Administrative Units lassen sich manuell befüllen oder dynamisch über Regeln.

Für größere Umgebungen ist dynamisch fast immer der spannendere Ansatz:

(user.country -eq "Germany")

oder für Geräte:

(deviceOSType -eq "Windows")

Damit kann man regionale oder technische Scopes automatisch pflegen, solange die Attribute sauber sind.

Und genau dort kommt der praktische Haken.

Eine dynamische Administrative Unit ist nur so gut wie die Daten, auf denen sie basiert. Wenn country, department, usageLocation, extensionAttribute oder Geräteeigenschaften inkonsistent gepflegt werden, baust du dir keinen sauberen Scope. Du baust dir ein Berechtigungsmodell auf Stammdatenqualität.

Das kann funktionieren. Aber dann muss jemand diese Daten als Sicherheitsinput behandeln.

Zusätzlich gibt es ein paar harte Einschränkungen:

1. Dynamische AUs unterstützen Benutzer oder Geräte, aber nicht beides gleichzeitig.
2. Dynamische AUs für Gruppen werden nicht unterstützt.
3. Wenn eine AU dynamisch ist, verwaltet die Regel die Mitgliedschaft.
4. Für dynamische Benutzer-AUs brauchst du genug Entra ID P1 Lizenzen für die eindeutigen Benutzer, die darüber Mitglied werden.

Für Geräte sieht die Lizenzlage entspannter aus: Für Geräte, die über eine dynamische Geräte-AU Mitglied werden, verlangt Microsoft laut Dokumentation keine Lizenz pro Gerät.

Der Intune-Irrtum

Viele lesen "Devices können Mitglied einer Administrative Unit sein" und denken direkt an Intune Delegation.

Leider nein.

Administrative Units können im Entra-Kontext mit Geräten arbeiten. Zum Beispiel kann ein scoped Admin Geräte deaktivieren, löschen oder BitLocker Recovery Keys lesen, wenn die passende Rolle und der passende Scope vorhanden sind.

Intune-Gerätemanagement ist damit aber nicht sauber nach Administrative Units scoped.

Das heißt praktisch:

Wenn du Local IT Germany erlauben willst, Windows-Geräte in Intune für Deutschland zu verwalten, dann bist du weiter bei Intune RBAC, Scope Groups, Scope Tags und sauberer Zuweisungslogik. Administrative Units lösen diesen Teil nicht.

Das ist vermutlich der Punkt, an dem viele beim ersten Design einmal falsch abbiegen.

Administrative Units sitzen in Entra RBAC. Intune bringt sein eigenes RBAC-Modell mit. Beide Welten berühren sich an Geräten, aber sie verschmelzen nicht zu einem gemeinsamen Delegationsmodell.

Schade, aber man muss es wissen.

Restricted Management Administrative Units sind eine andere Liga

Normale Administrative Units begrenzen, was ein scoped Admin tun darf.

Restricted Management Administrative Units drehen den Schutz deutlich schärfer.

Bei einer Restricted AU dürfen nur Admins mit expliziter Rollenzuweisung auf genau diese Restricted AU die Microsoft-Entra-Eigenschaften der enthaltenen Objekte ändern. Tenantweite Admin-Rollen reichen dafür nicht mehr aus.

Sogar ein Global Administrator mit Tenant-Scope kann ein Objekt in einer Restricted AU nicht einfach ändern, solange er sich nicht explizit auf diese AU scoped.

Das klingt erstmal absurd, ist aber genau der Sinn.

Du nutzt Restricted AUs nicht für normale Delegation. Du nutzt sie für Objekte, bei denen normale tenantweite Admin-Rechte zu breit sind.

Typische Beispiele:

1. CEO- und Executive-Accounts
2. Break-Glass-nahe Support-Objekte
3. sensible Sicherheitsgruppen
4. regionale Objekte mit harten Compliance-Anforderungen
5. Geräte bestimmter besonders schutzwürdiger Personen

Der beste Use Case ist aus meiner Sicht nicht "wir machen alles sicherer", sondern sehr konkret:

Bestimmte Objekte dürfen nicht mehr vom normalen Helpdesk oder von tenantweiten Gruppenadmins verändert werden.

Genau dafür sind Restricted AUs stark.

Restricted AUs brechen dir auch Workflows

Die scharfe Variante hat ihren Preis.

Microsoft weist in der Dokumentation selbst darauf hin, dass bestehende Workflows brechen können, wenn du Objekte in eine Restricted Management Administrative Unit legst.

Das ist keine kleine Fußnote.

Wenn irgendein Prozess bisher mit tenantweiten Rollen, Graph Application Permissions oder gruppenbasierten Besitzern gearbeitet hat, kann dieser Prozess plötzlich gegen die Wand laufen.

Ein paar Beispiele:

1. Ein Helpdesk Admin kann das Passwort eines Executive Accounts nicht mehr zurücksetzen.
2. Ein Groups Administrator kann eine sensitive Security Group nicht mehr bearbeiten.
3. Eine App mit Graph Application Permissions darf Objekte in Restricted AUs nicht automatisch verändern.
4. Group Owner können Gruppen in Restricted AUs nicht wie gewohnt verwalten.
5. Bestimmte Entra ID Governance Funktionen greifen für Benutzer oder Gruppen in Restricted AUs nicht wie erwartet.

Dazu kommt: Den Restricted-Status setzt du beim Erstellen der AU. Danach kannst du ihn nicht einfach an- oder ausschalten.

Das ist also kein Toggle für "machen wir mal kurz sicherer".

Restricted AUs brauchen einen echten Plan.

Ein sinnvolles Modell für Enterprise-Tenants

Ich würde Administrative Units in großen Tenants in zwei Kategorien denken.

Kategorie A: Normale Administrative Units für Delegation

Diese AUs bilden operative Verantwortung ab:

1. Land
2. Region
3. Business Unit
4. Schule oder Fakultät
5. Tochtergesellschaft
6. separater Support-Bereich

Hier geht es um Skalierung.

Local IT soll lokale Aufgaben erledigen können, ohne dass das zentrale Identity-Team jeden Passwort-Reset und jede Benutzerkorrektur anfassen muss.

Ein mögliches Modell:

AU-DE-All
AU-DE-Berlin
AU-DE-Munich
AU-FR-All
AU-UK-All
AU-Exec-Support

Wichtig: Administrative Units lassen sich nicht verschachteln.

AU-DE-Berlin ist also nicht automatisch Teil von AU-DE-All. Wenn du beide Scopes brauchst, musst du die Mitgliedschaft bewusst modellieren, zum Beispiel über dynamische Regeln oder Automation.

Kategorie B: Restricted AUs für Schutzobjekte

Diese AUs bilden keine normale Organisation ab, sondern Schutzbedarf.

Zum Beispiel:

RAU-Executive-Accounts
RAU-Tier0-Security-Groups
RAU-BreakGlass-Adjacent
RAU-Regulated-Objects-DE

Hier geht es nicht darum, Local IT produktiver zu machen.

Hier geht es darum, dass bestimmte Objekte nicht mehr beiläufig von zu breit berechtigten Admins verändert werden können.

Der Unterschied ist wichtig, weil sonst jedes zweite Objekt in einer Restricted AU landet und du dir den Betrieb selbst verbaust.

Mein pragmatischer Aufbau

Wenn ich Administrative Units in einem bestehenden Enterprise Tenant einführen müsste, würde ich nicht mit dem Portal anfangen.

Ich würde zuerst diese Fragen beantworten:

1. Welche Aufgaben sollen delegiert werden?
2. Welche Objekte gehören fachlich in den Scope?
3. Welche Attribute bestimmen die Mitgliedschaft?
4. Welche Rollen reichen aus?
5. Welche Teams dürfen den Scope administrieren?
6. Welche Prozesse laufen heute mit tenantweiten Rechten?
7. Welche Objekte brauchen Restricted Schutz statt normaler Delegation?

Danach erst kommt die technische Umsetzung.

Ein sauberer erster Pilot wäre zum Beispiel:

1. Eine normale AU für ein Land oder eine Business Unit.
2. Benutzer dynamisch über ein stabiles Attribut aufnehmen.
3. Eine kleine Helpdesk-Rolle mit AU-Scope zuweisen.
4. Testen, welche Aktionen im Microsoft 365 Admin Center, Entra Admin Center und per PowerShell wirklich funktionieren.
5. Audit Logs prüfen.
6. Erst danach weitere Rollen oder Regionen ausrollen.

Für Restricted AUs würde ich noch vorsichtiger starten:

1. Keine produktiven VIPs im ersten Test.
2. Separates Testobjekt mit vergleichbaren Eigenschaften.
3. Alle beteiligten Prozesse prüfen: Helpdesk, Automation, Lifecycle, Group Management, App Permissions.
4. Break-Fix-Prozess dokumentieren.
5. Erst danach echte Schutzobjekte aufnehmen.

Restricted AUs sind stark, aber sie verzeihen schlechte Betriebsprozesse nicht.

Lizenzthema kurz und schmerzarm

Normale Administrative Units kannst du mit Entra ID Free erstellen.

Sobald du aber Admins mit Rollen über den Scope einer Administrative Unit ausstattest, braucht jeder dieser AU-Admins Entra ID P1.

Für normale manuell gepflegte AU-Mitglieder reicht laut Microsoft Entra ID Free. Bei dynamischen Administrative Units brauchen die Benutzer, die über dynamische Regeln Mitglied werden, eine passende P1-Abdeckung. Für dynamische Geräte-AUs fällt laut Microsoft keine Lizenz pro Gerät an.

Restricted Management Administrative Units brauchen ebenfalls Entra ID P1 für die AU-Admins.

Das ist kein exotisches Lizenzmonster, aber du solltest es vor dem Rollout prüfen. Gerade dynamische Benutzer-AUs können sonst plötzlich eine Lizenzdiskussion auslösen.

Fazit

Administrative Units sind eines dieser Features, die man leicht unterschätzt, weil sie nicht spektakulär aussehen.

In der Praxis lösen sie aber ein echtes Enterprise-Problem: Delegation im gemeinsamen Tenant.

Sie helfen dir, lokale oder fachliche Admin-Rechte sauberer zu schneiden, ohne für jede Region eigene Tenants oder wackelige Prozessabsprachen zu bauen.

Die Grenzen muss man ernst nehmen. AUs sind kein Daten-Isolationsmodell. Sie verschachteln sich nicht. Gruppenmitglieder werden nicht automatisch Teil des Scopes. Intune-Gerätemanagement spielt nicht sauber mit. Dynamische Regeln stehen und fallen mit deinen Attributen.

Restricted Management Administrative Units sind dann die schärfere Variante für sensible Objekte. Sehr nützlich, aber definitiv nichts für einen spontanen Freitagabend-Rollout.

Mein persönlicher Take:

Für globale Entra-Tenants gehören normale Administrative Units in jedes ernsthafte Delegationsmodell. Restricted AUs gehören in die Werkzeugkiste für Schutzobjekte, aber mit deutlich mehr Respekt.

Weitere Informationen:

• Microsoft Learn: Administrative units in Microsoft Entra ID
• Microsoft Learn: Dynamic membership rules for administrative units
• Microsoft Learn: Restricted management administrative units