Hybrid Edge Falschrouting

Wenn Sie bei der Hybrid-Konfiguration etwas falsch anpassen, können Sie mit Exchange Edge Servern eine Loop produzieren.

Ausgangssituation

Ein Kunde hatte Exchange On Premises mit Exchange Online über Exchange Edge Server verbunden. Der HCW hat die komplette Konfiguration korrekt durchgeführt und im Grund hat schon alles funktioniert. Eine Konfiguration mit Exchange Edge Server ist etwas "besonders", denn die Connectoren werden auf den "inneren" Exchange Servern definiert und über den Edge-Sync Prozess zum Edge-Server übertragen. Die Connectoren sehen daher mit dem "--" als Adressraum etwas komisch aus. Der HCW richtet auf dem lokalen Server einen Send-Connector mit etwa folgender Konfiguration ein:

Name:               "Outbound to "<guid>"
Local Bridgehead:   "Edge1,Edge2"
Adressspace:        "<tenant>.mail.onmicrosoft.com
Zustellung:         MX Record
TLS-Zertifikat:     <DN und Aussteller des Client Zertifikats>

Die Konfiguration verrät den lokalen Transport-Rollen, dass Sie alle Mails an diese Domain an die beiden Edge Server senden müssen. Die beiden Edge Server haben die Konfiguration auch bekommen und damit auf ihrer Seite einen Send-Connector zur Exchange Online mit den gleichen Werten konfiguriert.

In die Gegenrichtung bekommen die Edge Server natürlich auch einen Send-Connector, der alle Mails an die internen Transport-Rollen weiterleitet. Der sieht mit seinem Addressspace etwas komisch aus, aber das ist normal (Siehe auch Exchange Edge Default Settings)

AddressSpaces                : {smtp:--;100}
DNSRoutingEnabled            : False
Name                         : EdgeSync - Inbound to <name>
Port                         : 25
SmartHostAuthMechanism       : ExchangeServer
SmartHosts                   : {--}
SmartHostsString             : --
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0

Eine Domain "--" gibt es natürlich nicht, aber für den Edge Server ist das der Hinweis, wie Mails von extern nach intern gesendet werden sollen. Welche Domains als "Intern" zählen, bekommt der Edge durch die "Accepted Domains" mit:

Note: By default, you can't configure a Send connector for an internal relay domain on a subscribed Edge Transport server. Messages sent to recipients in the internal relay domain are automatically forwarded to internal Mailbox servers in the subscribed Active Directory site by using the default "EdgeSync - Inbound to " Send connector. This Send connector is automatically configured to route mail for all authoritative domains and internal relay domains (the address space value is --)
Quelle: Accepted domains in Exchange Server - Relay Domains: https://learn.microsoft.com/en-us/exchange/mail-flow/accepted-domains/accepted-domains?view=exchserver-2019#relay-domains

Dass dies nicht immer so ist, habe ich auf Edge, Hybrid, ExternalDomain beschrieben.

Die "Smarthosts" mit dem Eintrag "--" bekommt er über die EdgeSubscription aus der zugewiesenen Exchange Site automatisch mit. Zudem müssen Sie auf dem Receive Connector des Edge Server natürlich auch noch die Konfiguration für "TlsDomainCapabilities" konfigurieren. Darauf weißt sie aber der HCW auch explizit hin.

Damit die Verbindung mit Exchange Online funktioniert, gibt es dort natürlich auch auch einen "Inbound Connector", der die Verbindungen von den Edge-Servern annehmen und ihre lokale Installation z.B. anhand des Zertifikats als "Organisation" erkennen. Für den Rückweg zur OnPremises Umgebung gibt es meist einen Connector der einfach alle Mails der "Accepted Domains" zum lokalen Server sendet.

So funktioniert dann auch das Exchange Routing:

  • Mails an Exchange Online werden nur angenommen, wen der Empfänger bekannt ist
    ADSync muss daher dafür sorgen, dass alle lokalen Empfänger auch in Exchange Online als Mailuser o.ä. bekannt sind und eine "TargetAddress/RemoteRoutingAddress" haben, die aber auf die primäre Adresse verweist. Exchange Online weiß aber, dass er daraus keine Loop macht, sondern die Mail anhand des SMTP-Routings nach extern senden muss. Hier kommt dann der Outbound-Connector  im Tenant zum Einsatz
  • Exchange OnPremises nimmt alles an aber braucht eine Weiterleitung
    Mails, die den lokalen Exchange Server erreichen werden entweder lokal zugestellt oder bei einer "RemoteMailbox" über das Feld "TargetAddress/RemoteRoutingAddress" an die <tenantname>.mail.onmicrosoft.com-Adresse weitergeleitet. Hier routet dann der OnPremises SendConnector die Mails über den Edge Server zur Cloud

Eigene Domain für Teams

Exchange Hybrid zeichnet sich nun dadurch aus, dass Sie die SMTP-Adressen und Domains zwischen zwei Exchange Organisationen, der lokalen Installation und Exchange Online, gemeinsam nutzen. Der ADSync-Prozess hat die Aufgabe, alle Exchange Empfänger aus dem lokalen System in die Cloud zu replizieren, damit diese dort erreichbar sind. Nun kann es natürlich auch Empfänger geben, die in der Cloud sind aber für die es lokal noch keine Objekte gibt.

Das sollte nie passieren aber ich wette, dass verschiedene Tenants dieses Problem haben. Ich gebe ihnen zwei Beispiele.

  • Cloud Only Empfänger
    Es passiert immer einmal, dass jemand einen Benutzer in der Cloud anlegt, den es im lokalen AD nicht gibt und daher von ADSync nicht repliziert wird und lokal auch keine "Remote Mailbox" ist. Das können z.B. externe Mitarbeiter sein, Gäste mit Postfach oder sie sind sowieso gerade bei der Migration zu "Exchange Online Only" oder haben eine andere Firma zugekauft und ersparen sich das lokale AD-Konto.
  • Teams und Office Groups, Verteiler
    Die zweite Empfängergruppe sind Verteiler, Teams und Office Groups, denen Sie eine Adresse aus ihrer registrierten Domain gegeben haben und natürlich auch erreichbar sein sollen. Wenn Sie aber kein "Groups Writeback" konfiguriert haben dann weiß auch hier das lokal Exchange nichts von diesen Empfänger.

In beiden Fällen kennt der lokale Exchange Server die Empfänger nicht und würde die Mails gar nicht annehmen. Exchange kennt aber einen Weg, dies zu umgehen, indem sie die Domain als "internal Relay" statt "Autoritativ" definieren und per Connector die Mails weiterleiten. Der Admin ändert die Konfiguration, um das Routing zu optimieren:

  • Accepted Domains:  Umstellung der <firma.tld> von Autoritativ auf Internal Relay
  • SendConnector zu Office 365:  Addieren von "firma.tld" als Domain
  • SendConnector zu Office 365: Zustellung von MX auf <tenant>-mail-onmicrosoft-com.mail.protection.outlook.com

Das Mailrouting funktioniert damit und alle Empfänger in der Cloud sind erreichbar.

Aus meiner Sicht ist dies natürlich eine Fehlkonfiguration, da der lokale Exchange nicht mehr sicher prüfen kann, ob ein Empfänger gültig ist und es zu Unzustellbarkeitsberichten kommen kann. Aber wer werfe den ersten Stein?

Fehlerbild

Das Problem fällt erst auf, wenn die erste Mails von Exchange Online an einen lokalen Empfänger gesendet wird. Dazu gibt es auch wieder zwei Szenarien:

  • MX Record über Exchange Online
    Wenn Sie mit ihrem lokalen Spamfilter nicht zufrieden sind, dann können Sie den MX-Record zu Exchange Online lenken und dort Werbung, Spam und Schadsoftware wegfiltern lassen. Exchange Online kennt alle Empfänger und kann entsprechend auch ungültige Empfänger gleich ablehnen.
  • Erste Mailbox in die Cloud migriert
    Der zweite Fall passiert, sobald sie z.B. bei einer Migration die erste Mailbox in die Cloud migriert haben. Die Person kann problemlos die anderen Empfänger in der Cloud erreichen und von allen anderen erreicht werden Sie kann aber keine Mails an lokale Postfächer senden.

Wenn Sie dann im Messagetracking nachschaue, dann sehen sie in Exchange Online sehr wohl, dass die Mail vom Postfach an den Transport übergeben wird und über den Outbound-Connector zum lokalen Edge-Server übertragen wird. Allerdings sehen Sie, dass die Mail wenige Sekunden später direkt wieder zum Exchange Online Server zurück gesendet wird. Das passiert 2-3 Mail bis die Mail dann in der Quarantäne hängen bleibt. Der Absender bekommt keine Unzustellbarkeit und der Empfänger hat keine Mail im Posteingang. Wenn Sie zusätzlich noch den Centralized Mail Transport aktiviert haben, dann betrifft dies auch alle Mails, die von der Cloud ins Internet versendet werden.

Aus dem Messagetracking geht ja hervor, zu welchem Edge-Server die Mail übertragen wurde. Der erfahrene Exchange Admin schaut als auf dem Edge Server nach der Mail und findet zwei Event:

RECEIVE
SENDEXTERNAL

Der erste Event berichtet über den Empfang von Exchange Online aber der zweite Event zeigt, das die Mail direkt wieder zu Exchange Online zurück gegangen ist. Warum dem so ist, sehen Sie mit einem "Get-SendConnector" dann sehr schnell:

Adressraum                        NextHop
-------------------------------   --------------------------------------------------------
<tenant>.mail.onmicrosoft.com     <tenant>-mail-onmicrosoft-com.mail.protection.outlook.com
<firma.tld>                       <tenant>-mail-onmicrosoft-com.mail.protection.outlook.com

Dadurch, dass Sie auf dem internen Send-Connector die Domain "<firma.tld" auf den Hybrid-Connector addiert haben, hast auch der Edge Server gelernt, dass die Domain "<firma.tld" in die Cloud geroutet wird.

Der Edge-Server ist nämlich kein Forwarder, der stumpf alle Mails von extern nach intern weiterleitet und interne Mails immer nach Extern sendet. Es ist eine vollwertige Transportrolle mit einer SMTP-Routingtabelle, die allerdings mittels EdgeSync von der internen Konfiguration gespeist wird.

Sie können auf dem Edge über eine lokale PowerShell sogar an EdgeSync vorbei eigene Send-Connectoren anlegen. Davon rate ich aber nachdrücklich ab.

In diesem Fall mussten wir also die Domain auf dem internen Connector entfernen und wohl oder übel alle Empfänger im Tenant, die eine lokal ebenfalls genutzte SMTP-Domain verwenden, im lokalen AD nachträglich anlegen.

Kein Problem ohne Edge

Das Problem passiert übrigens nicht, wenn Sie auf den Edge-Server verzichtet hätten, da dann die eingehenden Mails vom der internen Transport-Rolle angenommen und dann anhand der GAL zuerst an lokale Empfänger zugestellt würden. Wenn es den Empfänger aber im lokalen Exchange nicht gibt, dann würden wieder die Einstellungen der "Accepted Domain" und die SMTP-Routingtabelle herangezogen, um die Mail an das nächste System zu leiten.

Das Problem wäre auch mit dem Edge Server nicht aufgetreten, wenn die Konfiguration des Hybrid Connectors nicht um die zusätzliche Firmendomain erweitert worden wäre.

Das Beispiel zeigt aber wieder wieder gut, dass Sie besser an den Microsoft Standards bleiben sollten und das Identity Management mit ADSync eine der wichtigsten Funktionen im Exchange Hybrid Mode ist.

Ich bin weiter der Überzeugung, dass wir in der heutigen Zeit keinen Exchange Edge Server mehr benötigen, um Exchange OnPremises vor den Gefahren des Internets und für eine Kopplung mit einem Exchange Online Tenant brauchen, wenn ihre Firewall gut die Source-IP-Adressen der Cloud erlauben kann und Sie einen vorgeschalteten Spamfilter als Schutz gegen unerwünschte Mails aus dem restlichen Internet haben.

Weitere Links