Exchange mit Extended Protection veröffentlichen

Diese Seite behandelt die unterschiedlichen Optionen einen Exchange OnPremises Server zu veröffentlichen, wenn Sie z.B. Exchange Extended Protection nutzen. IIS Extended Protection verhindert Angriffe über NTLM-Angriffe (CVE-2024-21410 Betrachtung) aber durch die Abhängigkeit von Zertifikaten einige Randbedingungen zu beachten.

Extended Protection erfordert, dass der Exchange Server, der die Authentifizierung ausführt das identische Zertifikat zum HTTPS-Verschlüsseln nutzt, welche auch der Client bei seinem Verbindungsaufbau erhält. Ein Proxy oder Namensänderungen o.ä. dazwischen sind nur unter dieser Voraussetzung erlaubt.

Worum geht es?

Heute reicht es nicht mehr, wenn Sie ihren Mailserver aus ihrem internen Netzwerk für Clients erreichbar machen. Anwender sind im Homeoffice, auf Reisen oder nutzen ein Smartphone und erwarten einfach von überall Zugriff auf ihre Mails. Der Client muss also aus dem Internet auch den lokalen Exchange Server über HTTPS erreichen. Folgende Dinge kommen dabei zusammen.

  • Die Exchange Dienste müssen per HTTPS auf Port 443 erreichbar sein
    Kaum jemand wird Exchange mit einem Bein ins Internet stellen. Oft es ist es aber auch nur eine Reverse-NAT-Veröffentlichung. In der Regel stehen aber ein Reverse Proxy oder Web Application Firewall davor.
  • Passendes Zertifikat
    Für den Zugriff von Intern reicht oft ein Zertifikat von einer internen PKI. Das hilft insbesondere, wenn der DNS-Name nicht zum Internet kompatibel ist und sie kein öffentliches Zertifikat bekommen können. Aus dem Internet sollte es ein öffentliches Zertifikat rein, damit die Client keine Zertifikatwarnungen bekommen
  • Passende Internal/External-URLs
    Die Einstellungen helfen Exchange - Autodiscover die richtigen Antworten zu liefern. Oft werden intern und extern unterschiedliche Namen genutzt, was Auswirkungen auf Zertifikate hat.

Die Herausforderung dabei ist, die Zugriffe der verschiedenen Clients über die Eingangstüren entsprechend zu steuern und das Setup kann unterschiedliche komplex sein. Hier einmal der XXL-Aufbau mit den meisten denkbar Bausteinen

  • Interne Clients sprechen den internen Loadbalancer an, der die Zugriffe auf die Frontend-Rolle verteilt.
  • Externe Clients landen auf einer Web Application Firewall in der DMZ, die Zugriffe nach entsprechender Prüfung ebenfalls an die FrontendRolle sendet.
  • Die Frontendrolle leitet die Zugriffe nach entsprechender Authentifizierung an die für das Postfach aktive Mailboxrolle weiter.

Seit dem Hafnium Exploit im Jahr 2021 haben wir Exchange Administratoren das Bedürfnis, die Exchange Server besser zu sichern und z.B. URLs und Inhalte zu prüfen und zu filtern. Allerdings hat dann CVE-2024-21410 im Feb 2024 gezeigt, dass genau das Aufbrechen von SSL-Verbindungen zur Analyse wiederrum "Man in the Middle"-Angriffe über NTLM erst ermöglicht, weil wir  Exchange Extended Protection dann nicht einschalten können. Die Funktion des IIS (IIS Extended Protection) erfordert eine durchgängige Verbindung vom Client zum Frontend-Webserver, welcher die Authentifizierung durchführt. Selbst Tricks wie Kerberos - Constraint Delegation und Double Hop funktionieren nicht für externe Anwender, da diese ja kein Kerberos-Ticket liefern.

Exchange Frontend und Mailbox

Wenn Sie die Exchange Architektur von Exchange anschauen, dann finden Sie auf jedem Exchange Server nicht nur eine Webseite, sondern immer zwei virtuelle Webseiten:

Sie sehen auch, dass die "Exchange Back End"-Seite deutlich mehr virtuelle Verzeichnisse anbietet aber von Client eigentlich nicht angesprochen werden sollte. Die "Default Webseite" nimmt die Anfragen der Client auf Port HTTP/80 und HTTPS/443 an, authentifiziert den Zugriff und gibt dann die Anfrage als "Reverse Proxy" auf den passenden Backend-Server (Port 81/444) weiter. Bei einem "Single Server" ist dann eine Verbindung auf die lokale Backendseite. In Umgebungen mit mehreren Servern wird die Verbindung vom Frontend zu dem Backend Server aufgebaut, der die aktive Datenbank zum Postfach hat. Die Vorteile liegen auf der Hand: Die Verbindung des Clients bleibt auf dem einen Server, egal ob sein Postfach einmal schwenkt und wenn der Frontend ausfällt, kann er beliebiger anderer Frontend die Verbindung wieder aufnehmen.

Das bedeutet für die Zertifikate, dass der Client sich immer nur zur Frontend-Seite verbindet. Welche Zertifikate auf dem Backend-Server gebunden sind, ist eigentlich egal, denn Exchange "kennt" ja seine Server. Eine Verbindung von Frontend zu Frontend kann es aber auch geben, z.B. wenn die Server in unterschiedlichen AD-Sites sind und die andere Site keine "ExternalURL" konfiguriert hat.

Exchange DNS-Namen

Der Zugriff auf Exchange Server aus dem internen LAN funktioniert auch mit selbstsignierten Zertifikaten und Namen wie "SRVEX01.ad.local", da der Exchange Server bei der Installation sich automatisch ein Zertifikat selbst ausstellt, im Active Directory veröffentlicht und Outlook so smart ist, dem Zertifikat zu vertrauen, wenn es den Zugangspunkt per SCP (Autodiscover und SCP) bekommen hat. ein Browser mit OWA, ein SmartPhone mit ActiveSync oder ein externer Zugriff aus dem Internet wird natürlich eine Zertifikatswarnung liefern. Also brauchen wir früher oder später auch "richtige" Zertifikate einer öffentlichen PKI. Damit müssen Sie sich auf einen oder mehrere Namen festlegen, die alle von der externen PKI akzeptiert werden. Ein "SRVEX01.ad.local" gehört sicher nicht dazu.

Viele Firmen nutzen nun aber Loadbalancer (HLB) oder Web Application Firewalls (WAF), die eingehende Verbindungen von extern per HTTPS terminieren und untersuchen. Dort ist dann schnell ein Zertifikat für "webmail.<firmenname>" gekauft und installiert. Der HLB oder die WAF können dann nach intern die Verbindung wieder "reencrypten" und vertrauen einfach der internen PKI. Und schon können Sie die internen privaten Zertifikate weiter nutzen. Das geht aber mit Exchange Extended Protection und IIS Extended Protection aber nicht mehr, wenn Sie die "Windows Integrated Authentication (WIA)" nutzen. Da muss der Exchange Frontend Server das gleiche Zertifikat haben.

Zertifikate tauschen

Es ist Zeit das Zertifikat auf dem internen Server zu tauschen. Ehe Sie nun aber vorschnell das Zertifikat von ihrem HLB/WAF auf die Exchange Server bringen, sollten Sie noch einmal kontrollieren, welche internen Clients sich bisher per TLS mit ihrem Server verbinden. Sehr oft habe ich es erlebt, dass intern weitere Namen benutzt werden, die aus dem Internet nicht erreichbar sein und auch gar nicht im externen Zertifikat enthalten sind. Wenn Sie in der Konstellation das externe Zertifikat intern auf die Frontend Webseite binden, dann müssen sie zeitgleich auch ihrem HLB/WAF das neue Ziel mitteilen. Aber kritischer kann natürlich die interne Störung sein, wenn Sie per Service Connection Point oder "Interne URLs" auf die privaten Namen verweisen, die dann im gebunden öffentlichen Zertifikat nicht mehr enthalten sind.

Eine pauschale Lösung kann ich hier leider nicht beschreiben. Wenn Sie EP aktivieren müssen und sich an die Microsoft Empfehlungen halten, dann bleibt nur die Wahl, dass der Client das Zertifikate sieht, welches auch die Exchange Client Access-Rolle nutzt.

EP kompatible Versionen

Sicher ist der direkt Durchgriff von Client auf die Exchange Client Access Rolle der einfachste aber auch am wenigsten geschützte Weg. Folgende Optionen sollten funktionieren.

Variante Beschreibung

Exchange mit Public

Ich würde zwar keinen Exchange Server mit einem Beinchen direkt ins Internet stellen, aber es gibt Firmen, die ganze öffentliche Subnetze haben und diese hinter einer Firewall als Router betreiben. Die Firewall kann in dem Fall sehr gute alle Zugriff von Extern mit Ausnahmen von 80/443 blockieren. Die Firewall darf natürlich nicht aufbrechen und sollte auch ein Auge auf die ausgehenden Verbindungen haben.

Exchange hinter NAT

Kleinere Firmen haben oft nur genau ein Teilnetz als Subnetz hinter dem Router des Providers. Meist hat dann die Firewall mehrere IP-Adressen und leitet Pakete per "Reverse NAT" auf interne private Adressen der veröffentlichen Dienste weiter. Einige Firewall erlauben wohl sogar die Umleitung anhand des Server Name Indication (SNI)-Namens im TLS "CLIENT-HELLO", indem Sie den TCP-Handshake selbst aufbauen. Das ist aber dennoch kein Aufbrechen. Mit TLS 1.3 kann es aber schwer werden, solche "IP/Host-Sharing"-Szenarien weiter betreiben.

Dies ist auch die Funktionsweise eines Layer-4 Loadbalancer.

SSL Bridging

Es ist auch weiterhin möglich, die TLS-Verbindung auf einem vorgelagerten System zu terminieren, die Daten zu inspizieren und danach wieder auf dem Weg zur Exchange Client Access-Rolle erneut zu verschlüsselt. Voraussetzung ist dabei natürlich das identische Zertifikat auf beiden Systemen.

SNI-Mapping auf IIS

Wenn der Wechsel des internen Zertifikats nicht einfach möglich ist, dann könnte folgender Trick helfen: Sie können auf dem IIS in den Bindungen über die Funktion Server Name Indication (SNI) auf eine Webseite auch mehrere Zertifikate binden. Der IIS, bzw. genauer der HTTPS.SYS-Unterbau schaut sich dann den vom Client (oder Reverse Proxy) angefragten Server Name Indication (SNI) an und wählt das passende Zertifikat. Wenn ihr Exchange Server aus dem Interne z.B. nur unter "Webmail" und "Autodiscover" erreichbar ist, kann dies ein legitimer Ansatz sein, das öffentlichen Zertifikat auf die beiden Namen zu binden und das bisherige interne Zertifikat als "Default" zu belassen.

Sie sind damit natürlich nicht mehr genau an der Standardkonfiguration und bei jeder Zertifikatsänderung, Verlängerung etc. mit "Enable-ExchangeCertificate" sollten Sie nachschauen, ob die Bindungen noch passen.

Es ist aber ein schneller Weg, wenn Sie als Schutz gegen CVE-2024-21410 die Exchange Extended Protection aktivieren müssen.

Eigene Webseite für extern

Ein letzter Weg wäre ein "Kopieren" der Webseite, d.h. dass Sie auf dem Exchange Server z.B. eine zweite sekundäre IP-Adresse einrichten und darauf eine Kopie der "Default Webseite" anlegen. Genau genommen reichen ja die wenigen Verzeichnisse wie "/MAPI", "/EWS" und "/Microsoft-Server-ActiveSync". Der Zugriff auf /OWA wird ja bei den meisten Firmen schon per "Form based" erfolgen und ist damit hinsichtlich Exchange Extended Protection gesondert zu betrachten.

Auf einer eigenen Webseite können Sie dann natürlich das gleiche Zertifikat wir auf dem HLB/WAF verwenden ohne die bisherig interne Kommunikation zu stören.

Eigener CAS für extern

Eine Exchange Client Access Rolle kann nicht in einer DMZ installiert werden, auch wenn dies immer mal wieder versucht wurde. Da der Server aber Kontakt zum AD benötigt, ist die Firewall der DMZ-Zone dann doch sehr löchrig. Sie können aber durchaus intern eigene Exchange Server aufsetzen, die von keinem internen Client sondern nur von extern angesprochen werden. Hier können Sie dann auch Zertifikat ohne Rücksicht konfigurieren. Allerdings könnte es notwendig sein, diese Server in eine eigene AD-Site zu setzen und die für intern genutzten Server ohne "ExternalURL" zu betreiben, damit ein Site2Site-Proxy stattfindet.

Ob solch ein Aufwand aber gerechtfertigt ist, würde ich bezweifeln.

Ich habe natürlich auch noch andere Möglichkeiten überlegt aber als nicht funktionsfähig verworfen.

  • EF auf Reverse Proxy (AAR)
    Für den IIS gibt es die Funktion IIS ARR (Application Request Routing), damit er als Reverse-Proxy agieren kann. Ich dachte erst daran, auf dem Server dann IIS Extended Protection zu aktivieren und zum Exchange Server nicht mehr. Das scheitert aber daran, dass der AAR keine Authentication unterstützt und selbst wenn er den Client per NTLM mit IIS Extended Protection sicher anmelden würde, hätte nur er dann die NTLM-Anmeldung aber kommt damit ja nicht zum Exchange Server weiter.
    Application Request Routing  https://www.iis.net/downloads/microsoft/application-request-routing
  • SSL Offloading
    Die "Exchange Front End"-Seite prüft, ob eine Verbindung per HTTPS erfolgt ist und verhält sich dann anders. Soe verhindert Exchange z.B. Migrationen über den MRSPROXY ohne TLS-Verbindung. Zudem ist es von Microsoft nicht supportet und funktioniert nicht.
  • PreAuth mit Constraint Delegation
    Natürlich habe ich überlegt, ob vielleicht die Web Application Firewall einfach die Authentifizierung übernimmt und sich dann mit einem Kerberos-Ticket und Constraint Delegaten zum Exchange Server durchschlägt. Dann wäre auch die Anmeldung zwischen Client und Exchange aufgebrochen. Vermutlich geht es aber ich habe es bislang nicht testen können.

Vielleicht gibt es noch andere Optionen, die mir bislang noch nicht eingefallen sind. Dann reiche ich sie gerne nach, wenn Sie mich darauf hinweisen

Ein Vorschlag

Durch die Veröffentlichung von Exchange zum Internet haben Sie sich über die Einstellungen von "External URL" schon auf DNS-Namen festgelegt. Neben dem "Autodiscover"-Eintrag ist der Exchange Server mit einem weiteren Namen veröffentlicht. Sie kennen sicher Namen wie:

    owa.<firmendomain.tld>
webmail.<firmendomain.tld>
outlook.<firmendomain.tld>
   mail.<firmendomain.tld>

Sicher gibt es noch andere Namen, die wir nun auch im internen LAN verwenden sollten. Das bedeutet nun, dass Sie sich Gedanken über die Namensauflösung im internen LAN und vielleicht Split-DNS einsetzen müssen, damit interne Clients beim Zugriff auf den Namen auf die interne Server gelangen und nicht nach außen und wieder drinnen geroutet werden.

In dem Zuge gilt natürlich auch ein Blick auf "die Werte in "InternalURL" und "ExternalURL" der verschiedenen Dienste.

Wenn ich hier nun z.B. "https://EX01.msxfaq.local/EWS/Exchange.asmx" eingetragen habe und ein Zugriff auf den Server das externe Zertifikat ohne diesen Namen verwendet, dann passt der Name nicht und die Verbindung kommt höchstwahrscheinlich nicht zustande.

Das wird vermutlich dem Exchange Administrator zuerst auffallen, wenn er explizit sich mit einem bestimmten Server z.B. über "https://EX01.msxfaq.local/ECP" verbinden will und eine Zertifikatswarnung bekommt.

Da es für die Nutzung von Exchange Extended Protection Pflicht ist, dass ihr extern genutzte Zertifikat genauso auch auf dem internen Exchange Server verwendet wird, müssen Sie Wohl oder Übel das externe Zertifikat auch auf die internen Exchange Server installieren und binden.

Denken Sie dabei daran, dass Sie auch die Zertifikatskette, also eventuell erforderliche "Intermediate"-Zertifikate mit installieren.

Das Zertifikat aktivieren Sie nun mit Enable-ExchangeCertificate für den IIS.

# Liste der Zertifikate ausgeben um den Thumbprint zu finden
# Sie erkennen vermutlich es daran, dass es # Akivieren Sie das Zertifikat für den Webservice.
Enable-ExchangeCertificate `
   -Thumbprint <thumbprint> `
   -Services IIS

Diese Änderung entbindet natürlich nun das bisherige Zertifikat. Ein Zugriff auf einen Server über den FQDN des Servers oder sogar den kurzen NetBIOS-Namen geht nur noch ohne Zertifikatswarnung, wenn der Name im Zertifikat ist.

Tipp: Das alte Zertifikat ist ja weiter da und sie können die SSL-Bindungen der Default Webseite manuell so bearbeiten, dass über den Namen bei Server Name Indication (SNI) für den FQDN des Servers ein anderes Zertifikat gezogen wird.

Lifecycle

Zertifikate gelten nicht "endlos" sondern habe natürlich ein Ablaufdatum und als Betreiber haben Sie dann die Wahl, ob sie das Zertifikat unter Beibehaltung der Privaten/Öffentlichen Schlüssel verlängern oder neue Zertifikate anfordern und auf den Servern installieren. In Verbindung mit Extended Protection ist dies problemlos, wenn Sie das Zertifikat auf einem Server nutzen und keine SSL-Inspection mit Bridging davor betreiben.

Wenn Sie aber mehrere Exchange Server als Cluster betreiben oder einen Layer7-Loadbalancer davor haben, dann müssen Sie die Aktivierung des neuen Zertifikats aufeinander abstimmen, damit der Wechsel quasi gleichzeitig erfolgt.

Weitere Links