Exchange Online Berechtigungen prüfen: Welche Cmdlets zeigen welche Rechte wirklich (Mailbox, Shared, Raum, Gruppe)?

Berechtigungsmodelle in Exchange Online: Mailbox, Ordner, Empfänger und Gruppen sauber auseinanderhalten

Exchange Online bildet „Berechtigung“ nicht als einheitliches Konzept ab, sondern als Bündel separater Modelle. In der Praxis entstehen Fehlinterpretationen vor allem dann, wenn Ergebnisse aus unterschiedlichen Ebenen vermischt werden: Objektberechtigungen an der Mailbox (wer darf welche Mailbox öffnen), Berechtigungen an Ordnern (wer darf in einen bestimmten Ordner), Empfängerberechtigungen (wer darf „Send As“ oder „Send on Behalf“), sowie Gruppenmitgliedschaften und Gruppen-Moderation. Eine saubere Trennung dieser Ebenen ist Voraussetzung, um Rechteprobleme reproduzierbar zu prüfen, statt Effekte durch erneute Vergabe zu überdecken.

Vier Ebenen, vier Datenquellen: Warum ein Cmdlet nie die ganze Wahrheit liefert

Das Mailbox-Objekt hat eigene Delegationsrechte (klassisch „Full Access“ und „Send As“), die nicht identisch sind mit Ordnerrechten. „Full Access“ erlaubt das Öffnen der gesamten Mailbox, sagt aber nichts darüber aus, ob ein bestimmter Ordner im Client sichtbar wird. Umgekehrt kann ein Ordnerrecht (z. B. auf Kalender) ohne Full Access existieren und wirkt dann nur auf diesen Ordner. „Send As“ wiederum ist eine Empfängerberechtigung am AD/Recipient-Objekt; sie ist technisch nicht an Ordner oder Mailboxzugriff gekoppelt. „Send on Behalf“ ist keine klassische Access Control List (ACL), sondern wird über die Delegationseigenschaft am Empfängerobjekt abgebildet, was Auswirkungen auf Abfrage und Auswertung hat.

Gruppen (Distribution Groups und Microsoft 365 Groups) bringen zusätzliche Modelle ins Spiel: Mitgliedschaft, Besitzer, Moderation, Message Approval, sowie optionale Beschränkungen wie „nur interne Absender“. Diese Mechanismen entscheiden über Zustellung und Senden-an, nicht über Ordnerzugriff. Für die Fehlersuche ist daher zuerst zu klären, welche Wirkung beobachtet wird: Öffnen, Lesen/Schreiben in Ordnern, Senden als/ im Auftrag, oder Zustell-/Sende-Berechtigung über Gruppenregeln.

Mailboxdelegation vs. Ordner-ACL: Was „sichtbar“ ist und was nicht

Mailboxdelegation (Full Access) wird über Mailbox-ACLs abgebildet und lässt sich mit den üblichen Cmdlets zuverlässig auslesen. Sichtbarkeit im Client ist damit aber nicht automatisch erklärt, weil Outlook und OWA zusätzliche Logik anwenden: Automapping steuert die automatische Einbindung in Outlook, nicht den effektiven Zugriff. Außerdem wirken Ordner-ACLs unabhängig davon; ein explizites Deny auf Ordnerebene kann Zugriff verhindern, obwohl Full Access existiert. Die umgekehrte Richtung ist häufiger: Ein Kalender wird per Ordnerrecht geteilt, obwohl kein Full Access gesetzt ist. Dann erscheinen im Client häufig nur einzelne Ordner (oder freigegebene Kalender), was bei der Analyse als „fehlende Mailboxberechtigung“ missverstanden wird.

Ordnerberechtigungen besitzen zudem ein Vererbungsmodell innerhalb der Ordnerhierarchie. Standardrechte wie Default und Anonymous sind keine Personen, sondern Platzhalteridentitäten, die in Ausgaben regelmäßig mit echten Einträgen vermengt werden. Auch sind nicht alle sichtbaren Effekte als ACL-Eintrag abfragbar: Freigaben über moderne „Sharing“-Erfahrungen können in Clients als „geteilt“ erscheinen, obwohl das zugrunde liegende Konstrukt weiterhin klassische Ordnerrechte und/oder Sharing-Policies nutzt. Für eine belastbare Prüfung zählt am Ende die konkrete ACL auf dem betroffenen Pfad.

• Mailbox-ACL prüfen (Full Access): Get-MailboxPermission -Identity <MailboxId> | Where-Object {$_.User -notlike "NT AUTHORITY\SELF"}
• Ordner-ACL am konkreten Pfad prüfen: Get-MailboxFolderPermission -Identity "<MailboxId>:\Kalender"
Get-MailboxFolderPermission -Identity "<MailboxId>:\Posteingang\Unterordner"
• Standardidentitäten einordnen: Get-MailboxFolderPermission -Identity "<MailboxId>:\Kalender" | Where-Object {$_.User -in @("Default","Anonymous")}
• Automapping von Berechtigung trennen (Zuweisungsquelle sichtbar machen): Get-MailboxPermission -Identity <MailboxId> | Select User,AccessRights,IsInherited,Deny

Empfängerrechte: „Send As“ und „Send on Behalf“ sind unterschiedliche Mechaniken

„Send As“ wird als Empfängerberechtigung geführt und erscheint nicht in Get-MailboxPermission. Für Troubleshooting ist relevant, dass „Send As“ oft als vermeintliches Mailboxrecht gesucht wird, obwohl es am Recipient hängt und deshalb mit Get-RecipientPermission zu prüfen ist. Zusätzlich existieren Edge-Cases: Manche Einträge in der Ausgabe entsprechen System- oder Dienstprinzipalen und sind für Endanwender nicht relevant; sie sollten die Auswertung nicht dominieren. „Send on Behalf“ ist wiederum keine ACL wie „Send As“, sondern eine Eigenschaft am Empfängerobjekt; die Abfrage läuft über GrantSendOnBehalfTo. Beide Modelle können parallel existieren und produzieren im Client ähnliche, aber nicht identische From:-Darstellungen.

Outlook- und OWA-Verhalten verzerren zudem die Wahrnehmung: Ein erfolgreiches Senden beweist nicht, dass das erwartete Recht gesetzt ist; Cached Mode, gespeicherte From:-Einträge und unterschiedliche Compose-Flows können dazu führen, dass ein anderer Absender verwendet wurde als angenommen. Umgekehrt kann ein korrekt gesetztes Recht temporär „nicht wirken“, wenn Offline Address Book oder Autocomplete veraltete Daten liefern. Für die technische Prüfung zählt ausschließlich die serverseitige Berechtigungslage am Empfängerobjekt.

• „Send As“ am Empfänger prüfen: Get-RecipientPermission -Identity <MailboxOrGroupId> | Where-Object {$_.AccessRights -contains "SendAs"}
• „Send on Behalf“ am Empfänger prüfen: Get-Mailbox -Identity <MailboxId> | Select-Object -ExpandProperty GrantSendOnBehalfTo
• Fehlannahme vermeiden („Send As“ ist nicht „Full Access“): Get-MailboxPermission -Identity <MailboxId> | Where-Object {$_.AccessRights -contains "FullAccess"}

Gruppen sauber abgrenzen: Mitgliedschaft, Besitzer, Delivery Management, Moderation

Bei Distribution Groups betrifft „Berechtigung“ primär zwei Achsen: Wer darf an die Gruppe senden (Delivery Management) und wer darf die Gruppe verwalten (Owners/ManagedBy, Moderation). Mitgliedschaft steuert die Zustellung, ist aber nicht automatisch ein „Sende-Recht“, wenn die Gruppe das Senden einschränkt. Moderation verändert den Zustellpfad vollständig; eine Nachricht kann technisch angenommen, aber zur Genehmigung zurückgehalten werden. Diese Zustände werden in Client-Fehlermeldungen nicht immer sauber differenziert. Daher sollten bei Zustellproblemen zunächst die Gruppeneigenschaften geprüft werden, bevor Mailbox- oder Ordnerrechte als Ursache angenommen werden.

Auch hier gilt: Die Abfragen müssen zum Objektmodell passen. Get-DistributionGroupMember beantwortet Mitgliedschaft, nicht Zustellregeln. Get-DistributionGroup liefert Delivery- und Moderationsparameter, aber keine Mailbox-ACLs. In hybriden oder historisch gewachsenen Tenants tauchen zudem Mail-aktivierte Security Groups auf, die sich in der Oberfläche wie Distribution Groups anfühlen, aber im Backend unterschiedliche Verwaltungs- und Berechtigungslogik mitbringen. Für reproduzierbare Analysen ist deshalb die eindeutige Identität (ObjectId/Alias/PrimarySmtpAddress) und der konkrete Gruppentyp entscheidend.

• Mitgliedschaft prüfen: Get-DistributionGroupMember -Identity <GroupId>
• Delivery Management & Moderation prüfen: Get-DistributionGroup -Identity <GroupId> | Select-Object RequireSenderAuthenticationEnabled,AcceptMessagesOnlyFrom,AcceptMessagesOnlyFromDLMembers,RejectMessagesFrom,RejectMessagesFromDLMembers,ModerationEnabled,ModeratedBy,BypassModerationFromSendersOrMembers,ManagedBy
• Gruppentyp einordnen (Empfängerklasse): Get-Recipient -Identity <GroupId> | Select-Object RecipientType,RecipientTypeDetails

Objekt-Cheat-Sheet: Cmdlets und Rückgaben pro Objekttyp (User/Shared/Resource Mailbox, Distribution Group) inklusive Sichtbarkeitslücken und Vererbung

Die folgenden Zuordnungen trennen konsequent zwischen (a) Rechten auf dem Mailbox-/Ordnerobjekt, (b) Rechten auf AD-/Entra-Objekten wie Gruppenmitgliedschaften sowie (c) Rechten, die aus Outlook/OWA-Funktionalität abgeleitet werden, ohne als klassische Exchange-ACL sichtbar zu sein. Entscheidend ist die Erwartung an die Rückgabe: Viele Cmdlets zeigen ausschließlich explizite Einträge und ignorieren die tatsächliche Effektivität durch Vererbung, Gruppenzugehörigkeit oder Client-Caching.

User/Shared/Resource Mailbox: „Mailbox Permissions“ (Send As, Full Access, Send on behalf)

User Mailbox, Shared Mailbox und Resource Mailbox (Room/Equipment) verhalten sich bei den Kernberechtigungen weitgehend identisch. Unterschiede entstehen weniger im ACL-Modell als durch Client- und Protokollbesonderheiten: Full Access kann Auto-Mapping auslösen, das die Sichtbarkeit in Outlook prägt, ohne die tatsächliche Berechtigung zu verändern. „Send on behalf“ ist zudem kein klassischer ACL-Eintrag auf dem Postfach, sondern ein Attribut am Postfachobjekt.

• Full Access prüfen (explizit): Get-MailboxPermission -Identity <Mailbox> | Where-Object { $_.AccessRights -contains "FullAccess" -and -not $_.Deny }
• Send As prüfen (explizit): Get-RecipientPermission -Identity <Mailbox> | Where-Object { $_.AccessRights -contains "SendAs" -and -not $_.Deny }
• Send on behalf prüfen: Get-Mailbox -Identity <Mailbox> | Select-Object -ExpandProperty GrantSendOnBehalfTo
• Gruppen-basiertes Recht nachvollziehen: Get-RecipientPermission -Identity <Mailbox>
Get-DistributionGroupMember -Identity <Group> -ResultSize Unlimited

Mailbox-Ordnerberechtigungen: Kalender/Inbox/Custom Folder und Vererbung im Ordnerbaum

Ordnerberechtigungen sind MAPI/Store-basiert und werden über Get-MailboxFolderPermission sichtbar. Hier existiert eine echte Ordnerhierarchie: Berechtigungen auf \Kalender wirken nicht automatisch auf Unterordner; Vererbung ist im Mailbox-Store kein universelles Konzept wie in NTFS. Häufig entsteht Verwirrung, weil „Default“ und „Anonymous“ Einträge kein Delegationsartefakt sind, sondern Basiseinträge, die für Frei/Gebucht- oder anonyme Szenarien relevant sein können.

Distribution Group: Mitgliedschaft, Senden, Moderation – getrennte Prüfpfade

Distribution Groups vereinen mehrere Mechanismen, die in Störungen regelmäßig vermischt werden: Mitgliedschaft (Wer empfängt?), Zustellbeschränkungen (Wer darf senden?), und Moderation (Wer genehmigt?). Für die Fehlersuche ist relevant, dass „darf senden“ nicht über Get-RecipientPermission der Gruppe ausgedrückt werden muss, sondern über gruppenspezifische Eigenschaften. Zusätzlich können „Send As“ und „Send on behalf“ auch für Gruppen existieren, werden jedoch über andere Cmdlets sichtbar als die klassischen Zustelllisten.

• Mitglieder (statisch): Get-DistributionGroupMember -Identity <DG> -ResultSize Unlimited
• Mitglieder (dynamisch): Get-DynamicDistributionGroup -Identity <DDG>
Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup <DDG>).RecipientFilter -ResultSize Unlimited
• Wer darf an die Gruppe senden (Delivery Management): Get-DistributionGroup -Identity <DG> | Select-Object RequireSenderAuthenticationEnabled,AcceptMessagesOnlyFrom,AcceptMessagesOnlyFromDLMembers,RejectMessagesFrom,RejectMessagesFromDLMembers
• Moderation und Bypass: Get-DistributionGroup -Identity <DG> | Select-Object ModerationEnabled,ModeratedBy,BypassModerationFromSendersOrMembers
• Send As auf der Gruppe (falls genutzt): Get-RecipientPermission -Identity <DG> | Where-Object { $_.AccessRights -contains "SendAs" -and -not $_.Deny }

Sichtbarkeitslücken entstehen hier vor allem durch verschachtelte Gruppen und dynamische Regeln: Ein Absender kann effektiv berechtigt sein, obwohl er in AcceptMessagesOnlyFrom nicht namentlich erscheint, weil er Mitglied einer zugelassenen Gruppe ist. Umgekehrt kann ein erlaubter Eintrag wirkungslos bleiben, wenn der Absender beim Versand als anderer Identität auftritt (z. B. über eine freigegebene Mailbox) und dadurch nicht gegen die erwartete Absenderadresse geprüft wird.

Typische Missverständnisse und Praxischecks: Outlook-/OWA-Eigenheiten, Caching, „Send As“ vs. „Send on Behalf“ und reproduzierbare Fehleranalyse

Outlook, OWA und die „gefühlte“ Berechtigung: Warum UI und Serverzustand auseinanderlaufen

Viele Berechtigungsfälle wirken widersprüchlich, weil Clients nicht ausschließlich den aktuellen Serverzustand abbilden. Outlook (Desktop) kombiniert Autodiscover-Informationen, lokale Profile, Offline-Adressbuch (OAB) und Caches für Free/Busy bzw. Verfügbarkeitsdaten. OWA (Outlook on the web) zeigt dagegen meist unmittelbarer den Serverzustand, hat aber eigene Einschränkungen (z. B. bei der Darstellung zusätzlicher Postfächer oder beim Verhalten des „Von“-Felds). Daraus entstehen Situationen, in denen Rechte korrekt gesetzt sind, der Effekt aber erst verzögert oder nur in einem Client sichtbar wird.

Ein häufiger Irrtum: „Berechtigung fehlt“, obwohl tatsächlich ein anderer Pfad scheitert. Beispiel: Ein zusätzliches Postfach lässt sich in Outlook öffnen, aber Ordner fehlen. Das ist oft kein fehlendes FullAccess, sondern eine Kombination aus Automapping, Profilzustand und Ordnersicht, oder ein Problem mit „Default“-Berechtigungen auf dem Kalender/Top of Information Store. Umgekehrt kann OWA Zugriff suggerieren (weil ein freigegebener Ordnerlink existiert), während MAPI/EWS-Aktionen in Outlook an fehlenden Rechten auf dem betreffenden Ordner scheitern.

„Send As“ vs. „Send on Behalf“: Unterschiedliche Speicherorte, unterschiedliche Auswertung

„Send As“ und „Send on Behalf“ werden häufig gleichgesetzt, haben aber technische Unterschiede: SendAs ist ein AD-Recht und wird durch Exchange beim Senden serverseitig geprüft; SendOnBehalf ist eine Eigenschaft des Postfach-/Gruppenobjekts, die beim Erzeugen der Nachricht ausgewertet wird und im „Von“-Feld als „A im Auftrag von B“ erscheint. Beide können parallel gesetzt sein, was zu uneinheitlichen Ergebnissen führt, wenn Clients unterschiedliche Mechanismen bevorzugen oder zwischengespeicherte Empfängerdaten verwenden.

Besonders tückisch: Die „Von“-Auswahl in Outlook hängt stark von der Auflösung der Absenderidentität ab (AutoComplete/„Vorschläge“, GAL/OAB, zuletzt verwendete Absender). Ein vorhandenes „Send As“ kann technisch korrekt sein, trotzdem schlägt der Versand fehl, wenn eine andere Absenderidentität gewählt wurde (z. B. ein Kontaktobjekt statt der tatsächlichen Mailbox, oder ein veralteter LegacyDN-Eintrag). Fehlermeldungen lauten dann oft generisch („Sie besitzen nicht die Berechtigung, im Namen dieses Benutzers zu senden“), obwohl die Ursache in der Absenderauflösung liegt.

Caching und Replikation: Warum „gesetzt“ nicht gleich „wirkt“ ist

In Exchange Online gibt es keine klassische AD-Replikation wie on-premises, dennoch treten Verzögerungen auf: Änderungen an Empfängerobjekten, an Berechtigungen und an Mitgliedschaften benötigen Zeit, bis sie in allen relevanten Verzeichnissichten und Token- bzw. Zugriffspfaden konsistent sind. Zusätzlich arbeitet Outlook mit lokalen Artefakten: OAB (je nach Modus), AutoComplete, Profil-Caches und lokale Delegateninformationen. Dadurch kann die symptomatische Lage stundenlang „kleben“, obwohl die Konfiguration bereits korrigiert wurde.

Für reproduzierbare Checks ist entscheidend, den Zugriffspfad festzulegen. Eine Nachricht „Send As“ kann in OWA sofort funktionieren, während Outlook weiterhin scheitert, weil ein bereits geöffnetes MAPI-Session-Token oder ein altes AutoComplete-Objekt genutzt wird. Umgekehrt kann Outlook (Cached Mode) eine GAL-Information zeigen, die erst nach OAB-Update korrigiert wird, während serverseitige Cmdlets bereits den neuen Zustand liefern.

• AutoComplete als Fehlerquelle: In Outlook kann ein veralteter Eintrag die Absenderauflösung verfälschen; als Gegenprobe eignet sich das manuelle Auswählen aus der GAL oder OWA sowie ein Vergleich der aufgelösten Adresse in den Nachrichteneigenschaften (praktische Cmdlet-Seite: Get-Recipient -Identity <String> | Select Name,RecipientTypeDetails,PrimarySmtpAddress,ExternalDirectoryObjectId).
• OAB/GAL-Divergenz: Abweichungen zwischen Outlook (Cached Mode) und OWA sprechen oft für einen OAB-/Cache-Effekt; als objektiver Zustand gilt der Cmdlet-Output, z. B. Get-Mailbox -Identity <Mailbox> | Select DisplayName,Alias,RecipientTypeDetails.
• Token-/Sitzungszustand: Nach Berechtigungsänderungen kann ein kompletter Neustart von Outlook und eine neue Anmeldung in OWA als Kontrollpunkt dienen; serverseitig bleibt die Prüfung über Get-RecipientPermission bzw. Get-MailboxPermission maßgeblich, nicht die UI-Anzeige.
• Mitgliedschaften und verschachtelte Gruppen: Effektive Rechte können von Gruppen abhängen, die im Client „unsichtbar“ bleiben; die Mitgliedschaft sollte mit Get-DistributionGroupMember -Identity <Group> (und bei Verschachtelung iterativ) nachvollzogen werden, statt nur die direkt gesetzten Einträge zu betrachten.

Praxischecks für eine reproduzierbare Fehleranalyse (statt „Neu vergeben“)

Eine belastbare Analyse trennt „Konfiguration“ von „Symptom“. Dazu gehört, das betroffene Objekt (Mailbox, Shared Mailbox, Raum, Gruppe) eindeutig zu identifizieren, den betroffenen Vorgang (Ordnerzugriff, Kalenderanzeige, Senden als, Senden im Auftrag, Automapping) zu isolieren und dann mit passenden Cmdlets exakt die zugehörigen Rechte und Eigenschaften zu prüfen. Erst wenn die technische Sicht konsistent ist, lohnt der Blick auf Clientbesonderheiten.

Typische Anti-Patterns verschleiern Ursachen: FullAccess wird „zur Sicherheit“ neu gesetzt, obwohl das Problem ein fehlendes SendAs ist; Delegation wird gesetzt, obwohl der Benutzer über eine Gruppe bereits berechtigt ist und Outlook nur den Gruppenpfad nicht transparent macht; oder „es funktioniert in OWA“ wird als Entwarnung interpretiert, obwohl ein MAPI-spezifisches Szenario betroffen ist (z. B. Zugriff auf einen bestimmten Ordner, der in OWA gar nicht genutzt wird).

• Objekt- und Identitätscheck (Eindeutigkeit): Get-EXOMailbox -Identity <UPNOrAlias> -PropertySets Minimum | Select DisplayName,PrimarySmtpAddress,ExternalDirectoryObjectId,RecipientTypeDetails
• Send-As-Rechte (direkte Einträge, keine Vermischung): Get-RecipientPermission -Identity <MailboxOrGroup> | Select Trustee,AccessRights,IsInherited,Deny
• Send-on-Behalf (Eigenschaft, nicht „Berechtigung“): Get-Mailbox -Identity <Mailbox> | Select -ExpandProperty GrantSendOnBehalfTo
Get-DistributionGroup -Identity <Group> | Select -ExpandProperty GrantSendOnBehalfTo
• FullAccess vs. Automapping (Symptomtrennung): Get-MailboxPermission -Identity <Mailbox> | ? {$_.User -notlike "NT AUTHORITY\\SELF"} | Select User,AccessRights,IsInherited,Deny
Get-MailboxPermission -Identity <Mailbox> -User <User> | Select AccessRights
• Client-Gegenprobe (Pfadwechsel): Versand/Öffnen in OWA und Outlook getrennt testen und die Absender-/Zielidentität erneut aus der GAL auswählen; serverseitige Bestätigung parallel über Get-Recipient -Identity <SMTP> und die oben genannten Berechtigungscmdlets.