BasicAuth Ende mit POP3/IMAP4 umgehen

Es wird langsam ernst, denn Microsoft twittert mittlerweile einen "Countdown". Niemand sollte darauf spekulieren, dass Microsoft die Abschaltung noch mal vertagt.

Nach dem 1. Okt 2022 wird Microsoft die "Basic Authentication" in Exchange Online abschalten und wer bis dahin nicht OAUTH2 / Modern Authentication unterstützt, wird offline sein. Den genauen Zeitpunkt können Sie im Admin Center und Microsoft 365 Message Center einsehen. Hier eine Meldung, die ich am 20. Okt 2022 in einem meiner Tenants gesehen habe.

Sie können zwar noch eine "Verlängerung" bis 31.12.2022 beantragen, aber spätestens dann müssen Sie eine der folgenden Lösungen umgesetzt haben.

Das Problem

Microsoft hat es immer wieder angekündigt und vertagt aber im 1. Okt 2022 sollte es nun endlich passieren, dann zumindest Exchange Online keine Anmeldung mehr per "BasicAuth" am Postfach zulässt. Das betrifft primäre die Dienste POP3 und IMAP4, über die speziell viele "Automatisierungsprozesse" arbeiten. Aber auch EWS und ActiveSync sind betroffen.

M365 Platform Call Jun 14 2022 - Greg Taylor - Basic Auth Deprecation in Exchange Online
https://pnp.github.io/blog/microsoft-365-platform-community-call/2022-06-14/files/M365%20Platform%20Call%20-%20June%2014%202022.pptx

Es gibt nun verschiedene Lösungsansätze:

Analyse

Ob und wer noch "Basic Auth" mit Exchange Online nutzt, konnten sie im SignIn Log über das Azure Portal in Erfahrung bringen. Da die Anmeldung per BasicAuth aber mittlerweile "abgeschaltet" ist und die SignIn-Logs ihne Zusatzprodukte maximal 30 Tage aufbewahrt wurden, finden Sie dort nichts mehr. Wenn sich Anwender bis heute noch nicht gemeldet haben, dann nutzen Sie POP3/IMAP4 gar nicht-

Automatische Umstellung

Sie können natürlich darauf hoffen oder vertrauen, dass die Software schon alleine erkennt, wenn beim Handshake eben nicht mehr "PLAIN" angeboten wird oder der plumpe Versuch mit einem "Access Denied" abgewiesen wird.

Das Problem haben auch die Millionen IOS-basierten Smartphones und Tablets, welche schon lange OAUTH können Aber Apple hat z.B. erst mit IOS 15.6 eine Funktion eingebaut, die Anmeldung bei einem bestehenden Profil automatisch umzustellen. Vorher musste der Anwender ein neues Profil anlegen. Nun wird Microsoft intensiv mit Apple hier kommuniziert haben, um diese Funktion zu integrieren.

Gehen Sie aber nicht davon aus, dass andere Produkte "genauso" schlau sind. Wenn sie nicht vorbereitet sind, dann wird es nach dem 1. Oktober irgendwann zu Störungen kommen.

Leider hat Microsoft keinen Prozess implementiert, der in die Postfächer einfach eine Mitteilung sendet, ob und mit welchen Clients sich der Anwender per BasicAuth angemeldet hat.

Manuelle Umstellung

Es gibt natürlich schon Produkte, die "Modern Authentivation" oder "OAUTH" unterstützen aber eine statische Konfiguration nutzen. Als Administrator oder Betreiber müssen Sie kontrollieren, welche Dienste noch ohne OAUTH auf Exchange Online zugreifen und diese umstellen. So kann z.B. ServiceNow schon per OAUTH ein Support-Postfach leeren aber es muss eben eingestellt werden:

Wenn Sie diese Umstellung nicht vornehmen, dann bekommen Sie eben keine Tickets mehr, weil ServiceNow die Mailbox nicht mehr abrufen kann.

Hier könnte aber der Dienstleister oder das Server-Produkt solche Anmeldefehler über das Reporting melden. Sogar vorab könnte jemand eine "nutzt *.office365.com mit Basic"-Konfiguration erkennen und den Kunden darauf hinweisen. Ich befürchte aber, dass dies nicht passiert.

POP/IMAP-Proxy Service

Seitdem Microsoft die Abschaltung von BasicAuth angekündigt habe, habe ich mir Gedanken über alternative Lösungen gemacht. Eine Lösung könnte ein lokaler Proxy sein, der zwischen die Applikation und Exchange Online geschaltet wird. Das ist vermutlich keine Lösung für tausende von Clients aber für automatische Prozess, die für die es keinen Plan-B gibt, könnte das ein gangbarer Weg sein.

Der Client spricht dann nicht mehr mit outlook.office365.com sondern mit dem Proxy, der z.B. einen IMAP4-Server simuliert. Natürlich meldet sich der Client an dem Server per Username/Kennwort an aber der Proxy prüft die Daten nun gar nicht, sondern macht seinerseits eine IMAP4-Verbindung zu outlook.office365.com auf und meldet sich doch mit OAUTH an.

Der Proxy muss natürlich eine AppID und ein Client-Secret haben und auch im Tenant als App eingetragen und entsprechenden Berechtigungen und Consent versehen sein. Aber rein technisch sollte es einfach sein, so einen Proxy zu entwickeln der nach der erfolgreichen Anmeldung einfach nur transparent die TCP-Connection durchreichen muss. Es gibt natürlich Herausforderungen:

  • SSL
    Auch der Proxy sollte natürlich nicht unterschlüsselt erreichbar sein und einen TLS-Handshake erzwingen. Niemand sollte sein Kennwort quasi in "Klartext" übertragen.
  • Multi Threading/Pooling
    Eine Lösung muss natürlich damit umgehen können, dass mehrere Prozess eine Verbindung parallel anfordern und betreiben.
  • Kein MFA
    Wenn per OAUTH eine weitere Anmeldung erforderlich wird, dann kann das nicht umgesetzt werden. Es gibt keine Lösung, da die Anmeldung keine Rückfrage vorsieht.

Ich kann zwar einiges mit PowerShell erreichen und ein PoC auf Basis von PowerShell ist sicher denkbar (Siehe auch PowerShell und TCP). Allerdings fehlt mir die Zeit und ganz klar auch die Anforderung von zumindest einem Kunden so eine Lösung zu bauen. Daher verweise ich erst einmal auf andere Projekte, die eine vergleichbare Funktion bereitstellen.

Die Idee der POP3/IMAP4-Proxy-Lösungen ist also nicht ganz neu.

Eigener lokaler Exchange Server

Es verbietet ihnen natürlich niemand, einen eigenen POP3/IMAP4-Server zu betreiben. Wenn Sie als Firma immer noch einen Exchange Server On-Premises haben und z.B. im Hybrid-Mode agieren, dann können Sie die betroffenen Postfächer sehr einfach wieder auf den lokalen Server verziehen. Allerdings müssen Sie den Clients dann natürlich auch wieder den neuen Server mitteilen. Wenn das Postfach aber von einem Cloud-Service abgefragt wird, dann müssen Sie ihren Exchange Server zumindest für diese Clients auch aus dem Internet erreichbar machen.

Natürlich ist der Betrieb eines lokalen Exchange Servers vielleicht nicht das, was Sie wollen. Vor allem seit dem es auch offiziell möglich ist, ohne lokalen Exchange Server und nur mit der Exchange PowerShell eine Exchange Online Umgebung zu verwalten.

Eigener lokaler Mailserver

Wenn Sie nur wenige "Funktionspostfächer haben" und der Service selbst auch intern ist, dann können Sie vielleicht einen kleinen unabhängigen SMTP-Server aufbauen, der nur die wenigen Postfächer bedient. So könnten eine hMailServer-Instanz sehr schnell und einfach aufgebaut und betrieben werden. Der kleine Server dient dann als Postfachserver, der aber ebenfalls von Exchange Online per SMTP erreichbar sein muss. Der Betrieb kann aber einfacher und damit günstiger als ein lokaler Exchange Server sein.

Eine Mail an "<funktionspostfach>@<firmendomain>" können Sie dann einfach über einen Exchange Online Kontakt z.B. weiterleiten auf <funktionspostfach>@service.<firmendomain>. Der lokale Mailserver nimmt nur Mails von Office 365 an und legt sie in das Postfach ab, damit ihre Software diese dann per POP3/IMAP4 abrufen kann. Der Weg über eine SMTP-Zustellung mit einer Beschränkung auf eine Zieladresse und nur von ausgewählten Quell-IP-Adressen sichert so einen Server schon sehr gut ab.

Mit einem Kontakt und Weiterleitung zu einem anderen Server umgehen Sie übrigens die Beschränkungen eines Exchange Online Postfachs. Siehe auch Exchange Online Message Rate Grenzen.

Rückkehr des POP3-Sammlers

Es gibt noch eine kleine Abwandlung dieser Funktion, die in den Anfangszeiten des Internet oft genutzt wurde. Damals waren Standleitungen teuer und ein Mailserver hat die Nachrichten einer Firma per POP3 vom Provider abgeholt und intern verteilt. Das ist theoretisch auch hier denkbar.

Voraussetzung ist natürlich, dass sich der POP3-Sammler gegenüber Exchange Online mit OAUTH anmelden kann. Solche Sammeldienste gibt es viele.

Übrigens ist es nicht einmal so untypisch, dass eine Applikation eingehende Nachrichten aus einem Verzeichnis abholt und sich eines SMTP-Servers zum Empfang bedient. Auch Microsoft SharePoint hat den Windows SMTP-Server genutzt, um Mails zu empfangen.

Alternative Bereitstellung

Aber wenn Sie schon beim Thema POP3-Sammler sind, dann könnten Sie einmal prüfen, ob es andere Wege gibt, eine Information in das verarbeitende System gibt. Es muss ja nicht eine POP3/IMAP4-Zugang sein. Vielleicht reicht ja auch ein Verzeichnis, in dem Sie EML/MSG-Dateien bereitstellen und von dort dann wieder eingelesen werden.

Dann könnte es durchaus eine Option sein, die Mails mit einem POP3-Sammler oder eigenem Skript oder vielleicht sogar Graph aus dem Exchange Online Postfach abzuholen und ihrer Applikation vorzuwerfen.

SMTP-Versand

Bislang habe ich nur über das Abholen von Mails aus einem Exchange Online Postfach geschrieben. Hier möchte Microsoft eine höhere Sicherheit erreichen. Eigentlich ist Exchange Online noch bis 1. Okt 2022 eines der wenigen Systeme gewesen, die noch "BasicAuth" erlaubt haben. Die Abschaltung sichert die Cloud nicht nur besser ab sondern reduziert auch die Komplexität bei Microsoft. Der Exchange Online Server muss nicht mehr die Zugangsdaten selbst überprüfen. Ein Angreifer mit gültigen Zugangsdaten könnte ja alle Mails lesen und ggfls. verändern.

Beim Versand von Mails per SMTP ist aber kein Zugriff auf das Postfach möglich. Es geht ja nur um das "Einliefern" von Mails, die dann von Exchange Online an den Empfänger zugestellt oder weiter geleitet wird. Hier ist wohl kein OAUTH-Zwang vorgesehen, so dass sie auch nach dem 1. Okt 2022 weiterhin zumindest Mails per SMTP mit Basic-Authentifizierung nach einem Wechsel mit STARTTLS versenden können.

Das erleichtert schon den Versand von Mails mit Multifunktionsgeräten oder auch einfachen Skripten.

Sie können natürlich auch ohne Authentifizierung eine Mail per SMTP über den MX-Record an ihren Tenant senden. Allerdings wird ohne weitere Konfiguration hier natürlich der Spamfilter ggfls. die Mail blockieren oder in die Quarantäne senden. Eine Nutzung von Exchange Online als Relay zu anderen Diensten ist in dem Fall auch nicht möglich.

Einschätzung

Dass Microsoft den Zugriff auf Exchange Online Postfächer ab dem 1. Oktober nach und nach auf OAUTH umstellt, ist logisch und war lange angekündigt. In Panik müssen Sie aber nicht verfallen, denn es gibt jede Menge andere Optionen, diese Informationen aus dem Exchange Online Postfach an ihre Applikation zu übergeben. Zuerst sollten Sie den Hersteller oder Entwickler natürlich fragen, ob seine Anwendung auch OAUTH kann. Wenn dies nicht geht, können Sie die Mails über einen anderen POP/IMAP-Server bereitstellen, den Sie dem eigentlichen Exchange Online System nachschalten. Vielleicht gibt es aber auch einen ganz anderen Weg, z.B. über Graph, um die Informationen abzurufen und weiter zu verarbeiten.

Weitere Links