Linux-Hybrid mit EXO

Nicht alle Firmen haben lokal einen Exchange Server oder wollen Exchange installieren und Hybrid aufbauen. Gerade Universitäten haben oft eine gewachsene lokale IMAP-Mail-Serverumgebung mit Spamfiltern. Über die Microsoft 365 A1/A3/A5-Pakete können aber auch akademische Einrichtungen die verschiedenen Microsoft 365-Dienste nutzen. Da kommt schnell die Frage nach einer Kopplung mit Exchange Online auf.

Zu dieser Seite gibt es eine ältere Version, die noch andere Aspekte beschreibt Exchange Online mit IMAP4-Hybrid.

"Mild Hybrid"

Ohne lokale Exchange Server gibt es natürlich keinen ´richtigen Hybrid Mode und Microsoft Teams wird wohl nie einen Kalender eines Benutzer auf einem lokalen CalDav, SoGo, Cyrus, OpenExchange, Exim, Kolab, Zafara, Dovecot oder anderen Servers lesen können, da es hier einfach keine kompatible REST-API gibt. Wer also Microsoft (Teams, Planner etc.) ohne Exchange-Postfach betreibt, wird die ein oder andere Einschränkung haben. Wenn dies aber kein Problem ist, dann lässt sich auch eine Umgebung aus Exchange Online und lokalem Mailserver mit SMTP-Domain-Sharing konfigurieren. Dabei gibt es auch hier drei Optionen:

• Exchange Online hinter lokalem Mailserver
  Sie verstecken Exchange hinter ihrem vorhandenen Spamfilter, d.h. alle Mails aus dem Internet an Exchange Online Postfächer gehen über OnPremises zu Exchange Online und umgekehrt sendet Exchange Online alles über ihren lokalen Servern
• Exchange Online neben lokalem Mailserver
  Eingehende Mails gehen über den MX-Record weiter zum lokalen Server und weiter zu Exchange Online aber Exchange Online kann auch selbst versenden. In eine Richtung sparen Sie den Umweg aber müssen dafür natürlich Exchange Online in den SPF-Record eintragen.
• Exchange Online vor lokalem Mailserver
  Speziell wenn Sie mit ihrem Spamfilter unzufrieden sind, können Sie auch den MX-Record zu Exchange Online Protection routen und Exchange Online stellt Mails ins Cloud-Postfach zu und leitet Mails an lokale Postfächer an ihre weiter betriebene Mailserver weiter. Der lokale Mailserver ist nur noch für Exchange Online über Port 25 erreichbar.

Da die meisten Umgebungen mit dieser Aufgabenstellung erst mit Exchange Online "anfangen", beschreibe ich im weiteren den Fall 1 mit Exchange Online "hinter" den lokalen Mailservern. Das hat noch die weiteren "weichen" Aspekte, dass Exchange damit nicht das führende System gibt, nicht alle Empfänger zwingend auch in der Cloud bekannt sein müssten und lokalen Spamfilter nicht entfallen.

Adressbuch und Kontakte

Der zweite Aspekt dieser Anbindung sind die Adressen. Die Postfächer in Exchange Online müssen ja weiterhin lokale irgendwie definiert sein, z.B.

• Adressbuch (LDAP, CardDAV)
  Wer nicht mit Outlook und Exchange sondern z.B. mit Thunderbird arbeitet, möchte trotzdem ein Adressbuch nutzen. Thunderbird und ähnliche Programme unterstützen die Einbindung von LDAP-Verzeichnisdiensten und anderen Quellen. Wenn die Exchange Online Anwender kein lokales Postfach haben, sollten Sie dennoch auffindbar sein
• Mailrouting/Spamfilter
  Aber auch der "Unterbau" muss ja wisse, welche gültigen Empfängeradressen es in Exchange Online gibt, damit er diese Mails annimmt und natürlich auch weiß, wohin diese geroutet werden.

Aber auch in die Gegenrichtung muss es einen Abgleich geben, d.h. lokale Postfächer sollten auch in Exchange Online aus den gleichen zwei Gründen bekannt sein.

• Adressbuch in Exchange Online
  Wenn lokale Postfächer in der Cloud nicht bekannt sind, dann können Exchange Online Benutzer diese nicht im Adressbuch finden. Sie benötigen in Exchange Online daher entsprechende MailUser oder MailContacts. Wenn lokale Benutzer auch ein Benutzerkonto in der Cloud (AzureAD/EntraID) haben, dann können sie aus dem User einen MailUser machen. Wenn der lokale Benutzer überhaupt keine Dienste in der Cloud nutzen soll, dann reicht ein "MailContact"
• Mailrouting
  Natürlich muss auch Exchange

Vergessen Sie bei all den Postfächern aber nicht die sonstigen Elemente wie z.B. Mailverteiler. Sie können diese auf einer Seite als Verteiler mit Mitgliedern pflegen und auf der anderen Seite als Kontakt, bei dem die Benutzer dann keine Mitglieder sehen. ein Abgleich von echten Verteilern samt Mitgliedern kann aber eine Herausforderung sein. Wenn Sie lokal auf Unix mit MailMan einfache Mailinglisten betreiben, dann sind Kontakte eh der einzige Weg. Denken Sie aber auch an Teams-Teams und Office Groups, welche auch eine Mailadresse aus ihrer gemeinsamen Domain bekommen können. Mailadressen müssen zwischen beiden Welten eineindeutig sein. Schon daher sollten Sie sicherstellen, dass alle Mailadressen in allen Systemen komplett vorhanden sind

Für diese Aufgabe müssen Sie sich natürlich überlegen wie die Identitäten in der Cloud generell verwaltet werden. Hier gibt es gleich mehrere Optionen:

• Lokales AD und ADSync
  Wenn Sie eh ein lokales Active Directory für die Benutzer haben, dann wäre ADSync eine Option. Allerdings müssen Sie daran denken, dass solche "DirSync"-User in der Cloud nur eingeschränkt verwaltet werden können. Faktisch brauchen Sie im lokalen AD zumindest die Exchange Schemaerweiterungen und eine Exchange Management Rolle. Siehe auch ADSync mit Exchange Online Only, DirSync mit Exchange u.a.
• Microsoft Graph, Exchange PowerShell o.a.
  Wenn Sie auf ADSync verzichten, dann sind ihre Exchange Online Postfächer aber auch die Verweise auf die lokalen Postfächer nicht gesperrt und können mit eigenen Dirsync-Tools verwaltet werden. Ich habe solche Lösungen schon bei Schulen umgesetzt, die gar kein lokalen AD hatten oder der Aufwand eines ADSync pro Schule mit je eigenem Tenant zu hoch war.
• School Data Sync
  Für Academic-Tenants gibt es mit School Data Sync (SDS) sogar eine eigene Schnittstellen, CloudOnly-Personen, d.h. Schüler und Lehrer automatisiert zu provisionieren. Wobei hier ein Exchange Online Postfach quasi dazu gehört. Aber es kann eine Basis für individuelle Anpassungen sein.

Mailrouting

Mit den Adressbüchern ist es aber nicht getan. Sie müssen die beiden Welten miteinander verbinden, da Sie ja die gleichen SMTP-Domain nutzen sollen. Sowohl der lokale Server als auch Exchange Online senden mit der SMTP-Domain ins Internet aber auch zu dem jeweils anderen System. Die Kommunikation zwischen beiden Welten sollte auf jeden Fall verschlüsselt, authentifiziert und mit passenden Filterregeln versehen werden. Jeder gut gepflegte Spamfilter blockiert Mails von extern wenn diese vorgeben von intern zu kommen. Genau das ist aber der Fall, wenn Exchange Online und das lokale System miteinander kommunizieren.

Wenn eine fremde Mail aus dem Internet beim lokalen Server für ein Exchange Online Postfach ankommt, dann muss er diese ja umleiten. Dazu braucht er aber normalweise eine gesonderte Domäne um Loops zu verhindern. Das ist ein Grund, warum in Exchange Online jedes Postfach auch immer eine <userpart>@<tenantname>.mail.onmicrosoft.com-Adresse bekommt über die eine Mail zuverlässig zugestellt werden kann.

Der lokale Server "kann" Mails an diese Domain natürlich per MX-Record an Exchange senden, aber wenn er sich dann bei einer Umleitung als Domäne des ursprünglichen Absenders ausgibt, für dessen Domain es einen "SPF =-all"-Eintrag gibt, dann wird Exchange die Mail ablehnen. Hier müssen Sie Exchange Online helfen, die Mail von ihrem lokalen System zu erkennen. Auch in die Gegenrichtung müssen Sie Exchange Online natürlich einen Weg zum lokalen Server weisen und der lokale Server muss Exchange Online "erkennen". Damit kommen wir zu fünf Kommunikationsbeziehungen und deren Lösung.

Nach der Einrichtung sollten sie natürlich all diese Kombinationen mit Postfächern ausführlich testen. Nutzen Sie als Absender besser DNS-Domains, die mit SPF, DKIM, DMARC abgesichert sind, so dass Sie Validierungsfehler umgehend finden.

• Linux Exchange Hybrid

Migration, Doppelpostfach und Weiterleitungen

Der Neuaufbau und Betrieb ist nur ein Teil der Lösung. Es wird früher oder später die Frage kommen, wie Postfächer von der einen Seite zur anderen Seite migriert werden können. Und tatsächlich gibt es hier wieder mehrere Möglichkeiten. Für eine gewisse Zeitspanne muss es für den Benutzer ja ein Postfach auf beiden Seiten geben, damit die Inhalt z.B.: per IMAP migriert werden können. Wir wissen alle, dass IMAP viel aber nicht alles kann Mails kommen meist noch relativ problemlos über die Leitung aber Termine und Kontakte sind individuell zu prüfen.

Die Benutzer kommt von einem lokalen Postfach und kann zukünftig z.B. Outlook nutzen oder er geht von einem Exchange Postfach mit Outlook zu einem lokalen Postfach. Mit Thunderbird oder anderen Programmen geht es aber genauso gut. Für die Funktion ist nur wichtig, dass auch mit zwei Postfächern immer nur genau ein Postfach "führend" ist, d.h. der Anwender sollte ein primäres Postfach haben, in dem er seine Mails liest und schreibt. Dann ist es relativ ungefährlich im anderen System auch ein Postfach einzurichten. Dort kommen dann natürlich Mails der Kollegen im gleichen System ab und sollten über eine Umleitung an das primäre Postfach reroutet werden: Das kann der Administrator oder der Benutzer selbst einrichten. Von einem lokalen Postfach kann die Umleitung an die Adresse "<user>@<tenant>.mail.onmicrosoft.com" gerichtet werden. Mit dem passenden Connector vom lokalen System zu Exchange Online erreichen die Mails dann die Cloud. Umgekehrt nutzen die meisten Firmen einfach die primäre Adresse, denn eine Umleitung aus Exchange Online wird anhand der Outbound-Connectoren geroutet,

Mit den beiden Postfächern können Sie dann das Mittel ihrer Wahl nutzen, um die Inhalte in das neue Zielpostfach zu übertragen. Sei es durch z.B. Outlook oder Thunderbird auf dem Client, bei dem ein Anwender einfach die relevanten Mails per Drag&Drop umziehen oder mit verschiedenen Tools von kommerziellen oder kostenfreien Drittherstellern. Auch Exchange Online kennt eine IMAP-Migration, die aber nur den Umzug von einem fremden IMAP4-Server zu Exchange Online unterstützt aber nicht mehr den Weg zurück

• IMAP4 Migration zu Exchange
• IMAP4 mit Office 365

Zusammenfassung

Ich habe hier keine bebilderte Schritt für Schritt-Anleitung beschrieben aber anhand der Erklärung der Zusammenhänge sollten ein halbwegs versierter Mail-Admin die Konfiguration zum Mailrouting und Migrationen problemlos umsetzen können. Der knifflige Teil ist, wie so oft, der Verzeichnisabgleich. Ohne ADSync müssen Sie irgendwie die Empfänger des lokalen Systems in Exchange Online verwalten und die Exchange Online Empfänger zumindest im lokalen SMTP-Routing bereitstellen. Wenn Sie ADSync mit einem lokalen Active Directory nutzen, müssen Sie dieses zumindest auch mit dem Exchange Schema und einer Exchange Management Rolle ausstatten, damit Sie über das lokale AD die Exchange Online Empfänger verwalten können.

Das ist alles möglich aber es fängt in der Regel mit einem Bild auf einem Whiteboard, Flipchart oder beim Online-Meeting mit z.B. Visio an, um die Bausteine zusammenzufügen.

Bei Bedarf können Sie gerne meine Kollegen bei Net at Work oder mich ansprechen. 

Weitere Links

• IMAP4 mit Office 365
• Linux Exchange Hybrid
• Exchange Online mit IMAP4-Hybrid
• Exchange Online Connector Routing
• Exchange Intern/Extern
• Partner Connector
• Office 365 Inbound Mailrouting
• Partner Inbound Connector
• X-OriginatorOrg
• Centralized Mail Transport
• ADSync mit Exchange Online Only
• DirSync mit Exchange
• DL Management mit EXO
• Centralized Mail Transport
• Hybrid Hintereingang