Conditional Access Report-Only-Modus, veraltete Ausnahmen: Richtlinien, die nicht wirklich durchgesetzt werden

Conditional Access Report-Only-Modus, veraltete Ausnahmen: Was „durchgesetzt" wirklich bedeutet

Conditional Access Report-Only-Modus und veraltete Ausnahmen sind die beiden häufigsten Gründe, warum eine Conditional-Access-Richtlinie im Microsoft Entra Admin Center als „Ein" angezeigt wird, aber überhaupt nichts blockiert. Beide Zustände werden bei einer schnellen Portalprüfung leicht übersehen, weil die Richtlinie weiterhin existiert, weiterhin die richtigen Bedingungen konfiguriert hat und weiterhin in der Richtlinienliste erscheint:

• Die Richtlinie — oder eine an ihr vorgenommene Änderung — befindet sich im Report-Only-Modus, der Anmeldungen auswertet und das Ergebnis protokolliert, aber niemals Zugriff gewährt, blockiert oder eine zusätzliche Anforderung stellt.
• Die Richtlinie wird durchgesetzt, aber ihre Ausnahmeliste ist über den engen, dokumentierten Grund hinausgewachsen, für den sie ursprünglich erstellt wurde, sodass genau die Anmeldungen, auf die es ankommt, unbehelligt daran vorbeirutschen.

Keins von beidem ist ein Fehler. Beides sind unterstützte, beabsichtigte Microsoft-Entra-Funktionen. Die Lücke ist operativer Natur: Niemand hat erneut geprüft, ob die Ausnahme noch gebraucht wurde. Entra ID bedingter Zugriff Lücken: welche Fehlkonfigurationen reale Angriffsflächen lassen behandelt den breiteren Umfang und die Kontrolllandschaft — fehlende Richtlinien, Workload-Identitäten, Legacy-Authentifizierung. Dieser Artikel bleibt eng fokussiert: was passiert, nachdem eine Richtlinie existiert, wenn ihr Durchsetzungsstatus oder ihre Ausnahmeliste unbemerkt von dem abweicht, was der Tenant für geschützt hält.

Report-Only-Modus: Die stille Nicht-Kontrolle

Report-Only ist ein richtlinienspezifischer Zustand in Conditional Access. Microsoft dokumentiert ihn als Möglichkeit für Administratoren, „die meisten Conditional-Access-Richtlinien zu testen, bevor sie aktiviert werden" — während der Anmeldung wertet das System die Richtlinie aus, setzt aber keine Grant- oder Sitzungskontrollen durch, und Benutzer werden von einer Report-Only-Richtlinie niemals zu MFA aufgefordert, auf Gerätekonformität geprüft oder blockiert.

Warum Report-Only von einem Testzustand zu einem dauerhaften wird

Der Mechanismus, der dies in der Praxis gefährlich macht, ist nicht der anfängliche Rollout — die meisten Teams staffeln neue Richtlinien bewusst im Report-Only-Modus für ein Prüffenster. Das Risiko ist die Drift danach: Eine durchgesetzte Richtlinie kann von jedem mit Conditional Access Administrator-Rechten unbemerkt in den Report-Only-Modus zurückgezogen werden. Microsofts eigene Dokumentation stellt ausdrücklich klar, dass der Report-Only-Modus unabhängig vom vorherigen Zustand einer Richtlinie niemals Grant- oder Sitzungskontrollen durchsetzt: „Während der Anmeldung wertet das System Richtlinien im Report-Only-Modus aus, setzt sie aber nicht durch." Dieser einzelne Schalter, geändert während einer Fehlerbehebungssitzung oder einer Notfallzugriffsausnahme und nie zurückgesetzt, entfernt lautlos eine Kontrolle, die jedes Dashboard und jede Richtlinienliste weiterhin als konfiguriert anzeigt.

Microsofts Empfehlung lautet, Änderungen an einer bestehenden, durchgesetzten Richtlinie zu validieren, indem man sie in eine Report-Only-Kopie klont, statt den Schalter der Originalrichtlinie umzulegen — die Ergebnisse der Kopie mit der Live-Richtlinie zu vergleichen und die Kopie dann zu verwerfen, sobald man zufrieden ist. Wird dieses Muster nicht befolgt, landet die Originalrichtlinie selbst im Report-Only-Modus — manchmal auf unbestimmte Zeit.

Veraltete und übermäßige Ausnahmen: Wie die Abdeckung mit der Zeit erodiert

Ausnahmen existieren aus echten operativen Gründen: ein Außenbüro, das eine Standortanforderung noch nicht erfüllen kann, ein Legacy-Gerät vor dem Austausch, ein Break-Glass-Konto. Microsofts eigene Anleitung zur Verwaltung ausgeschlossener Benutzer macht deutlich, dass dies klein beginnt und zu einem Problem heranwächst:

„Häufig gibt es bei der ersten Konfiguration einer Ausnahme eine kurze Liste von Benutzern, welche die Richtlinie umgehen. Im Laufe der Zeit werden weitere Benutzer zur Ausnahme hinzugefügt, und die Liste wächst. Irgendwann müssen Sie die Liste überprüfen und bestätigen, dass jeder dieser Benutzer weiterhin für die Ausnahme infrage kommt."

Drei Wege, wie Ausnahmelisten schlimmer werden, als sie aussehen

1. Einzelne Benutzer- oder Legacy-On-Premises-Gruppenausnahmen bieten keine laufende Sichtbarkeit. Benutzer wissen oft nicht, dass sie ausgeschlossen sind, und wenn die Ausnahme eine On-Premises-synchronisierte oder dynamische Gruppe verwendet, haben Administratoren nur begrenzten Einblick, wer darin ist oder warum.
2. Selbstbedienungs-Gruppenmitgliedschaft kann eine Ausnahme in eine Umgehung verwandeln. Wenn die Ausnahmegruppe einen Selbstbedienungsbeitritt erlaubt (ein legitimes Muster für das Szenario „reisender Mitarbeiter"), kann jeder Benutzer, der die Gruppe entdeckt, sich selbst hinzufügen.
3. Die Berechtigung wird nicht erneut geprüft. Ein Benutzer, der wegen eines inzwischen ersetzten Legacy-Geräts ausgeschlossen wurde, oder eine Auftragnehmerausnahme, die den Vertrag überdauert hat, bleibt unbegrenzt ausgeschlossen, weil nichts eine erneute Prüfung erzwingt.

Die kompensierende Kontrolle: Zugewiesene Gruppen plus wiederkehrende Zugriffsüberprüfungen

Microsofts empfohlene kompensierende Kontrolle besteht darin, jede Ausnahme durch eine dedizierte Microsoft-Entra-Sicherheitsgruppe mit zugewiesener Mitgliedschaft (keine Liste einzelner Benutzer, keine Legacy-synchronisierte Gruppe) abzusichern und eine wiederkehrende Zugriffsüberprüfung an diese Gruppe anzuhängen. Das dokumentierte Muster für eine standortbasierte Ausnahme ist eine Überprüfung, die wöchentlich läuft, nie endet, eine Selbstbestätigung von jedem Mitglied verlangt und jeden automatisch entfernt, der nicht antwortet. Für eine Legacy-Authentifizierungsausnahme ist das empfohlene Muster eine wiederkehrende Überprüfung mit Geschäftsbereichsverantwortlichen als Prüfern und automatisch angewendeten Ergebnissen. Beide Muster erfordern eine Microsoft Entra ID P2-, Microsoft Entra ID Governance- oder Enterprise Mobility + Security E5-Lizenz — Zugriffsüberprüfungen sind auf niedrigeren Stufen nicht verfügbar.

Ausnahmen haben auch einen Scope-blinden Fleck, den die meisten Prüfer nicht kontrollieren: Ressourcenausnahmen bei „Alle Ressourcen"-Richtlinien. Microsoft rollt ab dem 15. Juni 2026 eine Durchsetzungsänderung aus, die genau diese Lücke schließt. Bisher wurden Anmeldungen, die nur einen engen Satz von „Baseline-Scopes" (openid, profile, email, offline_access, User.Read und eine Handvoll ähnlicher Verzeichnis-Scopes) anforderten, stillschweigend vollständig von der Durchsetzung ausgenommen, wenn eine „Alle Ressourcen"-Richtlinie irgendeine Ressourcenausnahme hatte — selbst wenn der Administrator, der die Richtlinie erstellt hat, glaubte, „Alle Ressourcen" bedeute alles. Öffentliche Clients wie die Azure CLI oder VS Code sowie vertrauliche Web-Apps, die nur diese Scopes anfordern, kamen ungeprüft durch. Angreifer, die OAuth-Flows mit minimalen Scope-Anfragen missbrauchen, ähnlich dem, was bei Device-Code-Phishing passiert, sind genau die Art von Anmeldung, die diese Lücke unbemerkt hätte durchlassen können. Dies ist ein Fall, in dem Microsofts eigene Telemetrie bestätigte, dass Ausnahmen auf Ressourcenebene breitere, unbeabsichtigte Abdeckungslücken erzeugten, als Tenants realisierten — genau das Fehlerverhalten, um das es in diesem Artikel geht, nur auf der Scope-Ebene statt auf der Benutzerebene.

Erkennung

Erkennung ist hier eine Korrelationsübung über Anmeldenachweise und Richtlinienänderungsverlauf hinweg, kein einzelner Alarm.

🚨 Gefahr: Eine Richtlinie mit null reportOnlyFailure- oder Failure-Ereignissen ist nicht zwangsläufig gut abgestimmt. Es kann ebenso bedeuten, dass die Ausnahmen der Richtlinie so umfangreich sind, dass fast nichts tatsächlich dagegen ausgewertet wird.

Behebung (Remediation)

Report-Only-Drift schließen

1. Rufen Sie den aktuellen Aktivierungsstatus jeder Richtlinie und das Datum ihrer letzten Änderung ab. Jede Richtlinie im Report-Only-Modus ohne dokumentiertes Enddatum für das Prüffenster ist die Lücke — nicht nur „ist das ein neuer Test", sondern „besitzt jemand die Aufgabe, dies zu Enforced hochzustufen."
2. Alarmieren Sie speziell bei Audit-Protokollereignissen Ein → Report-Only. Dieser Übergang ist selten, bewusst und gefährlich, wenn er bei einer zuvor durchgesetzten Richtlinie auftritt — er sollte niemals lautlos geschehen.

Ausnahme-Drift schließen

3. Ersetzen Sie Einzelbenutzer- und Legacy-synchronisierte-Gruppen-Ausnahmen durch dedizierte Entra-Sicherheitsgruppen mit zugewiesener Mitgliedschaft. Dies ist die Voraussetzung für den nächsten Schritt; Zugriffsüberprüfungen zielen auf Gruppen, nicht auf Ad-hoc-Benutzerlisten.
4. Hängen Sie an jede Ausnahmegruppe eine wiederkehrende Zugriffsüberprüfung an, gemäß Microsofts dokumentierten Mustern: Selbstbestätigung mit automatischer Entfernung für Reise-/Standortausnahmen, von Verantwortlichen geprüft mit automatischer Anwendung für Legacy-Auth- oder Geräteausnahmen. Dies erfordert eine Entra ID P2- oder Entra ID Governance-Lizenz.
5. Überprüfen Sie jede „Alle Ressourcen"-Richtlinie mit einer Ressourcenausnahme gegen die Durchsetzungseinführung der Baseline-Scopes vom 15. Juni 2026. Entscheiden Sie bewusst — aktivieren Sie die neue Durchsetzung frühzeitig über die Baseline-Scopes-Einstellungen, oder verwenden Sie „Verhalten anpassen" für die spezifischen Anwendungen, die die Legacy-Ausnahme wirklich benötigen — statt Microsofts Standard-Rollout stillschweigend entscheiden zu lassen.
6. Validieren Sie mit Nachweisen erneut, nicht mit Annahmen. Bestätigen Sie nach jeder Hochstufung von Report-Only zu durchgesetzt oder jeder Bereinigung einer Ausnahmegruppe das Ergebnis in den Anmeldeprotokollen für repräsentative ausgeschlossene und eingeschlossene Konten, nicht nur auf dem Konfigurationsbildschirm der Richtlinie.

Wie EtcSec dies erkennt

Die Azure/Entra-Prüfungen von EtcSec bilden die beiden Fehlermodi in diesem Artikel direkt ab: CA_POLICY_REPORT_ONLY kennzeichnet Conditional-Access-Richtlinien, die sich noch im Report-Only-Modus befinden, CA_EXCESSIVE_EXCLUSIONS und CA_GROUP_EXCLUSION_LARGE kennzeichnen Richtlinien, deren Ausnahme-Scope im Verhältnis zu ihrer Absicht groß geworden ist, und CA_USER_EXCLUSIONS_STALE kennzeichnet Ausnahmen auf Benutzerebene, die keinen Nachweis einer kürzlichen erneuten Überprüfung zeigen. Da beide Fehlermodi von Drift handeln statt von einem einmaligen Einrichtungsfehler, liegt der Wert darin, die Prüfung planmäßig erneut auszuführen — ein Tenant, der diese Prüfung vor sechs Monaten bestanden hat, kann sie heute lautlos nicht mehr bestehen, ohne dass eine einzige Richtlinie gelöscht oder eine einzige Einstellung geändert wurde.

Weiterführende Lektüre

• Entra ID bedingter Zugriff Lücken: welche Fehlkonfigurationen reale Angriffsflächen lassen
• Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden
• MFA Fatigue: Erkennung und Prävention für Microsoft Entra ID
• Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant
• Device Code Phishing: Wie OAuth Device Flow Entra-ID-Konten kompromittiert
• Azure Identity Protection: Reaktion auf Kompromittierte Konten

Primärquellen

• Conditional Access Policy Insights: Monitoring and Evaluation
• Conditional Access Insights and Reporting workbook
• Manage users excluded from Conditional Access policies
• Enforcement for baseline scopes in Conditional Access
• appliedConditionalAccessPolicy resource type — Microsoft Graph v1.0
• What are Microsoft Entra sign-in logs?