Hallo zusammen,
ich befinde mich derzeit in einer Hybridumstellung und versuche einen Exchange 2019 mit Microsoft 365 zu verbinden. Der Hybridwizard wurde auch erfolgreich durchlaufen und ADSync mit AzureAD (bzw. Entra) funktioniert auch.
Sobald nun allerdings ein Postfach via Exchange-Online Migration (Remote-Verschiebeoperation) in die Cloud gehoben wird, ist dieses Postfach für den Empfang neuer Mails unerreichbar. Der Versand von Mails funktioniert problemlos.
Nach diversen Recherchen konnte ich das Problem (wahrscheinlich) auf den Sende-Connector eingrenzen. Die zugehörige Queue für <domain>.mail.onmicrosoft.com steht still mit folgendem Fehler:
LED=451 4.4.395 Target host responded with error. -> 454 4.7.5 Certificate
validation failure, Reason:SubjectMismatch};{MSG=};{FQDN=<domain>-mail-onmicrosoft-com
.mail.protection.outlook.com
ich hab bereits probiert das TLS-Zertifikat neu zu setzen, jedoch ohne Erfolg. Aus Verzweiflung habe ich sogar den Inbound Connector im Exchange-Online umgestellt, aber auch hier ohne Erfolg.
Hat jemand eine Idee wie ich das Problem lösen kann und die Remote-Mailbox weiterhin mit Mails versorgen kann?
Vielen Dank für die Hilfe!
Sascha
Welche Firewall steht denn zwischen deinem Exchange und ExO? Irgendwas was den SMTP Traffic "manipuliert"?
Wobei subjectMisMatch ja eigentlich eindeutig ist. Es wird ein Host mit dem falschen (nicht erwarteten) Zertifikat erreicht.
Zwischen dem Ex und ExO ist eine Sophos UTM.
SMTP wird nur durchgeschleift, aber nicht verändert.
Im Send-Connector ist das TLS Zertifikat vom Exchange (ein Wildcard Zertifikat der Domain) hinterlegt.
Der Inbound Connector im ExO erwartet ebenfalls laut Einstellung das Wildcard-Zertifikat.
Daher kann ich mir das mismatch auf „<domain>-mail-microsoft-com.mail.protection.outlook.com nicht erklären und stehe auf dem Schlauch.
Genau, das Zertifikat im OnPrem-Send-Connector muß zum Zertifikat im EXO-Inbound-Connector passen.
Außerdem muß der FQDN des OnPrem-Send-Connectors dazu passen. Diesen findest du im GUI bei den Eigenschaften des Send-Connector - scoping - FQDN.
Überprüfen kannst du das Ganze, indem du für den Send-Connector das Logging aktivierst und dann ins ausgehende SMTP-Log schaust. Dort siehst du, mit welchem Namen sich der Server tatsächlich meldet und welche Zertifikate vorgezeigt werden.
Fehler wurde im Zusammenhang mit der Firewall gefunden!
Im Default Send-Connector war die Sophos Firewall als SmartHost eingetragen, sobald dieser SmartHost ebenfalls im Send-Connector für die Verbindung zum ExO eingetragen wurde sind die Mails durchgegangen.
Dennoch verwirrend das die Queue als Fehler ein SubjectMismatch im Zertifikat anzeigt, anscheinend zerpflückt die Firewall doch die SMTP Verbindung und ersetzt das TLS.
Danke für die Hilfe und falls noch jemand eine Erklärung für dieses Phänomen hat -> sehr gerne! :)
Im Default Send-Connector war die Sophos Firewall als SmartHost eingetragen, sobald dieser SmartHost ebenfalls im Send-Connector für die Verbindung zum ExO eingetragen wurde sind die Mails durchgegangen.
Nur als Hinweis (falls ich das oben falsch verstanden haben sollte, dann ignorieren):
https://learn.microsoft.com/de-de/exchange/transport-routing
Platzieren Sie keine Server, Dienste oder Geräte zwischen Ihren lokalen Exchange-Servern und Microsoft 365 oder Office 365, die SMTP-Datenverkehr verarbeiten oder ändern. Sicherer E-Mail-Fluss zwischen Ihrer lokalen Exchange-Organisation und Microsoft 365 oder Office 365 hängt von Informationen ab, die in Nachrichten enthalten sind, die zwischen der Organisation gesendet werden. Firewalls, die SMTP-Datenverkehr über TCP-Port 25 ohne Änderung zulassen, werden unterstützt.