Conditional-Access-Blockaden debuggen
Das Was-wäre-wenn-Tool als einzige seriöse Methode, eine CA-Policy zu zerlegen – ohne einen einzigen User auszusperren.Conditional-Access-Blockaden debuggen mit dem Was-wäre-wenn-Tool
Eine Conditional-Access-Policy zu debuggen, indem man Leute sich live einloggen lässt und schaut, was passiert, ist ungefähr so clever wie die Sicherung rauszudrehen, um zu prüfen, ob der Strom an ist. Das Was-wäre-wenn-Tool ist die einzige seriöse Methode, eine CA-Blockade zu zerlegen: Du baust den Anmeldefall nach, das Tool sagt dir, welche Policy greift und warum — ohne dass ein einziger echter User dabei ausgesperrt wird.
Eingaben rein, Auswertung gegen alle Policies, Verdikt pro Policy raus — eine reine Trockenübung.
Was das Was-wäre-wenn-Tool eigentlich tut
Das Tool findest du im Entra Admin Center unter Schutz → Conditional Access → Richtlinien → Was-wäre-wenn (früher unter „Azure AD"). Du gibst einen fiktiven Anmeldefall ein — welcher User, welche Cloud-App, welche IP beziehungsweise Named Location, welche Plattform, welcher Geräte-Status, welches Risiko — und das Tool wertet sämtliche Policies deines Tenants gegen genau diese Eingaben aus. Heraus kommt eine Liste: Welche Policy greift, welche nicht, und vor allem warum.
|
Info Das Tool wertet auch Report-only-Policies aus. Das ist Gold wert: Du kannst eine neue Policy im Report-only-Modus bauen, sie mit dem Was-wäre-wenn-Tool gegen Dutzende Szenarien durchspielen und siehst, wen sie blocken würde — bevor du sie überhaupt scharf schaltest. So findet niemand morgens die Tür verriegelt vor, weil du abends „nur kurz" eine Policy aktiviert hast. |
|---|
Der Debug-Workflow: vom Ticket zur Ursache
Ein sauberer Ablauf erspart dir das wilde Klicken. Das Sign-in Log liefert den Verdacht (meist Code 53003), das Was-wäre-wenn-Tool liefert den Beweis. Fünf Schritte, immer dieselben:
Log öffnen, Eckdaten notieren, Fall nachbauen, Ergebnis lesen, gezielt korrigieren — und gegenprüfen.
Der entscheidende Trick steckt in Schritt 2: Notiere dir aus dem Sign-in Log die exakten Eckdaten — User, App, IP, Plattform, Gerätestatus. Genau diese Werte fütterst du anschließend ins Tool. Je näher die Simulation am echten Fall liegt, desto präziser das Ergebnis. Wer hier schludert und „ungefähr" eingibt, debuggt am Ende den falschen Fall.
|
Praxis-Tipp Nach jeder Korrektur sofort die Gegenprobe machen: denselben Fall noch einmal simulieren. Klingt banal, wird aber ständig vergessen. Ich habe schon Tenants gesehen, in denen drei „Fixes" hintereinander gebaut wurden, ohne dazwischen zu prüfen — am Ende war die ursprüngliche Blockade weg, dafür zwei neue da. Ein Fix, eine Gegenprobe. Disziplin schlägt Bauchgefühl. |
|---|
Das Ergebnis richtig lesen: Block schlägt Grant
Das Tool listet pro Policy auf, ob sie angewendet wird und welche Grant-Controls sie verlangt. Hier lauert der häufigste Denkfehler: Conditional Access funktioniert nach dem Prinzip „Block gewinnt immer". Wenn auch nur eine einzige Policy den Zugriff blockt, ist Schluss — egal wie viele andere Policies „Zugriff gewähren" sagen. Du suchst also nicht die Policy, die Zugriff erlaubt, sondern die eine, die blockt.
|
Ergebnis im Tool |
Bedeutung |
Deine Aktion |
|---|---|---|
|
Wird angewendet — Block |
Diese Policy sperrt den Fall aus |
Der Schuldige. Bedingung oder Ausschluss prüfen. |
|
Wird angewendet — Grant (MFA o. Ä.) |
Greift, verlangt aber eine Kontrolle |
Prüfen, ob der User die Kontrolle erfüllen kann |
|
Wird nicht angewendet |
Bedingung traf nicht zu |
Tool nennt die fehlende Bedingung — nützlich, wenn die Policy greifen SOLLTE |
|
Report-only — würde greifen |
Noch nicht scharf, aber wirksam |
Vor dem Aktivieren Auswirkung abschätzen |
Die Grenzen des Tools — und wo du trotzdem ins Log musst
So gut das Tool ist: Es bewertet Policies, es simuliert keinen echten Login. Es weiß nicht, ob das Passwort stimmt, ob der MFA-Prompt durchläuft oder ob das Gerät in Intune wirklich als konform gemeldet ist. Es nimmt deine Eingaben als gegeben hin. Für die Frage „Greift die richtige Policy?" ist es perfekt — für „Kommt der User am Ende wirklich rein?" bleibt das echte Sign-in Log die Wahrheit.
Das Tool deckt jede Policy-Logik auf, ersetzt aber keinen echten Anmeldeversuch.
|
Achtung Verlass dich beim Geräte-Status nicht blind auf deine Eingabe. Du kannst im Tool „Gerät ist konform" ankreuzen — aber wenn das echte Gerät in Intune gar nicht konform gemeldet ist, simulierst du eine Wunschwelt. Der Klassiker: Im Tool ist alles grün, in der Realität scheitert der User trotzdem an 53000 („Gerät nicht konform"), weil die Compliance-Auswertung erst beim echten Login passiert. Gleiche dein Tool-Szenario immer mit dem ab, was im Sign-in Log und in Intune tatsächlich steht. |
|---|
Beispiel aus der Praxis
Bei der Musterwerk GmbH (Industrie, Entra ID P1) kam der Vertriebsleiter unterwegs nicht mehr in SharePoint. Das Sign-in Log zeigte Code 53003 und im Detail-Tab eine Policy namens „Block Legacy & untrusted Locations". Der erste Verdacht: Legacy-Authentifizierung. Statt nun an der Policy zu schrauben, baute der Admin den Fall im Was-wäre-wenn-Tool nach — User, SharePoint, die Hotel-IP aus dem Log, Plattform iOS.
Das Ergebnis war eindeutig: Nicht die Legacy-Bedingung griff, sondern eine Named Location. Die Hotel-IP fiel in keinen der definierten „Trusted"-Bereiche, und die Policy blockte alles außerhalb. Die Lösung war nicht, Legacy freizugeben (das wäre fatal gewesen), sondern eine saubere Ausnahme für vertrauenswürdige mobile Szenarien mit MFA-Pflicht. Ohne das Tool hätte das Team an der falschen Schraube gedreht und ein echtes Sicherheitsloch aufgerissen.
Verwandte Artikel
Häufige Fragen (FAQ)
Wo finde ich das Was-wäre-wenn-Tool in Entra ID?
Im Entra Admin Center unter „Schutz → Conditional Access → Richtlinien". Dort gibt es oben den Button „Was-wäre-wenn". Früher lag das unter „Azure Active Directory → Sicherheit → Conditional Access". Du brauchst mindestens Leserechte auf Conditional Access, um es zu nutzen.
Sperrt das Was-wäre-wenn-Tool echte Nutzer aus?
Nein. Das Tool ist eine reine Simulation. Es gibt kein Token aus, löst keinen echten Login aus und verändert nichts an deinen Policies. Du kannst beliebig viele Szenarien durchspielen, ohne dass ein einziger Nutzer etwas davon merkt. Genau deshalb ist es der sichere Weg zum Debuggen.
Warum zeigt das Tool eine Policy als „wird nicht angewendet"?
Weil mindestens eine Bedingung der Policy auf deinen simulierten Fall nicht zutrifft — etwa die falsche App, eine nicht passende Plattform oder ein ausgeschlossener User. Das Tool nennt dir die konkrete Bedingung. Das ist besonders nützlich, wenn eine Policy eigentlich greifen sollte, es aber nicht tut.
Berücksichtigt das Tool auch Report-only-Policies?
Ja, und das ist einer seiner größten Vorteile. Du kannst eine neue Policy im Report-only-Modus bauen und mit dem Tool durchspielen, wen sie blocken würde — komplett risikolos, bevor du sie aktivierst. So vermeidest du böse Überraschungen beim Scharfschalten.
Was bedeutet „Block gewinnt" bei Conditional Access?
Sobald eine einzige Policy den Zugriff blockiert, ist der Zugriff verweigert — unabhängig davon, wie viele andere Policies ihn gewähren würden. Beim Debuggen suchst du deshalb nicht die erlaubende Policy, sondern die blockierende. Das Was-wäre-wenn-Tool macht genau diese eine sichtbar.
Reicht das Tool, um ein Anmeldeproblem komplett zu lösen?
Für reine Conditional-Access-Fragen ja. Für Passwort-, MFA-, Geräte-Compliance- oder Lizenzprobleme nicht — diese sieht das Tool nicht, weil es deine Eingaben als gegeben annimmt. Hier bleibt das echte Sign-in Log die Wahrheitsquelle. Tool und Log ergänzen sich: Simulation für die Policy-Logik, Log für die Realität.
Wie geht es weiter?
|
Dein nächster Schritt Wenn dein Conditional-Access-Setup über die Jahre zu einem undurchsichtigen Dickicht aus Policies, Ausnahmen und Report-only-Resten geworden ist, lohnt ein Architektur- oder Redesign-Workshop: Wir nehmen deine Policies gemeinsam auseinander, simulieren die kritischen Szenarien sauber durch und bauen ein nachvollziehbares, dokumentiertes Regelwerk — damit das nächste Ticket in fünf Minuten gelöst ist statt in fünf Stunden Rätselraten. |
|---|