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:
Wir sind gefühlt eine der letzten die Extended Protection aktivieren.. Wir setzen aktuell Exchange Server 2016 CU 23 April20324HU ein.
Nach dem Aktivieren haben wir extreme Probleme beim Verbinden von iOs Geräten. Immer wieder werden die Nutzer aufgefordert ein Passwort einzugeben. Eingabe -> wieder von vorne. Immer wieder …
Wir setzen einen Citrix Netscaler als Loadbalancer ein und haben alles wie beschrieben umgesetzt.
Hat jemand hier ähnliche Erfahrung gemacht?
Viele Grüße
Hallo Franky!
ich habe einen EX 2019 CU 13 mit aktuellem SecurityPatch….Wildcard-zertifikat ist auf WAF Sophos SG eingespielt und auch am Exchange.
Hab SSLOffloading abschalten müssen und dann ist das Skript durchgelaufen. Leider kam danach beim Neustart von Outlook (intern) das Anmeldefenster. Ist das normal bzw. was muss man noch tun etc.?
Virenschutz ist oftmals ein Problem. Bei uns wars Kaspersky… in der anderen Firma wo TrendMicro im Einsatz ist, war kein Problem erkennbar.
Ich habe leider seit der Aktivierung von Exchange Extended Protection ein MRS Problem.
Die Migratino Jobs schmieren mir ab bzw. gehen auf failed :(
Folgendes Setting ist offensichtlich daran Schuld;
Im IIS auf meinen vier ESXN (Cluster System + Exch Server 2016 mit DAG) , wird ja in den Default Web Site Settings im EWS (value wird auf allow gesetzt), ich habe es derweil auf none gestellt, und schon gehen die Migration Batches wieder.
Fehler der Migration Batches ist ein autodiscover.*.* Error.
Kennt das Problem irgendwer und kann irgendjemand helfen? Auch die Migration Batches kommen mir seitdem sehr viel langsamer vor :(
EWS Throttling ist bei mir deaktiviert (mittels Microsoft Call).
Es ist bitter und nervt etwas. Wäre über Unterstützung froh.
Falls jemand am Verzweifeln ist,
UTM WAF mit Exchange Extended Protection funktioniert.
Wir haben Laptops die sich extern per Outlook (MAPI) verbinden.
Bei uns war es der Virenscanner der ausgehende Verbindungen kontrolliert hat und dazu sein eigenes Zertifikat dazwischen geschaltet hat, was zu der „Endlosen Passwortabfrage“ geführt hat. Ausnahme für unsere URL eingerichtet und schon hat alles funktioniert, inklusive Reverse Authentication.
Wir verwenden das Get-SophosUTMCertificate.ps1 Skript mit leichten Anpassungen,
Franky, ein Vorschlag, aktualisiere das Skript (beim Import-ExchangeCertificate) und schreibe noch eine englische Anleitung.
Es gibt genug Menschen die an den neuen Einstellungen verzweifeln und Du bist immer wieder die Erleuchtung mit Deinem Beiträgen.
Ein Hinweis die lokalen Virenscanner zu kontrollieren könnte auch nicht schaden ;)
Vielen Dank für Deine super Texte
1000 Dank! Genau das war es bei uns (ESET).
Nachdem nun das Thema mit Archiving gefixed wurde überlegen wir das auch umzusetzen, gibts zum jährlichen Zertifikatstausch ein best practice? In Verbindung mit F5 HLB die SSL Bridging machen kommts ja hier gezwungenermaßen zu ner Downtime bis alle wieder das gleiche Cert haben oder? Das geht aktuell ja alles ohne Unterbrechung des Produktivbetriebs
Bei uns fehlt im Abschnitt „Default Web Site“ in der Zeile von „Autodiscover“ die Klammer „(128-bit)“. Ist das noch bei jemandem der Fall?
Exchange 2016 DAG.
Autodiscover; None; None; True; True; [FEHLT]; Ignore; False
Wir haben bei uns das Problem das Outlook for Mac nach der Aktivierung kein OAB mehr laden kann.
Das ist uns erst diese Woche aufgefallen, wenn nicht so viele neue Einträge erzeugt werden.
Leider mussten wir die Extended Protection für den OAB Pfad abschalten und haben bis jetzt auch noch keine andere Lösung dafür.
Kenn jemand das Problem?
Extended Protection causes Outlook for Mac not to update the OAB: https://support.microsoft.com/en-us/topic/extended-protection-causes-outlook-for-mac-not-to-update-the-oab-4c08e7a6-30f2-4338-b0c2-fe48605f5f02
Leider sind meine Sonderzeichen beim Post verschwunden:
also nochmal:
WAF – (http oder https) – LB – ( https ) – EX ( gleiches Zertifikat auf LB und EX )
Moin Frank,
ich habe dieses Thema auch demnächst vor der Brust und hätte eine kurze
Verständnisfrage:
Ist es tatsächlich Relevant was die WAF macht wenn ich noch einen LB habe? Oder reicht/zählt nicht der LB in der Verbindung mit den Exchangeservern?
Nach meinen bisherigen Verständnis würde es so gehen?
WAF LB Exchange (gleiche Zertifikat auf LB und EX)
Grüße
Alle müssen das gleiche Zertifikat nutzen. Ansonsten ist es ja ein Man-in-the-Middle und genau das soll ja verhindert werden.