EXO Hybrid mit Preauth

Viele Firmen nutzen Exchange On-Premises und veröffentlichen den Server über einen Web Application Firewall, welche über eine Preauthentication einen zusätzlichen Schutz bietet. Direkte Zugriffe per Outlook aus dem Internet sind dann meist nur mittels VPN möglich, wo auch z.B.: per Zertifikat o.ä. ein Schutz möglich ist. In Exchange Online fällt all das weg, denn Sie können keine eigene Firewall vor ihre Cloud stellen. Aber wie verbinden Sie hier Exchange Online und Exchange On-Premises per Hybrid Mode?

Sicherheit mit OAUTH

Seit Herbst 2022 hat Microsoft in der Cloud den Umstieg endlich geschafft und die Exchange Online Server nehmen (fast) nur noch Verbindungen mit "Modern Auth" an. Exchange ignoriert damit einfach Kombinationen aus Benutzernamen und Kennworten und liefert auch keine entsprechende Informationen mehr aus. Sie können zwar noch ein Anfrage an Exchange liefern aber als Antwort kommt nur ein leerer REALM zurück:

PS C:> Invoke-WebRequest https://outlook.office.com/ews/exchang.asmx -ErrorVariable ee 
Invoke-WebRequest: Response status code does not indicate success: 401 (Unauthorized) 

PS C:\> $ee.Innerexception | fl response

Response : StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 1.1, Content:
           System.Net.Http.HttpConnectionResponseContent, Headers:
           {
             Server: Microsoft-IIS/10.0
             request-id: a6a66ff6-2359-ed16-6a85-67a02a66b8fd
             Alt-Svc: h3=":443"
             Alt-Svc: h3-29=":443"
             X-WSSecurity-Enabled: True
             X-WSSecurity-For: Logon
             X-FederationTrustTokenIssuerUri: urn:federation:MicrosoftOnline
             X-WSSecurity-SymmetricKey-Enabled: True
             X-WSSecurity-X509Cert-Enabled: True
             X-OAuth-Enabled: True
             X-FirstHopCafeEFZ: FRA
             X-FEProxyInfo: FR2P281CA0091.DEUP281.PROD.OUTLOOK.COM
             X-FEEFZInfo: FRA
             X-Powered-By: ASP.NET
             X-FEServer: FR2P281CA0091
             WWW-Authenticate: Basic Realm=""
             Date: Thu, 06 Apr 2023 18:12:05 GMT
             Content-Length: 0
           }, Trailing Headers:
           {
           }

Ein Client muss also ein "Bearer"-Token senden und wird dann zum OAUTH-Service geleitet, der sich mit all den Anmeldungen herumschlagen muss. Für die Sicherheit von Exchange Online ist natürlich förderlich, da jeder Request sehr früh geprüft werden kann, ob ein gültiges OAUTH-Token oder Authentication-Cookie enthalten ist. DoS-Attacken lassen sich so mit weniger Aufwand abwehren und Exchange muss keinen nachgelagerten Server fragen. On-Premises ist dies übrigens auch möglich, wenn Sie ihren lokalen Exchange z.B. mit Hybrid Modern Authentication (HMA) absichern.

Was macht aber ein On-Premises-Administrator, der seinen Server nicht mit Hybrid Modern Authentication (HMA) absichert und z.B. eine Preauthentication durch einen Reverse Proxy nutzt. Wollen wir wirklich PreAuth abschalten?

Umgebung

Für die Koexistenz mit Exchange On-Premises richten wir mit dem HCW - Hybrid Configuration Wizard eine Hybrid-Bereitstellung ein. Je nach Dauer und umfang ist das eine kleine "Minimum Hybrid"-Konfiguration, bei der eigentlich nur das Mailrouting und die Migrationsendpunkte hinterlegt werden. Wer eine längere Koexistenz plant, wird natürlich auch Frei/Belegt-Zeiten, Mailtipps, Stellvertreter u.a. zwischen beiden Welten bereitstellen müssen. Hier wird es nun interessant, da Exchange Online nur "OAUTH" spricht und sich, mit Ausnahme bei der Migration, nicht mit einem Benutzernamen oder Kennwort am lokalen Exchange Server anmeldet, sondern per OAUTH-Token. Der HCW richtet dazu im lokalen Exchange den Tokenserver von Exchange Online als "vertrauenswürdig" ein.

Diese Funktion einer Anmeldung mit eine OAUTH-Token führt aber dazu, dass sie ihren On-Premises-Exchange Server nun zumindest für Exchange Online auch "anonym" erreichbar machen müssten. Exchange Online kann nicht mit einer Preauthentication umgehen und ich habe noch keine Web Application Firewall gefunden, die ein OAUTH-Token von Exchange Online als vorgelagerte Authentifizierung prüft und die Anforderung dann an Exchange intern weiter gibt:

Ich habe schon bei mehreren Kunden so eine "schlaue WAF" angesprochen aber bislang hat die noch kein Firewall-Admin eingerichtet bekommen. Wenn einer meiner Leser dies nutzt, dann freue ich mich pber einen Hinweis auf eine entsprechende Veröffentlichung oder Quellen.

Gehen wir aber für die nächsten Schritte davon aus, dass Sie ihren regulären OWA-Zugang nicht "öffnen" wollen. Dann kommt sehr schnell die Überlegung, ob man nicht einfach einen weiteren Hostnamen derart konfigurieren kann, dass Exchange Online nicht über Autodiscover und die gelieferten ExternalURL-Einträge mit dem lokalen Exchange Server kommuniziert, sondern statische Werte hinterlegt werden könnten. Das Szenario könnte dann wie folgt aussehen:

Sie sehen hier drei Zugänge aus dem Internet (rechts) und Exchange online (rechts) zum On-Premises-Exchange Server links.

SourceIP Ziel Name/IP Port Beschreibung

<ANY>

owa.msxfaq.de
IP1

443

Das ist der bisher schon vorhandene Zugang zu Exchange Outlook Web Access, ActiveSync aus dem Internet mit zusätzlicher Absicherung durch die Web Application Firewall

Exchange Online Range

hybrid.msxfaq.de
IP2

443

Dieser zweite Zugang ist nur von Exchange Online zu erreichen und erlaubt einen direkten Zugriff auf die Exchange Webdienste. Natürlich können Sie die Verbindungen auch über einen Reverse Proxy leiten. Denken Sie an die Einschränkungen von SSL-Inspection, SSL-Offloading und unterschiedlichen Zertifikaten. Dieser Zugang kann dann für EWS-Abfragen (Free/Busy, Mailtipps) als auch für den Migration Endpunkt genutzt werden

Exchange Online Range

edge.mxsfaq.de

25

Zuletzt soll es auch noch einen Verbindung per SMTP geben, die auch nicht von jeder IP-Adresse aus dem Internet erreicht werden kann, sondern auf Exchange Online beschränkt wird.

Wer eine IP-Adresse sparen will, dann den Hybrid-Zugang per HTTP und SMTP natürlich über eine IP-Adresse leiten, wenn die Firewall die Verbindungen je nach Port auf dann unterschiedliche Backend-Server leiten kann.

Support-Statement?

Ehe sie so eine Konfiguration angehen, sollten Sie zuerst den Support-Status prüfen. Vielleicht hat Microsoft selbst oder ein anderer Autor das Problem schon thematisiert. Tatsächlich findet sich in einem Blog-Artikel des Exchange Teams vom August 2015 ein entsprechender Hinweis zur Koexistenz von Exchange 2010 mit Exchange 2013

Should we have a hybrid specific URL? We have seen deployments where a decision is made to keep the existing Mail.Contoso.com and Autodiscover.Contoso.com pointing to a bank of Exchange 2010 servers and have a new hybrid URL, such as hybrid.Contoso.com, pointing to a couple of Exchange 2013 servers. This is an example of an environment that did not introduce Exchange 2013 in a recommended way. Let’s forget about hybrid for a second. When you introduce Exchange 2013 into an environment you should configure coexistence in a supported way. This means that you install enough Exchange 2013 servers to handle the proxy load for all On-Premises mailboxes and point the external URL to the latest version of Exchange in the site. Again, deploy the latest version properly before you enter a hybrid configuration.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/hybrid-deployment-best-practices/ba-p/604221

Leider beschäftigt sich der Artikel im weiteren mit Exchange 2007/2010/2013 und dass mit Exchange 2016 vieles besser wird und "Hybrid" ja keine "pro Server" sondern eine Einstellung "Pro Organization" ist. Leider hilft uns das hier aber auch nicht wirklich weiter, denn auf den Abschnitt "Let’s forget about hybrid for a second" folgt dann keine weitere Information mehr.

Man muss hier Microsoft natürlich mal in Schutz nehmen, dass dieser Artikel schon von 2015 ist nicht mehr aktualisiert wurde.

Autodiscover

Die Einrichtung einer solchen Nebenverbindung kann leider der HCW nicht automatisch unterstützen Er geht davon aus, dass Exchange Online natürlich über die SMTP-Domain des Postfachs auch einen "https://autodiscover.<domain>" ausführen kann und das geht in unserem Bild vielleicht auch nicht. Speziell wenn Sie von extern nur "OWA/ActiveSync" erlauben und Outlook-Clients per VPN eh von intern kommen, können Sie Autodiscover blockieren. Das stört aber erst einmal Exchange, weil Exchange Online natürlich als Standardfunktion mit Autodiscover den optimalen Zugangspunkt ermitteln will. Dies können Sie aber ändern.

The TargetAutodiscoverEpr parameter specifies the Autodiscover URL of Exchange Web Services for the external organization, for example, https://msxfaq.com/autodiscover/autodiscover.svc/wssecurity. Exchange uses Autodiscover to automatically detect the correct Exchange server endpoint to use for external requests.
https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationrelationship?view=exchange-ps

Allerdings sollten Sie dennoch überlegen, ob Sie den Zugang zu Autodiscover aus dem "Internet" ohne PreAuth konfigurieren, denn Microsoft Teams benötigt zwingend "Autodiscover V2", um z.B. den Kalender eines On-Premises-Postfach zu finden und anzuzeigen

Wenn Sie Autodiscover quasi "anonym" erreichbar machen, dann kann auch Teams mittels OAUTH sich autorisieren aber natürlich könnte auch jeder andere "böse" Client per Autodiscover eine Kennwort-Attacke starten und Konten ggfls. aussperren. Wenn Sie, wie anfangs skizziert, bislang nur OWA und ActiveSync bereitgestellt haben, dann können Sie den Zugriff auf die Autodiscover-Dienste natürlich auch auf die Microsoft IP-Adressen beschränken, um das Risiko hier zu minimieren-

Konfiguration

Die Verbindung von Exchange Online zu Exchange On-Premises wird durch den HCW angelegt, welcher folgende Elemente konfiguriert, die angepasst werden müssen.

HCW Konfiguration Erledigt

EXO: Organizationrelationship

Über die Organizationrelationship wird Konfiguration, welche Funktionen der anderen Seite genutzt werden, z.B. Free(Busy, Mailtips etc). Hier sthet auch die URL, über die Benutzer den Weg zu ihrer OWA-Seite finden, wenn Sie sich irrtümlich an Exchange Online angemeldet haben aber ihr Postfach noch On-Premises liegt.

PS C:\> Get-OrganizationRelationship | fl name,target*

Name                  : O365 to On-Premises - 1191ecb5-aafb-41d5-a616-52a314c7d5db
TargetApplicationUri  : FYDIBOHF25SPDLT.msxfaq.de
TargetSharingEpr      :
TargetOwaURL          : https://owa.msxfaq.de/owa
TargetAutodiscoverEpr : https://autodiscover.msxfaq.de/autodiscover/autodiscover.svc/WSSecurity

Sie sehen hier aber auch, dass HCW eine Adresse bei "TargetAutodiscoverEpr" hinterlegt und dafür denn TargetSharingEpr leer gelassen hat. Hier kann ich ansetzen, um z.B. Autodiscover auf hybrid.msxfaq.de umzustellen oder bei einer einfachen Umgebung direkt den WebService anzugeben:

Set-OrganizationRelationship `
   -Identiy <name> `
   -TargetSharingEpr https://hybrid.msxfaq.de/exchange/exchange.asmx

Damit ist diese Konfiguration schon einmal von Autodiscover unabhängig und nutzt den Hintereingang.

EXO: IntraOrganizationConfiguration

Diese Einstellung können Sie nur auslesen aber nicht ändern.

PS C:\> Get-IntraOrganizationConfiguration

OnlineDiscoveryEndpoint                     : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc
OnlineTargetAddress                         : msxfaq.mail.onmicrosoft.com
OnPremiseTargetAddresses                    : {msxfaq.de}
OnPremiseDiscoveryEndpoint                  :
OnPremiseWebServiceEndpoint                 :
DeploymentIsCompleteIOCReady                :
HasNonIOCReadyExchangeCASServerVersions     :
HasNonIOCReadyExchangeMailboxServerVersions :

Sie sind aber für die Einrichtung des IntraOrganizationConnector relevant:

EXO: IntraOrganizationConnector

Dieser Connector hat nicht mit "Mailrouting" zu tun und ist in der GUI von Exchange nicht sichtbar. Hierüber wird aber ebenfalls die Konfiguration der Hybrid-Funktion beeinflusst. Sie sehen auch hier einen "DiscoveryEndpoint", den HCW angelegt hat, der aber nicht den Hostnamen "Autodiscover" nutzt.

PS C:\> Get-IntraOrganizationConnector | fl name,disc*,targ*

Name                 : HybridIOC - 1191ecb5-aafb-41d5-a616-52a314c7d5db
DiscoveryEndpoint    : https://owa.msxfaq.de/autodiscover/autodiscover.svc
TargetAddressDomains : {msxfaq.de}
TargetSharingEpr     :

Auch hier ist der Wert im Feld "TargetSharingEpr" leer und kann PowerShell gesetzt werden, damit Autodiscover gar nicht mehr relevant ist.

Set-IntraOrganizationConnector `
   -Identity <name>
   -TargetSharingEpr https://hybrid.msxfaq.de/exchange/exchange.asmx

EXO: Outbound Connector

Für das Mailrouting von der Cloud zum lokalen Exchange Server wird ohne Connector der MX-Record genutzt. Das ist nicht sinnvoll, da dort ja Spamfilter u.a. die Mails aus dem eigenen Tenant als Phsihing blocken könnte. Ein eigener Connector zum lokalen Exchange über einen separaten Eingang ist ratsam. Die On-Premises Firewall kann ja "das Internet" von diesem Eingang aussperren.

PS C:\> Get-OutboundConnector "Outbound to 1191ecb5-aafb-41d5-a616-52a314c7d5db" | fl connector*,recip*,smarthosts,cloud*

ConnectorType            : On-Premises
ConnectorSource          : HybridWizard
RecipientDomains         : {msxfaq.de}
SmartHosts               : {edge.msxfaq.de}
CloudServicesMailEnabled : True

Sie können mit Set-Outboundconnector einfach das Feld "Smarthosts" nach ihren wünschen anpassen, wenn Sie dies noch nicht direkt im HCW gemacht haben.

Set-OutboundConnector `
   -Identity <name> `
   -Smarthosts edge.msxfaq.de

Wenn Sie Port 443 und 25 unter dem gleichen Namen "hybrid.msxfaq.de" bereitstellen und über die Firewall verteilen, dann können Sie sich einen gesonderten Namen sparen

EXO: Migration Endpunkt

Zuletzt haben wir noch den Migrationsendpunkt, welchen Sie schon bei der Konfiguration des HCW gleich abweichend von ihrem normalen OWA-Zugang einrichten können

PS C:\> Get-MigrationEndpoint | fl identity,endpointtype,remoteserver,useautodiscover,isremote

Identity        : MigEndpoint
EndpointType    : ExchangeRemoteMove
RemoteServer    : owa.msxfaq.de
UseAutoDiscover :
IsRemote        : True

Natürlich können Sie auch das Feld "Remote-Server" über die PowerShell anpassen

Set-Migrationendpoint `
   -identiy <name> `
   -RemoteServer hybrid.msxfaq.de

Damit haben wir nun Exchange Online alle Fakten mitgeteilt, damit er nicht mehr per Autodiscover den lokalen Exchange Server abfragen will und als Hostname dann die Informationen aus den Feldern "ExternalURL" der jeweiligen virtuellen Verzeichnisse heranzieht.

OAUTH und Test-OAuthConnectivity

Eine Hürde gibt es aber noch zu nehmen. Wir stellen war so die Hostnamen für Exchange Online um aber im gleichen Zuge wird Exchange Online dann auch ein OAUTH-Token für den neuen Namen, hier "hybrid.msxfaq.de" anfordern. Wir haben On-Premises natürlich ein Zertifikat für diesen Namen eingerichtet aber der Exchange Server weiß nicht, dass es nun auch "hybrid.msxfaq.de" heißt. Wenn ich hier nicht korrigieren, dann bekomme ich folgenden Fehler beim Test mit.

PS C:\> Test-OAuthConnectivity `
           -Service EWS  `
           -TargetUri https://hybrid.msxfaq-ag.de/metadata/json/1  `
           -Mailbox mailbox1@msxfaq.de  `
           -Verbose  `
        | fl
VERBOSE: Returning precomputed version info: 3.1.0
VERBOSE: POST https://outlook.office365.com/adminapi/beta/<GUID des Tenant>/InvokeCommand with -1-byte payload
VERBOSE: received 2444-byte response of content type application/json;charset=utf-8
VERBOSE:


Task        : Checking EWS API Call Under Oauth
Detail      : The configuration was last successfully loaded at 1/1/0001 12:00:00 AM UTC. This was 1063606480 minutes ago.
              The token cache is being cleared because "use cached token" was set to false.
              Exchange Outbound Oauth Log:
              Client request ID: 818bebf3-26ab-412e-9dca-295a99177b03

Die PowerShell triggert bei Exchange Online den Aufruf an, sich mit "https://hybrid.msxfaq.de/ews/Exchange.asmx" erst einmal anonym zu verbinden und zu erfahren, welche Anmeldeverfahren der Server kann.

              Information:[OAuthCredentials:Authenticate] entering
              Information:[OAuthCredentials:Authenticate] challenge from 'https://hybrid.msxfaq.de/ews/Exchange.asmx' received: 
                    Bearer client_id="00000002-0000-0ff1-ce00-000000000000",
                    trusted_issuers="00000001-0000-0000-c000-000000000000@<GUID des Tenant>,
                                     00000004-0000-0ff1-ce00-000000000000@msxfaq.de",
                                     Negotiate,NTLM,Basic realm="owa.msxfaq.de"
              Information:[OAuthCredentials:GetToken] client-id: '00000002-0000-0ff1-ce00-000000000000', 
                    realm: '', trusted_issuer: '00000001-0000-0000-c000-000000000000@<GUID des Tenant>,
                                                00000004-0000-0ff1-ce00-000000000000@msxfaq.de'

Der Server bietet neben Negotiate, NTLM, Basic auch Bearer an und liefert auch den trusted_issuer mit. Das führt bei Exchange Online nun dazu sich ein Ticket für den Service zu besorgen.

              Information:[OAuthCredentials:GetToken] Start building a token using organizationId '<GUID des Tenant>'
              Information:[OAuthCredentials:GetToken] Start building a token using adUser
              Information:[OAuthTokenBuilder:GetAppToken] start building the apptoken
              Information:[OAuthTokenBuilder:GetAppToken] checking enabled auth servers
              Information:[OAuthTokenBuilder:GetAppToken] trusted_issuer includes the auth server 
                                             'MicrosoftSts': 00000001-0000-0000-c000-000000000000@*,
              Information:[OAuthTokenBuilder:GetAppToken] trying to get the apptoken from the auth server 'MicrosoftSts'
                               for resource '00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>',
                               tenantId '<GUID des Tenant>',userDomain 'msxfaq.de'
              Information:[TokenCache:GetActorToken] try to get a new  token synchronously
              Information:[OAuthTokenBuilder:GetAppToken] finish building apptoken; the token is 
                            {"typ":"JWT","alg":"RS256","x5t":"-KI3Q9nNR7bRofxmeZoXqbHZGew","kid":"-KI3Q9nNR7bRofxmeZoXqbHZGew"}.
                            "oid": ""b3a9a725-04a3-4d43-a1ea-99b8263f55e0"" 
                            "iss": ""00000001-0000-0000-c000-000000000000@<GUID des Tenant>"" 
                            "aud": ""00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>"" 
                            "nbf": "1680789166" "exp": "1680875866"
              Information:[OAuthTokenBuilder.GetAppWithUserToken] nameid is allowed to be included in the claim set
              Information:[OAuthTokenBuilder.GetAppWithUserToken] only nameid to be included in the claim: no
              Information:[OAuthTokenBuilder.GetAppWithUserToken] building token with user context for the audience 
                            '00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>'
              Information:[OAuthTokenBuilder.GetAppWithUserToken] claims count: 5
              Information:[OAuthTokenBuilder.GetAppWithUserToken] TokenResult length: 650

Exchange Online konnte erfolgreich ein OAUTH-Token von seinem Authentication-Service bekommen. Damit geht er nun wieder zum On-Premises Exchange Server.

              Information:[OAuthCredentials:Authenticate] send request to 'https://hybrid.msxfaq.de/ews/Exchange.asmx' 
                            with the bearer token: '{"alg":"none","typ":"JWT"}.
                            "iss": ""00000002-0000-0ff1-ce00-000000000000@<GUID des Tenant>"" 
                            "aud": ""00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>"" 
                            "nbf": "1680791976" "exp": "1680820776" ; 
                            actor: {"typ":"JWT","alg":"RS256","x5t":"-KI3Q9nNR7bRofxmeZoXqbHZGew","kid":"-KI3Q9nNR7bRofxmeZoXqbHZGew"}.
                            "oid": ""b3a9a725-04a3-4d43-a1ea-99b8263f55e0"" 
                            "iss": ""00000001-0000-0000-c000-000000000000@<GUID des Tenant>"" 
                            "aud": ""00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>"" 
                            "nbf": "1680789166" "exp": "1680875866" '
              Token:{"alg":"none","typ":"JWT"}."iss": ""00000002-0000-0ff1-ce00-000000000000@<GUID des Tenant>"" 
                    "aud": ""00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>"" 
                    "nbf": "1680791976" "exp": "1680820776" ;
              actor: {"typ":"JWT","alg":"RS256","x5t":"-KI3Q9nNR7bRofxmeZoXqbHZGew","kid":"-KI3Q9nNR7bRofxmeZoXqbHZGew"}.
                    "oid": ""b3a9a725-04a3-4d43-a1ea-99b8263f55e0"" 
                    "iss": ""00000001-0000-0000-c000-000000000000@<GUID des Tenant>"" "aud":
              ""00000002-0000-0ff1-ce00-000000000000/hybrid.msxfaq.de@<GUID des Tenant>"" "nbf": "1680789166" "exp": "1680875866"

Die Antwort passt dann leider nicht mehr, denn es kommt kein "200OK" sondern ein "(401) Unauthorized"

              Exchange Response Details:
              HTTP response message:
              Exception:
              System.Net.WebException: The remote server returned an error: (401) Unauthorized.
                 at System.Net.HttpWebRequest.GetResponse()
                 at Microsoft.Exchange.Monitoring.TestOAuthConnectivityHelper.SendExchangeOAuthRequest(ADUser user, 
                    String orgDomain, Uri targetUri, String& diagnosticMessage, 
                    Boolean appOnly, Boolean useCachedToken, Boolean reloadConfig), 
                    diagnostics: 2000003;reason="The hostname component of the audience claim value is invalid. 
                    Expected 'owa.msxfaq.de'. Actual 'hybrid.msxfaq.de'.";error_category="invalid_resource"
ResultType  : Error
Identity    : Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid     : True
ObjectState : New

Wer sich den Fehler genau anschaut, sieht auch die Ursache für den 401:

The remote server returned an error: (401) Unauthorized.
diagnostics: 2000003;reason="The hostname component of the audience claim value is invalid. 
  Expected 'owa.msxfaq.de'. Actual 'hybrid.msxfaq.de'.";error_category="invalid_resource"

Der lokale Exchange Server antwortet mit einem 401-Fehler, da er das Ticket vom Server bekommen hat aber es nicht auf sich bezieht. Der Fehler hier zeigt, dass etwas auf dem Weg aus dem Internet den Hostheader umschreibt. Damit der On-Premises Exchange Server das OAUTHToken decodieren kann, muss der Hostheader mit dem AUD-Header im Token übereinstimmen. Die Details dazu finden Sie auf Exchange OAuth.

Ergebnis

Wenn Sie ihre Umgebung korrekt konfigurieren, sollte es problemlos möglich sein, ihren lokalen Exchange Server einmal mit OWA/RCP/MAPI/ActiveSync etc. und einen Preauthentication-Proxy abzusichern und parallel einen zweiten Zugangspunkte für die Abfragen von Free/Busy und die Migration von Postfächern einzurichten. Denken Sie aber daran, dass dies nicht bei der Koexistenz von Microsoft Teams mit On-Premises-Postfächern zur Anzeige des Kalenders weiter hilft, denn Teams nutzt Autodiscover V2 und ignoriert die Exchange Online Konfiguration hinsichtlich "IntraOrganizationConfiguration und IntraOrganizationConnector"

Die hier beschriebene Einrichtung kann aber dennoch speziell für eine Migration sinnvoll sein, wenn Sie die Exchange Webdienste unter einem eigenen Namen nur per OAUTH anonym erreichbar machen wollen und ihr Reverse Proxy keine abweichende Konfiguration nach SourceIP zulässt.

Weitere Links