MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

DMARC findet falsche Hybrid-Konfiguration

Microsoft 365 sendet seit DMARC-Reports, wenn Sie als Absender dies wünschen um ihren Versand zu überprüfen. Einige Reports haben meine Aufmerksamkeit geweckt, da ich sie nicht erwartet habe. Heute weiß ich, dass ich mit DMARC quasi aus der Ferne erkennen kann, ob das Zielsystem ein korrektes Hybrid Routing konfiguriert hat.

Der Report

Meine Kollegen von NoSpamProxy haben einen eigenen DMARC-Service aufgebaut, den ich für meine Domains nutzen darf und dort haben wir folgende Berichte gefunden:

Sendet ein System  mit einer 14.x.x.x-Adresse und einen mit "gw" beginnenden Systemname eine Mail mit einer Domain, was sie nicht darf.

 
Quelle: 25Reports https://www.nospamproxy.de/de/produkt/25reports/

In den Details sehe ich, dass der Absender "netatwork.de" ist und die Zieladresse eine Microsoft 365 MOERA - Microsoft Online Email Routing Address ist.


Quelle: 25Reports https://www.nospamproxy.de/de/produkt/25reports/

Der Report kommt von dem Report Agent "Enterprise Outlook". So nennt Microsoft die DMARC-Agent von Exchange Online/Defender.


Quelle: 25Reports https://www.nospamproxy.de/de/produkt/25reports/

Wer sich mit DMARC etwas auskennt, kann sich schon denken, was hier passiert.

EXO Postfach und OnPrem-MX mit Hybrid

Wer Exchange Online mit einem lokalen Exchange Server koppelt, kann den MX-Record entweder auf Exchange Online mit EOP oder auf den lokalen Exchange Server mit einem vorgelagerten Spamfilter routen. Nun stellen Sie sich mal folgendes vor:

  • MX-Record verweist  auf Spamfilter
  • SpamFilter sendet die Mails an Exchange OnPremises
  • Dort gibt es eine Remote Mailbox, die Mails an Cloud Postfächer weiterleitet
  • Exchange OnPremises sendet die Mails an ihren Exchange Online Tenant
  • Mails wird ins Exchange Online Postfach zugestellt.

Also Bild sieht dies wie folgt aus:

 

Nun kombinieren wir dies mit einem SPF/DKIM/DMARC-Eintrag für die Domain Net at Work

  • SPF  ip-Adresse und "-ALL" 
    Damit stellt der Absender sicher, dass Mails dieser Domain nur von den aufgeführten Servern versendet werden darf. Ein Empfänger, der SPF-prüft, kann damit die Annahme von Mails dieser Domain über andere Server verhindern.
  • DKIM Einträge werden aufgebracht
    Damit kann der Empfänger auch bei einem fehlerhaften SFP-Check immer noch prüfen, ob die Mail an sich unverändert und authentisch ist.
  • DMARC mit RUA
    Über einen RUA-Eintrag teilt der Absender der Welt mit, dass Empfänger ihm gerne eine Rückmeldung senden dürften.

Zwei Voraussetzungen müssten  allerdings zutreffen, damit diese Fall zutrifft:

  1. MX-Record über OnPremises
    Nur dann werden die Mails durch den lokalen Exchange Server zu Exchange Online geroutet.
  2. Empfänger ist eine "Remote Mailbox"
    Nur dann greift eine TargetAddress/ExternalEmailAddress, um die Mail von OnPremises zum eigenen Tenant zu routen.

Wenn Sie sich nun die Auswertung noch mal anschauen, dann hat der Exchange Server in der Mitte mit seiner öffentlichen IP-Adresse "B" versucht eine Mail mit einem Absender von "netatwork.de" an seinen eigenen Tenants zu senden. DAs sollte eigentlich funktionieren.

Hybrid Routing prüfen

Bei einer korrekt konfigurierten Hybrid-Umgebung erkennt Exchange Online den lokalen Exchange Server entweder an der IP-Adresse oder viel besser noch an einem eindeutigen Zertifikat. Mails über diesen Connector werden von Exchange online als "intern" angesehen und keiner Spamprüfung unterworfen. Vor allem werden diese Mails nicht SPF/DKIM geprüft und auch nicht in einen DMARC-Report gemeldet. Ich habe schon mehrfach solche Fehlkonfigurationen analysiert, weil Kunden komische Probleme hatten. Ob ihre Hybrid-Konfiguration von Exchange OnPremises zu Exchange Online korrekt ist, können Sie sogar als Anwender einfach prüfen, wenn ihr Postfach in Exchange Online liegt und die Mails über die OnPremises Umgebung gehen:

  • Absender prüfen 
    Zuerst bitten Sie einen Anwender ihrer Firma mit einem Postfach auf dem lokalen Server ihnen eine Mail zu senden. Kontrollieren Sie dann bei der Mail die Schreibweise des Absenders. Wenn nur der Displayname zu sehen ist, scheint alles OK zu sein. Wenn aber hinter dem Namen in "< >" auch die SMTP-Adresse steht, dann hat Exchange Online diese Mail als "anonym" angenommen und das wäre falsch.
  • SMTP-Header
    Ein anderer Weg ist der Blick auf den SMTP-Header der empfangenen Mail. Eine Mail aus dem Internet enthält folgende Header

    Wenn die Mail aber über den Hybrid Connector gekommen ist, dann suchen Sie mal nach "HybridOnPrem" im Header

    Diese Information zeigt an, dass die Mail tatsächlich über einen Hybrid Connector angekommen ist. In der Zeile "X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp" steht sogar, dass die Attribution über eine IP-Adresse erfolgt ist und welcher welche IP-Adresse bei Exchange Online angekommen ist.

Wenn Sie so verifiziert haben, dass die Mails von ihrem lokalen Exchange Server an ihren Tenant als "Organization Connector" gewertet werden, dann sollte Exchange Online keinen DMARC-Report senden, auch wenn die einliefernde IP-Adresse ihres Exchange Servers nicht zur SMTP-Domain des Absender aus dem Internet passt.

Korrigieren!

Wer Hybrid nutzt, aber Exchange Online ihren lokalen Server nicht erkennt, hat mehr Probleme, als dass ich von Exchange Online per DMARC diese Information erhalte. Exchange Online behandelt die Mails als Extern und nicht intern, was mehrere Folgen hat, z.B.

  • Mails in Quarantäne oder Junk-E-Mail
    Externe aber auch interne Mails werden durch EOP-Spamfilter bewertet und werden nicht immer zugestellt.
  • Externe statt interne "Out of Office"
    Anwender können Abwesenheitsnachrichten in Outlook einstellen. Diese Meldungen können für interne und externe Empfänger unterschiedlich sein
  • Mails an beschränkte Postfächer oder Verteiler in Exchange Online
    Über Empfangsbeschränkungen können Sie steuern, ob ein Postfach z.B. aus dem Internet erreichbar ist. Hier werden gerne Raumpostfächer nur intern für Termineinladungen intern erreichbar gemacht. Wenn ein Raum in Exchange Online angelegt ist, können interne Absender den Raum dann nicht einladen

Das sind nur ein paar Probleme, die sie mit einer unvollständigen Hybrid-Konfiguration haben können. 

Wer ist betroffen?

Mit dem Wissen um diesen  Fehler haben wir nun natürlich alle an uns gesendete DMARC-Reports auf Meldungen von "Enterprise Outlook" angeschaut, bei denen die Zieladresse eine "*@*.mail.onmicrosoft.com" oder "*@*.onmicrosoft.com" gewesen ist. So konnten wir alle Firmen, welche Mails von uns bekommen, hinsichtlich einer korrekten Hybrid-Konfiguration prüfen.

Ich werde hier nicht die Firmen an einen Pranger stellen. Aber wenn mir so ein Fehler auffällt, dann versuche ich den Mailadministrator der Firma zu informieren und verweise ihn auf diese Seite.

Wir haben den Verdacht, dass bei ihnen die Exchange Hybrid Konfiguration nicht
korrekt konfiguriert ist. Exchange Online unterstützt DMARC, um Absendern ein
Feedback über den Versand ihrer Mail zu liefern. Wir bei Net at Work bekommen
von Microsoft die Meldung, dass ihr lokaler Exchange Server im Namen von
Net at Work etwas an ihren Tenant sendet. Wenn Exchange Online ihren lokalen
Server „erkennt“, dann sollte es keine DMARC-Meldung geben.

Prüfen Sie bitte, wie in ihrem Exchange Online der „Inbound OnPrem Connector“
konfiguriert ist. Er erkennt ihren lokalen Exchange Server entweder am
Zertifikatsnamen oder der IP-Adresse. Der OnPremises Server muss beim
Send-Connector zu Exchange Online ein Zertifikat mit dem identischen Namen
oder die in der Cloud hinterlegte IP-Adresse nutzen.

Solange dies nicht passt, werden Mails vom lokalen Exchange Server in ihrem
Tenant nicht als „Intern“ angesehen. Mails könnten z.B. in Junk-E-Mail oder
Quarantäne landen, Empfänger mit Empfangsbeschränkung werden nicht erreicht
und interne OnPremises Absender erhalten von Exchange Online Postfächern
externe OOF-Meldungen-Meldungen.

Weitere Links