Microsoft-Services · Glossar

Conditional Access

Microsofts Regel-basiertes Zugriffssteuerungs-System — „Wenn …, dann …“. Conditional Access wertet Signale (User, Gerät, Standort, Risiko) aus und entscheidet, ob ein Login erlaubt wird, welche Auflagen gelten, oder ob er geblockt wird. Das Herzstück von Zero Trust.

Auf einen Blick
Entra P1
Lizenz-Voraussetzung
IF-THEN
Regel-Struktur
25+
Signale verfügbar
Log only
Test-Modus vor Enforcement

Was ist Conditional Access?

Conditional Access (CA) ist ein Policy-Framework in Microsoft Entra ID, das bei jedem Login eines Users entscheidet, ob und wie der Zugriff gewährt wird. Die Logik folgt immer einem einfachen Muster:

Wenn User X, mit Gerät Y, von Standort Z, auf App A zugreifen will —
Dann mach B (erlauben / blockieren / MFA verlangen / Compliant Device fordern / …).

Conditional Access ist damit das Herzstück moderner Zero-Trust-Architektur. Statt User pauschal „drin“ oder „draußen“ zu behandeln, wird jeder einzelne Zugriff kontextabhängig bewertet.

Die Signale, auf die CA reagiert

Signal-KategorieBeispiele
User / GruppeIndividuelle User, Sicherheits-Gruppen, alle Gastbenutzer, Rollen
Cloud AppExchange, SharePoint, Teams, M365, AVD, Windows 365, individuelle SaaS-Apps
StandortNamed Locations (IP-Bereiche), Länder, bekannte vs. unbekannte Netze
Device PlatformWindows, macOS, iOS, Android, Linux
Device StateEntra-Joined, Compliant (Intune), Hybrid-Joined, Unmanaged
Client-AppBrowser, Mobile App, Desktop Client, Legacy Protocols (IMAP/POP)
Sign-In Risk (P2)Real-time Risk-Score (Low/Medium/High) basierend auf ML
User Risk (P2)Account-Compromise-Indicator aus Threat Intelligence

Was CA als Reaktion tun kann

Zugriffs-Kontrollen (Grant Controls)

  • Block Access — harter Block
  • Require MFA — zweiter Faktor erzwingen
  • Require Compliant Device — nur von Intune-Compliant-Geräten
  • Require Hybrid Joined Device — nur von Domain-Joined-Geräten
  • Require Approved Client App — nur aus Microsoft-Apps (Outlook Mobile, Teams)
  • Require App Protection Policy — App-MAM-Schutz
  • Require Authentication Strength — z.B. phishing-resistentes MFA (FIDO2)
  • Require Password Change — bei erhöhtem User Risk

Session-Kontrollen

  • Sign-In Frequency — User muss sich alle X Stunden neu anmelden
  • Persistent Browser Session — „Angemeldet bleiben“ erlauben/verbieten
  • App Protection via MCAS — Defender for Cloud Apps Session Restrictions
  • Require Continuous Access Evaluation

Typische CA-Policies in der Praxis

Klassische Baseline-Policies

Policy-NameWENNDANN
MFA für alleAlle User, alle Apps, alle StandorteMFA erforderlich
Block Legacy AuthClient-App = IMAP/POP3/SMTPBlock
Admin-MFA-AlwaysUser hat Admin-RolleMFA ohne Trusted-Locations-Exception
Block LänderLogin aus High-Risk-LändernBlock
Compliant Device für M365Zugriff auf Exchange, SharePoint, OneDriveIntune-Compliant Gerät
Gäste-RestrictionUser-Typ = GuestNur spezifische Apps zugreifbar
High Risk BlockSign-In Risk = High (P2)Block + Password Change

Break-the-Glass-Accounts: Bei jeder CA-Strategie mindestens 2 Admin-Accounts außerhalb aller CA-Policies haben (Exclude-Liste). Sonst kann ein Policy-Fehler den gesamten Tenant aussperren.

Conditional Access für AVD und Windows 365

Conditional Access ist für DaaS-Szenarien besonders wichtig — und hat dort ein paar Spezialfälle.

Die zwei relevanten Apps in CA für AVD

  • Azure Virtual Desktop (Cloud App): Steuerung des Zugangs zum AVD-Broker
  • Azure Windows VM Sign-in (für Entra-Joined Session Hosts): Steuerung des Windows-Logins in der Session

Diese sind unabhängig — man kann z.B. den AVD-Broker-Zugang locker machen, aber den Windows-Login strikt (MFA + Compliant Device).

Windows 365

Für Windows 365 reicht eine Policy auf die Cloud-App „Windows 365“. Da der Cloud-PC selbst Entra-Joined ist, gilt die Policy für den gesamten Zugang.

Best-Practice-Pattern für DaaS

  1. User mit Zugriff auf AVD/W365 grundsätzlich mit MFA absichern
  2. Externen Zugang nur aus bekannten Ländern erlauben
  3. Unmanaged Endgeräte: nur Browser-Access zu W365/AVD — kein Desktop-Client-Download auf private Geräte
  4. Admin-Pools: zusätzlich phishing-resistentes MFA (FIDO2-Key)

CA-Patterns in DaaS Maps

Die DaaS Maps zeigen Conditional-Access-Patterns für AVD, Windows 365 und weitere DaaS-Plattformen. Zum Austausch über CA-Design und Zero-Trust-Strategien findet ihr mich auf LinkedIn.