MFA nicht erzwungen alle Benutzer Conditional Access Entra: Die kritische Lücke hinter reinen Admin-Richtlinien

MFA nicht erzwungen alle Benutzer Conditional Access Entra: Was das konkret bedeutet

MFA nicht erzwungen alle Benutzer Conditional Access Entra ist eine eigenständige, häufige und als kritisch eingestufte Lücke in Microsoft Entra ID — und sie ist nicht dasselbe Versäumnis wie das vollständige Fehlen von Conditional Access. Ein Mandant kann jede Checkliste vom Typ „Haben Sie Conditional Access?" bestehen, eine Richtlinie vorweisen, die buchstäblich Alle Benutzer adressiert, und trotzdem jedes Konto ohne Administratorrolle allein per Kennwort erreichbar lassen. Das passiert, wenn die Gewährungssteuerung der Richtlinie etwas anderes als MFA verlangt (etwa Gerätekonformität), oder wenn die MFA-Durchsetzung über mehrere rollen- oder anwendungsbezogene Richtlinien verstreut ist, die einzeln solide wirken, in der Summe aber nie eine flächendeckende Abdeckung ergeben.

Dies ist der engere, häufigere und gefährlichere Verwandte von zwei bekannteren Problemen:

• Überhaupt keine Conditional-Access-Richtlinie, die alle Benutzer adressiert. Das ist das Versagen der Grundabdeckung — siehe Conditional Access: Lücken in der Baseline-Richtlinienabdeckung in Entra ID für Mandanten, in denen überhaupt keine Richtlinie Administratorrollen, alle Benutzer, alle Cloud-Apps oder Gerätekonformität abdeckt. Dieser Artikel setzt voraus, dass eine Richtlinie für alle Benutzer bereits existiert; die Lücke hier ist enger und leichter zu übersehen — die Richtlinie existiert, aber sie verlangt kein MFA.
• MFA nur für Administratoren erforderlich. Die meisten Conditional-Access-Härtungen beginnen hier, und das aus gutem Grund — siehe Azure-Identitätssicherheit: Warum MFA allein nicht reicht. Aber eine auf Administratoren begrenzte MFA-Richtlinie kann, wie gut sie auch gebaut ist, strukturell nicht die Konten schützen, denen sie nie zugewiesen wurde. Standardbenutzer melden sich an denselben Postfächern, denselben SharePoint-Websites und denselben Branchenanwendungen an wie Administratoren; sie sind kein geringerwertiges Ziel, sie sind schlicht ein ungeschütztes.

Genau deshalb ist die Lücke selbst für Teams leicht zu übersehen, die bereits echte Härtungsarbeit geleistet haben. Eine Organisation, die administratorbezogenes MFA gemäß MFA_NOT_ENFORCED_ADMINS ausgerollt oder die Authentifizierung globaler Administratoren gemäß PA_GLOBAL_ADMIN_NOT_MFA abgesichert hat, hat die schwieriger aussehende Arbeit zuerst erledigt und nimmt vernünftigerweise an, der einfachere, breitere Fall — alle übrigen Benutzer — sei dadurch bereits mit abgedeckt. Strukturell ist er das nicht: Administratorbezogene und alle Benutzer umfassende Richtlinien beruhen in Entra ID auf unterschiedlichen Zuweisungsbedingungen, sodass der Abschluss der einen die Abdeckung der anderen genau dort belässt, wo sie begonnen hat, nämlich bei null.

Zwei getrennte Vorlagen, zwei getrennte Secure-Score-Aktionen

Microsoft modelliert „MFA erforderlich" nicht als eine einzige Steuerung. In der Vorlagengalerie für Conditional Access sind Mehrstufige Authentifizierung für Administratoren erforderlich (Require multifactor authentication for admins) und Mehrstufige Authentifizierung für alle Benutzer erforderlich (Require multifactor authentication for all users) als zwei getrennte Vorlagen aufgeführt. Beide erscheinen gemeinsam unter Microsofts eigener Kategorie „Secure foundation" — der Gruppe, die Microsoft ausdrücklich empfiehlt, gemeinsam bereitzustellen — und beide erscheinen erneut, weiterhin als zwei getrennte Einträge, unter der Kategorie „Zero Trust". Keine der beiden Vorlagenbeschreibungen beansprucht, das Feld der jeweils anderen abzudecken, in keiner der beiden Listen.

Dieselbe Trennung existiert in der Bewertung. Der Identity Secure Score von Microsoft Entra ID führt Mehrstufige Authentifizierung (MFA) für Administrative Rollen erforderlich (Require multifactor authentication (MFA) for administrative roles) und Sicherstellen, dass alle Benutzer MFA abschließen können (Ensure all users can complete MFA) als zwei eigenständige Verbesserungsaktionen in seinem eigenen Katalog. Ein Mandant kann die erste voll ausschöpfen und bei der zweiten null erreichen; Secure Score behandelt sie nicht als redundant, und wer einen Conditional-Access-Export prüft, sollte das ebenfalls nicht tun.

Die Aktion für alle Benutzer wird zudem als Prozentsatz der insgesamt geschützten Benutzer bewertet, nicht als binäres Bestanden/Nicht bestanden. In Microsofts eigenem Rechenbeispiel ergeben 5 geschützte Benutzer von insgesamt 100 Benutzern rund 0,53 % von möglichen 10,71 % für diese Steuerung — was bedeutet, dass die meisten Mandanten, die mit MFA für alle Benutzer „begonnen" haben, weiterhin den größten Teil des Risikos tragen, das die Steuerung schließen soll.

Wie fragmentierte Abdeckung die Lücke verbirgt

Die Administrator-MFA-Vorlage und die Vorlage für MFA für alle Benutzer sind nicht gleich zugeschnitten, und genau dieser Unterschied lässt eine Lücke eine oberflächliche Richtlinienprüfung überleben:

• Mehrstufige Authentifizierung für Administratoren erforderlich (Require multifactor authentication for admins) weist unter Verzeichnisrollen zu, und nur einer definierten Liste integrierter Rollen — Globaler Administrator, Anwendungsadministrator, Authentifizierungsadministrator, Administrator für privilegierte Rollen, Sicherheitsadministrator und weitere, die Microsoft in seiner Dokumentation ausdrücklich benennt. Microsofts eigene Warnung ist unmissverständlich: "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." Eine benutzerdefinierte Rolle „IT-Support" mit erhöhten Berechtigungen oder eine Rolle, die nur auf Ebene einer Verwaltungseinheit zugewiesen ist, bleibt für diese Richtlinie unsichtbar, selbst während sie aktiviert und durchgesetzt ist.
• Mehrstufige Authentifizierung für alle Benutzer erforderlich (Require multifactor authentication for all users) weist unter Einschließen: Alle Benutzer zu, wobei Ausschlüsse auf Break-Glass-Konten und Dienstkonten der Verzeichnissynchronisierung beschränkt sind. Es gibt keine Rollenbedingung, durch die ein Benutzer herausfallen könnte.

Weil die beiden Richtlinien unterschiedliche Zuweisungsmodelle verwenden, kann ein Mandant mehrere tatsächlich durchgesetzte MFA-Richtlinien ansammeln — eine für globale Administratoren, eine für eine bestimmte Finanzanwendung, eine nur bei riskanter Anmeldung ausgelöste — und trotzdem nie die eine Richtlinie ausgerollt haben, deren Einschließen buchstäblich Alle Benutzer lautet, deren Zielressourcen Alle Ressourcen sind und deren Gewährungssteuerung MFA verlangt. Jede einzelne Richtlinie ist real; keine von ihnen ergibt, auch zusammengenommen, die von Microsoft empfohlene Grundlinie. Entra ID: Lücken im bedingten Zugriff behandelt das breitere Muster aus Ausschlüssen und Geltungsbereichsabweichungen, das einen Conditional-Access-Bestand vollständig aussehen lässt, während in der Produktion echte Angriffsfläche bleibt. Azure: privilegierter Zugriff und zu viele globale Administratoren behandelt das parallele Versagen auf der privilegierten Seite, wo dauerhafte Administratorrollen und PIM-Lücken dieselbe zugrunde liegende Schwäche von der anderen Seite her verstärken.

Detection

Diese Lücke zu bestätigen erfordert kein Raten — Microsoft Entra ID protokolliert die genau erreichte Authentifizierungsstufe bei jeder Anmeldung, pro Benutzer und pro Anwendung.

Gemäß Microsofts eigener Anleitung zum Auffinden von MFA-Lücken bei Administratoren: "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." Diese Anleitung ist ausdrücklich für Administratoren geschrieben, das Feld selbst ist jedoch nicht rollenbezogen — es ist eine Eigenschaft des Anmeldeereignisses, sodass dieselbe Prüfung für jede Benutzergruppe gilt, ob Administrator oder nicht.

authenticationRequirement wird an der signIn-Ressource im Beta-Endpunkt von Microsoft Graph bereitgestellt — an der stabilen signIn-Ressource in v1.0 ist es nicht vorhanden — und es unterstützt $filter mit den Operatoren eq und startsWith:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

Der Filter ist prozentcodiert — %20 für die Leerzeichen, %27 für die Anführungszeichen — sodass die Anfrage sowohl in einem Kommandozeilenclient als auch im Graph Explorer eingefügt funktioniert. Uncodiert lassen die rohen Leerzeichen Werkzeuge wie curl die URL lokal ablehnen, bevor sie überhaupt gesendet wird.

Oder mit dem Beta-Modul des Microsoft Graph PowerShell SDK:

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Microsofts Vorlage für MFA für alle Benutzer bereitstellen

Prüfen Sie zuerst, ob Microsoft bereits eine im Mandanten hinterlegt hat. Von Microsoft verwaltete Richtlinien werden von Microsoft direkt in berechtigte Mandanten erstellt und ausgerollt, und eine davon trägt den Namen Multifactor authentication for all users (Mehrstufige Authentifizierung für alle Benutzer) — sie "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." Sie kommt inaktiv an: "The policy is automatically created in your tenant in a Report-only state." Microsoft aktiviert sie anschließend "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," und benachrichtigt Mandanten zwei Wochen vorher. Filtern Sie in der Spalte Created by auf Microsoft, bevor Sie ein Duplikat bauen.

Verwenden Sie andernfalls die Vorlagengalerie für Conditional Access, oder bauen Sie die gleichwertige Richtlinie direkt:

• Setzen Sie unter Zuweisungen → Benutzer den Wert Einschließen: Alle Benutzer.
• Fügen Sie unter Ausschließen nur die dokumentierten Break-Glass- bzw. Notfallzugangskonten Ihrer Organisation hinzu und, falls Sie Hybrid-Identitätssynchronisierung verwenden, die Rolle „Directory Synchronization Accounts" — nicht einen pauschalen Ausschluss für „das IT-Team", der die Lücke stillschweigend wiederherstellt.
• Setzen Sie unter Zielressourcen den Wert Einschließen: Alle Ressourcen, ohne Anwendungsausschlüsse.
• Wählen Sie unter Gewähren die Option Authentifizierungsstärke erforderlich und darin die integrierte Multifactor authentication strength.

2. Im Report-only-Modus ausrollen und bestätigen, dass er tatsächlich verlassen wird

Prüfen Sie die voraussichtliche Auswirkung über Richtlinienauswirkung oder die Arbeitsmappe „Conditional Access Insights and Reporting", bevor Sie Richtlinie aktivieren auf On umstellen — so fangen Sie ein Break-Glass-, Dienst- oder Legacy-Auth-Konto ab, das sonst unerwartet blockiert würde. Eine Richtlinie, die unbefristet im Report-only-Modus verbleibt, oder eine Ausschlussliste, die stillschweigend über ihren ursprünglichen Umfang hinausgewachsen ist, setzt nichts durch und zeigt trotzdem „On" — prüfen Sie das nach dem Rollout, nicht nur bei der Erstellung.

3. Abdeckung mit dem What-If-Tool überprüfen

Führen Sie das What-If-Tool für eine Stichprobe gewöhnlicher Benutzer ohne Administratorrolle aus — nicht nur für die Administratorkonten, die bereits von der anderen Richtlinie abgedeckt sind —, um zu bestätigen, dass die neue Richtlinie tatsächlich auf sie zutrifft. Aktivierte Richtlinien und Richtlinien im Report-only-Modus fließen beide in einen Auswertungslauf ein, sodass eine noch im Report-only stehende Richtlinie hier erscheint. Lesen Sie die Ausgabe als Simulation und nicht als Garantie: Microsoft weist darauf hin, dass das Werkzeug "doesn't test for Conditional Access service dependencies," und dass Bedingungen, die Sie nicht angeben, Bedingungen sind, die es nicht auswerten kann.

4. Das nicht als Ersatz für administratorbezogenes MFA behandeln — und umgekehrt

Falls auch die administratorbezogene MFA-Richtlinie noch nicht ausgerollt ist, behandeln Sie sie als zweite, getrennte Maßnahme. Siehe Azure-Identitätssicherheit: Warum MFA allein nicht reicht und Azure: privilegierter Zugriff und zu viele globale Administratoren. Eine Richtlinie auszurollen ersetzt die andere nicht; beide stehen aus gutem Grund auf Microsofts eigener Liste „Secure foundation".

5. Über Basis-MFA hinausgehen, sobald die Abdeckung stabil ist

Sobald eine breite MFA-Abdeckung durchgesetzt und stabil ist, wechseln Sie von der Basis-Authentifizierungsstärke Multifactor authentication strength zu phishing-resistenten oder passwortlosen Methoden für die Benutzer, die sie unterstützen können — siehe Entra ID: Änderung der Passwordless-MFA-Registrierung.

Wie EtcSec dies erkennt

Das Azure-/Entra-Audit von EtcSec prüft gezielt auf MFA_NOT_ENFORCED_ALL: eine Conditional-Access-Konfiguration, in der keine Richtlinie, die alle Benutzer und alle (oder praktisch alle) Cloud-Apps adressiert, eine Gewährungssteuerung trägt, die MFA oder eine MFA-gleichwertige Authentifizierungsstärke verlangt. Sie wird unabhängig von MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA und CA_NO_POLICY_ALL_USERS ausgewertet — eine dieser Prüfungen zu bestehen bereinigt diese hier nicht.