Outlook Anmeldemaske nach Exchange Zertifikatstausch
Vor kurzem bin ich auf folgendes Problem gestoßen: das Zertifikat auf einem Linux Loadbalancer, der vor einem Exchange Cluster steht, wurde getauscht. Direkt nach dem Reload der Config ploppte bei allen Outlook Clients die bekannte Windows Anmeldemaske auf. Kein Client war mehr in der Lage, mit dem Exchange zu kommunizieren. Im Browser konnte man allerdings problemlos die Exchange Endpunkte (wie z.b. das OWA) aufrufen und sich auch anmelden. Nur Clients, die via MAPI und EWS angebunden waren, verweigerten ihren Dienst.
Aufbau
Bevor wir allerdings zur eigentlichen Ursache des Problems kommen, schauen wir uns den Aufbau dieser Exchange Umgebung einmal an – denn das ist hierbei entscheidend. Der Exchange Cluster besteht aus mehreren Exchange Server 2019 Backend Nodes. Davor steht ein redundantes Pärchen an Linux Loadbalancer mit Haproxy und SSL Bridging. Jeder Client greift auf die Backend Nodes ausschließlich über die Loadbalancer zu. Am Exchange selbst ist das in 2024 veröffentlichte Sicherheitsfeature Exchange Extended Protection aktiviert.
Ursache
Bei diesem Aufbau sind die Keywords Exchange Extended Protection und SSL Bridging entscheidend. Daher beleuchten wir diese beiden Termini noch einmal.
Beim SSL Offloading terminiert die verschlüsselte SSL Verbindung aus Sicht des Clients am Loadbalancer und wird dort entschlüsselt. Anschließend schickt der Loadbalancer die Daten unverschlüsselt an das Backend (also in unserem Fall den Exchange) weiter.
Beim SSL Bridging hingegen terminiert die SSL Verbindung auch am Loadbalancer, wird dort allerdings erneut verschlüsselt und an das Backend weitergeschickt.
Da wir das Sicherheitsfeature Exchange Extended Protection aktiviert haben und somit besser gegen MitM (Man-in-the-Middle) Attacken geschützt sind, greift allerdings eine besondere Limitierung. Extended Protection funktioniert nämlich nur unter SSL Bridging und auch nur dann, wenn sowohl der Loadbalancer, als auch die Exchange Backend Nodes das gleiche Zertifikat zur Kommunikation verwenden. Sollten wir entweder SSL Offloading oder unterschiedliche Zertifikat verwenden, wird dies bereits als MitM-Attacke erkannt und die Authentifizierung funktioniert nicht mehr.
Fazit
Eine solche Fehlersuche kann sich schon einmal in die Länge ziehen. Vor allem dann, wenn das Management der Loadbalancer und jene der Exchange Nodes in unterschiedlichen Teams stattfindet. Ein Zertifikat ist schnell getauscht und falls die Zusammenhänge zwischen aktivierte Extended Protection und SSL Bridging nicht bekannt sind, gestaltet sich auch das Debugging als kompliziert. Trotzdem ist es empfehlenswert, die Exchange Extended Protection zu aktivieren und die Besonderheit innerhalb des Teams zu kommunizieren.
