MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

EXO EWS 2025/2026

Vermutlich haben Sie diesen Artikel nach dem 20 Feb 2025 gefunden, weil Microsoft in Exchange Online den Zugriff per EWS Application Impersonation abgeschaltet hat und viele 3rd-Party-Apps nicht mehr funktionieren. Eine Anpassung ist erforderlich. Aber auch das hilft nur wenige Monate, denn das Ende von EWS in Exchange Online ist seit 2018 angekündigt und soll 2026 erfolgen.

Worum geht es?

Benutzer und Applikationen konnten schon seit Exchange 2007 auf ihre Daten in Exchange über den Exchange Webservice (EWS) zugreifen. Wenn dies ein Anwender macht, dann meldet er sich einfach mit seinen Anmeldedaten an und greift zu. Wenn ein automatischer Prozess auf viele Postfächer zugreifen will, dann hat er natürlich nicht die Zugangsdaten des Anwenders. Daher gibt es hier ein besonderes Recht "Application Impersonation". Sie konnten in Exchange OnPremises aber auch in Exchange Online einer Applikation das Recht geben, sich "als Benutzer" auszugeben. In den ersten Versionen umfasste das Recht gleich alle Postfächer und damit war das Konto kritisch und quasi ein "Golden Key" für Exchange Daten.

Seit Exchange 2010 Konnten die das Recht daher über einen "Management Scope" und RBAC beschränken, d.h. ein Applikation musst das Recht "User_Impersonation" haben, welches z.B. auf eine mittels OPATH-Filter definierte Teilmenge an Postfächern den Zugriff hat.

In Exchange Online kam das erst viel später und so gab es noch viele Konfigurationen, bei denen Applikationen mit EWS Impersonation auf Exchange Online Postfächer zugegriffen haben. Das geht seit Februar 2025 nicht mehr und es gibt auch keine Verlängerung. Microsoft schließt diesen im Grunde unsicheren Zugriff.

As we recently repeated, we will begin blocking App Impersonation in Feb 2025. It’s very important that you make sure you don’t have any applications using this form of access, or they will stop working in February 2025. There are no exceptions.
Quelle: Security Related Updates in Exchange Online
https://techcommunity.microsoft.com/blog/exchange/security-related-updates-in-exchange-online/4303525

Wobei auch dies nur eine Übergangslösung ist, denn das Ende von EWS ist für 2026.

We are still on track to remove Exchange Web Services (EWS) from Exchange Online starting October 2026. This will be a breaking change for all applications using EWS.
Quelle: https://techcommunity.microsoft.com/blog/exchange/security-related-updates-in-exchange-online/4303525

Today, we are announcing that on October 1, 2026, we will start blocking EWS requests to Exchange Online.
Despite today’s announcement, EWS is still available and supported for use in production environments.
Quelle: Retirement of Exchange Web Services in Exchange Online
https://techcommunity.microsoft.com/blog/exchange/retirement-of-exchange-web-services-in-exchange-online/3924440

Wenn EWS entfällt, müssen entsprechende Produkte über Microsoft Graph und Exchange Online Inhalte zugreifen und die Beschreibung auf dieser Seite werden dann obsolet.

Legacy Exchange Online Tokens

Am 17. Februar 2025 wurde aber noch ein zweiter Zugang abgeschaltet.

Legacy Exchange Online tokens are deprecated and will be turned off across Microsoft 365 tenants starting February 17th, 2025. If you're a developer migrating your Outlook add-in from legacy tokens to Entra ID tokens and nested app authentication, you'll need to test updates to your add-in.
https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/turn-exchange-tokens-on-off

Es geht hier um EWS-Zugriffe und Outlook API-Zugriffe, die von modernen Outlook AddOns mit diesen "alten" AppIDs und Tokens zum Zugriff auf Daten des Benutzers genutzt werden. Verwechseln Sie dies nicht mit dem Outlook COM-AddOns, die noch die alte Technik repräsentieren und mit dem Neuen Outlook nicht mehr funktionieren. Sie können diese mit folgendem Befehl in der Exchange Online PowerShell ermitteln.

Get-AuthenticationPolicy -AllowLegacyExchangeTokens

Sie können als Administrator diese "Legacy Exchange Online Tokens" für einige Zeit reaktivieren aber auch nicht auf Dauer. Hier ist der Entwickler des AddIns gefordert, möglichst schnell seinen Code auf eigene Entra ID Tokens und Microsoft Graph umzustellen. So kann der Administrator dann für jedes AddOn eigene Einstellungen bezüglich Consent und damit verbundenen Berechtigungen einstellen.

MC724116 - Bin ich betroffen?

Eigentlich hätten Sie es wissen können und müssen, denn Microsoft hat in das Microsoft 365 Message Center eine entsprechende Meldung platziert:

In dem Message Center führt Microsoft auch auf, wie Sie ihre Umgebung prüfen können, denn der Eintrag MC724116 signalisiert nur, dass Sie mindestens eine Applikation mit der RBAC-Rolle "Application Impersonation" hat.

Get-ManagementRoleAssignment `
   -Role ApplicationImpersonation `
   -GetEffectiveUsers `
   -Delegating:$false

Das bedeutet aber nicht, dass diese Applikation auch noch aktiv in Verwendung ist. Sie müssten nun über die Exchange Online PowerShell und "Get-ManagementRoleAssignement" nach den Applicationen suchen und dann im Unified Audit Log nachschauen, ob sich diese Applikationen noch anmelden. Dankenswerterweise hat Microsoft dazu eine PowerShell bereitgestellt, die dies für sie übernimmt.

appImpersonationUsersReport
https://github.com/cparker-msft/appImpersonationUsersReport/

Graph-FindImpersonation
https://github.com/jmartinmsft/Exchange-App-Usage-Reporting/tree/main
Report of users leveraging the ApplicationImpersonation RBAC role with third party EWS applications. 

Temporäre Abhilfe

Sollten Sie solche Applikationen gefunden haben, dann können diese seit Februar 2025 nicht mehr arbeiten. Microsoft möchte natürlich, dass Sie möglichst schnell auf Microsoft Graph umstellen. Aber in der Zwischenzeit bis Oktober 2026 können Sie noch folgenden Weg nutzen:

Implement App-only authentication and RBAC for Applications: Make the necessary code and configuration updates for EWS applications requiring 1-to-many mailbox access to use App-only access (uses EWS.AccessAsApp OAuth Application permission) along with implementing resource-scoped access using Role-Based Access Control (RBAC) for Applications in Exchange Online.
Quelle: https://techcommunity.microsoft.com/blog/exchange/critical-update-applicationimpersonation-rbac-role-deprecation-in-exchange-onlin/4295762

Der alte Weg funktionierte so, dass eine Applikation sich per OAUTH2-Berechtigungen ein Token beschafft hat, in dem "Application Permission" gewährt wurde und per RBAC optional der Zugriff auf eine Teilmenge der Anwender erlaubt wurde. Das geht nicht mehr. Die Konvertierung erfolgt wie folgt:

Schritt Erledigt

Application mit AppID/ObjectID ermitteln

Zuerst besorgen Sie sich die AppID, mit der die bisherigen Zugriffe erfolgen. Ein Startpunkt ist die Auflistung der Apps, die das bisher unbeschränkte Recht verwenden:

Get-ManagementRoleAssignment `
   -Role ApplicationImpersonation `
   -GetEffectiveUsers `
   -Delegating:$false

Suchen Sie dann im Azure Portal auf https://portal.azure.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/AppAppsPreview/menuId~/null nach den Apps anhand der AppID. Die Liste zeigt neben der AppID auch die ServiceID an.

Nutzen Sie die Application, um

Service Principal anlegen

Im nächsten Schritt legen wir ein Service Principal in Exchange für jede einzelne AppID an

New-ServicePrincipal `
   -AppId <Hier die AppID ihrer bisherigen App> `
   -ObjectId <Hier die ObjectID ihrer bisherigen App> `
   -DisplayName 'SPN for Apppolicy to RBAC'

Management Scope

Wie früher für die AppID mit den Rechten stellten wir nun einen Management Scope für den Service Principal. Das Beispiel fasst alle Postfächer zusammen, die in der Abteilung "Vertrieb" sind.

New-ManagementScope `
   -Name "MGMTScopeApp1" `
   -RecipientRestrictionFilter "Department -eq 'Vertrieb'"

Sie können auch andere Felder, z.B. CustomAttribute 1-15 nutzen und müssen sich natürlich überlegen, wie Sie z.B. per Provisioning o.ä. die Felder füllen.

Management Role Assignment

Nun verbinden wir den neu angelegten ManagementScope mit dem Service Principal

New-ManagementRoleAssignment `
   -App <Hier die AppID ihrer bisherigen App> `
   -Role "Application Mail.Read" `
   -CustomResourceScope "MGMTScopeApp1"

Ich habe hier im Beispiel nur "Application Mail.Read" gewährt. Prüfen Sie genau, welche Berechtigungen ihre Applikation, die demnächst mit dem Service Principal läuft benötigt. Zur Auswahl stehen:

Application Mail.Read
Application Mail.ReadBasic
Application Mail.ReadWrite
Application Mail.Send
Application MailboxSettings.Read
Application MailboxSettings.ReadWrite
Application Calendars.Read
Application Calendars.ReadWrite
Application Contacts.Read
Application Contacts.ReadWrite
Application Mail Full Access
Application Exchange Full Access
Application EWS.AccessAsApp

Sie können Impersonation für EWS z.B. auf Mails oder nur Kontakte beschränken. Geben Sie nur die Berechtigungen, die ihre Lösung benötigt. Bitte benutzen Sie gerade nicht das Recht "Application EWS.AccessAsApp".

Berechtigungen prüfen

Sie soeben gewährten Zugriffsrechte können Sie wie folgt prüfen. Es kann aber etwas dauern, bis die Ausgabe die effektiven Berechtigungen anzeigt, denn Exchange Online hat durchaus ein Caching und auch Tokens haben eine Gültigkeit.

Test-ServicePrincipalAuthorization `
   -Identity $AppId `
   -Resource <Zielpostfach anhand des Alias, UPN, Mailadresse>

Eine Wartezeit von 30-60 Minuten ist hilfreich und öffnen Sie am besten eine neue Exchange Online PowerShell.

Cleanup

Aktuell haben Sie nun einen Service Principal, den ihre Applikation nutzt. Die App hat aber auch noch den AdminConsent für die alten RBAC-Rechte. Die sollten Sie im Azure-Portal natürlich widerrufen.

Application anpassen

Nun müssen Sie natürlich kontrollieren, ob sie in der Applikation noch etwas ändern müssen. Die AppID ist zwar die gleiche aber wenn Sie bisher ein OAUTH2-Token für das Recht "Application EWS.AccessAsApp" angefordert hat, muss Sie nun ggfls. die reduzierten Berechtigungen anfordern.

Rückbau

Denken Sie daran, dass im Oktober 2026 der EWS-Zugriff in Exchange Online komplett wegfallen wird. Bis dahin muss ihre Applikation auf Microsoft Graph umgestellt werden oder entfallen.

Wer ist schuld?

Leider ist es nun mal passiert, dass Microsoft einen unsicheren Zugang mit Vorankündigung und Blog-Artikeln und MessageCenter-Meldung irgendwann auch einmal abschalten muss. Das hat aber sicher bei dem ein oder anderen Tenant erst mal zu Störungen, Unterbrechungen und Fehlersuche geführt, was eigentlich nicht sein müsste. Damit kommt immer die Frage auf, wie man das besser hätte sehen können oder man sogar jemand die Schuld in die Schuhe schieben könnte. Selbst Fragen nach Haftung oder Schadenersatz könnten aufkommen. Wer kommt uns das in den Sinn

  • Microsoft als Betreiber
    Microsoft übernimmt natürlich den Betrieb des Service aber entwickelt diesen auch weiter. Änderungen und Weiterentwicklungen gehören dazu und Microsoft kommuniziert Änderungen über das Microsoft 365 Message Center und andere Wege. Wobei einige Meldungen sehr kurzfristig sein können aber diese Meldung ist seit vielen Monaten bekannt.
  • Der Tenant-Administrator oder Exchange Online Administrator
    Aus meiner Sicht gibt es immer eine für den Service verantwortliche Person bei der Firma, die den Tenant nutzt bzw. einen beauftragten Dienstleister. Hier sehe ich auf jeden Fall die Pflicht sich die entsprechenden Servicemeldungen aus dem Microsoft 365 Message Center zu lesen.
  • Programmierer/3rd-Party Hersteller
    Irgendjemand hat ja die Lösung entwickelt und die Einrichtung dokumentiert. Zumindest bei kommerziellen Produkten könnte der Lieferant seine Kunden über so eine Änderung informieren. Schließlich muss er ja auch seine Dokumentation aktualisieren oder gleich das Nachfolgeprodukt auf Basis von Microsoft Graph verkaufen. Aber da der Hersteller oder Lieferant nicht weiß, ob speziell ältere Produkte überhaupt noch im Einsatz sind und betroffen ist, sollten Sie von der Seite keine Information erwarten.
  • Dienstleister
    Viele Firmen beauftragen externe Dienstleister mit der Unterstützung. Hier hängt es von der Intensität ab, ob eher projektbezogene Leistungen erbracht werden oder wirklich ein "Managed Service" genutzt wird. Über Funktionen wie GDAP - Granular Delegated Admin Privileges könnte ein Dienstleister auch das Message Center lesen und die Konfiguration prüfen.

Irgendwie ist es immer ein "Jeder hat etwas Schuld". Aber der Zugriff mit den alten sehr umfangreichen Rechten ist ein Sicherheitsrisiko, welches wohl in der Vergangenheit gerne von Angreifern ausgenutzt wurde. Genaue Zahlen hat hier nur Microsoft aber ohne Grund würde Microsoft wohl nicht diesen Weg so kurz vor der generellen Abschaltung von EWS im Oktober 2026 abschalten.

Weitere Links