← Microsoft Entra ID & Microsoft 365 Administration

Identity Governance und Lebenszyklus

Zwei Einstellungen einer Zugriffsüberprüfung sind einzeln vernünftig: Ergebnisse automatisch anwenden, und Nichtantwort als Ablehnung werten. Zusammen können sie laut Dokumentation den gesamten Zugriff auf eine Ressource entziehen — es genügt, dass die beiden Prüfenden gleichzeitig im Urlaub sind. Dieses Modul behandelt die drei Werkzeuge der Governance und die Frage, an der sie sich unterscheiden: was den Vorgang auslöst. Dazu den teuersten der drei Lebenszyklus-Fälle — den Wechsel, bei dem alles weiter funktioniert und deshalb niemandem etwas auffällt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Drei Ereignisse, an denen sich Zugriff ändern muss

Bisher ging es darum, wie Zugriff entsteht und wie er begrenzt wird. Dieses Modul behandelt, wie er wieder verschwindet — die Aufgabe, an der fast jede Organisation scheitert, weil es dafür kein auslösendes Ereignis gibt, das sich von selbst meldet.

Joiner: Jemand tritt in den Bereich ein, in dem Zugriff nötig ist — eine neue Beschäftigung, ein neues Projekt.
Mover: Jemand wechselt innerhalb der Organisation. Neue Rechte kommen hinzu; die alten bleiben, wenn niemand sie entzieht.
Leaver: Jemand verlässt den Bereich. Der Zugriff muss enden.

Der mittlere Fall ist der teuerste. Beim Eintritt bemerkt jeder, dass etwas fehlt — die Person kann nicht arbeiten und meldet sich. Beim Austritt gibt es meist einen Prozess. Beim Wechsel dagegen funktioniert alles weiter, und genau das ist das Problem: Über Jahre sammelt eine Person die Rechte jeder Station, die sie durchlaufen hat, und niemandem fällt es auf.

LernzielDu kannst ein Zugriffspaket samt Richtlinie entwerfen, die Vollständigkeitseinstellungen einer Zugriffsüberprüfung sicher wählen und einen Lebenszyklus-Workflow aus Aufgabe und Ausführungsbedingung zusammensetzen.

Zugriffspakete: Zugriff als Bündel statt als Einzelteil

Der zentrale Baustein der Berechtigungsverwaltung ist das Zugriffspaket — laut Dokumentation ein Bündel aller Ressourcen, die jemand für ein Vorhaben oder eine Aufgabe braucht. Statt fünf Einzelanträge zu stellen, beantragt jemand ein Paket.

Mitgliedschaft in Sicherheitsgruppen und Microsoft-365-Gruppen
Zuweisung zu Anwendungen
Zugriff auf SharePoint-Online-Websites
Verzeichnisrollen — über rollenfähige Gruppen aus dem Modul zu Gruppen
Lizenzen — über eine Gruppe mit gruppenbasierter Lizenzierung

Die letzten beiden Zeilen sind der Grund, warum sich der Aufwand lohnt: Ein Paket kann Lizenz, Gruppenmitgliedschaft und Anwendungszugriff zusammen vergeben und zusammen wieder entziehen. Damit ist das Ende genauso vollständig wie der Anfang — die Eigenschaft, die einer manuellen Vergabe grundsätzlich fehlt.

Katalog — Ein Behälter für Ressourcen, aus dem Zugriffspakete zusammengestellt werden. Er ist zugleich die Delegationsgrenze: Wer einen Katalog verwalten darf, kann daraus Pakete bauen, ohne Verzeichnisrollen zu besitzen.

Diese Delegation ist der Punkt, an dem die Berechtigungsverwaltung im Alltag trägt. Die Dokumentation nennt sie ausdrücklich: Die Fähigkeit, Zugriffspakete zu erstellen, lässt sich an Personen ohne Verwaltungsrolle übergeben, und diese können dann selbst festlegen, wer beantragen darf, wer genehmigt und wann der Zugriff endet. Die Fachabteilung entscheidet damit über ihren eigenen Bereich, ohne dass jemand ihr dafür eine Verzeichnisrolle geben müsste.

Verglichen mit dem ersten Modul ist das ein anderer Weg zum selben Ziel. Dort war die Antwort auf eine Delegationsfrage die kleinste passende Rolle mit einem Geltungsbereich. Hier ist sie ein Katalog: Der Zuschnitt entsteht nicht über Rechte am Verzeichnis, sondern über die Auswahl der Ressourcen, die überhaupt im Katalog liegen.

Richtlinien: wer darf beantragen, wer genehmigt, wann endet es

Ein Paket allein vergibt nichts. Erst eine Richtlinie legt die Regeln fest, und ein Paket kann mehrere davon haben — etwa eine für Beschäftigte und eine für Partnerorganisationen.

Wer beantragen darf — vorhandene Personen oder Partnerorganisationen→Wer genehmigt — auch mehrstufig→Wie lange die Zuweisung gilt, bevor sie ohne Verlängerung abläuft→Ob wiederkehrend überprüft wird

Die Richtlinie trägt die Befristung, nicht das Paket

Neben der Antragsrichtlinie gibt es zwei weitere Wege: die direkte Zuweisung durch Verwaltende und die automatische Zuweisung anhand von Regeln über Eigenschaften wie Abteilung oder Kostenstelle. Bei der automatischen Variante steht ein Satz in der Dokumentation, der sie erst wertvoll macht: Der Zugriff wird auch wieder entfernt, wenn sich diese Eigenschaften ändern.

Damit ist der Mover-Fall gelöstGenau hier liegt die Antwort auf das teuerste der drei Ereignisse. Wechselt jemand die Abteilung, endet die automatische Zuweisung des alten Bereichs von selbst — nicht weil jemand daran gedacht hat, sondern weil die Bedingung nicht mehr zutrifft. Der Preis ist, dass die Attributpflege damit zur Zugriffssteuerung wird; ein Tippfehler im Personalsystem entzieht Rechte.

Verbundene Organisationen: der Gast, der von selbst geht

Für externe Personen schließt die Berechtigungsverwaltung genau die Lücke, die im vorigen Modul offen blieb. Sind Partnerorganisationen als verbundene Organisationen eingetragen, können deren Personen Zugriff beantragen, ohne vorher im Verzeichnis zu existieren.

Der Ablauf steht so in der Dokumentation: Beantragt jemand Zugriff, der noch nicht im Verzeichnis ist, und wird genehmigt, so wird die Person automatisch eingeladen und erhält die Zuweisung. Läuft der Zugriff später ab und hat die Person keine weiteren Paketzuweisungen, kann ihr B2B-Konto im Verzeichnis automatisch entfernt werden.

Warum das der eigentliche Gewinn istDas vorige Modul endete mit dem Befund, dass Gastobjekte bleiben, weil ihr Lebenszyklus in einer fremden Organisation liegt. Hier bekommt das Gastobjekt einen Lebenszyklus in deiner Organisation: Es entsteht mit einem Anlass und endet mit ihm. Das ist der Unterschied zwischen einem Bestand, der wächst, und einem, der atmet.

Die Einschränkung ist ebenso wichtig: Die automatische Entfernung greift nur, wenn keine andere Zuweisung mehr besteht. Wer einem Gast nebenher eine Gruppenmitgliedschaft von Hand gibt, hebt die Automatik für dieses Konto auf — und merkt es nicht.

Zugriffsüberprüfungen: wer prüft

Die zweite Säule sind wiederkehrende Überprüfungen. Sie beantworten die Frage, ob ein bestehender Zugriff noch begründet ist, und lassen sich wöchentlich, monatlich, vierteljährlich oder jährlich ansetzen.

Benannte Prüfende: Ausgewählte Personen prüfen für alle. Gut bei kleinen, klar zuständigen Beständen.
Gruppeneigentümer: Wer die Gruppe verantwortet, prüft ihre Mitglieder. Die Dokumentation nennt ausdrücklich den Fall der Gäste in Gruppen mit sensiblen Inhalten.
Vorgesetzte: Jede Person wird von ihrer Führungskraft geprüft. Skaliert gut, setzt aber gepflegte Vorgesetztenangaben voraus.
Selbstüberprüfung: Die Betroffenen bestätigen ihren eigenen Bedarf. Am billigsten und am schwächsten.

Die Wahl entscheidet über die Qualität des Ergebnisses. Eine Selbstüberprüfung liefert zuverlässig die Antwort, dass alle ihren Zugriff weiterhin brauchen — sie ist trotzdem nicht wertlos, weil sie den Bestand sichtbar macht und einen Vermerk erzeugt. Man sollte sie nur nicht mit einer Prüfung verwechseln.

Die Dokumentation nennt zudem Anlässe, bei denen sich eine Überprüfung besonders lohnt, und einer davon ist leicht zu übersehen: wenn eine Gruppe für einen neuen Zweck verwendet werden soll. Eine dynamische Gruppe, die bisher eine Verteilerliste speiste, bekommt eine andere Bedeutung, sobald an ihr ein Anwendungszugriff hängt — geprüft wurde ihre Zusammensetzung aber unter den alten Vorzeichen.

Der Auslöser, den niemand einplantNicht die Zeit macht eine Mitgliederliste überprüfungsbedürftig, sondern die Änderung ihrer Wirkung. Wer eine bestehende Gruppe für eine neue Berechtigung wiederverwendet, erbt eine Liste, die jemand anderes für einen anderen Zweck zusammengestellt hat.

Die Einstellung, die alles entziehen kann

Beim Anlegen einer Überprüfung stehen zwei Einstellungen nebeneinander, die zusammen gefährlich werden. Die Dokumentation warnt davor ausdrücklich.

autoApplyDecisionsEnabled — Ergebnisse automatisch anwenden. Steht ab Werk auf false; dann muss jemand die Entscheidungen nach Abschluss von Hand anwenden. Auf true werden sie nach Ablauf der Überprüfungsdauer angewandt, unabhängig davon, ob die Prüfenden geantwortet haben.
defaultDecisionEnabled — greift eine Vorgabe, wenn niemand geprüft hat. Ebenfalls ab Werk false. Die Vorgabe selbst steht in defaultDecision mit den Werten Approve, Deny oder Recommendation.

Die Dokumentation setzt an beide Eigenschaften denselben Warnhinweis: Sind autoApplyDecisionsEnabled und defaultDecisionEnabled auf true, kann der gesamte Zugriff der Beteiligten auf diese Ressource entzogen werden, falls die Prüfenden nicht antworten.

Warum das so leicht passiertBeide Einstellungen sind einzeln vernünftig. Automatische Anwendung erspart Nacharbeit, und Nichtantworten als Ablehnung zu werten ist die vorsichtige Auslegung. Zusammen ergeben sie eine Kette, in der Untätigkeit — nicht eine Entscheidung — zum Entzug führt. Bei einer Überprüfung im Urlaubsmonat genügt das.

Der sichere Zuschnitt für die erste Runde ist deshalb: defaultDecisionEnabled auf false lassen und autoApplyDecisionsEnabled ebenfalls — also beide Werkseinstellungen behalten. Erst wenn die Prüfenden verlässlich antworten, lohnt die Automatik, und dann mit einer Erinnerung vor dem Ende der instanceDurationInDays.

Eine kleine Einstellung mit großer WirkungjustificationRequiredOnApproval steht ab Werk auf false — Prüfende können also ohne Begründung genehmigen. Für einen Nachweis, der später etwas wert sein soll, gehört sie auf true. Der Preis ist Reibung: Wer 80 Mitglieder bestätigen muss, tippt 80 Begründungen, und die Qualität der achtzigsten ist absehbar.

Was mit abgelehnten Gästen geschieht

Ist eine Überprüfung auf Gäste zugeschnitten, gibt es eine eigene Einstellung dafür, was mit abgelehnten Personen passiert. Zwei Wege stehen zur Wahl, und sie unterscheiden sich erheblich.

Mitgliedschaft entfernen: Der Gast verliert den Zugriff auf diese Gruppe oder Anwendung. Er kann sich weiterhin am Tenant anmelden und behält allen anderen Zugriff.
Anmeldung sperren, nach 30 Tagen entfernen: Der Gast wird tenantweit gesperrt, unabhängig von anderem Zugriff. Innerhalb von 30 Tagen lässt sich das rückgängig machen; danach wird das Konto aus dem Tenant gelöscht.

Die zweite Variante ist die Antwort auf das Bestandsproblem aus dem vorigen Modul — sie räumt tatsächlich auf. Sie ist zugleich die riskantere: Eine irrtümliche Ablehnung sperrt jemanden vollständig aus, und die 30 Tage sind die einzige Gelegenheit, das zu bemerken.

Die Kombination, die man vermeiden sollteDiese Einstellung zusammen mit Zugriff entfernen bei Nichtantwort und automatischer Anwendung. Dann führt ein nicht bearbeiteter Überprüfungslauf dazu, dass Gäste tenantweit gesperrt und einen Monat später gelöscht werden — ohne dass jemand eine Entscheidung getroffen hätte.

Entscheidungshilfen und ihre Grenzen

Damit Prüfende nicht raten müssen, kann das System Empfehlungen einblenden. Zwei Verfahren stehen zur Verfügung, und beide haben eine benennbare Schwäche.

Keine Anmeldung in 30 Tagen: Wer sich in den letzten 30 Tagen angemeldet hat, wird zur Genehmigung empfohlen, sonst zur Ablehnung. Bei Überprüfungen auf Anwendungsebene zählt die Anmeldung an der Anwendung, nicht am Tenant.
Zugehörigkeit zur Gruppe: Bewertet den durchschnittlichen Abstand einer Person zu den übrigen Mitgliedern in der Organisationsstruktur. Wer weit entfernt ist, gilt als gering zugehörig und wird zur Ablehnung empfohlen.

Die erste Empfehlung bestraft alles, was selten gebraucht wird — ein Notfallwerkzeug, ein quartalsweiser Abschluss, eine Vertretungsregelung. Die zweite bestraft alles, was quer zur Hierarchie liegt, also gerade die abteilungsübergreifende Zusammenarbeit.

Der Rückblickzeitraum ist dabei einstellbar: recommendationLookBackDuration steht ohne Angabe auf 30 Tagen. Für Gruppen und Verzeichnisrollen ist jede Dauer zulässig — für Überprüfungen von Anwendungen sind 30 Tage laut Dokumentation das Maximum. Wer einen quartalsweise genutzten Zugriff prüft, kann den Zeitraum bei einer Gruppe also passend weiten, bei einer Anwendung nicht.

Der richtige GebrauchEmpfehlungen sind eine Vorsortierung, keine Entscheidung. Sie werden gefährlich in dem Moment, in dem defaultDecision auf Recommendation steht — dann entscheidet die Heuristik allein, und ihre beiden Schwächen wirken ungebremst.

Inaktive Konten als Zuschnitt

Eine Überprüfung muss nicht den ganzen Bestand umfassen. Sie lässt sich auf inaktive Personen begrenzen — solche, die sich seit einer wählbaren Zahl von Tagen weder interaktiv noch anderweitig angemeldet haben, bis zu 730 Tagen.

Das ist der günstigste Einstieg in eine Aufräumaktion: kleiner Umfang, hohe Trefferquote, geringes Risiko. Wer 200 Gäste hat und nicht weiß, wo er anfangen soll, prüft zuerst die seit einem Jahr inaktiven.

Ein durchdachtes DetailDie Dokumentation nennt eine Ausnahme, die man sonst schmerzhaft lernt: Kürzlich erstellte Konten fallen nicht in den Umfang. Wird die Inaktivität auf 90 Tage gesetzt und ein Gast wurde vor 60 Tagen eingeladen, bleibt er außen vor — damit jede Person mindestens einmal die Gelegenheit hatte, sich anzumelden, bevor sie wegen Untätigkeit entfernt wird.

Lebenszyklus-Workflows: Aufgabe plus Ausführungsbedingung

Die dritte Säule automatisiert die drei Ereignisse aus dem ersten Abschnitt. Ein Workflow besteht laut Dokumentation aus Aufgaben und einer Ausführungsbedingung, und die Bedingung zerfällt in zwei Fragen: wer ist betroffen und wann wird ausgelöst.

Das Beispiel der Dokumentation ist eine E-Mail an die Führungskraft sieben Tage vor dem Wert im Attribut employeeHireDate. Aufgabe: E-Mail senden. Wer: neue Beschäftigte. Wann: sieben Tage vor dem Eintrittsdatum.

Der Bezug auf ein Datum ist der entscheidende Unterschied zu dynamischen Gruppen aus dem Modul zu Gruppen. Eine dynamische Regel kann prüfen, ob ein Attribut einen Wert hat — sie kann nicht sagen: sieben Tage vorher. Ergänzend nennt die Dokumentation zwei weitere Unterschiede: Workflows verwalten statische Gruppen ohne Regel, und sie können Aktionen an der Gruppe selbst ausführen, nicht nur an der Mitgliedschaft.

Für den Austritt zählt entsprechend employeeLeaveDateTime. Typische Aufgaben eines Leaver-Workflows sind, das Konto zu deaktivieren, Gruppenmitgliedschaften zu entfernen und die Führungskraft zu benachrichtigen — angestoßen zu einem festgelegten Zeitpunkt relativ zum Austrittsdatum, nicht wenn jemand daran denkt.

Der Zusammenhang mit dem Modul zum Abgleich ist zu beachten: In einer hybriden Umgebung stammen diese Attribute meist aus dem lokalen Verzeichnis oder aus dem Personalsystem. Der Workflow ist damit nur so pünktlich wie die Pflege der Quelle — und ein leeres Austrittsdatum löst gar nichts aus.

Was dabei entstehtWorkflows führen einen Verlauf und schreiben in die Überwachungsprotokolle. Damit ist der Lebenszyklus nicht nur automatisiert, sondern belegbar — was bei einer Prüfung mehr wert ist als die Automatisierung selbst.

Durchgerechnet: eine Zugriffsüberprüfung, die niemanden versehentlich aussperrt

Erste Überprüfung eines Gastbestands

Szenario

Im Tenant liegen rund 200 Gastkonten aus mehreren Jahren. Niemand kann sagen, welche noch gebraucht werden. Der erste Entwurf lautet: alle Gäste prüfen lassen, Ergebnisse automatisch anwenden, bei Nichtantwort Zugriff entfernen.

Anforderungen

Der Bestand soll kleiner werden.
Niemand soll durch Untätigkeit Dritter den Zugriff verlieren.
Der Aufwand soll für die erste Runde überschaubar bleiben.

Schritte

Umfang klein schneiden: nur Gäste, die seit 180 Tagen inaktiv sind. Kürzlich eingeladene fallen ohnehin heraus.
Prüfende wählen: die Gruppeneigentümer, nicht die Gäste selbst — sonst bestätigt jeder seinen eigenen Bedarf.
Bei Nichtantwort keine Änderung setzen und die Ergebnisse zunächst von Hand anwenden. Die dokumentierte Warnung gilt genau der Gegenkombination.
Entscheidungshilfe einschalten, aber als Vorsortierung — nicht als Verhalten bei Nichtantwort.
Für abgelehnte Gäste zunächst nur die Mitgliedschaft entfernen. Die tenantweite Sperre mit 30-Tage-Frist erst, wenn die Prüfenden verlässlich antworten.

Merksatz: Die erste Runde misst, ob der Ablauf trägt. Erst die zweite darf automatisch entziehen — mit denselben Einstellungen, aber begründetem Vertrauen.

Der Preis dieses Vorgehens ist, dass die erste Runde wenig aufräumt: Nichtantworten bleiben folgenlos, und jemand muss die Ergebnisse anwenden. Dafür entsteht kein Vorfall, bei dem eine Abteilung am Montag ohne Zugriff dasteht, weil ein Prüfender im Urlaub war.

Die Reihenfolge, die alles zusammenhält

Zugriff als Paket vergeben, damit er als Paket endet→Befristung in die Richtlinie schreiben, nicht in eine Erinnerung→Automatische Zuweisung über Attribute nutzen — sie löst den Mover-Fall→Überprüfungen klein und mit harmlosen Voreinstellungen beginnen→Erst automatisch entziehen, wenn die Prüfenden verlässlich antworten

Untätigkeit darf nichts entziehen

Governance ist der Bereich, in dem die Werkzeuge fertig sind und die Einführung scheitert — meist an einer ersten Runde, die zu groß war oder zu scharf eingestellt. Der Unterschied zwischen einem Bestand, der wächst, und einem, der atmet, liegt nicht in der Technik, sondern darin, ob die erste Überprüfung Vertrauen geschaffen hat.

Gleich im CheckDie Übungen prüfen den Aufbau eines Zugriffspakets, die gefährliche Kombination der Vollständigkeitseinstellungen, den Umgang mit abgelehnten Gästen und den Unterschied zwischen dynamischer Gruppe und Lebenszyklus-Workflow.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-13