Conditional Access in Microsoft Entra ID: Sichere Einführung ohne Benutzer auszusperren

Wie wird Conditional Access eingeführt, ohne Administratoren, Benutzer oder technische Konten versehentlich auszusperren? Neue Richtlinien sollten zuerst klar abgegrenzt, mit Emergency-Access-Konten abgesichert, im Report-only-Modus ausgewertet und auf Pilotgruppen getestet werden. Vor der Aktivierung müssen What-If-Ergebnisse und reale Anmeldeprotokolle zeigen, welche Richtlinien gemeinsam auf typische Anmeldungen wirken.

Conditional Access ist eine Policy Engine. Sie bewertet Signale wie Benutzer, Zielressource, Gerät, Standort, Risiko, Client oder Authentifizierungsstärke und erzwingt daraus Kontrollen. Mehrere zutreffende Richtlinien werden gemeinsam angewendet. Eine Anmeldung kann daher eine einzelne Richtlinie bestehen und trotzdem an einer zweiten scheitern.

Das Entscheidungsmodell verstehen

Eine Richtlinie besteht vereinfacht aus:

1. Assignments: Wer und welche Ressource sind betroffen?
2. Conditions: Unter welchen Umständen gilt die Richtlinie?
3. Access Controls: Wird blockiert oder welche Anforderungen müssen erfüllt werden?
4. Session Controls: Wie wird die Sitzung zusätzlich gesteuert?
5. State: Aus, Report-only oder aktiv.

Conditional Access erteilt keinen Zugriff auf eine Ressource. Die zugrunde liegende Berechtigung muss bereits bestehen. Die Richtlinie entscheidet, ob und unter welchen Bedingungen eine Anmeldung mit dieser Berechtigung zugelassen wird.

Die Auswertung erfolgt nach dem ersten Faktor der Anmeldung. Benutzername, Kennwort oder ein anderer primärer Nachweis werden also zunächst verarbeitet; erst danach kann Conditional Access zusätzliche Anforderungen wie MFA, Gerätekonformität oder eine Blockierung erzwingen.

Voraussetzungen

Für klassische Conditional-Access-Richtlinien wird in der Regel mindestens Microsoft Entra ID P1 benötigt. Risikobasierte Richtlinien mit Benutzer- oder Anmelderisiko bauen zusätzlich auf Identity-Protection-Funktionen und damit typischerweise auf P2- beziehungsweise entsprechenden Suite-Lizenzen auf.

• passende Microsoft-Entra-Lizenzierung für die verwendeten Funktionen,
• mindestens zwei getestete Emergency-Access-Konten nach Microsoft-Empfehlung,
• getrennte Administratorkonten,
• inventarisierte Benutzer- und Workload-Identitäten,
• Kenntnis verwendeter Clients, Plattformen und Authentifizierungsflüsse,
• Zugriff auf Anmeldeprotokolle,
• benannte Richtlinieneigentümer,
• Change- und Rollback-Prozess.

Lizenzanforderungen können sich nach Funktion unterscheiden. Die aktuelle Microsoft-Entra-Lizenzübersicht ist vor der Umsetzung verbindlich zu prüfen.

Zielbenutzer und Gruppen sauber wählen

Ein verbreitetes Zielbild ist „alle Benutzer“. Für die Einführung ist trotzdem ein Pilot notwendig. Typischer Ablauf:

1. Richtlinie für Pilotgruppe erstellen.
2. Emergency-Access-Konten ausschließen.
3. Service- und technische Identitäten separat bewerten.
4. Report-only-Ergebnisse prüfen.
5. Pilot aktivieren.
6. Scope schrittweise erweitern.

Ausschlüsse sind Sicherheitsentscheidungen

Breite Ausschlussgruppen wie „MFA-Ausnahmen“ wachsen leicht unkontrolliert. Jede Ausnahme benötigt:

• konkreten Grund,
• Eigentümer,
• Ablaufdatum,
• alternative Kontrolle,
• regelmäßigen Review.

Für Workload-Identitäten existieren eigene Konzepte. Benutzerbasierte Ausnahmen sollten nicht als dauerhafte Lösung für Anwendungen oder Automatisierungen dienen.

Zielressourcen festlegen

Richtlinien können bestimmte Cloud Apps, Aktionen oder alle Ressourcen adressieren. Eine Richtlinie für alle Ressourcen bietet breite Abdeckung, kann aber bei falscher Konfiguration erhebliche Auswirkungen haben. Ressourcen-Ausnahmen sollten gezielt und anhand aktueller Microsoft-Dokumentation geplant werden.

Prüfen Sie insbesondere:

• Microsoft Admin Portals,
• Microsoft Graph und APIs,
• Exchange, SharePoint und Teams,
• selbst entwickelte und fremde Enterprise Applications,
• Registrierungs- oder Sicherheitsinformationsaktionen,
• Legacy- und Geräteszenarien.

Bedingungen richtig interpretieren

Standorte

Named Locations können IP-Bereiche oder Länder-/Regionssignale abbilden. Ein „vertrauenswürdiger Standort“ ist keine Identitätsgarantie. VPN, mobile Netze, Cloudproxys und wechselnde IPs müssen berücksichtigt werden.

Geräteplattform und Gerätezustand

Eine Anforderung wie „compliant device“ setzt funktionierende Geräteverwaltung, Registrierung und Richtlinienauswertung voraus. Vor Aktivierung muss geprüft werden, welche Geräte nicht verwaltet werden können und welche Geschäftsprozesse betroffen sind.

Client Apps und Authentifizierungsflows

Browser, mobile/desktop Clients und ältere Authentifizierungswege können unterschiedlich behandelt werden. Gerätecodefluss, Legacy Authentication und spezielle Teams-Geräte benötigen eine separate Betrachtung.

Risiko

Benutzer- oder Anmelderisiko kann zusätzliche Lizenz- und Identity-Protection-Funktionen voraussetzen. Risk Policies benötigen klare Remediation- und Helpdesk-Prozesse.

Grant Controls und kombinierte Wirkung

Mögliche Anforderungen sind beispielsweise:

• MFA,
• bestimmte Authentication Strength,
• konformes Gerät,
• Microsoft-Entra-hybrid-joined Device,
• genehmigte Client-App oder App-Schutzrichtlinie,
• Nutzungsbedingungen.

Innerhalb einer Richtlinie kann je nach Konfiguration eine oder alle ausgewählten Anforderungen gelten. Über mehrere Richtlinien hinweg müssen alle anwendbaren Anforderungen erfüllt werden. Das ist eine häufige Ursache unerwarteter Blockierungen.

Report-only richtig einsetzen

Report-only ist für Pilotierungen sehr hilfreich, bildet aber nicht jede praktische Nebenwirkung ab. Microsoft weist beispielsweise darauf hin, dass bestimmte Gerätekonformitätsprüfungen auf macOS, iOS oder Android trotz Report-only noch Zertifikatsabfragen auslösen können, weil der Client dafür lokale Informationen einsammeln muss.

Report-only wertet die meisten Richtlinien aus, ohne sie als Blockierung oder Grant-Anforderung durchzusetzen. Die Ergebnisse erscheinen in Anmeldeprotokollen und geeigneten Auswertungen.

Report-only ist aber kein vollständiger Ersatz für einen Pilot:

• Benutzerverhalten unter echter MFA-Anforderung wird nicht vollständig simuliert,
• einige Sessioneffekte zeigen sich erst aktiv,
• nicht jeder seltene Client oder Prozess tritt im Beobachtungszeitraum auf,
• fehlende oder ungenaue Signale können die Auswertung beeinflussen.

Beobachtungszeitraum

Der Zeitraum sollte typische Arbeitsmuster enthalten: Büro, Homeoffice, mobile Nutzung, Monats- oder Quartalsprozesse, externe Zugriffe und Wartungsaufgaben. Ein einzelner Arbeitstag reicht selten.

What-If-Tool und Anmeldeprotokolle

What If

Das What-If-Tool beantwortet vor allem die Policy-Frage für eine angenommene Zielressource. Es bildet nicht jede Dienstabhängigkeit eines Workloads vollständig ab. Ein scheinbar sauberes Teams-Szenario kann in der Praxis trotzdem an Exchange-Online- oder SharePoint-Abhängigkeiten scheitern und muss deshalb mit echten Anmeldungen gegengeprüft werden.

Mit dem What-If-Tool lässt sich prüfen, welche Richtlinien für eine simulierte Anmeldung gelten würden. Eingaben können Benutzer, Zielressource, Plattform, Standort und weitere Signale umfassen.

Es beantwortet vor allem: „Welche Richtlinien wären unter diesen Annahmen anwendbar?“ Es ersetzt nicht die Prüfung einer echten Anmeldung mit tatsächlichem Token, Gerätestatus und Clientverhalten.

Anmeldeprotokolle

Bei realen Anmeldungen sollten folgende Bereiche geprüft werden:

• Conditional-Access-Ergebnis,
• angewendete und nicht angewendete Richtlinien,
• Fehlercode und Failure Reason,
• Authentication Details,
• Client App,
• Gerätedetails,
• Standort- und Risikosignale,
• Ressource und Service Principal.

Protokolldaten können sich nach Verarbeitung noch ergänzen. Entscheidungen sollten nicht auf einem einzelnen unvollständigen Feld basieren.

Einführungsreihenfolge

Eine mögliche, risikoarme Reihenfolge:

1. Emergency Access erstellen und testen.
2. Legacy-Authentifizierung inventarisieren und kontrolliert behandeln.
3. MFA für privilegierte Administratoren pilotieren.
4. MFA für Benutzergruppen erweitern.
5. Registrierungsprozess und SSPR absichern.
6. Gerätezustand für geeignete Gruppen einführen.
7. externe Benutzer separat behandeln.
8. risikobasierte Richtlinien und Authentication Strengths ergänzen.
9. Ausnahmen und alte Richtlinien konsolidieren.

Das Zielbild muss zur Organisation passen. Die Reihenfolge ist kein universelles Microsoft-Rezept, sondern ein risikobasierter Ansatz.

Typische Fehlerbilder

Administrator nach Richtlinienaktivierung ausgesperrt

Sofortmaßnahmen:

• Emergency-Access-Konto verwenden,
• betroffene Richtlinie deaktivieren oder auf Report-only setzen,
• Audit- und Anmeldeprotokolle sichern,
• Scope oder Grant Control korrigieren,
• Pilot erneut durchführen.

Kein Notfallkonto verfügbar zu haben, ist ein eigenständiger kritischer Befund.

MFA-Schleife

Mögliche Ursachen:

• Session Controls oder Sign-in Frequency,
• widersprüchliche Richtlinien,
• fehlerhafte Registrierung,
• Client speichert oder erneuert Token nicht korrekt,
• Registrierung selbst wird durch CA blockiert.

Test: Browser-InPrivate, anderer Client, Authentication Details, Security-Info-Registrierung und anwendbare Richtlinien prüfen.

Konformes Gerät wird als nicht konform erkannt

Prüfen Sie:

• Geräteobjekt und Join-Typ,
• MDM-Registrierung,
• letzte Compliance-Auswertung,
• verwendeten Browser/Client,
• Benutzer- und Gerätezuordnung,
• Tokenalter.

Rückfall ist eine begrenzte Pilot- oder Geräteausnahme mit Ablaufdatum, nicht die dauerhafte Deaktivierung der Compliance-Anforderung.

Servicekonto wird blockiert

Interaktive Benutzerkonten sind oft ungeeignet für Automatisierung. Prüfen Sie, ob Managed Identity, Service Principal, Zertifikat oder Workload Identity Federation genutzt werden kann. Bis zur Migration kann eine eng begrenzte Ausnahme erforderlich sein, die überwacht und terminiert wird.

Externe Benutzer erfüllen Geräteanforderung nicht

Bei B2B-Szenarien können Cross-Tenant Access Settings das Vertrauen in MFA- oder Device Claims anderer Entra-Organisationen steuern. Diese Vertrauensentscheidung muss organisationsspezifisch bewertet werden. Alternativ sind andere Grant Controls oder getrennte Gastzugriffsmodelle nötig.

Rückfallplan je Richtlinie

Jede Richtlinie sollte folgende Angaben besitzen:

• Richtlinien-ID und Name,
• Eigentümer,
• alter und neuer Status,
• Zielgruppen und Ausnahmen,
• erwartete Wirkung,
• Abnahmetests,
• Schwellenwert für Rollback,
• autorisiertes Rückfallkonto,
• Kommunikationsweg.

Ein Rollback kann bedeuten:

• von On auf Report-only,
• Pilotgruppe verkleinern,
• fehlerhafte Bedingung entfernen,
• temporäre, eng begrenzte Ausnahme,
• Session widerrufen und erneuten Test durchführen.

Betrieb und Wartbarkeit

Richtlinien benötigen Namenskonventionen und Dokumentation. Ein Beispiel:

CA-<Scope>-<Resource>-<Control>-<State>

Zusätzlich sollten Zweck, Owner, Change-ID und Ausnahmeprozess dokumentiert werden. Vermeiden Sie viele sich überlappende Richtlinien ohne klares Design. Microsoft nennt eine Plattformgrenze für die Anzahl der Conditional-Access-Richtlinien; unabhängig davon wird ein unübersichtlicher Bestand schon weit früher betrieblich riskant.

Regelmäßige Reviews umfassen:

• ausgeschlossene Benutzer und Gruppen,
• ungenutzte oder deaktivierte Richtlinien,
• Report-only-Richtlinien ohne Abschlussentscheidung,
• Richtlinien mit sehr wenigen oder unerwartet vielen Treffern,
• neue Apps, Plattformen und Authentifizierungswege,
• Funktionstest der Notfallkonten.

Abnahmetests

1. Standardbenutzer im Firmengerät.
2. Standardbenutzer auf nicht verwaltetem Gerät.
3. Administrator mit separatem Admin-Konto.
4. Emergency-Access-Konto.
5. Gastbenutzer aus einer Partnerorganisation.
6. mobiler Client und Browser.
7. deaktivierte oder alte Authentifizierungsmethode.
8. Nutzer bei Passwort- oder Sicherheitsinforegistrierung.
9. ausgewählte Service- oder Gerätekonten.
10. Zugriff auf kritische Enterprise Application.

Jeder Test dokumentiert erwartete und tatsächliche Richtlinienwirkung.

Direkt angrenzend sind die Beiträge MFA, Passkeys und SSPR in Microsoft Entra verwalten für die Anmeldemethoden und Notfallzugang für Microsoft 365 für den getesteten Rückfallweg.

So wird Conditional Access schrittweise statt als riskanter Big Bang eingeführt

Conditional Access wird nicht durch möglichst viele Richtlinien sicher, sondern durch verständliche Ziele, kontrollierte Scopes und überprüfte Wirkung. Emergency Access, Report-only, What If, reale Pilotanmeldungen und ein konkreter Rollback verhindern, dass Schutzmaßnahmen selbst zum Ausfall führen. Nach der Einführung bleiben Ausnahmen, neue Anwendungen und veränderte Geräte- oder Authentifizierungsszenarien Bestandteil des laufenden Betriebs.