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 On-Premises 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 On-Premises 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 On-Premises 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 On-Premises Server. |
Internet -> On-Prem -> 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 On-Premises. 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 On-Premises 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 -> On-Prem -> 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 On-Premises. In dem Fall muss Exchange On-Premises ihren den Tenant genau erkennen, denn ihr lokale Exchange Plattform soll ja kein "Offenes Relay" sein. Nur mit der passenden Einrichtung erlaubt Exchange On-Premises, 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 On-Premises gesendet. Auch hier ist wieder wichtig, dass Exchange On-Prem 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 On-Premises 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 On-Premises und der "Inbound Connector" bei Exchange Online. Es gibt hier aber einen Unterschied:
- Exchange On-Premises 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 On-Premises
Exchange On-Premises 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 On-Prem 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 On-Premises 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 On-Premises erlaubt Exchange Online die Zustellung und wehr die Mail nicht als Spam/Spoofing o.ä. ab. |
EXO |
Match |
AcceptedDomain |
* |
SameOrg |
Ohne die Erkennung des passenden On-Prem 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 On-Prem 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:
- Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
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 On-Premises
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
On-Premises 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 On-Premises 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 On-Premises 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 On-Premises 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 On-Premises 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 On-Premises 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 On-Premises-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 On-Premises 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.
OnPrem und X-OriginatorOrg
Bei dem Empfang von Mails aus der Cloud an den lokalen Exchange Server kommt es noch auf das Feld X-OriginatorOrg an, welches nur ausgewertet wird, wenn die Mail über einen Connector angekommen ist, der ein "AcceptCloudSericesMail" oder "AcceptOorgProtocol" hat und die XOORG-Domain einer lokalen Accepted Domain in Exchange entspricht.
Damit wird eine eindeutige Tenant-Zuordnung möglich. Wenn ich z.B.: meinem "bösen Tenant" einen Outbound Connector zu ihrem OnPremises System hinterlege, dann bekomme ich nicht das gleiche Vertrauen, obwohl meine Verbindung von den gleichen IP-Bereichen und mit dem gleichen Zertifikat komme, mit denen auch ihr eigener Tenant die Verbindung aufbaut.
Nun ist auch klar, warum ein fremdes Relay zwischen Exchange OnPremises und Exchange Online nicht unterstützt wird.
Weitere Informationen finden Sie dazu auf:
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 ConnectorNew-OutboundConnector ` -Name "Outbound to MSXFAQ" ` -enabled:$true ` -Smarthosts hybrid.msxfaq.net ` -UseMXRecord:$False ` -RouteAllMessagesViaOn-Premises:$true ` -CloudServicesMailEnabled: True ` -Recipientdomains “*“ ` -Connectortype On-Premises ` -TLSDomain hybrid.msxfaq.net ` -TLSSettings:Domainvalidation |
OnPrem Receive ConnectorSet-ReceiveConnector ` -Identity „EX2016\Default EX2016“ ` -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"} |
OnPrem->EXO |
EXO: Inbound ConnectorNew-InboundConnector ` -Name „Inbound from <guid>“ ` -Senderdomains “*“ ` -RequireTLS $true ` -TlsSenderCertificateName hybrid.msxfaq.net ` -connectortype On-Premises ` -Enabled:$true ` -CloudServicesMailEnabled $true ` -TreatMessagesAsInternal $false |
OnPrem Send ConnectorSet-SendConnector ` -Identity „Outbound to Office 365 - <guid>“ ` -CloudServicesMailEnabled: $True ` -Fqdn hybrid.msxfaq.net ` -RequireTLS : $True ` -TlsAuthLevel : DomainValidation ` -TlsCertificateName : <I>CN=IssuingCA, O=xxxx, C=DE<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.
Mehrere Connectoren
Der Hybrid Configuration Wizard setzt die Einstellungen auf dem lokalen Server nur für den "Default Receive Connector". Das funktioniert sicher bei vielen Firmen mit einem einzelnen Server, die auf dem Exchange Server auch zugleich das öffentliche Zertifikat mit den Namen eingerichtet und gebunden haben. In der Standardeinstellung stellt Exchange aber auch ein "Self Signed Zertifikat" für seinen FQDN aus. Nun müssen Sie beachten, wie Exchange das "richtige" Zertifikat für den Inbound Connector nutzt. Jeder Receive Connector hat einen "FQDN" und normalerweise steht da der FQDN des Servers drin.
Ich könnte mir nun ein SAN-Zertifikat kaufen in dem sowohl der Name "EX01.UCLABOR.DE" als auch der gewünschte Hybrid-Name enthalten ist. Ein SAN-Zertifikat kostet etwas mehr aber hilft den Firmen nicht, die einen inoffiziellen FQDN intern verwenden. Das Beispiel hier zeigt daher einen manuell angelegten Receive-Connector mit dem Namen "Inbound Hybrid", der bei mir aus Port 26 lauscht und den passenden FQDN hat, so dass er auch genau das eine offizielle Zertifikat nutzt. Natürlich muss ich manuell hier dann auch die Hybrid-Einrichtungen setzen.
Auf der Firewall habe ich dann eingehende Verbindungen von Exchange Online auf die öffentlichen IP-Adresse und Port 25 auf die interne IP-Adresse und Port 26 per ReverseNAT konfiguriert. Das ist aber nur eine Option.
- Selection of Inbound STARTTLS
Certificates
https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb430748(v=exchg.80) - Selection of Inbound Anonymous TLS
Certificates
https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2007/bb430790(v=exchg.80) - Assign certificates to Exchange Server
services
https://learn.microsoft.com/en-us/exchange/architecture/client-access/assign-certificates-to-services?view=exchserver-2019
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 On-Prem steht |
Extern |
EXO |
OnPrem |
|
Nur wenn On-Prem 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
- Office 365 Message Attribution - How does message
attribution work?
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
Weitere Links
- XOORG und Exchange
- X-OriginatorOrg
- HCW - Hybrid Configuration Wizard
- Receive Connector Zertifikate
- Office 365 Inbound Mailrouting
- Exchange Online Protection
- Microsoft Defender für Office 365 Plan 1 und Plan 2
- Sender Based Routing
- EXO Enhanced Filtering
-
Partner
Connector
Sonderbehandlung anhand IP-Adresse und/oder Zertifikat für gewisse Absenderdomains - Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143