Restricted Management Administrative Units schützen sensible Konten

In vielen Tenants, die ich betreue, stellt sich früher oder später dieselbe Frage: Wie schützt man besonders sensible Konten wirksam davor, dass Standard-Administratoren sie ungewollt verändern? Gemeint sind etwa die Konten der Geschäftsführung, Notfallzugänge oder privilegierte Admins. Sind Berechtigungen breit verteilt oder arbeiten mehrere IT-Dienstleister im Tenant, steigt das Risiko, dass ein Admin mit zu weitreichenden Rechten eines dieser Konten versehentlich oder absichtlich sperrt, löscht oder verändert. Klassische Rollen wie „Benutzeradministrator“ helfen da nicht weiter, weil sie global gelten und damit zu viel erlauben. Für dieses Problem hat Microsoft in Entra ID die Restricted Management Administrative Units geschaffen. Mit ihnen lässt sich endlich wirksam festlegen, dass nur ein kleiner Kreis von Admins die kritischen Konten verwalten darf.

Eine Restricted Management AU entzieht Konten der normalen Verwaltung

Administrative Units (AUs) gibt es in Entra ID schon länger. Mit der Option „Restricted management administrative unit“ bekommen sie aber einen ganz anderen Nutzen. Angelegt werden solche AUs im Microsoft Entra Admin Center unter Identität → Rollen & Administratoren → Administrative Einheiten → Hinzufügen. Dabei muss „Eingeschränkte Verwaltung“ gleich beim Anlegen auf „Ja“ stehen, denn nachträglich lässt sich die Einstellung nicht mehr ändern. Konten, die in diese AU aufgenommen werden, können danach nur noch Admins verwalten, denen ausdrücklich eine Rolle für genau diese AU zugewiesen wurde. Sogar Global Admins und User Admins auf Tenant-Ebene verlieren an diesen Konten viele Änderungsrechte. Damit einer Person AU-Rollen zugewiesen werden können, braucht sie eine Entra-ID-P1-Lizenz. Die zugehörige Dokumentation findet ihr auf docs.microsoft.com.

Im folgenden Diagramm ist das Prinzip dargestellt: Die sensiblen Konten liegen in einer Restricted AU. Verwalten dürfen sie nur Admins, die eine Rolle für diese AU haben, alle anderen bleiben außen vor, auch die Tenant-Administratoren.

flowchart TD
    tenant_admin["Global Admin"]
    user_admin["User Admin (Tenant)"]
    au_admin["AU Admin (Restricted AU)"]
    sensitive_accounts["Sensible Konten"]
    standard_accounts["Andere Konten"]
    restricted_au["Restricted AU"]
    tenant_admin --> standard_accounts
    tenant_admin -.-> sensitive_accounts
    user_admin --> standard_accounts
    user_admin -.-> sensitive_accounts
    au_admin --> restricted_au
    restricted_au --> sensitive_accounts

Abbildung: Zugriff auf sensible Konten in einer Restricted Management AU

Global Admins behalten nur noch wenige Rechte an geschützten Konten

Welche Rechte Global Admins gegenüber Restricted Management AUs noch haben, sorgt oft für Unsicherheit. Die AU selbst löschen oder Admins auf AU-Ebene zuweisen dürfen sie weiterhin. Die Mitglieder der Restricted AU können sie dagegen nicht mehr verwalten: Sie setzen dort keine Passwörter zurück, ändern keine Attribute und fügen weder Gruppenmitgliedschaften hinzu noch entfernen sie welche. Auch wer ein Konto nur vorübergehend in die AU aufnehmen will, muss sich an strenge Regeln halten. Viele Organisationen gewinnen dadurch deutlich mehr Aufgabentrennung und Schutz vor Missbrauch, vor allem bei Break-Glass-Accounts und C-Level-Konten. Genaueres zu den Berechtigungen steht in der Microsoft-Dokumentation.

Die Einrichtung gelingt in wenigen Schritten, birgt aber Stolperfallen

In der Praxis gehe ich so vor: Im Entra Admin Center lege ich eine neue Administrative Unit an und aktiviere dabei „Eingeschränkte Verwaltung“. Danach nehme ich die gewünschten Benutzer in die AU auf. Damit jemand diese Konten verwalten kann, weise ich anschließend Rollen wie „Benutzeradministrator“ oder „Kennwortadministrator“ gezielt für diese AU zu, entweder im Portal oder per PowerShell. Dabei nicht vergessen, dass der Admin für die Zuweisung Entra ID P1 benötigt. Wie die Rollenzuweisung im Einzelnen funktioniert, erklärt diese Anleitung. In vielen Unternehmen setze ich zusätzlich Privileged Identity Management (PIM) ein, sodass AU-Rollen nur befristet vergeben werden. Das bringt eine weitere Schutzebene: Ein berechtigter Admin schaltet sich erst dann für die Restricted AU frei, wenn er sie wirklich braucht, auf Wunsch auch erst nach einer Genehmigung.

Praxis-Tipp: Für Gruppen taugen AUs nicht. Gruppenmitgliedschaften und -eigenschaften in Entra ID schränken sie nicht ein. Privilegierte Gruppen brauchen deshalb eine eigene Governance-Strategie, zum Beispiel mit Access Reviews.

Helpdesk und Notfallzugänge brauchen angepasste Abläufe

Auf einen Stolperstein stoße ich immer wieder: Helpdesks und 1st-Level-Teams sind gewohnt, bei jedem beliebigen Konto Passwörter zurückzusetzen oder Sperren aufzuheben. Sobald eine Restricted Management AU im Einsatz ist, laufen die üblichen Prozesse für diese Konten plötzlich ins Leere – und das ist auch so beabsichtigt. Die Helpdesk-Playbooks müssen also angepasst werden, und es braucht eine klare Regelung für Notfälle, etwa wenn das Konto des Geschäftsführers gesperrt ist. Bei Notfallzugängen (Break Glass) führt an der Restricted AU ohnehin kein Weg vorbei. Solche Konten sollten sich weder über die gewöhnlichen Benutzerprozesse noch von regulären Admins ändern lassen. Außerdem empfehle ich, Zugriffsversuche zu überwachen.

Der Aufwand für die Einrichtung lohnt sich in der Praxis

Nach mehreren Projekten ziehe ich eine klare Bilanz: Für hochsensible Entra-ID-Konten gibt es derzeit keinen wirksameren eingebauten Schutz als Restricted Management Administrative Units. Eingerichtet sind sie schnell, die zuständigen Admins haben danach kaum zusätzlichen Verwaltungsaufwand, und die Sicherheit steigt spürbar. Wer die P1-Lizenz und die einmalige Überarbeitung der Helpdesk-Prozesse in Kauf nimmt, macht seinen Tenant deutlich widerstandsfähiger gegen interne Fehler und gezielte Angriffe. Wer darüber hinaus mehr aus Entra Governance herausholen möchte, findet in diesem Beitrag einen guten Einstieg in automatisierte Joiner-/Leaver-Szenarien.