Der hybride Nachrichtenfluss zwischen einer lokalen Exchange Organisation und Exchange Online ist eine Geschichte voller Missverständnisse.
Dieser Artikel befasst sich mit der Aufhebung des hybriden zentralisierten Nachrichtenflusses und der Anforderung, alle an externe Empfängeradressen adressierte E-Mail-Nachrichten von On-Premises Absendern über Exchange Online zu routen. Diese Umstellung erfolgt am einfachsten mit Hilfe des Hybrid Configuration Wizards (HCW).
Voraussetzungen Hybrider Nachrichtenfluss
Bevor wir uns die Konfiguration der Konnektoren bei aktiviertem zentralisierten Nachrichtenfluss und welche Einstellungen die neuen Konnektoren nach Aufhebung desselben haben, werfen wir einen Blick auf die generellen technischen Anforderungen für den sicheren Nachrichtenfluss zwischen beiden Exchange Organisationen.
Es gibt wenige Grundvoraussetzungen für den Betrieb des hybriden Nachrichtenfluss zwischen einer On-Premises Exchange Organisation und dem eigenen Exchange Online Mandanten.
- Die hybride SMTP-Verbindung erfordert eine direkte SMTP-Verbindung zwischen Exchange Server und Exchange Online
- Es dürfen keine anderen E-Mail-Systeme zwischen Exchange Server und Exchange Online betrieben werden
- Es dürfen keine Netzwerkkomponenten zwischen Exchange Server und Exchange Online betrieben werden, die TLS-Verbindungen manipulieren
- Die On-Premises Exchange Server müssen die CRL-Endpunkte für Microsoft-Zertifikate und des eigenen offiziellen Transportzertifikates erreichen können
Der Grund für diese Voraussetzungen liegt darin, dass die SMTP-Verbindung zwischen beiden Exchange-Welten mit Hilfe der TLS-Authentifizierungsfunktion DomainValidation abgesichert wird. Hierbei finden folgende Aktionen statt:
- Der On-Premises Sendekonnektor nutzt das im Parameter TlsCertificateName konfigurierte Zertifikat für die TLS-Authentifizierung gegenüber dem eingehenden Konnektor in Exchange Online
- Das Zertifikat ist nicht mit einem eindeutigen Fingerabdruck referenziert, sondern in einer Namesnotation, bestehtend aus dem Namen der austellenden Zertifizierungsstelle (Issuer) und dem allgemeinen Namen des Zertifikates (Common Name).
- Exchange Server sucht im lokalen Zertifikatsspeicher nach einem Zertifikat mit dem passendem Namen, dem passenden Aussteller und einer gültigen Laufzeit.
Dies kann zu Problemen führen, wenn mehr als passendes Zertifikat, z.B. während einer Zertifikaterneuerung, im Zertifikatsspeicher gefunden wird.
- Der On-Premises Sendekonnektor erwartet, dass der eingehende Konnektor in Exchange Online ein Zertifikat mit dem im Parameter TlsDomain konfigurierten Common Name (CN) präsentiert
- Der eingehende Konnektor in Exchange Online erwartet, dass die sich die eingehende TLS-Verbindung mit einem Zertifikat authentifiziert, das den im Parameter TlsDomain allgemeinen Namen hat.
- Der On-Premises Sendekonnektor und der eingehende Konnektor in Exchange Online in überprüfen jeweils die beteiligten Zertifikate für den Aufbau der TLS-Verbindung und die TLS-Authentifizierung auf
- Vollständigkeit der Zertifikatskette
- Prüfung der Zertifikatrückzugslisten (CRL)
- Prüfung der Domänenübereinstimmungen (s.o.)
Gleiches gilt für die Gegenrichtung in der Kommunikation des ausgehenden Konnektors von Exchange Online zum On-Premises Empfangskonnektor.
Sollte die DomainValidation-Prüfung, insbesondere von On-Premises zu Exchange Online, am eingehenden Konnektor fehlschlagen, wird die Verbindung nicht abgewiesen. Stattdessen wird die über die Verbindung übertragene Nachricht nicht als “aus einer vertrauensvollen Organisation” gewertet, sondern als “anonyme” Zustellung aus dem Internet. Dies hat wiederum direkte Auswirkungen auf die nachgelagerten Prüfungen durch Defender für Microsoft 365.
Aber kommen wir zur Umstellung des Nachrichtenfluss.
Hinweis
In diesem Artikel werden nur die wichtigsten bzw. die relevanten Attribute der Exchange-Konnektoren dargestellt.
Die Ausgangslage
Die hier dargestellte Umgebung nutzt ein externes Cloud-Gateway für die Filterung von E-Mail-Nachrichten. Der DNS MX-Eintrag der eigenen Empfängerdomänen zeigt somit auf die Gateway-Lösung. Eingehende Nachrichten werden nach der Filterung mit einer Smarthost-Konfiguration an die lokalen Exchange Server geroutet.
Die lokale Exchange Organisation und Exchange Online befinden sich einer klassischen Vollhybrid-Stellung mit zentralisiertem Nachrichtenfluss. Alle aus dem Internet empfangenen E-Mail-Nachrichten werden über die Hybridstrecke, in diesem Beispiel mit konfigurierten Edge Transport Servern, zu Empfängeradressen in Exchange Online geroutet.
Ausgehende Nachrichten von Absendern in Exchange Online werden zur lokalen Exchange Organisation zugestellt und, für externe Adressen, an die Gateway-Lösung für weitere Zustellung geroutet.
Werfen wir einen Blick auf die für den zentralisierten Nachrichtenfluss konfigurierten Konnektoren in Exchange Online.
Konnektoren des Hybrid Configuration Wizard
Eingehender Konnektor von On-Premises zu Exchange Online
Der eingehende Konnektor für den zentralisierten Nachrichtenfluss hat folgenden Eigenschaften:
Name : Inbound from GUID
ConnectorType : OnPremises
ConnectorSource : HybridWizard
SenderDomains : {smtp:*;1}
RequireTls : True
RestrictDomainsToIPAddresses : False
RestrictDomainsToCertificate : True
CloudServicesMailEnabled : True
TlsCertificateName : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=smtpo.varunagroup.deDer Konnektor nimmt E-Mail-Nachrichten beliebiger Absenderdomänen (SenderDomains = *) an, insofern sie über einen TLS-abgesicherte Verbindung (RequireTls = True) zugestellt werden, die sich mit dem konfigurierten TLS-Zertifikat (TlsCertificateName = smtpo.varunagroup.de und RestrictDomainsToCertificate = True) authentifiziert hat.
Ausgehender Konnektor von Exchange Online zu On-Premises
Der ausgehende Konnektor für das Routing von E-Mail-Nachrichten aus Exchange Online zur On-Premises Exchange Organisation sieht wie folgt aus:
Identity : Outbound to GUID
UseMXRecord : False
Comment :
ConnectorType : OnPremises
ConnectorSource : HybridWizard
RecipientDomains : {*}
SmartHosts : {smtpo.varunagroup.de}
TlsDomain : smtpo.varunagroup.de
TlsSettings : DomainValidation
IsTransportRuleScoped : False
RouteAllMessagesViaOnPremises : True
CloudServicesMailEnabled : True
Alle E-Mail-Nachrichten (RecipientDomains = * und RouteAllMessagesViaOnPremises = true) werden an einen Smarthost (SmartHosts = smpto.varunagroup.de) zugestellt, insofern der Smarthost das passende TLS-Zertifikat (TlsDomain = smtpo.varunagroup.de) verwendet und die TLS-Prüfung (TlsSettings = DomainValidation) erfolgreich ist. Die ausgehenden Nachrichten werden an den Standard Empfangskonnektor gesendet, dessen Konfiguration vom Hybrid Configuration Wizard für diesen Zweck angepasst wird.
Wie ändert sich die Konfiguration, wenn der zentralisiserte Nachrichtenfluss durch den Hybrid Confguration Wizard umgestellt wird?
Umstellung zentralisierter Nachrichtenfluss
Mit der Deaktivierung des zentralisierten Nachrichtenflusess im Hybrid Configuration Wizard ändert sich das E-Mail-Routing des On-Premises Sendekonnektors und des ausgehenden Konnektors in Exchange Online. Nach der Aktualisierung (Löschung und Neuerstellung) sehen die Konnektoren wie folgt aus:
Sendekonnektor von On-Premises zu Exchange Online für unternehmensinterne E-Mail-Nachrichten
Der On-Premises Sendekonnektor für den organisationsinternen hybriden Nachrichtenfluss zu Exchange Online hat keine große Änderung erfahren.
Identity : Outbound to Office 365 - GUID
AddressSpaces : {SMTP:varunagroup.mail.onmicrosoft.com;1}
CloudServicesMailEnabled : True
DNSRoutingEnabled : True
Fqdn : smtpo.varunagroup.de
RequireTLS : True
SourceTransportServers : {EDGE01}
TlsAuthLevel : DomainValidation
TlsCertificateName : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=smtpo.varunagroup.de
TlsDomain : mail.protection.outlook.comDer Sendekonnektor ist weiterhin für die Zustellung von Nachrichten für Empfängeradressen des Hybridadressraumes TENANTNAME.mail.onmicrosoft.com, in diesem Beispiel varunagroup.mail.onmicrosoft.com, zuständig. Die Absicherung der TLS-Verbindung erfolgt mit Hilfe der DomainValidation, also der umfassenden Prüfung der verwendeten TLS-Zertifikate.
Ausgehender Konnektor von Exchange Online zu On-Premises
Beim ausgehenden Konnektor von Exchange Online zum lokalen Transportserver sieht es schon anders aus. Dieser nutzt nun eine andere Konfiguration.
Identity : Outbound to GUID
UseMXRecord : False
Comment :
ConnectorType : OnPremises
ConnectorSource : HybridWizard
RecipientDomains : {varunagroup.de}
SmartHosts : {smtpo.varunagroup.de}
TlsDomain : smtpo.varunagroup.de
TlsSettings : DomainValidation
IsTransportRuleScoped : False
RouteAllMessagesViaOnPremises : False
CloudServicesMailEnabled : True
AllAcceptedDomains : False
SenderRewritingEnabled : False
Es werden nur noch Nachrichten für die Empfängerdomäne der lokalen Postfächer, in diesem Beispiel varunagroup.de, zur On-Premises Exchange Organisation gesendet. Wenn die lokalen Exchange Organisation mehr akzeptierte Domänen enthält, sollten diese hier aufgeführt sein. Der HCW fügt nur die Domänen hinzu, die für einen Hybridbetrieb ausgewählt sind. Ebenso ist der Parameter RouteAllMessagesViaOnPremises nun auf False konfiguriert.
Auch dieser Konnektor nutzt weiterhin die Funktion DomainValidation, um die TLS-Verbindung abzusichern.
Was fehlt
Aber was fehlt nun, wenn wir alle Nachrichten für externe Empfängeradressen aus der lokalen Exchange Organisation über unseren Exchange Online Mandanten routen möchten?
Der Hybrid Configuration Wizard erstellt uns nur einen hybriden Sendekonnektor mit dem Adressraum der technischen Routingdomäne.
Es fehlt der explizite Sendekonnektor für den Internetadressraum *. Dieser muss explizit erstellt werden, wie das folgende Beispiel exemplarisch, mit Routing über einen Edge-Transport-Server, zeigt.
Sendekonnektor für externe E-Mail-Nachrichten über Exchange Online
Identity : E-Mail to Internet via ExchangeOnline
AddressSpaces : {SMTP:*;1}
CloudServicesMailEnabled : True
Comment : Send to external recipients via EDGE, EXO, and GW
DNSRoutingEnabled : False
Fqdn : smtpo.varunagroup.de
RequireTLS : True
SmartHostAuthMechanism : None
SmartHosts : {varunagroup-mail-onmicrosoft-com.mail.protection.outlook.com}
SourceTransportServers : {EDGE01}
TlsAuthLevel : CertificateValidationDieser Sendekonnektor routet die Nachrichten mit per MX-Auflösung (DNSRoutingEnabled = false), sondern per direkter Smarthost-Konfiguration an die MX-Adresse unseres Exchange Online Mandanten (SmartHosts = varunagroup-mail-onmicrosoft-com.mail.protection.outlook.com). Die Nachrichten sollen ja unsere Exchange Organisation über unseren Exchange Online Mandanten verlassen.
Da die Funktion DomainValidation für externe Zieladressen nicht funktionieren kann, muss für diesen Konnektor die etwas schwächere Funktion CertificateValidation genutzt werden. HIerbei werden immer noch die Gültigkeit und die CRL-Endunkte der verwendeten Zertifikate geprüft.
Da wir weiterhin das Cloud-Gateway für die finale Zustellung an externe Adressen nutzen möchten, fehlt uns nun noch die passenden Konnektoren für die Gateway-Kommunikation in Exchange Online. Schauen wir uns zuerst den ausgehenden Konnektor von Exchange Online zum Gateway an.
Ausgehender Konnektor für externe E-Mail-Nachrichten zum E-Mail-Gateway
Hierzu wird ein ausgehender Konnektor vom Typ Partner (ConnectorType = Partner) erstellt.
Identity : Outbound To Gateway
UseMXRecord : False
Comment : All outbound messages to Gateway
ConnectorType : Partner
ConnectorSource : Default
RecipientDomains : {}
SmartHosts : {s1.externalgateway.org, s2.externalgateway.org}
TlsDomain :
TlsSettings : EncryptionOnly
IsTransportRuleScoped : True
ValidationRecipients : {JaneDoe@externaldomain.test}
IsValidated : TrueDer Konnektor stellt ausgehender Nachrichten direkt an zwei dedizierte Smarthost-Adressen des Anbieters zu (SmartsHosts = s1.externalgateway.org, s2.externalgateway.org). Da sich bei diesem Anbieter die TLS-Zertifkate schon mal ändern können, erzwingen wir nur TLS (TlsSettings = EncryptionOnly).
In diesem Beispiel wird der Konnektor explizit in Zusammenarbeit mit einer Exchange Transportregel (ETR) verwendet. Die ETR routet Nachrichten mit Empfängeradressen außerhalb der Organisation über diesen Konnektor.
Die Erstellung dieses Konnektor erfordert eine Überprüfung, um produktiv genutzt werden zu können. HIer nutzt du einfach irgendeine externe E-Mail-Adresse.
Um nun im Rahmen der Umstellung auch eingehende Nachrichten vom Cloud-Gateway direkt in unserem Exchange Online Mandanten empfangen zu können, bedarf es weitere eingehenden Konnektors.
Eingehender Konnektor vom E-Mail-Gateway
Auch der eingehende Konnektor für Nachrichten vom Cloud-Gateway ist vom Typ Partner.
Identity : Inbound from Gateway
ConnectorType : Partner
ConnectorSource : AdminUI
SenderIPAddresses : {IP-1, IP-2}
SenderDomains : {smtp:*;1}
RequireTls : True
RestrictDomainsToIPAddresses : False
RestrictDomainsToCertificate : False
CloudServicesMailEnabled : False
TreatMessagesAsInternal : False
TlsSenderCertificateName :
OrganizationalUnitRootInternal : varunagroup.onmicrosoft.comDer Konnektor akzeptiert Verbindung von den offiziellen IP-Adressen des Cloud-Anbieters (SenderIPAddresses = IP-1, IP-2) auf Basis einer erzwungenen TLS-Verschlüsselung (RequireTls = True). Akzeptiert werden beliebige Absenderdomänen (SenderDomains = *).
Die Kunst besteht nun darin, keinen Konnektor zu konfigurieren, der aus dem eigenen Exchange Online Mandanten ein Open Relay macht.
Links
- Transport routing in Exchange hybrid deployments
- New-InboundConnector
- Sendekonnektor TLS-Authentifizierungsoptionen
Viel Spaß mit Exchange Server und Exchange Online.
