AcceptCloudServicesMail und CloudServicesMailEnabled

Diese Seite versucht etwas Licht hinter die Einstellung "AcceptCloudServicesMail" bei Exchange Connectoren zu bringen, der offizielle nur durch den HCW - Hybrid Configuration Wizard gesetzt werden darf.

Diese Seite ist "Work in Progress" und beschreibt meine Erkenntnisse aus verschiedenen Umgebungen. Diese sind nur teilweise durch Microsoft beschrieben und können falsch sein. Microsoft entwickelt seine Produkte weiter und die manuelle Nutzung der hier beschrieben Felder am HCW vorbei ist von Microsoft nicht unterstützt.

Zwei Topologien - Eine Organisation

Alle Exchange OnPremises Server "vertrauen" sich untereinander und tauschen Metainformationen zu den Mails aus, wo her diese kommen. Es wäre recht ungeschickt, wenn Exchange Server auch interne Mails bei jeden Empfang auch auf Spam und Viren prüfen müssen und unklar ist, ob der Absender zur Verwendung der Mailadresse berechtigt ist. Dies gilt analog für alle Exchange Online Server untereinander. Sobald Sie nun beide Plattformen nutzen, muss es eine Verbindung zwischen den eigentlich getrennten Systemen geben, deren Konfiguration der HCW - Hybrid Configuration Wizard für sie erledigt. Dazu gehören die Abfrage von Frei/Belegt-Zeiten, Mailtipps aber auch Migrationsendpunkte und das Mailrouting. Nur die Einrichtung des ebenfalls zwingend erforderlichen Adressbuchabgleichs durch ADSync müssen Sie getrennt vornehmen.

Bei AcceptCloudServicesMail und CloudServicesMailEnabled dreht sich alles um SMTP-Übertragung zwischen Exchange OnPremises und Exchange Online. Die beiden eigentlich getrennten Exchange Umgebungen müssen per SMTP derart verbunden werden, dass nicht nur Mails übertragen werden, sondern auch Spamfilter, Headerfirewall und andere Schutzfunktionen umgangen werden. Wenn z.B. eine Mail "anonym" bei Exchange eingeliefert wird, dann zeigt Outlook beim Absender auch die SMTP-Adresse mit. Nur bei "authentifizierten" Zustellungen erscheint z.B. der "Displayname" und die Absender der einen Seite sollen ja auf der anderen Seite ja auch als "vertrauenswürdig" erscheinen und Mails von authentifizierten Absendern sollten auch bei der Spambewertung anders betrachtet werden.

Routing und Accepted Domain

Damit stellt sich die Frage wie sich Exchange Server gegenseitig authentifizieren und welchen Mehrwert eine Authentifizierung damit verbindet. Dazu schauen wir uns verschiedene Routing-Möglichkeiten einmal an.

Szenario Beschreibung

Innenverhältnis

Wir fangen einfach an und eine Firma nutzt sowohl Exchange OnPremises als auch Exchange Online. Normalerweise nutzen sie den Hybrid Configuration Wizard um das Routing zu konfigurieren, damit die Tenant Domain über einen Send-Connector in die Cloud geht. Umgekehrt sendet die Cloud alle Mails an ihre Domains zum OnPremises Server.

Internet -> OnPrem -> EXO

Speziell am Anfang einer Migration verweist der MX-Record auf die vorhandene Spamfilter-Lösung und die Mails landen daher über einen eigenen Spamfilter bei Exchange OnPremises. Wenn der Empfänger schon in der Cloud ist, dann routet Exchange die Mail anhand der RemoteRoutingAddress (LDAP:TargetAddress) an die "<tenantname>.onmicrosoft.com-Adresse direkt in den Tenant.

Hier muss der Tenant ihren OnPremises Server erkennen und als "Trusted" eintragen, denn die Absenderadresse ist ja eine externe Domain, die per SPF z.B. einen Versand verhindern kann. Nur mit der passenden Konfiguration kommt die Mail in dem Fall dennoch beim Exchange Online Empfänger an

EXO -> OnPrem -> Internet

Am Anfang werden Sie aber auch einen Exchange Online Absender erst einmal zwingen, den lokalen Exchange Server als Relay zum Internet zu nutzen. Vielleicht haben Sie EXO noch nicht in der SPF-Liste drin oder lokale Archiv- und Disclaimer-Lösungen erfordern ein Routing über OnPremises.

In dem Fall muss Exchange OnPremises ihren den Tenant genau erkennen, denn ihr lokale Exchange Plattform soll ja kein "Offenes Relay" sein. Nur mit der passenden Einrichtung erlaubt Exchange OnPremises, dass Absender ihrer Domains so ihre Mails ins Internet versenden können.

Internet -> EXO -> OnPrem

Wenn Sie Exchange Online Protection oder Defender for Office 365 P1/P2 nutzen, dann routen Sie eingehende Mails in ihre Domain über den MX-Record zu Microsoft. Empfänger in Exchange Online bekommen die Mail direkt aber alle Ziele auf dem lokalen Server bekommt die Mail über die "RemoteRoutingAddress" und einen Outbound-Connector zu Exchange OnPremises gesendet.

Auch hier ist wieder wichtig, dass Exchange OnPrem ihren eigenen Tenant erkennt und nicht einen "unsicheren" Nebeneingang für Spammer öffnet. Daher prüft Exchange das vom Absender vorgezeigte Zertifikat um dann die Mails nur anzunehmen, wenn der Empfänger auch OnPremises ist.

OnPrem -> EXO -> Internet

Sobald Sie Mails über Exchange Online Protection oder Defender for Office 365 P1/P2 empfangen, sollten Sie auch ausgehende Mails über den Weg routen. So "versteckt" sich der lokale Exchange Server quasi hinter der Cloud und kann sogar von Transportregeln und DKIM-Signaturen von Exchange Online profitieren.

Sie sehen also, dass in allen fünf Fällen eine saubere und eindeutige Identifizierung der Gegenseite erforderlich ist , um dann weitere Prüfungen hinsichtlich der Absender und Empfänger vorzunehmen.

MTLS und IP-Adresse

Bei all diesen Fällen ist es wichtig, dass die Exchange Server sich "erkennen" und richtig einstufen. Das machen die Server über Zertifikate bzw. IP-Adresse und natürlich die Absenderadressen und Empfängeradressen. Interessant ist bei der Betrachtung der "Receive Connector" bei Exchange OnPremises und der "Inbound Connector" bei Exchange Online. Es gibt hier aber einen Unterschied:

  • Exchange OnPremises Receive Connector
    Hier legt Microsoft keinen eigenen Connector mit einer eigenen IP-Adresse:Port-Kombination an , sondern pflegt den Parameter "AcceptCloudServicesMail" am Default Connector. Das bedeutet, dass Exchange Online sich eingehend mit diesem Connector verbinden muss. Sie können natürlich auch einen eigenen Connector mit eigener IP-Adresse und vor allem Namen für das eigene Zertifikate anlegen und in Exchange Online konfigurieren.
  • Exchange Online Inbound Connector
    Hier legt HCW einen eigenen Connector anhand der Quell-IP oder über ein Zertifikat ermittelt wird. Das ist aber nur ein Teil der Wahrheit, denn theoretisch könnte ja jeder Exchange Online Admin ebenfalls unabsichtlich oder absichtlich einen ähnlichen Connector anlegen. Hier muss Microsoft dann die Absender und Ziel-Domain der Mail mit einbeziehen, um den richtigen Tenant zu wählen.
    Hier legen ich ihnen den Artikel zu "Office 365 Message Attribution (https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143) ans Herz, der die Zuordnung und vorab die verschiedenen Konflikte beschreibt.

Ich habe versucht, alle Testfälle auch nachzustellen, aber speziell mit Exchange Online ist das nicht ganz einfach. Denken Sie daran, dass Exchange Online ihre Tenants eine strenge Absenderprüfung hat und nur Mails "originär" von authentifizierten Absendern sendet oder über vorhandene Kontakte weiterleitet.

Nach meinen Recherchen stellt sich das dann wie folgt dar:

Zu Exchange OnPremises

Exchange OnPremises erlaubt über den Parameter "AcceptCloudServicesMail" nur eine Authentifizierung per Zertifikatnamen aber keine IP-Adresse

Eingehend zu Zertifikat From To Ergebnis Beschreibung

OnPrem

=mail.protection.outlook.com

AcceptedDomain

AcceptedDomain

SameOrg

Alle Vorteile der "internen Verbindung" werden angewendet.

OnPrem

=mail.protection.outlook.com

AcceptedDomain

*

SameOrg

IN dem Fall kann die Cloud über Exchange OnPrem auch in das Internet senden. Der lokale Exchange Server ist ein "Relay" für Exchange Online, solange die Absenderadresse aus ihren hinterlegten Domains kommt

OnPrem

=mail.protection.outlook.com

*

AcceptedDomain

SameOrg

Auch dies ist möglich, wenn Sie z.B. den MX-Record zu EXO stellen und die Mails dann an OnPremises Empfänger anhand der MailUser in der Cloud rerouted werden. (RemoteRecipientAddress/TargetAddress)

OnPrem

=mail.protection.outlook.com

*

*

?

Dieser Fall "sollte" nie passieren, dass aus der Cloud eine Mail versendet wird, die weder von ihrer Firma noch an ihre Firma geht. Insofern konnte ich da auch noch nicht nachstellen.

OnPrem

<>mail.protection.outlook.com

 

 

Default

RISIKO. per Default erlaubt Exchange auf dem "Default Receive Conectore" keine anonyme Zustellung. Aber viele Firmen haben das geändert und dann könnte ein Spammer zumindest interne Empfänger erreichen. Daher sollten Sie den Connector nicht für "any ip" aus dem Internet erreichbar machen sondern nur den vorgeschalteten Spamfilter.

Zu Exchange Online

Über den Inbound Connector können Sie den lokalen Server sowohl per TLS-Zertifikat aber auch IP-Adressen erkennen lassen. Daher habe ich vier Fälle, wenn Sie in Exchange Online einen Inbound Connector vom Typ "OnPrem zu Office 365" eingerichtet haben, und das Zertifikat oder die Source-IP-Adresse passt:

Eingehend zu Zertifikat/IP From To Ergebnis Beschreibung

EXO

Match

AcceptedDomain

AcceptedDomain

SameOrg

Analog zu Exchange OnPremises erlaubt Exchange Online die Zustellung und wehr die Mail nicht als Spam/Spoofing o.ä. ab.

EXO

Match

AcceptedDomain

*

SameOrg

Ohne die Erkennung des passenden OnPrem Exchange würde so eine Mail als Spoofing und SPF-Fail vermutlich abgeleht.

EXO

Match

*

AcceptedDomain

SameOrg

Diese Mail würde EXO erst mal auch anonym annehmen aber natürlich durch Spamfilter jagen. Erst über den Connector wird dies verhindert

EXO

Match

*

*

?

Auch diese Mails sind theoretisch möglich, wenn Sie z.B. in Exchange OnPrem eine "Umleitung" statt Weiterleitung einrichten. Aber es ist natürlich nicht sichergestellt, dass EXO die Mail dann auch wieder "los" bekommt.

EXO

NoMatch

*

AcceptedDomain

Spamfilter

Wenn der einliefernde Server sich nicht per Zertifikat oder IP authentifizieren kann, dann ist es eine "normale" Mail, die dem Spamfilter unterworfen wird

EXO

NoMatch

*

Anderer Tenant

Spamfilter

Wenn die Domain des Empfängers zu einem anderen Tenant passt, dann wird sie den dortigen Einstellungen unterworfen

EXO

NoMatch

*

*

Abgelehnt

Wenn Exchange Online weder den Absender authentifizieren kann noch das Ziel ein Empfänger oder Domain in Exchange Online ist, dann lehnt Exchange die Mail ab.

Für die Verarbeitung eingehender Mails ist der folgende Blog-Artikel von Microsoft wichtig:

Da steht:

... The certificate name, or Subject Alternative Name (SAN) on the certificate, is used to lookup matching tenant Inbound connectors that are of type OnPremises across all tenants within the EOP forest.
... we next look at which tenant has the TlsSenderCertificateName domain configured as an accepted domain.
... we next look at the Connecting IP and find all tenants with Inbound OnPremises connectors which match the IP.
... we next look at what tenant has the MailFrom domain configured as an accepted domain. 
Quelle: Office 365 Message Attribution https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Da Ziel muss sein, dass EXO die Mail als "Originating" klassifiziert, d.h. sie kommt von ihnen und damit ist sie vertrauenswürdig.

Andere TLS-Domain

Natürlich beschreibt Microsoft die Nutzung des Parameters "AcceptCloudServicesMail" nur für die Hybrid-Bereitstellung. Aber es ist natürlich möglich, auch eine andere TLS-Domain zu hinterlegen. Das eröffnet neue Wege für vorgelagerte Mailsysteme oder Spamfilter. Stellen Sie sich vor, dass z.B. ein Spamfilter wie NoSpamProxy die guten Mails an das nachgelagerte Exchange System übertragen will. Was sollte sie daran hintern, dass der Mailserver sich per MTLS am Exchange Online oder Exchange OnPremises authentifiziert und sie über AcceptCloudServicesMail und CloudServicesMailEnabled der Verbindung die entsprechenden Vorteile einräumen?

Ich würde aber davon absehen, denn dann würde auch ein externe Absender in Outlook nur noch mit dem "Displaynamen" angezeigt werden. Der Anwender könnte nicht mehr erkennen, dass die Mail letztlich doch "anonym" von extern gekommen ist.

Multi Domain Hosting

Einen weiteren Sonderfall gibt es, wenn Sie seine Exchange Umgebung mit mehreren Tenants verbinden wollen. Stellen Sie sich vor, sie haben eine Exchange OnPremises Umgebung, in der zwei Firmen gehostet werden und die nun im Rahmen einer Office 365-Einführung "getrennt" werden sollen.

Die Herausforderung dabei ist, dass Exchange OnPremises ohne 3rd Party Tools keine Sender Based Routing kann. Sie können daher bei der Verbindung zu Exchange Online keinen eigenen Send-Connector verwenden. Exchange OnPremises routet nur anhand der Ziel-Domain. Damit wird es für Exchange Online natürlich knifflig zu ermitteln, welcher Tenant nun gemeint ist.

Es gibt schon Gründe, warum Microsoft mit dem HCW nur eine Verbindung einer OnPremises Topologie mit einem Exchange Online Tenant erlaubt und es nur HybridConfigurationDocument im lokalen AD gibt.

Das bedeutet aber nicht, dass Sie nicht manuell eine vergleichbare Konfiguration zum zweiten Tenant aufbauen können. Mit dem Wissen um den Entscheidungsbaum können Sie durchaus hier unterscheiden, denn Exchange Online bewertet neben dem Zertifikat auch die SMTP-Domains der Absender bzw. Empfänger, um den passenden Tenant zuzuordnen. Allerdings müssen ihre Firmen natürlich darauf vertrauen, dass Sie ihre OnPremises-Umgebungen sauber und "sicher" sind. Knifflig wird das natürlich wieder bei Führungskräften, die für beide Firmen arbeiten und daher mit unterschiedlichen Absenderadressen ihr Mails formulieren. Das kann beim Messagetracking dann schon knifflig werden, wenn ausgehende Mails von OnPremises auch noch über EXO in die weite Welt geroutet werden.

Eingehend können Sie auch erst mal nicht anhand des von Exchange Online gelieferten Zertifikats den Tenant unterscheiden. Das geht dann nur zusätzlich durch die Auswertung der Exchange Header, die bei aktivierten AcceptCloudServicesMail und CloudServicesMailEnabled mitgeliefert werden. Oder Sie "vertrauen" einfach darauf, dass die Absenderdomains von Exchange Online nicht gefälscht sind.

Parameter

Hier dann noch noch mal als Referenz die Stellen, an denen Sie AcceptCloudServicesMail und CloudServicesMailEnabled einstellen können:

Exchange Online

Exchange OnPrem

EXO->OnPrem

EXO: Outbound Connector

New-OutboundConnector `
   -Name „Outbound to MSXFAQ“ `
   -enabled:$true `
   -Smarthosts hybrid.msxfaq.net `
   -UseMXRecord:$False `
   -RouteAllMessagesViaOnPremises:$true `
   -CloudServicesMailEnabled: True `
   -Recipientdomains “*“ `
   -Connectortype OnPremises `
   -TLSDomain hybrid.msxfaq.net `
   -TLSSettings:Domainvalidation

OnPrem Receive Connector

Set-ReceiveConnector `
   -Identity „EX2016\Default EX2016“ `
   -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"}

OnPrem->EXO

EXO: Inbound Connector

New-InboundConnector `
   -Name „Inbound from <guid>“ `
   -Senderdomains “*“ `
   -RequireTLS $true `
   -TlsSenderCertificateName hybrid.msxfaq.net `
   -connectortype OnPremises `
   -Enabled:$true `
   -CloudServicesMailEnabled $true `
   -TreatMessagesAsInternal $false

OnPrem Send Connector

Set-SendConnector `
   -Identity „Outbound to Office 365 - <guid>“ `
   -CloudServicesMailEnabled: $True `
   -Fqdn hybrid.msxfaq.net `
   -RequireTLS : $True `
   -TlsAuthLevel : DomainValidation `
   -TlsCertificateName : <I>CN=IssuingCA, O=xxxx, C=BE<S>CN=hybrid.msxfaq.net, C=DE `
   -TlsDomain : mail.protection.outlook.com

 

Hinweis:
Bei den Einstellungen gibt es ein Feld "ConnectorSource". Hier sehen, Sie, wer den Connector zuletzt verwaltet hat. Bislang habe ich "AdminUI" oder "HybridWizard" gesehen. Es zählt immer die letzte Änderung, d.h. es ist ersichtlich, ob jemand manuell einen Connector geändert hat, der vom HCW angelegt wurden.

Verifikation

Am Ende steht natürlich noch die Überprüfung an, ob die Mails alle wie erwartet zugestellt werden. Genau genommen müssen Sie diese Matrix bei jeder Veränderung der Connectoren immer wieder durchlaufen und nicht alle Kombinationen müssen möglich sein.

Absender Via Ziel Status Beschreibung

OnPrem

-

OnPrem

 

 

OnPrem

-

EXO

 

 

EXO

-

EXO

 

 

EXO

-

OnPrem

 

 

Extern

-

OnPrem

 

 

Extern

OnPrem

EXO

 

Nur wenn EXO hinter OnPrem steht

Extern

EXO

OnPrem

 

Nur wenn OnPrem hinter EOP steht

EXO

OnPrem

Extern

 

 

EXO

-

Extern

 

 

OnPrem

-

Extern

 

 

OnPrem

EXO

Extern

 

 

Beachten Sie dabei auch die Sonderfälle mit "Centralized Mail Transport", Spoofing etc.

Establishing Exchange Hybrid Mailflow
https://techcommunity.microsoft.com/t5/video-hub/establishing-exchange-hybrid-mailflow/ba-p/1681493
https://www.youtube.com/watch?v=1i_SO6nKe0o

Weitere Links