MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Online SMTP BasicAuth Abschaltung

Ich habe schon mehrere Seiten zur SMTP-Verbindung und Authentifizierung mit Exchange Online geschrieben aber da immer wieder Postings und Meldungen zu der Abschaltung geschrieben werden, möchte ich hier die wichtigsten Punkte zusammenfassen. Wer mag, kann die ausführlichen Artikel immer noch lesen.

Was, wann und warum?

Wer eine Mail über Exchange Online an externe Empfänger senden will, muss sich natürlich bei Exchange Online anmelden, damit der Cloud Service den Absender und die Legitimation überprüfen kann. Wäre das nicht der Fall, dann wäre Exchange Online ein offenes Relay. Eine Anmeldung per SMTP ist also nicht ungewöhnlich aber natürlich auch eine Angriffsmöglichkeit. Es ist nicht schwer, den Benutzernamen zu erraten (Meist die Mailadresse des Absenders) und dann kann ich einfach viele Kennworte durchprobieren. Exchange Online muss jede Anmeldung prüfen und verwerfen. Eine weitere Absicherung gibt es erst einmal nicht.

Das ist erst möglich, wenn ich eine Anmeldung mit "Benutzername + Kennwort" gar nicht mehr zulasse und dem Client sage, er möge bitte mit einem SAML-Token ankommen. Der Client muss dann zuerst zum SAML/OAUTH-Service (z.B. login.microsoftonline.com) gehen und sich dort authentifizieren. Hier sind zusätzliche Schutzfunktionen, z.B. MFA, Passkey, Anomalie-Erkennung etc.) sowie implementiert. Der Exchange Server kann nicht legitime Verbindungsversuche direkt ablehnen. Exchange Online spart Ressourcen und wird sicherer. Das sollten alle Nutzer von Exchange Online befürworten.

Die Anmeldung per Benutzername/Kennwort ist aber (Stand Feb 2025) immer noch möglich, aber wird schrittweise abgeschaltet. Zuerst wird es bei neuen Tenants nicht mehr per Default aktiviert aber kann reaktiviert werden. Dann werden nach und nach Tenants deaktiviert und am Ende ist eine einfache Anmeldung per Benutzername/Kennwort gar nicht mehr möglich. Mein letzter Zeitplan (Stand Feb 2026) ist:

Zeitpunkt Veränderung

31. Nov 2026

Keine Änderung. BasicAuth ist weiterhin aktiv. Als Administrator können Sie sehen, wer diese Funktion nutzt und auch selbst deaktivieren

Vielleicht ist jetzt eine gute Gelegenheit eine solche Nutzung zu ermitteln und die Umstellung zu Planen. Neue Systeme sollten gleich zukunftssicher eingerichtet werden.

Ende Dez 2026

BasicAuth wird bei allen Tenants abgeschaltet. Als Administrator können Sie es aber wieder reaktivieren.

Das bedeutet natürlich. dass es ihnen auch auffallen muss, wenn ihre Prozesse keine Mails mehr senden können

ab 1 Jan 2027

Bei danach neu angelegten Tenants ist BasicAuth nicht mehr aktiv, aber kann wohl wieder reaktiviert werden

ca. 2. HJ 2027

Finale Abschaltung auf allen Tenants. Ob Microsoft die Zeit noch mal weiter schiebt, werden wir noch sehen.

Die Abschaltung von BASICAUTH mit SMTP wurde von Microsoft schon vor vielen Jahren angekündigt und die erste Deadline war der 1. Oktober 2022 und wurde danach mehrfach verschoben. Ich habe aber den Eindruck, dass Microsoft es nun ernst meint

Wer nutzt BasicAuth im Tenant?

Betroffen sind nur Systeme, die über Exchange Online Mails mit Authentifizierung einliefern. Nicht betroffen sind Systeme, die Mails "anonym" oder über entsprechende Connectoren einliefern oder über eigene Wege ihre Mails versenden, z.B. Newsletter etc. Nicht betroffen sind Outlook, OWA, ActiveSync. Thunderbird und andere IMAP4-Clients können meist schon OAUTH oder sind einfach umzustellen. Dankenswerterweise stellt Microsoft im Exchange Online einen passenden Report zur "SMTP-Authentifizierung" bereit. In meinem LAB-Tenant gibt es keine Anmeldungen. Daher ist der Bericht bei mir leer.


Quelle: https://admin.cloud.microsoft/exchange#/reports/smtpauthmailflowdetails

Das kann bei ihnen natürlich ganz anders aussehen. Oben erscheinen Kuchendiagramme aber interessanter ist die Tabelle unten mit der Absenderadresse und dem verwendeten Authentifizierungsprotokoll. Auch die TLS-Version ist interessant, wenn TLS1.0/TLS1.1 abgeschaltet wird. Der Reports zeigt als Standard nur die letzten 7 Tage an. Denken Sie daran, den Wert auf die maximalen 90 Tage zu stellen, damit Sie auch frühere Verbindungen sehen

Hier sollten sie möglichst schnell die Verwendung analysieren und umstellen.

Szenarien

Die einen mögen nun "Zeter und Mordio" schreien oder auf Microsoft schimpfen aber wenn wir mit etwas Abstand den Sachverhalt betrachten, dann ist die Abschaltung von BasicAuth nachvollziehbar. Vielleicht hätte Microsoft pro Tenant eine IP-AllowList ermöglichen können, mit der ich dann z.B. die ´Firewall" als NAT-Device zulassen könnte. Aber für wie viele Tenants würde dies helfen? Es gibt genug alternative SMTP-Dienste, die weiterhin das Risiko eingehen, eine Anmeldung per BASICAUTH zu erlauben. Aber überlegen Sie mal, welche Fälle es eigentlich gibt. Wir haben einen automatisierten Dienste, der Mails über einen "Smarthost" an verschiedene Gegenstellen senden könnte. Folgende Szenarien decken aus meiner Sicht alles ab:

 

Ich unterscheide vier Fälle: 

Fall von Intern an  Einsatzfäll bessere Lösung

 

1

Intern 

Automatische Mails aus Skripten und von Diensten

Für den Fall können Sie auf eine Authentifizierung sogar verzichten. Zwar prüft Exchange dann nicht den Absender und klassifiziert ihn nicht nicht als Intern, aber das stört meist nicht. Legen Sie einen "Partner Inbound Connector" an, senden sie mit einer Subdomains o.ä. und vertrauen Sie der Source-IP z.B.: über EXO Enhanced Filtering, Transportregeln und SPF-Einträgen, damit die Mails nicht als Spam klassifiziert werden.

Durch den Wegfall der Authentifizierung haben Sie auch kein Problem mit MFA, App-Registrations u.a.

 

2

Einzelne externe Adresse

Alarme an externe Dienstleister, z.B. Backup, Storage, Toner für Drucker 

In dem Fall würde ich diese eine externe Adresse, z.B. "toner@<dienstleisterdomain>" einfach als MailContact in meinem Active Directory anlegen. Das Objekt hat dann eine interne Mailadresse "toner@msxfaq.net" und kann auch einfach so angeschrieben werden. Sie müssten auf dem Kontakt natürlich noch "anonym" erlauben und vielleicht per Transportregel den Absenderkreis einschränken. Exchange leitet die Mail dann nach extern um.

 

3 

Einzelne externe Domain 

Migrationen und Koexistenz oder Subdomains mit z.B. einer Ticketnummer als Userpart

In Exchange Online können Sie leider keine fremde Domain als "Exchange Accepted Domain" und dann den Status "External Relay" versehen. Sie könnten über einen Org-Connector den Systemen (Siehe auch Linux Exchange Hybrid) dem Sender einen Vertrauensvorschuss geben, aber das ist auch ein Risiko.

Hier müssten Sie dann schon überlegen, ob eine Authentifizierung oder ein anderer Versandweg möglich ist

 

4

Beliebige externe Adresse

ERP/CRM-Systeme und Listserver 

Auch hier könnten Sie per Org-Connector (Siehe Linux Exchange Hybrid) dem System den höchsten Vertrauenslevel geben aber ich geben zu bedenken, dass Exchange noch andere Schutzfunktionen hat, z.B.

TERRL - Tenant External Recipient Rate Limit, Mailbox External Recipient Rate (ERR) Limit, Limit Enforcement System) und daher nur eingeschränkt für diese Funktionen genutzt werden kann. Prüfen Sie hier wirklich auf Alternativen.

 

Fall 1 und 2 sind einfach und problemlos umzusetzen. Kniffliger wird Fall 3, wobei es hier vielleicht ihr Versendeprozess die Mails direkt an den MX-Record der Gegenseite zustellt, mit der Sie ja irgendwie eine Geschäftsbeziehung haben. Es sollte ja auch im Interesse der Empfängerdomain sein.

Ansonsten müssen sie über andere SMTP-Relays, sei es im Eigenbetrieb oder als externe Dienstleistung, versenden. Das ist für größere Mailvolumen sowieso die bessere Option, da einige Exchange Online Message Rate Grenzen auch auf authentifizierte Konten angewendet werden

Lösungen

Auf der Seite Exchange Online als Outbound Relay habe ich einige Konfigurationen mit Exchange Online aber auch anderen Diensten beschrieben. Im Grund gibt es folgende Optionen.

  • Versand per OAUTH/SAML
    Damit der Versender weiter Mails als authentifiziertes Postfach senden kann, stellen Sie ihn auf SMTP mit OAUTH oder direkt auf Microsoft Graph um. Er braucht natürlich ein Postfach mit Exchange Plan und unterliegt den normalen Beschränkungen eines authentifizierten Benutzers
  • Anonymer Versand
    Das ist ein einfacher Weg, wenn das einliefernde System nur interne Empfänger erreichen will. Vielleicht geben Sie ihm eine eigene (Sub-)Domain mit passendem SPF-Eintrag und mit einem Partner Inbound Connector und EXO Enhanced Filtering können Sie die Zustellung verbessern
  • Kleine SMTP-Relay
    Für andere Dinge kann es interessant ein ein kleines SMTP-Relay zu betreiben. Oft haben Firewalls schon die Funktion eingebaut und ihr Prozess sendet dann direkt an den Empfänger. Denken Sie an eine passende SMTP-Versanddomain und den SPF-Eintrag. Es gibt solche Dienste auch "aus der Cloud". Ich nutze für einige Dienste einfach ein SMTP-Zugang meines Webhosting-Providers.
  • Massenmail bitte nicht über Exchange Online
    Dafür sollten Sie dann alternativen SMTP-Dienstleistern suchen. Sendgrid, Mailgun. Mailchimp, Azure Communication Services, AWS,Cloudflare sind sicher die großen Player aber es auch europäische Anbieter, wer Wert auf lokale Dienste legt.

Einschätzung

Microsoft wird in näherer Zukunft sicher die Anmeldung zur Einlieferung als authentifizierter Benutzer per SMTP an Exchange Online auf OAUTH2 / Modern Authentication umstellen und wer heute noch SMTP mit BASICAUTH nutzt, muss handeln. Allerdings ist dies aus meiner Sicht keine unlösbare Aufgabe sondern sollte auch in ihrem eigenen Interesse sein. Aber es Arbeit damit verbunden, sei es der Rückbau zu alter Systeme, die Änderung der Konfiguration auf OAUTH eventuell verbunden mit einem Update oder die Nutzung alternativer SMTP-Relays im Eigenbetrieb oder anderer Cloud-Dienste.

Microsoft stellt ihnen einen einfach erreichbaren und zu verstehenden Report im Exchange Online Admin Center bereit. Es liegt nun an ihnen, ob sie sich diesen Report anschauen und entsprechende Maßnahmen umsetzen.

Weitere Links