Viele Admins verlassen sich seit Jahren auf Integrationen, die in Exchange Online über Exchange Web Services (EWS) und die Rolle ApplicationImpersonation laufen. Vor allem bei Backup-Lösungen, Archivierungs-Tools oder Raumbuchungssystemen hat man die alten Schnittstellen und Berechtigungen lange einfach weiterlaufen lassen. Lange geht das nicht mehr gut. Microsoft hat angekündigt, EWS in Exchange Online zum 1. Oktober 2026 abzuschalten (Retirement of Exchange Web Services), und entfernt bereits schrittweise die RBAC-Rolle ApplicationImpersonation. Trotzdem finde ich in vielen Tenants, die ich betreue, noch Service-Accounts mit genau diesen Berechtigungen. Oft hat sie seit Jahren niemand mehr angefasst, und zuständig fühlt sich auch keiner. Spätestens 2025 wird daraus ein echtes Problem, denn neue Zuweisungen von ApplicationImpersonation sind schon heute nicht mehr möglich, und ab Februar 2025 werden auch die bestehenden entfernt.

Microsoft schaltet EWS ab und streicht die Rolle ApplicationImpersonation

Für automatisiertes Mailbox-Management, Migrationen oder Tools von Drittanbietern war EWS lange die naheliegende Schnittstelle. Backup-Lösungen und Migrationsdienste haben sie besonders gern genutzt, weil sie darüber bequem sämtliche Postfächer im Tenant auslesen konnten. Häufig steckte dahinter ein Account mit ApplicationImpersonation, der sich als beliebige Benutzerin ausgeben durfte. Aus heutiger Sicht ist das natürlich höchst bedenklich, und mich wundert es nicht, dass Microsoft diesem Modell ein Ende setzt. Einerseits wird EWS in Exchange Online im Oktober 2026 endgültig abgeschaltet. Andererseits lässt sich die klassische Rolle ApplicationImpersonation im RBAC von Exchange Online bereits seit Mai 2024 nicht mehr zuweisen, und ab Februar 2025 verschwindet sie ganz. Wer noch Integrationen oder Servicekonten mit EWS und ApplicationImpersonation entdeckt, sollte deshalb jetzt tätig werden, spätestens aber im Laufe des Jahres 2025.

Aus diesem Zeitplan ergibt sich für solche Integrationen ungefähr folgender Ablauf:

flowchart TD
  Start["Alte EWS-Integration im Einsatz"] --> CheckImpersonation["ApplicationImpersonation zugewiesen?"]
  CheckImpersonation -->|"Ja"| Risk["Kritisch: Entzug ab Feb 2025"]
  CheckImpersonation -->|"Nein"| EWSOnly["Nur EWS-Berechtigung"]
  Risk --> Migrate["Umstellung auf Graph nötig"]
  EWSOnly --> Migrate
  Migrate --> EWSRetirement["EWS-Ende am 1.10.2026"]

Abbildung: Zeitstrahl für EWS und ApplicationImpersonation in Exchange Online

Viele ältere Backup- und Archiv-Tools stellt das vor eine echte Herausforderung. Daneben müssen auch etliche interne Skripte und Migrationsjobs auf neue Schnittstellen und Berechtigungsmodelle umgebaut werden.

Betroffene Integrationen spürt man mit PowerShell und Entra ID auf

Eine vollständige Liste aller Altanwendungen, die im Tenant noch mit EWS und ApplicationImpersonation arbeiten, hat nach meiner Erfahrung niemand. Man muss die Fälle also selbst aufspüren und jeden einzelnen prüfen und dokumentieren. Am Anfang steht die Exchange Online PowerShell, mit der sich die bestehenden Rollenzuweisungen auslesen lassen:

# PowerShell 7, Exchange Online Management Modul, Rolle Compliance Management o. Exchange Administrator
Get-ManagementRoleAssignment -Role ApplicationImpersonation

In der Ausgabe stößt man oft auf Service-Accounts oder spezielle Anwendungen, die auf Dutzende Postfächer zugreifen dürfen. Parallel dazu sollte man in Entra ID die App-Registrierungen auf auffällige Berechtigungen durchsehen. Für EWS sind das konkret die delegierte Berechtigung EWS.AccessAsUser.All und die Anwendungsberechtigung full_access_as_app. Im Entra-Portal → App-Registrierungen filtert man dafür nach genau diesen API-Berechtigungen. Wer gründlicher vorgehen möchte, wertet zusätzlich die Anmeldeprotokolle von Entra aus (Protokollierung aktivieren, Lizenz: Entra ID P1) und sucht dort nach Anwendungen, die sich gegen EWS authentifizieren oder die genannten Berechtigungen verwenden.

Aus der Praxis: Backup-Produkte von Drittanbietern arbeiten häufig noch mit EWS und ApplicationImpersonation, obwohl der Hersteller längst eine Graph-Integration im Angebot hat. Mit einem Upgrade ist man hier auf der sicheren Seite.

Bei Herstellern von Buchungs- oder Archivierungslösungen sollte man spätestens jetzt nachfragen, wie ihre Roadmap aussieht. Nicht selten kostet die Umstellung auf aktuelle Schnittstellen extra oder läuft sogar auf eine komplette Neuimplementierung hinaus.

Microsoft Graph und Application RBAC ersetzen das alte Modell

Ohne EWS führt für moderne Integrationen kein Weg mehr an der Microsoft Graph API vorbei (Überblick über die Graph Mail API). Ihr Funktionsumfang deckt inzwischen die allermeisten Szenarien ab und genügt auch für anspruchsvolle Backup- oder Archivierungslösungen. Schwierig wird es bei den Zugriffsrechten. Mit klassischen App-Berechtigungen über Graph kann eine Anwendung oft direkt auf alle Postfächer zugreifen, also ganz ähnlich wie früher mit ApplicationImpersonation. An dieser Stelle ist das neue RBAC for Applications in Exchange Online ein deutlicher Fortschritt. Mit New-ServicePrincipal und gezielten Rollenzuweisungen lässt sich der Zugriff fein auf einzelne Postfächer oder Gruppen von Postfächern begrenzen.

Die Zuweisung läuft ungefähr so ab:

  • Zuerst legt man für die Anwendung einen Service Principal an, sofern es noch keinen gibt.
  • Danach erstellt man per PowerShell einen Management Scope, der etwa nur ausgewählte Postfächer enthält.
  • Zum Schluss weist man dem Service Principal die Exchange-Online-Rolle (z. B. Mailbox Import Export) gezielt für diesen Scope zu.

Ausführlichere Informationen zu Application RBAC und eine Anleitung Schritt für Schritt finden sich in der offiziellen Dokumentation Application RBAC in Exchange Online. Die Lösung ist noch recht jung, läuft in meinen Projekten aber zuverlässig, vorausgesetzt, man arbeitet mit den aktuellen Modulen und verfügt über die nötigen Rollen.

Die Bestandsaufnahme sollte jetzt beginnen

Auch wenn EWS erst 2026 endgültig abgeschaltet wird, sollte man sich spätestens jetzt einen Überblick verschaffen, wo EWS und ApplicationImpersonation noch genutzt werden. Diese Schritte haben sich bewährt:

  1. Bestehende Rollenzuweisungen für ApplicationImpersonation ermitteln (PowerShell)
  2. App-Registrierungen mit EWS-Scopes in Entra ID prüfen und dokumentieren
  3. Bei Drittanbieter-Integrationen nachhaken, ob und wann die Roadmap Graph unterstützt
  4. Eine Pilotmigration auf Microsoft Graph und Application RBAC testen
  5. Service-Accounts und Skripte rechtzeitig umstellen

Vor allem in größeren Umgebungen zahlt es sich aus, schrittweise und sauber dokumentiert zu migrieren und die Verantwortlichkeiten von Anfang an klar zu regeln.

Der Abschied von alten Zöpfen tut weh und bringt mehr Sicherheit

Viele Jahre lang waren EWS und ApplicationImpersonation ein bequemer Weg, Integrationen an Exchange Online anzubinden, aus heutiger Sicht allerdings ein gefährlicher. Dass Microsoft jetzt konsequent aufräumt, halte ich aus Security-Sicht für richtig, auch wenn die Umstellung für viele Organisationen schmerzhaft wird. Graph und Application RBAC sind nicht perfekt, für die kommenden Jahre aber aus meiner Sicht die beste Wahl. Wer jetzt anfängt, hat genug Zeit für eine saubere und sichere Migration und muss kurz vor der Abschaltung nicht hektisch improvisieren. Mehr zum Berechtigungsmanagement und zu Migrationen in Exchange Online steht übrigens im Beitrag Shared Mailboxes in Exchange Online absichern.