Sektion 20: Conditional Access: Zugriff steuern basierend auf Compliance

Einleitung

Conditional Access ist das Herzstück jeder modernen Zero-Trust-Strategie – und die Kopplung mit der Geräte-Compliance ist der Moment, in dem aus Intune mehr als ein Verwaltungswerkzeug wird: ein echtes Kontrollinstrument. Während Compliance-Richtlinien in Intune nur festlegen, wie ein Gerät beschaffen sein muss, entscheidet Conditional Access, was passiert, wenn ein Gerät diese Anforderungen nicht erfüllt. Erst durch dieses Zusammenspiel entsteht ein geschlossener Sicherheitskreis: bewerten, entscheiden, durchsetzen.

In dieser Sektion gehen wir das Thema vom Fundament an: Du lernst, wie Conditional Access technisch funktioniert, wie der Compliance-Status von Intune nach Microsoft Entra ID übertragen wird, wie Du sinnvolle Richtlinien mit Ausschlüssen und Break-Glass-Konten aufbaust – und wie Du die klassischen Fehlerquellen systematisch troubleshootest, wenn User mit „Device is not compliant“-Meldungen an Deiner Tür klopfen.

Grundkonzepte: Wie Conditional Access und Compliance zusammenspielen

Conditional Access als If-Then-Konstrukt

Jede Conditional-Access-Richtlinie folgt einer simplen Logik: WENN ein Signal eine Bedingung erfüllt, DANN greift eine Zugriffssteuerung. Signale sind Benutzer, Standort, Anwendung, Risiko – und eben der Gerätestatus. Ein typisches Beispiel:

WENN ein User auf Exchange Online zugreift UND das Gerät nicht compliant ist …
DANN wird der Zugriff blockiert oder auf einen Compliant-Status beschränkt.

Wichtig für das Verständnis: Conditional Access wird zur Anmeldung ausgewertet, nicht kontinuierlich. Entra ID prüft den Gerätestatus im Moment des Token-Ausstellens. Das erklärt, warum Änderungen am Compliance-Status bis zur nächsten Anmeldung oder Token-Erneuerung (Access Tokens laufen typischerweise nach 60–90 Minuten ab) unsichtbar bleiben können.

Die drei Bausteine einer Richtlinie

Jede CA-Richtlinie besteht aus drei Blöcken:

Assignments (Zuweisungen): Wer (Users/Groups), womit (Cloud-Apps), unter welchen Bedingungen (Conditions: Plattform, Standort, Client-App, Risiko, Gerätefilter).
Access Controls – Grant (Gewährung): Was verlangt wird – Multi-Factor Authentication, Compliant Device, Domain-Joined Device oder eine Kombination mit UND/ODER-Logik.
Access Controls – Session (Sitzung): Zusätzliche Beschränkungen der Sitzung selbst – App-Enforced Restrictions, Conditional Access App Control oder begrenzte Sitzungsdauer für unsichere Geräte.

Compliance: Der Gerätestatus als Signal

Eine Compliance-Richtlinie in Intune bewertet ein Gerät anhand konkreter Einstellungen: BitLocker-Verschlüsselung, Firewall, Defender-Status, minimale OS-Version, Jailbreak/Root-Erkennung, benötigte Patch-Level. Das Ergebnis dieser Bewertung schreibt Intune in das Geräteobjekt in Entra ID: compliant, not compliant oder in grace period.

Die CA-Steuerung „Gerät muss als konform markiert sein“ (Require device to be marked as compliant) liest exakt dieses Attribut aus. Microsoft empfiehlt diese Steuerung ausdrücklich gegenüber der älteren Variante „Domain-Joined ODER konform“, weil Letztere ein rein lokales Domänen-Gerät ohne Intune-Verwaltung durchlässt – ein Zustand, der in einer Zero-Trust-Welt ein Sicherheitsrisiko darstellt.

Gerätearten und ihre Bedeutung

Nicht jedes Gerät kann den Compliance-Status liefern. Du musst die Gerätekategorien kennen:

Microsoft Entra Hybrid Joined: In die lokale AD eingebundene Geräte, die per Sync oder Co-Management zu Intune reporting. Typisch für klassische Unternehmensumgebungen.
Microsoft Entra Joined: Direkt in Entra eingebundene Geräte, meist per Autopilot bereitgestellt. Der Standard für moderne Cloud-First-Umgebungen.
Microsoft Entra Registered: Persönliche Geräte (BYOD), die mit einem Arbeitskonto registriert sind. Sie können compliant sein, wenn sie per MDM verwaltet werden – sind sie nur per MAM (App-Schutzrichtlinien) verwaltet, liefern sie kein Compliance-Signal.

Der letzte Punkt ist eine der häufigsten Stolperfallen: Ein BYOD-Gerät mit reinen App-Schutzrichtlinien (MAM ohne Enrollment) kann eine „Require Compliant Device“-Richtlinie niemals erfüllen – und wird konsequent blockiert. Dafür existieren MAM-Steuerungen wie „Approved Client App“, die in Kombination mit Gerätefiltern und Ausnahmen sauber abgebildet werden müssen.

Praxis-Implementierung: Der sichere Aufbau in fünf Schritten

Schritt 1: Compliance-Richtlinie erstellen und zuweisen

Bevor Du Conditional Access verschärfst, muss die Compliance-Seite stehen. Navigiere zu Intune Admin Center → Devices → Compliance → Policies und erstelle für Windows 10/11 eine Richtlinie mit sinnvollen Defaults:

BitLocker aktiviert und funktionsfähig
Firewall aktiviert
Defender-Antimalware aktiviert und aktuell
Minimale OS-Version (z.B. aktuelle Windows-11-Build)
Device Health Attestation bestanden

Weise die Richtlinie einer Gerätegruppe zu, die alle verwalteten Geräte enthält. Vergiss nicht: Compliance-Richtlinien wirken auf Geräte, CA-Richtlinien auf User – Du orchestrierst also zwei Seiten desselben Systems.

Schritt 2: Break-Glass-Konto und Ausschlussgruppe anlegen

Bevor irgendeine CA-Richtlinie scharf geschaltet wird, baust Du die Rettungsleine:

Erstelle ein dediziertes Notfallkonto (z.B. ca-emergency@domain.de) mit starkem, in einem Tresor dokumentiertem Passwort und aktivierter MFA.
Erstelle eine Entra-Sicherheitsgruppe CA-Exclusion-BreakGlass und nimm ausschließlich dieses Konto auf.
Schließe diese Gruppe in jeder CA-Richtlinie aus. Das ist nicht optional – ein Fehler in einer auf „All Users“ zielenden Richtlinie sperrt ohne Ausschluss den gesamten Tenant.

Schritt 3: Die CA-Richtlinie im Report-Only-Modus

Erstelle unter Entra Admin Center → Protection → Conditional Access → New policy folgende Richtlinie:

Users: All Users, excluding CA-Exclusion-BreakGlass
Target resources: All cloud apps
Conditions → Device platforms: Windows, iOS/iPadOS, Android
Conditions → Filters for devices: device.managementType -eq "mdm" – damit adressierst Du nur wirklich per MDM verwaltete Geräte
Grant: „Require device to be marked as compliant“
Enable policy: Report-only

Der Report-Only-Modus ist die wichtigste Waffe gegen Selflockouts: Die Richtlinie wird für jede Anmeldung simuliert und protokolliert, ohne etwas zu blockieren. Lass sie mindestens 5–7 Tage laufen und werte die Sign-In-Logs aus, bevor Du auf „On“ stellst.

Schritt 4: Was passiert mit Outlook, Teams und Co.?

Moderne Authentifizierung (OAuth) macht CA-Richtlinien für native Clients wie Outlook und Teams wirksam – mit einem entscheidenden Detail: Legacy-Authentifizierung (IMAP, POP, ältere SMTP-Implementierungen) kann viele Grant-Steuerungen gar nicht erfüllen. Blockiere deshalb in einer separaten Richtlinie alle Client-Apps außer „Mobile apps and desktop clients“ und „Browser“, oder hebe die Legacy-Authentifizierung direkt tenantweit per Security Defaults oder eigener Block-Richtlinie auf. Sobald „Require Compliant Device“ greift und Legacy-Auth nicht explizit erlaubt ist, stirbt sie ohnehin ab – sauberer ist der aktive Block.

Schritt 5: Monitoring über die Sign-In-Logs

Nach dem Scharfschalten beobachtest Du unter Entra → Monitoring → Sign-in logs die Spalte Conditional Access. Dort siehst Du pro Anmeldung, welche Richtlinien ausgewertet wurden und mit welchem Ergebnis (Success, Failure, Report-only). Filtere auf „Failure“, um betroffene User und Geräte sofort zu identifizieren – das ist Dein Live-Dashboard für die Verschärfung.

Praxisbeispiel: Conditional-Access-Richtlinie per Microsoft Graph API

In größeren Umgebungen willst Du CA-Richtlinien nicht manuell bauen, sondern versioniert ausrollen. Der Graph API Endpoint /v1.0/identity/conditionalAccess/policies akzeptiert die Richtlinie als JSON. Ein vollständiges Beispiel:

{
  "displayName": "CA-020 Require Compliant Device - All Cloud Apps",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "applications": {
      "includeApplications": ["All"]
    },
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["<break-glass-group-object-id>"]
    },
    "platforms": {
      "includePlatforms": ["windows", "iOS", "android"],
      "excludePlatforms": []
    },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["compliantDevice"]
  },
  "sessionControls": null
}

Der Status enabledForReportingButNotEnforced entspricht dem Report-Only-Modus. Nach der Auswertungsphase änderst Du ihn auf enabled. Mit PowerShell und dem Microsoft Graph SDK legst Du diese Richtlinie direkt an:

# Voraussetzung: Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$policy = @{
  displayName = "CA-020 Require Compliant Device - All Cloud Apps"
  state       = "enabledForReportingButNotEnforced"
  conditions   = @{
    applications = @{ includeApplications = @("All") }
    users        = @{
      includeUsers = @("All")
      excludeGroups = @("<break-glass-group-object-id>")
    }
    platforms   = @{
      includePlatforms = @("windows", "iOS", "android")
    }
    clientAppTypes = @("browser", "mobileAppsAndDesktopClients")
  }
  grantControls = @{
    operator = "AND"
    builtInControls = @("compliantDevice")
  }
} | ConvertTo-Json -Depth 10

New-MgIdentityConditionalAccessPolicy -Body $policy

Der Wert compliantDevice ist der programmatische Name der Steuerung „Require device to be marked as compliant“ – diese IDs sind in der Graph-Dokumentation vollständig referenziert, was Dir eine saubere Infrastructure-as-Code-Strategie für Deinen gesamten CA-Bestand erlaubt.

Praxisbeispiel: Non-Compliant-Geräte automatisiert identifizieren

Für den Betrieb lohnt sich ein täglicher Report, welche Geräte den Status verfehlen und damit User blockieren. Graph liefert den Compliance-Status direkt am Managed Device:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All `
  -Filter "complianceState eq 'noncompliant'"

foreach ($d in $devices) {
  [PSCustomObject]@{
    DeviceName  = $d.DeviceName
    User        = $d.UserPrincipalName
    OS          = $d.OperatingSystem
    OSVersion   = $d.OsVersion
    LastSync    = $d.LastSyncDateTime
    State       = $d.ComplianceState
  }
} | Export-Csv -Path "C:\Reports\NonCompliant_Devices.csv" -NoTypeInformation -Encoding UTF8

Die Spalte LastSyncDateTime ist dabei Gold wert: Ein Gerät, das seit Tagen nicht mehr mit dem Intune-Service gesprochen hat, meldet oft einen veralteten Status – das ist dann kein Compliance-, sondern ein Kommunikationsproblem.

Best Practices

Immer Report-First: Keine Richtlinie geht ohne mindestens eine Woche Report-Only-Laufzeit live. Die Sign-In-Logs zeigen Dir exakt, wen Du blockieren würdest.
Break-Glass ist Pflicht: Ein Notfallkonto mit dokumentiertem Passwort, ausgeschlossen von jeder Richtlinie. Regelmäßig testen – ein ungetestetes Notfallkonto ist keins.
Filter statt Ausnahmen für Geräte: Nutze Gerätefilter (device.managementType -eq "mdm"), um nur verwaltete Geräte zu adressieren, statt Ausnahmegruppen zu pflegen, die niemand mehr verwaltet.
Require Compliant statt Domain-Joined-or-Compliant: Letzteres lässt unmanagede Domängeräte durch – ein Tunnel durch Deine gesamte Device-Strategy.
MFA ergänzen, nicht ersetzen: Compliant Device prüft das Gerät, nicht die Identität. Kombiniere beides mit UND-Logik für den Zugriff auf hochsensible Workloads wie Exchange, SharePoint oder Admin-Portale.
Betreiberreihenfolge beachten: Bei mehreren Grant-Steuerungen entscheidet der Operator: AND verlangt alles, OR genügt eines. Bei „All Cloud Apps“ mit OR aus Compliant Device und Approved Client App können MAM-Geräte überleben – bei AND kollidieren sie. Plane die Logik pro Zielgruppe, nicht global.
Grace-Period sauber kalkulieren: Setze in der Compliance-Richtlinie eine Toleranzperiode (z.B. 3–7 Tage) für nicht konforme Geräte. So bekommen User Zeit für Updates, bevor CA hart blockiert.
Beschreibe den Pfad, nicht nur die Sperre: Blockierte User brauchen eine Handlung: Company Portal öffnen, Sync triggern, Meldung lesen. Kommuniziere den Prozess, bevor die Richtlinie live geht – der Helpdesk-Call-Aufwand sinkt massiv.

Troubleshooting: Wenn „Device is not compliant“ auftaucht

Szenario 1: Intune sagt compliant, Entra blockiert trotzdem

Der Klassiker. Ursache ist fast immer ein Zeit- oder Objektproblem:

Veraltete Bewertung: Der User hat das Compliance-Problem gerade behoben, aber Intune hat noch nicht neu bewertet. Geräte prüfen ihren Status standardmäßig alle 8 Stunden – ein manueller Sync im Company Portal erzwingt die sofortige Neubewertung.
Token-Falle: Entra wertet CA nur bei Anmeldung bzw. Token-Erneuerung aus. Der User muss sich ab- und neu anmelden, nicht nur die App schließen.
Doppeltes Geräteobjekt: Es existieren zwei Einträge für dasselbe physische Gerät (einmal Entra Registered, einmal Entra Joined/MDM). Die CA-Auswertung trifft auf das falsche, nicht komforme Objekt. Prüfe mit dsregcmd /status auf dem Client, welcher Join-Typ und welche Device-ID vorliegen, und vergleiche mit dem Geräteobjekt in Entra.

# Auf dem Client ausführen – liefert Join-Typ und Device-ID
dsregcmd /status

Interessant sind die Felder AzureAdJoined, DomainJoined und DeviceId. Findet sich ein Entra-Registered-Eintrag mit anderer ID als dem MDM-Gerät, liegt der Konflikt offen – dann bereinigst Du das doppelte Objekt.

Szenario 2: BYOD-Gerät blockiert, obwohl MAM funktioniert

Das ist kein Fehler, sondern Design: Ein reines MAM-Gerät (nur App-Schutzrichtlinien, kein MDM-Enrollment) kann „Require Compliant Device“ nie erfüllen. Lösung: Erstelle eine separate Richtlinie für die BYOD-Zielgruppe, die stattdessen „Require app protection policy“ als Grant-Steuerung nutzt, und schließe diese Gruppe aus der Compliant-Device-Richtlinie aus. Damit bleiben private Geräte produktiv nutzbar, ohne Sicherheitsanforderungen aufzugeben.

Szenario 3: Browser-Anmeldung funktioniert, native App nicht

Outlook blockiert, der Browser geht durch? Prüfe die Client-App-Bedingung und die Geräteauthentifizierung: Native Clients müssen das Gerät über den Workplace Join bzw. PRT (Primary Refresh Token) nachweisen. Ein Client ohne PRT ist per Definition kein vollwertiges Gerät. dsregcmd /status zeigt unter „SSO State“, ob ein PRT existiert – fehlt er, hilft oft ein Rejoin (dsregcmd /leave gefolgt von einer erneuten Anmeldung) oder bei Autopilot-Geräten eine Neuausrichtung.

Szenario 4: Richtlinie greift für die falsche Zielgruppe

Mehrere CA-Richtlinien werden kumulativ ausgewertet: Jede Richtlinie, deren Bedingungen zutreffen, muss erfüllt werden – es gibt kein „die eine gewinnt“. Blockiert eine Kombination unerwartet, nutze das What If-Tool (Entra → Conditional Access → What If): User, App, Plattform und Standort eingeben, und Entra zeigt Dir alle ausgewerteten Richtlinien samt Ergebnis. Das ist die schnellste Methode, um Konflikte zwischen „All Cloud Apps“-Blockern und spezifischen Allow-Richtlinien zu finden.

Schnelldiagnose-Checkliste

Lizenzen prüfen: Conditional Access braucht Entra ID P1 (in Microsoft 365 Business Premium oder E3/E5 enthalten). Ohne P1 sind die Richtlinien einfach nicht sichtbar/auswertbar.
Compliance-Richtlinie überhaupt zugewiesen? Geräte ohne zugewiesene Richtlinie sind per Definition nicht compliant.
Sign-In-Log öffnen und konkret nach der Failed-Anmeldung filtern – dort steht, welche Richtlinie mit welchem Grund blockiert hat.
Gerätefilter-Logik prüfen: Ein zu enger Filter lässt die Richtlinie für das Gerät gar nicht erst zutreffen, während eine andere Richtlinie blockiert.
Last Sync Time im Intune-Geräteobjekt: > 24 Stunden deutet auf Zertifikat- oder Netzwerkprobleme des Intune-Management-Extensions-Agents.

Fazit

Conditional Access auf Basis von Compliance ist kein einzelnes Feature, sondern die Nahtstelle zwischen Geräteverwaltung und Identitätssicherheit. Compliance-Richtlinien definieren den Soll-Zustand Deiner Geräteflotte, Conditional Access übersetzt Abweichungen in harte Zugriffsentscheidungen. Die Disziplin liegt dabei weniger in der Technik als im Vorgehen: Report-Only vor Scharfschaltung, Break-Glass vor der ersten Richtlinie, Gerätefilter für saubere Zielgruppen und ein definierter BYOD-Pfad über App-Schutzrichtlinien.

Mit den PowerShell- und Graph-Beispielen aus dieser Sektion hast Du nicht nur die Klick-Anleitung, sondern auch die Bausteine für einen versionierten, automatisierten CA-Bestand. Wenn Du die Sign-In-Logs als Frühwarnsystem nutzt und die typischen Konfliktmuster – veraltete Bewertungen, doppelte Geräteobjekte, MAM-vs-MDM – kennst, wird aus „Device is not compliant“ kein Helpdesk-Desaster, sondern ein routinierter Prozess. In der nächsten Sektion bauen wir darauf auf und kombinieren Gerätestatus mit Risikosignalen und Standortbedingungen zu vollständigen Zero-Trust-Zugriffsarchitekturen.