Administrative Units in Entra ID sinnvoll nutzen
Adminrechte sauber delegieren – per Scope statt per VertrauenAdministrative Units sinnvoll nutzen – Delegation ohne Chaos
Administrative Units sind das Werkzeug gegen den Reflex „dann mach ihn halt zum User Administrator". Eine Administrative Unit (AU) zieht eine Grenze um einen Teil deines Tenants – einen Standort, eine Tochtergesellschaft, eine Abteilung – und erlaubt es, Adminrechte nur innerhalb dieser Grenze zu vergeben. Der Helpdesk in Werk Süd setzt Passwörter in Werk Süd zurück, sieht aber Werk Nord nicht einmal. Das ist gelebtes Least Privilege – ohne dafür ein zweites Tenant aufzumachen.
Skizze 1: AUs unterteilen den Tenant in verwaltbare Einheiten; gescopte Admins arbeiten nur in ihrer eigenen Einheit.
|
Info – was eine AU ist (und was nicht) Eine Administrative Unit ist ein Container für Benutzer, Gruppen und Geräte, kombiniert mit der Möglichkeit, eine Adminrolle auf genau diesen Container zu beschränken (scoped role assignment). Wichtig: Eine AU ist keine Organisationseinheit (OU) aus dem klassischen AD und keine Sicherheitsgrenze für Daten – sie segmentiert die Verwaltung, nicht den Zugriff auf Ressourcen. Lizenz: Zugewiesene AUs gibt es ab Entra ID P1. Dynamische AUs (Mitgliedschaft per Attribut-Regel) brauchen P1 für jedes Mitglied der AU – das ist die übliche Kostenfalle bei großen dynamischen Einheiten. |
|---|
Das Problem: Adminrechte kennen keine Grenzen
Standard-Entra-Rollen gelten tenant-weit. Machst du jemanden zum User Administrator, darf er die Passwörter aller Benutzer zurücksetzen – des Praktikanten genauso wie des Geschäftsführers. In einem Konzern mit mehreren Standorten oder Tochterfirmen ist das selten gewollt. Der lokale IT-Mensch in Hamburg soll Hamburg verwalten, nicht den Vorstand in München.
Vor AUs gab es dafür nur hässliche Workarounds: separate Tenants (teuer, Sync-Hölle), Verzicht auf Delegation (alles läuft über das zentrale Team, das zum Flaschenhals wird) oder zu großzügige Rollen (Risiko). AUs lösen das sauber: Rolle plus Geltungsbereich statt Rolle für alles.
Skizze 2: Ein AU-gescopeter User Administrator verwaltet seine Einheit vollständig – und sieht von tenant-weiten Dingen nichts.
|
Achtung – AUs sind keine Datengrenze Der häufigste Denkfehler: „Ich packe die Geschäftsführung in eine eigene AU, dann kommt der normale Admin nicht mehr ran." Das stimmt nur für AU-gescopte Admins. Ein tenant-weiter Global Administrator oder User Administrator ignoriert AU-Grenzen komplett – die gelten ausschließlich für Rollen, die explizit auf die AU beschränkt wurden. Wer sensible Konten wirklich schützen will, braucht zusätzlich Restricted Management AUs und vor allem weniger tenant-weite Admins (siehe PIM). |
|---|
Zugewiesen oder dynamisch – die Mitgliedschaftsfrage
AUs füllen sich auf zwei Wegen. Die Wahl entscheidet über Pflegeaufwand und Lizenzkosten.
|
Typ |
Mitgliedschaft |
Stärken / Schwächen |
|---|---|---|
|
Zugewiesen |
Du fügst Benutzer/Gruppen/Geräte manuell hinzu. |
Volle Kontrolle, P1 reicht für die AU. Aber: Pflege per Hand, veraltet schnell. |
|
Dynamisch |
Regel über Attribute (z. B. department, jobTitle, city). |
Pflegt sich selbst, ideal für Standort/Abteilung. Aber: P1 pro Mitglied, Regel muss sauber sein. |
|
Restricted Mgmt |
Wie oben, plus Schutz vor tenant-weiten Admins. |
Schützt VIP-/Dienstkonten auch vor globalen Rollen. Mit Bedacht einsetzen. |
Skizze 3: Stabil und manuell abgegrenzt? Zugewiesene AU. Ändert sich Zugehörigkeit über ein Attribut? Dynamische AU.
|
Praxis-Tipp – dynamisch nur mit sauberen Attributen Eine dynamische AU ist nur so gut wie das Attribut, auf dem sie fußt. Wenn euer „department"-Feld bei der Hälfte der Leute leer oder „Diverses" ist, baust du eine AU, die ständig die falschen Leute ein- und aussortiert. Erst die HR-Datenqualität fixen (am besten direkt aus dem HR-System per Inbound Provisioning), dann dynamische AUs darauf aufsetzen. Sonst delegierst du Chaos statt Ordnung. |
|---|
Umsetzung mit PowerShell (Microsoft Graph)
Eine AU anlegen, einen Benutzer hinzufügen und einer Person die Rolle „User Administrator" nur für diese AU geben – die drei typischen Schritte:
|
Connect-MgGraph -Scopes "AdministrativeUnit.ReadWrite.All",` "RoleManagement.ReadWrite.Directory"
# 1) AU anlegen $au = New-MgDirectoryAdministrativeUnit -DisplayName 'Werk Sued' ` -Description 'Standort Sued – lokale Verwaltung'
# 2) Benutzer als Mitglied hinzufuegen $ref = @{ '@odata.id' = "https://graph.microsoft.com/v1.0/users/$userId" } New-MgDirectoryAdministrativeUnitMemberByRef ` -AdministrativeUnitId $au.Id -BodyParameter $ref
# 3) Rolle NUR auf diese AU scopen $role = Get-MgRoleManagementDirectoryRoleDefinition ` -Filter "displayName eq 'User Administrator'" $assign = @{ principalId = $helpdeskUserId roleDefinitionId = $role.Id directoryScopeId = "/administrativeUnits/$($au.Id)" # <- der Scope } New-MgRoleManagementDirectoryRoleAssignment -BodyParameter $assign |
|---|
Der ganze Zauber steckt im directoryScopeId. Steht da /, gilt die Rolle tenant-weit; steht da /administrativeUnits/<id>, ist sie auf die AU begrenzt. Genau diese eine Zeile ist der Unterschied zwischen Least Privilege und Vollmacht.
Beispiel aus der Praxis
Die Sparfuchs & Partner Steuerberatungs GmbH ist klein, aber auf drei Standorte verteilt, und jeder Standort hat eine Bürokraft, die sich „um den Computerkram kümmert". Bisher liefen alle Passwort-Resets über den externen IT-Dienstleister – jeder Reset eine Mail, ein Ticket, eine Stunde Wartezeit. Den drei Bürokräften einfach User Administrator zu geben, kam nicht infrage: Dann hätte die Bürokraft in Standort A die Passwörter der Partner in Standort C zurücksetzen können.
Die Lösung mit Augenmaß und knappem Budget: Drei zugewiesene AUs, eine pro Standort, kein dynamisches Attribut-Gedöns (bei 30 Leuten lohnt der Pflegeaufwand nicht). Jede Bürokraft bekam User Administrator, gescopt auf ihre AU. Resultat: Passwort-Resets passieren jetzt in zwei Minuten vor Ort, der teure Dienstleister wird nur noch für echte Probleme gerufen, und die Partner-Konten bleiben für die Bürokräfte unsichtbar. P1-Lizenzen waren ohnehin vorhanden – Mehrkosten null.
Verwandte Artikel
Häufige Fragen (FAQ)
Frage: Sind Administrative Units dasselbe wie OUs aus dem alten Active Directory?
Antwort: Nein, auch wenn die Idee verwandt ist. OUs im klassischen AD strukturieren das Verzeichnis und hängen Gruppenrichtlinien an. AUs in Entra ID segmentieren ausschließlich die Verwaltung: Sie erlauben es, eine Adminrolle auf einen Ausschnitt des Tenants zu beschränken. Sie sind keine GPO-Träger und keine Datengrenze.
Frage: Welche Lizenz brauche ich für Administrative Units?
Antwort: Zugewiesene AUs funktionieren ab Entra ID P1. Dynamische AUs, deren Mitgliedschaft über eine Attribut-Regel gefüllt wird, brauchen P1 für jedes einzelne Mitglied der AU. Bei großen dynamischen Einheiten kann das spürbar ins Geld gehen – das vorher durchrechnen.
Frage: Kann ein Global Administrator die AU-Grenzen umgehen?
Antwort: Ja. AU-Grenzen gelten nur für Rollen, die explizit auf die AU gescopt wurden. Tenant-weite Rollen wie Global Administrator oder ein nicht gescopter User Administrator ignorieren AUs vollständig. Wer Konten auch vor globalen Rollen abschirmen will, braucht Restricted Management Administrative Units.
Frage: Was sind Restricted Management AUs?
Antwort: Eine besondere AU-Variante, deren Mitglieder selbst von tenant-weiten Admins nicht mehr verwaltet werden können – nur noch von explizit für diese AU berechtigten Rollen. Gedacht für hochsensible Konten wie Break-Glass-Accounts oder Vorstandskonten. Mächtig, aber mit Vorsicht zu genießen: Falsch konfiguriert sperrst du dich selbst aus.
Frage: Sollte ich zugewiesene oder dynamische AUs verwenden?
Antwort: Faustregel: Ist die Zugehörigkeit stabil und klar manuell abgrenzbar (Standort, Tochterfirma), nimm zugewiesene AUs. Ergibt sich die Zugehörigkeit aus einem gepflegten Attribut (Abteilung, Jobtitel), nimm dynamische AUs – aber nur, wenn die Attributdaten wirklich sauber sind. Schlechte Datenqualität macht dynamische AUs zur Fehlerquelle.
Frage: Kann ich AUs mit PIM kombinieren?
Antwort: Ja, und das ist eine sehr saubere Kombination. Du kannst eine auf eine AU gescopte Rolle zusätzlich über PIM nur eligible machen. Der lokale Admin ist dann nicht nur auf seine Einheit beschränkt, sondern aktiviert seine Rechte auch nur bei Bedarf und auf Zeit – Delegation und Least Privilege in einem.
Wie geht es weiter?
|
Dein nächster Schritt Mehrere Standorte, Tochterfirmen oder Abteilungen, und die Delegation läuft entweder über zu mächtige Rollen oder gar nicht? In der Implementierungs- oder Migrationsbegleitung bauen wir deine AU-Struktur zusammen auf, scopen die Rollen sauber, klären die Lizenzfrage vorab und verzahnen das Ganze bei Bedarf mit PIM – damit lokale Teams arbeiten können, ohne dass jemand mehr sieht, als er soll. |
|---|