Conditional Access Grundlagen

Was Conditional Access tatsächlich ist

Conditional Access (CA) ist die Policy-Engine von Entra, die Zugriffe auf Cloud-Apps anhand von Signalen bewertet und steuert.

Wichtige Signale (Beispiele):

Benutzer-/Gruppenzugehörigkeit (inkl. Admin-Rollen)
Geräte-Status (compliant, hybrid-joined, MDM-registriert)
Client-Typ (Browser, mobile Apps, Legacy Auth)
Standort (Named Locations), Risiko (Sign-in/User risk)

Ergebnis sind Controls wie MFA, Block, Device-Requirement, Session Controls.

Designregeln, die sich bewährt haben

1) Policies als “Produkte” betreiben

Jede Policy hat einen Owner, ein Ziel und eine kurze Begründung.
Änderungen laufen über Review und dokumentierten Rollout.
Nutze Report-only vor produktivem Enforcement.

2) Saubere Scope-Strategie

Verwende Gruppen als Ziel (keine Einzelpersonen).
Trenne Admin-Policies von User-Policies.
Plane Break-Glass Accounts, die bewusst aus CA ausgenommen sind (stark geschützt, überwacht, nicht im Alltag genutzt).

3) Legacy Authentication früh blocken

Legacy Auth (z. B. Basic Auth) ist ein häufiger Einfallspunkt. Eine klare Baseline ist:

Legacy Auth blockieren (separat, mit Monitoring vor Cut-over)
Ausnahmen nur befristet und nachvollziehbar

4) Phishing-resistente Authentifizierung bevorzugen

Wenn möglich, steuere nicht nur “MFA ja/nein”, sondern die Qualität:

Authentication Strengths (z. B. FIDO2, Windows Hello for Business)
Vermeide schwache Faktoren als Default (SMS/Voice) – nur als Übergang/Exception.

Typische Baseline-Policies (Startpunkt)

Alle Benutzer: MFA/Strong Auth für cloud apps (je nach Risiko-/Gerätestrategie).
Admins: MFA/Phish-resistant + compliant device + eingeschränkte Locations.
Legacy Auth: Block.
High-risk Sign-ins: Block oder zwingend Password reset (abhängig vom Risiko-Signal).

Wichtig: CA-Policies wirken gemeinsam. Eine Block-Entscheidung “gewinnt”.

Beispiel: Admin-Portale separat absichern

In der Praxis ist es hilfreich, Admin-Zugriffe als eigenes Paket zu behandeln:

Ziel: Admin-Rollen (oder dedizierte Admin-Gruppen)
Cloud App: “Microsoft Admin Portals”
Controls: phish-resistente Authentifizierung + compliant device
Optional: Named Locations / restriktivere Session

So verhinderst du, dass Admin-Sicherheit “weich” wird, nur weil User-Policies aus UX-Gründen nicht maximal hart sein können.

Details dazu: Conditional Access für Admin-Portale.

Rollout ohne Selbstschuss

Pragmatischer Ablauf:

Report-only aktivieren und mindestens einige Tage Daten sammeln.
Betroffene Clients/Flows identifizieren (Legacy Auth, Service Accounts, nicht compliant Geräte).
Ausnahmen minimieren und mit Ablaufdatum versehen.
Enforcement aktivieren, zunächst in Wellen (Pilotgruppen).

Praktischer Tipp: Behandle CA wie Code – mit Rolloutplan, Verantwortlichkeit und Rückfalloption. Der wichtigste Teil ist selten die Policy selbst, sondern der kontrollierte Übergang.

Troubleshooting: Wo schaue ich nach?

Entra Sign-in Logs: welche CA-Policies wurden angewendet, welcher Control hat geblockt?
Geräteseite: ist das Gerät wirklich compliant (Intune), und wann wurde es zuletzt ausgewertet?
Client: Browser vs Modern Auth App – Legacy Clients verhalten sich anders.

Wenn du in Logs ein “Expected/Unexpected”-Bild brauchst:

Vergleiche einen funktionierenden Sign-in mit einem fehlschlagenden (gleicher User, gleiche App, anderes Gerät/Netz).
Prüfe, ob sich der Client-App-Typ unterscheidet (Modern vs Legacy) – das erklärt viele “plötzliche” Brüche.

Wenn CA plötzlich “Legacy”-Flows abwürgt, siehe auch Conditional Access bricht Legacy Auth.