OrganizationConnector

Auf dieser Seite möchte ich genauer auf den Exchange Online Inbound Connector von der eigenen Organisation eingehen, den der Hybrid Configuration Wizard in der Regel anlegt. Nach dieser Seite könnte OrganizationConnector Attribution weiter interessant sein.

Internet-, Partner- und OrganizationConnector

Der Versand und Empfang von Mails wird in Exchange Online über Connectoren konfiguriert. Ein neuer Tenant hat keine Connectoren, so dass die Standardeinstellungen zum tragen kommen

  • Versand über MX
    Jeder Tenant ohne Connector hat quasi einen Default Connector, der Mails per MX-Record von Postfächern des Tenants versendet.
  • Empfang per MX
    Zudem nimmt ein Tenant Mails an, bei denen die Empfängeradresse (Envelope-To, RCPT TO, P1-To, RFC5281-To) eine Domain hat, die im Tenant als Domain registriert ist. Natürlich gibt es hier einen einfachen Spamfilter.

Für die Anbindung von Partnern können Sie entsprechende Partner Connectoren konfigurieren, mit denen sie eingehend Mails von bestimmten Absenderdomains z.B. auf bestimmte Quell-IP-Adressen oder MTLS-Zertifikate beschränken oder ausgehend für bestimmte Empfängerdomänen z.B. TLS-Verschlüsselung oder Smarthosts erzwingen. Dabei werden Connectoren zum Versand und Empfang unabhängig voneinander konfiguriert.

Exchange Online versucht zuallererst zu ermitteln, ob eine Mail als "Originating" oder "Incoming" gewertet wird. "Originating" bedeutet, dass die Mail von einem Absender in ihrer Firma, d.h. entweder ein Exchange OnPremises oder ein Exchange Online-Postfach, ist. Eine Mail über einen Partner-Connector kann nie als "Originating" klassifiziert werden.

Einrichtung durch HCW

Sobald Sie Exchange Hybrid nutzen, wollen Sie eine enge Verbindung zwischen ihrem lokalen Exchange Server und ihrem Exchange Online Tenant herstellen, damit z.B. die Mails immer verschlüsselt sind, automatische Weiterleitungen intern möglich sind und die Absender als "vertrauenswürdig" eingestuft werden. Dazu ist es erforderlich, dass Exchange z.B. gewisse Header in der Mail nicht entfernt, was er bei anonym eingelieferten Mails ansonsten tut.

Der "Organization Connector" erlaubt aber noch mehr, z.B.

  • Eingehendes Routing Internet -> EXO -> OnPremises
    Exchange OnPremises vertraut soweit ihrem, und nur ihrem, Tenant, dass auch Mails von extern angenommen werden, obwohl z.B. ein SPF-Check nicht erfolgreich sein kann
  • Eingehendes Routing Internet -> OnPremises -> EXO
    Sie können auch Mails über ihre lokalen Server an ihren Exchange Online Tenant routen ,ohne dass der Spamfilter von Exchange Online sich beschwert
  • Ausgehendes Routing EXO -> OnPremise -> Internet
    In dem Fall muss ihr Exchange OnPremises ihrem Tenant, und nur ihrem Tenant, vertrauen, dass es quasi ein Relay darstellt ohne ein offenes Relay zu sein
  • Ausgehendes Routing OnPremise -> EXO -> Internet
    Genauso gut können Sie ihren Exchange Server hinter Exchange Online verstecken und so z.B. die DKIM-Signatur von Exchange Online nutzen.
  • Internes Routing
    Natürlich sollten wir die sichere und fehlerfreie Kommunikation zwischen ihrem, und nur ihrem, Tenant mit ihrer OnPremises Umgebung nicht vergessen.

Der Organization Connector gibt es daher vier mal:

  • Lokal: SendConnector- von Exchange OnPrem zu Exchange Online
  • Cloud: InboundConnector- von Exchange OnPrem zu Exchange Online
  • Cloud: OutboundConnector von Exchange Online zu Exchange OnPrem
  • Lokal:  ReceiveConnector von Exchange Online zu Exchange OnPrem

Nur gut, dass in den meisten Firmen der HCW - Hybrid Configuration Wizard die Konfiguration aller vier Einstellungen übernimmt und Sie damit kein Problem haben sollten. In Exchange Online finden Sie dann die beiden Connectoren.

Auf der OnPremises-Seite finden Sie sichtbar aber nur den "SendConnector" zur Cloud. Die Konfiguration für den Empfang ist etwas versteckt und nicht im Exchange Admin Center zu sehen. Auf dem ReceiveConnector "Default Frontend <servername> wird einzig das Feld "TlsDomainCapabilities : {mail.protection.outlook.com:AcceptCloudServicesMail}" gesetzt.

Aber so einfach ist es dann doch wieder nicht, denn auch der HCW erwartet ein paar Angaben, wie zumindest die Cloud den Weg zum lokalen Exchange Server findet und umgekehrt die Cloud ihren lokalen Server erkennt.

OnPremise -> Exchange Online - IP oder Zertifikat?

Einen eingehende SMTP-Verbindung kann ein System an der entfernten IP-Adresse oder einem per MTLS vorgezeigten Client-Zertifikat festmachen. Nach der Verbindung kann ein System immer noch die Absenderadresse, die gefälscht sein kann, und die gewünschte Empfängeradresse nutzen, um z.B. den Tenant oder Connector auszuwählen. Beim Partner-Connector können Sie über die IP-Adresse oder den Zertifikatsnamen gehen. Beide Verfahren haben ihre Vorteile aber auch Einschränkungen.

Sie können problemlos einen Send-Connector anlegen und Exchange OnPremises mitgeben, welches Zertifikat er bei Exchange Online vorweisen soll. Das funktioniert wunderbar, wenn ihr Exchange Server direkt per SMTP/25 kommunizieren darf, denn sonst klappt das mit MTLS nicht und das Zertifikat von einer in Exchange Online vertrauenswürdigen PKI ausgestellt ist. Zudem muss die Domain zu einer Domäne im Tenant passen und damit ist der Zieltenant genau bestimmbar. Die RCPTTO-Adresse eigentlich sich nicht, denn sie kann ja auch extern sein, wenn sie von OnPremises über die Cloud ins Internet senden wollen.

Problemtisch wird dies, wenn sie eine lokale Exchange Umgebung haben aber mit vielen Tenants einen OrganisationConnector einrichten wollen. Dann müssen Sie pro Tenant mit einem eigenen ausgehenden Zertifikat arbeiten, damit Exchange Online die Verbindungen zu den verschiedenen Tenants unterscheiden kann.

Bitte lesen Sie zum Verständnis unbedingt die Seite "Office 365 Message Attribution" auf https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143. Dieser Artikel beschreibt genau den Entscheidungsbaum für Verbindungen zu Exchange Online.

Passen Sie aber auch auf, wenn Sie gerne mit "Wildcard"-Zertifikaten arbeiten und ihr regulärer Mailversand auch diese Zertifikat nutzt.

Wen Sie dann eine Mail an eine andere Firma senden, deren MX-Record aber zu Exchange Online verweist, dann landet die Mail nicht anonym in deren Tenant sondern wird in ihren Tenant als "Eingehend über OrganisationConnector" zugeordnet.

Wenn Sie OnPremises eine statische IP-Adresse haben, dann kann diese als Kriterium genutzt werden.

Exchange Online -> OnPremise -> IP oder Zertifikat?

In der Gegenrichtung meldet sich Exchange Online immer per Zertifikat mit "mail.protection.outlook.com". Allerdings muss das nicht automatisch ihr Tenant, sondern kann auch ein anderer Tenant sein. Exchange OnPremises erkennt anhand des Zertifikat die Cloud und wertet dann zusätzliche Informationen aus. (Siehe auch XOORG und Exchange und X-OriginatorOrg). Die Remote-IP-Adresse ist hier nicht sinnvoll als Kriterium nutzbar. Sie kann aber in der davor liegenden Firewall z.B.: den Zugriff auf den Exchange OnPremises Receive Connector aus dem Internet beschränken.

Sie müssen natürlich eine TLS-Verbindung von Exchange Online annehmen, damit sie per MTLS auch "mail.protection.outlook.com" bekommen. Sie wissen natürlich, dass außer einem Exchange Edge Server kein anderes SMTP-Relay dazwischen sein darf. Daher muss ihr Exchange OnPremises Server ein öffentliches Zertifikat haben, welche aber auch noch den FQDN des Server enthält. Sonst verhindert Exchange die Konfiguration.

Was ist ja logisch, da sie mit mehreren lokalen Exchange Servern auch eine interne SMTP-Kommunikation zwischen den Servern haben. Sie brauchen hier ein SAN-Zertifikat einer öffentlichen PKI für den Hybrid-Namen und die FQDN der Exchange Server. Das kann ein Problem sein, wenn  auch Ein Problem ist das für Firmen, deren interne Servernamen eine Domain nutzen, für die Sie kein Zertifikat bekommen können. z.B. weil sie eine ".local"-Domain verwenden oder sogar einen DNS-Namen, den eine anderen Firma besitzt.

Wenn Sie keinen Edge-Server vor ihren Exchange Server setzen wollen, dann können Sie einen manuell einen eigenen ReceiveConnector für den Empfang von Exchange Online anlegen. Er muss natürlich auf einem anderen Port oder eine eigene IP-Adresse konfiguriert werden, so dass Sie darauf dann das Hybrid-Zertifikat binden können.

Oder Sie konfigurieren den Outbound Connector in Exchange Online zum OnPremises System so, dass er zwar TLS erfordert aber das Zertifikat nicht prüft. Damit ist die Verbindung immer noch per TLS verschlüsselt aber theoretisch könnte jemand mit DNS-Spoofing oder Man in the Middle mit einem eigenen Zertifikat dann doch ihre interne Kommunikation mitlesen. Der Aufwand hierfür ist aber sehr hoch und dürfte nur Providern oder staatlichen Stellen möglich sein.

Manuell anlegen?

Wenn Sie genau wissen, was Sie tun, können Sie alle Einstellungen auch manuell durchführen, die ansonsten der HCW für sie übernimmt. Allerdings frage ich sie vorab, warum Sie dies machen wollen. Ich habe schon mehrere Umgebungen gesehen, in denen ein Organization Connector angelegt wurde, weil man eine besondere Routing-Anforderung lösen wollte und auf der anderen Seite dann andere Probleme aufgetreten sind.

Nutzen Sie den Organization Connector ausschließlich für die Verbindung von Exchange OnPremises mit ihrem Exchange Online Tenant.

Weitere Links