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.

Wer Exchange OnPremises betreibt und nicht in einer Nacht die komplette Migration durchziehen kann, wird immer bei einer der verschiedenen Hybrid-Optionen landen.

Exchange Online kennt dazu drei Varianten:

  • Minimum Hybrid
    Primär für kleine Firmen mit kurzer Koexistenz-Zeit, die schnell alle Daten in die Cloud migrieren wollen und während der kurzen Zeit auf Free/Busy, Mailtipps etc verzichten. Dies ist für Kunden nicht möglich
  • "Classic Hybrid"
    Dis war lange Zeit der einzige „Full Hybrid“-Mode, der eine sehr gute Koexistenz und Migrationsplattform bereitgestellt hat. Allerdings ist das Setup für mittlere und kleine Firmen aufwändig
  • Modern Hybrid
    Bei dieser jungen Variante betreibt Microsoft einen Proxy in der Cloud, der in Verbindung mit einem lokal zu installierenden Agenten die EWS-Anfragen zum OnPremises Server tunnelt und damit keine EWS-Veröffentlichung für diesen Fall erforderlich ist. Der Weg wäre denkbar aber die EWS-Veröffentlichung ist bei Kunden für andere Dienste sowieso Voraussetzung.

Alle drei Varianten haben ihren Einsatzweck und ich betrachte die Voraussetzungen für "Classic-Hybrid" und nutze meine "uclabor.de" als Beispieldomäne. Das ist die "umfangreichste" und die beiden anderen Varianten sparen sich ein paar Einstellungen bei Verlust der entsprechenden Funktion.

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 Anruferidentifizierung
    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.

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. Daher besser am Anfang und die Vorteile von Beginn an mitnehmen.

SMTP-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 OnPremises 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.

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
  • 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.

Microsoft Federation Gateway

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.

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.

MRS Migration

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