Hybrid Mail Routing

Exchange On-Prem und der Einstieg in die Cloud bedeutet für die meisten Firmen die Einrichtung einer Koexistenz beider Exchange Organisationen. Nur kleine Firmen können einen "Sprung" in die Cloud wagen und alle Postfächer zu einem Stichtag umstellen. Damit ist es erforderlich, die beiden Welten zu koppeln, damit interne Mails auch geschützt zwischen den beiden Welten ausgetauscht werden. Office 365 sieht dazu den "Hybrid Mode" vor.

Beachten Sie dazu auch Hybrid Centralized Mail Transport, HCW im Detail und Office 365: Mail Connector

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s
Sehr gute Beschreibung zum Mailrouting in einer Hybrid Umgebung

Grundverständnis

Technisch ist auch die Verbindung eine Office 365 Tenant mit einer Exchange On-Prem-Installation nichts anderes als eine Verbindung von zwei Exchange Organisationen, wie ich auf Interorg und Verzeichnisabgleich schon beschrieben habe.

  • Connectoren und Domaineinstellungen stellen das Mailrouting sicher
    Dabei wird bevorzugt der direkte Weg zum Zielsystem gesucht, um Relay-Systeme, Spamfilter u.a. zu umgehen und vielleicht abweichende Grenzwerte (größere Mails), andere OOF-Einstellungen, Weiterleitungen o.ä. zu erlauben.
  • Mailkontakte stellen das Adressbuch und die Weiterleitung sicher
    Damit das Adressbuch auf dem Client auf beiden Seiten eine vollständige Liste anzeigt, werden die On-Prem Postfächer in der Cloud als MailUser angelegt und Exchange Online Postfächer sind lokal dann eine "Remote Mailbox". Das hat auch den Vorteil, dass man "unbekannte" Empfänger schon beim Eintreffen erkennen und ablehnen kann.

Für die Kontakte sorgt der Office 365 ADSync-Prozess und das Mailrouting übernehmen normale Exchange Send-Connectoren und Receive Connectoren, die vom Hybrid Configuration Wizard entsprechende angelegt werden. Allerdings wird hier natürlich der Einsatz von TLS erfordert. Über diesen Weg authentifizieren sich die beiden Connectoren gegenseitig, d.h. der Send-Connector On-Prem spricht mit einem eigens eingerichteten Connector in Office 365 und umgekehrt. Offiziell kann die Exchange Online Umgebung nur mit einem Exchange Hubtransport oder einen Exchange Edge in ihrem Firmennetzwerk sich verbinden.

„Es dürfen keine weiteren SMTP-Hosts oder Dienste zwischen dem lokalen Exchange 2013-Clientzugriffsserver oder einem Exchange 2013/2010 SP3-Edge-Transport-Server und EOP vorhanden sein. Nachrichten hinzugefügte Informationen, die Hybridtransportfunktionen aktivieren, werden entfernt, wenn die Nachrichten einen Nicht-Exchange 2013-Server, einen Server vor Exchange 2010 SP3 oder einen SMTP-Host durchlaufen.“
Quelle: https://technet.microsoft.com/de-de/library/jj659055(v=exchg.150).aspx

Ignite 2017: BRK2090 Insights into your Office 365 Mail Flow
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2090
https://www.youtube.com/watch?v=PGJ9poMrYhc

Domains in Office 365

Wenn Sie einen Tenant in Office 365 einrichten, dann werden SMTP-Domänen angelegt. Eine dritte Domäne kommt aber bei den meisten Firmen sowieso hinzu, wenn Sie ihre Firmendomäne einrichten.

Die Domänen haben folgende Bewandtnis:

  • msxfaq.onmicrosoft.com
    Dies ist die Default Domäne, aus der z.B. der UPN und die Mailadresse für all die Benutzer abgeleitet wird, die ein Konto in der Cloud haben. Dieses Domäne ist auch in Exchange per Default vorhanden und ist zugleich die "OriginatorOrg".
  • msxfaq.mail.onmicrosoft.com
    Dies ist die SMTP-Routing-Domäne für Postfächer in der Cloud, zu denen es einen Kontakt in der On-Prem-Umgebung gibt. Sie wird in Exchange Online als auch On-Prem angelegt, wenn Exchange mit Hybrid konfiguriert wird. Sie wird zusätzlich auch unter "RemoteDomains" hinterlegt um die Formatierung der übertragenen Mails zu optimieren. Die andere Organisation ist ja nicht irgendjemand. Weiterhin wird diese Domäne auch in den Empfängerrichtlinien addiert.
  • msxfaq.net
    Dies ist eine zusätzliche Domäne, die durch das Hinzufügen in Office 365 auch in Exchange addiert wird. Das ist z.B. eine "richtige" SMTP-Domäne mit der die Postfächer erreichbar sind und auch Mails versenden.

Diese Liste ist nicht zwingend mit den Domänen in ihrer On-Premises-Exchange Organisation identisch. Sie können lokal durchaus On-Prem weitere SMTP-Domänen haben, die für Exchange Online aber nicht relevant sein müssen. Wichtig ist, dass alle Empfänger in beiden Welten vorhanden sind, so dass die Adressbücher "gleich" sind.

Mailrouting

Wie Sie von Exchange sicher schon kennen, wird das Mailrouting über Connectoren konfiguriert. On-Prem ist das ein Send-Connector, der Mails an die Cloud sendet. Damit die Cloud ihren On-Prem Server "erkennt" , wird dort ein "Inbound Connector" angelegt, der der Cloud dabei hilft ihren On-Prem Server zu erkennen. Das kann über die IP-Adresse oder einen Namen im Zertifikat sein.

In die Gegenrichtung legt der HCW einen "Outbound Connector" in der Cloud an, der Mails an ihre On-Prem-Benutzer sendet. Diese Mails landen dann auf einem Receive Connector ihrer On-Prem-Umgebung. Bis Exchange 2010 hat der HCW einen eigens dafür definierten Connector angelegt. Seit Exchange 2013 wird der Standard Connector genutzt. Das bringt durchaus Risiken, wie ich auf Hybrid Hintereingang beschrieben habe.

Ausgangssituation

Werfen wir einen Blick auf die Connectoren. Wenn Sie das erste Mal das Exchange Control Panel der Exchange Online Instanz starten, dann sehen Sie, dass es per Default erst mal keine Connectoren gibt.

Eine Exchange Online Instanz kann aber dennoch Mails in das Internet versenden oder empfangen, wenn sie den MX-Record entsprechend gesetzt haben. Bei einer On-Prem Installation ist das schon etwas anders. Hier gibt es bei Exchange 2016 schon fünf Receive-Connectoren

Der Hybrid Configuration Wizard erweitert diese Konfiguration nun um folgende weitere Connectoren.

On-Prem: Send-Connector "Outbound to Office 365"

Der Hybrid Assistent legt einen Send Connector mit dem Namen "Outbound to Office 365" an, über den ihre Exchange On-Prem Organisation alle Mails an die Domäne "<tenant>.mail.onmicrosoft.com" per MX-Record zur Cloud sendet. Der MX-Record dazu wird von Microsoft verwaltet.

nslookup -q=MX msxfaq.mail.onmicrosoft.com
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
msxfaq.mail.onmicrosoft.com  MX preference = 10, mail exchanger = msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com
[PS] C:\>Get-SendConnector "Outbound to Office 365"| fl

AddressSpaces                : {smtp:msxfaq.mail.onmicrosoft.com;1}
AuthenticationCredential     :
CloudServicesMailEnabled     : True
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
ConnectorType                : Default
DNSRoutingEnabled            : True
DomainSecureEnabled          : False
Enabled                      : True
ErrorPolicies                : Default
ForceHELO                    : False
Fqdn                         : mail.msxfaq.de
FrontendProxyEnabled         : False
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : EX2016
Identity                     : Outbound to Office 365
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
MaxMessageSize               : 35 MB (36,700,160 bytes)
Name                         : Outbound to Office 365
Port                         : 25
ProtocolLoggingLevel         : None
Region                       : NotSpecified
RequireOorg                  : False
RequireTLS                   : True
SmartHostAuthMechanism       : None
SmartHosts                   : {}
SmartHostsString             :
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {EX2016}
TlsAuthLevel                 : DomainValidation
TlsCertificateName           : <I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de,
                               OU=Domain Control Validated
TlsDomain                    : mail.protection.outlook.com
UseExternalDNSServersEnabled : False

Eine Authentifizierung per Benutzername o.ä. findet nicht statt. Aber die Cloud "erkennt natürlich ihren Server, wie sie gleich sehen werden.

Hinweis:
Der Hybrid Connector ist wirklich per Default nur für die MEUI-Domain "<tenantname>.mail.onmicrosoft.com" zuständig. Wenn sie in der Cloud auch Empfänger in der Domain "<tenantname>.onmicrosoft.com" nutzen, z.B. Microsoft Teams/Office Groups, dann können Sie diese Domain später mit addieren und damit auch diesen Verkehr durch den Tunnel senden.

Office 365: Inbound Connector

Der HCW legt in Office 365 zwei Connectoren an, einen für eingehende Mails von ihrem On-Prem-System und einen für Mails an ihr On-Prem-System.

Der "Inbound Connector" sorgt dafür, dass die Mails von der lokalen Umgebung entsprechend "vertrauenswürdig" sind.

In dem Beispiel identifiziert sich der On-Prem Server mit einem Zertifikat. Alternativ kann dies auch eine IP-Adresse sein. Dazu passend gibt es natürlich On-Prem dann auch den bereits beschriebenen Send-Connector.

Office 365: Outbound Connector

In die Gegenrichtung wird ein "Outbound Connector" zur On-Prem-Umgebung angelegt. Maßgeblich hier das "Mail Flow Szenario" und hier die Angabe des "Smarthost". Auch hier wird das Zertifikat zusätzlich als Sicherheit verwendet, nicht dass ein DNS-Spoofing die Mails zu einem anderen Server umleiten könnte.

Der Connector ist hier für den Adressraum "*" gültig, da wir auch alle Mails von Office 365 über die On-Prem-Umgebung und NoSpamProxy versenden. Wenn Sie Mails aus der Cloud direkt in das Internet senden wollen, dann stehen hier nur die lokale Domänen.

On-Prem: Receive Connector

Auch der lokale Exchange Server muss ja unterscheiden können, ob die Mail nun " aus dem Internet" oder von Exchange Online im allgemeinen oder von ihrem Exchange Online Tenant kommt. Exchange On-Premises geht erst einmal davon aus, dass ihr Receive Connector "Default Frontend <servername>" für jegliche RemoteIP-Adresse auch aus dem Internet erreichbar ist und daher die Konfiguration dort angepasst werden muss.

Der HCW prüft dies aber und wenn es keinen Receive Connector gibt, der "any" annimmt, dann legt HCW einfach einen neuen Connector an:

Das kann unerwartete Ergebnisse haben, wenn Sie vorher absichtlich eine "offene Annahme" unterbunden haben.

Die Standard Connectoren von Exchange 2016 sind z.B.:

[PS] C:\>Get-ReceiveConnector

Identity                                Bindings                                Enabled
--------                                --------                                -------
EX2016\Default EX2016                   {0.0.0.0:2525, [::]:2525}               True
EX2016\Client Proxy EX2016              {[::]:465, 0.0.0.0:465}                 True
EX2016\Default Frontend EX2016          {[::]:25, 0.0.0.0:25}                   True
EX2016\Outbound Proxy Frontend EX2016   {[::]:717, 0.0.0.0:717}                 True
EX2016\Client Frontend EX2016           {[::]:587, 0.0.0.0:587}                 True
EX2016\RelayAnonymous                   {[::]:25, 0.0.0.0:25}                   True

Sie finden hier aber noch einen zusätzlichen Receive Connectoren "RelayAnonymous", der für ausgewählte Source-IP-Adressen ein Relay erlaubt. Interessant ist hier als oder Default Frontend, mit dem sich Exchange 2016 verbinden könnte. Hier eine Auswahl der Felder:

[PS] C:\>Get-ReceiveConnector "EX2016\Default Frontend EX2016" |fl

AuthMechanism                             : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
BinaryMimeEnabled                         : True
Bindings                                  : {[::]:25, 0.0.0.0:25}
TlsCertificateName                        : <I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa,
                                            C=BE<S>CN=*.msxfaq.de, OU=Domain Control Validated
Comment                                   :
Enabled                                   : True
RemoteIPRanges                            : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}
RequireEHLODomain                         : False
RequireTLS                                : False
EnableAuthGSSAPI                          : False
ExtendedProtectionPolicy                  : None
LiveCredentialEnabled                     : False
TlsDomainCapabilities                     : {mail.protection.outlook.com:AcceptCloudServicesMail}
Server                                    : EX2016
TransportRole                             : FrontendTransport
Identity                                  : EX2016\Default Frontend EX2016

Und hier noch mal die "tlsdomaincapabilities" genauer aufgeschlüsselt.

[PS] C:\>(Get-ReceiveConnector "EX2016\Default Frontend EX2016").tlsdomaincapabilities | fl

Domain             : mail.protection.outlook.com
Capabilities       : AcceptCloudServicesMail
SmtpX509Identifier :

Zum einen sind die RemoteIP-Ranges nicht eingeschränkt und dann findet sich nur im Feld "TlsDomainCapabilities" der Wert "{mail.protection.outlook.com:AcceptCloudServicesMail}". Das ist auch der einzige Eintrag, den der HCW hier macht. Bei allen anderen Connectoren ist der Wert nicht gesetzt:

[PS] C:\>Get-ReceiveConnector | select identity,TlsDomainCapabilities

Identity                                                  TlsDomainCapabilities
--------                                                  ---------------------
EX2016\Default EX2016                                     {}
EX2016\Client Proxy EX2016                                {}
EX2016\Default Frontend EX2016                            {mail.protection.outlook.com:AcceptCloudServicesMail}
EX2016\Outbound Proxy Frontend EX2016                     {}
EX2016\Client Frontend EX2016                             {}
EX2016\RelayAnonymous                                     {}

So versteht der On-Prem-Server, dass eine Verbindung eines entfernten Systems, welches sich per Zertifikat als "mail.protection.outlook.com" ausweist, der passende Tenant ist.

Da kann man nun nur noch hoffen, dass keine PKI irrtümlich ein Zertifikat für diesen Namen ausstellt und damit jemand anderes sich als legitimer Partner ausweisen kann.

Wie unangenehmer dürfte es ihnen aber sein, dass der Receive Connector erst einmal von "überall" erreichbar ist und auch wenn sich die Absenderseite nicht mit einem Zertifikat ausweist, so kann sie dann eben "normale" Mails ohne Empfängerprüfung, SPF-Check, RBL-Check etc. einliefern. Keine verlockende Aussicht.

Achtung:
Sie müssen sich Gedanken zur weiteren Absicherung des On-Prem Receive Connectors machen, da sie ansonsten eventuell ein "offenes System" haben.

Beachte dazu auch die Seite Hybrid Hintereingang

Remote Domains

Mit den Connectoren in Office 365 und On-Prem ist sichergestellt, dass die Mails zwischen den beiden Welten direkt und per TLS verschlüsselt und abgesichert übertragen werden. Ganz fertig sind wird aber noch nicht, da im nächsten Schritt nun den beiden Welten beigebracht wird, dass die andere Seite vertrauenswürdiger ist als das restliche Internet. Das gilt z.B. hinsichtlich von OOF-Meldungen (Intern statt extern), die Erlaubnis zur automatischen Weiterleitung von Mails über Regeln u.a.

Auch das macht der HCW für sich, indem er in Office 365 ihre On-Prem-Domain entsprechend einträgt und konfiguriert.

On-Prem werden die vergleichbaren Einstellungen für die "tenantname.mail.onmicrosoft.com" gemacht, die als TargetAddress bei den Benutzern hinterlegt ist, deren Postfach schon in der Cloud liegt.

Routing mit CBR -Connector based Routing

Während bei Exchange On-Prem normalerweise anhand der Ziel-SMTP-Domäne der passende Send-Connector ausgewählt wird, ist die bei Exchange Online anders geregelt. Über Transport-Regeln kann man nicht nur die Mails verändern, sondern auch den "Next Hop" vorgeben.

Das können Administratoren einer On-Prem-Umgebung so nicht aber eröffnet in Office 365 vielfältige Möglichkeiten einer Anbindung von anderen Dienstleistern.

Von anderem Tenant

Interessant ist der Versand einer Mail von einem anderen Office 365 Tenant an eine On-Prem Service. Auch hier wird die Mail per TLS verschlüsselt und es werden die gleichen Mailserver für den Versand ins Internet wie auch zum Versand im Hybridmode genutzt. Ein Relay muss also einen anderen Indikator heranziehen, um die Mail aus dem "eigenen Partner-Tenant" auch als solchen zu verwenden.

Hier habe ich mal eine Mail aus meinem NoSpamProxy extrahiert und mir die Header angeschaut.

X-OriginatorOrg: msxfaq.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2015 16:11:58.9849 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: eef62a09-7718-4063-82db-d7582dc8916f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR01MB267

Wenn eine Firewall oder Schutzlösung etwas genauer auf die Verbindung schaut, dann könnte Sie anhand des Zertifikats ermitteln, dass die Gegenstelle Office 365 ist und dann über den Header den Tenant ermitteln.

Weitere Links