Achtung: Neue Phishing-Welle nutzt Azure Blob Storage – so schützen Sie Ihr Microsoft 365 mit Passwordless Authentication

Cyberkriminelle sind heute kreativer denn je – und sie nutzen sogar Microsoft-Dienste selbst, um Nutzer zu täuschen.
Ein aktueller Fall zeigt, wie Angreifer über Azure Blob Storage glaubwürdige Microsoft-Login-Seiten fälschen, um Zugangsdaten zu stehlen.

Doch wer Passwordless Authentication einsetzt, schließt genau diese Lücke – und eliminiert Passwörter als Einfallstor.

Phishing über Azure Blob Storage – so funktioniert der Angriff

Die aktuelle Angriffswelle nutzt legitime Microsoft-Domains wie *.blob.core.windows.net.
Betroffene erhalten Links, die auf den ersten Blick harmlos wirken, z. B.:

forms.office.com/<zufälliger-wert>

Nach dem Klick wird man auf eine Seite weitergeleitet, die wie eine echte Microsoft-Login-Seite aussieht – aber in Wahrheit gefälscht ist.
Die Domain endet oft auf:

https://<zufälliger-name>.blob.core.windows.net/<datei>.pdf

Sobald man sich dort mit seinem Microsoft-365-Konto anmeldet, werden Passwort und Authentifizierungstoken abgefangen.
Damit erhalten Angreifer Zugriff auf den gesamten Microsoft-365-Mandanten des Unternehmens.

Besonders perfide:
Da die Domain windows.net zu Microsoft gehört, halten viele Benutzer sie für sicher.

Warum herkömmliche Schutzmaßnahmen nicht ausreichen

Auch wenn Unternehmen heute Firewalls, MFA, Webfilter und Awareness-Trainings einsetzen – Phishing bleibt ein Problem.
Denn Angreifer täuschen vertraute Umgebungen perfekt nach.

Selbst Multi-Faktor-Authentifizierung (MFA) hilft nur bedingt:
Bei Token-Phishing oder Session Hijacking kann sie umgangen werden.

Das Kernproblem bleibt: Passwörter sind phishbar.

Passwordless Authentication – Sicherheit durch den Wegfall des Passworts

Mit Passwordless Authentication löst Microsoft das Problem elegant:
Anstelle eines Passworts nutzt der Benutzer starke kryptografische Schlüssel, die an sein Gerät oder seinen Authenticator gebunden sind.

Beispiele für Passwordless-Login-Methoden

  • Windows Hello for Business – Anmeldung per PIN oder Gesichtserkennung
  • Microsoft Authenticator – Anmeldung durch Push-Bestätigung
  • FIDO2-Sicherheits-Keys – z. B. YubiKey oder Feitian-Key

Damit entfällt die Notwendigkeit, ein Passwort einzugeben – und somit das Risiko, dass es abgefangen wird.

So funktioniert Passwordless technisch

Passwordless basiert auf einem sicheren Public/Private-Key-Verfahren:

  1. Der Private Key bleibt sicher auf dem Gerät oder Token des Benutzers.
  2. Der Public Key wird bei Microsoft Entra ID (ehemals Azure AD) gespeichert.
  3. Beim Login signiert das Gerät eine Challenge – ohne dass ein Passwort übertragen wird.

👉 Selbst eine täuschend echte Phishing-Seite kann diese Anmeldung nicht nachahmen,
weil der Private Key das Gerät niemals verlässt.

Vorteile von Passwordless Authentication

VorteilBeschreibung
🛡️ Phishing-resistentKeine Passwörter = kein Angriffsziel
🚀 Schneller LoginKein Eintippen, kein „Passwort vergessen“
💼 Weniger SupportaufwandReduziert Helpdesk-Tickets
🔑 Stärkere SicherheitBasierend auf Kryptografie, nicht Wissen
🔗 Microsoft 365 integriertUnterstützt in Entra ID, Windows & Azure

Fazit: Phishing verhindern, bevor es passiert

Der Phishing-Angriff über Azure Blob Storage verdeutlicht, dass Angreifer heute legitime Dienste nutzen, um Vertrauen zu missbrauchen.

Mit Passwordless Authentication nehmen wir ihnen das wichtigste Werkzeug –
das Passwort – einfach weg.

💬 „You can’t phish what doesn’t exist.“
– Microsoft Security Engineering Team

Passwordless ist keine Zukunftstechnologie mehr,
sondern der nächste logische Schritt in der Sicherheitsstrategie moderner Microsoft-Umgebungen.

Cloud-verwaltete Remote Postfächer – It’s finally happening!

Time to say goodbye… Jedenfalls zum letzten Exchange in eurer Umgebung!

Wenn du bisher gewartet hast, um den „letzten Exchange Server“ endlich loszuwerden, haben wir gute Nachrichten für dich:
Cloud-verwaltete Remote-Postfächer sind ab sofort allgemein verfügbar (GA)!

Am 20. August 2025 wurde die öffentliche Vorschau dieser Funktion angekündigt. Nun ist es endlich so weit!

Was sich seit der Vorschau verbessert hat

In der Public Preview war es noch nötig, Hybrid Identity Admin– oder Global Admin-Rechte zu haben, um die Eigenschaft isExchangeCloudManaged eines Postfachs zu ändern. Wenn man nur Exchange Admin-Rechte genutzt hat, wurde stillschweigend nichts geändert – ohne Fehlermeldung.

Das ist jetzt Geschichte
Ab sofort reicht die Exchange Admin-Berechtigung völlig aus, um die Einstellung zu ändern. Ein kleines, aber sehr willkommenes Update.

Was erwartet uns noch demnächst?

1. Mandantenweites LES-Flag

Damit kannst du künftig zentral festlegen, dass alle neuen, verzeichnissynchronisierten Postfächer automatisch ohne Exchange-Attribute in die Cloud synchronisiert und dort verwaltet werden.
Das spart dir die Konfiguration pro Postfach und beschleunigt die Einführung deutlich.

  • Private Preview: Ende dieses Monats
  • Allgemein verfügbar: Nächster Monat

2. Writeback von Exchange-Attributen

Manche Unternehmen haben lokale Anwendungen, die auf bestimmte Exchange-Attribute im AD angewiesen sind. Um hier einen reibungslosen Übergang zu ermöglichen, wird es bald möglich sein, wichtige Exchange-Attribute aus der Cloud zurück ins lokale AD zu schreiben – über Entra Cloud Sync.

  • Private Preview: November
  • Allgemein verfügbar: Anfang nächsten Jahres

Für alle, die on-prem ganz abschaffen wollen

Die oben genannten Features richten sich an Organisationen, die ihr lokales AD weiter betreiben, aber den letzten lokalen Exchange Server abschalten möchten.

Wenn du allerdings planst, komplett in die Cloud zu wechseln, hat Microsoft ebenfalls spannende Optionen für dich: den Objektbasierten Source-of-Authority (SOA)-Transfer. Damit kannst du Benutzer, Gruppen und Kontakte vollständig in Entra ID verschieben und dort verwalten.

  • Gruppen-SOA ist schon in der öffentlichen Vorschau
  • Benutzer-SOA ebenfalls
  • Kontakt-SOA ist jetzt als Vorschau verfügbar

Damit kannst du Identitäten vollständig in die Cloud heben, ohne Verwaltungsfunktionen einzubüßen – ein entscheidender Baustein, wenn du Exchange On-Prem endgültig abschalten willst.

Wie werde ich also meinen letzten Exchange los? Da wir hier das Rad natürlich auch nicht neu erfinden müssen, findet ihr hier den Link zum Learning Artikel von Microsoft:

https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management

End of Support für Exchange 2016 und 2019 – was bedeutet das konkret?

Viele Unternehmen setzen heute noch auf Exchange 2016 oder 2019. Am 14. Oktober 2025 endet der Extended Support für Exchange Server 2016 und Exchange Server 2019. Ab diesem Zeitpunkt stellt Microsoft keine Sicherheitsupdates, Bugfixes oder technische Unterstützung mehr für diese Versionen bereit.

Das bedeutet: Systeme, die nach dem 14. Oktober 2025 weiterhin betrieben werden, laufen ohne Schutz vor neu entdeckten Schwachstellen – eine Situation, die insbesondere sicherheitskritische Hybrid‑Szenarien gegenüber Exchange Online zu einem ernsthaften Risiko macht.

Microsoft setzt seit einiger Zeit auf ein neues Sicherheitskonzept für Hybrid-Szenarien: ungepatchte oder veraltete Exchange-Server werden aktiv überwacht. Sobald ein System dauerhaft nicht mehr dem aktuellen Patchstand entspricht, kann Microsoft die Kommunikation zwischen On-Premises und Exchange Online gezielt drosseln oder sogar blockieren. Ziel ist es, unsichere Server schneller aus dem Verkehr zu ziehen und Unternehmen damit zum Handeln zu bewegen.

Die Maßnahme zielt auf Systeme, die ein dauerhaftes Sicherheitsrisiko darstellen – insbesondere, wenn sie über längere Zeit nicht mehr mit den aktuellen CUs (Cumulative Updates) und SUs (Security Updates) versorgt wurden.

Der Grund ist klar: Veraltete und ungepatchte Systeme sind ein massives Sicherheitsrisiko – sowohl für deine eigene Infrastruktur als auch für die Cloud.

Drosselung und Blockierung – was heißt das für mich?

Wenn das System nicht auf einem aktuellen Stand ist, wird man mit Einschränkungen rechnen müssen. Microsoft kann den Datenverkehr zwischen deinem Exchange-Server und Exchange Online drosseln oder ganz unterbinden.

30 Tage Schonfrist – aber nur begrenzt

Du kannst die Drosselung zwar für 30 Tage pausieren, aber:

  • Diese „Grace Period“ steht nur drei Mal pro Kalenderjahr zur Verfügung.
  • Danach bleibt dir keine andere Wahl, als dein System zu aktualisieren oder eine Migration zu planen.

Kurz gesagt: Das ist nur eine Notlösung, keine Strategie.

Mit dem nahenden End of Support stellt sich die Frage: Wird Microsoft diese Systeme direkt blockieren?

Die gute Nachricht: Nein, nicht sofort!! Microsoft hat klargestellt:

„We do not plan to throttle a ‘fully up to date’ Exchange 2016/2019 immediately starting end of support, no. The throttling / blocking is to address persistently vulnerable servers (servers that are out of date significantly). We do not have ‘a date’ when we would start throttling those versions after they go out of support as that depends on vulnerabilities found / updates released. And yes, you’ll still have the usual time to pause the throttling / blocking.“

Das heißt für mich:

  • Wenn der Exchange 2016 oder 2019 bis zum Supportende aktuell gehalten wird, ist man zunächst auf der sicheren Seite.
  • Kritisch wird es erst, wenn nach Supportende neue Schwachstellen auftauchen – denn dann kannst du diese Systeme nicht mehr patchen.
  • Spätestens in diesem Moment riskierst man, in die Drosselung oder Blockierung zu laufen.
  • Auch hier gibt es die Option, die Drosselung temporär zu pausieren – aber nur begrenzt und nicht als Dauerlösung.

Microsoft macht aber unmissverständlich klar: Nur aktuelle Systeme dürfen im Hybrid-Betrieb laufen. Heißt zusammengefasst:

  • Nur vollständig gepatchte und unterstützte Systeme dürfen dauerhaft mit Exchange Online kommunizieren.
  • Das bedeutet für dich: Planung statt Reaktion – ob durch Migration nach Exchange Online oder ein rechtzeitiges Upgrade.
  • Wer wartet, bis die Drosselung greift, läuft Gefahr, den Mailfluss für 30 Tage nur noch künstlich „freischalten“ zu können – und spätestens nach drei Verlängerungen steht die Infrastruktur still.

Fazit

Mit dem Ende des Extended Supports am 14. Oktober 2025 ist klar: Exchange 2016 und 2019 werden zur tickenden Zeitbombe, sobald keine Sicherheitsupdates mehr verfügbar sind. Microsoft duldet im Hybrid-Betrieb nur Systeme, die auf dem aktuellen Patchstand sind. Alles andere führt über kurz oder lang zu Drosselung, Blockierung und eingeschränkter Kommunikation mit Exchange Online.

Heißt für euch: Warte nicht, bis Microsoft eingreift. Plane jetzt deine Strategie – ob Migration nach Exchange Online oder ein rechtzeitiges Upgrade auf Exchange Subscription Edition. Nur so wird sichergestellt, dass der Mailfluss stabil bleibt und du nicht auf Notlösungen wie die begrenzte 30-Tage-Pause angewiesen bist.

Cloud-Managed Remote Mailboxes – der nächste Schritt zur finalen Exchange-Server-Stilllegung

Hintergrund: Das „Last Exchange Server“-Problem

Viele Unternehmen, die mittlerweile sämtliche Postfächer in Exchange Online betreiben, behalten dennoch einen lokalen Exchange-Server – allein zur Verwaltung von Empfängerattributen. In Hybrid-Szenarien ist das Bearbeiten von Remote-Mailbox-Eigenschaften in der Cloud standardmäßig blockiert, da die Quelle der Autorität (Source of Authority, SOA) in der On-Premises-Exchange-Umgebung liegt (techcommunity.microsoft.com).

Die neue Cloud-Management-Funktion

Microsoft hat ein neues Feature in Exchange Online (aktuell im Preview-Status) angekündigt, das es ermöglicht, die Exchange-Attribute synchronisierter Benutzerkonten mit Remote-Postfächern direkt aus der Cloud zu bearbeiten. Identitätsattribute wie Name oder Telefon bleiben dabei nach wie vor On-Premises-verwaltet (techcommunity.microsoft.com).

Zentrales Element ist der neue Parameter IsExchangeCloudManaged. Setzt man diesen auf True, übernimmt Exchange Online die Quelle der Autorität für die betreffenden Exchange-Attribute eines Benutzers (techcommunity.microsoft.com).

So funktioniert es im Detail

  • Standardmäßig ist bei synchronisierten Benutzern IsExchangeCloudManaged = False, d. h. Exchange-Attribute werden in der On-Premises-AD verwaltet und in die Cloud repliziert.
  • Wird IsExchangeCloudManaged = True, kann man Exchange-Attribute wie E-Mail-Adressen, spezielle Attribute (z. B. CustomAttribute1–15, proxyAddresses) über Exchange Online PowerShell oder das Admin Center ändern. Diese Änderungen bleiben erhalten, da der On-Prem-Sync sie nicht mehr überschreibt (learn.microsoft.com).
  • Identitätsattribute – z. B. Name, Abteilung, Telefonnummer – verbleiben weiterhin unter der Kontrolle der lokalen Active Directory und sind von der Änderung nicht betroffen (techcommunity.microsoft.com).
  • In Phase 1 (aktuell verfügbar) kann pro Postfach entschieden werden, welches Attributset cloud-gesteuert wird. Eine Rückumstellung (Rollback) ist möglich (learn.microsoft.com).
  • In einer späteren Phase (Phase 2) ist geplant, dass Änderungen an Exchange-Attributen in der Cloud automatisch wieder zurück in das lokale AD geschrieben werden („Write-Back“), vorausgesetzt, Entra Cloud Sync wird genutzt (learn.microsoft.com).
  • Bereits verfügbar ist eine object-level SOA-Übertragung für Gruppen (Group SOA); künftig sollen Attribute auch für Benutzer- und Kontaktobjekte cloud-gesteuert werden können (learn.microsoft.com).

Vorteile dieser Entwicklung

  • Endlich Exchange-Server-frei – Der „Last Exchange Server“ wird überflüssig, selbst in Hybrid-Szenarien.
  • Weniger administrative Komplexität – Verwaltung über Exchange Online PowerShell, Admin Center oder Microsoft 365 Admin Center.
  • Sicherheitsgewinn – Reduzierter On-Prem-Fußabdruck bedeutet weniger Angriffsfläche und weniger Patchaufwand.
  • Zukunftssicher – Mit geplantem Write-Back und Cloud-SOA für Gruppen und Kontakte entsteht eine echte Cloud-Zielarchitektur.

Umsetzung: So hebst du IsExchangeCloudManaged auf

  1. In Exchange Online PowerShell: Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true
  2. Status prüfen: Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged

Meine Meinung als IT-Consultant

Für viele unserer Kunden ist dies ein Herzenswunsch, der nun endlich Realität wird: weg vom letzten lokalen Exchange-Server, hin zu einer komplett cloudbasierten Verwaltung. In zahlreichen Projekten haben wir immer wieder erlebt, dass die Pflicht, einen On-Premises-Server nur für die Exchange-Verwaltung stehen zu lassen, nicht nur technisch, sondern auch organisatorisch und sicherheitsrelevant ein großes Ärgernis war. Mit den Cloud-Managed Remote Mailboxes ist diese Hürde nun gefallen – und das macht den Weg zur echten „Cloud Only“-Strategie frei.

Fazit

Mit Cloud-Managed Remote Mailboxes macht Microsoft einen bedeutenden Schritt in Richtung endgültige Ablösung des lokalen Exchange Servers – auch für hybride Umgebungen. Diese neue Funktion bündelt Verwaltung, Sicherheit und Flexibilität in der Cloud und zeigt deutlich, wie die Zukunft der Exchange-Verwaltung aussieht.

Conditional Access und Microsoft Defender for Endpoint: Ein Teufelskreis?

Eine wirkungsvolle Möglichkeit, die Sicherheit innerhalb eines Unternehmens zu erhöhen, besteht darin, den Microsoft Defender for Endpoint Status über eine Compliance-Richtlinie in den Compliance-Status für Intune verwaltete Geräte einzubinden. Auf diese Weise können gefährdete Geräte schnell identifiziert und vom Zugriff auf Unternehmensdaten ausgeschlossen werden. Dieser Ansatz schafft eine zusätzliche Schutzebene. Zusätzlich stellt dieser sicher, dass nur Geräte mit einem sicheren Status auf sensible Informationen zugreifen können. Insbesondere bei schwerwiegenden Sicherheitslücken oder Sicherheitsvorfällen ist dies eine zuverlässige Methode die Geräte bis zur Mitigation der Ursache vom Zugriff auf Unternehmensdaten zu sperren.

Dender for Endpoint in Compliance Policy
Dender for Endpoint in Compliance Policy

Allerdings kann die Verknüpfung von Microsoft Defender for Endpoint und Conditional Access Richtlinien schnell in einen Teufelskreis führen. Das passiert , wenn eine Conditional Access Regel implementiert ist, die den Zugriff für nicht kompatible Geräte blockiert. Dadurch entsteht ein Dilemma: Die betroffenen Geräte können sich nicht erneut als kompatibel registrieren. Der Grund dafür ist die Conditional Access Policy die den Zugriff sperrt. Das macht es für den Administrator schwer das Gerät, ohne ein komplettes Zurücksetzen wieder kompatibel zu bekommen.

Wie der Teufelskreis entsteht?

Standardmäßig können die beiden Microsoft Defender for Endpoint Applikationen nicht direkt aus Conditional Access Richtlinien ausgenommen werden. Die Folge ist, dass Geräte, die durch den Conditional Access blockiert werden, keine Möglichkeit haben, sich wieder als kompatibel zu registrieren. Der Zugriff auf dafür notwendige Dienste wird gesperrt, wodurch der Status „nicht kompatibel“ bestehen bleibt. Standardmäßig stehen die beiden Applikationen „MicrosoftDefenderATP XPlat“ und „Microsoft Defender for Mobile TVM app“ nicht im Conditional Access zur Auswahl.

Wie kann der Teufelskreis durchbrochen werden?

Um diesen Teufelskreis zu durchbrechen, müssen die beiden Service Principals registriert werden: „MicrosoftDefenderATP XPlat app“ (a0e84e36-b067-4d5c-ab4a-3db38e598ae2) und Microsoft Defender for Mobile TVM app (e724aa31-0f56-4018-b8be-f8cb82ca1196).

Dies funktioniert mit der Powershell mit folgendem Code:

Install-Module Microsoft.Graph

Import-Module Microsoft.Graph.Applications

 

Connect-MgGraph

$params = @{

              appId = "a0e84e36-b067-4d5c-ab4a-3db38e598ae2"

}

New-MgServicePrincipal -BodyParameter $params

$params = @{

              appId = "e724aa31-0f56-4018-b8be-f8cb82ca1196"

}

New-MgServicePrincipal -BodyParameter $params

Nach der Registrierung können die Anwendungen aus den Conditional Access Richtlinien ausgeschlossen werden. Dieser Ausschluss sorgt dafür, dass die Geräte weiterhin Zugriff auf die notwendigen Dienste haben, selbst wenn sie als nicht kompatibel markiert sind. Dadurch wird es möglich, die Geräte wieder als kompatibel zu registrieren und den Zugriff zu normalisieren.

Defender for Endpoint aus Conditional Access Policy ausschließen.
Defender for Endpoint aus Conditional Access Regel ausschließen

Fazit

Mit diesem Trick kann der Teufelskreis durchbrochen werden und die Geräte erhalten wieder Zugriff auf die M365 Dienste, sobald die Compliance wiederhergestellt ist. Auch bleibt während der Non-Compliance die Kommunikation mit dem Defender for Endpoint bestehen und wird nicht „abgeschnitten“. Das erhöht die Sicherheit und hilft dabei das Potential des Defender for Endpoints bestmöglich zu nutzen. Der Defender for Endpoint Status kann unter anderem in den Compliance Policies für Windows, iOS und Android genutzt werden.

Exchange Server 2025: Was Sie bei der Migration zur Subscription Edition beachten müssen

Im Mai 2024 hat Microsoft seine Exchange Server Roadmap vorgestellt und die Pläne für die Zukunft von Exchange Server veröffentlicht. Siehe Neuerungen in der Exchange Server Roadmap: Neueste Updates zur Exchange Server Roadmap: Entdecken Sie CU15 und Exchange Server SE

Mit dem bevorstehenden Release der Exchange Server Subscription Edition (SE) ab 2025 stellt Microsoft wichtige Neuerungen und Anforderungen für Organisationen vor, die ältere Versionen von Exchange Server nutzen. Die Migration zu Exchange SE ist entscheidend, da ältere Versionen wie Exchange 2016 und 2019 nur noch begrenzt unterstützt werden. In diesem Artikel erfahren Sie, wie Sie Ihre Organisation optimal auf das Upgrade vorbereiten.

Die Roadmap

Zur besseren zeitlichen Darstellung, hier ist eine Tabelle, die diese Veröffentlichungen und ihre Auswirkungen auf die Koexistenz mit früheren Versionen zusammenfasst:

NameErscheinungsdatumDetailsKoexistenz
Exchange Server 2019 CU15Zweite Halbjahr 2024Finales CU für Exchange Server 2019. Codeparität mit Exchange Server SE RTM (mit Ausnahme von SUs, die vor Exchange SE RTM veröffentlicht wurden)Keine Koexistenz mit Exchange 2013
(Installation wird durch CU15-Setup blockiert)
Exchange Server SE RTMAnfang zweite Halbjahr 2025Ermöglicht ein direktes Upgrade von Exchange 2019 CU14 oder CU15. Codeparität mit Exchange 2019 CU15 + alle SUs, die seit CU15 veröffentlicht wurden (keine neuen Features oder andere Codeänderungen)Keine Koexistenz mit Exchange 2013
(Installation wird durch RTM-Setup blockiert)
Exchange Server SE CU1Ende zweite Halbjahr 2025Erste Einführung neuer Funktionen in Exchange Server SEKeine Koexistenz mit Exchange 2013, Exchange 2016 oder Exchange 2019 (Installation durch CU1-Setup blockiert)
Übersicht Roadmap

Supportstatus von Exchange Server-Versionen

In der folgenden Tabelle werden die letzten drei Versionen von Exchange, ihre LifeCycle und die Auswirkungen der oben genannten Versionen dargestellt:

Exchange VersionEnd of SupportAb 2019 CU15Ab Exchange SE RTMAb Exchange SE CU1
Exchange 201311.04.2023not supportednot supportednot supported
Exchange 201614.10.2025Extended SupportExtended SupportNot supported
Exchange 2019 CU14.10.2025Extended SupportExtended SupportNot supported
Übersicht Support

Alle anderen Versionen und Builds von Exchange Server werden nicht unterstützt, mit Ausnahme von Exchange 2019 CU13, das mit der Veröffentlichung von Exchange 2019 CU15 nicht mehr unterstützt wird.

Koexistenz verschiedener Versionen in derselben AD Organisation

Microsoft nimmt gravierende Änderungen in Exchange Server vor, die sich auf die Koexistenz mit älteren Versionen in derselben Organisation (Forest) auswirken. In der Vergangenheit war es möglich, eine ältere (und sogar nicht unterstützte) Version von Exchange Server in einer Organisation mit neueren Versionen von Exchange Server weiterhin auszuführen. Wir IT-Consultants sprachen gerne von einer N-2 Versionskoexistenz. Dies bedeutet, in der Vergangenheit wurden die aktuelle und zwei vorherige Versionen innerhalb einer AD Organisation unterstützt.

Dies ändert sich in zweierlei Hinsicht:

  • Das Setup in Exchange Server 2019 CU15 und Exchange Server SE RTM blockiert die Koexistenz mit Exchange Server 2013.
  • Das Setup in Exchange Server SE CU1 blockiert die Koexistenz mit allen nicht unterstützten Versionen (z. B. Exchange Server 2013, Exchange Server 2016, Exchange Server 2019) und lässt die Koexistenz nur mit Exchange Server SE zu.

Wichtig: Wenn Exchange Server SE CU1 veröffentlicht wird, wird der Support für alle anderen Versionen von Exchange Server eingestellt. Wie in der folgenden Tabelle beschrieben, müssen Sie zum Installieren von CU1 (oder höher) zunächst alle älteren Versionen von Exchange Server außer Betrieb nehmen und ordnungsgemäß aus Ihrer Organisation entfernen.

Was Sie nun unternehmen sollten

Um auf Exchange Server SE zu aktualisieren, haben Sie verschiedene Optionen.

Da Exchange 2013 bereits sein „End of Life“ erreich hat, sollten Sie bereits Exchange Server 2016 CU23 oder Exchange Server 2019 CU13/CU14 nutzen. Falls Sie eine frühere Version von Exchange 2016 einsetzen, ist ein sofortiges Update auf CU23 erforderlich. Für Exchange 2019 Kunden wird CU14 empfohlen, jedoch wird auch CU13 noch unterstützt.

Wenn Sie ältere Versionen wie Exchange 2013 oder noch älter betreiben, sollten Sie entweder auf Exchange Online migrieren oder ein Upgrade auf Exchange Server 2019 mit dem neuesten Cumulative Update in Betracht ziehen.

Warum sollten wir unsere Server aktualisieren, wenn es keine neuen Features gibt?

Microsoft wird den Support für Exchange Server 2016 und 2019 am 14. Oktober 2025 einstellen. Um ein direktes und unkompliziertes Upgrade von Exchange Server 2019 zu ermöglichen, wurden neue Funktionen entweder bereits in Exchange Server 2019 CU15 integriert oder für Exchange Server SE CU1 und höher vorbereitet.

Der Wechsel zu Exchange Server SE RTM führt zu einem Update des Brandings sowie neuen Lebenszyklus- und Supportrichtlinien. Nach der Veröffentlichung von Exchange SE CU1 werden ältere Versionen nicht mehr unterstützt, und Microsoft führt ab CU1 neue Funktionen für Exchange Server ein.

Intune schneller als GPOs?

Bisher hatte die Verwaltung von Richtlinien für Windows Geräte über Intune einen entscheidenden Nachteil gegenüber GPOs. Der Refresh Zyklus von 8 Stunden. So werden bisher die MDM-Richtlinien nur alle 8 Stunden aktualisiert. Die GPOs jedoch alle 90 Minuten. Mit dem neuen Feature Config Refresh ist das nun Vergangenheit und der Aktualisierungszeitraum für Intune Richtlinien lässt sich anpassen. Mit diesen Anpassungen ist Intune schneller als GPOs!

Was ist der Config Refresh?

Config Refresh ist eine Funktion, die für Windows 11 ab dem Juni 2024 Security Update verfügbar ist. Es ermöglicht, die Häufigkeit der Aktualisierung von MDM-Richtlinien zu konfigurieren. Dies ist wichtig, um sicherzustellen, dass die Einstellungen nicht von den vorgesehenen Richtlinien abweichen. Aber auch, dass Konfigurationsanpassungen schnell auf den Endgeräten ankommen.

Die Vorteile von Config Refresh

Mit Config Refresh können Administratoren die Aktualisierungszeit der Richtlinien auf ein Intervall zwischen 30 Minuten und 24 Stunden einstellen. Zu den weiteren Schlüsselfunktionen von Config Refresh gehören:

  • Eine Reset-Operation, um die Einstellungen, die über den Policy CSP verwaltet werden, zurückzusetzen
  • Offline-Funktionalität
  • Pausieren von Config Refresh für Troubleshooting

Die Konfiguration des Config refresh und des Aktualisierungsintervall findet sich bereits innerhalb des Settings catalog:

Intune Settings catalog: Einstellung für ein schnelleres Intune
Intune Settings catalog: Einstellung für ein schnelleres Intune

Ein benutzerdefiniertes Profil ermöglicht die Konfiguration der Pause. Der Entsprechende Key lautet:

./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/ConfigRefresh/PausePeriod

Gültige Werte sind eine Zahl zwischen 0 und 1440 Minuten (24 Stunden).

Wichtiger Hinweis

Der Config Refresh ist für MDM-Richtlinien konzipiert, die durch den Policy CSP verwaltet werden. Einige Richtlinien, insbesondere der BitLocker CSP, werden ebenfalls Config Refresh-Regeln folgen. Andere Richtlinien, wie Firewall, AppLocker, PDE und LAPS, fallen nicht in diesen Bereich!

Fazit

Ein interessantes Feature und weiterer Pluspunkt Policies über Intune, anstatt GPOs zu konfigurieren. Neben dem Vorteil Statusmeldungen zu den Policies zu erhalten und der Tatsache, dass eine Verbindung zum Internet ausreichend ist, um eine Policy-Änderungen auf ein Gerät anzuwenden. Bei den klassischen GPOs ist hierfür immer eine Verbindung zum Domain Controller erforderlich. Nun sind ist Intune auch deutlich schneller als die klassischen GPOs.

Microsoft MFA für alle Benutzer ab Juli 2024?

Eigentlich sollte sie bereits für jeden Microsoft 365 Benutzer aktiv sein, die Multi Faktor Authentifizierung (MFA). Trotzdem hat Microsoft mit der Ankündigung MFA für alle Benutzer anzufordern für Aufregung gesorgt (Microsoft will require MFA for all Azure users). Insbesondere da es Gründe für bestimmte Benutzer bestehen, keine MFA zu forcieren. Hierunter fallen z.B. Service Benutzer oder auch bestimmte Benutzergruppen.

Die Ankündigung wurde mittlerweile präzisiert und es betrifft nur Benutzer, die auf folgende Anwendungen zugreifen:

  • Azure portal
  • Microsoft Entra admin center
  • Azure PowerShell
  • Azure CLI
  • Terraform für die Administration von Azure

Auf die genannten Anwendungen greifen in der Regel nur Benutzer zu, die administrative Vorgänge durchführen. Vom MFA-Zwang ausgenommen werden sollen: Dienstprinzipalobjekte, verwaltete Identitäten, Workload-Identitäten und weitere tokenbasierte Konten. Microsoft sammelt hier auch noch weiteren Input für weitere Szenarien, wie z.B. Break-Glass Administratoren. Diese sind als Best-Practise ohne MFA empfohlen, um im Notfall weiterhin Zugang zum Tenant zu bieten.

Wie setzt Microsoft die Anforderung technisch um?

Dazu gibt es leider noch keine konkrete Aussage. Ich vermute allerdings, dass dies über eine von Microsoft verwaltete Regel des bedingten Zugriffs realisiert wird. In der Technet zu den von Microsoft verwalteten Richtlinien (Secure your resources with Microsoft-managed Conditional Access policies – Microsoft Entra ID | Microsoft Learn), findet sie die folgende Regel, die stark an die Ankündigung von Microsoft erinnert: „Require multifactor authentication for Azure management.“

Welche Aufgaben ergeben sich hieraus?

  • Prüfen der Sign-in Logs auf die oben genannten Anwendungen, um die betroffenen Benutzer, insbesondere Service Benutzer zu identifizieren.
  • Registrieren der MFA für alle Benutzer, die auf die oben genannten Anwendungen zugreifen.
  • Bei allen klassischen Service Benutzern die Möglichkeit prüfen, diese auf tokenbasierte Konten umzustellen.
  • Falls es über eine von Microsoft verwaltete Richtlinie realisiert wird, unbedingt die Break Glass Admins ausschließen.

Fazit

Zusammenfassend handelt es sich um eine sinnvolle Maßnahme um die Sicherheit der Tenants zu erhöhen. Noch immer gibt es viele ungesicherte Konten mit kritischen Zugriffen. Für diese soll nun die MFA aktiviert werden. Auch sind viele Service Accounts im Einsatz, die längst durch tokenbasierte Konten ersetzt werden könnten. Leider ist die ist die Kommunikation recht kurzfristig und vage.

Neuer Missbrauch der DHCP-Administratorengruppe zur Erweiterung der Privilegien in Windows-Domänen

Als IT-Consultant möchte ich Sie, die IT-Administratoren, über eine kritische Sicherheitsbedrohung informieren, die die DHCP-Administratorengruppe in Windows-Domänen betrifft. Dieses Risiko könnte unzureichend abgesicherte DHCP-Server in Machtinstrumente für Angreifer verwandeln, die vollständige Domain-Übernahmen anstreben.

Was Sie wissen müssen: Die DHCP-Administratorengruppe kann in einigen Fällen dazu missbraucht werden, erweiterte Berechtigungen innerhalb einer Windows-Domäne zu erlangen. Dies geschieht durch das Manipulieren von DHCP-Optionen, die eigentlich dazu dienen, Netzwerkkonfigurationen zu verteilen.

Wie genau funktioniert der Angriff?

Der Angriff mittels der DHCP-Administratorengruppe für Privilegienerweiterung in Windows-Domänen erfolgt durch die missbräuchliche Verwendung der DHCP-Konfigurationsmöglichkeiten. Angreifer, die Zugang zur DHCP-Administratorengruppe haben, können spezielle DHCP-Optionen manipulieren. Ein kritischer Punkt dabei ist die Veränderung der DNS-Servereinstellungen über DHCP, was es ermöglicht, DNS-Anfragen umzuleiten. Dies kann zu einer Maschine-im-Mittelpunkt (MITM)-Attacke führen, bei der der Angreifer DNS-Anfragen abfängt oder manipuliert, um weitergehende Angriffe wie Kerberos-Authentifizierungsumleitungen durchzuführen. Solche Angriffe ermöglichen eine Eskalation der Privilegien bis hin zur Übernahme eines Domain Controllers, wenn der DHCP-Server auf diesem installiert ist.

Ein kritischer Aspekt dieses Angriffs auf die DHCP-Administratorengruppe ist, dass er auf legitimen Konfigurationsmöglichkeiten beruht und keine direkten Schwachstellen ausnutzt. Daher existiert keine einfache „Fix“ oder Patch, um diese Angriffsart zu unterbinden.

Präventionsmaßnahmen

In der Welt der Netzwerksicherheit ist die korrekte Platzierung und Verwaltung von Rollen innerhalb einer Active Directory (AD)-Umgebung entscheidend, um Sicherheitsrisiken zu minimieren. Ein häufig übersehener, aber kritischer Aspekt ist die Trennung von Diensten durch das AD Tiering Modell, speziell die Positionierung der DHCP-Rolle in Bezug auf Domain Controller (DC).

Das Risiko einer inkorrekten Rollenverteilung: Wenn der DHCP-Dienst auf einem Domain Controller installiert ist, öffnet dies Tür und Tor für potenzielle Angriffe. Angreifer, die Zugriff auf die DHCP-Administratorengruppe erlangen, können diese Position nutzen, um weitreichende Privilegien innerhalb der Domäne zu eskalieren. Diese Gefahr wird durch die Nutzung von DHCP-Optionen verstärkt, die manipuliert werden können, um bösartige Netzwerkkonfigurationen zu verbreiten oder unerlaubte DNS-Updates zu initiieren.

Die Lösung durch AD Tiering: Ein gut durchdachtes AD Tiering Modell bietet eine effektive Strategie, um solche Risiken zu mindern.

Im idealen Modell:

  • Tier 0 umfasst die Domain Controller und andere kritische Infrastrukturkomponenten, die die höchsten Sicherheitsanforderungen haben.
  • Tier 1 sollte Dienste wie DHCP beherbergen, die zwar wichtig sind, aber eine klare Trennung von den Kernkomponenten des Active Directory benötigen.

Durch die Einhaltung dieses Modells wird verhindert, dass DHCP-Administratoren Zugriff auf die kritischsten Bereiche der IT-Infrastruktur erhalten und somit das Risiko einer Privilegienerweiterung drastisch reduziert.

Schritte zur Implementierung und Überwachung:

  1. Überprüfung der aktuellen Infrastruktur: Identifizieren Sie alle Instanzen, in denen DHCP-Dienste auf Domain Controllern laufen, und planen Sie deren Migration.
  2. Einrichtung von Zugriffsbeschränkungen: Stellen Sie sicher, dass nur autorisierte Benutzer Zugriff auf kritische Systeme im Tier 0 haben.
  3. Regelmäßige Überwachung und Anpassungen: Überwachen Sie die Einhaltung des Tiering-Modells und passen Sie die Zugriffsrechte kontinuierlich an.

Fazit: Die strikte Trennung von Diensten nach dem AD Tiering Modell ist ein wesentlicher Bestandteil einer robusten Sicherheitsstrategie. Indem Sie sicherstellen, dass kritische und weniger kritische Systeme ordnungsgemäß isoliert sind, stärken Sie die Sicherheit Ihrer gesamten IT-Infrastruktur und minimieren das Risiko von Sicherheitsvorfällen, die durch eine falsche Rollenzuweisung entstehen könnten. Mehr zum Tiering Model finden Sie hier:

AD Tiering Struktur – Funktion und Nutzen

Neuerungen in der Exchange Server Roadmap: Neueste Updates zur Exchange Server Roadmap: Entdecken Sie CU15 und Exchange Server SE

Die aktuelle Roadmap für den Exchange Server von Microsoft enthält wichtige Updates, die erhebliche Auswirkungen auf die zukünftige Planung und Verwaltung der IT-Infrastruktur in Unternehmen haben. Für IT-Entscheider und Administratoren ergeben sich daraus spezifische Handlungsanweisungen und Überlegungen.

Hier sind die wesentlichen Neuerungen und deren zeitliche Einordnung:

Wichtige Entwicklungen und Zeitplan

  1. Letztes Kumulatives Update für Exchange Server 2019:
    • Im zweiten Halbjahr 2024 wird das finale kumulative Update (CU15) für den Exchange Server 2019 veröffentlicht. Dieses Update wird wichtige Funktionen einführen, die auf die Unterstützung der RTM-Version des Exchange Server Subscription Edition (SE) abzielen.
  2. Einführung des Exchange Server Subscription Edition:
    • Anfang des dritten Quartals 2025 wird der Exchange Server SE veröffentlicht, gefolgt vom ersten kumulativen Update (CU1) Ende 2025. Diese neue Edition erfordert Abonnement-Lizenzen oder Lizenzen mit aktiver Software Assurance für Server und Benutzerlizenzen.
  3. Kostenloser Exchange Hybrid Server:
    • Microsoft wird weiterhin eine kostenlose Lizenz für den Hybrid Server anbieten, die über den Hybrid Configuration Wizard verfügbar ist. Dies unterstreicht das Engagement von Microsoft, Hybrid- und On-Premises-Lösungen zu unterstützen.
  4. Technische Updates und Sicherheitsverbesserungen:
    • CU15 führt die Unterstützung für TLS 1.3 ein, um die Sicherheit zu verbessern, indem veraltete kryptografische Algorithmen eliminiert werden. Zudem wird die Zertifikatsverwaltung im Exchange Admin Center (EAC) wieder eingeführt, was Administratoren die Verwaltung von Zertifikaten erleichtert.
  5. Unterstützung für neue Betriebssysteme:
    • Exchange Server 2019 CU15 wird auch Windows Server 2025 unterstützen, sobald dieses Betriebssystem allgemein verfügbar ist.

Strategische Bedeutung und Umsetzung

Diese Entwicklungen erfordern eine sorgfältige Planung und Umsetzung durch IT-Entscheider und Administratoren:

  • Planung der Migration: Unternehmen, die derzeit Exchange 2013 verwenden, müssen vor der Installation von Exchange 2019 CU15 oder SE ihre Systeme von Exchange 2013 entfernen, da die Unterstützung für die Koexistenz mit Exchange 2013 entfernt wird.
  • Lizenzmanagement: Die Umstellung auf Exchange Server SE erfordert neue Produktlizenzen, außer für Hybrid-Server, die weiterhin kostenlos über den Hybrid Configuration Wizard lizenziert werden.
  • Sicherheitsstrategie aktualisieren: Die Einführung von TLS 1.3 und die fortlaufenden Updates sollen die Sicherheit von Exchange Server weiter stärken und Unternehmen helfen, ihre Daten effektiv zu schützen.

Zusammenfassung

Die jüngsten Ankündigungen von Microsoft bieten eine klare Richtung für die Zukunft des Exchange Servers, mit einem starken Fokus auf Sicherheit, Unterstützung neuer Technologien und die Flexibilität durch das Abonnementmodell. Unternehmen sind gut beraten, diese Entwicklungen in ihre IT-Strategie zu integrieren, um die Vorteile der neuen Funktionen voll auszuschöpfen und gleichzeitig Compliance und Sicherheit zu gewährleisten.

Cookie Consent mit Real Cookie Banner