ExchangeServer

Extended Protection (Exchange)

Allgemeine Infos

Extended Protection (EP) ist eine Funktion von Windows Server, die die vorhandene Windows-Authentifizierung gegen Authentication-Relay- und Man-in-the-Middle-Angriffe absichert. Dazu prüft IIS ein Channel Binding Token (CBT), das die Anmeldung an die konkrete TLS-Verbindung bindet. Ein Angreifer, der NTLM-Anmeldedaten abfängt und an Exchange weiterleitet, scheitert, weil seine TLS-Sitzung nicht zum Token passt.

Exchange unterstützt EP seit den Security Updates vom August 2022; Exchange 2016 und 2019 brauchen dafür mindestens das CU vom September 2021 beziehungsweise das 2022 H1 CU. Seit Exchange Server 2019 CU14 (2024 H1 CU, Februar 2024) aktiviert das Setup EP standardmäßig. Microsoft verlangte EP damals auch, um CVE-2024-21410 vollständig zu schließen, eine Rechteausweitung über NTLM-Relay. Die Microsoft-Dokumentation gilt für Exchange 2016, 2019 und Exchange Server SE und warnt, dass ein Abschalten den Server für bekannte Schwachstellen angreifbar macht.

Abgrenzung: EP hat nichts mit den Extended Security Updates (ESU) für Exchange 2016 und 2019 zu tun. Es betrifft die Webdienste in IIS (Outlook im Web, ECP, EWS, MAPI, RPC, ActiveSync), nicht den SMTP-Mailflow. Eng verbunden ist es mit der Exchange-Zertifikatsverwaltung, weil Exchange und Load Balancer dasselbe Zertifikat nutzen müssen, und mit dem Microsoft Hybrid Agent, für den eine Ausnahme beim EWS-Frontend gilt.

Funktionsweise & Details

EP wird je virtuellem Verzeichnis in IIS gesetzt und kennt drei Stufen: None (keine CBT-Prüfung), Allow (Prüfung aktiv, Clients ohne EP-Unterstützung bleiben zugelassen) und Require (Clients ohne EP werden abgewiesen). Die Einrichtung läuft so:

  1. Voraussetzungen herstellen: identische TLS-Konfiguration auf allen Exchange-Servern, SchUseStrongCrypto und SystemDefaultTlsVersions explizit auf 1, kein NTLMv1 (LmCompatibilityLevel empfohlen 5, mindestens 3) und kein SSL-Offloading für Outlook Anywhere.
  2. Das Microsoft-Skript ExchangeExtendedProtectionManagement.ps1 (aka.ms/ExchangeEPScript) in einer erhöhten Exchange Management Shell mit Organization-Management-Rechten starten. Es kontrolliert CU- und SU-Stand sowie TLS-Konsistenz aller Server und bricht bei Abweichungen ab.
  3. Das Skript setzt die empfohlenen Werte, etwa Require für OWA, ECP, MAPI und RPC sowie Allow für EWS, ActiveSync und OAB im Default Web Site; im Exchange Back End steht fast überall Require.
  4. Für Server, die über den Hybrid Agent veröffentlicht sind, nimmt -ExcludeVirtualDirectories "EWSFrontEnd" das EWS-Frontend aus, sonst scheitern Postfachverschiebungen und Frei/Gebucht-Abfragen.
  5. Mit -DisableExtendedProtection setzt Du EP auf allen oder mit -ExchangeServerNames auf einzelnen Servern wieder auf None.

Beim Setup ab Exchange 2019 CU14 steuern die Schalter /DoNotEnableEP und /DoNotEnableEP_FEEWS, ob EP beziehungsweise EP auf dem EWS-Frontend aktiviert wird.

Vorteile & Nutzen

  • Weitergeleitete NTLM-Anmeldungen laufen ins Leere, weil das Token an die TLS-Sitzung des echten Clients gebunden ist; das entschärft eine ganze Angriffsklasse auf Exchange.
  • Der Schutz setzt am Prinzip des Relay-Angriffs an und wirkt deshalb auch gegen Varianten, für die es noch kein Update gibt.
  • Das Microsoft-Skript kontrolliert die Voraussetzungen vorab und setzt alle virtuellen Verzeichnisse einheitlich, was Tippfehler in IIS vermeidet.
  • Ab Exchange 2019 CU14 ist EP ohne Zusatzaufwand aktiv, sofern TLS, Zertifikate und Load Balancer passen.

Praxisbeispiel

Ein Logistikunternehmen mit 150 Postfächern veröffentlicht Outlook im Web über einen Load Balancer mit SSL-Offloading. Nach dem Update auf Exchange 2019 CU14 ist EP aktiv, Outlook fragt ständig nach Kennwörtern und OWA-Anmeldungen schlagen fehl, weil der Load Balancer die TLS-Verbindung aufbricht. Die IT stellt den Load Balancer auf SSL-Bridging mit demselben Zertifikat wie auf den Exchange-Servern um, gleicht die TLS-Einstellungen beider Server an und führt das EP-Skript erneut aus. Danach melden sich Outlook und OWA ohne Rückfragen an, und der Skriptlauf meldet keine Abweichungen mehr.

Worauf sollte man achten?

  • SSL-Offloading ist mit EP nicht unterstützt; bei SSL-Bridging muss der Load Balancer exakt dasselbe Zertifikat wie Exchange verwenden.
  • Bei jeder Zertifikatserneuerung EP zuerst per Skript abschalten, das neue Zertifikat für IIS auf allen Mailbox-Servern und am Load Balancer zuweisen und EP danach wieder aktivieren.
  • Drittanbieter-Software vorab testen: Virenscanner, die Verbindungen über einen lokalen Proxy leiten, gelten als Man-in-the-Middle und werden blockiert.
  • OWA und ECP über Microsoft Entra Application Proxy zu veröffentlichen, ist mit EP nicht unterstützt; Safari unter macOS und iOS scheitert an NTLM-SSO für OWA, hier helfen Hybrid Modern Authentication oder Microsoft Edge unter macOS.
  • Das virtuelle Verzeichnis PowerShell im Default Web Site nur auf Anweisung des Microsoft-Supports ändern.

Lizenz & Verfügbarkeit

Extended Protection ist Bestandteil von Windows Server und Exchange Server und kostet nichts extra. Unterstützt wird es ab den August-2022-SUs für Exchange 2016 und 2019, standardmäßig aktiv ist es ab Exchange 2019 CU14; die Microsoft-Dokumentation gilt auch für Exchange Server SE. Exchange 2016 und 2019 haben im Oktober 2025 das Support-Ende erreicht, Sicherheitsupdates gibt es dafür nur noch über das separat zu erwerbende ESU-Programm. Stand: Oktober 2026.

Fazit

Extended Protection gehört auf jeden Exchange-Server, der Windows-Authentifizierung anbietet. Bring vorher TLS, Zertifikate und Load Balancer in Ordnung, dann läuft EP ohne Nebenwirkungen.

Weiterführende Links

Verwandte Artikel