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
451 4.4.0 Primary target IP address responded with: "421 4.4.1 connection timed out"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
%ExchangeInstallationsPfad% -> TransportRoles -> Logs -> Hub -> ProtocolLog -> SmtpSendIm Log habe ich dann sehr schnell die folgenden Zeilen gefunden (Tipp: Suchen nach dem Namen des Konnektors, in meinem Fall “Outbound to Office 365”)
2019-05-28T15:07:00.088Z,Outbound to Office 365,08D6DB768B3F8C32,0,,104.47.5.36:25,*,SendRoutingHeaders,Set Session Permissions 2019-05-28T15:07:00.088Z,Outbound to Office 365,08D6DB768B3F8C32,1,,104.47.5.36:25,*,,attempting to connect 2019-05-28T15:07:00.135Z,Outbound to Office 365,08D6DB768B3F8C32,2,<IP_Exchange>:53638,104.47.5.36:25,+,, 2019-05-28T15:07:00.228Z,Outbound to Office 365,08D6DB768B3F8C32,3,<IP_Exchange>:53638,104.47.5.36:25,<,"220 <Servername>.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 28 May 2019 15:06:59 +0000", 2019-05-28T15:07:00.228Z,Outbound to Office 365,08D6DB768B3F8C32,4,<IP_Exchange>:53638,104.47.5.36:25,>,EHLO <Exchange_WAN_Name>, 2019-05-28T15:07:00.275Z,Outbound to Office 365,08D6DB768B3F8C32,5,<IP_Exchange>:53638,104.47.5.36:25,<,250 <Servername>.mail.protection.outlook.com Hello [<Public_IP>] SIZE 157286400 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS 8BITMIME BINARYMIME CHUNKING SMTPUTF8, 2019-05-28T15:07:00.275Z,Outbound to Office 365,08D6DB768B3F8C32,6,<IP_Exchange>:53638,104.47.5.36:25,>,STARTTLS, 2019-05-28T15:07:00.321Z,Outbound to Office 365,08D6DB768B3F8C32,7,<IP_Exchange>:53638,104.47.5.36:25,<,220 2.0.0 SMTP server ready, 2019-05-28T15:07:00.321Z,Outbound to Office 365,08D6DB768B3F8C32,8,<IP_Exchange>:53638,104.47.5.36:25,*," CN=*.domain.tld, OU=IT, O=FIRMA, STREET=STRASSE, L=ORT, S=NRW, PostalCode=11111, C=DE CN=COMODO RSA Organization Validation Secure Server CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB 00ED5D8C39E38780CCE126F2C923354D1D 2D21517CD71AA9FE85B27A5D6738A4172A543312 2018-06-08T02:00:00.000Z 2020-09-06T01:59:59.000Z *.domain.tld;domain.tld",Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names 2019-05-28T15:07:00.326Z,Outbound to Office 365,08D6DB768B3F8C32,9,<IP_Exchange>:53638,104.47.5.36:25,*,,TLS negotiation failed with error UnknownCredentials 2019-05-28T15:07:00.326Z,Outbound to Office 365,08D6DB768B3F8C32,10,<IP_Exchange>:53638,104.47.5.36:25,-,,Local
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
Get-ExchangeCertificateausfü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
Enable-ExchangeCertificate -ThumbPrint "2D21517CD71AA9FE85B27A5D6738A4172A543312" -Services SMTPabgesetzt 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…
