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.

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

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:

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:

• X-OriginatorOrg
• XOORG und Exchange

Parameter

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

New-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

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

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

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=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.

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