Hybrid Agent, Extended Protection und Port 9821

Wenn Sie HCW einrichten und mittlerweile Exchange 2019 mit CU14 installiert haben, dann kann ihr Setup mit einem suspekten Fehler scheitern, dass etwas nicht per TCP über den Port 9812 kommunizieren kann. Hier erkläre ich die Ursache bei meiner Umgebung. Spoiler: Exchange Extended Protection war schuld, welches mit CU14 per Default aktiviert wurde.

Fehlerbild "net.tcp" auf Port 9821

Einer meiner Labor-Umgebungen besteht aus einem Windows 2016 Domain Controller und einem Exchange 2019 Cluster-Server, der Anfang 2024 auf den aktuellen Patchlevel CU14 gebracht wurde. Einige Zeit später wollte ich diese Umgebung, die eigentlich nicht aus dem Internet erreichbar ist, zu einem Labor über "Modern Hybrid" machen. Also habe ich einen Zugang zum Internet bereitgestellt und den aktuellen HCW gestartet. Nach Eingabe aller erforderlichen Zugangsdaten ging HCW an die Arbeit und installiert natürlich den "Hybrid Updater Agent" und Hybrid Agent". Allerdings konnte die Installation nicht abgeschlossen werden.

Mir war eigentlich nicht bekannt, dass mein Agent eine ausgehende Verbindung auf so einen "komischen" Port aufbauen möchte.

Logging

Zur Fehlersuche habe ich mit zuerst die verfügbaren Protokolle angeschaut. Sowohl der HCW als auch der Agent schreiben entsprechende Textdateien in verschiedene Verzeichnisse.

Weitere Informationen zu den Protokolldateien finden Sie auf HCW Logging

Sehr schnell habe ich die Stelle gefunden, bei der ein Fehler auftritt. Anscheinend richtet HCW den Agenten als auch den AzureADAppProxy ein und startet dann einen "Test-MigrationServerAvailability". Im Log steht dann aber:

2024.11.05 14:23:13.397   10276 [Client=UX, Session=Tenant, Cmdlet=Test-MigrationServerAvailability, Thread=12]
                                        START Test-MigrationServerAvailability 
                                           -ExchangeRemoteMove: $true 
                                           -RemoteServer '<GUID>.resource.mailboxmigration.his.msappproxy.net' 
                                           -Credentials (Get-Credential -UserName UCLABOR\fcadmin)
2024.11.05 14:23:18.825   10277 [Client=UX, Session=Tenant, Cmdlet=Test-MigrationServerAvailability, Thread=12]
                                      FINISH Time=5428,0ms Results=1
                                       {ErrorDetail=Microsoft.Exchange.Net.CommunicationErrorTransientException: 
                                           The call to 'net.tcp://fr0p281mb1770.deup281.prod.outlook.com:9821/Microsoft.Exchange.MailboxReplicationService 
                                           FR0P281MB1770.DEUP281.PROD.OUTLOOK.COM 
                                              (15.20.8114.28 ServerCaps:FFFFFFFF, 
                                               ProxyCaps:1FFFFFFFFFFFFFFFC7DD2DFDBF5FFFFFCB07EFFF,
                                               MailboxCaps:, legacyCaps:FFFFFFFF)' failed. 
                                        Error details: The call to 'https://eb92551b-9c63-4472-a8dc-2be7fcf00313.
                                                 resource.mailboxmigration.his.msappproxy.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'...  

Die Fehlermeldung mit "Negotiate, NTLM" kenne ich auch schon von MRS und Extended Protection und da war es auch Extended Protection. Für den Hybrid Agent haben wir nun schon einmal zwei Adressen und URLs die ich prüfen kann.

DNS, Ports und Firewall

Zuerst habe ich natürlich geschaut, ob die Namen auflösbar und die Ports erreichbar ist. Solches losgelösten Aufrufe lassen sich dann natürlich auch einfacher in FirewallLogs und ProxyLogs wiederfinden. Die DNS-Anfrage mit dem Check auf Port 9821 hat nicht funktioniert aber der HTTPS-Request gegen den von Microsoft über den Agenten freigegeben Agenten konnte ich zumindest zu einem 403 verleiten.

Das war aber erwartet, da ich keine Anmeldedaten mit übergeben habe und selbst mit Anmeldedaten ist ein "Invoke-RESTMethod" kein gültiger MRS-Request. Der Verbindungsversuch auf Port 9821 wurde vom Client gar nicht erst gestartet, denn der Name ist schon nicht per DNS auflösbar. Das sind wohl interne Servernamen für Migrationen, die nicht allgemein erreichbar sind.

Wireshark

Parallel habe ich auf dem Server mit Wireshark mitgeschnitten aber auch hier nur die üblichen Verbindungen zu Exchange Online gesehen.

Mein Hybrid Agent hat also definitiv keine Verbindung zu diesem Port 9821 und die Fehlermeldung ist also eher irreführend statt hilfreich. Auf dem lokalen Server hat der Hybrid Agent aber auch keinen Port 9821 irgendwo geöffnet. Es gab zumindest bei mir keinen entsprechenden Port, wie ich per Admin-PowerShell und Get-NETConnection schnell ermitteln konnte:

PS C:\> Get-NetTCPConnection -LocalPort 9821

 

Es dürfte sich also ein interne Port in der Microsoft 365 Cloud handeln, über den Exchange Online eine Brücke zum lokalen Exchange Server schlägt.

IISLOG

Nun weiß ich natürlich, wie der Zugriff von Exchange auf einen lokalen Exchange Server über den Exchange Hybrid Agent und Azure AD Application Proxy im Grund funktioniert. Die Cloud geht zu ihrer Gegenstelle, die dann die Verbindung zum lokalen Agent durchreicht, der sich dann zum Exchange Server verbindet. Also sollte ich die Versuche auf meinem Exchange Server finden. Mit der Uhrzeit, ggfls. korrigiert um die Zeitzonen habe ich dann folgende Zugriffe mehrfach gefunden

Der erfahren Exchange und IIS Administrator sieht gleich, dass dies keine "normale" Anmeldung ist. Klassisch sind bei "Negotiate" immer drei Zeilen:

  • Zeile 1: zeigt den anonymen Zugriff mit einem 401.0-Fehler
    Der Client auf der anderen Seite bekommt damit erst einmal mit, das eine Anmeldung erforderlich ist und welche Protokolle unterstützt werden
  • Zeile 2: Der Client sendet "Negotiate" aber der Server liefert dann einen 401.1 mit Details
    Erst nun hat der Client z.B. einen Salt oder Startwert für die eigentliche NTLM-Challlenge
  • Zeile 3: 401 oder 200
    Hier sehen wir dann, ob die Anmeldung erfolgreich war oder eben nicht

In meinem Beispiel sehen Sie, dass die ersten Versuche gegen 14:23:55 alle mit 3x 401 beendet wurden. die verschiedenen erweiterten Fehlercodes gebe mir die ersten Hinweise:

401.1 == logon failure.   2148074254 = no credentials were supplied. 
401.1 == logon failure.   2148074248 = SEC_E_INVALID_TOKEN
401.1 == logon failure.   2148074310 = SEC_E_BAD_BINDINGS

Insbesondere beim "2148074310 = EC_E_BAD_BINDINGS" klingelt bei mir was.

Extended Protection

Microsoft hat vor einige Jahren schon den Support für Exchange Extended Protection eingebaut aber mit Exchange 2019 CU14 wird Exchange Extended Protection nun  per Default eingeschaltet. Das hat bislang immer die Firmen erwischt, die einen Loadbalancer oder Reverse-Proxy vor ihren Exchange Server geschaltet und die TLS-Verbindung aufgebrochen haben. Allerdings betrifft Extended Protection auch den Exchange Hybrid Agent, denn technische verbindet sich der Migration Server von Exchange Online nicht direkt mit dem lokalen Exchange Server sondern mit einem ReverseProxy in Azure und von dort geht es dann weiter zum lokalen Exchange Server. Natürlich kommen dabei unterschiedliche Zertifikate zum Einsatz und damit ist auch klar warum die NTLM-Anmeldung bricht.

Fragen Sie mich bitte nicht, warum Microsoft hier immer noch NTLM verwenden und nicht z.B. auch OAUTH-Tokens setzt.

Die Lösung besteht hier darin, die Funktion Extended Protection zu deaktivieren.

Sie können die Funktion natürlich manuell im IIS abschalten aber am einfachsten geht es über das PowerShell Skript von CSS-Exchange:

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

Es ist eigentlich zum Einschalten der "Extended Protection"-Funktion vorgesehen und zeigt sogar explizit an, dass sie EP nicht mit mit dem Hybrid Agent aktivieren dürfen. Interessanterweise steht dies nicht in den Dokumentationen.

Ich bin ziemlich sicher, dass noch mehr Firmen mit bereits installiertem Hybrid Agent beim nächsten Update auf CU14/CU15 genau auf dieses Problem stoßen könnten.

Wenn ich das Skript mit dem Parameter "-DisableExtendedProtection" aufrufe, dann schaltet es EP ab.

Eigentlich könnte Microsoft sehr einfach bei der Installation von CU14 erkennen, dass es einen Hybrid Agent gibt und darauf hinweisen oder die Aktivierung nicht machen.

Problem gelöst

Nachdem ich aber Extended Protection auf meinem Exchange Server abgeschaltet habe, konnte HCW die Installation auch verifizieren.

Im IISLog ist dann zu sehen, dass ab 17:16 die Zugriffe nach zweimal 401-Meldungen mit einem 200 OK quittiert wurden.

Damit steht nun einer weiteren Migration und Koexistenz nichts mehr entgegen.

Denken Sie aber immer daran, dass der "Modern Hybrid Agent" sich nicht um die Teams-Integration oder SMTP-Routing kümmert.

Weitere Links