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.
- MOERA-Adresse - Was hat es mit der "onmicrosoft.com"-Adresse bei den Benutzern auf sich?
- Routingdomänen
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
MOERA - Microsoft Online Email Routing Address "<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.
Ob der Connector bei einer Mail vom lokalen Exchange Server gegriffen hat, können Sie im SMTP-Header der Mail im Exchange Online Postfach sehen:
x-ms-exchange-crosstenant-id: de21c301-a4ae-4292-aa09-6db710a590a6 x-ms-exchange-crosstenant-originalattributedtenantconnectingip: TenantId=<Tenant-GUID>;Ip=[80.66.20.24];Helo=[hybrid.msxfaq.de] x-ms-exchange-crosstenant-authsource: EX19.msxfaq.de x-ms-exchange-crosstenant-authas: Anonymous x-ms-exchange-crosstenant-fromentityheader: HybridOnPrem
Diese Header zeigen an, dass die Mail über einen Hybrid-Connector angenommen wurde.
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
- XOORG und Exchange
- CloudServicesMail
- ExternalEmailAddress
- Office 365: Mail Connector
- Hybrid Centralized Mail Transport
- Exchange Online als Nebeneingang für Mailempfang
- HCW im Detail
- Interorg
- Verzeichnisabgleich
- Office 365 Netzwerkziele
- MOERA-Adresse - Was hat es mit der "onmicrosoft.com"-Adresse bei den Benutzern auf sich?
- Routingdomänen
- Exchange online mail flow
https://community.office365.com/en-us/f/148/t/234679 - Transport Routing in Exchange hybrid deployments
https://technet.microsoft.com/EN-US/library/jj659050(v=exchg.150).aspx - Exchange Online: Keeping your 'Inbound
From Office 365' Receive
Connector Current with Microsoft
Public IP's
https://blogs.technet.microsoft.com/mitchelatmicrosoft/2014/12/22/exchange-online-keeping-your-inbound-from-office-365-receive-connector-current-with-microsoft-public-ips/ - Important notice for Office 365
email customers who have
configured connectors
https://blogs.technet.microsoft.com/exchange/2016/03/29/important-notice-for-office-365-email-customers-who-have-configured-connectors/ - Announcing a new way to create
connectors in Office 365
http://blogs.office.com/2015/05/22/announcing-a-new-way-to-create-connectors-in-office-365/ - How and when to decommission
your On-Premises Exchange
servers in a hybrid deployment
https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx - Office 365 β Common Exchange
Online Hybrid Mail Flow Issues
https://blogs.perficient.com/microsoft/2015/02/office-365-common-exchange-online-hybrid-mail-flow-issues/ - How-To Configure Message
Routing Between Cisco Email
Security in the Cloud and
Microsoft Office 365
https://www.cisco.com/c/dam/en/us/products/collateral/security/cloud-email-security/guide-c07-738366.pdf
Benutzt separate eigene IP-Adresse um Mail von Office 365 anzunehmen. Lücke, dass andere Tenants diese Ip missbrauchen wird genannt aber nicht gelöst