Exchange Online mit Wildcard-Zertifikat
Ich möchte auf dieser Seite einen Sonderfall eine Fehlkonfiguration mit Exchange Hybrid vorstellen, die gar nicht so selten vorkommen dürfte. Sie hat etwas mit dem eingesetzten SMTP-Zertifikate zu tun aber zeigt auch die Bedeutung der Spamfilter und SPF/DKIM/DMARC-Records.
Fehlerbild
Wie so oft beginnt es damit, dass ein Anwender der eigenen Firma einen externen Empfänger erreichen will und die Mail aber nicht ankommt. Der Spamfilter der Gegenseite lehnt die Mail und der Anwender macht ein Helpdesk-Ticket auf. Die Umgebung ist eigentlich recht schnell erklärt und dürfte bei vielen Firmen zumindest noch eine Weile so aussehen:
- Exchange Hybrid
Die parallele Bereitstellung von Exchange Servern im eigenen LAN und Postfächern in Exchange Online ist bei vielen Firmen Standard, gerade wenn Sie noch am Anfang ihrer Exchange Hybrid Migration stehen. - Eigener Spamfilter
Wenn Sie mit EOP nicht zufrieden sind oder Zusatzfunktionen wie Disclaimer, Archiv, Compliance, SMIME/PGP etc. haben, dann betreiben Sie einen eigenen SMTP-Service, der auch Mails ins Internet sendet. - Optional
Hybrid Centralized Mail Transport
Ob ihre Exchange Online Absender nun die Mails selbst versenden oder über Centralized Mailrouting gehen, ist für das später aufgezeigte Fehlerbild irrelevant.
Ein Bild macht die Zusammenhänge einfacher verständlich:
In dieser Umgebung sendet nun ein Anwender der lokalen Exchange Umgebung "msxfaq.de" (1) eine Mail an einen Empfänger in "UCLABOR:DE", deren MX-Record nach Exchange Online Protection verweist. Über einen Send-Connector im lokalen Exchange Server werden nun alle Mails zum vorgelagerten Spamfilter gesendet, der dann über DNS den Mailserver des Empfängers findet und die Mail zustellt.
Das hat nicht funktioniert und daher hat der Exchange Admin sein Messagtracking bemüht.
- Exchange On-Premises
Natürlich konnte er anhand des Absenders die Mai finden und die Nachverfügung zeigte, dass Exchange die Mail mit einem "250 OK" an den Spamfilter übertragen hat - Spamfilter
Das nächste Tracking im Spamfilter zeigte ebenfalls, dass dieser die Zieldomains per DNS aufgelöst und die Nachricht an "uclabor-de.mail.protection.outlook.com:25" zugestellt hat und die Verbindung per TLS verschlüsselt hat. Exchange Online hat die Mail angekommen aber einige Sekunden später kam dann eine Unzustellbarkeit von Exchange Online zurück - Exchange Online Tracking
Da die Fehlermeldung aus Exchange Online gekommen ist, haben wir auch im Tenant gesucht und sind dort fündig geworden. Die ausgehende Mail konnte auch im Exchange Online nachgetrackt werden und der NDR wurde ebenso sichtbar.
Jetzt könnten Sie ja auf den Gedanken kommen, das Microsoft in Exchange Online ein riesiges globales Messagetracking macht und ich als Admin von "msxfaq.de" bei einer Suche nach eigenen Mails auch den Pfad in einem anderen Tenant finden kann. Das ist aber ein Irrglaube.
Routing Beschreibung
Die Tatsache, dass wir die eigene ausgehende Mail auch in Exchange Online Tracken konnten, ist ein eindeutiges Zeichen, dass die Mails durch den eigenen Tenant gelaufen ist. Wir haben uns dann noch mal die komplette Hybrid-Bereitstellung durch den HCW angeschaut und keinen Fehler finden können. Auch der Spamfilter hat nichts falsch gemacht.
Das Fehlerbild ist aber sichtbar geworden, als wir uns die Zertifikate angeschaut haben. Der HCW erfragt ja bei der Einrichtung, wie Sie die Exchange On-Premises-Umgebung gegen die Cloud authentifiziert. Das kann man per SourceIP-Adresse machen. Üblich ist aber ein Zertifikat, denn IP-Adressen können sich ändern und gerade hinter einer Firewall mit NAT könnten sich ja auch andere Systeme mit der gleichen IP-Adresse am Tenant melden und damit einen nicht erlaubten Vertrauensvorschuss bekommen.
Zertifikate sind aber immer noch ein "kniffliges Thema" bei vielen Firmen und öffentlichen Zertifikate kosten auch noch Geld. Auch wenn es eigentlich unsicherer ist verwenden Administratoren daher gerne ein "Wirdcard-Zertifikat", um nicht für jeden Namen einen eigenen Request-Prozess zu durchlaufen. So war es auch hier, dass sowohl der Exchange Server als auch der Spamfilter sich das gleiche Zertifikat geteilt haben.
Wenn Sie aber das Bild noch einmal genaue anschauen, dann sollte ihnen das Fehlverhalten aber direkt auffallen. Die vom On-Premises Benutzer (1) gesendete Mail wird vom SpamFilter (2) über den MX-Record für "uclabor.de" natürlich auf den Host "uclabor-de.mail.protection.outlook.com:25" zugestellt. Wenn aber nun beide Firmen in der gleiche geografischen Region sind, dann verweisen beide MX-Records auf die gleichen Server, obwohl sie natürlich unterschiedliche Namen haben.
Exchange Online ist aber eine "Shared Hosting"-Installation und muss nun entscheiden, wie es die eingehende Verbindung bewertet. Es kann ja durchaus sein, dass es mehrere Tenants mit den gleichen Einstellungen bei "Inbound Connectoren" gibt. Exchange Online nutzt daher eine Kombination aus SourceIP, Client-Zertifikat, Absender Domain und Zieldomain, um den passenden Tenant und da drin den zutreffenden Connector zu bestimmen.
Der HCW nutzt bevorzugt ein Zertifikat mit MTLS zur Bestimmung der Gegenseite und so legt der HCW in Exchange Online einen "Inbound Connector" an, in dem der Name des verwendeten Zertifikats hinterlegt ist. Der Mailserver kann sich nun z.B. mit einem "EHLO exchangeonpremserver.msxfaq.de" melden, was ExchangeOnline aber nicht auswertet. Aber mit dem STARTTLS sendet nicht nur Exchange Online sein Zertifikat sondern auch der On-Premises-Exchange sendet sein Zertifikat. Exchange Online wertet nun die Namen im Zertifikat aus.
Da in dem Beispiel aber sowohl Hybrid-Mails vom lokalen Exchange Server zum eigenen Tenant aber auch per MX-Record versendeten Mails per Zertifikat abgesichert werden, kann Exchange Online die beiden Ausgänge der Firmen nicht genau unterscheiden. Auch die MAIL FROM-Adresse nicht hinreichend, denn Sie ist in beiden Fällen ja "msxfaq.de". Die RCPT TO-Adresse kommt aber hier nicht mehr zum Einsatz, wenn es im eigenen Tenant einen "Inbound Connector" mit der Einstellungen "Vom Server der Organisation" gibt. Dann geht Exchange Online davon aus, dass die On-Premises-Umgebung die Mails "über die Cloud" ins Internet sendet. In dem Beispiel verwenden sowohl der On-Premises Exchange Server aber auch der normale "Mailversandserver" das gleiche Zertifikat und die Mail, die eigentlich an einen anderen Tenant gehen sollte, landet erst einmal im eigenen Tenant. Der Weg ist daher:
- Neue Mail vom On-Premises Exchange Anwender wird erstellt
- Die Mail landen über den Send Connector beim ausgehenden Spamfilter
- (b) Der Spamfilter sendet die Mail zu Office aber wird dem eigenen Tenant zugeordnet
- Der eigene Tenant will die Mail per MX-Record zum Ziel-Tenant senden. Der lehnt aber ab
- Der eigene Tenant erstellt einen NDR und sendet ihn per Hybrid-Connector zum Postfach
Der Versand vom eigenen Tenant zum Zieltenant kann aus verschiedenen Gründen fehlschlagen, z.B. weil Sie vergessen haben, Exchange Online mit ihn den SPF ihrer Domain aufzunehmen oder weil der Geschäftspartner einen Partner-Connector angelegt hat, der nur direkte Mails vom On-Premises-System erwartet. Der genaue Grund trägt hier auch nichts zu eigentlichen Thematik bei.
Testfälle
Wenn Sie daher an ihren Connectoren herum schrauben, Zertifikate tauschen, IP-Adressen wechseln oder das Routing mit Transportregeln oder DNS-Einträgen und Smarthosts beeinflussen, dann sollten Sie möglichst alle Testfälle mit entsprechenden Postfächern durchspielen. Die ersten vier Sender und Empfänger in dem Bild sind noch schnell aufgelistet
- Firmenpostfach in ExchangeOnPrem (useronprem@msxfaq.de)
- Firmenpostfach in Exchange Online (useronline@msxfaq.de)
- Fremdes Postfach im Internet oder
Exchange Online (MX-Record)
Wenn die andere Firma in Exchange Online ist, sollten Sie diesen Sonderfall nochmal genauer betrachten.
Sie sollten daher Mails zwischen den drei Partnern in beide Richtungen senden und tracken. Das sind schon sechs Testnachrichten allein bei den Basis-Tests
Wenn Sie aber denken, damit alle Sender und Empfänger erwischt zu haben, dann denken Sie mal an die Sonderfälle in Exchange Online, die Sie gerne übersehen aber durch eigene Domains auffallen wie:
- Eingehende "Azure VoiceMails" an ihre
Firmenpostfächer
Wer die Sprachmailbox in der Cloud nutzt, bekommt verpasste Anrufe per SMTP-Mail in sein Postfach zugestellt. - Eingehende "Benachrichtigungen", z.B.
von Teams, SharePoint, Yammer, Delve, Viva
an ihre Firmenpostfächer
Auch diese Absender kommen mit "teams.microsoft.com" und anderen Adressen und werden bei Transportregeln gerne vergessen - Mails von und an "<tenantname>.onmicrosoft.com"
und "<tenantname>.mail.onmicrosoft.com"-Adressen
Für diese Domains können Sie als Administrator den MX-Record nicht beeinflussen, d.h. Mails an diese Adressen gehen immer per MX-Record direkt an die Cloud. Das betrifft z.B. Microsoft 365 Groups und damit auch Microsoft Teams.
Ich habe sogar schon Tenants gesehen, die trotz Exchange Hybrid eigene "Cloud-Only"-Benutzer mit einem Postfach und einer "onmicrosoft.com"-Adresse angelegt haben und sich dann natürlich über "suspekte" Routings gewundert haben. Mails an lokale Postfächer liefen dann durch den Hybrid Connector aber der Rückweg wurde wieder über das Internet geroutet, da der Hybrid-Connector per Default nur ein Routing für "<tenant>.mail.onmicrosoft.com" und nicht "<tenant>.onmicrosoft.com" enthält.
Zusammenfassung
Der Betrieb von Exchange Online und Exchange Hybrid kennt neben dem normalen Betriebsarten sehr viele Fallstricke, die zu unerwarteten Ergebnissen bei der Zustellung, beim Empfang oder Weiterverarbeitung von Nachrichten führen können. Gerade die Konfiguration von Connectoren und Zertifikaten aber auch die Arbeit mit Transportregeln, Siehe Centralized Mailrouting Multiforest, sind nicht immer einfach vorherzusehen. Daher sind zwei Grundtätigkeiten bei der Konfiguration wichtig.
- Verstehen
Sie müssen wissen, was Sie erreichen wollen und wie die verschiedenen Komponenten, speziell Exchange Online, funktionieren und entscheiden. Es wird auch Konstellationen geben, die nicht oder nur mit bestimmten Voraussetzungen möglich sind. Ich denke da insbesondere an DKIM-Signaturen und DMARC, was in Zukunft noch viel wichtiger wird.
Für die Konfiguration der Hybrid-Connectoren sollten Sie zur Sicherheit einen eigenen Namen mit exklusiven Zertifikat vorsehen, damit Exchange Online genau eine Verbindung zu ihrem Tenant zuweisen kann. - Testen/Monitoring
Speziell wenn sie keine parallele Test-Umgebung haben, dann sollten Sie nach den Änderungen alle Fälle ausführlich testen. Da Änderungen in Exchange durchaus durch Replikation und Caching verzögert sein können, sind die Tests auch nach einiger Zeit noch einmal zu wiederholen.
Auch bestimmte Kennzahlen wie z.B. "Anzahl der NDRs pro Zeiteinheit" oder "erkannte Dubletten" - KISS - Keep it simple stupid
Wie das hier vorgestellte Beispiel zeigt, gehört dazu gerade nicht die Vereinfachung durch den Einsatz von Wildcard- oder SAN-Zertifikaten. Der "Hybrid Connector" für den Nachrichtenfluss zwischen ihrer lokalen Exchange Umgebung sollte immer einen eigenen DNS-Namen mit dazugehörigem Zertifikat haben. Es sollte zumindest keine Übereinstimmung mit ihrem normalen Mailversand geben
Ich hoffe, diese Seite mit einem speziellen Problem beim Routing von Mails an andere Office 365 Tenants hat ihnen beim Verständnis und beim Vermeiden von Fehlkonfigurationen im eigenen Tenant geholfen. Sie sollten jedenfalls alarmiert sein, wenn Sie im Exchange Messagtracking ihres eigenen Tenant entsprechende Nachrichten finden, die sie dort nicht erwarten.