Microsoft Entra im August 2026: Cloud Sync übernimmt Geräte, Governance wird automatisch

Stand: 12. August 2026

Wenn ich mir die Entra-Neuerungen dieses Monats ansehe, fällt mir vor allem eines auf: Microsoft räumt gerade sehr systematisch die Gründe weg, aus denen wir bei Kunden bisher lokale Infrastruktur betreiben mussten. Einzeln betrachtet sind das kleine Features. In Summe verschiebt sich die Architektur.

Und es geht dabei längst nicht mehr nur um Benutzerkonten und Single Sign-on. Entra wird zunehmend zur Steuerungsebene für hybride Identitäten, Geräte, externe Benutzer und deren gesamten Lebenszyklus.

Auf einen Blick

Cloud Sync synchronisiert jetzt Computerobjekte aus dem lokalen Active Directory. Damit fällt der letzte große Funktionsunterschied zu Entra Connect Sync weg.
Exchange-Attribut-Writeback ist allgemein verfügbar und skaliert auf bis zu 600.000 cloudverwaltete Mailboxen pro Tenant.
Sponsorlose Gastkonten lassen sich über Lifecycle Workflows automatisiert erkennen und bereinigen.
Entra External ID akzeptiert Registrierungen über externe Identity Provider jetzt auch ohne E-Mail-Adresse.
Microsoft vergibt seit Juli 2026 Transition-Windows für den Wechsel auf Cloud Sync, zunächst aber nur an einfach aufgebaute Tenants. Wer Funktionen nutzt, die Cloud Sync nicht abdeckt, bleibt vorerst bewusst auf Connect Sync.
Der 30. September 2026 ist kein Abschaltdatum für Connect Sync, sondern eine Mindestversions-Frist. Die beiden Themen werden derzeit häufig verwechselt.

Neuerung	Status	Betrifft
Device Sync in Entra Cloud Sync	Public Preview	Hybrid-AD-Umgebungen mit Hybrid Join
Exchange-Attribut-Writeback über Cloud Sync	Allgemein verfügbar (GA)	Exchange-Hybrid-Umgebungen
Erkennung sponsorloser Gäste in Lifecycle Workflows	Public Preview	B2B-Kollaboration, ID Governance
E-Mail optional im User Flow (External ID)	Allgemein verfügbar	CIAM, Kunden- und Partnerportale
GPO Backup/Restore in Entra Domain Services	Public Preview	Entra Domain Services
Automatische SSO-Genehmigung auf verwalteten Geräten	Allgemein verfügbar	Windows 11, ab Patchday Juli 2026

Entra Cloud Sync synchronisiert jetzt Geräte aus dem Active Directory

Technisch ist das für mich die spannendste Neuerung des Monats.

Cloud Sync war bisher auf Benutzer, Gruppen und Kontakte beschränkt. Microsoft positioniert den Dienst schon länger als die moderne, cloudverwaltete Alternative zu Entra Connect Sync, aber in Beratungsgesprächen kam an dieser Stelle immer der gleiche Einwand: „Wir brauchen aber Hybrid Join.“ Damit war die Diskussion regelmäßig beendet.

Genau das ändert sich jetzt. Computerobjekte lassen sich aus dem lokalen Active Directory nach Entra ID synchronisieren, anschließend können die Geräte einen Entra Hybrid Join durchführen. Die Funktion steckt in der Public Preview und ist standardmäßig deaktiviert. Technisch läuft sie über einen AD2AADDeviceSync-Job innerhalb einer bestehenden AD-zu-Entra-ID-Konfiguration.

Voraussetzungen für Device Sync

Bevor Sie das im Lab ausprobieren, lohnt ein Blick auf die Anforderungen laut Microsoft Learn:

Microsoft Entra Provisioning Agent in der Version 1.1.1107 oder neuer
eine bestehende AD-zu-Entra-ID-Cloud-Sync-Konfiguration
die Tenant-ID sowie die verifizierte Domäne, mit der sich die Geräte authentifizieren. Bei föderierten Umgebungen ist das die föderierte Domäne, sonst die primäre *.onmicrosoft.com-Domäne.
einen konfigurierten Service Connection Point (SCP). Dafür brauchen Sie temporär ein Konto mit Enterprise-Admin-Rechten in jeder betroffenen Gesamtstruktur.
mindestens die Rolle Hybrid Identity Administrator für die Konfiguration im Entra Admin Center

Einzelne Geräte lassen sich über Provision on demand im Device-Tab testen, alternativ können Sie den gesamten Vorgang über Microsoft Graph steuern. Für einen ersten Test empfehle ich eine dedizierte OU mit einer Handvoll Rechnern, nicht die Produktiv-OU.

Warum das für Hybrid-Identity-Architekturen wichtig ist

Für Kunden mit klassischer AD-Infrastruktur ist das ein größerer Schritt, als es zunächst klingt.

Die fehlende Gerätesynchronisation war für viele Organisationen der letzte verbleibende Grund, Entra Connect Sync überhaupt weiterzubetreiben. Mit der Preview fällt genau dieses Argument weg.

Nebenbei verschwindet damit auch ein Stück Angriffsfläche. Ein Entra-Connect-Server hält Zugriff auf die Anmeldeinformationen und Attribute sämtlicher synchronisierter Objekte und gehört deshalb zwingend nach Tier-0. Wie relevant das in der Praxis ist, hat der Angriff über Azure AD Connect gezeigt, bei dem genau dieser Server als Brücke zwischen lokaler und Cloud-Umgebung missbraucht wurde. Cloud Sync ersetzt den schwergewichtigen Server durch leichtgewichtige Agents. Das macht die Architektur nicht automatisch sicher, verkleinert aber den Blast Radius eines einzelnen Systems spürbar.

Trotzdem, und das sage ich meinen Kunden derzeit sehr deutlich: Cloud Sync ist noch kein vollständiger Ersatz. Diese Funktionen bleiben vorerst Entra Connect Sync vorbehalten:

Funktion	Entra Connect Sync	Entra Cloud Sync
Benutzer, Gruppen, Kontakte	Ja	Ja
Geräte, Hybrid Join	Ja	Preview
Erweiterte Synchronisationsregeln	Ja	Nein
Vollständiges attributbasiertes Filtering	Ja	Eingeschränkt
Sehr große Objektmengen	Ja	Skalierungsgrenzen beachten
Getrennte Gesamtstrukturen ohne Konnektivität	Nein	Ja
Lokale SQL-Datenbank erforderlich	Ja	Nein

Für neue Deployments und anstehende Modernisierungsprojekte gehört Cloud Sync klar auf die Architektur-Roadmap. Eine laufende, saubere Entra-Connect-Installation würde ich deswegen aber nicht anfassen, solange sie tut, was sie soll.

Cloud Sync ist das Zielbild, aber niemand muss jetzt migrieren

Vorweg, weil hier gerade sehr viel Halbwissen kursiert: Sie müssen Ihren Entra Connect Sync nicht ablösen. Der Dienst läuft weiter, wird weiter unterstützt und lässt sich in einer aktuellen Version völlig regulär betreiben, auch über den Herbst hinaus.

Was Microsoft im April 2026 angekündigt hat, ist ein begleiteter Übergang in Wellen. Seit Juli 2026 erfahren Tenants über das Microsoft 365 Message Center, über Entra Connect Health und per E-Mail ihren individuellen Transition-Zeitplan.

Entscheidend ist dabei, wer in den ersten Wellen überhaupt angesprochen wird, nämlich Tenants, deren Synchronisationsbedarf Cloud Sync heute schon vollständig abdeckt. Also einzelne Gesamtstruktur, Standard-Attributflüsse, keine exotischen Regeln. Wer erweiterte Funktionen nutzt oder ein großes Verzeichnis betreibt, gehört ausdrücklich nicht dazu und wird erst kontaktiert, wenn Cloud Sync die entsprechenden Szenarien beherrscht.

Ehrlich muss man allerdings auch sagen: Freiwillig ist der Wechsel nur auf Sicht. Microsoft formuliert Cloud Sync als Zielarchitektur für alle Kunden, und die Benachrichtigungen fragen nicht nach Interesse, sie teilen ein Zeitfenster zu. Für komplexe Umgebungen reden wir dabei aber über einen Zeitraum von Jahren, nicht von Monaten.

Für die Praxis heißt das zweierlei. Ist Ihre Konfiguration schlicht, kann die Nachricht mit Ihrem Zeitfenster jederzeit eintreffen, dann lohnt sich ein Pilot besser jetzt als unter Termindruck. Haben Sie dagegen eine Abhängigkeit, die Cloud Sync nicht abbildet, bleiben Sie bewusst auf Connect Sync, dokumentieren den Blocker und behalten die Feature-Vergleichsliste im Auge. Beides ist eine völlig legitime Entscheidung. Nur die Inventur Ihrer Sync-Konfiguration sollten Sie in beiden Fällen nicht aufschieben, die dauert erfahrungsgemäß deutlich länger als die eigentliche Umstellung.

Nicht verwechseln: Der 30. September 2026 ist kein Abschaltdatum für Connect Sync

Rund um dieses Thema kursieren derzeit zwei Termine, die regelmäßig durcheinandergeworfen werden. Es handelt sich aber um zwei völlig unabhängige Vorgänge.

Erstens die Härtungsfrist am 30. September 2026. Microsoft hat im Mai 2025 die Version 2.5.79.0 von Entra Connect Sync veröffentlicht, die eine Backend-Service-Änderung zur Absicherung enthält. Wer bis zum Stichtag nicht mindestens auf dieser Version ist, bei dem stellen sämtliche Synchronisationsdienste den Betrieb ein, und zwar so lange, bis das Upgrade nachgeholt wird. Der Effekt ist also reversibel. Es handelt sich um eine Mindestversions-Anforderung, nicht um eine Abkündigung des Produkts.

Wichtig dabei: 2.5.79.0 ist lediglich das Minimum. Aktuell ist Version 2.6.84.0 vom 7. Juli 2026, die zusätzlich Security-Fixes enthält. Die zwischenzeitlich veröffentlichte 2.6.79.0 wurde nach dem Release zurückgezogen, wer sie installiert hat, muss deinstallieren und die aktuelle Version einspielen. Und noch ein Punkt, der oft falsch verstanden wird: Der Stichtag bezieht sich ausschließlich auf die Connect-Sync-Version, nicht auf die Windows-Server-Version des Sync-Servers.

Zweitens der Übergang auf Cloud Sync. Dieser Vorgang hat weder ein Enddatum noch einen Stichtag. Es ist ein begleiteter Übergang in Wellen, keine erzwungene Umstellung.

Wer am 1. Oktober 2026 auf einer aktuellen Connect-Sync-Version läuft, synchronisiert also unverändert weiter. Die Migration auf Cloud Sync bleibt ein Architekturprojekt mit eigenem Zeitplan und ist kein Notfall, der an diesem Datum hängt.

Sponsorlose Gastkonten automatisch erkennen und löschen

Kommen wir zu Entra ID Governance und zu einem Thema, das mir in fast jedem Tenant-Assessment begegnet: externe Benutzer.

Gastkonten sind in vielen Microsoft-365-Umgebungen ein unterschätztes Sicherheitsproblem. Ein externer Kollege wird für ein Projekt eingeladen, bekommt Zugriff auf Teams, SharePoint oder eine Enterprise Application, und irgendwann endet das Projekt. Ohne funktionierenden Governance-Prozess bleibt das Konto danach noch Monate oder Jahre bestehen. Ich habe Tenants gesehen, in denen mehr als die Hälfte der Gastkonten seit über einem Jahr keine Anmeldung mehr aufwies.

Besonders problematisch sind sponsorlose Gäste, also externe Benutzer, für deren Zugriff im Unternehmen niemand mehr verantwortlich ist.

Microsoft erweitert dafür die Lifecycle Workflows. Sie können Prozesse aufbauen, die solche Konten erkennen und anschließend automatisiert behandeln, inklusive einer neuen Preview-Aufgabe, mit der sich Benachrichtigungen über die bevorstehende Entfernung sponsorloser Gäste versenden lassen.

Im selben Update sind weitere Lifecycle-Workflow-Funktionen dazugekommen: ein What-if-Modus zur Simulation von Workflows, das Abbrechen laufender Ausführungen sowie die Aufgabe User Attribute Updates, mit der sich bis zu zehn Attribute automatisiert setzen oder leeren lassen. Gerade der What-if-Modus ist eine sinnvolle Ergänzung, wenn man Workflows baut, die am Ende Konten löschen.

Wichtig: Guest Governance ist seit Januar 2026 kostenpflichtig

Bevor Sie solche Workflows planen, sollten Sie die Abrechnungssituation kennen. Dieser Punkt sorgt aktuell für die meisten Überraschungen.

Seit dem 30. Januar 2026 verlangt Microsoft für Guest-Governance-Funktionen in Entra ID Governance eine verknüpfte Azure-Subscription. Ohne diese Verknüpfung lassen sich gastbezogene Richtlinien nicht mehr anlegen oder aktualisieren. Betroffen sind unter anderem Access Reviews mit Gästen im Scope, Entitlement-Management-Richtlinien mit Sponsor-Genehmigern und Lifecycle Workflows, deren Ausführungsbedingungen userType eq 'Guest' enthalten.

Abgerechnet wird pro monatlich aktivem Gastbenutzer, wobei ein Gast pro Monat nur einmal berechnet wird, auch wenn mehrere Governance-Aktionen greifen. Wenn Sie 2.000 Gastkonten automatisiert bereinigen wollen, kalkulieren Sie diese Kosten also besser vorab durch.

Identity Governance wird damit operativer

Genau darin liegt für mich die eigentliche Entwicklung.

Identity Governance war lange gleichbedeutend mit regelmäßigen Access Reviews und Genehmigungsprozessen. Microsoft baut daraus zunehmend automatisierte Lifecycle-Prozesse.

Das Ziel kann schließlich nicht sein, einmal pro Quartal eine Excel-Liste mit 2.000 Gastkonten durchzugehen. Gute Governance heißt, dass unnötige Berechtigungen möglichst automatisch auffallen und verschwinden.

Wer viele Dienstleister, Projektpartner oder B2B-Kollaborationen hat, sollte deshalb prüfen, wie belastbar die eigenen Sponsor- und Guest-Prozesse tatsächlich sind.

Der Sicherheitsaspekt ist dabei nicht theoretisch. Die Analyse der Gruppe Storm-2949 hat gezeigt, dass moderne Cloud-Angriffe selten über spektakuläre Exploits laufen, sondern über vergessene Identitäten, überprivilegierte Konten und fehlende Governance. Ein Gastkonto ohne Sponsor ist genau so ein Kandidat.

Entra External ID: Registrierung ohne E-Mail-Adresse

Auch Entra External ID wird flexibler.

Bei der Registrierung über einen externen OpenID-Connect-Identity-Provider war bisher eine E-Mail-Adresse erforderlich. Lieferte der Provider keinen entsprechenden Claim, schlug die Registrierung schlicht fehl. Wer schon einmal einen branchenspezifischen IdP angebunden hat, kennt diesen Fehler vermutlich.

Microsoft erlaubt nun, die E-Mail-Adresse auf Ebene des User Flows optional zu machen. Benutzer können sich dadurch allein über ihre Identität beim angebundenen Provider registrieren. Fehlt der Claim und ist das Attribut als optional konfiguriert, wird das Konto ohne E-Mail-Adresse angelegt.

Das klingt nach einer Kleinigkeit, erweitert die möglichen CIAM-Szenarien aber erheblich. Nicht jedes Identitätssystem nutzt die E-Mail-Adresse als primäres Identifikationsmerkmal. In Kundenportalen, Mitgliederplattformen oder bei nationalen eID- und Banking-Identitäten sind Kundennummern oder Mitgliedskennungen oft deutlich relevanter.

Ein Hinweis aus der Praxis: Wenn Sie die E-Mail-Adresse in einem User Flow optional machen, betrifft das alle Anwendungen, die diesen User Flow verwenden. Testen Sie die Änderung deshalb vor dem produktiven Rollout, sonst fällt es Ihnen an der falschen Stelle auf die Füße.

Exchange-Attribute aus der Cloud verwalten, jetzt allgemein verfügbar

Diese Neuerung dürfte vor allem Administratoren klassischer Hybrid-Exchange-Umgebungen interessieren, und sie hat den Preview-Status inzwischen verlassen.

Phase 1 verschiebt die Source of Authority für Exchange-spezifische Attribute eines synchronisierten Benutzers in die Cloud. Gesteuert wird das pro Postfach über IsExchangeCloudManaged = $true. Identitätsattribute wie Name, Abteilung und Anmeldename kommen weiterhin aus dem lokalen Active Directory, während Exchange-Eigenschaften über Exchange Online, das Exchange Admin Center oder Exchange Online PowerShell verwaltet werden. Der Schritt lässt sich jederzeit zurücknehmen, was die Sache angenehm risikoarm macht.

Phase 2 ergänzt das Writeback. Änderungen an unterstützten Exchange-Attributen werden über Cloud Sync zurück ins lokale Active Directory geschrieben. Ändert sich beispielsweise eine Proxy-Adresse in Exchange Online, landet der neue Wert automatisch im AD. Lokale Line-of-Business-Anwendungen, die Exchange-Attribute direkt aus dem Verzeichnis lesen, arbeiten damit weiter mit aktuellen Daten. Und solche Anwendungen gibt es in der Praxis deutlich häufiger, als die Dokumentation vermuten lässt.

Die wichtigsten Eckdaten laut Microsoft Learn und dem GA-Announcement:

Unterstützung für bis zu 600.000 cloudverwaltete Mailboxen pro Tenant, in der Preview lag die Grenze noch bei 200.000
verfügbar in Commercial, GCC High, DoD und 21Vianet
Writeback erfordert zwingend Entra Cloud Sync. Für Entra Connect Sync wird es die Funktion nicht geben.
Provisioning Agent ab Version 1.1.1107.0, bei parallelem Betrieb von Entra Connect Sync mindestens Version 2.5.190.0
neu bei GA: Auch das mail-Attribut wird zurückgeschrieben. Wer bereits in der Preview aktiv war, muss die Standard-Attributzuordnungen einmalig wiederherstellen, damit das Mapping angelegt wird.

Cloud Sync läuft dabei parallel zu einer bestehenden Entra-Connect-Sync-Installation. Connect Sync synchronisiert weiterhin die Identitäten, Cloud Sync übernimmt ausschließlich das Exchange-Writeback.

Ein weiterer Schritt Richtung Cloud-only Management

Strategisch passt die Funktion gut zur Gesamtentwicklung.

Viele Organisationen betreiben längst sämtliche Benutzer-Mailboxen in Exchange Online, halten aber trotzdem lokale Exchange-Komponenten am Leben, weil bestimmte Attribute weiterhin aus dem Active Directory verwaltet werden müssen. Genau diese Verantwortlichkeiten entkoppelt die neue Architektur.

Für alle, die ihren letzten lokalen Exchange Server loswerden wollen, ist das ein wichtiger Baustein. Microsoft hat dafür inzwischen auch einen vollständigen Leitfaden zur Deinstallation veröffentlicht. Ein Hinweis am Rande, weil die Frage regelmäßig kommt: Die msExch*-Schemaerweiterungen bleiben nach der Deinstallation im Active Directory bestehen. Schemaerweiterungen lassen sich nun einmal nicht zurücknehmen.

Weitere Neuerungen im August-Update

Kurz erwähnt, weil sie in den meisten Zusammenfassungen untergehen:

Automatische SSO-Genehmigung auf verwalteten Geräten. Eine mit dem Juli-Patchday eingeführte Windows-11-Registry-Policy erlaubt es, Single-Sign-on-Anfragen auf verwalteten Entra-ID-Geräten automatisch zu genehmigen, statt Benutzer manuell bestätigen zu lassen. Damit bekommt die Zustimmungsabfrage „Mit Anmeldung fortfahren?“, die Microsoft 2024 wegen des Digital Markets Act eingeführt hat, endlich eine administrativ steuerbare Lösung. Besonders relevant für nicht-persistente VDIs, bei denen die Abfrage bisher in jeder neuen Sitzung auftauchte.
GPO Backup und Restore in Entra Domain Services (Preview). Gruppenrichtlinienobjekte lassen sich aus automatisch vorgehaltenen Sicherungspunkten wiederherstellen.
Termine zum Vormerken. Die Preview des memberOf-Regeloperators endet am 3. November 2026. Automatische Zuweisungsrichtlinien, die memberOf verwenden, werden bereits ab dem 27. Oktober 2026 in Quarantäne gestellt und verarbeiten dann keine Zuweisungen mehr.

Das größere Bild: Hybrid Identity wandert in die Cloud

Betrachtet man die Neuerungen zusammen, wird die Strategie ziemlich deutlich.

Microsoft schafft hybride Identitäten nicht von heute auf morgen ab. Stattdessen werden einzelne Verantwortlichkeiten schrittweise aus der lokalen Infrastruktur herausgelöst.

Benutzer und Gruppen lassen sich zunehmend cloudseitig verwalten. Exchange-Attribute wandern nach Exchange Online und bei Bedarf wieder zurück. Cloud Sync übernimmt immer mehr Provisioning-Aufgaben und synchronisiert in der Preview inzwischen auch Geräte. Parallel automatisiert Entra ID Governance die Prozesse für Benutzer, Gäste und Berechtigungen.

Damit verändert sich auch die Frage, die am Anfang jedes Hybrid-Identity-Projekts steht.

Früher lautete sie: „Wie synchronisieren wir unser Active Directory zuverlässig in die Cloud?“

Künftig eher: „Welche Objekte müssen überhaupt noch lokal verwaltet werden, und für welche kann Entra bereits die führende Plattform sein?“

Das ist ein deutlich grundlegenderer Architekturwechsel, als die einzelnen Release Notes vermuten lassen.

Was Sie jetzt prüfen sollten

Cloud-Sync-Readiness klären. Analysieren Sie, welche Funktionen Ihre Entra-Connect-Sync-Installation tatsächlich nutzt und ob Cloud Sync diese abbilden kann. Daraus ergibt sich, ob Sie zu den früh angesprochenen Tenants gehören oder bewusst warten.
Guest Governance überprüfen. Externe Benutzer brauchen einen klaren Sponsor sowie automatisierte Prozesse für Ablauf, Review und Löschung. Kalkulieren Sie die MAU-basierte Abrechnung von Anfang an mit ein.
Hybrid Exchange hinterfragen. Welche technischen Gründe machen einen lokalen Exchange Server heute noch erforderlich? Mit dem GA des Writebacks fällt ein weiterer davon weg.
External-ID-Architektur modernisieren. Bei Kunden-, Partner- oder Mitgliederportalen eröffnen die flexibleren Federation- und User-Flow-Optionen neue Szenarien.
Agent-Versionen aktualisieren. Provisioning Agent 1.1.1107 oder neuer sowie Entra Connect Sync 2.5.190.0 oder neuer sind Voraussetzung für die neuen Funktionen.
Härtungsfrist einhalten. Entra Connect Sync muss bis zum 30. September 2026 auf mindestens Version 2.5.79.0 laufen, besser direkt auf der aktuellen 2.6.84.0.

Fazit

Auf den ersten Blick wirken die Entra-Neuerungen im August 2026 wie eine Sammlung kleiner technischer Erweiterungen. Zusammengenommen zeigen sie einen klaren Trend: Microsoft macht die Cloud zur Steuerungsebene für hybride Identitäten.

Cloud Sync übernimmt weitere Aufgaben, Governance-Prozesse werden automatisiert, und klassische Abhängigkeiten von lokalen Systemen verschwinden Stück für Stück.

Das heißt nicht, dass Sie Ihr lokales Active Directory morgen abschalten können. Solange es existiert, sollte es auch abgesichert bleiben. Der Entra ID Kennwortschutz für das lokale AD ist dafür nach wie vor eine der am häufigsten lizenzierten und am seltensten aktivierten Funktionen.

Es heißt aber sehr wohl, dass bestehende Hybrid-Identity-Architekturen regelmäßig auf den Prüfstand gehören. Denn die entscheidende Frage ist längst nicht mehr, ob Identity Management stärker in die Cloud wandert, sondern wie schnell die eigene Umgebung diesen Schritt sinnvoll mitgehen kann.

Häufige Fragen

Kann Microsoft Entra Cloud Sync Geräte synchronisieren?

Ja. Über den AD2AADDeviceSync-Job lassen sich Computerobjekte aus dem lokalen Active Directory nach Entra ID synchronisieren, anschließend können die Geräte einen Entra Hybrid Join durchführen. Die Funktion befindet sich in der Public Preview und ist standardmäßig deaktiviert.

Ersetzt Cloud Sync jetzt Entra Connect Sync?

Noch nicht. Erweiterte Synchronisationsregeln, umfangreiches attributbasiertes Filtering und sehr große Objektmengen bleiben weiterhin Gründe für Entra Connect Sync, und wer solche Anforderungen hat, soll laut Microsoft ausdrücklich darauf bleiben. Cloud Sync ist aber die erklärte Zielarchitektur, und seit Juli 2026 vergibt Microsoft gestaffelt individuelle Transition-Windows, beginnend mit einfach aufgebauten Tenants.

Wird Entra Connect Sync am 30. September 2026 abgeschaltet?

Nein. An diesem Datum stellen ausschließlich Installationen unterhalb der Version 2.5.79.0 die Synchronisation ein, und zwar so lange, bis das Upgrade nachgeholt wird. Wer auf einer aktuellen Version läuft, derzeit 2.6.84.0, synchronisiert unverändert weiter. Der Übergang auf Cloud Sync ist ein davon unabhängiger, gestaffelter Prozess ohne festes Enddatum.

Wie viele Mailboxen unterstützt das Exchange-Attribut-Writeback?

Seit dem GA bis zu 600.000 cloudverwaltete Mailboxen pro Tenant. In der Public Preview lag die Grenze bei 200.000.

Welche Agent-Version wird für Device Sync benötigt?

Der Microsoft Entra Provisioning Agent muss in Version 1.1.1107 oder neuer installiert sein.

Kann sich ein Benutzer in Entra External ID ohne E-Mail-Adresse registrieren?

Ja, sofern das E-Mail-Attribut im User Flow als optional konfiguriert ist. Liefert der externe OpenID-Connect-Identity-Provider keinen E-Mail-Claim, wird das Konto ohne E-Mail-Adresse angelegt. Die Einstellung wirkt auf alle Anwendungen, die diesen User Flow verwenden.

Kostet die automatisierte Bereinigung von Gastkonten etwas?

Ja. Guest-Governance-Funktionen in Entra ID Governance setzen seit dem 30. Januar 2026 eine verknüpfte Azure-Subscription voraus und werden pro monatlich aktivem Gastbenutzer abgerechnet.

Storm-2949: Warum Microsoft-Cloud-Umgebungen heute aktiv betrieben und geschützt werden müssen

Die Angriffsfläche moderner Unternehmen hat sich in den letzten Jahren grundlegend verändert. Während früher primär lokale Server und Netzwerke im Fokus standen, richten professionelle Angreifer ihre Aktivitäten heute gezielt auf Microsoft 365, Azure und Microsoft Entra ID.

Die aktuelle Analyse der Hackergruppe Storm-2949 durch Microsoft zeigt eindrucksvoll, wie moderne Cloud-Angriffe funktionieren — und warum klassische Sicherheitsmaßnahmen alleine längst nicht mehr ausreichen.

Die Angreifer nutzen dabei keine spektakulären Zero-Day-Exploits, sondern kombinieren:

kompromittierte Identitäten,
Social Engineering,
Fehlkonfigurationen,
schwache Governance,
und mangelnde Überwachung von Cloud-Umgebungen.

Das macht diese Angriffe besonders gefährlich: Viele Aktivitäten wirken zunächst wie legitime Administratoraktionen und bleiben dadurch lange unentdeckt.

Die Angriffskette von Storm-2949

Microsoft beschreibt einen mehrstufigen Angriff auf Microsoft-Cloud-Umgebungen, bei dem sich die Angreifer schrittweise durch Identitäten, Azure-Dienste und Ressourcen bewegen.

Quelle:
Microsoft Security Blog – Storm-2949 Analyse

Wie die Angreifer vorgehen

Die Kampagne beginnt häufig mit Social Engineering oder kompromittierten Benutzerkonten.

Typische Einstiegspunkte:

Self-Service Password Reset (SSPR)
MFA-Manipulation
Phishing
Passwort-Spraying
Device-Code-Phishing
kompromittierte Legacy-Authentifizierung

Nach dem initialen Zugriff bewegen sich die Angreifer systematisch durch die Cloud-Umgebung:

1. Kompromittierung von Entra-ID-Konten

Sobald Benutzerkonten übernommen wurden, versuchen die Angreifer:

weitere MFA-Methoden hinzuzufügen,
Persistenz aufzubauen,
privilegierte Rollen zu identifizieren,
und Sicherheitsmechanismen zu umgehen.

2. Ausnutzung von Azure- und Microsoft-365-Diensten

Die Gruppe nutzt anschließend legitime Microsoft-Dienste für laterale Bewegungen:

SharePoint
Azure Virtual Machines
Azure Key Vault
Azure Storage Accounts
Azure SQL
Web Apps

Besonders kritisch:
Die Aktivitäten sehen oft wie normale Administratoraktionen aus.

3. Zugriff auf sensible Daten

Ziel der Kampagne ist häufig:

Datendiebstahl,
Persistenz,
oder die Vorbereitung weiterer Angriffe.

Betroffen sind typischerweise:

Kundendaten,
interne Dokumente,
Datenbanken,
Zugangsschlüssel,
Servicekonten,
API-Secrets,
Entwicklungsumgebungen.

Warum klassische Security heute nicht mehr ausreicht

Viele Unternehmen verlassen sich noch immer auf:

Antivirus,
klassische Firewalls,
einzelne MFA-Lösungen,
oder einmalige Security-Projekte.

Moderne Cloud-Angriffe umgehen diese Schutzmechanismen jedoch zunehmend über:

kompromittierte Identitäten,
legitime Cloud-Funktionen,
OAuth-Token,
Fehlkonfigurationen,
und überprivilegierte Konten.

Ich betone es immer wieder, die Realität ist:
Die Identität ist heute der eigentliche Sicherheitsperimeter.

Was Unternehmen jetzt tun sollten

Technische Schutzmaßnahmen

Phishing-resistente MFA einsetzen

Conditional Access konsequent nutzen

Zugriffe sollten abhängig gemacht werden von:

Standort,
Gerätetyp,
Risiko-Level,
Benutzerrolle,
Compliance-Status.

Legacy Authentication deaktivieren

Alte Authentifizierungsprotokolle sind weiterhin ein häufiger Angriffsvektor.

Rollen und Berechtigungen minimieren

Wichtige Prinzipien:

Least Privilege
Just-in-Time-Administration
Trennung privilegierter Konten
regelmäßige Rechte-Reviews

Besonders kritisch:

Global Administrator
Key Vault Zugriff
Service Principals
Managed Identities

Cloud-Monitoring etablieren

Unternehmen benötigen heute:

zentrales Logging,
SIEM-Anbindung,
Security Monitoring,
Anomalie-Erkennung,
Incident Response Prozesse.

Warum Security alleine nicht genügt

Ein zentrales Problem vieler Unternehmen:
Cloud-Sicherheit wird noch immer als Einzelprojekt betrachtet.

Doch moderne Microsoft-Cloud-Umgebungen verändern sich permanent:

neue Dienste,
neue Funktionen,
neue Sicherheitsanforderungen,
neue Angriffsmethoden.

Deshalb reicht es nicht aus, einmalig Sicherheitsmaßnahmen einzuführen.

Microsoft 365 und Azure benötigen einen kontinuierlich betreuten und professionell betriebenen Tenant.

Tenant as a Service: Sicherheit als Betriebsmodell

Ein moderner „Tenant as a Service“-Ansatz verbindet:

Betrieb,
Security,
Governance,
Monitoring,
und kontinuierliche Optimierung.

Dabei geht es nicht nur um Support, sondern um den aktiven sicheren Betrieb der gesamten Microsoft-Cloud-Umgebung.

Was ein Tenant-as-a-Service-Modell ermöglicht

Kontinuierliche Härtung der Umgebung

Ein professionell betriebener Tenant wird laufend:

überprüft,
optimiert,
gehärtet,
und an neue Bedrohungen angepasst.

Permanente Überwachung

Dazu gehören:

Monitoring von Entra ID,
Analyse verdächtiger Logins,
Überwachung privilegierter Konten,
Erkennung ungewöhnlicher Datenbewegungen,
Auswertung von Security Alerts.

Schnellere Reaktion auf Angriffe

Im Ernstfall zählt Geschwindigkeit.

Ein betreuter Tenant ermöglicht:

schnelle Incident Response,
Eindämmung kompromittierter Konten,
forensische Analyse,
Wiederherstellung betroffener Dienste.

Entlastung der internen IT

Viele interne IT-Teams sind bereits stark ausgelastet durch:

Tagesbetrieb,
Projekte,
Support,
Migrationen,
Compliance-Anforderungen.

Tenant as a Service schafft:

klare Betriebsprozesse,
standardisierte Security-Governance,
dokumentierte Richtlinien,
und nachhaltige Betriebsunterstützung.

Der Faktor Mensch bleibt entscheidend

Die meisten Angriffe beginnen weiterhin mit:

Social Engineering,
Phishing,
oder manipulierten Benutzern.

Technische Schutzmaßnahmen alleine reichen daher nicht aus.

Wichtige organisatorische Maßnahmen:

Security Awareness Trainings
Phishing-Simulationen
klare Notfallprozesse
Rollen- und Berechtigungskonzepte
definierte Security-Verantwortlichkeiten

Fazit

Die Storm-2949-Kampagne zeigt deutlich:

Moderne Angriffe auf Microsoft 365, Azure und Entra ID sind hochprofessionell, identitätsbasiert und oft nur schwer erkennbar.

Die größte Gefahr entsteht dabei häufig nicht durch einzelne Sicherheitslücken, sondern durch:

fehlende Governance,
unzureichendes Monitoring,
überlastete IT-Teams,
und mangelnden kontinuierlichen Betrieb der Cloud-Umgebung.

Unternehmen benötigen deshalb heute mehr als klassische Security-Produkte.

Sie brauchen:

kontinuierliche Sicherheitsüberwachung,
professionellen Cloud-Betrieb,
klare Governance,
schnelle Reaktionsfähigkeit,
und einen dauerhaft gehärteten Microsoft-Tenant.

Genau hier setzt ein moderner Tenant-as-a-Service-Ansatz an:
Security wird nicht mehr als Einzelmaßnahme verstanden, sondern als kontinuierlicher Bestandteil des gesamten IT-Betriebs.

Versteckte bösartige OAuth-Apps in Microsoft 365 entdecken – mit dem Tool Cazadora

Die Nutzung von Cloud- und Identitätsdiensten wie Microsoft 365 nimmt ständig zu – damit steigt auch das Risiko neuer Angriffswege. Ein besonders heimtückischer Ansatz: Angreifer nutzen OAuth-Apps, die in Azure/Entra ID registriert wurden, um Zugriffe auf Daten zu erlangen – oft ohne dass es die Administratoren oder Nutzer merken. In einem aktuellen Blogbeitrag erklärt Huntress Labs, wie solche Apps funktionieren, wie häufig sie auftreten – und stellt mit Cazadora ein Open-Source-Skript vor, mit dem sich verdächtige Anwendungen aufspüren lassen. BleepingComputer
Als IT-Consultant lohnt es sich, dieses Thema im Blick zu behalten, denn selbst gut verwaltete Microsoft-365-Tenants sind nicht immun.

Was sind OAuth Apps in Azure/Entra ID – und warum sind sie relevant?

In der Welt von Azure AD / Entra ID und Microsoft 365 gibt es zwei zentrale Kategorien von Apps:

Application Registrations: Anwendungen, die innerhalb des eigenen Tenants entwickelt oder registriert wurden. BleepingComputer+1
Enterprise Applications: Instanzen von Anwendungen, die von anderen Tenants registriert wurden, aber in Ihrer Tenant-Umgebung verwendet werden. BleepingComputer

Der typische Ablauf sieht so aus: Ein Benutzer oder Administrator erlaubt einer App, sich mit ihrem Konto (Authentifizierung) zu verbinden und über OAuth entsprechende Rechte (Autorisierung) zu erteilen. Sobald das geschehen ist, wird in Ihrem Tenant ein Service-Principal für diese App angelegt, über den die App im Namen der Nutzer agieren kann. BleepingComputer

Warum ergeben sich daraus Risiken?

Die Funktionalität ist legitim und zentraler Bestandteil moderner Cloudanwendungen – das macht sie attraktiv für Angreifer, da sie wenig auffällig ist. BleepingComputer+1
Manche Einstellungen erlauben es, dass jeder Nutzer ohne Überprüfung Apps registrieren bzw. ihnen Rechte geben kann – je nach Tenant-Konfiguration. BleepingComputer
Eine bösartige oder kompromittierte App kann somit Zugriff auf sensible Daten erlangen, ohne dass klassische Malware- oder Endpoint-Kontrollen sie zwingend aufdecken.

Angriffstypen: „Traitorware“ und „Stealthware“

Huntress unterscheidet zwei relevante Kategorien von missbräuchlichen OAuth-Apps:

Traitorware

Hierbei handelt es sich um eigentlich legitime Apps oder weit verbreitete Tools, die allerdings von Angreifern für bösartige Zwecke genutzt werden. Die App selbst ist nicht zwangsläufig bösartig designt, aber ihre Nutzung erscheint ungewöhnlich und riskant.

Huntress fand z. B., dass ca. 10 % der ausgewerteten Tenants mindestens eine solche App installiert hatten. BleepingComputer
Merkmale: bekannte App-Namen, aber oft ungewöhnliche Berechtigungen oder eine ungewöhnliche Nutzerzuordnung.

Stealthware

Diese Kategorie umfasst echt bösartige oder speziell für Angriffe erstellte OAuth-Apps – klein, maßgeschneidert, selten und damit schwer zu entdecken.

Sie haben oft sehr geringe Verbreitung (z. B. < 1 % aller Tenants) und hohe Delegated-Berechtigungen auf einzelne Nutzer. BleepingComputer
Da die Namen willkürlich oder unerkennbar sind („…………“, „Test App“, Domain-Name etc.), entziehen sie sich oft automatisierten Erkennungsmechanismen.

Warum sollte man auditieren?

Die Daten zeigen: Selbst bei Organisationen mit etabliertem Sicherheitsrahmen tauchen solche Apps auf – teilweise seit Jahren unentdeckt. BleepingComputer
Ein (zu) beruhigender Befund: Wenn eine App nicht automatisch gefunden wird, heißt das noch nicht, dass keine bösartige App vorhanden ist. Vigilanz bleibt erforderlich.

Vorstellung von Cazadora

Um Administratoren und Sicherheitsverantwortlichen zu helfen, hat Huntress das Werkzeug Cazadora veröffentlicht. BleepingComputer

Was macht Cazadora?

Es handelt sich um ein Open-Source-Skript, das über die Microsoft Graph API Daten über alle Application Registrations und Enterprise Applications im Tenant abruft. BleepingComputer
Es führt eine automatisierte Analyse durch und markiert Applikationen mit auffälligen Merkmalen (z. B. ungewöhnlicher Name, seltene Verbreitung, starke Berechtigungen, Loopback-Reply-URL etc.). BleepingComputer
Ziel ist nicht, alle bösen Apps sicher aufzuspüren, sondern einen schnellen Überblick zu geben und potenzielle „Rauchzeichen“ sichtbar zu machen.

Wichtige Hinweise

Kein Tool ersetzt eine vollständige manuelle Prüfung oder eine laufende Sicherheitsüberwachung – Cazadora ist ein Sprungbrett, keine Garantie. BleepingComputer
Ergebnisse sollten von einem Administrator oder Sicherheitsanalysten bewertet werden.
Anpassungen im Tenant (z. B. Benutzerrechte bei App-Registrierung) können helfen, den Angriffsraum zu reduzieren.

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:

Der Private Key bleibt sicher auf dem Gerät oder Token des Benutzers.
Der Public Key wird bei Microsoft Entra ID (ehemals Azure AD) gespeichert.
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

Vorteil	Beschreibung
🛡️ Phishing-resistent	Keine Passwörter = kein Angriffsziel
🚀 Schneller Login	Kein Eintippen, kein „Passwort vergessen“
💼 Weniger Supportaufwand	Reduziert Helpdesk-Tickets
🔑 Stärkere Sicherheit	Basierend auf Kryptografie, nicht Wissen
🔗 Microsoft 365 integriert	Unterstü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.

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

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.

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.

„Mit Anmeldung fortfahren?“ Änderung bei Windows Single-Sign-On

Microsoft hatte es bereits im Dezember angekündigt. Aufgrund des Digital Markets Act (DMA) müssen die Benutzer dem Single-Sign-On auf Windows Geräten zustimmen. Hierzu erhält der Benutzer bei dem Zugriff auf M365 Ressourcen die Frage „Mit Anmeldung fortfahren?“. Diese muss der Anwender mit „weiter“ bestätigen um sich zu authentifizieren. Unter aka.ms/sso-info werden weitere Informationen angeboten. Die Infoseite erklärt, dass SSO weiterhin nur nach Bestätigung dieser Abfrage möglich ist.

Der Benutzer muss diese Meldung auf jedem Gerät an dem er arbeitet einmalig bestätigen. Die Bestätigung ist anschließend nicht mehr nötig, nur wenn sich der Benutzer 90 Tage nicht mehr an diesem Gerät authentifiziert hat.

Die Änderung wird nach und nach innerhalb des Europäischen Wirtschaftsraums aktiviert. Betroffen davon sind die Betriebssysteme Windows 10 und 11, bei denen innerhalb des initialen Gerätesetups ein Land innerhalb des Europäischen Wirtschaftsraums gewählt wurde. Explizit wirkt diese Änderung nicht auf Server Betriebssystemen.

Innerhalb der Entra-Anmeldeprotokolle führen fehlende Benutzerzustimmungen zu Anmeldefehlern mit dem Code 9002341 und der Fehlerursache „User is required to permit SSO“.

In einigen Fällen führt dies zu Problemen, da beispielsweise die Authentifizierung gegen Microsoft 365 Dienste wie z.B. bei einem automatischen Intune Join via GPO nicht durchgereicht wird. Dies klappt erst, wenn der Benutzer den SSO bestätigt hat. Aber auch bei nicht-persistenten VDIs führt das neue Feature bei jeder neuen Sitzung zur oben genannten Abfrage. Microsoft sind Probleme bekannt und will zeitnah nachbessern.

Weitere Infos und der Blog-Eintrag von Microsoft dazu:

Upcoming changes to Windows Single Sign-On | Windows IT Pro (microsoft.com)

Microsoft Entra Password Protection: Ein Muss für die Sicherheit Ihres Unternehmens

In der heutigen digitalen Welt, in der Cybersicherheit von größter Bedeutung ist, bleibt das Passwort ein grundlegender, aber oft übersehener Aspekt der Sicherheitsstrategie eines Unternehmens. Viele Organisationen besitzen bereits Lizenzen für fortschrittliche Sicherheitstools, setzen diese jedoch nicht ein. Ein solches Beispiel ist die Microsoft Entra Password Protection – ein leistungsstarkes Werkzeug, das speziell dafür entwickelt wurde, die Passwortsicherheit zu verbessern, indem es die Verwendung schwacher und häufig genutzter Passwörter verhindert.

Trotz der Verfügbarkeit dieses Tools aktivieren viele Kunden die Funktion nicht. Dieser Artikel dient als Ihre jährliche Erinnerung daran, warum es entscheidend ist, den Microsoft Entra ID Kennwortschutz in Ihrem lokalen Active Directory zu implementieren, vor allem, wenn Sie über die entsprechende Entra ID P1 oder P2 Lizenz verfügen.

Warum Microsoft Entra Password Protection wichtig ist

Viele Unternehmen haben bereits eine Lizenz für Microsoft Entra ID, nutzen aber den Kennwortschutz nicht. Dieses Tool verbessert die Passwortkomplexität im lokalen Active Directory signifikant, indem es bekannte schwache Passwörter und ihre Varianten sowie weitere schwache Begriffe blockiert, die spezifisch für eine Organisation sein könnten.

Die häufigsten Missverständnisse aufgeklärt

Im Laufe der Jahre sind mir einige Missverständnisse begegnet, die dazu führen, dass Organisationen zögern, diese notwendige Sicherheitsmaßnahme zu ergreifen. Hier möchte ich einige dieser Missverständnisse ausräumen:

„Es ist zu kompliziert einzurichten“: Die Implementierung von Microsoft Entra Password Protection ist unkompliziert und erfordert keine Änderungen am AD DS-Schema oder das Öffnen neuer Netzwerkports.
- Es wird keine spezifische AD Gesamtstrukturebene erfordert
  - Wenn Azure nicht verfügbar ist, hat dies keine Auswirkungen auf das Zurücksetzen Ihrer Kennwörter
  - Erfordert keine neuen Ports, welche auf Ihren DC’s geöffnet werden müssen
  - Es ist nicht erforderlich, dass Ihre DC’s über einen Internetzugang verfügen. Die Passwort-Sperrliste wird von einem Proxyserver/Dienst verteilt
„Unsere Passwörter sind bereits stark genug“: Selbst wenn Ihre Organisation strenge Passwortrichtlinien verfolgt, gibt es immer noch eine Fülle gängiger Passwörter und Variationen, die durch traditionelle Richtlinien nicht abgedeckt werden. Tatsächlich ergänzt Microsoft Entra Password Protection vorhandene Richtlinien durch Hinzufügen einer weiteren Sicherheitsebene gegen schwache Passwörter. Microsoft Entra erweitert Ihren Schutz, indem es eine globale Datenbank schwacher Passwörter und deren Variationen nutzt.
„Es wird die Benutzerfreundlichkeit beeinträchtigen“: Während die Blockierung schwacher Passwörter die Passwortauswahl einschränken kann, dient sie dem größeren Ziel, Konten sicherer zu machen.
- Die Funktion wird erst wirksam, wenn die Passwörter Ihrer Benutzer das nächste Mal ablaufen bzw. zurückgesetzt werden müssen. Es wird keine Massenzurücksetzung der Passwörter durchgeführt.
„Es ist nur eine weitere unnötige Sicherheitsmaßnahme“: Angesichts der steigenden Zahl von Cyberangriffen, insbesondere Passwort-Spray-Angriffen, ist die Verwendung eines Tools wie Microsoft Entra alles andere als unnötig. Es ist eine essenzielle Schicht in Ihrer Sicherheitsstrategie, die die Schwachstellen, die durch schwache Passwörter entstehen, minimiert.

Mein Aufruf zum Handeln

Die Implementierung des Microsoft Entra ID Kennwortschutzes ist nicht nur eine Best Practice, sondern eine Notwendigkeit in der heutigen von Cyberbedrohungen geprägten Landschaft. Durch die Verbesserung der Passwortkomplexität und die Eliminierung schwacher Passwörter stärken Sie die Verteidigungslinie Ihres Unternehmens gegen unautorisierten Zugriff erheblich.

Wenn Ihre Organisation über eine Lizenz für Microsoft Entra (P1/P2) verfügt, ist es an der Zeit, den Kennwortschutz zu aktivieren. Dies ist ein einfacher Schritt, der die Sicherheit Ihres Unternehmens erheblich verbessern kann. Vermeiden Sie die gängigen Fallen schwacher Passwörter und machen Sie den ersten Schritt in Richtung einer sichereren digitalen Umgebung.

Lassen Sie dieses Jahr nicht ungenutzt verstreichen, ohne die volle Macht der Microsoft Entra Password Protection zu nutzen. Es ist ein einfacher, aber wirkungsvoller Schritt, um die Cybersicherheit Ihres Unternehmens zu stärken.

Sicherer Zugriff im Zeitalter der Künstlichen Intelligenz: Was ist neu bei Microsoft Entra?

Als IT-Berater bin ich immer auf der Suche nach den neuesten Innovationen im Bereich der Cybersicherheit, die meinen Kunden helfen können, ihre digitale Umgebung zu schützen. Deshalb war ich sehr gespannt auf die Ankündigungen von Microsoft Entra, der integrierten Lösung für Identitäts- und Zugriffsmanagement, auf der Ignite 2023 Konferenz. Nun möchte ich mit einer zeitlichen Verzögerung endlich über meine persönlichen Highlights berichten.

Was ist Microsoft Entra?

Microsoft Entra bietet eine Reihe von Funktionen, die den sicheren Zugriff auf alle Anwendungen und Ressourcen für alle Benutzer und Geräte ermöglichen, die sich von überall aus verbinden. Dabei werden die Prinzipien des Zero Trust Ansatzes verfolgt, der auf der Verifizierung von Identität, Gerät, Anwendung und Netzwerk basiert, bevor der Zugriff gewährt wird.

Einige der Highlights, die mich besonders beeindruckt haben, sind:

Security Service Edge (SSE): Dies ist eine neue Lösung, die Microsoft Entra Internet Access und Microsoft Entra Private Access umfasst. Microsoft Entra Internet Access ist ein identitätszentriertes Secure Web Gateway (SWG), welches den Zugriff auf alle Internetanwendungen und -ressourcen mit bedingtem Zugriff und Web-Inhaltsfilterung sichert. Microsoft Entra Private Access ist ein identitätszentriertes Zero Trust Network Access (ZTNA), das den Zugriff auf alle privaten Anwendungen und Ressourcen mit bedingtem Zugriff und modernen Authentifizierungsmethoden sichert. Beide Lösungen arbeiten mit dem bestehenden Sicherheits- und Netzwerkstack von Microsoft und einem offenen Partnernetzwerk zusammen, um eine nahtlose Integration zu gewährleisten.
Microsoft Security Copilot: Dies ist ein neuer digitaler Assistent, welcher in das Microsoft Entra Admin Center eingebettet ist und den Administratoren hilft, häufige Aufgaben zu automatisieren, schneller zu beheben, komplexe Richtlinien zu interpretieren und Workflows zu entwerfen. Der Security Copilot beantwortet einfache Fragen, was eine bedingte Zugriffsrichtlinie macht oder warum die mehrstufige Authentifizierung (MFA) ausgelöst wurde. Der Security Copilot bietet auch eine Risikozusammenfassung, Abhilfemaßnahmen und empfohlene Anleitungen für gefährdete Identitäten, um das schnelle Reagieren auf Identitätsrisiken zu erleichtern. Ich kann also einfach meinen digitalen Assistenten Fragen stellen und dieser analysiert die notwendigen Anmeldelogs, bereitet diese auf und liefert mir eine passende Antwort.
Phishing-resistente Authentifizierungsmethoden: Microsoft Entra unterstützt verschiedene MFA-Methoden, um die Authentifizierung vor Phishing zu schützen. Dazu gehören zum Beispiel FIDO2 Security Keys, Windows Hello for Business, Microsoft Entra Certificate-Based Authentication (CBA) und Passkeys. Alle diese Methoden ermöglichen es, Passwörter ganz zu eliminieren, so dass sie nicht erraten, abgefangen oder gephished werden können. Microsoft Entra CBA ermöglicht es, Authentifizierungsrichtlinien nach Zertifikat, Ressourcentyp und Benutzergruppe anzupassen. Passkeys sind eine neue Funktion, welche mit Windows 11 eingeführt wurde und es ermöglicht, sich mit dem Gesicht, dem Fingerabdruck oder der PIN des Geräts bei einer Website, Anwendung oder einem Dienst anzumelden, für den man einen Passkey erstellt hat. Microsoft Entra ID-Benutzer werden bald in der Lage sein, sich mit Passkeys anzumelden, die aus der Microsoft Authenticator App verwaltet werden. Ein aus meiner Sicht wichtiger Schritt, um die Notwendigkeit von Kennwörtern endgültig abzuschaffen.
Microsoft Entra Permissions Management: Dies ist eine Lösung, die Einblicke in die Berechtigungsrisiken bietet. Es gibt zwei wichtige Integrationen, die mir aufgefallen sind. Die erste ist die Integration mit Microsoft Defender for Cloud (MDC), diese ermöglicht es, Identitäts- und Zugriffsberechtigungsinformationen mit anderen Cloud-Sicherheitsinformationen in einer einzigen Schnittstelle zu konsolidieren. Diese Ansicht zeigt handlungsorientierte Empfehlungen zur Behebung von Berechtigungsrisiken sowie den Permissions Creep Index an und erleichtert die Durchsetzung des Least Privilege Zugriffs für Cloud-Ressourcen über Azure, Amazon Web Services (AWS) und Google Cloud hinweg. Die zweite Integration ermöglicht es ServiceNow-Kunden, zeitgebundene, bedarfsgesteuerte Berechtigungen für Multicloud-Umgebungen (Azure, AWS, Google Cloud) über das ServiceNow-Portal anzufordern. Diese beliebte IT-Service-Management (ITSM)-Lösung stärkt somit die Zero Trust-Haltung, indem sie Zugriffsberechtigungsanfragen zu bestehenden Genehmigungsworkflows in ServiceNow hinzufügt. Ein wichtiger Schritt Richtung herstellerunabhängiger Zero-Trust Architektur.

Fazit

Ich bin beeindruckt von dem Umfang und der Tiefe der Funktionen, welche Microsoft Entra bietet, um den sicheren Zugriff auf alles und für jeden zu ermöglichen. Ich glaube, dass diese Lösungen meinen Kunden helfen kann, ihre digitale Transformation voranzutreiben und gleichzeitig ihre Sicherheit zu erhöhen. Gerade die Integration von anderen Cloud Services wie AWS, Google oder Service-Now sind wichtige Schritte für die Absicherung der Identitäten.

Übersicht über Windows LAPS

In diesem Blogbeitrag möchte ich Ihnen eine spannende neue Funktion vorstellen, welche mit dem heutigen Sicherheitsupdate vom 11. April 2023 für die folgenden Windows-Editionen direkt im Betriebssystem enthalten sind:

Windows 11 Pro, EDU, and Enterprise
Windows 10 Pro, EDU, and Enterprise
Windows Server 2022 and Windows Server Core 2022
Windows Server 2019

Windows Local Administrator Password Solution (Windows LAPS) für Azure Active Directory

Native Integration in Windows

Windows LAPS ist sofort einsatzbereit. Sie müssen kein externes MSI-Paket mehr installieren, kein AD-Schema mehr erweitern und keine Gruppenrichtlinien verteilen! Alle zukünftigen Anpassungen, Verbesserungen oder Funktionsupdates werden über die normalen Windows-Patching-Prozesse bereitgestellt.

Was ist Windows LAPS?

Windows LAPS ist eine Windows-Funktion, die bereits für in Windows Server Active Directory eingebundene Geräte verfügbar ist. Sie ermöglicht es Ihnen, die Kennwörter der lokalen Administratorkonten auf Ihren Geräten automatisch zu generieren, zu ändern und zu speichern. Dies erhöht die Sicherheit, da Sie nicht mehr das gleiche Kennwort für alle Geräte verwenden müssen, und vermeidet somit das Risiko von Pass-the-Hash-Angriffen und unterbindet aktiv das sogenannte Lateral Movement.

Windows LAPS bietet einige Vorteile gegenüber anderen Methoden zur Verwaltung von lokalen Administratorpasswörtern, wie z.B.:

Es generiert zufällige und komplexe Passwörter für jedes Gerät und ändert sie regelmäßig nach einem festgelegten Zeitplan.
Es speichert die Passwörter verschlüsselt in einem Active Directory-Attribut, das nur von berechtigten Benutzern oder Gruppen abgerufen werden kann.
Es vermeidet die Verwendung eines gemeinsamen Passworts für alle Geräte oder die manuelle Verfolgung von Passwörtern in einer Excel-Tabelle oder einem anderen Medium.
Es ermöglicht es Administratoren, die Passwörter bei Bedarf schnell zu ändern oder zurückzusetzen, z.B. bei einem Sicherheitsvorfall oder einem Mitarbeiterwechsel.
Es ist einfach zu implementieren und zu verwalten, ohne dass zusätzliche Hardware oder Software erforderlich ist.

Windows LAPS ist eine nützliche Lösung für alle Organisationen, die lokale Administratorpasswörter auf ihren Windows-Geräten effektiv verwalten wollen. Es ist kostenlos und einfach zu verwenden und bietet einen hohen Grad an Sicherheit und Kontrolle.

Windows LAPS unterstützt Azure AD

Windows LAPS für Azure Active Directory erweitert die bestehende Funktion um die Möglichkeit, die Kennwörter der lokalen Administratorkonten in Azure Active Directory zu sichern. Dies hat mehrere Vorteile:

Sie können die gespeicherten Kennwörter über Microsoft Graph abrufen.
Sie können zwei neue Microsoft Graph-Berechtigungen erstellen, um nur die Kennwort-„Metadaten“ (z. B. für Sicherheitsüberwachungs-Apps) oder das sensible Klartextkennwort selbst abzurufen.
Sie können Azure-Richtlinien für rollenbasierte Zugriffssteuerung (Azure RBAC) verwenden, um Autorisierungsrichtlinien für das Abrufen von Kennwörtern zu erstellen.
Sie können das Azure-Verwaltungsportal verwenden, um Kennwörter abzurufen und zu ändern.
Sie können die Funktion über Intune verwalten!
Sie können das Kennwort automatisch ändern, nachdem das Konto verwendet wurde.

Wie kann ich Windows LAPS für Azure Active Directory einrichten?

Um Windows LAPS für Azure Active Directory einzurichten, müssen Sie zunächst einen Mechanismus zur Bereitstellung von Richtlinien auf Ihren Geräten wählen. Die bevorzugte Option ist die Verwendung von Microsoft Intune mit dem Windows LAPS-Konfigurationsdienstanbieter (CSP). Wenn Sie Microsoft Intune nicht verwenden, können Sie auch andere Methoden verwenden, wie z. B. die direkte Änderung der Registrierung oder die Verwendung von Gruppenrichtlinie für lokale Computer.