Das Sicherheitsfeature „Windows Extended Protection“ wurde mit einem Sicherheitsupdate im August 2022 für Exchange Server 2013, 2016 und 2019 eingeführt und schützt vor „Man in the middle (MitM)-Angriffen.
In kleinen Organisationen, in den es nur einen einzelnen Exchange Server, ohne Loadbalancer und Web Application Firewalls gibt, kann Windows Extended Protection recht einfach aktiviert werden. In größeren Umgebungen mit Exchange DAG, Loadbalancern und WAFs, müssen aber aber ein paar wichtige Dinge beachtet werden.
Loadbalancer / WAF und Windows Extended Protection
In der Regel kommen auf Loadbalancern und Web Application Firewalls SSL Bridging oder SSL Offloading zum Einsatz. Extended Protection unterstützt nur SSL Bridging, aber kein SSL Offloading. Das nächste Bild zeigt das Verhalten von SSL Bridging:
Wenn SSL Bridging zum Einsatz kommt, müssen WAF, Loadbalancer und Exchange Server das gleiche Zertifikat verwenden. Unterschiedliche Zertifikate, beispielsweise ein Zertifikat von einer Internen PKI auf Exchange Server und Loadbalancer und ein öffentliches Zertifikat auf der WAF, funktionieren nicht mit Windows Extended Protection.
Loadbalancer unterstützen meistens 3 verschiedene Arten, wie mit https Verbindungen umgegangen wird. Hier mal ein Beispiel anhand eines Kemp Loadbalancers und den Exchange Templates:
HTTPs-Passthrough und HTTPS re-encrypted funktionieren mit Windows Extended Protection, wenn der Loadbalancer das gleiche Zertifikat wie die Exchange Server verwendet. HTTPS Offload wird nicht unterstützt.
Manchen AntiVirus / Endpoint Security Programme entschlüsseln ebenfalls HTTPS Verbindungen mit einem eigenen Zertifikat auf dem Client. Diese Programme arbeiten also auch mit SSL Bridging, ähnlich wie es Loadbalancer und WAFs tun, aber auch dabei handelt es sich um eine MitM-Methode, welche durch Windows Extended Protection verhindert werden soll. Wird solche Software eingesetzt, muss hier eine Ausnahme für die Verbindungen mit Exchange konfiguriert werden.
Unterstützte Exchange Versionen
Wie bereits eingangs erwähnt, wurde Extended Protection im August 2022 mit einem Sicherheitsupdate für Exchange Server nachgerüstet. Alle Exchange Server in der Organisation müssen also mindestens das Update aus August 2022 installiert haben.
Hier sind einmal die Build Nummern die mindestens vorhanden sein müssen:
| Name | Veröffentlicht | Build (kurz) | Build (lang) |
| Exchange Server 2019 CU12 Aug22SU | 9. August 2022 | 15.2.1118.12 | 15.02.1118.012 |
| Exchange Server 2016 CU23 Aug22SU | 9. August 2022 | 15.1.2507.12 | 15.01.2507.012 |
| Exchange Server 2013 CU23 Aug22SU | 9. August 2022 | 15.0.1497.40 | 15.00.1497.040 |
Am besten bringt man vor der Aktivierung von Windows Extended Protection alle Exchange Server auf das jeweils aktuellste Patchlevel. Sollte es noch Exchange 2013 Server mit Öffentlichen Ordnern geben, dann müssen diese zu Exchange 2016 oder Exchange 2019 migriert werden. Außerdem funktioniert Extended Protection nicht mit der Modern Hybrid Konfiguration.
TLS Einstellungen der Exchange Server
Alle Exchange Server der Organisation müssen die gleichen Einstellungen für TLS verwenden. Hier ist der Exchange Health Checker eine große Hilfe, denn dieser prüft die TLS Einstellungen und zeigt an, wenn TLS 1.2 für den Server nicht aktiviert ist.
Die erforderlichen TLS Einstellungen lassen sich bequem mit dem Script aus diesem Beitrag konfigurieren:
Extended Protection aktivieren
Zur Aktivierung von Exended Protection hat Microsoft ein PowerShell Script zur Verfügung gestellt, welches die nötigen Einstellungen vornimmt und auch eine Vorabprüfung der Voraussetzungen durchführt. Das Script kann hier runtergeladen werden:
Das Script lässt sich dann in der Exchange Shell mit administrativen Berechtigungen ausführen:
.\ExchangeExtendedProtectionManagement.ps1
Der Status der Extended Protection lässt sich wie folgt prüfen:
.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection
Falls es Probleme gibt, lassen sich die Änderungen durch das Script mit den folgenden beiden Befehlen wieder rückgängig machen:
.\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig"
.\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestrictTypeEWSBackend"
In dem folgenden Artikel finden sich weitere Informationen: