In vielen Tenants, die ich mir anschaue, hakt es bei Conditional Access weniger an der Technik als am Vertrauen in die eigene Konfiguration. Kaum etwas ist unangenehmer als ein frisch ausgerolltes Regelwerk, das plötzlich wichtige Leute aussperrt. Bei Remote-Arbeitsplätzen tut das besonders weh. Zum Glück gibt es seit einiger Zeit mehrere Werkzeuge, mit denen sich Conditional Access testen lässt, bevor die Regeln tatsächlich greifen. Wer sie geschickt einsetzt, bringt Richtlinien zügig und nachvollziehbar in den Betrieb und erlebt dabei keine bösen Überraschungen.

Der Report-only-Modus ist die wichtigste Sicherheitsleine beim Testen

Am stressfreisten führt man Conditional-Access-Richtlinien heute fast immer im Report-only-Modus ein, und auch Änderungen lassen sich so gut vorbereiten. Ist eine Policy im Entra Admin Center angelegt, setzt man sie einfach auf „Report-only“. Dann wird ihre Wirkung nur simuliert. Entra ID bewertet jede Anmeldung und protokolliert, ob die Policy gegriffen hätte, erzwingt aber nichts. Für mich ist das der Standardweg, um komplexere Regeln oder Anpassungen ohne Risiko vorzubereiten. Im Alltag schaue ich regelmäßig direkt in die Anmeldeprotokolle und prüfe, wie viele Ereignisse eine Policy betreffen würde. Sehr hilfreich ist dabei der eigene „Report-only“-Tab, den die Detailansicht jeder Anmeldung schon seit Längerem bietet. Dort steht genau, wie sich die Policy ausgewirkt hätte, samt Begründung, warum die Anmeldung erfolgreich gewesen oder blockiert worden wäre.

Praktischer Tipp: Gebt jeder neuen Policy einen sprechenden Namen mit Präfix, etwa „[Test-RO]“ für die Report-only-Phase. Dann weiß man auch nach Wochen noch, welche Richtlinien gerade geprüft werden und welche längst produktiv laufen.

Das What-If-Tool prüft Richtlinien, bevor sich jemand anmeldet

Noch bevor ich eine Policy in den Report-only-Modus schalte, nutze ich oft das What-If-Tool (Entra Admin Center → Schutz → Conditional Access → Richtlinien → What If). Damit spiele ich verschiedene Szenarien durch, ohne dass sich ein Benutzer wirklich anmelden muss. Ich wähle einen Benutzer aus, dazu bestimmte Apps, Standorte oder Gerätetypen, und lasse mir anzeigen, welche Policies greifen würden. Gerade wenn neue Ausnahmen schnell überprüft werden sollen, etwa für Service Accounts oder spezielle Geräte, spart das viel Zeit. Einzelheiten und Hinweise zur Bedienung stehen in der Dokumentation von Microsoft.

Das Insights-Workbook wertet echte Anmeldedaten aus

Wer tiefer einsteigen möchte, greift zum Conditional Access Insights and Reporting Workbook. Dafür müssen die Anmeldeprotokolle von Entra ID allerdings über eine Diagnoseeinstellung (Diagnostic Setting) in einen Log-Analytics-Workspace fließen (Azure Log Analytics setzt passende Lizenzen und Rollen voraus, z. B. Azure Monitor Reader, Entra ID P1/P2). Das Workbook findet man im Entra Admin Center unter „Überwachungsdaten“ oder im Azure-Portal als Workbook-Vorlage. Dort werte ich gebündelt aus, wie Policies in der Vergangenheit gewirkt hätten, welche Benutzer betroffen gewesen wären und welche Fehlermeldungen häufig auftauchen. Vieles davon erklärt Microsoft auch in der Anleitung zu Insights & Reporting.

Das folgende Diagramm zeigt, wie die Werkzeuge ineinandergreifen, damit sich Conditional Access testen lässt, bevor eine Policy scharf geschaltet wird:

flowchart TD
    PolicyErstellen["Policy erstellen"] --> WhatIf["What If-Test durchführen"]
    PolicyErstellen --> ReportOnly["Report-only-Modus aktivieren"]
    ReportOnly --> SignInLogs["Sign-in-Protokolle prüfen"]
    SignInLogs --> Workbook["Insights Workbook auswerten"]
    Workbook --> PolicyAktivieren["Policy produktiv schalten"]

Abbildung: Test- und Analysewerkzeuge für Conditional Access während des Rollouts.

Pilotgruppen und Notfallkonten gehören zu jedem Rollout

So ausgereift die Technik inzwischen ist, ohne durchdachtes Rollout-Konzept kommt beim Testen von Conditional Access niemand aus. Bewährt hat sich, neue Policies zunächst nur auf festgelegte Pilotgruppen anzuwenden und Service- sowie Notfallkonten bewusst auszunehmen. Die bekannten „Break-Glass“-Konten dürfen von neuen Policies grundsätzlich nie erfasst werden. Wie man solche Konten sauber einrichtet und absichert, habe ich ausführlich in Notfallzugriffskonten in Entra ID: Sicher umgesetzt 2024 beschrieben. Erst wenn die Testgruppe mehrere Tage lang keine Probleme meldet und auch das Reporting keine auffälligen Ausreißer zeigt, weite ich die Policy schrittweise aus. Das Monitoring bleibt dabei engmaschig. Wer für den Anfang die wichtigsten Policies sucht, findet konkrete Beispiele in diesem Beitrag: Conditional Access in Microsoft Entra ID: Die ersten Richtlinien, die jeder Tenant braucht.

Eine saubere Dokumentation ist Pflicht und kein Luxus

Wer seine Conditional-Access-Strategie klar dokumentiert, besteht Audits leichter und findet später auch Fehler oder überflüssige Regeln schneller. Ich notiere, welche Policies produktiv sind, welche noch im Test laufen („Report-only“), welche Gruppen oder Benutzer ausdrücklich ausgeschlossen sind und wann das nächste Review fällig ist. Mit einer verständlichen Namenskonvention sieht man schon im Portal auf einen Blick, ob eine Richtlinie produktiv ist oder getestet wird. So entsteht kein Durcheinander, wenn nach Monaten der Überblick fehlt oder ein Kollege die Betreuung übernimmt.

Wer gründlich testet, bleibt entspannt

Conditional Access zu testen ist heute kein Hexenwerk mehr, auch wenn die Tücken im Detail stecken. Mit Report-only, What If und dem Insights-Workbook hält man das Risiko klein und behält den Überblick. Die Technik allein reicht aus meiner Sicht aber nicht. Erfolgreich werden Policies erst, wenn Dokumentation und ein sauberer Rollout dazukommen. Und es ist eine Menge wert, wenn niemand mehr nachts angerufen wird, weil schon wieder jemand ausgesperrt ist.