Exchange Hybrid Starter

Was bedeutet Hybrid für eine Firma mit lokalem Exchange Deployment? Für die Koexistenz und Migration von Exchange Postfächern in Office 365 mit lokalen Exchange Servern ist die Einrichtung des Exchange Hybrid Mode erforderlich. Und immer wieder kommen in Vorgesprächen die Rückfragen, ob man denn das wirklich braucht. Es ist ja so viel zu konfigurieren und erscheint kompliziert. Zudem muss man verschiedene Dienste erreichen können und eigene Dienste erreichbar machen.

Allgemein

Der Exchange Hybrid-Mode ist die einzige Option, um eine Exchange Online -Instanz mit einer lokalen Exchange 2010-2019-Installation derart zu koppeln, dass eine Koexistenz und Migration möglich ist. der Hybrid-Mode ist nicht mit Exchange 2007/2003 oder anderen Mailsystemen nutzbar. Der Hybrid Mode besteht aus mehrere Komponenten:

  • Verzeichnisabgleich per ADSync
    Dies ist für jeden Hybrid-Mode Basisvoraussetzung
  • Erreichbarkeit der beiden Welten per SMTP und HTTP
    Optional mithilfe eines Agenten
  • Konfigurationen auf beiden Seiten
    Damit Sie sich "kennen" und vertrauen

Allerdings gibt es mittlerweile vier verschiedene Ausprägungen, so dass für Firmen die Bandbreite von einer schnellen Migration über ein Wochenende bis zu einer lange enge Koexistenz möglich sind. Wenn Sie das erste mal dem HCW aufrufen und sich angemeldet haben, kommen irgendwann einige Dialoge, die erklärt werden müssen. Microsoft unterscheidet zwei unterschiedliche "Features" und zwei "Topologien", zu denen ich auf der Seite HCW Feature&Topologie weiter eingehe.

Hier geht es erst einmal darum, die allgemeinen Aspekte einer Koexistenz von Exchange On-Premises und Exchange Online zu verstehen.

ADSync/Adressbuch/GAL

Es gilt die Grundregel “ Meine Adressen sind deine Adressen”. Für die reibungslose Funktion ist eine vollständige Synchronisation der On-Premises Exchange Empfänger in die Cloud mittels ADSync erforderlich. Es müssen also nicht nur ein paar Pilot-Benutzer mit ADSync eingebunden sein, sondern alle, was unter „Get-Recipient“ aufgeführt wird (Postfächer, Öffentliche Ordner, Verteiler, Räume, Shared Mailboxen etc.“ müssen auch in der Cloud vorliegen. Die Objekte müssen zudem eine primäre SMTP-Adresse haben, die im eigenen Tenant verifiziert ist. Ich weiß, dass diese Voraussetzung bei Firmen kritisch gesehen wird, vor allem wenn es um einen Piloten geht und Stammdaten noch nicht bereinigt sind und Datenschutz/Mitbestimmung noch nicht geklärt sind. Wenn dieses Voraussetzung aber nicht erfüllt sind, dann kann folgendes passieren.

  • Unvollständiges Adressbuch
    Anwender mit Postfach in Exchange Online nutzen das globale Adressbuch in der Cloud. Wenn hier Anwender nach jemandem Suchen, werden sie vielleicht nicht fündig. Das führt zu Verdruss und Tickets im Helpdesk
  • Unstimmige Verteilermitglieder bekommen keine Mails
    Mails an Verteiler werden schon von Exchange Online aufgefächert. Lokale Empfänger, die nicht in Office 365 vorhanden sind, sind auch nicht Mitglied in dem Verteiler-Replikat in der Cloud. Eine Mail aus der Cloud an den Verteiler wird nur an die dort enthaltenen Empfänger aufgeteilt. Fehlende On-Premises Empfänger bekommen diese Mails daher nicht.
  • Unvollständige People Picker
    Die Informationen aus der Exchange Online GAL werden auch von anderen Online Diensten genutzt, z.B. Skype, SharePoint, Groups etc. Wenn dort Personen fehlen, dann können diese auch nicht adressiert werden
  • Skype/Teams Anrufer-Identifizierung
    Die VoIP-Lösungen nutzen ebenfalls das AzureAD um z.B. Personen auf Rufnummern aufzulösen oder Rufnummern auf Namen zu mappen. Es bietet sich schon an hier zumindest die Firmenmitarbeiter auch mit den erforderlichen Stammdaten zu synchronisieren.
  • Fehlerhafte Provisionierung
    Wenn Sie mit ADSync nur Benutzer übertragen aber die Exchange Properties auslassen, dann führt das ggfls. zu Doppelostfächern. Siehe auch Doppelpostfach mit Exchange Online

All diese Probleme und die damit verbundenen Kosten können vermieden werden, wenn die GAL komplett synchron ist. Und die Arbeit muss früher oder später dann noch erfolgen.

Aus meiner Sicht sollten sie gleich am Anfang klären, dass die Identitäten komplett synchronisiert sind und die Vorteile von Beginn an mitzunehmen.

Mail-Routing

Exchange Online und Exchange On-Premises müssen für die Anwender wie „ein System“ aussehen. Der Mailfluss muss zwischen beiden Welten sicher, verschlüsselt und zügig erfolgen. Ohne entsprechende Konfiguration ist ein Mailfluss durchaus möglich, da On-Premises Sender über die Weiterleitungsadresse „@<tenantname>.mail.onmicrosoft.com“ auch Objekte in der Cloud erreichen können. Allerdings gehen diese Mails dann durch die normale SMTP-Kette samt Disclaimer, Archiv, Spamfilter, Queues über das Internet zu Exchange Online, wo ebenfalls Spamfilter Mails blockieren können. Zudem sind die Mails als „Extern" zu erkennen obwohl sie doch eigentlich intern sind. Aber ein strenger SPF-Eintrag für ihre Domäne verhindert diesen Weg zuverlässig.

In die Gegenrichtung kann auch jeder Office 365 Dienst und Anwender natürlich eine Mail an „@uclabor.de“ senden, da Exchange Online nicht vorhandene Empfänger als extern ansieht und die Mails über das Internet an den MX-Record der Domain sendet. Auch diese Mails müssen durch NoSpamProxy und andere Filter durch und werden dort als „Spoofing“ blockiert, wenn der Absender eine interne Domain, z.B. „@uclabor.de“ sendet.

Daher ist es wichtig eine direkte und gesicherte Verbindung zwischen der lokalen Exchange Installation und dem Tenant aufzubauen. Über entsprechende lokale „Sende-Connectoren“ wird die lokale Exchange Umgebung angewiesen die Mails an „<tenantname>.mail.onmicrosoft.com“ vorbei an den Filtern direkt zu den Exchange Online Servern zu senden. Exchange Online bekommt einen „Inbound Connector“, der diese Mails vom der eigenen Firma als „intern“ ansieht und zustellt. Umgekehrt sendet Exchange Online über einen „Outbound Connector“ alle Mails an die Firmen-Domains nicht über den MX-Record, sondern an eine bereitgestellte IP-Adresse an die lokale Exchange Umgebung.

  • Öffentliche IP-Adresse mit Namen und Zertifikat für Port 25
    In Exchange Online wird dieser Name als „Next Hop“ konfiguriert. Die Verbindung wird per Default per MTLS verschlüsselt, so dass ein passendes Zertifikat vorliegen muss.
  • Eingang schützen
    Auf der Empfängerseite muss dieser Eingang per Port 25 natürlich limitiert werden, damit keine Malware oder Portscanner hier einen Weg zu den eigenen Exchange Servern finden. Der einfachste Weg ist die Beschränkung der Verbindungen über eine Firewall auf die „Source IP-Range“ von Office 365. Alternativ kann der MTLS-Handshake genutzt werden, da auch Microsoft ein Zertifikat vorweist.
    Auch eine Konfiguration der Windows Firewall selbst als Schutz-Level ist denkbar, aber widerspricht meist dem geforderten 4- Augen –Prinzip von Systemen mit öffentlicher IP-Adresse. Dieser Zugang muss von niemandem außer Exchange Online erreicht werden. Optional können über Transport-Regeln auch Felder im Header geprüft werden, damit fremde Tenants nicht den Hintereingang nutzen.
  • Ausgang gewähren
    Auch der eigene Server sendet Mails direkt an Office 365 und dazu müssen die Exchange Server natürlich die Office 365 Services per 25 erreichen können.
  • Kein Fremdproxy/Relay
    Da Exchange für diesen Kanal eigene SMTP-Verben und MTLS nutzt, ist ein 3rd-Party Relay nicht möglich. Die einzige erlaubte Zwischenstation zwischen internen Exchange Servern und Exchange Online sind Exchange Edge-Server. Die sind aber eher selten im Einsatz.

Sie müssen aber gar keine direkte Verbindung einrichten. Natürlich kann ihr lokaler Exchange Server auch Mails über die Domain "@tenantname.mail.onmicrosoft.com" quasi "ins Internet" zu Microsoft senden und alle Absender in der Cloud senden ihre Mails über den MX-Record zu ihrem lokalen Systeme. Dann müssen Sie aber ihrem Spamfilter beibringen, warum so viele Mails von Microsoft mit ihrer eigenen Absender-Domain kommen. Normalerweise ist das bei "Phishing" der Fall.

Details zu den Unterschieden finden Sie auf HCW Feature&Topologie

Internet/Zugriff

Der lokale Exchange Server muss bestimmte URLs im Internet erreichen und ansprechen können. Er muss also „surfen“ dürfen. Folgende Ziele sind hier besonders im hybrid Mode zu beachten:

  • CRL
    Da alle Verbindungen per TLS abgesichert werden, muss der Exchange Server die entsprechenden CRL der ausstellenden PKIs erreichen können. Dieser Abruf erfolgt in der Regel unterschlüsselt über HTTP (TCP Port 80!)
  • MFG
    Das Microsoft Federation Gateway stellt die entsprechenden Tokens für die Authentifizierung zwischen den Servern aus. Der lokale Exchange Server muss diesen Web Services erreichen können
  • EWS
    Für die Abfrage von „Frei/Belegt-Zeiten“ von Objekten in der Cloud oder Mailtipps u.a. muss der lokale Exchange Server die Exchange Web Services (EWS) in der Cloud erreichen können.

All diese Ziele sind „bekannte URL“ und können anonym erreicht werden. Exchange Server können angewiesen werden, einen http-Proxy zu nutzen, an dem Sie sich auch als „Computer“ authentifizieren. Letztlich ist es nur wichtig, dass die Erreichbarkeit gewährleistet ist.

Bei der "Modern"-Variante hilft ihnen Microsoft mit einem lokalen Agenten, der eine ausgehende Verbindung zu Azure aufbaut und damit den Zugriff für Exchange Online ermöglicht. Leider sind damit nicht alle Funktionen möglich.

Details zu den Unterschieden finden Sie auf HCW Feature&Topologie

Microsoft Federation Gateway

Diese Komponente war bis Exchange 2010 erforderlich. Exchange 2013 und neuer nutzen OAUTH und Trusted Applications

Der lokale Exchange Server muss eine Verbindung zum Microsoft Federation Gateway nutzen, um Zugriffstokens zur Authentifizierung zu erhalten. Dazu muss der Server Internet-Zugriff haben. Zudem müssen aber alle Domains im Federation Gateway hinterlegt und verifiziert werden. Dazu ist je Domain ein TXT-Record im öffentlichen DNS erforderlich. Die Konfiguration des MFG selbst führt der Hybrid Configuration Wizard alleine aus. Die DNS-Einträge sind manuell zu addieren.

Über diese Partnerschaft kann aber quasi Jeder im Internet sich ein „Token“ auch für den Zugriff auf die Exchange Server von Kunden besorgen. Erst Exchange entscheidet dann aber anhand von konfigurierten Vertrauensbeziehungen, ob die Anfrage auch beantwortet wird oder nicht. Ein unerlaubter Zugriff ist bei passender Konfiguration damit nicht möglich aber es bleibt ein Restrisiko einer DoS-Attacke, wie bei jeder veröffentlichten Anwendung.

Autodiscover/Free/Busy/EWS

Damit Benutzer der einen Seite weitergehende Informationen zu Benutzern der jeweils anderen Plattform erhalten können, z.B. Frei/Belegt-Zeiten, MailTipps etc., ist eine Kopplung per EWS erforderlich. Dazu muss Office 365 die lokalen EWS-Dienste auflösen (Stichwort Autodiscover) und erreichen (HTTPS ohne PreAuth) erreichen können. Umgekehrt muss auch der lokale Server die Office 365 Server erreichen können.

Eine Beschränkung auf „Source-IP“ wäre hinsichtlich Office 365 als Client denkbar aber EWS wird auch von Skype for Business Clients etc. genutzt, so dass der EWS-Zugang für das Internet offen ist.

Migration MRSProxy

Die Verlagerung von Daten (Postfachmigration) wird aktiv von Office 365 gesteuert. Der Mailbox Replication Server in der Cloud ist dafür zuständig, Inhalte von Postfächer in die Cloud zu übertragen (Pull) aber auch bei Rückmigrationen nach On-Premises die Daten wieder auf lokale Server zurück zu schreiben. Auf der lokalen Umgebung ist dazu der MRS-Proxy als Endpunkt bereit zu stellen.

Technisch ist der MRSPROXY einfach ein Teil von EWS und damit schon veröffentlicht. Als Besonderheit ist dabei zu beachten, dass SSL-Offloading nicht möglich ist, d.h. der MRSProxy arbeitet nur, wenn er per HTTPS angesprochen wird.

Weitere Links