Office 365 Fremdconnectoren

Für On-Prem betriebene Exchange Server gab es schon immer umfangreiche Connectoren von Drittherstellern, so dass z:B. Fax, SMS, Telex, Notes, GroupWise, MS Mail und viele andere Dienste an Exchange angebunden werden konnten. Dazu wurde früher eine Gateway API genutzt, bei der jeder Connector ein Postfach hatte, welcher per MAPI von einem Gateway gelesen und geschrieben wurde. Mit Exchange 2007 wurde ein ForeignConnector eingeführt, über den Mails an fremde Systeme gesendet und empfangen werden konnten. Mit dem Linked Connector hat Microsoft in Exchange 2010 noch eine Besonderheit geschaffen, um Mails von einem bestimmten Eingang über ein Zwischensystem zu routen. Seit Exchange 2013 gibt es all das nicht mehr und in der Cloud sowieso nicht. Hier ist SMTP der primäre Transport was aber andere Wege nicht ausschließt. Siehe auch Connector per CatchAll.

Dieser Artikel ist ein Ergebnis unserer eigenen Recherchen für eine Office 365 Anbindung einer NoSpamProxy-Instanz. Siehe auch "Anbindung von NoSpamProxy in Office 365" (https://www.nospamproxy.de/de/anbindung-von-nospamproxy-in-office-365/)

Anforderungen von Kunden

Office 365 bietet aktuell keine Lösung für den Versand von Fax, SMS, Telex oder anderen Diensten. Dass heute eigentlich nur "SMTP-Adressen" als Transportadressierung dienen, ist kein echtes Problem mehr. Wenn es richtig eingerichtet ist, dann kann eine Adresse in der Form "<Rufnummer>@fax.firma.de" durchaus zu einem Faxserver bei einem Provider oder beim Kunden geroutet werden.

Umgekehrt sollte es jedem 3rd Party Gateway problemlos möglich sein, eine eingehende Information als SMTP-Nachricht an das Postfach zuzustellen und dabei eine geeignete Absenderadresse zu verwenden, damit der Anwender sogar darauf antworten kann.

Auf den ersten Blick scheint das für einen Exchange Administrator und diverse Dritthersteller nichts besonderes oder gar neues zu sein. Bislang wurden auch On-Premises viele Fremdsysteme einfach per SMTP an Exchange angebunden. Warum sollte das mit Office 365anders sein? Dass möchte ich ihnen erklären-

Zuerst sollten Sie aber auch die Seite Office 365 Mail Connector gelesen haben.

Besonderheiten eines "Link zu Office 365"

Wenn Exchange Server und Fremd-Connector im gleichen LAN stehen und es quasi eine 1:1 Beziehung gibt, dann kann ein Produkt sowohl auf TLS/SSL zur Verschlüsselung als auch auf eine weitergehende Authentifizierung verzichten. Wenn ein Faxserver nur die Kommunikation mit der IP-Adresse des Exchange Servers akzeptiert, dann ist er schon relativ sicher. Umgekehrt kann im Exchange Server natürlich ein "Receive Connector" angelegt werden, der eingehende Verbindungen per SMTP von der IP-Adresse des Connector-Servers einfach annimmt. Auch hier kann auf Verschlüsselung und eine weitergehenden Authentifizierung verzichtet werden.

Mit Office 365 ist nun aber alles anders, denn:

  • FaxServer aus dem Internet erreichbar
    Damit ein Exchange Server von Office 365 eine Mail an den Connector-Server senden kann, muss er diesen erreichen. Im einfachsten Fall hört der Connector-Server daher auf einer festen offiziellen IP-Adresse. Damit ist es aber auch von vielen anderen Servern aus dem Internet erreichbar, DoS-Attacken sind möglich und auch die Authentifizierung muss sichergestellt sein. Wollen Sie ein "Open Fax Relay" betreiben ?
  • Port 25
    Angreifer finden ihren Server sehr einfach, da in Office 365 erst mal nur Port 25 als Ziel-Port definiert werden kann. Das Ausweichen auf einen anderen Port ist daher nicht möglich und auch keine ausreichende Sicherheit.
  • IP-Adresse von Office 365 Sender sind viele
    Im Gegensatz zu einem lokalen Exchange Server versendet Microsoft natürlich mit vielen Servern aus verschiedenen Standorten die Mails in die Welt und auch zu ihrem Gateway. Sie können versuchen auf der Firewall eine Filterliste zu pflegen, von welchen IP-Adressen ihr Connector Server erreichbar ist oder auf dem Dienst selbst einzuschränken, von welche Source-IPs eine Verbindung angenommen wird. Aber zuverlässig ist dies nicht
  • Andere Tenants
    Die Beschränkung auf die Office 365 Source-IPs unterliegt aber noch einer anderen aber wesentlichen Problematik: Auch andere Office 365 Tenants nutzen die gleichen IP-Adressen. Die Filterung nach Source-IP ist also für solche Connectoren ungeeignet. Stellen Sie sich vor, ich mit meinem @carius.onmicrosoft.com richte einen Connector an <fax.firma.de> über ihren Faxserver ein. Sie können weder anhand der Source-IP noch dem TLS-Zertifikat meine Mail von ihrem legitimen System unterscheiden.
  • Office 365 erkenne "Trusted Sources"
    Eingehende Mails von ihrem Connector Server sollten in Office 365 natürlich nicht erst durch die Spam-Filter laufen, sondern zuverlässig zugestellt werden. Office 365 kann dazu die Source-IP als Kriterium oder z.B. ein Client-Zertifikat nutzen
  • Internet auf dem Weg
    Da der Verkehr in den meisten Fällen "über das Internet" geht, ist auch die Verbindungsicherung (Verschlüsselung) wichtig. Office 365 nutzt per Default dazu TLS/SSL aber kann das auch ihr Connector Server ?

Sie sehen also, dass es nicht allein damit getan ist mal schnell den Faxserver aus dem Internet erreichbar zu machen und ein paar Einstellungen in Office 365 und dem Server vorzunehmen.

Anforderungen an die 3rd Party Lösung

Die Anforderungen haben sich geändert aber sind natürlich erfüllbar. Nur müssen die Drittprodukte nun etwas nachrüsten.

Diese Änderungen sind nicht erforderlich, wenn Sie Exchange "Hybrid"-Mode betreiben. Dann haben Sie weiterhin einen Exchange Server On-Prem, der also Zugangspunkt für den Connector dienen kann und sowohl lokale Benutzer als auch Office 365 Benutzer bedienen kann. Der Mailfluss zwischen Office 365, On-Prem und Connector-Server läuft dann über Exchange als Vermittler.

Es gibt aber durchaus einen Markt für die Anbindung eines Connector-Server direkt gegen Office 365, z.B.:

  • Betrieb ohne Hybrid Mode
    Vielleicht wollen sie keinen Exchange Server On-Premises betreiben, was neben dem Server und Strom natürlich auch statische IP-Adressen, Zertifikate, Konfiguration, Firewalls etc. bedeutet.
  • Eigenbetrieb in der Cloud
    Vielleicht wollen Sie den Dienst selbst z.B. in Azure anstatt ab ihrem Standort betreiben und wollen daher nicht auf die Hilfe eines Exchange Hybrid Server zurückgreifen.
  • Hosted Service
    Oder sie nutzen die Dienstleistung eines Hosters, der für sie die Services betreibt. Dann sollten Sie aber hinterfragen, wie der Hoster die Verbindungen von Office 365 nach Tenants unterscheiden kann und wie er die Mails an ihre Postfächer "sicher" zustellt.

Aus meiner Sicht muss eine direkte Anbindung an Office 365 wie folgt laufen.

Vom Connector zum Postfach

Vom Connector Server zum Office 365 Postfach ist der Weg noch relativ einfach.

  1. Connector Server empfängt die Nachricht vom fremden System
    Bei einem Faxserver ist das eine Faxkarte oder über ein VoIP/FoIP-Verbindung
  2. Empfänger Lookup
    Der Service schaut z.B. im lokalen Active Directory oder seiner lokalen Benutzerdatenbank nach, welche Mailadresse zum Empfänger gehört.
  3. Connectorserver konvertiert die Nachricht in ein gültiges SMTP-Format und addiert auch eine gültige Antwortadresse. Bei einem Faxserver könnte dies <rufnummer>@fax.firma.de sein.
  4. Connectorserver sendet die Mail per SMTP an den Office 365 Smarthost
    Hierzu muss aber auf Office 365 natürlich das Quellsystem sich ausweisen können. Das geht z.B. über:
    • Source IP-Adresse
      Das ist einfach und funktioniert recht gut, wenn der Connector Server eine öffentliche feste IP-Adresse hat. Verschlüsselt ist so aber erst mal nichts
    • Client-Zertifikat'
      Wenn der SMTP-Sender ein Zertifikat nutzen kann, dann würde ich diesen Weg immer vorziehen. Damit kann sich der Connector Service als Sender nicht nur über die IP-Adresse sondern über den Namen im Zertifikat ausweisen. Nebenbei ist die Übertragung noch verschlüsselt.
      Office 365 erlaubt keine Authentifizierung mit Benutzernamen und Kennwort.
  5. Benutzer liest die Mail per Outlook, OWA o.ä., in dem Postfach und kann sogar drauf antworten

Damit kommen die Fremdnachrichten ohne weiteren Umweg direkt bis in das Postfach

Vom Postfach zum Connector

In die Gegenrichtung ist der Weg etwas kniffliger:

  1. Benutzer erstellt eine neue Nachricht an die Zieladresse
    Da intern alles "SMTP" ist, muss als auch eine Faxnummer quasi als Mailadresse geschrieben werden. Denkbar ist eine Subdomäne der Firmendomäne, also in der Form <Faxnummer>@fax.firma.de.
  2. Routing in Office 365
    In Office 365 hat der Administrator natürlich einen Send-Connector angelegt, der nun alle Mails an diesen Adressraum an einen vordefinierten Smarthost sendet. Der Smarthost ist ihr Connector Server oder der nächtse Hop auf dem Weg auf dem Weg dorthin. Das geht über den Adressraum, alternativ auch über Transportregeln, die Mails an einen entsprechenden Connector weiter leiten. Ziel-Port ist natürlich 25 und TLS wäre eigentlich optional. Aber wenn Sie ein paar Abschnitte vorher gelesen haben, dass die Source-IP als Kriterium nicht ausreicht, wird hier TLS machen, um zum einen die Daten zu verschlüsseln und zudem den Office 365 Sender zu einer Authentifizierung per Client-Zertifikat zu zwingen.
  3. Empfang durch Connector Server
    Der nächste Hop, den Sie als Betreiber des Connector Servers stellen, muss die Verbindung von Office 365 per TLS annehmen und sicherstellen, das es sich wirklich um Office 365 handelt. IP-Adressen sind möglich aber bedeuten viel Pflege. Aus meiner Sicht muss der SMTP-Empfänger daher die Identität des Absenders per Client Zertifikat sicherstellen.
  4. Absender Prüfung (Tenant und User)
    Aber selbst das reicht noch nicht aus, da alle Tenants von Office 365 diese vorige Hürde nehmen. Der Empfänger muss also noch im SMTP-Header die Tenant-ID abfragen und damit die Zuordnung zum "eigenen Tenant" sicherstellen. Zudem sollte er auch die From-Adresse prüfen, ob diese überhaupt das Recht hat, z.B. ein FAX zu senden
  5. Konvertierung
    Erst wenn alle Vorbedingungen geprüft sind, macht die Konvertierung des Inhalts in das Zielformat Sinn.
  6. Versand
    Zuletzt wird die Nachricht an das Zielsystem übermittelt und ggfls. eine Rückmeldung an den Absender generiert.

Gerade der Punkt 3 und 4 dieser Auflistung ist eine Herausforderung, da viele Anbieter von Connector-Servern sich bislang nicht wirklich zum TLS und Client-Zertifikate gekümmert haben und ich noch kein Produkt gesehen habe (Stand Jun 2015), welches auch die TenantID im Header mit auswertet. Hier ein Beispiel einer ausgehenden Mail

x-microsoft-antispam: uriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB268;
x-forefront-antispam-report: BMV:1;SFV:NSPM;SFS:(10009020)()(8;DIR:OUT;SFP:1101;
  SCL:1;SRVR:DB3PR01MB268;H:DB3PR01MB265.eurprd01.prod.exchangelabs.com;FPR:;SPF:None;MLV:sfv;LANG:;
x-microsoft-antispam-prvs: <DB3PR01MB2681D7658ED56F6309EA0839E050@DB3PR01MB268.eurprd01.prod.exchangelabs.com>
x-exchange-antispam-report-test: uriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);
  SRVR:DB3PR01MB268;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB268;
x-forefront-prvs: 05168A3970
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2015 23:02:43.2217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: <guid des tenant>
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR01MB268

Neben vielen Headern ist hier das Feld "X-MS-Exchange-CrossTenant-id:" von Interesse, welches die GUID des Tenant enthält.

Achtung: Das Feld "X-MS-Exchange-CrossTenant-id" ist um den Sep 2022 im Header verschwunden. Wer darauf eine Regel aufgebaut hat, muss sich was anderes Suchen. So ist das aber mit nie von Microsoft offiziell nach extern kommunizierten Feldern.

Hosting von Diensten ?

Wenn Sie all diese "Mühe" sich ersparen wollen, dann können Sie die Aufgabe natürlich auch an einen Dienstleister übertragen. Sie senden dann alle Nachrichten einfach dort hin und erwarten, dass der Dienstleister schon sicher den Absender verifiziert.

Tipp: Ich empfehle jedem größeren Kunden, der Office 365 nutzt, sich einfach einen zweiten Tenant zum Test und Spielen. Das kostet für 5 User weniger als 20€/Monat und sollte im Budget sicher möglich sein. Mit diesem Tenant können Sie dann aber z.B. mal prüfen, ob der Provider wirklich die Mails vom falschen Tenant dann auch stoppt

Als Hoster wird der Empfang von Mails der Kunden auf Office 365 natürlich auch etwas anspruchsvoller. Früher hat jeder Kunde ja seine eigene öffentliche IP-Adresse genutzt und Sie konnten problemlos diese als "Source-Filter" und Selektionsmerkmal für den Kunden nutzen. Sobald aber mehrere Kunden auf Office 365 umgestellt haben, wird ihr Server nur noch die Office 365 Source-IP-Adressen sehen. Spätestens dann sollte ihr erstes System zum einen die Client-Zertifikate unterstützen, damit der Absender eindeutig als Office 365 identifiziert werden kann.

Dies ist nicht nur wichtig zur Verschlüsselung der Mails zum Connector Server, sondern auch wichtig um die Integrität der Nachricht sicher zu stellen. Schließlich muss sichergestellt sein, dass die "Tenant-ID" im Header der Mail auf jeden Fall gültig und nicht gefälscht ist.

DirSync zum Fax-Service

Office 365 nutzt Office 365:Identitäten, um Berechtigungen zu steuern. Ein FaxServer (On-Prem oder Cloud) benötigt die Information, welche Benutzer Faxe versenden dürfen und Routinginformationen, um eingehende Faxe an das richtige Postfach zuzustellen.

Passenderweise sind diese Daten, d.h. SMTP-Adresse und Fax-Nummer, in Office 365 zu hinterlegen. Damit stellt sich die Frage, wie insbesondere Hosted Fax Services" sich diese Informationen von der Cloud beziehen können. Denkbar sind mehrere Wege:

  • Azure AD PowerShell
    Der Fax-Service könnte eine Azure AD PowerShell starten und damit z.B. die Mailadresse und die Faxadresse auslesen
  • Azure GraphAPI
    Über die neue GraphAPI geht da auch direkt per REST.
  • Nutzung des On-Prem AD
    Alternativ kann man natürlich auch die Mailadresse und Faxnummer weiter im On-Premises-Active Directory pflegen und so dem Faxserver bereit stellen
  • Publizieren zum Fax Service
    Zuletzt kann eine Firma selbst die Daten aus einer beliebigen Quelle beziehen und dann an den Fax-Service übertragen.

In den ersten drei Fällen muss natürlich der Faxserver entsprechende Zugangsdaten bekommen und eine der APIs unterstützen. Im dritten Fall muss der Faxserver zumindest einen API bereitstellen, um die Daten zu pflegen. Ich vermute mal, dass die meisten Anbieter hier entweder eine manuelle Pflege vorsehen. Dies ist für kleine Firmen mit wenig Änderungen oft sogar die bessere Wahl. Größere Firmen werden aber lieber die Daten irgendwie synchronisieren. Der letzte Weg mit den "Senden an den Service" ist aus Sicherheitsaspekten natürlich viel besser als einem Server ein Dienstkonto auf Office 365 zu geben.

Weitere Links