Microsoft hat die Abschaltung der Basic Authentication für SMTP AUTH in Exchange Online angekündigt. Als Erstes fallen dabei die Geräte aus, an deren Einrichtung sich niemand mehr erinnert: Scanner, Multifunktionsdrucker und alte Applikationsserver, bei denen ein Mailbox-Passwort in ein Webformular eingetippt wurde. Der Zeitplan für die Abschaltung wurde bereits angepasst. Prüfen Sie daher die aktuelle Ankündigung von Microsoft auf aktuelle Meilensteine, statt sich auf ein Datum aus einem Blogartikel zu verlassen, auch aus diesem. Die Inventarisierung ist unabhängig vom Datum dieselbe.
Warum gerade dieser Zugang noch offen ist
Die Basic Authentication wurde in Exchange Online bereits für Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover und die Outlook-Clients abgeschaltet. SMTP AUTH blieb dort unberührt, wo es genutzt wurde, und wurde in Tenants deaktiviert, in denen es nicht genutzt wurde.
Laut der Analyse von Microsoft in den Hinweisen zum Blockieren von Legacy-Authentifizierung nutzen mehr als 97 Prozent der Credential-Stuffing-Angriffe und mehr als 99 Prozent der Password-Spray-Angriffe Legacy-Authentifizierung.
SMTP AUTH wird von POP3- und IMAP4-Clients verwendet, die auch senden müssen, sowie von Anwendungen, Reporting-Servern und Multifunktionsgeräten, die Mails erzeugen.
Finden, was SMTP AUTH noch nutzt
Möglicherweise finden Sie nichts. Ist Security Defaults aktiviert, ist SMTP AUTH in Exchange Online bereits deaktiviert. Auch für Organisationen, die nach Januar 2020 erstellt wurden, ist es deaktiviert, sofern es nicht jemand pro Mailbox aktiviert hat.
Beginnen Sie andernfalls mit den Sign-in-Logs. Gehen Sie im Microsoft Entra admin center zu Entra ID > Monitoring & health > Sign-in logs, fügen Sie die Spalte Client App hinzu und filtern Sie nach den Protokollen der Legacy-Authentifizierung. Wiederholen Sie das auf dem Tab User sign-ins (non-interactive), denn Geräte melden sich selten interaktiv an. Für die Triage hilft die Workbook-Vorlage Sign-ins using legacy authentication.
Schauen Sie danach auf die Mailboxen. Einstellungen pro Mailbox überschreiben die organisationsweite Einstellung. Lassen Sie sich daher auflisten, wo SMTP AUTH explizit aktiviert ist:
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}Ein leerer Wert bedeutet, dass die Mailbox der Einstellung der Organisation folgt. Prüfen Sie diese mit Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Kontrollieren Sie anschließend die Seite "Scan to Email" des Druckers, die Benachrichtigungseinstellungen des ERP-Systems, Monitoring- und Backup-Tools sowie alle geplanten Skripte, die einen Bericht versenden.
Ordnen Sie jedem Treffer einen Verantwortlichen zu und notieren Sie Absenderadresse, Port, ob ein Drittanbieter den Absender hostet und ob die Empfänger intern oder extern sind. Diese Angaben brauchen Sie, um den passenden Ersatz zu wählen.
Wohin die einzelnen Absender wechseln sollten
Das richtige Ziel hängt davon ab, was der Absender kann, wo er läuft und an wen er Mails schickt.
| Absender | Wechsel zu | Bei Drittanbieter gehostet? | Hinweise |
|---|---|---|---|
| Anwendung mit OAuth-Unterstützung | Client SMTP submission mit OAuth | Unterstützt | Port 587, TLS 1.2 oder 1.3, lizenzierte Mailbox |
| Nur interne Benachrichtigungen | High Volume Email | Unterstützt | Port 587, HVE-Konto |
| Interne Empfänger, keine Authentifizierung möglich | Direct Send | Unterstützt | Port 25, SPF anpassen |
| Interne und externe Empfänger | Azure Communication Services Email | Im Vergleich von Microsoft nicht abgedeckt | Empfehlung von Microsoft für diesen Fall |
| Gerät ohne OAuth, in Ihrem Netzwerk | SMTP-Relay über einen Connector | Nicht unterstützt | Port 25, Zertifikat oder statische IP |
| Eigenes Skript oder selbst entwickelter Code | OAuth 2.0 oder Graph API | Ihr Code | Code anpassen |
Microsoft empfiehlt OAuth für Client SMTP submission und verweist auf HVE für rein interne Mails sowie auf Azure Communication Services Email für interne und externe Mails. Bei einem lokalen Mailserver können Sie auch darüber relayen, entweder mit Basic Authentication gegenüber diesem Server oder per anonymem Relay (nicht Open Relay).
Prüfen Sie zuerst das Volumen. Die OAuth-Übermittlung ist auf 10.000 Empfänger pro Tag und 30 Nachrichten pro Minute begrenzt. Für SMTP-Relay gelten diese Limits nicht, es hat jedoch eigene angemessene Grenzen. HVE kennt für interne Mails weder Empfänger- noch Nachrichtenraten-Limits.
Drucker und Scanner
Prüfen Sie zuerst die Firmware, denn ein Update des Herstellers kann OAuth nachrüsten. Falls nicht, ist das Connector-basierte SMTP-Relay die übliche Lösung. Es benötigt keine lizenzierte Mailbox, authentifiziert per TLS-Zertifikat (empfohlen) oder per statischer öffentlicher IP, die keine andere Organisation mitnutzt, und verwendet Port 25 gegenüber Ihrem MX-Endpunkt.
Relay speichert nichts in den Gesendeten Elementen und umgeht den Anti-Spam-Schutz nicht, sodass verdächtige Mails gefiltert werden können. Microsoft empfiehlt einen Eintrag im SPF-Record. Den Record können Sie mit unserem DMARC- und SPF-Checker prüfen. Ein Gerät, das standardmäßig Port 465 nutzt, unterstützt die für Client SMTP submission erforderlichen TLS-Versionen nicht. Ein Gerät ohne TLS 1.2 kann es gar nicht verwenden.
ERP-Systeme und andere Anwendungen
Fachanwendungen wie ein ERP-System sind am schwierigsten, weil der Hersteller den Mail-Code besitzt. Fragen Sie nach, ob das Produkt OAuth 2.0 für SMTP oder die Graph API unterstützt. Falls nicht, ist ein Connector-Relay die Rückfalllösung, sofern die Anwendung in Ihrem eigenen Netzwerk läuft.
Wird sie vom Hersteller gehostet, scheidet Relay aus: In der Tabelle von Microsoft ist SMTP-Relay die einzige Methode, die Absender bei Drittanbietern nicht unterstützt. Der Hersteller kann Client SMTP submission mit OAuth nutzen, HVE, wenn die Mails nur an interne Empfänger gehen, oder Azure Communication Services Email. Auch Direct Send funktioniert für gehostete Absender, ist aber nicht authentifiziert. Passen Sie daher Ihren SPF-Record so an, dass der Hersteller im Namen Ihrer Domain senden darf.
Sendet die Anwendung mit einer anderen Adresse als der der anmeldenden Mailbox, erteilen Sie die Berechtigung Send As. Ohne sie werden Nachrichten mit 5.7.60 SMTP; Client doesn't have permissions to send as this sender. zurückgewiesen.
Skripte
Für Skripte unter Ihrer Kontrolle nennt Microsoft die Graph API als Alternative für authentifizierten Mailversand. Alternativ können Sie OAuth 2.0 gegenüber den IMAP-, POP- oder SMTP-Endpunkten implementieren.
Womit Sie anfangen
- Ziehen Sie die Legacy-Anmeldungen aus den Entra-Sign-in-Logs, interaktiv und nicht interaktiv, und listen Sie die Mailboxen auf, bei denen
SmtpClientAuthenticationDisabledauf$falsesteht. - Benennen Sie für jeden Absender einen Verantwortlichen und halten Sie Empfänger (intern oder extern), Port, TLS-Unterstützung und ein mögliches Hosting durch Dritte fest.
- Wählen Sie aus der obigen Tabelle ein Ziel, testen Sie ein Gerät je Typ und stellen Sie jedes erst nach einer erfolgreichen Testnachricht um.
- Führen Sie nach der Migration
Set-TransportConfig -SmtpClientAuthenticationDisabled $trueaus. Eine Mailbox, die noch auf$falsesteht, überschreibt diese Einstellung. Setzen Sie daher jede mitSet-CASMailboxauf$null(folgt der Organisation) oder$true. Führen Sie den Filter-eq $falseerneut aus, um nachzuweisen, dass keine übrig sind, und bestätigen Sie den Wert der Organisation mitGet-TransportConfig. - Erstellen Sie eine Conditional-Access-Richtlinie, die Legacy-Authentifizierung blockiert, zunächst im Modus Report-only und mit mindestens einem ausgenommenen Notfallkonto.
Wenn die Inventur mehr zutage fördert, als Sie rechtzeitig migrieren können, unterstützt unser Consulting-Team Sie bei der Bestandsaufnahme und beim Umstellungsplan.
