Wer zwei Exchange-Server betreibt, braucht etwas davor, das die Zugriffe verteilt. Clients sollen eine einzige Adresse kennen, nicht zwei Server. Und fällt ein Server aus, soll niemand das merken. Diese Aufgabe übernimmt in meiner Demo ein Load Balancer von Kemp in der kostenlosen Variante.
Spannend ist weniger, dass es ihn gibt, sondern wie er arbeitet. Zwei Entscheidungen haben die ganze Architektur geprägt.
Entscheidung 1: Die Verschlüsselung bleibt zu
Viele Load Balancer entschlüsseln den Datenverkehr, schauen hinein und verschlüsseln ihn dann neu. Das nennt man SSL-Offloading, und es erlaubt clevere Dinge, etwa eine Prüfung jedes einzelnen Exchange-Dienstes.
Bei Exchange SE geht das so nicht mehr. Der Schutzmechanismus Extended Protection, den ich in Teil 3 erwähnt habe, bindet die Anmeldung an die verschlüsselte Verbindung zwischen Client und Server. Bricht ein Gerät dazwischen diese Verbindung auf und verschlüsselt sie mit einem eigenen Zertifikat neu, scheitert die Anmeldung. Microsoft hat das so gewollt: Es ist genau der Trick, mit dem Angreifer Anmeldungen abfangen und weiterreichen.
Neu verschlüsseln mit genau demselben Zertifikat wäre erlaubt, lässt sich bei meinem Load Balancer aber nicht mit dem transparenten Modus kombinieren, um den es gleich geht. Er reicht die verschlüsselte Verbindung deshalb unverändert durch. Er braucht kein Zertifikat und sieht keine Inhalte. Der Preis: Er kann nicht prüfen, ob Outlook im Web oder die mobile Synchronisation einzeln funktionieren. Er prüft jeden Server als Ganzes über eine Statusseite, die Exchange dafür bereitstellt.
Entscheidung 2: Exchange sieht die echte Adresse
Die zweite Entscheidung betrifft eine Frage, die in jedem Sicherheitsvorfall wichtig wird: Von wo hat sich jemand angemeldet? Ein Load Balancer ersetzt normalerweise die Absenderadresse durch seine eigene. Dann steht in den Protokollen von Exchange bei jedem Zugriff dieselbe Adresse, und die Spur endet am Load Balancer.
Ich betreibe ihn deshalb im transparenten Modus. Exchange sieht die tatsächliche Adresse des Anwenders, in den Webprotokollen genauso wie in der Nachrichtenverfolgung. In der Demo zeige ich das gern: einmal anmelden, Protokoll öffnen, da steht die Adresse des Clients, nicht die des Load Balancers.
Auch das hat einen Preis. Die Antworten der Exchange-Server müssen wieder über den Load Balancer zurück. Er ist deshalb ihr Standard-Gateway, und Clients dürfen nicht im selben Netz wie die Server liegen. Das war einer der Gründe für die getrennten Netze aus Teil 2. Verkehr zu den Domain Controllern und den Mailgateways läuft über eigene Wege am Load Balancer vorbei.
Mehr als nur Webzugriff
Über dieselbe Adresse laufen auch die klassischen Mailprotokolle für Abruf und Versand. Auch dort bleibt die Verschlüsselung bis zum Exchange-Server bestehen.
Was das für echte Projekte heißt
Die kostenlose Lizenz ist für die Demo ideal, für den Betrieb aber nicht gedacht: begrenzter Durchsatz, kein ausfallsicheres Paar, keine Firmware-Updates. Wichtiger ist die allgemeine Lehre: Vor dem Kauf eines Load Balancers für Exchange sollte geklärt sein, ob er Extended Protection und die gewünschte Transparenz zusammen unterstützt. Eine Sicherheitsfunktion entscheidet hier über die Architektur, nicht umgekehrt.
Im nächsten Teil geht es um den zweiten Eingang: wie Mails von außen in die Umgebung kommen.