EntraID | Group.Read.All vs. GroupMember.Read.All

Bei der Zuweisung von Microsoft Graph-Berechtigungen für App-Registrierungen in Microsoft Entra ID stoßen viele Administratoren auf ein logisches Dilemma. Um Gruppeninformationen über Skripte oder Applikationen auszulesen, werden oftmals reflexartig sowohl Group.Read.All als auch GroupMember.Read.All zugewiesen. Diese Annahme basiert auf der Fehlinterpretation, dass die eine Berechtigung ausschließlich die Metadaten der Gruppe und die andere isoliert deren Mitgliedschaften steuert. 

Diese Doppelvergabe ist auf API-Ebene technisch inkorrekt, wodurch Applikationen massiv überprivilegiert werden und die Angriffsfläche des Tenants unnötig vergrößert wird. Microsoft Entra ID agiert als zentrale Multi-Cloud-Identitäts- und Zugriffsverwaltungslösung für alle Microsoft 365 Workloads. Um eine belastbare Zero-Trust-Architektur aufzubauen, erfordert das System eine strikte Anwendung des Least-Privilege-Prinzips, wodurch der Missbrauch von überprivilegierten Konten oder Applikationen zwingend verhindert werden muss.

Das Verständnis der genauen Wirkungsweise granularer Berechtigungen ist die absolute Grundvoraussetzung, um Automatisierungen sicher zu betreiben. Wir brechen die Zusammenhänge der Graph API-Berechtigungen für Gruppen auf und definieren die exakten Architekturgrenzen zwischen delegierten Rechten und Applikationsrechten.

Wenn du eine Applikation mit delegierten Berechtigungen ausstattest, agiert diese immer im Kontext eines angemeldeten Benutzers. Die Berechtigung Group.Read.All erlaubt es dem Benutzer in diesem Szenario, Informationen für jede Gruppe auszulesen, auf die er expliziten oder impliziten Zugriff hat. Dies schließt Zugriffe ein, die durch administrative Rollen wie den "Groups Administrator" gewährt werden.

Der entscheidende Architekturfaktor ist jedoch die Definition des Begriffs "Gruppeninhalte" innerhalb der Graph API. Die Zuweisung von Group.* Berechtigungen gewährt der Applikation vollständigen Lesezugriff auf den gesamten Ressourcenstamm der Gruppe. Handelt es sich um eine Microsoft 365-Gruppe, umfasst dieses Ressourcen-Set nicht nur die reinen Mitgliedschaften und Besitzverhältnisse. Die Applikation erhält dadurch direkten Durchgriff auf die Dateien in der verbundenen SharePoint-Website, auf Artefakte des Teams (sofern die Gruppe Teams-aktiviert ist), auf den Gruppenkalender sowie auf sämtliche Konversations-Threads, die im Gruppenpostfach gespeichert sind.

Dieses Verhalten ist eine direkte Folge des Microsoft 365-Gruppendesigns, bei dem Kernprinzipien vorschreiben, dass alle Mitglieder einer Gruppe vollen und geteilten Zugriff auf sämtliche Gruppenressourcen haben. Nutzt du in einer interaktiven PowerShell-Sitzung die delegierte Berechtigung Group.Read.All, kannst du beispielsweise problemlos die erste Konversation aus dem Posteingang der Gruppe abrufen.

Zusätzlich ermöglicht diese Berechtigung das Auslesen von Dateien innerhalb der zugehörigen SharePoint-Site. Durch die Nutzung des Cmdlets Get-MgGroupDriveItemChild wird die Struktur der Standarddokumentenbibliothek abgebildet, wodurch die Anwendung direkten Lesezugriff auf die Dateiebene erhält.

Eine technische Ausnahme in dieser Struktur bildet Microsoft Planner. Planner erlaubt keinen Zugriff auf Pläne über die delegierte Group.Read.All Berechtigung. Der Zugriff auf Planner-Daten wird auf API-Ebene nicht durch Gruppenberechtigungen autorisiert, wodurch zwingend ein separates Set an Task-Berechtigungen erforderlich ist, um Planner-Aufgaben auszulesen.

Bei Microsoft Graph wird zwischen Delegated Permissions und Application Permissions unterschieden. Genau hier entstehen in vielen Microsoft-365-Umgebungen unnötige Sicherheitsrisiken.

Während Delegated Permissions nur auf Daten zugreifen können, die der angemeldete Benutzer selbst sehen darf, authentifizieren sich Application Permissions direkt gegenüber Entra ID, beispielsweise über Client Secrets, Zertifikate oder Managed Identities.

Gerade Berechtigungen wie Group.Read.All, Directory.Read.All oder User.Read.All können im App-Only-Kontext erhebliche Auswirkungen haben. Ein kompromittierter Service Principal ermöglicht Angreifern häufig tenantweite Enumeration, Zugriff auf Benutzerinformationen sowie persistente API-Zugriffe ohne Benutzerinteraktion.

Besonders kritisch ist dabei der sogenannte Admin Consent. Mit einem einzigen administrativen Zustimmungs-Klick werden häufig weitreichende tenantweite Berechtigungen vergeben, ohne dass die tatsächlichen Auswirkungen vollständig geprüft werden.

Zusätzlich geraten Service Principals oft aus dem Fokus der Sicherheitsüberwachung. Im Gegensatz zu Benutzerkonten besitzen sie häufig dauerhafte Tokens, hohe API-Berechtigungen und unterliegen weder MFA noch interaktiven Anmeldungen.

Auch OAuth2 Permission Grants stellen ein erhebliches Risiko dar. Veraltete Zustimmungen, unnötige API-Rechte oder dauerhafte Drittanbieterzugriffe bleiben in vielen Umgebungen jahrelang aktiv und werden selten überprüft.

Deshalb wird eine konsequente App Governance in modernen Microsoft-365-Umgebungen immer wichtiger. Dazu gehören unter anderem regelmäßige Reviews von Enterprise Applications, die Überwachung von Consent Grants, die Einschränkung von User Consent sowie der Einsatz von Managed Identities und zertifikatsbasierter Authentifizierung.

Die Komplexität und das Risiko steigen exponentiell, wenn wir den Kontext von delegierten Berechtigungen verlassen und Application Permissions (App-Rollen) betrachten. Application Permissions laufen als Hintergrunddienst ohne angemeldeten Benutzer. Wenn du einer App-Registrierung die Berechtigung Group.Read.All als Application Permission zuweist, erhält diese Applikation globalen Lesezugriff auf ausnahmslos alle Gruppen im gesamten Entra ID Tenant, inklusive aller zuvor genannten gekoppelten Ressourcen wie SharePoint-Dateien und Exchange-Konversationen.

Aufgrund dieser massiven Reichweite handelt es sich bei der App-Berechtigung Group.Read.All um ein High-Profile-Recht. Die Zuweisung an Skripte oder Applikationen muss auf absolut notwendige Ausnahmefälle beschränkt werden. Organisationen agieren hier oft fehlerhaft und nutzen diese Berechtigung für simple Reporting-Skripte. Dies widerspricht dem Konzept des "Assume Breach", bei dem Verteidigungsstrategien darauf ausgelegt sein müssen, dass das eigene Netzwerk oder die Identitäten bereits kompromittiert sind. Eine kompromittierte App-Registrierung mit Group.Read.All liefert einem Angreifer sofortigen Zugriff auf die sensibelsten Datenablagen der Organisation.

Noch kritischer ist die Zuweisung von Group.ReadWrite.All. Hier sind strikte Überwachung und Auditierung zwingend erforderlich, um laterale Bewegungen eines Angreifers zu verhindern. Eine technische Einschränkung der App-Berechtigung Group.Read.All ist jedoch, dass sie keinen Zugriff auf Gruppenkalender gewährt. Microsoft Graph unterstützt den Zugriff auf Gruppenkalender auf Architektur-Ebene ausschließlich über delegierte Berechtigungen.

Die Lösung für Automatisierungen, die lediglich Strukturdaten benötigen, ist GroupMember.Read.All. Dies ist keine additive Berechtigung zu Group.Read.All. Die Kombination beider Rechte ist vollkommen sinnlos, da sie absolut keinen zusätzlichen Zugriff auf Gruppendaten liefert. Group.Read.All beinhaltet bereits den vollen Zugriff auf Mitgliedschafts- und Besitzinformationen.

Die isolierte Rolle von GroupMember.Read.All besteht darin, den Lesezugriff auf Basisinformationen einer Gruppe zu beschränken. Hierzu zählen der Gruppen-Identifier, der Anzeigename sowie die direkten und transitiven Mitgliedschaften (Member und Owner). Der entscheidende Sicherheitsfaktor ist, dass GroupMember.Read.All keinerlei Zugriff auf die dahinterliegenden Gruppenressourcen wie SharePoint-Dateien, Teams-Chats oder Exchange-Postfächer gewährt.

Dadurch positioniert sich GroupMember.Read.All als die perfekte Least-Privilege-Alternative für Skripte und Applikationen, deren einziger Zweck das Reporting, das Auditing von Mitgliedschaften oder die Beantwortung von simplen Governance-Fragen ist (z. B. "In welchen Gruppen ist dieser User Mitglied?").

Ein technisches Detail der Graph API sorgt bei der Nutzung von GroupMember.Read.All häufig für Verwirrung in der PowerShell-Ausgabe. Wenn du die Mitgliedschaft oder den Besitz einer Gruppe über Get-MgGroup abrufst, liefert die API primär ein Array von Account-Identifiern zurück.

Die Graph API ist so konzipiert, dass erweiterte Kontodaten wie Anzeigenamen oder E-Mail-Adressen in der speziellen Eigenschaft additionalProperties gekapselt werden. Versuchst du jedoch, diese aufzulösen, erhältst du oft nur den OData-Typen der Identität.

In diesem Fall liegt kein Fehler im Skript oder in der API vor. Die Ursache liegt in der strengen Berechtigungsprüfung von Entra ID. Die Applikation hat zwar das Recht, die Mitgliedschaft der Gruppe auszulesen, ihr fehlt jedoch die Berechtigung, die Eigenschaften des User-Objekts selbst zu lesen. Um die Metadaten der Identitäten vollständig aufzulösen, muss die Applikation zwingend mit User.ReadBasic.All oder User.Read.All ausgestattet werden. Sobald diese Berechtigung greift, liefert die API die fehlenden Informationen wie displayName, mail oder userPrincipalName direkt in den additionalProperties mit aus.

Die Implementierung von Berechtigungskonzepten in Microsoft 365 erfordert ein tiefes technisches Verständnis der darunterliegenden API-Architektur. Das blinde Zuweisen von Berechtigungen auf Basis ihrer Namensgebung führt unweigerlich zu massiven Sicherheitslücken, da die tatsächliche technische Reichweite – insbesondere bei Application Permissions – oft unterschätzt wird. Die Entscheidung zwischen Group.Read.All und GroupMember.Read.All ist keine reine Funktionalitätsfrage, sondern eine fundamentale Sicherheitsentscheidung.

Durch die Zuweisung von Group.Read.All öffnest du einer Applikation die Türen zu den sensibelsten unstrukturierten Daten deiner Organisation, da sämtliche SharePoint-, Teams- und Exchange-Ressourcen der Gruppen offengelegt werden. In einer Welt, in der Cloud-Technologien und Identitäten den neuen Sicherheitsperimeter bilden, muss jeder API-Zugriff kritisch validiert werden. Die konsequente Nutzung von GroupMember.Read.All in Kombination mit User.ReadBasic.All für reine Automatisierungs- und Reporting-Skripte reduziert die Angriffsfläche drastisch. Es ermöglicht Administratoren, ihre operativen Governance-Aufgaben vollumfänglich zu erfüllen, ohne das Least-Privilege-Prinzip zu verletzen. Letztlich ist IT-Sicherheit nicht dazu da, die Arbeit zu blockieren, sondern sie auf eine sichere und kontrollierte Weise zu ermöglichen. Die korrekte Konfiguration von Microsoft Graph ist hierfür der wichtigste architektonische Baustein.