[English]Mit dem CU14 will Microsoft bei Exchange Server 2019 standardmäßig die Windows Server-Funktion Extended Protection zur verbesserten Absicherung aktivieren. Diese Funktion soll sich aber bei der Installation des CU14 bei Bedarf deaktivieren lassen. Das hat Redmond zum 28. August 2023 bekannt gegeben. Weiterhin gibt es die Ankündigung, dass Exchange 2016/2019 endlich Support für HTTP Strict Transport Security (HSTS) bekommen. Auch das hat Microsoft gerade in einem Techcommunity-Beitrag bekannt gegeben.
Exchange 2019 CU14 aktiviert Extended Protection
Extended Protection (EP) ist eine Windows-Funktion, die Server vor Angriffen vom Typ „Man in the Middle“ (MiTM) schützen soll. EP ermöglicht innerhalb der Windows-Authentifizierung in IIS eine Bindung zwischen den auf der Anwendungsschicht übergebenen Authentifizierungsinformationen und der TLS-Kapselung auf den unteren Ebenen des Protokollstapels. Die Authentifizierungsinformationen werden auch ergänzt, indem der Namespace, auf den der Client zugreift, in die Verbindung aufgenommen wird. Wenn ein MiTM nicht den Namensraum repräsentiert, den der Server erwartet, oder wenn er die TLS-Informationen zwischen Client und Server manipuliert, ist die Bindung ungültig und die Authentifizierungsanfrage schlägt fehl. Dies macht NTLM-Relay- und Ticket-Replay-Szenarien für böswillige Akteure viel schwieriger.
Gemäß obigem Tweet und diesem Techcommunity-Artikel vom 28. August 2023 hat Microsoft angekündigt, dass ab dem kumulativen Update (CU) CU14 (Freigabe ist für das 2. Halbjahr 2023 geplant) für Exchange Server 2019 Extended Protection (EP) standardmäßig aktiviert wird. Exchange Server 2019 befindet sich derzeit im Mainstream-Support und ist die einzige Version, die noch CUs erhält.
Administratoren können diese Standardeinstellung jederzeit nach Installation des CU14 wieder deaktivieren, und ggf. zu einem späteren Zeitpunkt erneut aktivieren, schreibt Microsoft. Um EP zu deaktivieren, müssen Administratoren die Befehlszeilenversion von Setup verwenden (die Details zum Aufruf will Microsoft zu einem späteren Zeitpunkt dokumentieren). Wird das CU14 über die GUI-Version installiert, wird die EP-Option automatisch aktiviert. Wer das unbeaufsichtigte Setup oder Skripte zur Bereitstellung von CUs verwendet, muss diese so ändern, dass der neue Setup-Parameter hinzugefügt wird, um EP zu deaktivieren.
Microsoft empfiehlt aber allen Kunden, EP in ihrer Umgebung zu aktivieren. Wenn auf Ihren Servern das SU vom August 2022 oder eine neuere SU installiert ist, wird EP bereits unterstützt. Server, die auf einem Patchstand älter als die SU vom August 2022 sind, gelten als dauerhaft anfällig und sollten sofort aktualisiert werden. Wenn Sie außerdem Exchange-Server haben, die älter sind als die SU vom August 2022, wird die Server-zu-Server-Kommunikation mit Servern, auf denen EP aktiviert ist, unterbrochen. Weitere Details sind in diesem Techcommunity-Artikel zu finden.
Exchange 2016/2019 bekommen HSTS-Support
In einer weiteren Ankündigung, siehe folgenden Tweet, hat Microsoft im Techcommunity-Beitrag Announcing support for HSTS on Exchange Server 2016 and 2019 angekündigt, dass nun HTTP Strict Transport Security (HSTS) offiziell unterstützt werde.
HSTS ist ein Richtlinienmechanismus, der dazu beiträgt, Websites (OWA oder ECP bei Exchange Server) vor Man-in-the-Middle-Angriffen wie Protokoll-Downgrade-Angriffen und Cookie-Hijacking zu schützen. Es handelt sich um einen weithin unterstützten Standard, der in RFC 6797 definiert wurde. Die HSTS-Unterstützung ermöglicht Webservern Browsern vorzugeben, dass Anfragen des Browsers nur über HTTPS-Verbindungen erfolgen sollten. Dies stellt sicher, dass Verschlüsselung und Authentifizierung bei der Übertragung verwendet wird. HSTS verhindert, dass Benutzer Warnungen vor ungültigen Zertifikaten (z. B. abgelaufene, ungültige oder nicht vertrauenswürdige Zertifikate, Namensübereinstimmungen usw.) umgehen können. Versucht ein Angreifer einen Protokoll-Downgrade-Angriff oder einen Man-in-the-Middle-Angriff, erkennt der Browser die Verletzung der HSTS-Richtlinie und bricht die Verbindung ab.
Microsoft hat diese Dokumentation mit den notwendigen Schritten zur Konfiguration von HSTS auf Exchange Server 2016 und 2019 veröffentlicht. Der Exchange HealthChecker soll in Kürze ein Update erhalten, damit dieser anzeigen kann, ob die HSTS-Konfiguration auf dem Exchange Server wie erwartet eingerichtet wurde.
Frage zu HSTS: mir wird nicht ganz klar ob HTTP to HTTPS Redirection aktiviert werden muss oder nicht?!
Wir haben den Standardwert: keine Umleitung, SSL erforderlich auf der Default Web Site.
Nein, es muss (darf) nicht aktiviert werden. Falls es gewünscht ist, dann wie in dem anderen Microsoft Artikel beschrieben konfigurieren.
Danke! Dann ist es relativ simpel. Mal paar Tage abwarten was andere berichten und nicht funktioniert ;)
Modern Hybrid Agent wir auch nicht unterstützt. Ganz toll.
„Wer zu spät kommt den bestraft das Leben.“, oder TYPISCH Microsoft!
„Extended Protection for Authentication“ haben die Frickler aus Redmond schon unter Windows XP SP3 mit diversen Sicherheitsupdates (siehe https://web.archive.org/web/20161110083546/https://support.microsoft.com/en-us/kb/968389, , , https://support.microsoft.com/en-us/kb/973917, , https://support.microsoft.com/en-us/kb/2345886, https://support.microsoft.com/en-us/kb/2509470, …) vor ca. 18 (in Worten: ACHTZEHN) Jahren in VIELEN Systemkomponenten und Anwenderprogrammen implementiert, es in ihrer unendlichen Weiss^WDummheit aber nicht für nötig erachtet, ihren als „Exhange“ berüchtigten, notorisch unsicheren Schrott ebenso zu behandeln!
Dito HSTS, das ebenfall schon vor VIELEN Jahren eingeführt wurde.
EINMAL mit Profis arbeiten…
Von den angeführten Links gehen grad mal zwei, der Rest führt zu „Sorry, page not found“.
Wer „einmal mit Profis arbeiten“ in ein Forum setzt, sollte nicht selbst im IT-Glashaus sitzen….
wenn man HSTS aktiviert, dürfte OWA über ein selbst signiertes Zertifikat nicht mehr funktionieren oder? Da man die Meldung ja im Browser „wegklicken“ kann.
d.h. man wird u.A. zu Let’s Encrypt gezwungen ?
Wenn OWA extern verfügbar ist, ist ein Self Signed Cert sowieso fahrlässig. User sollten nicht darauf trainiert werden, Fehlmeldungen wegzuklicken, sondern die Webseite sofort zu schließen und den Support zu kontaktieren. Denn entweder ist das eine Phishing-Seite oder der Admin hat Mist gebaut.
Bei solchen Meldungen kann ich MS verstehen, dass sie immer mehr Security erzwingen. Der schlechte Ruf von Exchange basiert ja zum Großteil auf schlechten Konfigurationen.
Intern reicht natürlich ein Zertifikat der eigenen CA.
Owa ist extern bei uns nicht verfügbar. Über VPN einwählen und dann die interne OWA Seite öffnen. Geht das dann noch ?
wenn du die zertifikate vorher verteilt hast oder die auf einem domain trust zertifikat basieren, ja.
„HSTS“ != „HSTS Preloading“
meine Frage ist einfach, ob mein selbst erstelltes Zertifikat, welches automatisch vom Exchange 2019 Server erstellt wird, intern noch funktioniert, falls ich diese Funktion „HSTS“ aktiviere.
Kann mir das jemand beantworten?
Ziel ist es, weiterhin per VPN sich anzumelden und dann Owa zu öffnen.
Die Frage wurde oben bereits beantwortet. Wenn die Clients eine Zertifikatswarnung erhalten und diese umgehen, dann wird es mit HSTS nicht mehr funktionieren. Siehe entsprechenden MS Artikel – ganz am Ende des Artikels sind Beispielbilder wo man die Warnung nicht mehr umgehen kann.
Alternativ: setze den IIS Eintrag mit dem Testwert „300“ und schau was passiert. Gibt es Probleme, entferne den Eintrag wieder. In deinem Fall ohne „preload“.
Extended Protection habe ich hier auf dem Exchange 2016 schon seit Monaten aktiviert.
Läuft ohne Probleme.