Outlook zeigt neue Delegierungsrechte nicht sofort: Ursachen in Replikation, Tokens und Autodiscover

Wie Exchange Online Delegierungs- und Sende-Rechte verarbeitet: Postfachberechtigungen, Entra-ID-Tokens und Outlook-Authentifizierung

Damit Delegierungs- und Sende-Rechte in Outlook zuverlässig einzuordnen sind, muss die Verarbeitungskette in Exchange Online getrennt betrachtet werden: (1) welche Berechtigungen serverseitig am Postfachobjekt bzw. am Empfänger-/Verzeichnisobjekt hinterlegt sind, (2) wie Microsoft Entra ID (Azure AD) darauf basierende Zugriffstoken ausstellt und aktualisiert, und (3) wie Outlook diese Token und die über Autodiscover ermittelten Endpunkte in ein MAPI-over-HTTP-Profil übersetzt. Verzögerungen entstehen häufig nicht, weil „Exchange langsam“ ist, sondern weil mehrere Schichten mit eigenen Caches und Aktualisierungszyklen zusammenspielen.

Serverseitige Berechtigungen: Mailbox-ACLs vs. Empfänger-/Verzeichnisberechtigungen

Exchange Online kennt verschiedene Berechtigungstypen, die technisch nicht identisch gespeichert und ausgewertet werden. FullAccess (Vollzugriff) ist eine Postfachberechtigung, die den Zugriff auf Ordnerinhalte und Postfachelemente ermöglicht. SendAs und SendOnBehalf betreffen dagegen das Senden mit einer anderen Absenderidentität und werden bei der Nachrichtenerstellung und -übermittlung geprüft.

Wichtig ist die Unterscheidung, wo die jeweilige Berechtigung „lebt“: FullAccess wird als Exchange-Mailboxberechtigung auf dem Postfachobjekt geführt (vereinfacht: eine Access Control List, die Exchange beim Öffnen des Postfachkontexts auswertet). SendAs ist eine Empfängerberechtigung am Zielobjekt (in Exchange Online über Get-RecipientPermission sichtbar) und wird von Exchange beim Senden anhand der Absender-/Von-Logik geprüft. SendOnBehalf ist eine Eigenschaft des Postfachs (delegierte Absenderliste), die Exchange beim Senden als „im Auftrag von“ auswertet.

Weil diese Rechte in unterschiedlichen Datenpfaden liegen, können sie auch unterschiedlich „schnell“ sichtbar werden: Ein Outlook-Profil kann beispielsweise bereits das zusätzliche Postfach (FullAccess) öffnen, während SendAs beim Senden zunächst noch scheitert – oder umgekehrt, wenn zwar SendOnBehalf gesetzt ist, das Postfach aber nicht geöffnet werden kann.

Token-Ebene: Was Microsoft Entra ID wirklich „cached“

Outlook authentifiziert sich gegen Exchange Online über OAuth 2.0 (Modern Authentication). Dabei erhält der Client Zugriffstoken (Access Tokens) mit kurzer Lebensdauer sowie eine Refresh-Mechanik (Refresh Token bzw. brokerbasierte Erneuerung), um neue Access Tokens zu beziehen. Entscheidend: In den Tokens stehen nicht „alle Exchange-Berechtigungen“ im Detail. Viele delegierte Aktionen werden serverseitig beim Zugriff oder beim Senden anhand der aktuellen Berechtigungen geprüft, nicht allein anhand eines einmal ausgestellten Tokens.

Dennoch existieren tokenbezogene Effekte: Outlook und das zugrunde liegende Authentifizierungsmodul (Web Account Manager/AAD Broker; in aktuellen Office-Builds typischerweise MSAL-basiert) halten Kontoinformationen und Token-Caches lokal vor. Wenn sich die zugrunde liegende Identität ändert (z. B. Passwortänderung, Conditional-Access-Neubewertung, MFA-Status, Gerätecompliance) oder wenn Outlook eine neue Autorisierung anstoßen muss, kann ein „sauberer“ Token-Refresh den Zeitpunkt beeinflussen, ab dem der Client wieder konsistent mit dem Server spricht. Das ist vor allem relevant, wenn der Client in einem Grenzzustand zwischen mehreren Konten/Tenants oder veralteten Anmeldeartefakten arbeitet.

• Access Token (kurzlebig): Outlook nutzt es für den Zugriff auf Exchange Online (z. B. über die Ressource https://outlook.office365.com bzw. die zugehörigen Exchange-Online-Endpunkte); es wird regelmäßig erneuert, ohne dass der Benutzer interaktiv eingreifen muss.
• Refresh-Mechanik und Broker: Windows kann Token über den Broker erneuern; bei Inkonsistenzen helfen Ab- und Anmeldung oder das Entfernen des Kontos aus „Zugriff auf Arbeits- oder Schulkonto“ (kontextabhängig), weil dadurch veraltete Artefakte nicht weiterverwendet werden.
• Berechtigungen werden serverseitig geprüft: Ob ein Benutzer tatsächlich SendAs ausführen darf, entscheidet Exchange beim Senden; ein „Token enthält die neue Delegierung noch nicht“ ist selten die echte Ursache, aber Token-/Brokerzustände können die Fehlersymptome verstärken.

Outlook-Authentifizierung und Sitzungsaufbau: Von Autodiscover zu MAPI/HTTP

Outlook stellt nicht „einfach eine Verbindung zu Exchange her“, sondern initialisiert ein Profil aus mehreren Bausteinen. Zuerst wird über Autodiscover ermittelt, welche Dienstendpunkte und Einstellungen gelten (Mailbox-Serverlogik, MAPI/HTTP-Endpunkte, ggf. Umleitungen). Anschließend baut Outlook MAPI-over-HTTP-Sitzungen auf und erstellt lokale Strukturen (OST, AutoComplete/„Nicknames“, Caches für Ordnerhierarchie und Frei/Gebucht-Informationen). In dieser Phase kann Outlook auch zusätzliche Postfächer automatisch einbinden, wenn die serverseitige Konfiguration es vorsieht (Auto-Mapping, typischerweise ausgelöst durch FullAccess).

Für die Praxis ist entscheidend: Selbst wenn Exchange Online eine Berechtigungsänderung bereits akzeptiert hat, nutzt Outlook bis zum nächsten geeigneten Aktualisierungszeitpunkt häufig weiterhin die vorhandene Profil- und Sitzungslogik. Autodiscover-Ergebnisse können zwischengespeichert sein; außerdem hält Outlook bestehende Verbindungen stabil, statt sie bei jeder Berechtigungsänderung neu aufzubauen. Deshalb sind Symptome wie „Postfach erscheint nicht“, „Beim Senden kommt NDR/Fehler 5.7.x“ oder „Von-Feld zeigt nicht den richtigen Absender“ nicht automatisch ein Hinweis auf fehlende Rechte, sondern häufig auf einen noch nicht erneuerten Clientzustand.

Welche Prüfungen Exchange beim Zugriff und beim Senden durchführt

Beim Öffnen eines zusätzlichen Postfachs prüft Exchange die dazu passende Mailboxberechtigung (z. B. FullAccess). Beim Senden prüft Exchange abhängig vom Szenario: Für SendAs wird kontrolliert, ob der authentifizierte Benutzer als die angegebene Absenderidentität senden darf; für SendOnBehalf wird geprüft, ob der Benutzer in der Delegatenliste des Postfachs enthalten ist. Diese Prüfungen passieren in der Regel erst zum Zeitpunkt der Aktion (Öffnen/Senden) und nicht bereits beim Start von Outlook.

Warum Änderungen verzögert sichtbar werden: Propagation in Exchange, Token-Caches, Autodiscover-Antworten und lokale Outlook-Zwischenspeicher

Wenn Delegierungs- oder Sende-Rechte gerade gesetzt wurden, wirken sie oft nicht „sofort“ in Outlook. Das ist selten ein einzelner Fehler, sondern fast immer das Ergebnis mehrerer, voneinander unabhängiger Zwischenschichten: Exchange muss die Änderung intern propagieren und zur Laufzeit auswerten, Entra ID (Azure AD) stellt Zugriffstoken mit begrenzter Lebensdauer aus, Outlook verwendet diese Token (und weitere lokale Sicherheitsartefakte) weiter, und die Profillogik basiert auf Autodiscover-Antworten, die ebenfalls zwischengespeichert werden. Zusätzlich kommen Outlook-spezifische Caches (Offlinecache/OST, Namensauflösung, „remembered settings“) ins Spiel, die die Wahrnehmung weiter verzerren können.

Propagation und interne Konsistenz in Exchange (Online und Hybrid)

Serverseitige Berechtigungen wie FullAccess, SendAs und SendOnBehalf werden in Exchange verarbeitet und für verschiedene Workloads (MAPI/HTTP, EWS, Transport/Submission) in unterschiedlichen Auswertungspfaden genutzt. Nach einer Änderung muss der neue Zustand innerhalb der Exchange-Infrastruktur propagieren; parallel können noch „alte“ Berechtigungsinformationen in Cache-Schichten existieren. In Exchange Online sind diese Zeiten variabel, weil die Verarbeitung verteilt und mandantenübergreifend optimiert ist; in Hybrid-Szenarien kommt zusätzlich die Replikation zwischen lokaler AD, ggf. Exchange on-premises und Entra ID hinzu.

Wichtig ist die Unterscheidung zwischen „Berechtigung ist gesetzt“ und „Berechtigung wird bereits in allen relevanten Diensten konsistent ausgewertet“. Gerade bei SendAs spielt zusätzlich eine Rolle, dass die Berechtigung beim Senden im Submission-/Transport-Kontext geprüft wird, während FullAccess vor allem die Postfachöffnung betrifft. Dadurch kann es vorkommen, dass ein zusätzliches Postfach bereits geöffnet werden kann, das Senden aber noch abgewiesen wird (oder umgekehrt je nach Clientfluss).

Token-Caches: Warum „Abmelden“ nicht immer sofort alles aktualisiert

Moderne Outlook-Versionen authentifizieren sich in Microsoft-365-Umgebungen über OAuth 2.0. Dafür erhält der Client Zugriffstoken, die typischerweise für eine begrenzte Zeit gültig sind, und eine Refresh-Mechanik, mit der neue Zugriffstoken bezogen werden. Der entscheidende Punkt: Viele Rechteprüfungen hängen nicht nur an „wer ist angemeldet“, sondern daran, welchen Token- und Sitzungsstand der Client gerade nutzt und wann dieser erneuert wird. Wenn Outlook ein gültiges Zugriffstoken besitzt, versucht es häufig, damit weiterzuarbeiten, selbst wenn sich Berechtigungen serverseitig geändert haben.

Je nach Konstellation genügt es daher nicht, Outlook zu schließen und wieder zu öffnen. Manche Zustände bleiben im Windows-Konto-/WAM-Kontext (Web Account Manager) oder in der Office-Identitätsablage erhalten. Ein sauberer Token-Rollover tritt oft erst ein, wenn eine erneute interaktive Anmeldung erzwungen wird oder der Token abläuft bzw. neu ausgestellt werden muss. Das erklärt, warum zwei Benutzer mit identischer Rechtezuweisung unterschiedliche „Wartezeiten“ erleben können: Der Zeitpunkt der letzten Anmeldung und der lokale Brokerzustand sind nicht synchron.

• Typisches Symptom bei Token-Caching: Outlook zeigt weiterhin „Sie haben nicht die Berechtigung, dieses Postfach zu öffnen“, während Outlook on the web (OWA) nach dem Setzen von FullAccess bereits Zugriff erlaubt.
• Typisches Symptom beim Senden: Das Postfach lässt sich öffnen, aber beim Senden als anderer Benutzer erscheint ein NDR/Fehler trotz gesetztem SendAs oder SendOnBehalf; nach einer erneuten Anmelderunde (oder später) funktioniert es plötzlich.
• Administrativer Reality-Check: Serverseitig prüfen mit Get-MailboxPermission -Identity <Postfach> (für FullAccess) und Get-RecipientPermission -Identity <Postfach> (für SendAs), um „noch nicht wirksam/noch nicht überall konsistent“ von „Client hält alten Zustand“ zu trennen.

Autodiscover: Persistente Antworten und Profilinitialisierung als Verzögerungsfaktor

Autodiscover bestimmt, welche Endpunkte Outlook für das Postfach, Freigaben und Zusatzpostfächer nutzt, und ist eng an das Outlook-Profil gekoppelt. In der Praxis ist nicht nur die DNS-/Service-Konfiguration relevant, sondern auch, dass Outlook Autodiscover-Ergebnisse lokal speichert und nicht bei jedem Start eine vollständige Neuermittlung erzwingt. Wenn Rechteänderungen dazu führen, dass Outlook ein Postfach „automatisch“ hinzufügen soll (Automapping bei FullAccess) oder sich die Topologie/Zuordnung ändert (Hybrid, Umzug, Delegate-Szenarien), kann eine persistente Autodiscover-Antwort die Aktualisierung verzögern.

Hinzu kommt: Nicht jede Delegierungsänderung löst zwingend eine sofortige, clientseitige Profilanpassung aus. Automapping ist kein „Live-Feed“, sondern wirkt zuverlässig erst dann, wenn Outlook die relevanten Metadaten erneut bezieht und verarbeitet. Das kann durch Token-/Anmeldestatus, Netzwerkpfad oder schlichte Cache-Laufzeiten beeinflusst werden. Deshalb ist es möglich, dass Outlook on the web das zusätzliche Postfach sofort anbietet, Outlook Desktop aber erst nach einem Autodiscover-Refresh oder einer Profilaktion nachzieht.

• Autodiscover als Engpass: Outlook zeigt ein per FullAccess berechtigtes Postfach nicht in der Ordnerliste, obwohl es serverseitig korrekt gesetzt ist; das manuelle Hinzufügen über Kontoeinstellungen funktioniert dagegen.
• Hybrid-Sonderfall: Wenn Identitäten oder Postfachstandorte kürzlich geändert wurden, kann eine ältere Autodiscover-Antwort noch auf einen veralteten Zugriffspfad verweisen, bis Outlook die Informationen neu abruft.

Lokale Outlook-Zwischenspeicher: OST, Namensauflösung und „zuletzt verwendet“

Outlook hält eine Reihe lokaler Zustände, die indirekt wie „fehlende Berechtigungen“ aussehen können. Der Exchange-Cachemodus erzeugt eine OST-Datei, in der freigegebene Ordnerinhalte abhängig von Einstellungen und Outlook-Version (z. B. „Freigegebene Ordner herunterladen“) lokal zwischengespeichert werden. Wenn ein Postfach neu hinzukommt, kann der Client zwar bereits Zugriff haben, aber die Darstellung (Ordnerbaum, Elemente, Absenderauswahl) hinkt hinterher, bis Synchronisierung und interne Indizes aktualisiert sind.

Auch die Namensauflösung und die Absenderauswahl sind cachegetrieben. Beim Senden „Als“ oder „Im Auftrag von“ hängt die UI davon ab, ob Outlook den Absender als gültig auflösen kann und ob das betreffende Objekt im lokalen Adressbuch-/Offline-Adressbuch-Kontext verfügbar ist. Das führt zu Situationen, in denen die Berechtigung serverseitig bereits greift, die Absenderzeile aber nicht stabil angeboten wird oder eine zuvor fehlerhafte Auswahl „kleben bleibt“.

• Synchronisationsverzug statt Berechtigungsproblem: Nach neuem FullAccess ist das Postfach sichtbar, aber Ordner/Elemente erscheinen zeitversetzt, weil OST-Synchronisierung und Indizierung nachlaufen.
• Adressauflösung als Stolperstein: Beim Eintragen des Absenders in „Von“ wird der Name nicht aufgelöst oder springt zurück; häufig korreliert das mit veralteter Offlineadressbuch-/GAL-Auflösung, nicht mit fehlendem SendAs.
• Praktische Abgrenzung: Wenn OWA bereits korrekt „Senden als“ ermöglicht, Outlook aber nicht, liegt die Ursache sehr häufig in lokalem Zustand (Token/UI/Cache) und nicht in Get-RecipientPermission-Berechtigungen.

Praxisdiagnose und Maßnahmen: Abgrenzung mit Outlook on the Web, kontrollierte Tests und gezielte Schritte bis zur Profilneuerstellung (inklusive Hybrid- und SendAs/SendOnBehalf-Sonderfällen)

Wenn neu vergebene Delegierungs-, FullAccess– oder Sende-Rechte in Outlook scheinbar „nicht greifen“, sollte die Diagnose strikt zwischen Serverzustand und Clientzustand trennen. Outlook on the Web (OWA) eignet sich dabei als Referenz, weil es ohne lokales Outlook-Profil, ohne OST und mit eigener Authentifizierungskette arbeitet. Das Ziel der folgenden Schritte ist nicht „blindes Cache-Löschen“, sondern eine kontrollierte Eingrenzung, ob die Verzögerung aus Propagation/Directory-Änderungen, aus Token-/Autodiscover-Caches oder aus Outlook-Profilzuständen stammt.

Abgrenzung: Wirkt das Recht serverseitig bereits? (OWA als Referenz)

Der erste Test erfolgt immer mit OWA: Anmeldung am Zielpostfach bzw. Öffnen des delegierten Postfachs über die Konten-/Profilfunktionen in OWA. Funktioniert der Zugriff dort (Ordner sichtbar, Inhalte abrufbar, Versand wie erwartet), ist die serverseitige Berechtigung in der Regel korrekt gesetzt und zumindest in dem Teil der Dienstinfrastruktur wirksam, der die OWA-Sitzung bedient. Scheitert OWA hingegen ebenfalls, liegt der Fokus auf dem tatsächlichen Berechtigungsstand, auf Propagation/Verzeichnisänderungen und (in Hybrid-Szenarien) auf der Konsistenz zwischen On-Premises-Verzeichnis und Exchange Online.

Kontrollierte Tests: Rechtezustand und Zielobjekt verifizieren (bevor Maßnahmen am Client beginnen)

Bevor Outlook-seitig eingegriffen wird, sollte der Rechtezustand mit eindeutigen Identitäten geprüft werden (UPN/Primäre SMTP/Objekt-ID statt nur Anzeigenamen). Besonders bei gleichnamigen Postfächern, kürzlich umbenannten Konten oder Gast-/B2B-Konstellationen entstehen sonst Fehldiagnosen. Zusätzlich ist relevant, welche Rechte tatsächlich benötigt werden: Für das Öffnen eines Postfachs in Outlook ist typischerweise FullAccess relevant; für den Versand aus dem fremden Postfach SendAs oder SendOnBehalf. Eine Fehlannahme („FullAccess reicht für SendAs“) ist ein häufiger Grund für vermeintliche „Replikationsprobleme“.

• FullAccess prüfen (Exchange Online): Get-MailboxPermission -Identity <ZielMailbox> | Where-Object { $_.User -like "*<Delegierter>*" -and $_.AccessRights -contains "FullAccess" -and -not $_.IsInherited }
• SendAs prüfen (Exchange Online): Get-RecipientPermission -Identity <ZielMailbox> | Where-Object { $_.Trustee -like "*<Delegierter>*" -and $_.AccessRights -contains "SendAs" }
• SendOnBehalf prüfen: Get-Mailbox -Identity <ZielMailbox> | Select-Object -ExpandProperty GrantSendOnBehalfTo
• Automapping-Status einordnen: Get-MailboxPermission -Identity <ZielMailbox> -User <Delegierter> | Select-Object AccessRights,IsInherited,Deny,InheritanceType
• OWA-Referenztest (Endanwender-URL): https://outlook.office.com/mail/

Wenn die Cmdlets die Rechte korrekt anzeigen, OWA aber weiterhin verweigert, ist die häufigste Ursache kein Outlook-Cache, sondern eine noch nicht durchgängig wirksame Änderung (Propagation) oder ein falsches Zielobjekt (z. B. Berechtigung auf falscher Mailbox gesetzt). In Hybrid-Umgebungen ist außerdem zu klären, ob das Objekt (z. B. RemoteMailbox/MailUser) maßgeblich On-Premises verwaltet wird und Änderungen nur dort dauerhaft sind.

Gezielte Beschleunigung: Maßnahmen mit minimalem Eingriff (vom Token bis zum Postfach-Neuaufbau)

Wenn OWA bereits korrekt funktioniert, wird der Fokus auf Outlook gelegt. Die folgende Reihenfolge ist absichtlich von „leicht und reversibel“ zu „eingriffsintensiv“ aufgebaut. Nach jedem Schritt empfiehlt sich ein klarer Testpunkt (Outlook neu starten, Postfach öffnen, Testmail mit „Von“ senden) statt mehrere Änderungen zu stapeln.

• Outlook vollständig beenden und Identitäts-Token erneuern: Outlook schließen (inkl. Tray), anschließend in Windows unter Einstellungen > Konten > Auf Arbeits- oder Schulkonto zugreifen das betroffene Konto trennen und wieder verbinden oder in Office oben rechts abmelden/anmelden; danach Outlook starten.
• Gespeicherte Anmeldeinformationen prüfen (nur wenn Anomalien sichtbar sind): im Credential Manager unter Windows-Anmeldeinformationen bzw. Webanmeldeinformationen Einträge zu MicrosoftOffice, ADAL, MSOID oder Outlook gezielt entfernen; danach erneute Anmeldung auslösen.
• Outlook „Von“-Feld und Absenderauswahl kontrollieren: in neuer Nachricht Optionen > Von aktivieren; als Absender über Von > Andere E-Mail-Adresse... die primäre SMTP des Zielpostfachs auswählen (nicht nur per Anzeigename). Damit werden Fehlauflösungen gegen veraltete Einträge im AutoComplete reduziert.
• AutoComplete-Eintrag für Absender bereinigen (bei falscher Auflösung): im „Von“-Auswahldialog den falschen Vorschlag entfernen; alternativ AutoComplete-Liste gezielt leeren über Datei > Optionen > E-Mail > Nachrichten senden > AutoVervollständigen-Liste leeren.
• Delegiertes Postfach entfernen und erneut hinzufügen (ohne Profilneubau): Datei > Kontoeinstellungen > Kontoeinstellungen > Ändern > Weitere Einstellungen > Erweitert und das zusätzliche Postfach entfernen, Outlook schließen, wieder hinzufügen, Outlook starten; bei Automapping-Szenarien ggf. zunächst nur manuell hinzufügen, um das Ergebnis zu verifizieren.
• Zwischenspeicherung gezielt als Test deaktivieren (nur kurzfristig): testweise „Exchange-Cache-Modus“ für das Konto deaktivieren (Outlook neu starten) um zu prüfen, ob ausschließlich OST-/Sync-Zustand blockiert; danach in der Regel wieder aktivieren.
• Neue Outlook-Profilinitialisierung als letzter Schritt: in der Systemsteuerung Mail (Microsoft Outlook) ein neues Profil anlegen (Profile anzeigen), Konto neu hinzufügen und delegierte Postfächer erst nach erfolgreichem Primärlogin ergänzen; der Schritt ist besonders wirksam, wenn Autodiscover- oder Identitätszustände im Profil „festhängen“.

Sonderfälle: Hybrid-Umgebungen sowie SendAs vs. SendOnBehalf in der Praxis

In Hybrid-Szenarien entscheidet die Autorität des Objekts, wo Rechte dauerhaft gepflegt werden. Bei Exchange-Hybrid mit synchronisierten Identitäten gilt häufig: Postfachbezogene Berechtigungen werden in Exchange Online gesetzt, Objektattribute (wie Delegationslisten, je nach Konfiguration) können jedoch von On-Premises überschrieben werden. Treten Rechte „sporadisch“ auf oder verschwinden wieder, ist eine typische Ursache eine nachgelagerte Synchronisation, die den gewünschten Zustand zurücksetzt. Hier sollte geprüft werden, ob die Änderung am korrekten Ort vorgenommen wurde und ob Governance/Provisioning-Prozesse eingreifen.

Bei SendAs und SendOnBehalf sind unterschiedliche Fehlbilder zu erwarten. SendOnBehalf zeigt für Empfänger sichtbar „im Auftrag von“ und hängt an der Mailbox-Konfiguration; SendAs lässt die Nachricht so erscheinen, als käme sie direkt vom Zielpostfach, und basiert auf einem separaten Berechtigungseintrag. In Outlook können beide Varianten zusätzlich von lokaler Adressauflösung und vom „Von“-Handling beeinflusst werden. Ein sauberes Testdesign ist daher: (1) OWA-Versand als Referenz, (2) Outlook-Versand mit expliziter Eingabe der SMTP im „Von“-Feld, (3) erst danach Cache-/Profilmaßnahmen. Nur so lässt sich vermeiden, dass ein reines UI-/Auflösungsproblem fälschlich als „Replikation“ eskaliert wird.