Hybrid mit 3rdParty-Gateway

Diese Seite beschreibt einen Weg, wie Sie zwischen Exchange OnPremises und Exchange Online ein 3rdParty-Gateway schalten können, was nicht der "Exchange Edge Server" ist. Viele Firmen haben eine Security-Richtlinie, dass interne Server nicht direkt mit dem Internet sprechen dürfen, sondern immer ein Proxy oder Relay dazwischen stehen muss. Bei Exchange Hybrid ist dies naturgemäß der Exchange Edge-Server. Es gibt aber Firmen, die schon ein entsprechendes SMTP-Relay haben und nicht noch ein Edge-Cluster aufbauen und veröffentlichen wollen. Mit der Beschreibung auf dieser Seite haben Sie das Handwerkzeug, auch mit einem 3rd-Party SMTP-Relay eine Exchange Hybrid Bereitstellung einrichten zu können.

Microsoft-Beschreibung

Für eine klassische Hybrid Bereitstellung von Exchange OnPremises mit Exchange Online müssen die beiden Exchange Umgebungen entweder direkt miteinander kommunizieren.

Wenn Sie aber einen direkte Kommunikation interner Server mit dem Internet nicht erlauben und daher ein Relay in einer DMZ aufbauen wollen, dann müssen Sie offiziell einen Exchange Edge Server dafür installieren.

Ein Exchange Edge Server ist quasi ein Exchange Server, der nur dir Transport-Rolle betreibt und früher (Exchange 2007) sogar als Spamfilter bezeichnet wurde aber dieser Anforderung schon lange nicht mehr gerecht wird. Mittlerweile ist es ein relative dummes Relay mit eingeschränkten Rewrite-Möglichkeiten und ohne SPF noch DKIM-Funktionen. Zudem scheint es nur ganz wenige Administratoren oder Consultants zu geben, die den Edge und damit verbundenen EdgeSync mit all den Zertifikaten wirklich "kennen" und ich bin auch kein Freund des Exchange Edge-Servers.

Was spricht dann eigentlich dagegen, ein eigenes Relay zwischen Exchange OnPremises und Exchange Online in eine DMZ zu stellen, um auch diese Mails ausgefeilter zu analysieren?

Die Frage wurde mit in der Vergangenheit mehr als nur einmal gestellt.

Ist das erlaubt?

Da kommt natürlich immer die Frage auf, warum man kein 3rd Party Gateway dazu nutzen kann und die kurze Aussage von Microsoft ist.


Quelle: Transport Routing in Exchange hybrid deployments https://learn.microsoft.com/en-us/exchange/transport-routing

Lesen Sie bitte weiter, denn beim Commandlet "Inbound Connector" wird diese Aussage weiter abgeschwächt.

Das ist eine klare Aussage und natürlich hat Microsoft ein Interesse daran, dass die Kommunikation zwischen Exchange OnPremises und dem eigenen Exchange Online Tenant "Sicher" ist. Nicht umsonst nutzt Exchange dazu auf beiden Seiten Zertifikate, verschlüsselt die Verbindung per STARTTLS, weist sich per MTLS bei der Gegenseite aus und nutzt noch ein paar SMTP-Erweiterungen, wie z.B. XOORG.

Can someone spoof XOORG? The answer is “no”, the XOORG headers cannot be spoofed because it is the combination of the EOP TLS certificate, connector setting and accepted domain – and we control the headers when they pass through us, which is the case when our certificate is used.
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238

Ein empfangender Exchange OnPremises Server kann anhand dieses Felds unterscheiden, von welchem Tenant die Mails kommen. Sollte es uns aber anderweitig gelingen die Exchange Server davon zu überzeugen, dass die eingehende Verbindung vertrauenswürdig ist, dann könnte es ja doch gehen. Wie können wie unsere Exchange OnPremises und Online Server davon überzeugen, dass ein Header wie X-MS-Exchange-Organization-AuthAs übernommen bzw. richtig gesetzt wird?

Warnung

Die auf dieser Seite beschriebenen Details sind nicht von Microsoft abgesegnet und sicher nicht "Mainstream".

Die meisten Firmen und Hybrid-Umgebungen werden mit der Standardkonfiguration, welcher der HCW - Hybrid Configuration Wizard mit den  HCW Features&Topologien einrichtet, sehr gut fahren.

Der von Microsoft eingerichtete Hybrid-Mode sorgt hinsichtlich SMTP für zwei Funktionen:

  • Mail von ihrer Exchange OnPremises Umgebung zu ihrem Tenant sind "Intern"
    Dazu authentifiziert sich ihr lokaler Exchange Server über IP-Adresse oder Zertifikat gegen Exchange Online und Exchange Online nutz den Zertifikatsnamen oder die Absenderadresse zur Bestimmung des Tenants. Das ist bewährt und "Safe"
  • Mails von ihrem Exchange Online Tenants werden von Exchange OnPremises als "trusted" und "Intern" angesehen
    Dazu prüft Exchange OnPremises das eingehende Zertifikat (mail.protection.outlook.com) und die Domain bei XOORG und Exchange.

Allerdings verhindert die zweite Konfiguration nicht, dass auch ein anderer Tenant eine Mail über einen Partner-Connector an ihren OnPremises Server sendet. Die Mail ist dann zwar nicht "intern" aber der Spam und AV-Schutz von Exchange OnPremises ist ja nicht gerade berauschend. Siehe auch Hybrid Hintereingang

Deep Dive on Hybrid Mail Flow
https://www.youtube.com/watch?v=YvBU574SYvQ

OnPremises zu Exchange Online

Das kann man aber auch alle mit einem 3rd Party Gateway so konfigurieren. Wir müssen allerdings Exchange Online beibringen, dass die Mails vom OnPremises System "vertrauenswürdig" sind. Der HCW legt dazu normalerweise einen Inbound Connector vom Typ "OnPremises" an, in dem u.a. der Parameter "CloudServicesMailEnabled:$true". (Siehe auch AcceptCloudServicesMail und CloudServicesMailEnabled). Hier ein Beispiel:

PS C:\> Get-InboundConnector | fl name,*typ*,sender*,cloud*,treat*,enabled,*tls*

Name                     : Inbound from d03ff486-d465-498a-a28e-db307847e6cb
ConnectorType            : OnPremises
SenderIPAddresses        : {}
SenderDomains            : {smtp:*;1}
CloudServicesMailEnabled : True
TreatMessagesAsInternal  : False
Enabled                  : False
RequireTls               : True
TlsSenderCertificateName : hybrid.uclabor.de

Der HCW unterstützt offiziell keine 3rd Party Gateways und der Parameter "CloudServicesMailEnabled" ist für Exchange Hybrid reserviert und erwartet auf der anderen Seite einen Exchange OnPremises Server, der die von Exchange Online angebotenen eigenen SMTP-Verben und Erweiterungen unterstützt. (Siehe auch XOORG und Exchange). Diese erweiterten Funktionen stellen aber andere Mailserver und Relays nicht bereit. Aber sie wissen ja nun um die Funktion von "TreatMessagesAsInternal" und damit können sie auch einem anderen SMTP-Produkt die gleiche Berechtigung einräumen, die Exchange Online ansonsten nur Exchange OnPremises-Systemen zugesteht.

Unter Ziel ist, dass Exchange Online die Verbindung vom lokalen SMTP-Service so annimmt, dass es einem Hybrid-Routing entspricht oder zumindest sehr nahe kommt. Und dazu gehören folgende Dinge:

  • Richtige Attribution
    Die Mail muss natürlich dem richtigen Tenant zugeordnet werden. Der OnPremises-Connector nutzt dazu den Namen im Zertifikate mit der der lokale Mailserver seine Mail einliefert mit den Accepted Domains oder die IP-Adresse des Connectors und der Absenderdomain. Siehe auch OnPremises Connector Attribution. Das können wir auch mit einem 3rdParty-Gateway sicherstellen.
  • Als "Intern" ansehen
    Nun müssen wir Exchange Online noch beibringen, dass er die Mail als "intern" ansieht. Das schaffen wir mit dem Schalter TreatMessagesAsInternal auf dem Inbound-Connector in Exchange Online.
  • Erweiterte Header durchlassen
    Intern haben wie ja weiterhin einen Exchange OnPremises Server, der seine Mails auch mit den Headern versenden kann. Ich habe bislang noch nicht gesehen, dass Header abgeschnitten wurden, wenn die eingehende Mail durch einen OnPremises Inbound-Connector angenommen wurden
  • Keine Quarantäne/Spam/SPF
    Microsoft schreibt zum Commandlet "Set-InboundConnector", dass der Schalter TreatMessagesAsInternal den Exchange Online Spamfilter abschaltet, wenn die Absenderdomain aus den Accepted Domains kommt
  • XOORG-Verzicht
    Alle SMTP-Server machen nur dann XOORG, wenn nach einem EHLO und STARTTLS die Zielserver dieses Verb anbieten. Da meines Wissens kein 3rdParty-Gateway dies beim Empfang anbietet und beim Versand nutzt, stört es nicht auch nicht. Den Einfluss auf X-OriginatorOrg können wir daher ignorieren

Da so eine Konfiguration aber von Microsoft weder getestet noch dokumentiert ist, bewegen Sie sich natürlich schon etwas in einer Grauzone. Also machen wir eine kurze Risikoabschätzung, wenn Exchange Online die eingehende Verbindung nicht als "Intern" und "Vertrauenswürdig" ansieht. Es geht dabei ja nur um Mails, die von der eigenen Domain, d.h. von internen Absendern kommen. Mails aus dem Internet, die über eine OnPremises-Umgebung zu Exchange Online gehen und eine fremde Domain als Absender haben, werden nie als "Intern" klassifiziert.

  • SPF-Check
    Für ihre eigene Domain können Sie die IP-Adresse des 3rdParty-Gateway einfach mit aufnehmen. So wird Exchange Online immer ein SPF=PASS liefern, wenn es irrtümlich einen Spamcheck macht. Damit wird auch DKIM unwichtig und DMARC erfüllt
  • Spoofing
    Es könnte aber sein, dass Exchange Online die Absender als "Spoofing" ansieht und die Mail in die Quarantäne legt.
  • Quotas
    Ich kenne keine unterschiedlichen Grenzwerte bei der Anzahl an Mails, die abhängig vom Connector anstehen.

Vermutlich gibt es noch weitere Risiken und das größte Risiko ist eine Änderung der Funktionsweise durch Microsoft, die kurzfristig angekündigt wird und den Mailflow stört.

Hinweis:
Ich habe bei der Recherche auch Google und Co zum Thema "Hybrid mit 3rd Party Gateway" befragt und die Antworten haben alle beschrieben, wie man es einrichtet. Diese Anleitungen haben für einfache Fälle gestimmt aber keine ist auf das Feld "TreatMessagesAsInternal" eingegangen und damit waren die Anleitungen nicht komplett und nicht alle Fälle abgedeckt.

Exchange Online zu OnPremises

Kommen wir zum Schluss zur Gegenrichtung. Durch die Einrichtung von Exchange Hybrid wird ein "OnPremises Outbound Connector" in Exchange Online angelegt, der normalerweise als Scope alle "Accepted Domains" hat, und diese zu einem lokalen System sendet. Das Ziel kann eine IP-Adresse oder ein DNS-Namen sein und optional können wir TLS in unterschiedlichen Stufen erzwingen. Durch die Einstufung als "OnPremises"-Connector kommen einige Header mit später dem lokalen Exchange Server die korrekte Verarbeitung erleichtern.

Interessant wird es nun, was die lokale Gegenseite daraus macht. Sie kann zumindest kein XOORG anbieten, was ich aber nicht als Problem ansehe. Das 3rdParty-Gateway sollte natürlich ausreichend abgesichert sein, z.B. indem es nur Mails von Exchange Online (Zertifikat = mail.protection.outlook.com oder Source-IP) annimmt und TLS zumindest anbietet. Die Mail muss das 3rdParty-Gateway dann zum lokalen Exchange Server weiterleiten. Auch wenn der lokale Exchange Server ein XOORG anbietet, wird es das Relay vermutlich nicht nutzen. Exchange OnPremises kann daraus keinen Mehrwert ableiten.

Für die Klassifizierung als "Exchange Online" kommt aber das Zertifikat zum Einsatz. Der HCW legt lokal im Receive Connector den Namen des Zertifikats "mail.protection.outlook.com" im Feld "TlsDomainCapabilities". 

Das eigene 3rdParty-Gateway in meiner DMZ hat natürlich nicht das Microsoft-Zertifikat für "mail.protection.ooutlook.com". Das wäre nur möglich, wenn wir eingehende TCP-Verbindung von Microsoft z.B. per NAT direkt auf Exchange OnPremises weiterreichen würden. Aber die Problematik können wir dennoch auf eine von zwei Wegen lösen:

  • Eigener Name
    Ich kann nach jeder Ausführung des HCW einfach per Exchange PowerShell den Wert auf den Namen setzen, mit sich mein 3rdParty-Gateway an meinem Exchange OnPremises Server anmeldet. Das ist aber nicht perfekt, denn Microsoft könnte den Namen irgendwo im Code hinterlegt haben oder an die Konfiguration binden. Sie schreiben dazu etwas unscharf

Can someone spoof XOORG? The answer is “no”, the XOORG headers cannot be spoofed because it is the combination of the EOP TLS certificate, connector setting and accepted domain – and we control the headers when they pass through us, which is the case when our certificate is used.
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238

  • Zertifikat einer internen PKI
    Wenn Sie eine eigene PKI betreiben, können Sie Zertifikate mit einem beliebigen Namen ausstellen lassen, solange diese nicht extern erscheinen oder genutzt werden. Der lokale Exchange Server wird vermutlich sowieso schon der internen eigenen PKI ihres Unternehmens vertrauen. So könnte ihr 3rdParty-Gateway nach intern sich doch als "mail.protection.ooutlook.com" ausgeben, denn auch in 2025 hat Microsoft kein Zertifikat-Pinning o.ä. genutzt.

Mit einem dieser beiden Lösungen wird der lokale Exchange Server die eingehende Verbindung ihres 3rdParty-Gateways als "Vertrauenswürdiger CloudService" ansehen und die Mails und auch ggfls. vorhandene zusätzliche Header übernehmen. Allerdings gilt dies nicht für den Header X-OriginatorOrg, den Exchange OnPremises nur mitnimmt/setzt, wenn zwei Bedingungen passen:


Quelle: YouTube: Deep Dive: Increasing Mail Flow Security Posture https://youtu.be/AEsr737GFNg?t=1149
und YouTube: "Establishing Exchange Hybrid Mailflow" - https://youtu.be/1i_SO6nKe0o?t=751

Diese Anforderungen können wir nur erfüllen, wenn ihr 3rdParty-Gateway zum Exchange OnPremises Server ein EHLO absetzt und nach dem STARTTLS das "XOORG <ihredomain>" liefert. Wenn dies aber nicht möglich ist, habe ich bislang keine Probleme gesehen, denn der Spam-//Phishing-Schutz von Exchange OnPremises ist ja nicht wirklich vorhanden. Die Zustellung an ihre lokalen Benutzer sollte daher kein Problem sein.

Dennoch habe ich nach einen besseren Weg gesucht und mit einen "Receive Connector" angelegt. Als Remote-IP habe ich die IP-Adressen des Relay-Systems in der DMZ hinterlegt und unter "Sicherheit" haben ich auf "Extern gesichert" gestellt und die Checkbox bei "Exchange-Server" gesetzt.

Achtung:
Diese Einstellung ist gefährlich, denn jeder, der diesen Connector nutzen kann, wird von Exchange als "Server" angesehen und die Mails als "Intern" gekennzeichnet werden., d.h. kann auch die Relay-Funktion nutzen. Sie müssen sicherstellen, dass eingehende Mails von Exchange Online nur von ihrem Tenant kommen. Das 3rd-Party-Relay sollte dazu das Feld X-MS-Exchange-CrossTenant-Id auf ihre ID prüfen und die Zieladresse oder Absenderadresse muss von ihren eigenen Domain stammen. Exchange OnPremises kann dies ohne XOORG nicht prüfen!


Deep Dive on Hybrid Mail Flow https://youtu.be/YvBU574SYvQ?t=264

 

 

Bei Postfix können sie z.B. eine Test über die "Header_Checks" umsetzen. Wenn Postfix als Relay in einer DMZ steht und sie per Firewall (IP-Adresse, Zertifikat) z.B. sichergestellt haben, dass nur Exchange Online den Server erreichen kann UND nur Mails von ihrem Tenant den Weg nutzen dürfen, dann könnten Sie über Header_Checks alle Mails verwerfen, in denen die X-MS-Exchange-Tenant-Id nicht auf ihre GUID gesetzt ist.

# Anpassung in /etc/postfix/main.cf einfach
#
header_checks = regexp:/etc/postfix/header_checks
#
# Aktivieren imt "rcpostfix reload".

In der "header_checks"-Datei können Sie dann reguläre Ausdrücke nutzen, z.B.

!/^X-MS-Exchange-CrossTenant-Id: 12345678-123-1234-1234-1234567890AB/ 	REJECT

Interessanter ist aber, dass die Mails von extern über diesen Connector entsprechend klassifiziert wurden. Eine anonyme Testmail mit meiner Absenderadresse bei Net at Work per SMTP an ein lokales Postfach wurde als "Intern" klassifiziert. Das habe ich an drei Dingen erkannt:

  • Absender wurde aufgelöst
    Obwohl ich mit Send-Mailmessage eine einfache SMTP-Adresse eingeliefert habe, wurde der Displayname aufgelöst.

    Als Gegenprobe habe ich den gleichen Test noch einmal wiederholt, ohne dass "External gesichert" aktiviert war. dann wurde stattdessen die die SMTP-Adresse ausgegeben.
  • Interne OOF-Meldung
    Auf dem Testpostfach habe ich "Out Of Office" mit unterschiedlichen Texten für interne und externe Absender eingestellt. So konnte ich anhand der OOF-Rückmeldung ebenfalls sehen, dass die Mail "intern" war.
  • SMTP-Header
    Zuletzt hinterlegt Exchange die Information auch im Header in den Feldern X-MS-Exchange-Organization-AuthAs u.a. Hier stand bei mir dann auch intern.

Wenn ein Leser aber Idee hat, wie man z.B. ein Postfix dazu bringen kann, einfach an jedes "MAIL FROM: Absender" ein "XOORG=<meinedomain>" zu addieren, dann wäre das auch anders zu lösen.

Weitere Links