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.

Zero-Hour Auto Purge (ZAP): Der stille Helfer in Exchange Online

Eine Phishing-Mail passiert morgens um 8 Uhr den Filter, weil der Link dahinter noch harmlos ist. Um 11 Uhr schalten die Angreifer die Zielseite scharf, und die Mail liegt längst im Postfach. Genau für dieses Szenario gibt es in Exchange Online eine Funktion, die kaum jemand auf dem Radar hat: Zero-Hour Auto Purge (ZAP). Sie räumt bereits zugestellte Nachrichten nachträglich weg, ist in jeder Cloud-Mailbox enthalten und braucht keine Zusatzlizenz. Trotzdem wird sie oft unabsichtlich ausgehebelt. Schauen wir genauer hin.

Was ZAP macht

Klassische Filterung entscheidet einmal, im Moment der Zustellung. ZAP arbeitet danach weiter: Der Dienst gleicht bereits zugestellte Nachrichten laufend mit den aktualisierten Spam-, Phishing- und Malware-Erkennungen ab. Wird eine Mail nachträglich als bösartig eingestuft, verschiebt ZAP sie automatisch in den Junk-Ordner oder in die Quarantäne. Das Zeitfenster umfasst die letzten 48 Stunden nach der Zustellung, und auch der Ordner «Gelöschte Elemente» wird berücksichtigt. Die Benutzer merken davon nichts; es gibt keine Benachrichtigung. ZAP gehört zu den Bordmitteln von Exchange Online Protection, also zur Stufe 1 der drei Schutzstufen, die ich im letzten Beitrag beschrieben habe.

Die vier Varianten im Überblick

Microsoft 365 Preisänderung per 1. Juli 2026: Defender for Office 365 Plan 1 neu in E3 enthalten

Seit dem 1. Juli 2026 gelten neue Listenpreise für Microsoft 365. Die Erhöhungen sind bitter: je nach Plan von 5 Prozent (Microsoft 365 E5) bis zu 43 Prozent bei den Frontline-Plänen, angekündigt bereits am 4. Dezember 2025. Spannender als die Prozente ist aber, was Microsoft im Gegenzug in die Suiten packt. Für die E-Mail-Sicherheit sticht eine Änderung heraus: Defender for Office 365 Plan 1 ist neu ohne Aufpreis in Microsoft 365 E3 und Office 365 E3 enthalten. Grund genug, die Preisänderung und die drei Schutzstufen für Exchange Online genauer anzuschauen.

Die neuen Listenpreise per 1. Juli 2026

Microsoft hat bisher nur die USD-Listenpreise offiziell publiziert (pro Benutzer und Monat, Annual Commitment). Bestandskunden bleiben bis zu ihrer nächsten Verlängerung auf den bisherigen Preisen.

Plan	Alt	Neu	Änderung
Microsoft 365 Business Basic	$6.00	$7.00	+16%
Microsoft 365 Business Standard	$12.50	$14.00	+12%
Microsoft 365 Business Premium	$22.00	$22.00	unverändert
Office 365 E3	$23.00	$26.00	+13%
Office 365 E5	$38.00	$41.00	+8%
Microsoft 365 E3	$36.00	$39.00	+8%
Microsoft 365 E5	$57.00	$60.00	+5%
Microsoft 365 F1 / F3	$2.25 / $8.00	$3.00 / $10.00	+33% / +25%

Bemerkenswert: Die «ohne Teams»-Varianten steigen prozentual stärker (Microsoft 365 E3 ohne Teams +11%, E5 ohne Teams +6%). Das betrifft auch Schweizer Kunden, da Microsoft die Teams-Entbündelung hier ebenfalls anbietet; auf microsoft.com heissen diese Pläne «EWR (ohne Teams)».

Das Packaging-Update: Diese Funktionen kommen dazu

Microsoft begründet die Erhöhung mit einer Wertsteigerung der Suiten. Der Rollout der neuen Funktionen läuft seit Juni 2026 und soll bis am 1. August 2026 abgeschlossen sein; Tenants erhalten 30 Tage vorher eine Ankündigung im Message Center. Für E-Mail-Administratoren relevant:

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

Display Name Spoofing – Was steckt hinter dem Absendernamen?

Phishing-Angriffe setzen oft nicht auf gefälschte Domains oder komplexe Technik – sie missbrauchen einfach den Anzeigenamen im Absenderfeld einer E-Mail. Das nennt sich Display Name Spoofing, und es ist erschreckend einfach umzusetzen.

Was ist Display-Name-Spoofing?

Der Anzeigename im Absenderfeld («From») ist frei wählbar – z. B. Hans Muster, CEO. Die eigentliche Absenderadresse (z. B. hans.muster.ceo@betrug-mail.com) stimmt dabei nicht mit der Identität überein. Viele Mailprogramme zeigen standardmässig nur den Anzeigenamen an, die vollständige Adresse bleibt verborgen.

Typische Merkmale:

• Der Anzeigename entspricht einer bekannten Person (z. B. CEO, Finanzleiter, IT-Administrator)
• Die E-Mail-Adresse dahinter gehört nicht zur Organisation
• Ziel ist meist, Empfänger zu Überweisungen, dem Teilen vertraulicher Daten oder dem Öffnen von Schadlinks zu bewegen

Wie erkennt Microsoft solche Angriffe?

Bei reinem Display-Name-Spoofing schlägt SPF/DKIM/DMARC nicht fehl – die Absenderdomain (z. B. @gmail.com) ist technisch legitim authentifiziert. Microsoft Defender for Office 365 setzt deshalb auf eine Kombination aus modernen Erkennungsmethoden:

SPF, DKIM und DMARC – Was steckt dahinter und warum lohnt sich die Auswertung?

E-Mail ist nach wie vor das wichtigste Kommunikationsmittel im Geschäftsalltag – und gleichzeitig eines der beliebtesten Angriffsziele. Phishing, Spam und Domain-Spoofing nehmen zu. Mit SPF, DKIM und DMARC stehen drei bewährte Mechanismen zur Verfügung, die zusammen einen wirksamen Schutz bilden. In diesem Beitrag erkläre ich, wie die drei Protokolle funktionieren, was Alignment bedeutet und welchen konkreten Nutzen die Auswertung von DMARC-Reports bringt.

Die drei Säulen der E-Mail-Authentifizierung

SPF (Sender Policy Framework) legt fest, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Der Eintrag wird als TXT-Record im DNS veröffentlicht. Exchange Online-Kunden verwenden typischerweise:

v=spf1 include:spf.protection.outlook.com -all

DKIM (DomainKeys Identified Mail) versieht ausgehende E-Mails mit einer digitalen Signatur. Der empfangende Mailserver kann anhand eines öffentlichen Schlüssels im DNS prüfen, ob die Nachricht unverändert ist und wirklich von der angegebenen Domain stammt.

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf. Es legt fest, wie ein empfangender Mailserver mit Nachrichten umgehen soll, die die Prüfungen nicht bestehen – und liefert Reports darüber, was im Namen der eigenen Domain versendet wird.

Entfernung des letzten lokalen Exchange Servers nach Hybridbetrieb

Dieser Post beschreibt den vollständigen und unterstützten Ablauf, um den letzten lokalen Exchange Server nach einer abgeschlossenen Hybridmigration ausser Betrieb zu nehmen. Er richtet sich an Umgebungen, in denen alle produktiven Postfächer bereits nach Exchange Online migriert wurden, die Identitäten jedoch weiterhin im lokalen Active Directory verwaltet und über Microsoft Entra Connect (Azure AD Connect) mit Microsoft Entra ID synchronisiert werden.

Ziel ist es, den lokalen Exchange Server sicher zu entfernen, ohne die Empfängerverwaltung zu verlieren, und gleichzeitig sicherzustellen, dass keine hybriden Abhängigkeiten mehr bestehen. Dabei werden die Exchange Server SE Management Tools zur weiteren Verwaltung verwendet, und das Microsoft-Skript CleanupActiveDirectoryEMT.ps1 sorgt für die abschliessende Bereinigung der lokalen Active-Directory-Objekte.

Update Juli 2026: Dieser Beitrag wurde überarbeitet. Die OAuth-Bereinigung erfolgt neu über ConfigureExchangeHybridApplication.ps1 statt Remove-AuthServer, der Rückbau des Hybrid Agent wurde um Remove-HybridApplication ergänzt, und mit dem Source of Authority (SOA) Transfer gibt es inzwischen eine Alternative zur Empfängerverwaltung per Management Tools (siehe Abschnitt am Ende).

Checkliste

1) Ausgangslage prüfen

• Alle produktiven Postfächer sind in Exchange Online. Keine Benutzer-, Shared-, Ressourcen- oder Archivpostfächer mehr on-prem. Beispiel vor Ort:

Set-ADServerSettings -ViewEntireForest $true
Get-Mailbox -ResultSize Unlimited

Exchange SE Lizenzen

Lizenzsituation Exchange Server im Hybridbetrieb

Du planst 2 lokale Exchange-Server, die mit Exchange Online verbunden sind (Hybrid). Die Lizenzkosten hängen davon ab, ob es noch lokale Postfächer gibt und welche Microsoft 365 Lizenzen im Einsatz sind.

---

1. Alle Postfächer in der Cloud → kostenlose Hybridlizenz

• Wenn wirklich kein einziges Postfach On-Prem liegt, kannst du den kostenlosen Exchange Hybrid Server einsetzen.

• Keine Kosten für Serverlizenzen oder CALs.

• Lizenz wird über den Hybrid Configuration Wizard angefordert.

• Einschränkung: Die kostenlose Hybridlizenz darf nur für einen einzelnen Exchange-Server genutzt werden – kein zweiter Server für Hochverfügbarkeit oder Lastverteilung möglich.

---

2. Lokale Postfächer vorhanden, alle Benutzer mit Microsoft 365 E3/E5

• E3/E5 enthalten die Exchange-CAL-Rechte für On-Prem-Zugriff.

• Du brauchst nur die Serverlizenzen (Exchange SE Standard inkl. SA).

• 2 Server: aktuell ca. CHF 1’000 pro Jahr, ab Juli 2025 ca. CHF 1’100 pro Jahr (+10 % Preissteigerung).

---

3. Lokale Postfächer vorhanden, nicht alle Benutzer mit M365 E3/E5

• Für Benutzer ohne E3/E5 brauchst du zusätzlich CALs (ca. CHF 62 pro Benutzer/Jahr).

• Beispiel mit 5 lokalen Benutzern:

  • Serverlizenzen: CHF 1’000/Jahr

  • CALs: CHF 310/Jahr

  • Total: aktuell ca. CHF 1’310/Jahr, ab Juli 2025 ca. CHF 1’457/Jahr (wegen +10 % Serverpreis, +15 % CAL-Preis).

---

Fazit:

• Am günstigsten ist es, wenn alle Benutzer E3/E5 haben – dann fallen nur Serverkosten an.

• Wenn keine lokalen Postfächer vorhanden sind, kannst du komplett kostenlos mit der Hybridlizenz arbeiten, musst aber auf Hochverfügbarkeit verzichten.

• Sobald ein Postfach On-Prem liegt, reicht die Hybridlizenz nicht mehr aus.

Hyper-V Livemigration auf Windows Server Core schlägt fehl (0x8009030D)

 Die Installation eines Hyper-V Hostes mit Windows Server Core bietet sich an. Oder ihr verwendet eine der kostenlosen Windows Versionen "Hyper-V Server 2016" oder "Hyper-V Server 2019". Die kosten nichts, können aber nicht mit Desktop experience installiert werden.

Die Verwaltung der virtuellen Computer auf dem Hyper-V Host lässt sich wunderbar remote erledigen.

Doch vor kurzem habe ich doch etwas gefunden, was sich von der Ferne schlecht erledigen lässt. Wie ihr sicher wisst, funktionieren Livemigrationen von virtuellen Computern zwischen Hyper-V Hosts, auch wenn sie sich nicht als Cluster verbunden sind. Am einfachsten geht das zwischen Hyper-V Host welche Mitglied der gleichen Domäne sind.

Ich hatte damit nie Probleme, bis ich versucht habe eine VM per Livemigration von einem Hyper-V Host auf einen anderen Hyper-V Host zu verschieben und bei der Hyper-V Host's waren mit Windows Server Core installiert. Mir wurde eine unschöne Fehlermeldung angezeigt, die besagte, dass die Authentifizierung zwischen den Hyper-V Hosts nicht funktionierte und darum die VM nicht verschoben werden kann.

Dies ist die Fehlermeldung als Text:

Failed to establish a connection with host 'host name': No credentials are available in the security package (0x8009030E)

und in Deutsch:

Fehler beim Herstellen einer Verbindung mit dem Host 'host name': Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).

Das Problem ist, dass für die Authentifizierung zwischen den Hyper-V Hosts standardmässig CredSSP verwendet wird. Dies hat einen entscheidenden Nachteil: 

Man muss interaktiv an dem Hyper-V Host angemeldet sein, von dem aus man die Livemigration startet. Nur lässt sich auf einem Windows Server Core die Hyper-V Verwaltungskonsole nicht installieren. Man verwaltet die VMs aus der Ferne auf einem Admin-Server mit GUI.

Es gibt viele Vorschläge, wie man diese Problem lösen kann. Aus meiner Sicht ist es aber am einfachsten, die Livemigrationen direkt auf dem Hyper-V Host mit PowerShell zu starten:

Move-VM -Name Test-VM001 -DestinationHost Host01 -IncludeStorage -DestinationStoragePath "D:\Hyper-V\Test-VM001"

Sicherheitslücke in Exchange - Wurde ich schon angegriffen? Hafnium Test

 Es wurden ja in den letzten Monaten öfters Sicherheits-Updates für Exchange veröffentlicht. Doch die Sicherheitslücken, für welche Anfang März 2021 Patches veröffentlicht wurden, scheint eine der gefährlicheren zu sein. Informationen dazu gibt es auf dem Exchange Team Blog, im MS Security Blog oder auch bei EighTwOne.com.

Wichtig ist auch noch zu prüfen, ob schon ein Angriff stattgefunden hat, dies geht einfach mit dem Script  Test-ProxyLogon.ps1: https://github.com/microsoft/CSS-Exchange/tree/main/Security

Unter obigem Link gibt es noch weitere Scripts, welche zu diesem Thema gehören. Das Script ExchangeMitigations.ps1 soll nur angewendet werden, wenn ihr den Exchange Server aus irgendwelchen Gründen nicht sofort Patchen könnt. Das selbe gilt für BackendCookieMitigation.ps1. Diese beiden Scripts benötigt ihr also nicht, wenn ihr die Sicherheits-Updates installiert.

Das Script CompareExchangeHashes.ps1 nutzt euch nur etwas, wenn ihr einen Supportvertrag mit Microsoft habt. Es soll zusätzlich prüfen, ob ihr angegriffen worden seid. Das Problem ist aber, dass das Script 600 - 800 MB grosse XML-Dateien produziert und immer sagt, ihr seid angegriffen worden. Auch wenn man das Script auf einem neu installierten Exchange Server ohne Internetverbindung ausführt, wie ihr hier nachlesen könnt: https://www.reddit.com/r/sysadmin/comments/m16y8m/hafnium_breach_recap_new_compareexchangehashes/
Am Ende könnt ihr dass eben die XML-Dateien bei Microsoft hochladen, doch eben nur mit einem Supportvertrag.

Jedoch gibt es noch das Script HealtjCheck, welches sehr hilfreich ist: https://github.com/dpaulson45/HealthChecker#download

Damit könnt ihr einfach nachschauen, ob alle eure Exchange Server aktuell sind und es werden sonst noch sinnvolle Einstellungen geprüft.

Wenn euere Exchange Organisation aus mehren Exchange Server besteht, startend ihr das Health Checker Script am einfachsten mit folgenden Command:

Get-ExchangeServer | ?{$_.AdminDisplayVersion -Match "^Version 15"} | %{.\HealthChecker.ps1 -Server $_.Name}; .\HealthChecker.ps1 -BuildHtmlServersReport; .\ExchangeAllServersReport.html

Schon wieder ein neuer Sicherheits-Patch für Exchange (CVE-2020-16969)

 Kaum haben wir unsere Exchange-Umgebungen wieder sicher gemacht, indem eines der neusten CU's installiert wurde, erscheint schon wieder ein neuer Sicherheits-Patch für Exchange. Folgende Versionen sind betroffen:

• Microsoft Exchange Server 2013 Cumulative Update 23
• Microsoft Exchange Server 2016 Cumulative Update 17
• Microsoft Exchange Server 2016 Cumulative Update 18
• Microsoft Exchange Server 2019 Cumulative Update 6
• Microsoft Exchange Server 2019 Cumulative Update 7

Das Problem hat damit zu tun, wie Exchange Token validiert. Ein Angreifer, der die Sicherheitslücke erfolgreich ausnutzt, kann dies verwenden um weitere Informationen von einem Benutzer zu erhalten.

Hier die Original-Beschreibung von Microsoft:

An information disclosure vulnerability exists in how Microsoft Exchange validates tokens when handling certain messages. An attacker who successfully exploited the vulnerability could use this to gain further information from a user.

To exploit the vulnerability, an attacker could include specially crafted OWA messages that could be loaded, without warning or filtering, from the attacker-controlled URL. This callback vector provides an information disclosure tactic used in web beacons and other types of tracking systems.

The security update corrects the way that Exchange handles these token validations.

Quelle: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-16969

Unter dem Link findet ihr weitere Informationen und könnt die Sicherheits-Paches herunterladen.

Der Patch kommt als *.msp und ist in etwa 160 MB gross. Während der Installation werden die Exchange Services sowie der IIS gestoppt. Es gibt also einen Dienstunterbruch um am Ende muss der Server neu gestartet werden. Bei mir hat die Installation ca. eine Stunde gedauert. Am Ende musste der Server neu gestartet werden.

Startet die Installation in einem CMD mit erhöhten Rechten und falls ihr eine Umgebung mit mehreren Exchange Servern betreibt, setzt die Server vor der Installation in den Maintenance Mode.

Exchange Sicherheits-Updates

 Gerade geht wieder durch die Fachpresse, dass es immer noch diverse Exchange Umgebungen gibt, welche dringend Sicherheitsupdates benötigen. Erstaunlich ist vor allen, dass die aktuellen Meldungen eine bekannte Sicherheitslücke betreffen, welche seit Anfang 2020 bekannt ist, seit Februar 2020 gibt es einen Patch dafür (CVE-2020-0688). Aktive Angriffe sind bekannt.

Im Sommer 2020 wurde eine weitere Sicherheitslücke bekannt. Dafür hat Microsoft im September 2020 einen Patch veröffentlicht (CVE-2020-16875).

Beide Sicherheitslücken schliesst ihr am einfachsten, indem ihr die neuesten CU's installiert.

Exchange 2019 CU7

Exchange Server 2016 CU18

Exchange Server 2013 CU23

Sicherheitslücken gibt es immer wieder. Gefährlich wird es, wenn die Lücken bekannt werden und die ersten aktiven Angriffe verzeichnet werden. Ab dann, werdet ihr nicht mehr von Hackern, sondern von Scriptkiddie angegriffen!

Nachlesen lässt sich das z.B. bei Heise: https://www.heise.de/news/Dringend-patchen-Rund-eine-viertel-Million-Exchange-Server-angreifbar-4920095.html

Virtual geekmania Extended Edition

Das in diesem Jahr alles etwas anders ist ist leider eine Tatsache. Auch unser Fachkongress, die Geekmania ist davon betroffen. Sie findet diese Jahr virtuell online statt.

Weiter Informationen findet ihr hier: https://geekmania.ch/vgm/vgmee/

Im übrigen haben wir durch das momentane virtuelle Format diverse neue lehrreiche Videos auf unserem YouTube Kanal: iTrain GmbH YouTube Kanal

Neue Exchange Version angekündigt (Exchange vNext)

 Seit einigen Jahren steht betreffend MS Exchange immer wieder die gleiche Frage im Raum: Wird Microsoft noch eine neue Exchange Version on-premise herausbringen?

Nun, vor ein paar Tagen hat Microsoft an der Ignite verkündet, dass es in der zweiten Jahreshälfte 2021 die nächste Exchange Version für lokale Installationen geben wird.

Das ist doch nett, denken sich die meisten ;-) Schauen wir uns doch erst mal an, was Microsoft denn angekündigt hat:

• Migration von Exchange 2019 auf "Exchange vNext" ist als Inplace Upgrade möglich. Das heisst, Exchange vNext lässt sich auf einem Exchange 2019 genauso wie ein CU installieren. Man muss nicht parallel neue Server aufbauen und alles rüber migrieren.
  
  
• Exchange vNetxt erlaubt eine Koexistenz mit Exchange 2013, 2016 und 2019. Bis anhin waren immer nur die 2 letzten Versionen unterstützt. Nun sind es also die 3 letzten Versionen.
  
  
• Exchange vNext Lizenz gibt es nur subscription-based, also als Abo.

Wenn man sich diese Punkte auf der Zuge zergehen lässt und ein paar wenige graue Zellen im Hirn hat, dürfte jedem klar sein, was Microsoft mit dieser Exchange vNext Version für Ziele hat ;-)

Soviel , zu "nette Microsoft", wir dürfen ein CU bei euch kaufen und das geht nur im Abo ...

Exchange Team Blog zum Thema

geekmania 2019: Keynote: Microsoft, wir müssen reden!

geekmania 2019: Die Fischer von gestern sind die IT-Terroristen von Morg...

geekmania 2019: Hyperconverged! Die Mitmachsession - Part I