Basic Auth für SMTP AUTH endet: Der letzte Vorhang fällt Ende 2026

Es ist die letzte Bastion der Basic Authentication in Exchange Online. Für IMAP, POP, EWS und MAPI hat Microsoft die Passwort-Anmeldung bereits im Oktober 2022 abgeschaltet, nur bei SMTP AUTH durfte sie bisher bleiben. Damit ist bald Schluss: Ende Dezember 2026 deaktiviert Microsoft Basic Auth für SMTP AUTH in bestehenden Tenants standardmässig. Neue Tenants ab Januar 2027 bekommen sie gar nicht mehr, und im zweiten Halbjahr 2027 folgt das endgültige, unwiderrufliche Enddatum. Wer Geräte oder Skripte betreibt, die sich mit Benutzername und Passwort per SMTP an Exchange Online anmelden, sollte jetzt handeln, auch wenn sich die Frist reaktivieren lässt.

Worum es genau geht

SMTP AUTH, auch «authenticated client SMTP submission» genannt, ist das Protokoll, mit dem Anwendungen und Geräte E-Mails zur Verarbeitung an Exchange Online übergeben, typischerweise über TCP-Port 587. Wichtig ist die Unterscheidung: SMTP AUTH unterstützt zwei Anmeldeverfahren, die veraltete Basic Authentication (Benutzername plus Passwort) und die moderne Authentifizierung via OAuth. Abgeschaltet wird nur Basic Auth. SMTP AUTH als solches bleibt bestehen, sofern die anmeldende Anwendung auf OAuth umgestellt ist.

Betroffen ist ausschliesslich Exchange Online. An SMTP-Anmeldungen gegen einen lokalen Exchange Server (auch im Hybrid) ändert sich nichts – sofern die Geräte wirklich gegen den lokalen Server einliefern. Viele Hybrid-Umgebungen senden heute schon direkt gegen «smtp.office365.com», und diese Verbindungen sind sehr wohl betroffen.

Warum Microsoft Basic Auth abschaltet

Basic Authentication sendet Benutzername und Passwort bei jeder Verbindung mit. Das macht sie anfällig für Passwort-Spray- und Replay-Angriffe und verhindert wirksame mehrstufige Authentifizierung.

Let's Encrypt Zertifikate für Exchange automatisieren mit win-acme

Ein öffentliches Zertifikat gehört auf jeden Exchange-Server, der von aussen erreichbar ist. Der lästige Teil ist die Erneuerung: Let's-Encrypt-Zertifikate laufen nach 90 Tagen ab, und niemand will das alle drei Monate von Hand machen. Mit win-acme lässt sich das komplett automatisieren, inklusive Zuweisung an die Exchange-Dienste und geplanter Erneuerung. In diesem Beitrag zeige ich den kompletten Weg, und ich gehe auf einen kleinen Stolperstein im mitgelieferten Exchange-Skript ein, der mich kurz aufgehalten hat.

Warum win-acme

win-acme (WACS) ist ein schlanker ACMEv2-Client für Windows. Er fordert das Zertifikat bei Let's Encrypt an, legt es im Windows-Zertifikatspeicher ab, weist es über ein mitgeliefertes Skript den Exchange-Diensten zu und erstellt selbst eine geplante Aufgabe für die automatische Erneuerung. Kein zusätzlicher Dienst, keine wiederkehrende Handarbeit.

Voraussetzungen

Bevor es losgeht, sollten diese Punkte stehen:

• win-acme in der "pluggable"-Variante herunterladen und das ZIP vor dem Entpacken entsperren (Rechtsklick, Eigenschaften, Zulassen)
• Ausführung als Administrator direkt auf dem Exchange-Server
• Die gewünschten Hostnamen müssen von aussen auf Port 80 erreichbar sein, denn die HTTP-01-Validierung von Let's Encrypt spricht diesen Port an

Ein Detail aus der Praxis: In meinem Fall lagen die Namen auf zwei verschiedenen öffentlichen IPs. owa und autodiscover zeigten auf die eine, smtp auf die andere. Das ist kein Problem, solange auf beiden IPs Port 80 zum selben Exchange-Server durchgereicht ist. Die selfhosting-Validierung von win-acme nutzt HTTP.SYS und läuft dadurch problemlos parallel zu IIS auf Port 80.

Exchange Hybrid: SOA-Transfer – Postfach-Attribute endlich in der Cloud verwalten

Wer Exchange Hybrid betreibt und alle Postfächer längst in Exchange Online hat, kennt das Dilemma: Für die Verwaltung der Exchange-Attribute von synchronisierten Benutzern braucht es weiterhin einen lokalen Exchange Server – den berüchtigten Last Exchange Server (LES). Attribute wie E-Mail-Adressen oder CustomAttributes werden on-prem gepflegt und per Entra Connect in die Cloud synchronisiert. Microsoft bietet nun einen Ausweg: Mit dem Source of Authority (SOA) Transfer wandert die Verwaltungshoheit für Exchange-Attribute in die Cloud – pro Postfach oder gleich für den ganzen Tenant. Schauen wir genauer hin.

Was der SOA-Transfer macht

Der SOA-Transfer trennt die Zuständigkeiten sauber auf: Die Identitätsattribute (Name, UPN, Abteilung, Telefonnummern usw.) bleiben im lokalen Active Directory und werden weiterhin synchronisiert. Die Exchange-Attribute (E-Mail-Adressen, CustomAttributes, HiddenFromAddressListsEnabled, Weiterleitungen usw.) hingegen werden nach dem Transfer direkt in Exchange Online verwaltet – per EXO PowerShell, Exchange Admin Center oder Microsoft 365 Admin Center.

Gesteuert wird das über eine neue Postfach-Eigenschaft: IsExchangeCloudManaged. Steht sie auf true, ignoriert Exchange Online die Exchange-Attribute aus der on-prem-Synchronisation und erlaubt die direkte Bearbeitung in der Cloud.

Exchange Online EWS Retirement: Die wichtigste Frist endet bereits im August 2026

Exchange Web Services (EWS) begleitet uns seit Exchange 2007. Unzählige Backup-Lösungen, Migrationstools, Archivierungssysteme und selbst geschriebene Skripte nutzen die Schnittstelle bis heute. Damit ist bald Schluss: Ab dem 1. Oktober 2026 beginnt Microsoft, EWS in Exchange Online schrittweise zu deaktivieren. Am 1. April 2027 wird die Schnittstelle endgültig und unwiderruflich abgeschaltet. Wer jetzt nicht handelt, riskiert ab Oktober einen Betriebsunterbruch. Die wichtigste Deadline liegt dabei nicht im Oktober, sondern bereits Ende August 2026.

Warum Microsoft EWS abschaltet

Bereits 2018 kündigte Microsoft an, dass EWS keine neuen Funktionen mehr erhält. 2023 folgte die Ankündigung der Abschaltung in Exchange Online. Der Sicherheitsvorfall Midnight Blizzard im Januar 2024, bei dem Angreifer unter anderem EWS missbrauchten, hat die Dringlichkeit nochmals erhöht. Seither entfernt Microsoft EWS-Abhängigkeiten auch aus den eigenen Produkten wie Outlook, Teams und Dynamics 365. Der Nachfolger ist die Microsoft Graph API mit moderner Authentifizierung und granularen Berechtigungen.

Wichtig: Betroffen ist nur Exchange Online. An EWS in Exchange Server (on-premises) ändert sich nichts.

Exchange Online - Meeting Organizer bald übertragbar

Ein Benutzer verlässt die Firma – und plötzlich gehört ihm noch eine wichtige wiederkehrende Teams-Besprechung. Für Admins bedeutet das bis heute: unsaubere Workarounds oder kompletter Neuaufbau der Serie.

Microsoft hat nun ein neues PowerShell Cmdlet für Exchange Online angekündigt, das genau dieses Problem adressieren soll. In diesem Beitrag: was bereits bekannt ist, was noch fehlt und wie ihr prüft, ob das Feature in eurem Tenant verfügbar ist.

Das Problem bisher

Für verwaiste Meeting-Serien gab es bisher nur drei Optionen:

• Serie löschen und neu erstellen → Historie geht verloren
• Serie unverändert bestehen lassen → faktisch nicht mehr administrierbar
• Shared Mailbox für den alten Organisator → langfristig keiner zuständig

Keine dieser Varianten ist in produktiven Umgebungen wirklich zufriedenstellend.

Was das neue Cmdlet können soll

Das neue Exchange Online Cmdlet soll es ermöglichen, den Organisator eines Meetings oder einer gesamten Serie zu ändern – ohne Neuaufbau und ohne Verlust der Historie.

Der neue Organisator soll dabei vollständig übernehmen:

• Wiederholungseinstellungen
• Teilnehmerliste
• Titel und Beschreibung
• Teams-Meeting-Link