MRS und Extended Protection

Seit dem August 2022 hat Microsoft die Unterstützung für "Extended Protection" in Exchange OnPremises integriert und im Feb 2024 Update per Default aktiviert. Diese Seite beschreibt die Fehlermeldungen einer Migration von Postfächern in einer Exchange Hybrid Bereitstellung bei einer unpassenden Konfiguration.

Das Problem sollten Sie nie haben, aber wenn Sie es haben und im Internet suchen, dann sollten Sie hier landen und die Lösung oder Hinweise zur Fehlersuche finden.

Kurzfassung

Extended Protection ist ein zusätzlicher optionaler aber empfehlenswerter Schutz bei der Anmeldung per NTLM auf Windows Dienst. Der "MRS-Dienst" von Exchange Online nutzt eine Anmeldung per NTLM aus dem Internet, um Postfachdaten bei der Migration zwischen Exchange OnPremises und Exchange Online zu authentifizieren. Der Administrator hinterlegt dazu in Exchange Online einen "Migration Endpunkt" samt Domainuser und Kennwort, welcher auf dem lokalen Exchange Server die erforderlichen Berechtigungen hat.

Bei der Migration per MRS erzwingt sowohl Exchange Online als auch der lokale Exchange Server immer eine verschlüsselte Verbindung per HTTPS. Der lokale MRS-Dienst erlaubt keine Nutzung ohne HTTPS. Wenn Sie als Firma aber ihren Exchange Server nicht mit einem Bein ins Internet stellen, nicht per NAT direkt per NTLM erreichbar machen wollen und daher eine Loadbalancer oder Reverse Proxy davor schalten, dann müssen Sie für Extended Protection einige Bedingungen verstehen. Bei Extended Protection wird das Zertifikat des Exchange Servers mit in die NTLM-Anmeldung integriert und wenn die Gegenseite auch NTLM und Extended Protection versteht dann wird auch die Gegenseite das ihr vorliegende Zertifikat in die Berechnung mit einbeziehen. Wenn sich hier ein "Inspection Proxy", "Man in the Middle" oder ein Layer-7 Loadbalancer mit einem anderen Zertifikat einmischt, dann kommt die Anmeldung nicht zustande.

Der MRS-Dienst bei Exchange Online ist ein HTTP-Client, der "Extended Protection" nicht erzwingt aber nutzt, wenn es angeboten wird. Ich habe die entsprechenden Zeilen in "Gelb" markiert. Damit gibt es nur wenige funktionierende Kombinationen:

  • Wenn ein unterschiedliches Zertifikat genutzt wird, dann muss ihr Exchange Server auf NONE stehen
    Alle anderen Einstellungen funktionieren nicht!
  • Mit dem gleichen Zertifikat können Sie einstellen was sie wollen
    Denn MRS steht auf "optional" und daher kann er sich per EP anmelden, wenn die Zertifikate übereinstimmen aber wenn der Exchange kein EP anbietet, dann meldet er sich per NTLM auch ohne EP an

Probleme gibt es also immer dann, wenn Sie auf dem Exchange Server die Funktion "Extende Protection" auf "Require" aber auch nur bei "Accept" stellen, weil Exchange Online sich dann bei unterschiedlichen Zertifikaten nicht anmelden kann.

Status ermitteln

Die Konfiguration von Extended Protection können Sie manuell von Hand ändern und einsehen. Aber viel besser ist das PowerShell-Skript, welche Microsoft auf CSS-Exchange zum Download bereitstellt

Ein Aufruf mit dem Parameter "-ShowExtendedProtection" liefert ihnen über alle Server die aktuellen Einstellungen. Hier die Einstellungen wenn EP über das Skript aktiviert wurde.

Wie sehen aber auch, dass nur OWA, RPC, MAPI, ECP und API auf "Require" gestellt wurden. EWS wurde aber "nur" auf Allow gestellt, d.h. es ist nicht möglich aber nicht erzwungen.

Aktivieren können Sie Extended Protection einfach durch den Aufruf ohne Parameter. Beachten Sie die Warnungen zu Loadbalancern, Exchange Modern Hybrid und öffentliche Ordner auf Exchange 2013.

Das Skript prüft zusätzlich einige Voraussetzungen, z.B. die TLS-Einstellungen. Bei meinem Server habe ich z.B. TLS 1.0/1.1 abgeschaltet. Für Extended Protection ist ist aber keine Voraussetzung.

Exchange Online Fehler

Ich habe meine Konfiguration absichtlich "falsch" gemacht und Extended Protection aktiviert, obwohl ein Reverser-Proxy ein unterschiedliches Zertifikat liefert. Damit sollte der Zugriff auf EWS und insbesondere den MRPProxy-Dienst nicht mehr mittels NTLM möglich sein, wenn der Client das angebotene EP auch nutzt. Eine Migration eines OnPremises Postfachs zu Exchange Online schlägt im Sep 2024 mit folgender Meldung fehl:

Error: CommunicationErrorTransientException:
   The call to 'net.tcp://paxpr08mb6367.eurprd08.prod.outlook.com:9821/Microsoft.Exchange.MailboxReplicationService
   PAXPR08MB6367.eurprd08.prod.outlook.com (15.20.8005.10
   ServerCaps:FFFFFFFF, ProxyCaps:1FFFFFFFFFFFFFFFC7DD2DFDBF5FFFFFCB07EFFF, MailboxCaps:, legacyCaps:FFFFFFFF)' failed.
Error details: The Mailbox Replication Service was unable to connect to the remote server using the credentials provided.
   Please check the credentials and try again.
   The call to 'https://mrs.msxfaq.net/EWS/mrsproxy.svc' failed.
Error details: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.
   --> The remote server returned an error: (401) Unauthorized..
   --> The HTTP request is unauthorized with client authentication scheme 'Negotiate'.
   The authentication header received from the server was 'Negotiate,NTLM'.
   --> The remote server returned an error: (401) Unauthorized..
   --> The Mailbox Replication Service was unable to connect to the remote server using the credentials provided. Please check the credentials and try again.
The call to 'https://mrs.msxfaq.net/EWS/mrsproxy.svc' failed.
Error details: The HTTP request is unauthorized with client authentication scheme 'Negotiate'.
   The authentication header received from the server was 'Negotiate,NTLM'.
   --> The remote server returned an error: (401) Unauthorized..
   --> The HTTP request is unauthorized with client authentication scheme 'Negotiate'.
   The authentication header received from the server was 'Basic realm="mrs.msxfaq.net",Negotiate,NTLM'.
   --> The remote server returned an error: (401) Unauthorized.

Wenn Sie genau hinschauen, dass erkennt Exchange Online sehr wohl dass mein OnPremises Server "NTLM, BAsic" anbietet aber die Anmeldung dann nicht erfolgreich möglich ist. Mein Webserver liefert einen "401"-Fehler.

MRS Endpunkt prüfen

Welche Anmeldeverfahren ihr MRS-Endpunkt anbietet, können Sie von extern per PowerShell sehr einfach ermitteln:

PS C:\> Invoke-Webrequest https://mig.msxfaq.net/ews/mrsproxy.svc

Der Abruf wird ohne Anmeldedaten natürlich mit einem 401 quittiert, so dass ich mir die Fehlermeldung genauer anschauen muss.

Ich bin auf meinem Exchange Server gelandet und er zeigt mir auch die möglichen Anmeldeverfahren an. Die nächste Steigerung ist nun eine Authentifizierung mittels NTLM- Dazu muss ich mit einem Computer aus dem Internet einen Zugriff starten, der nicht Mitglied der Domain ist oder zumindest nicht an den KDC der Domäne kommt. Am besten starten Sie einmal "KLIST" um zu sehen, dass Sie kein gültiges Ticket für diesen Service haben. Wenn Sie dann eine explizite Anmeldung mit gültigen Anmeldedaten wie folgt durchführen, dann haben Sie je nach Konfiguration des IIS unterschiedliche Fehler:

PS C:\> Invoke-Webrequest https://mig.msxfaq.net/ews/mrsproxy.svc -Method POST -Credential (Get-Credential msxfaq\admin)
IIS-Einstellung Error-Code Beschreibung

Off

400 (Bad Request)

Wenn auf dem Webserver die Anmeldung per "Extended Protection" nicht aktiviert ist, dann kann ich mit anmelden aber bekomme natürlich einen "400 (Bad Request)". Schließlich sende ich ja keine gültige MRS-Payload mit

Accept

401 (Unauthorized)

Sobald ich den Status auf "Accept" stelle, versucht mein "Invoke-Webrequest" zwar eine Anmeldung aber die Anmeldung schlägt fehl. Das interpretiere ich so, dass auch die PowerShell sehr wohl EP unterstützt aber nicht erzwingt

Require

401 (Unauthorized)

Wenn der Webserver die Anmeldung per EP erzwingt, funktioniert die Anmeldung auch nicht.

Wer also die Einstellung im IIS auch nur auf "Accept" stellt und noch nicht auf "Require" kann Clients aussperren, die auf das "Accept" auch EP nutzen.

Exchange Online nutzt EP, wenn es angeboten

OnPremises Eventlog

Um das Fehlerbild zu analysieren, habe ich zu erst auf dem Exchange Server das Eventlog etwas hochgestellt.

Set-Eventloglevel "EX01\MSExchange Mailbox Replication\Service" -Level Expert
Set-Eventloglevel "EX01\MSExchange Mailbox Replication\Mailbox Move" -Level Expert

Nach den nächsten Migrationen habe ich das Application Eventlog auf den "MSExchangeMailbox Replication"-Dienst gefiltert.

Allerdings gab es keine Treffer. Das hat mich nun nicht so überrascht, denn der Fehler mit dem 401 wird ja schon vom IIS mit einem Fehler quittiert. Also habe ich die Einstellungen wieder zurück gedreht:

Set-Eventloglevel "EX01\MSExchange Mailbox Replication\Service" -Level Lowest
Set-Eventloglevel "EX01\MSExchange Mailbox Replication\Mailbox Move" -Level Lowest

Auch ein Blick in das Security Eventlog ergab keine Treffer, denn auch hier konnte die Anmeldung noch gar nicht ankommen.

IISLogs / FREB

Insofern war eine Analyse mit IIS Failed Request Tracing als ein Teil eines IIS - Webserver Troubleshooting angesagt. zuerst habe ich auf der Webseite das "Failed Request Tracing" aktiviert und dann im virtuellen Verzeichnisse "/EWS" die Überwachung auf "401"-Fehler aktiviert. Der IIS protokollierte dann jeden Zugriff mit, der mit einem 401 quittiert wurde. Sie können sich vorstellen, dass so eine Menge Events protokolliert werden, denn /EWS wird nicht nur für eine Postfachmigration sondern auch von Clients zum Abrufen von Frei/Belegt-Informationen und vielen anderen Prozessen genutzt und alle bekommen auf den ersten Zugriffe einen "401 unauthorized" zurück. Ich musste daher die Anzahl der Log von 50 (Default) Dateien auf 10000 setzen und mir ein kleines Skript schreiben, um aus der Menge an Dateien die interessanten Dateien zu extrahieren:

# Copy-FREBEvents
#
# Grab FREBLogs with specific request data

[cmdletbinding()]
param(
   $directory = "C:/inetpub/logs/FailedReqLogFiles/W3SVC1/*.xml" ,
   $url = "*/EWS/mrsproxy.svc" ,
   $headercontains = "*" ,
   $destination = "C:/inetpub/logs/FailedReqLogFiles/W3SVC1/filter/"
)

Write-Verbose "Copy-FREBEvents:Start"
Write-Verbose "Copy-FREBEvents:Parameter:directory  :$($directory)"
Write-Verbose "Copy-FREBEvents:Parameter:url        :$($url)"
Write-Verbose "Copy-FREBEvents:Parameter:destination:$($destination)"

if (!(Test-path -path $destination -pathtype container)) {
   Write-Verbose "Create Destination $($destination)"
   mkdir $destination | out-null
}

foreach ($item in (Get-item $directory)){
   Write-Verbose " Processing File $($item.fullname)"
   [xml]$content = get-content -path $item.fullname
   if ($content.failedRequest.url -like $url) {
      Write-Verbose " MATCH URL"

      $ReqHeader = (($content.failedRequest.Event `
                     | where {$_.RenderingInfo.Opcode -eq "GENERAL_REQUEST_HEADERS"}).eventdata.data `
                     | where {$_.name -eq "Headers"}).'#text'
      if ($RegHeader -like $headercontains) {
         Write-Verbose " MATCH HeaderContains"
         copy-item -path $item.fullname -destination $destination
      }
   }
}
Write-Verbose "Copy-FREBEvents.End"

In der Standardfunktion kopiere ich alle Requests mit einer URL="*/EWS/mrsproxy.svc" in ein Unterverzeichnis "/filter".

Ich muss dann nur noch das Stylesheet "freb.xsl" kopieren und einen Edge-Browser mit folgender Option starten

start msedge.exe --allow-file-access-from-files

Wer schon etwas länger die MSXFAQ liest, kennt vielleicht die Seite NTLM-Anmeldung und und dass es ganz normal ist, dass auch eine erfolgreiche Anmeldung immer durch einen oder zwei 401-Fehler eingeleitet werden. Der erste Zugriff erfolgt quasi immer "anonym" und durch den ersten 401-Fehler liefert der Webserver die möglichen Anmeldeverfahren zurück. Wenn dort "negotiate" enthalten ist und vom Cient ausgewählt wird, dann enthält der zweite Request noch keine Anmeldedaten sondern erst die Information über die verschiedenen Negotiate-Alternativen, die der Webserver auswertet und in der zweiten 401-Antwort seine Auswahl und eine Zufallszahl mit sendet, die der Client mit seinen Anmeldedaten verrechnet und erst im dritten Paket die Anmeldung erfolgt. Wenn wir aber drei 401-Fehler sehen, dann hat etwas nicht geklappt und das letzte Paket in der Reihe ist interessant.

Hier ist die Fehlermeldung dann schon eindeutig:

Client's supplied SSPI channel bindings were incorrect. (0x80090346)

Auch ohne weitere Analyse der NTLM/Negotiate-Daten ist das ein deutliches Zeichen, dass "Extended Protection" hier nicht funktioniert hat.

Negotiate-Analyse

Ich habe mir dennoch einmal die Mühe gemacht, den "REQUEST_HEADER" zu extrahieren.

 

Hier können wir einmal das Feld "X-Forwarded-For" sehen, was ein deutliches Zeichen für einen Reverse Proxy ist, der freundlicherweise hier die IP-Adresse des externen Systems (52.97.218.221) liefert. Das war zu der Zeit einer der Exchange Online Server. Zudem sehen wir im Feld "X-AnchorMailbox" die GUID des Postfachs, auf welche die Anmeldung erfolgen soll.

Der Wert im Feld "Authorization" ist so erst einmal nicht klar lesbar, sondern muss erst BASE64-decodiert werden. Das Ergebnis ist allerdings keine Text, JSON, XML o.ä. Datenstruktur sondern binär. Aber man kann dennoch schon die Teiltexte erkennen, die in dem Negotiate-Paket enthalten sind:

Die im vorigen Paket zugesandte mit dem Server-Zertifikat verrechnete Zufallszahl, die dann vom Client mit dem bei ihm sichtbaren Zertifikat und dem Hashwert des Kennwort des Kontos verrechnet wurde, können wir hier nicht interpretieren. Aber dass das Konto wohl "miguser" heißt, die Anfrage vom Microsoft Server PADPRO08MB6223 kommt und er sich an der Domain MSXFAQ bzw. msxfaq.local anmelden und den Service Principalname "HTTP/mrs.msxfaq.de" ansprechen möchte, können Sie aber sehen.

Lösung

In dem Fall und mit der Vorarbeit war die Lösung dann schnell umgesetzt. Entweder installiere ich auf dem Exchange Server das identische Zertifikat, welches auch der ReverseProxy bei der eingehende Verbindung von Microsoft nutzt oder ich schalte "Extended Protection" ab. In meinem Fall habe als schnelle Lösung erst einmal EP abgeschaltet, denn der Tausch des IIS-Zertifikats könnte einen negativen Einfluss auf Systeme haben, die sich von intern gegen den Exchange Server verbinden. Er hat intern ja den Namen "ex01.msxfaq.local" und das externe Zertifikat enthält diesen Namen nicht. Dazu habe ich wieder das Skript von CSSExchange genutzt:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

Danach waren alle Einstellungen auf NONE.

Damit kann die Migration erst einmal weiter laufen und mit etwas Ruhe kann ich dann prüfen, welche Clients ein Problem damit hätten, wenn Sie von intern den Server direkt ansprechen.

Übrigens: Die Arbeit des MailboxReplicationService kann ich nach erfolgreicher Anmeldung durch Exchange Online dann doch wieder in mehreren Logfiles sehen.

REM Die Zugriffe auf /EWS/mrsproxy.svc  finde ich im Webserverlog des Frontend und des Backend
C:\Inetpub/logs/W3SVC1
C:\Inetpub/logs/W3SVC2

Interessanter finde ich die Logs von Exchange selbst und hier insbesondere im Ordner "MailboxReplicationService"

REM Auch Exchange protokolliert die Aktivitäten.
C:\Program Files\Microsoft\Exchange Server\V15\Logging\MailboxReplicationService
C:\Program Files\Microsoft\Exchange Server\V15\Logging\EWS

Allerdings sehen sie erst dann Zugriffe, wenn die Authentifizierung erfolgreich war.

Zusammenfassung

Exchange Online migriert Postfächer über den "Mailbox Replication Service" und greift dazu auf den MRSProxy-Service des lokalen Exchange Servers zu. Da eine Anmeldung per Kerberos technisch nicht möglich ist, bleibt nur die NTLM-Anmeldung. Eine Anmeldung per OAUTH wäre technisch sicher auch möglich und umsetzbar. Dazu müsste aber Exchange Online überhaupt erst einmal einen Header "Authorization: Bearer" setzen was ich aber im Request nicht gesehen habe. Dann würde Exchange OnPremises auch Bearer anbieten.

Halten wir fest: Für die Migration mit Exchange Online muss der lokale Exchange Server über einen öffentlichen Servernamen (FQDN) mit einem passenden Zertifikat erreichbar sein und wenn Sie auf dem Exchange Server die Funktion "Extended Protection" aktivieren, dann muss Extended Protection auch funktionieren. Das ist eigentlich erst einmal nichts, was uns überraschen sollte. Insofern ist die Seite eher für die Personen interessant, die über eine Suchmaschine und die Fehlermeldungen hier gelandet sind und hoffentlich und die Lösung wissen.

Weitere Links