MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Dedicated Hybrid Application

Microsoft schaltet im Oktober 2026 den Zugriff per EWS in Exchange Online ab. Aber ein Jahr früher gibt (Okt 25) es eine zweite Änderung, die Exchange Hybrid stört, wenn Sie nicht handeln.

Diese Änderung kann umgesetzt werden, sobald sie das April 2025 HU für Exchange 2016CU23 oder Exchange 2019 CU14/CU15 installiert haben:
Released: April 2025 Exchange Server Hotfix Updates | Microsoft Community Hub
https://techcommunity.microsoft.com/blog/exchange/released-april-2025-exchange-server-hotfix-updates/4402471

Achtung: Deadline zur Umsetzung ist der 26. Okt 2025

Ich habe das Thema auch als Audiodatei für einen Podcast aufbereitet.
dedicated_hybrid_application.mp3

Exploitgefahr CVE-2025-53786?

Der erforderliche Hotfix und CVE ist von April 2025 aber kurz vor der Abschaltung schreiben einige Seiten dass Exchange eine kritische Lücke hätte. Wenn wir aber mal in die Quellen schauen, dann ist das trotz Einstufung mit einem CVS Score von 8 erst einmal theoretisch.

In an Exchange hybrid deployment, an attacker who first gains administrative access to an on-premises Exchange server could potentially escalate privileges within the organization’s connected cloud environment without leaving easily detectable and auditable trace. This risk arises because Exchange Server and Exchange Online share the same service principal in hybrid configurations.
Quelle: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53786

In aller Kürze:

  •  Es ist keine Exchange OnPremises Lücke
    Das Security Updates addiert Exchange 2016/2019 um eine Funktion, damit Exchange eine andere AppID nutzt und Microsoft diese im Oktober abschalten kann.
  •  Nicht über Internet ausnutzbar
    Es ist keine Lücke, die ein Angreifer von extern per EWS, Autodiscover, ActiveSync oder anderes Protokoll ausnutzen kann. Auch ein interner Anwender kann Exchange so nicht kompromittieren
  • Der Angriff erfolgt gegen Exchange Online mit dem Exchange OAuth Zertifikat
    Diese Anmeldung wird von Exchange OnPremises genutzt, um per EWS von Exchange Online die Frei/Belegt-Zeiten, Mailtipps und Benutzerfotos zu erhalten. Mit dem SAML-Token kann aber wohl auch noch andere APIs nutzen. Es ist aber nicht bekannt, welche dies sind und wie diese ausgenutzt werden können und es gibt noch keinen Proof of Concept.
  • Zur Ausnutzung muss man Admin auf dem Exchange Server sein
    Das OAUTH-Zertifikat ist im lokalen Zertifikatsspeicher des Computers hinterlegt. Ein Angreifer muss lokaler Admin oder SYSTEM oder ähnliche Privilegien haben, um sich mit dem privaten Schlüssel an Microsoft 365 anmelden zu können. Es geht nicht anonym oder als einfacher Domain User.
  • Wenn man keinen Exchange Server mehr hat und auch das OAUTH-Zertifikat nicht mehr da ist, dann kann man die Lücke nicht ausnutzen
    Selbst wer früher Hybrid eingerichtet hatte und einfach nur den lokalen Exchange Server und damit auch das OAUTH-Zertifikat entfernt hat, ist nicht mehr angreifbar.
  • Microsoft schaltet den Zugang im Oktober 2025 ab
    Dennoch sollte man den aktuelle HCW nutzen, um die Konfiguration anzupassen und danach per PowerShell den PublicKey aus dem alten Service Principal entfernen.
  •  Wenn ich einen nicht vertrauenswürdigen Admin habe oder eh schon gehackt bin, dann ist diese Lücke meine kleinste Sorge.
    Wenn ein Angreifer aber schon Admin auf Exchange ist, dann habe ich ganz andere Probleme, z.B. kann der Angreifer dann als "Trusted Subsystem" schon viel mehr Schaden anrichten. z.B. Mitgliedschaften in Sicherheits-Gruppen ändern. Sprich: Sie haben ihre Netzwerk dann schon vorher verloren und der Microsoft 365 Tenant wäre dann das i-Tüpfelchen.

Dennoch das US-CISA alle Behörden am 7. Aug angewiesen, ihre Exchange Server mit dem Hotfix auszustatten und die Konfiguration entsprechend anzupassen.

Ich hatte ja fast schon sowas geahnt, als Microsoft im April das Update rausgebracht hat aber zugleich die Abschaltung des alten Wegs zum Oktober, also grade mal 6 Monate später, festgelegt hat. Ich dachte nur, dass in Exchange Online eine Lücke besteht, die nicht anders gefixt werden könnte, als den Legacy Zugang abzuschalten.

Die Lösung ist einfach: Sie installieren das April 2025 Update auf allen Server und konfigurieren dann die pro Tenant individuelle alternative Anmeldeinformationen für den Zugriff auf Exchange Online auf eine eigene App um und deaktivieren danach die generischen Zugriffsinformationen per PowerShell. Microsoft hat dazu ein Flussdiagramm veröffentlicht:


Quelle: https://techcommunity.microsoft.com/blog/exchange/dedicated-hybrid-app-temporary-enforcements-new-hcw-and-possible-hybrid-function/4440682

 

Microsoft hatte sowie geplant, den Zugriff über diesen Weg zu Exchange Online im Oktober 2025 abzuschalten. Im August/September wird der Zugriff temporär schon einmal unterbrochen, damit "schläfrige Admins" durch Supportanfragen von Anwender aufwachen.


Quelle https://techcommunity.microsoft.com/blog/exchange/dedicated-hybrid-app-temporary-enforcements-new-hcw-and-possible-hybrid-function/4440682

Höchste Zeit also, die eigene Hybrid-Konfiguration zu prüfen und anzupassen und damit auch gleich die Lücke zu schließen.

Mittlerweile gibt es auch eine aktuelle Version des HCW, welcher die Konfiguration über eine GUI ermöglicht.

Achtung: Der letzte wichtige Schritt, das Zurücksetzen der "ResetFirstPartyServicePrincipalKeyCredentials" ist nicht Teil des HCW und muss manuell per PowerShell ausgeführt werden.

Die Lücke liegt nicht im lokalen Exchange selbst, sondern dass ein Admin auf Exchange mit den Credentials, die Exchange Hybrid zur Abfrage von Free/Busy, Mailtipps und Fotos per EWS aus der Cloud nutzt, sehr viele Rechte hat.

Allerdings frage ich mich, ob allein der Wechsel auf eine neue App Registration, die auch wieder "EWS full_access_as_app" bekommt und sich per Exchange Auth-Zertifikat anmeldet, nun sicherer ist.

Worum geht es?

Wenn Sie Exchange OnPremises und Exchange Online parallel nutzen und den Hybrid-Mode konfiguriert haben, dann greifen die jeweiligen Server auf die jeweils andere Seite zu und müssen sich dazu authentifizieren. Hier geht es um den Zugriff von Exchange OnPremises auf Informationen in Exchange Online. Dazu hat sich Exchange OnPremises per OAUTH als "Exchange Server" ausgegeben und mit einer globalen App-Permission auf die Exchange Online Daten zugegriffen. Sie finden Sie im Azure Portal, wenn Sie nach "Office 365 Exchange Online" oder der GUID "00000002-0000-0ff1-ce00-000000000000" suchen:

Mehr Details und insbesondere die Berechtigungen sind nicht zu sehen und von Microsoft vorgegeben und jedem im Tenant hinterlegt. Diese Applikation wird im Oktober 2025 nicht mehr zugelassen sein. Dies wirkt sich auf folgende Hybrid Komponenten aus:

Komponente  Beschrebung Status

Identity Sync , Empfängermanagement

Der Abgleich der AD/Entra ID-Objekte mit ADSync oder Cloud Sync ist durch diese Änderung nicht betroffen. Beachten Sie aber, dass es auch für ADSync ein Update gibt, welches bis zum 7. April umgesetzt werden sollte, wenn Sie danach weiter ADSync konfigurieren wollen:

 Keine Änderung

SMTP-Routing 

Die Übertragung von Mails zwischen dem lokalen Exchange Server und Exchange Online ist durch diese Umstellung nicht betroffen. Hier werden Source-IP oder idealerweise Zertifikate zur Authentifizierung genutzt. Allerdings gibt es das SMTP-Throttling für Server, die zu alt sind.

  Keine Änderung
Free/Busy
OnPrem->Online

Die Abfrage der Frei/Belegt-Zeiten von Exchange OnPremises zu Exchange Online ist nicht mehr möglich 

  Anpassung erforderlich
Free/Busy
Online->OnPrem

Die Abfrage der Frei/Belegt-Zeiten von Exchange Online zu Exchange OnPremises ist nicht betroffen.

  Keine Änderung
MailTipps
OnPrem->Online

Funktionieren ausgehend von Exchange OnPremises zu Exchange Online erst wieder nach der Änderung der Konfiguration

  Anpassung erforderlich
MailTipps
Online->OnPrem

Keine Veränderung der Funktion. 

  Keine Änderung
Postfachmigration
Bidirektional

Hier verbindet sich der Mailbox Replication Service (MRS) von Exchange Online zum lokalen Server über https. Diese Funktion ist nicht betroffen.

  Keine Änderung

Profilbilder 

Wenn Benutzer mit einem lokalen Postfach das Profilbild eines Exchange Online Benutzers erhalten sollen, muss die Konfiguration angepasst werden.

  Anpassung erforderlich

Es sind also nicht alle Funktionen einer Hybrid-Bereitstellung von der Härtung betroffen.

Wenn die gelben Funktionen auch nach dem Oktober 2025 weiter funktionieren sollen, müssen Sie als Administrator im Zeitraum von April 2025 bis Oktober 2025 aktiv werden.

Warum?

Der Wechsel auf eine eigene "Exchange Online Shared Application" hat zwei Gründe:

  • Sicherheit
    Aktuell greifen alle Exchange OnPremises Server mit der generischen "Exchange Online Application", die zu viele Berechtigungen hat. Das ist sprichwörtlich eine Altlast. Die neue Application hat deutlich weniger Berechtigungen.
  • Microsoft Graph
    Ab Okt 2026 müssen alle Hybrid-Anfragen über Microsoft Graph erfolgen. Spätestens dann wäre eine eigene Application erforderlich, die mit passenden Berechtigungen ausgestattet sind.

Es geht also wieder mal um Sicherheit und dazu gehört auch, dass jeder Dienst seine eigenen Zugangsdaten und granularen Berechtigungen bekommt und eben nicht viele Dienste mit einem Sammelkonto arbeiten.

 Vielleicht gibt es noch eine andere Lücke 

Diesmal braucht es aber die Mithilfe der Administratoren, denn Exchange OnPremises wird zukünftig mit einer neue Application Permission auf Exchange Online zugreifen. Dazu brauchen wir eine Konfiguration auf beiden Seiten, die ab Oktober 2025 umgesetzt sein muss.

Zeitraum

Die Zeiten der Umsetzung sind relativ kurzfristig. Vielleicht gibt es ja einen Angriffsvektor in Exchange Online über die generische Exchange Online Application, die nicht zu fixen ist und erst mit der Abschaltung im Oktober 25 geschlossen wird. Das ist aber reine Spekulation.

Letztlich haben Exchange Administratoren seit April 2025 die Möglichkeit, die Authentifizierung des lokalen Exchange Servers gegen den Tenant durch ein individuelles Zertifikat abzusichern.

Zeitpunkt Beschreibung Erledigt

Jetzt

Microsoft hat die erforderlichen Änderungen zur neue Anmeldung auf ihrem Blog veröffentlicht.

Zudem gibt es schon lange Aussagen zum Ende von EWS in Exchange Online. Für Exchange Administratoren gibt es nun zwei Dinge zu starten:

  • Exchange Hybrid Bereitstellung anzupassen
    Sie müssen bis Oktober 2025 eine Exchange App in Entra ID anlegen und den Public Key ihres Exchange OAuth-Zertifikats in Entra ID hinterlegen, damit zukünftig die Hybrid-Funktion von Exchange OnPremises zu Exchange Online auch nach dem Oktober 2025 weiter funktionieren.
  • EWS 3rd Party Apps auf Graph umzustellen
    Auch wenn Sie noch viele Monate Zeit haben, sollten Sie auch realisieren, dass nach dem Oktober 2026 kein Zugriff per EWS mehr möglich ist. Im Februar 2025 hat Microsoft hat schon die Application Impersonation-Rechte in Exchange Online angepasst (Siehe EXO EWS 2025/2026)
  • Update auf Exchange 2019CU14/CU15, Exchange 2016 / CU23
    Auch wenn ältere Versionen von Exchange 2016/2019 schon nicht mehr supportet sind, so werden sie sicher noch verwendet. Ältere Versionen können aber nicht auf das neue Verfahren umgestellt werden. Hier ist ein Update erforderlich.
  • Installation Exchange April 2025 HU
    Released: April 2025 Exchange Server Hotfix Updates | Microsoft Community Hub https://techcommunity.microsoft.com/blog/exchange/released-april-2025-exchange-server-hotfix-updates/4402471

Okt 2025

Exchange Online erlaubt keine Zugriff von Exchange OnPremises über die alte "Exchange Online Application" mehr. Mailflow und Anmeldungen funktionieren weiter aber Frei/Belegt-Zeiten, Profilbilder, Mailtipps und andere EWS-Zugriffe funktionieren nicht mehr, bis sie in ihrem Tenant die Änderung umgesetzt haben.

Okt 2026

EWS in Exchange Online wird abgeschaltet. Bis dahin müssen alle 3rd Party Apps auf Graph umgestellt sein Server auf Exchange Server SE . Ob dann Exchange 2016/2019 noch die Daten im Hybrid -Mode über Graph abrufen können,

Damit ergeht ein Aufruf an alle Exchange Administratoren und Dienstleister, ihre aktuellen Hybrid Umgebungen bis zum Oktober 2025 anzupassen.

Vorarbeit OAUTH-Zertifikat

Ehe Sie die Dedicated Hybrid Application konfigurieren, sollten Sie erst einmal einen Blick auf das Exchange OAuth-Zertifikat werden und wie lange es gültig ist. Dieses Zertifikat wird später für die Anmeldung an Entra ID genutzt und sollte natürlich nicht in den nächsten Monaten ablaufen.

Get-Exchangecertificate -thumbprint (Get-AuthConfig).CurrentCertificateThumbprint

 

Mein Zertifikat war zu meinen Test Mitte 2025 noch bis 27.01.2027 gültig und ich habe es nicht erneuert. Wenn ihr Zertifikat nicht mehr lange gültig ist, dann sollten Sie es vielleicht noch schnell erneuern

Konfiguration mit HCW

In einer neuen Version des HCW wird die Konfiguration der "Dedicated Hybrid App" zum Default gehören. In den erweiterten Einstellungen können Sie diese Funktion natürlich überspringen lassen. Die Aktivierung der Dedicated Exchange Server App erzwingt auch die beiden ersten Punkte zur Konfiguration von OAUTH und den Domains.

Der HCW legt dann in ihrem Tenant nicht nur die App Registration an und lädt das Zertifikat hoch, sondern fordert übergangsweise noch den "Admin Consent" für das recht umfangreiche "EWS full_access_as_app"-Recht ab.

Das ist aktuell noch erforderlich, solange die zu der Zeit noch unterstützten Exchange 2016/2019/SE-Server die Zugriffe per EWS ausführen. Später, wenn die Zugriffe per Graph erfolgen, dann dürfte dieses Recht entfallen.

Konfiguration PowerShell

Damit stellt sich die Frage, wie das zu erfolgen hat. Technisch sind dazu folgende Änderungen erforderlich:

  • Kompatible Exchange Version
    Es muss 2019 CU15 oder Exchange 2016/2019 April 2025 HU und alle neuere Versionen sein. Exchange 2013 und ältere Versionen können am Okt 2025 diese Daten nicht mehr abrufen und beim SMTP-Verstand werden diese sehr alten Versionen ebenfalls "gedrosselt". Aktualisieren Sie daher daher ihre Exchange Server
  • Exchange OAUTH Zertifikate
    Für den nächsten Schritt der Einrichtung und die spätere Nutzung muss ihre Exchange Umgebung ein Zertifikat zur Authentifizierung vorweisen. Das war aber schon bisher der Fall, denn das gleiche Zertifikate wurde auch zur Anmeldung mit der bisherigen AppID verwenden.
  • Application in Entra ID
    Dann muss in ihrem Tenant eine neue App-Registation angelegt werden, die drei Berechtigungen benötigt und zur Anmeldung mit den Zertifikat des vorherigen Schritts dessen Public-Key als ClientSecret eingerichtet wird.
  • Organization Relationship
    Zuletzt müssen Sie die Konfiguration der Organization Relationship anpassen, damit Exchange OnPremises nicht mehr das generische Application Konto nutzt, sondern sich mit dem Exchange Authentication Zertifikat ihrer anmeldet.

Sie können all diese Einstellungen natürlich manuell durchführen aber Microsoft stellt mit April HU zuerst ein PowerShell-Script bereit, welches alle erforderlichen Einstellungen vornimmt. Sie können als GlobalAdmin und Exchange Admin mit einem Befehl alle Änderungen vornehmen lassen.

ConfigureExchangeHybridApplication.ps1
https://microsoft.github.io/CSS-Exchange/Hybrid/ConfigureExchangeHybridApplication/

Das Skript muss in einer Admin-PowerShell gestartet werden und führt ohne weiteren Parameter keine Änderungen aus.

Wenn Sie die lokalen Exchange Anpassungen durchführen wollen, dann muss das Skript in einer Exchange Admin PowerShell auf einem Exchange Server ausgeführt werden, damit es z.B. das Auth-Zertifikat lesen kann. Um gleich alle Konfigurationen anzupassen ist folgender Aufruf erforderlich.

.\ConfigureExchangeHybridApplication -FullyConfigureExchangeHybridApplication 

Das geht natürlich nur, wenn Sie alle erforderlichen Berechtigungen haben, d.h. lokale Exchange Admin aber auch Admin im Tenant zum Anlegen der Application. Sie können aber auch die einzelnen Schritte separat ausführen und damit der delegierten Administration Rechnung tragen. So kann der Entra ID Application Admin" oder notfalls auch der "Global Admin" die Application einrichten, damit danach der Exchange Administrator die lokale Konfiguration anpasst.

Etwas später wird auch der  HCW - Hybrid Configuration Wizard ein entsprechendes Update erfahren, damit er die Konfiguration ebenfalls umsetzen. kann. Wer sich nicht sicher ist, welche Änderungen ein neuer HCW vielleicht noch umsetzt, der ist vielleicht mit dem PowerShell Script besser bedient.

Die genauen Schritte und Abhängigkeiten hat Microsoft auf ihrem Blog-Post veröffentlicht:


Quelle: https://techcommunity.microsoft.com/blog/exchange/exchange-server-security-changes-for-hybrid-deployments/4396833 

Es ändert sich aber nichts an der generellen Funktion für HTTPS-Anfragen, d.h. Proxy-Einstellungen, Namensauflösung, Firewall-Freischaltungen bleiben wie gehabt. Exchange OnPremises startet eine Exchange - Autodiscover-Anfrage gegen die TargetAddress der RemoteMailbox (Siehe auch MOERA - Microsoft Online Email Routing Address) und bekommt den EWS-Endpunkt in Exchange Online (meist outlook.office.com) und verbindet sich dann per HTTPS mit Exchange Online, meldet sich dann mit der neuen Application an und erhält hoffentlich die vom Client gewünschten Daten.

https://aka.ms/ConfigureExchangeHybridApplication

Details zur Konfiguration

Die Authentifizierung des lokalen Exchange Servers gegenüber Exchange Online erfolgt mit dem Exchange OAuth-Zertifikat mit dem CN="cn=Microsoft Exchange Server Auth Certificate", welches seit Exchange 2013 bei der Installation automatisch ausgestellt wird. Es ist ein "SelfSigned"-Zertifikat, welches fünf Jahre gültig ist aber von Hand erneuert werden muss. Das übernimmt weder das PowerShell-Script noch der HCW.

Exchange 2013 Setup creates a self-signed certificate with the friendly name Microsoft Exchange Server Auth Certificate. The certificate is replicated to all front-end servers in the Exchange 2013 organization. Quelle: https://technet.microsoft.com/de-de/library/jj150480(v=exchg.160).aspx  

In Entra ID wird dann eine neue Application angelegt, bei der der Public Key des Exchange Server Auth-Zertifikats hinterlegt wird. Das können Sie mit der PowerShell sehr einfach umsetzen.

Das PowerShell-Script legt die App übrigens direkt über HTTP-Request gegen graph.microsoft.com an und nutzt nicht die MGGraph-PowerShell.

Wer also in den  Source-Code des PowerShell-Skripts schaut, kann schön sehen, wie es sich ein Access-Token als "Azure PowerShell besorgt. Mit fast 6000 Lines of Code ist es wieder ein nettes Beispiel um sich Tricks abzuschauen.

In dem Bild ist auch gerade nicht zu sehen, dass er beim Schritt "ConfigureTargetSharingEpr" nicht gemacht hat. Zuerst hat er aber eine App angelegt. Die Applikation sehen Sie z.B. im Entra ID Portal: Ihre App hat natürlich eine andere AppID.

Create Application

Zuerst legt das Skript im Entra ID eine App Registration an, die sie auch in den "Enterprise Apps" sehen.

In der ersten Stufe bekommt die Application sehr umfangreiche EWS-Rechte:

Feiner abgestufte Graph-Rechte sind hier noch nicht konfiguriert worden. Ich vermute mal, dass dies erst mit der Installation von Exchange SE im Oktober 2025 oder später kommt und sich auf Kalender, Mails und das Profilfoto beschränken dürfte.

Szenario     EWS-Rechte (Bis Okt 2026)      Graph Berechtigungen
=======================================================================
Free/Busy :  Full_Access_As_App             Calendars.ReadBasic
Mailtips  :  Full_Access_As_App             Mail.Read
UserPhotos:  Full_Access_As_App             ProfilePhoto.Read.All

Die EWS-Rechte entfallen auf jeden Fall, wenn Exchange Online den Support für EWS in der Cloud (geplant Okt 2026) einstellt. Leider gibt es kein eigenes Recht für "Mailtipps", so dass auch dann noch "Mail.Read" recht umfangreich ist.

Upload Certificate

In der AppRegistration finden Sie das Zertifikat, mit dem sich der OnPremises Server an Exchange Online authentifiziert. Dieses wurde durch die Einrichtung durch den HCW oder das PowerShell-Script mit hochgeladen. Vergleichen Sie einfach den Thumbprint mit dem lokalen Exchange Server Auth Zertifikat.

 

Configure AuthServer 

Hier sehen Sie auch die Domains für den AuthServer und die AppID. Wenn ihre lokale Exchange Umgebung mit mehreren Tenants verbunden wird, dann haben sie auch mehrere AuthServer mit unterschiedlichen Domains und AppIDs.

Get-AuthServer "EvoSts - fb2c2d99-4d38-4d1f-ba15-be51f857b56a" ? 
| fl name,domainname,ApplicationIdentifier

Bei einer Konfiguration ohne Dedicated Hybrid App ist das Feld "ApplicationIdentifier" auf $null gesetzt.

ConfigureTargetSharingEpr

Dieser Punkt ist wichtig, da das Skript alle Org-Connectoren durchsucht und zu den Domains eine Autodiscover V2-Anfrage macht, um das Deployment zu erkennen. Wenn die Domain zu Exchange Online verweist, dann aktualisiert das Skript auch den "TargetSharingEpr". Das Feld ist bei klassischen Hybridbereitstellungen in der Regel "leer" und der Exchange Server sucht über die Autodiscover-Funktion nach dem entsprechenden Zugang.

Warum Microsoft sich hier nun anders entschieden hat, weiß ich nicht. Aber ich kann mir vorstellen, dass es einfach weniger Autodiscover-Anfragen gibt und die URL "outlook.office365.com" wird sich ja nicht so umfangreich ändern.

Achtung: Ich habe Situationen gesehen, wo falsche URLs nicht aktualisiert wurden oder die Domains nicht erkannt wurden.

SettingsOverwrite

Die letzte Änderung ist die globale "Exchange Server Overwrite"-Konfiguration. Auch die können Sie einfach abfragen:

Get-SettingOverwrite | fl name,server,parameters 

Diese Einstellung aktiviert die Nutzung der alternativen AppID, mit der Exchange dann über den EVOSTS-AuthServer sich ein Ticket organisiert. 

Entfernen "Service Principal"

Wenn denn alles funktioniert, dann müssen wir immer noch die früher genutzten Zugangsdaten auf dem lokalen Exchange Server entfernen.

.\ConfigureExchangeHybridApplication.ps1 -ResetFirstPartyServicePrincipalKeyCredentials

Damit wird das Schlüsselmaterial entfernt, welches sonst von einem Administrator missbraucht werden könnte, um damit auf Microsoft 365 Dienste zuzugreifen.

Kontrolle Sign-in Logs

Ob sich ihr Exchange Server korrekt mit der neuen Enterprise Application an ihrem Tenant anmeldet, können Sie bei den Signin-Logs kontrollieren:

 

Achten Sie darauf, dass Sie den Reiter "Service principal sign-ins" anwählen. Wenn ihr OnPremises Server sich hier mit "Success" anmelden kann, dann sollten alle Voraussetzungen erfüllt sein, d.h. der Exchange Server nutzt die neue "Dedicated Hybrid Application", die in Entra ID hinterlegt wurde und auch der Upload des Zertifikats hat funktioniert.

Multi Tenant

Eine 1:1 Hybrid-Bereitstellung ist einfach. Exchange Hybrid unterstützt aber 1:N und N:1 Konfigurationen. Entsprechend müssen Sie von einer Exchange Organisation eventuell in zwei Tenants eine App-Registrierung mit dem gleichen Zertifikat aber zwei AUTH-Servern konfigurieren. Wenn mehrere OnPremises Organisationen sich mit dem gleichen Tenant verbinden, dann bekommt jede OnPremises Organisation eine eigene AppRegistration mit eigenem Zertifikat.

Das funktioniert aber dann nicht mehr mit einem einfache Aufruf des PowerShell-Skripts mit dem Parameter "-FullyConfigureExchangeHybridApplication", da sie in einigen Fällen eine RemoteRoutingDomain und TenantID angeben müssen.

Achtung:
Die "SettingsOverwrite"-Einstellung in ihrer lokalen Umgebung ist global. Wenn Sie mehrere Tenants anbinden, dann sollten sie erst alle Tenants mit einer "Dedicated Hybrid App" ausstatten, ehe Sie den Exchange Server dafür freischalten.

Wenn Sie z.B. eine OnPremise Organisation mit zwei Tenants verbinden, dann haben Sie lokal auch zwei "<tenantname>.mail.onmicrosoft.com"-Domains. Von denen kann aber nur eine das Feld "Set-RemoteDomain <domain> -TargetDeliveryDomain:$true" haben. Dieses Kriterium nutzt aber das Skript, um die OAUTH-Federation einzutragen. Sie müssen also entweder die TargetDeliveryDomain jedes Mal auf den gewünschten Wert stellen oder die Parameter angeben.

Kontrolle und Fehlersuche

Ob ihr OnPremises Server nun schon den neuen Weg korrekt nutzt, können Sie nur indirekt prüfen. Ein Outlook-Client fragt natürlich per HTTPS den lokalen Exchange Server´, der dann wieder zur Cloud weiter zugreift. Aber in die HTTPS-Kommunikation zwischen Exchange OnPremises und Exchange Online können sie nur mit einem HTPS-Proxy eingreifen, wenn Sie Exchange dazu bringen, den Proxy zu nutzen. In Wireshark und Co könnten sie also nur generell erkennen, dass es die entsprechenden DNS-Anfragen und TCP/HTTPS-Verbindungen gibt.

Als einfache Option würde ich in Entra ID kontrollieren, ob die neu eingerichtete Anwendung für Anmeldungen genutzt wird. Das geht am einfachsten über "https://portal.azure.com" und die Enterprise Applications.

Ob der Exchange Server ein OAUTH-Token bekommt, können wir recht einfach über "Test-OAuthConnectivity" prüfen.

# Test auf OnPremises Exchange PowerShell
Test-OAuthConnectivity `
   -Service EWS `
   -TargetURI https://outlook.office.com/ews/exchange.asmx `
   -Mailbox <OnPrempostfach> | fl

Hier muss erst einmal ein "Success" kommen:

Das nicht sichtbare Property "Detail" sind hier aber nicht sichtbar. Dort drin stehen aber die Details wie z.B.:

Information:[OAuthTokenBuilder:GetAzureADAppToken] trying to get the apptoken
from the auth server 'EvoSts - fb2c2d99-4d38-4d1f-ba15-be51f857b56a' for
resource 'https://outlook.office.com', tenantId
'463e98ae-b7d4-4af2-8ef8-3eda0b4d8a7c', userDomain 'UCLABOR.DE'

...

Information:[OAuthTokenBuilder:GetAzureADAppToken] finish building apptoken, it is 
{"typ":"JWT","nonce":"g8HEhKCpFlrYT3Bn_-Eo14jDtR76oPanxHeQcYJMD_c",
 "alg":"RS256","x5t":"JYhAcTPMZ_LX6DBlOWQ7Hn0NeXE",
 "kid":"JYhAcTPMZ_LX6DBlOWQ7Hn0NeXE"
}.
"tid": "463e98ae-b7d4-4af2-8ef8-3eda0b4d8a7c"
"appid": "46746f22-c403-4166-acf4-eb7ebeef28d2" 
"ver": "1.0" "oid": "7a409263-07fd-49f6-b6ce-fa5aa4470501" 
"iss": "https://sts.windows.net/463e98ae-b7d4-4af2-8ef8-3eda0b4d8a7c/" 
"aud": "https://outlook.office.com" 
"nbf": "1753441094" 
"exp": "1753444994"

Hier ist dann gut zu sehen, dass der Exchange Server ein Token für die soeben angelegte AppID bekommen hat. Wenn Sie die AppID haben, können Sie daher recht einfach danach in dem String suchen:

(Test-OAuthConnectivity `
     -Service EWS `
     -TargetUri https://outlook.office.com/ews/exchange.asmx `
     -Mailbox OnPremMailbox `
).detail `
| Select-String "46746f22-c403-4166-acf4-eb7ebeef28d2" 

Wenn die nicht funktioniert, dann ist entweder bei ihnen lokal der AuthServer nicht so konfiguriert, dass er die AppID nutzt oder in Entra ID ist die Applikation nicht korrekt eingerichtet, z.B. gar nicht vorhanden oder nicht das richtig Zertifikat als Client Secret hinterlegt.

Wenn ihr Exchange Server dann ein Token bekommt, dann versucht er damit eine Anfrage zu Exchange Online. Dazu wurde eine "Organization Relationship" angelegt.

 

 

 

# List of Microsoft cloud domains which could be used as part of the TargetAutodiscoverEpr
$microsoftDomainsDefault = @("office365.com", "office365.us", "office365-net.us", "office.com", "cloud.microsoft", "outlook.com", "outlook.cn", "apps.mil")

 

 

 

Rollback

Bis zum Oktober 2025 haben Sie noch Zeit, wieder die alte "First Class App" zu nutzen. Die Beschreibung bei Microsoft liefert aber auch eine weitere wichtige Information hinsichtlich des HCW:


Quelle: Deploy dedicated Exchange hybrid app https://learn.microsoft.com/en-us/exchange/hybrid-deployment/deploy-dedicated-hybrid-app#how-to-roll-back-from-dedicated-exchange-hybrid-application

Auch Ende Juli hat Microsoft den HCW noch nicht aktualisiert, dass er mit der neuen Konfiguration einer "Dedicated Hybrid Application" umgehen kann. Er überschreibt einfach die Werte im AuthServer aber vergisst die anderen Overwrites zu korrigieren. Das geht dann mit:

# Settings Overwrite entfernen
Get-SettingOverride `
| Where-Object {$_.ComponentName -eq "Global" -and $_.SectionName -eq "ExchangeOnpremAsThirdPartyAppId"} `
| Remove-SettingOverride

# Exchange anweisen die Konfiguration neu zu laden
Get-ExchangeDiagnosticInfo `
   -Process Microsoft.Exchange.Directory.TopologyService `
   -Component VariantConfiguration `
   -Argument Refresh

#AuthServer anpassen
$tenantId = "123e4567-e89b-12d3-a456-426614174000"   # hier die TenantID ihres Microsoft 365 Tenants eintragen

(Get-AuthServer `
    | Where-Object {$_.Name -like "*evoSTS*" -and $_.Realm -eq $tenantId} `
) `
| Set-AuthServer `
   -ApplicationIdentifier $null `
   -DomainName $null

Zuletzt könnten sie auch noch in Entra ID die Enterprise Application löschen. Aber sie würde genauso wieder angelegt

Weitere Links