Kein Mailversand zwischen Office365 und Exchange 2016 im Hybrid-Modus möglich

Wer neben einer lokalen Infrastruktur noch auf die Vorteile von Office365 zurückgreifen möchte, der kommt am Exchange Hybrid-Modus nicht vorbei. Bei einem Hybrid-Betrieb wird die lokale Infrastruktur mit der Microsoft Online-Infrastruktur verbunden. So hat man die freie Wahl, wo ein Postfach liegt und wie schnell oder langsam man eine Migration in Richtung Office365 durchführen möchte.

Infos zum Betrieb

Ich gehe an dieser Stelle nicht näher auf die Einrichtung des Hybrid-Modus ein, sondern primär auf die Einstellungen und Probleme, die ich bei der Einrichtung gefunden habe. Da der Assistent einige Einstellungen selbst konfiguriert und diese nicht direkt nutzbar waren, musste ich an der ein oder anderen Stelle noch drehen, bis letztendlich die gesamte Kommunikation funktionierte.

Anbindung von außen

Die lokale Exchange-Infrastruktur ist nicht direkt per WAN erreichbar, sondern kann nur über eine Appliance / Reverse Proxy erreicht werden. Dies führt zu einer erhöhten Sicherheit im Betrieb, da in der Appliance nur gezielt IP-Adressen freigegeben werden können. Eine Liste der von Microsoft genutzten IP-Adressen und Namen ist hier zu finden:

Office 365 URLs and IP address ranges

Die Liste war sehr hilfreich, da nur genau diese Adressbereiche freigeschaltet werden konnten, und nicht von überall auf das System zugegriffen werden kann.

Zentraler Emailversand

In meinem Fall wird der Centralized Mail Transport genutzt. Dies bedeutet, dass alle Emails über die lokale Infrastruktur geroutet werden. Dies ist notwendig, damit Signaturen angefügt werden und die Emails im Log auftauchen. Hierbei habe ich festgestellt, dass selbst ein Versand von Emails “aus dem Internet” (also einer fremden Domain) an die onmicrosoft-Adresse nicht direkt zugestellt werden, sondern die Emails erst an die lokale Infrastruktur gesendet werden, bevor dann eine Zustellung zum Office365-Postfach stattfindet. Mehr Infos dazu auf Franks Seite MSXFAQ (Schönen Gruß an dieser Stelle).

Versand von Mails von Office365 an fremde Domains

Wird der Centralized Mail Transport genutzt, werden ausgehende Emails von einem Office365-Konto über den lokalen Exchange an die Außenwelt verschickt. Dies funktionierte mit internen Adressen sehr gut, nur Emails an externe Domains klappte nicht, es erschien sofort eine Fehlermeldung.

In der Fehlermeldung können wir sehr gut erkennen, dass der in der Mitte aufgeführte Mailserver (einer der internen Server) die Emails nicht weiterleitet, weil er laut Regelwerk kein Relay für externe Domains macht. Der Konnektor in der lokalen Infrastruktur, der die Mails vom Office365 annimmt, muss ein Relay erlauben, da sonst nur interne Domains funktionieren. Die beste Beschreibung dazu habe ich bei Frank Zöchling gefunden (schönen Gruß ebenfalls 🙂 )
Exchange Server: Mailspoofing verhindern

Nachdem der Konnektor angepasst war, wurden auch Emails an externe Adressen erfolgreich versandt.

Kommunikation zwischen lokal und Office365

Ich habe recht schnell feststellen müssen, dass der Versand von Emails an Office365-Konten nicht funktioniert, die Emails blieben “irgendwo” auf der Strecke. Also die üblichen Verdächtigen geprüft:

  • Blockt die Firewall die Kommunikation?
  • Funktioniert DNS?
  • Nimmt der Office365 Server Emails von meinem Server an?
  • Kann ich per Telnet Emails simulieren?

All diese Fragen konnte ich klären, es war weder die Firewall noch die anderen Punkte. Im nächsten Schritt habe ich mit dann über die Exchange Toolbox auf dem betroffenen Server die Mail-Warteschlange angeschaut.

Hier waren alle Emails enthalten, die ich testweise versendet habe und die bisher nicht angekommen sind. Die Fehlermeldung lautete

Damit ich noch mehr, macht vermutlich ein detailliertes Logging auf dem entsprechenden Konnektor Sinn. Also schnell das Logging auf dem Sendekonnektor aktiviert und im Log geschaut.

Nach kurzer Zeit erschienen die ersten Logdateien, zu finden sind die standardmäßig unter

Im Log habe ich dann sehr schnell die folgenden Zeilen gefunden (Tipp: Suchen nach dem Namen des Konnektors, in meinem Fall “Outbound to Office 365”)

 

In der vorletzten Zeile findet sich jeweils pro Email eine sehr wichtige Information:

TLS negotiation failed with error UnknownCredentials

Wenn man sich nun alle Informationen anschaut, sieht man im Logfile (grün markiert) sehr gut, dass hier ein Fingerprint von einem Zertifikat steht. Wenn wir nun auf einem der Exchange Server per PowerShell ein

ausführen, können wir hier alle verfügbaren Zertifikate sehen. In meinem Fall war dem Zertifikat mit dem Fingerprint 2D21517CD71AA9FE85B27A5D6738A4172A543312 kein Dienst zugeordnet, d.h. dieses Zertifikat durfte nicht für den Versand von SMTP Nachrichten genutzt werden. Nachdem ich nun per PowerShell den Befehl

abgesetzt habe (Wichtig: Die Frage nach dem ersetzen von dem aktuellen Zertifikat mit NEIN beantworten!), ging auch ein Versand der Emails.

Interessante Beobachtung am Rande: Auch nach der Aktivierung von SMTP für das Zertifikat tauchte SMTP nicht als Dienst für das Zertifikat auf. Ich weiß nicht ob das ein Problem mit der genutzten Exchange CU-Version ist oder ein generelles Verhalten, aber durch das Schreiben von diesem Artikel habe ich den Get-ExchangeCertificate-Befehl erneut ausgeführt und gesehen, dass kein SMTP als Dienst vermerkt ist. Es funktioniert aber trotzdem. Technik…

Jan

Jan Kappen arbeitet sein 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Seit September 2018 ist Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.