Purview synchronisiert permanente Adminrollen nach Entra - was MC1199765 wirklich macht

Du loggst dich morgens in Entra ein und siehst eine Rolle, die gestern noch nicht da war. Purview Workload Content Reader. Du hast sie nicht erstellt, sie ist aktiv und das auch noch permanent zugewiesen. Sie ist nicht eligible, also nicht über PIM aktivierbar. Daneben zwei weitere: Writer, Administrator. Und im Audit-Log taucht ein Initiator auf, den du noch nie gesehen hast: PurviewRoleAssignmentMigrator.

Deine Suche führt dich zu MC1199765 — Microsoft Purview Role management update.

Dein erster Gedanke ist nicht analytisch. Dein erster Gedanke ist: Was zur Hölle soll das?!

Wir haben monatelang Zero Standing Privilege durchgesetzt. PIM ausgerollt. Just-in-Time-Aktivierung mit MFA, Approval, Audit. Wir haben dem Vorstand erklärt, warum permanente Rechte ein Risiko sind. Und jetzt synchronisiert Microsoft permanente, aktive Adminrollen aus Purview direkt nach Entra — am PIM und am Governance-Prozess vorbei.

Die LinkedIn-Kommentarspalten sind voll davon. Sicherheitslücke. Rückschritt. Wie kann das sein?!

Und das wollen wir uns jetzt einmal ansehen.

Was hier wirklich passiert

Der Auslöser hat eine Nummer: MC1199765. Das Microsoft Purview Role management update, ausgerollt seit Mitte Februar 2026, Abschluss Ende Mai. Wer in der Roadmap-Flut der letzten Monate untergegangen ist, hat es vermutlich übersehen.

Microsoft Purview ist historisch als eigenständige Compliance-Schicht entstanden. Mit eigenem RBAC-Modell, eigenen Role Groups, eigener Logik. Vieles, was Purview-Admins können — Search, Export, Content Explorer, eDiscovery, Insider Risk, DSPM — lebte in Purviews Rechtewelt, nicht in Entra.

Gleichzeitig wurde Purview immer tiefer mit den Workloads verzahnt. Exchange, SharePoint, OneDrive, Teams. Die Workloads müssen verstehen, wer suchen darf, wer lesen darf, wer exportieren darf. Und genau da bricht es manchmal, weil M365 Workloads mit der Purview Role Permission nicht immer zurecht kommen. Workloadübergreifende Autorisierung braucht eine workloadübergreifende Identität.

Genau das passiert gerade.

Microsoft schiebt Purview-Berechtigungen aus der produktinternen Welt in die zentrale Identity-Control-Plane von Entra. Drei neue Rollen erscheinen:

• Purview Workload Content Reader — für Compliance Search, Export, einzelne Insider Risk- und Privacy Management-Rollen, Data Security Investigation Reviewer

• Purview Workload Content Writer — für Hold, Privacy Management Investigation, Data Security Investigation Investigator

• Purview Workload Content Administrator — für Search and Purge, Data Security Investigation Admin/Analyst

  

Hat eine Person mehrere Purview-Rollen, gewinnt die höchste Stufe: Administrator > Writer > Reader.

Was vorher ein Purview-internes Recht war, wird jetzt auch zu einer Entra-Rolle. Synchronisiert über eine First-Party-Enterprise-Application namens PurviewRoleAssignmentMigrator — sie ist es, die in deinem Audit-Log auftaucht und die PIM-Alerts triggert.

Damit folgt Microsoft seiner strategischen Linie der letzten Jahre: Entra wird die zentrale Vertrauensinstanz. RBAC, PIM, Conditional Access, Audit, Workload Authorization — alles wandert dorthin. Architektonisch nachvollziehbar und eigentlich erwartbar.

Warum es trotzdem reibt

Die meisten dieser Rechte existierten funktional vorher schon. Wer als Purview-Admin im Content Explorer suchen durfte, durfte es gestern auch. Wer eDiscovery-Cases exportieren konnte, konnte es vorher auch. Das Mapping erfindet keine neuen Befugnisse. Es macht bestehende Befugnisse zentral sichtbar.

Und genau hier wird die Lage interessant.

Vorher lebte das Privileg in einer produktinternen Ebene. Sichtbar nur, wer reinschaute. Jetzt steht es in Entra.

Aber es ist auch ein sichtbares Standing Privilege in der Ebene, die der Tenant als hochsensibel behandelt. Tokens, Graph, Conditional Access, PIM — Entra ist die Tür zum ganzen Haus. Permanente Rollen dort fühlen sich anders an als permanente Rollen in einem Compliance-Portal. Auch wenn die Befugnis funktional dieselbe ist.

Dazu kommt der Trigger, der die meisten Kommentare ausgelöst hat: Microsoft synchronisiert die Rollen als active Assignments, nicht als eligible. Wer gerade einen sauberen Zero-Standing-Privilege-Rollout abgeschlossen hat, sieht zu, wie permanente Rollen in genau das Modell hineinwachsen, das man gerade aufgelöst hat.

Ist das eine Sicherheitslücke?

Eine Sicherheitslücke im technischen Sinn ist ein unbeabsichtigtes Verhalten, das einem Angreifer Rechte verschafft, die er nicht haben sollte. Das passiert hier nicht. Niemand bekommt Rechte, die er vorher nicht hatte. Das Mapping greift auf bestehende Purview-Mitgliedschaften zurück und übersetzt sie eins-zu-eins. Microsoft macht das bewusst, somit ist es kein Bug.

Trotzdem widerspricht es Zero Trust.

Zero Trust ohne Zero Standing Privilege ist kein vollständiges Zero Trust. Microsoft selbst definiert Least Privilege im Zero-Trust-Framework explizit über JIT und JEA. Gartner, der ZSP überhaupt geprägt hat, formuliert es eindeutig: Standing Privilege ist im Cloud-Zeitalter nicht mehr tragfähig. Die ganze Sicherheitsindustrie — Tenable, CyberArk, BeyondTrust, Palo Alto — zieht dieselbe Linie. Permanente, aktive Adminrollen sind das Gegenmodell zu Zero Trust, nicht eine Variante davon.

Also ja, hier wird Zero Trust verletzt — aber nicht da, wo die Community gerade hinschaut.

Der eigentliche Skandal: Purview konnte man nie sauber PIMen

Hier wird es interessant. Und hier liegt der Punkt, den die ganze Empörungswelle übersieht.

Purview Role Groups können nicht direkt in PIM verwaltet werden. Sie waren nie PIM-fähig. Microsoft sagt das selbst im offiziellen Doc:

https://learn.microsoft.com/en-us/purview/purview-permissions#privileged-identity-management-for-groups-in-the-microsoft-purview-portal

Was es gibt, ist ein Workaround: PIM for Groups. Du erstellst eine role-assignable Security Group, machst sie zum Mitglied einer Purview Role Group, und PIMst dann die Group-Membership. Wer eligible ist, aktiviert die Mitgliedschaft → wird transitiv Purview-Admin.

Das heißt: Standing Privilege in Purview war über Jahre der Normalfall, nicht die Ausnahme. Nicht, weil Tenants schlecht aufgestellt waren, sondern weil Microsoft nie eine vernünftige native PIM-Integration für Purview gebaut hat.

Was Microsoft mit MC1199765 wirklich tut

Mit dieser Vorgeschichte verschiebt sich das ganze Bild.

Microsoft spiegelt beim Mapping den bestehenden Kunden-State:

• Wer vorher direkte User-Zuweisungen in Purview Role Groups hatte (also Standing Privilege, weil PIM nicht ging) — bekommt jetzt direkte, active Entra-Rollen. Funktional identisch, nur jetzt sichtbar.

• Wer vorher PIM-enabled Security Groups als Mitglieder seiner Purview Role Groups nutzte — bekommt diese Groups auch in den neuen Entra-Rollen. PIM-Mechanik bleibt erhalten.

Microsoft trifft beim Mapping also keine eigene Privilege-Entscheidung. Sie machen 1:1-Spiegelung.

Was Microsoft hier wirklich tut, ist nicht Standing Privilege erzeugen. Microsoft macht sichtbar, dass Standing Privilege in Purview seit Jahren der Default-Zustand ist. Und das löst die PIM-Alerts aus — nicht weil das Mapping schlecht wäre, sondern weil die zugrundeliegende Realität schlecht ist.

Die Empörung der Community richtet sich gegen das Mapping. Sie sollte sich gegen die fehlende native PIM-Integration richten, die das Mapping erst zu einem Standing-Privilege-Auslöser macht.

Für die technische Tiefe — die genaue Mapping-Tabelle, Screenshots der PIM-Alerts und Audit-Log-Einträge, sowie die Verbindungen zu PIM-fähigen Purview-Rollen — empfehle ich Ewelina Paczkowskas Analyse zu MC1199765 bei Welka's World.