Microsoft Entra Tenant Governance: Überblick, Einrichtung und Lizenzierung

Wie viele Tenants hat Ihre Organisation?

Schatten-Tenants sind leicht zu beschreiben und schwer zu finden. Ein Test-Tenant aus einem abgeschlossenen Projekt, ein Tenant, der mit einer Übernahme dazugekommen ist, einer, den ein Entwickler mit der Firmenkreditkarte angelegt hat. Sie liegen außerhalb Ihrer zentralen Richtlinien, haben oft nur noch einen einzigen Global Admin und tauchen in keinem Assessment auf. Was bisher fehlte, war eine Möglichkeit, sie direkt aus Entra heraus zu finden.

Genau dafür hat Microsoft Entra Tenant Governance entwickelt. Schauen wir uns an, was es kann, wie die Einrichtung funktioniert, was es an Lizenzen kostet und wo ich seine Grenzen sehe.

Was Tenant Governance leistet

Tenant Governance bündelt vier Funktionen unter Tenant governance im Entra Admin Center. Jede baut auf der vorherigen auf.

Die erste ist die Discovery. Sie sucht nach Tenants, die eine erkennbare Beziehung zu Ihrem Tenant haben, basierend auf B2B-Zusammenarbeit, der Nutzung von Multitenant-Apps und gemeinsamen Abrechnungskonten. Das Ergebnis ist eine Liste „Related tenants“ mit Aktivitätsdaten, die Sie selbst klassifizieren.

Gefundene Tenants lassen sich über eine Governance-Beziehung einbinden. Sie verbindet einen verwaltenden Tenant (Governing Tenant) mit einem verwalteten Tenant (Governed Tenant). Die Richtung ist festgelegt, und der verwaltete Tenant muss jeder Beziehung zustimmen. Richtlinienvorlagen (Policy Templates) legen fest, was die Beziehung bereitstellt: welche Entra-Rollen an welche Sicherheitsgruppen im verwaltenden Tenant gehen und welche benutzerdefinierten Multitenant-Apps bereitgestellt werden.

Für die laufende Kontrolle gibt es das Konfigurationsmonitoring. Sie beschreiben den Sollzustand eines Tenants als JSON-Baseline und lassen ihn von einem Monitor regelmäßig prüfen. Laut Microsoft werden mehr als 200 Ressourcentypen aus Entra, Intune, Exchange Online, Teams, Purview und Defender abgedeckt. Abweichungen erscheinen als Drift, mit Ist- und Sollwerten nebeneinander.

Die vierte ist die sichere Tenant-Erstellung. Neue Tenants können als „Governed Workforce“-Tenants angelegt werden. Sie sind ab der ersten Minute an Ihren Haupt-Tenant gebunden, und das Billing-Asset hält einen Wiederherstellungsweg offen, falls der letzte Admin das Unternehmen verlässt oder der Tenant kompromittiert wird.

Für Admins ist die delegierte Administration der Teil, den Sie am stärksten bemerken werden. Mitglieder der berechtigten Gruppe öffnen ein Admin-Portal mit angehängter Tenant-ID, zum Beispiel https://entra.microsoft.com/{tenant-id}, und melden sich mit ihrem eigenen Konto an. Keine lokalen Admin-Konten, keine B2B-Gäste mit Global Admin. Im Hintergrund erhält der verwaltete Tenant GDAP-Rollenzuweisungen und angepasste Einstellungen für den mandantenübergreifenden Zugriff.

Lizenzierung: Basic vs. Premium

Tenant Governance gibt es in zwei Stufen. Basic ist in Entra ID P1 und P2 enthalten und damit auch in Microsoft 365 E3, E5 und Business Premium. Premium ist in Entra ID Governance enthalten und damit auch in Entra Suite und Microsoft 365 E7.

Das Lizenzmodell gilt pro Admin, nicht pro Benutzer. Laut Microsofts Folien benötigen Sie eine Lizenz für jeden Administrator, der Funktionen von Tenant Governance nutzt; eine Lizenz für jeden Benutzer im Tenant ist nicht erforderlich.

Funktion	Basic (Entra ID P1 / P2)	Premium (Entra ID Governance)
Konfigurationsmonitoring und Drift-Berichte	Bis zu 800 Ressourcen pro Tenant und Tag, bis zu 30 Monitore	Zusätzlich 10 Ressourcen pro Tenant und Tag je Lizenz
Konfigurations-Snapshots	Bis zu 20.000 Ressourcen pro Tenant und Monat, bis zu 12 aktive Snapshot-Jobs	Zusätzlich 35 Ressourcen pro Tenant und Monat je Lizenz
Discovery verwandter Tenants	Nein	Ja
Governance-Beziehung mit GDAP	Ja	Ja
Governance-Beziehung mit Bereitstellung benutzerdefinierter Apps	Nein	Ja
Sichere Tenant-Erstellung mit Governance-Beziehung	ja	Ja

Zwei Dinge fallen auf. Erstens: Discovery gibt es nur mit Premium. Mit P1 oder P2 können Sie Tenants verwalten, die Sie bereits kennen, aber Sie können mit Entra nicht diejenigen finden, von denen Sie nichts wissen. Zweitens skaliert die Premium-Kapazität mit der Anzahl der Lizenzen: 100 Entra-ID-Governance-Lizenzen würden zusätzlich zum Basic-Limit 1.000 überwachte Ressourcen pro Tenant und Tag bringen.

Einrichtung in fünf Phasen

Microsofts Deployment Guide teilt den Rollout in fünf aufeinander aufbauende Phasen. Für die meisten Schritte wird die Rolle Tenant Governance Administrator benötigt. Für das Erteilen von Berechtigungen für das Konfigurationsmonitoring ist Global Administrator oder Privileged Role Administrator erforderlich.

1. Discovery aktivieren (Premium). Gehen Sie zu Tenant governance > Related tenants und wählen Sie Discover related tenants. Beachten Sie, dass sich diese Einstellung nicht rückgängig machen lässt. Es kann mehrere Tage dauern, bis Signale vorliegen. Klassifizieren Sie anschließend jeden Tenant. Microsoft schlägt drei Kategorien vor: bekannt und akzeptabel (Partner, Anbieter), Governance erforderlich (intern, unklare Zuständigkeit) und potenziell riskant (unbekannt, kein geschäftlicher Grund). Für die letzte Gruppe dokumentiert Microsoft einen eigenen Quarantäneprozess.

2. Richtlinienvorlagen erstellen. Unter Tenant governance > Templates legen Sie fest, welche Rollen an welche Gruppen gehen. Ein Detail mit Folgen: Änderungen an Vorlagen gelten nicht für bestehende Beziehungen. Sie müssen eine neue Anfrage senden, und der verwaltete Tenant muss sie erneut annehmen. Wenn Sie die sichere Tenant-Erstellung nutzen wollen, legen Sie außerdem eine Vorlage mit der ID default an.

3. Beziehungen einrichten. Wenn beide Tenants ein Abrechnungskonto teilen, reicht ein zweistufiger Handshake: Der verwaltende Tenant sendet eine Anfrage (14 Tage gültig), und der verwaltete Tenant nimmt sie an. Ohne gemeinsame Abrechnung sind drei Schritte nötig, gestartet vom verwalteten Tenant mit einer Einladung (30 Tage gültig). Prüfen Sie anschließend, ob das Beziehungsobjekt, die Einstellungen für den mandantenübergreifenden Zugriff, die GDAP-Zuweisungen und die Service Principals in beiden Tenants vorhanden sind.

4. Delegierte Administration nutzen. Fügen Sie Admins zu den in der Vorlage genannten Gruppen hinzu und arbeiten Sie dann im verwalteten Tenant über die Portal-URL mit dessen Tenant-ID.

5. Konfigurationsmonitoring einrichten. Erteilen Sie zunächst die benötigten Graph-Berechtigungen unter Configuration management permissions (für Conditional Access zum Beispiel Policy.Read.All) sowie gegebenenfalls Rollen. Für Exchange, Security und Compliance geschieht das in den jeweiligen Admin Centern. Erstellen Sie dann die Baseline, entweder manuell oder mithilfe der Snapshot-APIs aus der aktuellen Konfiguration. Jede Baseline umfasst bis zu 200 Ressourceninstanzen, und ein Monitor läuft alle sechs Stunden. Das tägliche Limit über alle Monitore hängt von Ihrer Lizenzstufe ab (siehe Tabelle oben).

Drift beheben Sie auf zwei Arten: Sie korrigieren die Ressource oder aktualisieren die Baseline, wenn die Abweichung gewollt ist. Der nächste Lauf markiert die Drift dann als behoben.

Szenarien

Drei Szenarien zeigen, wie die Funktionen von Tenant Governance in der Praxis zusammenspielen.

Szenario 1: Unser Haupt-Tenant

Der Haupt-Tenant ist unsere Produktivumgebung und muss in einem freigegebenen, konformen Zustand bleiben. Solange er sich in diesem Zustand befindet, erstellen wir einen Snapshot: einen Export der aktuellen Konfiguration zu einem bestimmten Zeitpunkt für die ausgewählten Ressourcentypen, gespeichert als JSON. Dieser Snapshot wird unsere Baseline, und ein Monitor meldet jede Abweichung davon, etwa eine geänderte Conditional-Access-Richtlinie. Der Drift-Bericht zeigt, was sich geändert hat, sodass wir die Einstellung wiederherstellen oder die Baseline aktualisieren können, wenn die Änderung gewollt war. Der Haupt-Tenant ist außerdem unser verwaltender Tenant, in dem die Richtlinienvorlagen für Szenario 2 liegen.

Szenario 2: Unsere Test-Tenants

Jeder Test-Tenant hat eine Governance-Beziehung zum Haupt-Tenant. Dadurch erhalten unsere Admins delegierten Zugriff: Sie sind Mitglieder einer Sicherheitsgruppe im Haupt-Tenant, die Richtlinienvorlage weist dieser Gruppe die benötigten Entra-Rollen im Test-Tenant zu, und sie melden sich mit ihrem Konto aus dem Haupt-Tenant an. Wir brauchen keine separaten Admin-Konten oder B2B-Gäste mit Admin-Rollen in jedem Test-Tenant. Braucht ein Test-Tenant diesen Zugriff nicht mehr, kann er die Beziehung auf seiner Seite beenden.

In unseren Test-Tenants probieren wir viele neue Features aus, die Konfiguration ändert sich also ständig. Manchmal müssen wir genau wissen, was sich wann geändert hat. Ein Monitor in jedem Test-Tenant macht Konfigurationsdrift sichtbar, sodass Abweichungen schnell auffallen statt erst Wochen später.

Szenario 3: Ein externer IT-Dienstleister

Dasselbe Modell funktioniert, wenn die Admins in einem anderen Unternehmen sitzen. Nicht jede Organisation hat eine eigene IT-Abteilung. Stellen Sie sich Unternehmen A vor, eine kleine Organisation mit eigenem Entra-Tenant und begrenzten IT-Ressourcen, und Unternehmen B, einen IT-Dienstleister, der für die Identitätssicherheit von Unternehmen A zuständig ist.

Unternehmen A möchte, dass Unternehmen B Conditional-Access-Richtlinien erstellt, ändert und pflegt, ohne dem Partner dauerhaft Global-Administrator-Zugriff zu geben und ohne für jeden Admin des Partners ein eigenes Konto anzulegen. Mit Tenant Governance wird der Tenant von Unternehmen B zum verwaltenden Tenant und der Tenant von Unternehmen A zum verwalteten. Da die beiden kein Abrechnungskonto teilen, startet Unternehmen A den dreistufigen Handshake mit einer Einladung. Die Richtlinienvorlage weist der Admin-Gruppe von Unternehmen B dann eine passende Rolle zu, etwa Conditional Access Administrator statt Global Administrator. Die Admins von Unternehmen B melden sich mit ihren eigenen Konten an, und Unternehmen A kann nachvollziehen, was die Admins des verwaltenden Tenants in seinem Tenant tun.

Meine Einschätzung: Wo es hilft und wo es zu kurz greift

Für mich ist Discovery der größte Gewinn. Bisher ließen sich Schatten-Tenants nur mit eigenen Skripten, Billing-Exporten oder durch einfaches Herumfragen finden. Jetzt liefert Entra eine Liste mit Signalen. Allein das macht das Feature einen Blick wert, auch wenn Sie nie eine einzige Governance-Beziehung einrichten. Der Haken: Dafür ist eine Premium-Lizenzierung nötig.

Der zweite Gewinn ist die delegierte Administration. In vielen Umgebungen verwalten Admins sekundäre Tenants über lokale Cloud-only-Konten oder B2B-Gäste mit hohen Rechten. Das sind dauerhaft privilegierte Identitäten, die nach einer Weile niemand mehr im Blick hat. Mit Governance-Beziehungen ist der Zugriff an Gruppen im Haupt-Tenant gebunden, und der verwaltete Tenant kann ihn widerrufen.

Einige Punkte würde ich vor einem Rollout klären:

• Discovery lässt sich nicht wieder abschalten. Ich würde die Aktivierung als bewusste Entscheidung dokumentieren und vorab festlegen, wer die Ergebnisse prüft und was mit riskanten Tenants passiert.

• Änderungen an Vorlagen müssen in jedem verwalteten Tenant erneut angenommen werden. Bei drei Tenants ist das kein Problem, bei dreißig schon. Planen Sie Ihre Vorlagen sorgfältig, bevor Sie sie ausrollen.

• Konfigurationsmonitoring erkennt Drift, behebt sie aber nicht. Es ersetzt keine Configuration-as-Code-Pipelines, sondern ist die Kontrollebene daneben.

• Baselines sind JSON. Für Teams ohne Erfahrung mit Graph-Ressourcen ist das eine echte Hürde. Die Snapshot-APIs helfen, weil sie Ihnen den aktuellen Zustand als Ausgangspunkt liefern.

• Partner, die Kunden-Tenants verwalten, werden nach Azure Lighthouse fragen. Lighthouse delegiert Azure-Ressourcen, vergibt aber keine Entra-Verzeichnisrollen. Tenant Governance schließt genau diese Lücke, die beiden schließen sich also nicht gegenseitig aus.

• Da die Lizenzierung pro Admin erfolgt, prüfen Sie, wie viele Personen tatsächlich Funktionen von Tenant Governance benötigen. Diese Zahl bestimmt die Kosten, nicht Ihre Benutzerzahl.

In meinen eigenen Tests hatte der Snapshot-Assistent ein paar Ecken und Kanten. Im Schritt Permissions listet er die Least-Privilege-Berechtigungen auf, die jeder Ressourcentyp benötigt.
Allein für Conditional-Access-Richtlinien sind das sieben Leseberechtigungen, darunter Policy.Read.All, Application.Read.All, Group.Read.All und User.Read.All. Ein Link führt direkt zu Manage permissions für den Configuration Management Service, wo Sie sie erteilen.

Der Haken: Die Spalte Granted aktualisiert sich nicht, nachdem Sie die Berechtigungen erteilt haben, und es gibt keine Schaltfläche zum Aktualisieren. Ich musste zum nächsten Schritt und wieder zurück wechseln, bevor der Assistent alle Berechtigungen als erteilt anzeigte. Erstellen Sie den Snapshot vorher, schlägt er fehl. Genau das ist mir passiert, weil ich zu schnell durch den Assistenten geklickt habe.

Und Regenerate wiederholt einen fehlgeschlagenen Snapshot nicht, sondern erstellt einen neuen.

Ein Snapshot kann auch mit dem Status Partially successful enden.

Das klingt schlimmer, als es ist, denn das Fehlerfenster zeigt genau, was schiefgelaufen ist :D.

In meinem Fall verwiesen die Conditional-Access-Richtlinien noch auf ein- oder ausgeschlossene Benutzer und Gruppen, die es im Tenant nicht mehr gibt. Das ist für sich genommen schon eine nützliche Aufräumliste.

Mein Vorschlag für den Einstieg: Wenn Sie Premium haben, aktivieren Sie Discovery und klassifizieren Sie die Ergebnisse. Richten Sie parallel einen ersten Monitor auf Ihrem Produktiv-Tenant ein, zum Beispiel für Conditional-Access-Richtlinien. Das funktioniert auch mit Basic und liefert Ihnen innerhalb weniger Wochen belastbare Erkenntnisse, ganz ohne Beziehungen zu anderen Tenants.