Willkommen zum letzten Teil der Serie. Mit dem Basis-Set aus Teil 4 habt ihr die wichtigsten Lücken geschlossen. Jetzt geht es um drei Dinge, die aus einem guten Setup ein sehr gutes machen: Richtlinien, die auf Risiko reagieren, Schutz für besonders sensible Bereiche und Sitzungen – und am Ende um das, was im Alltag am häufigsten passiert: die Fehlersuche.
Serie: Conditional Access verstehen
- Teil 1: Was ist Conditional Access?
- Teil 2: Anatomie einer Richtlinie
- Teil 3: Sicher einführen
- Teil 4: Das Basis-Set
- Teil 5: Fortgeschritten & Betrieb – ihr seid hier
Risiko-Richtlinien mit Entra ID Protection
Entra ID Protection bewertet jede Anmeldung und jedes Konto mit Hilfe von Microsofts Bedrohungsdaten. Dabei gibt es zwei Arten von Risiko:
| Risikoart | Worum geht es? | Beispiele | Empfohlene Antwort |
|---|---|---|---|
| Anmelderisiko | diese eine Anmeldung ist wahrscheinlich nicht vom Kontoinhaber | anonyme IP-Adresse, ungewöhnlicher Ort, bekannte Angreifer-Infrastruktur | MFA verlangen, Anmeldehäufigkeit „jedes Mal“ |
| Benutzerrisiko | das Konto ist wahrscheinlich kompromittiert | geleakte Zugangsdaten, von Microsoft gemeldete Kompromittierung | Risikobehebung verlangen |
Der große Vorteil: Erfüllt der Benutzer die Anforderung, ist das Risiko automatisch behoben. Niemand im IT-Team muss jeden Alarm von Hand abarbeiten. Das funktioniert allerdings nur, wenn alle Benutzer vorher MFA registriert haben – sonst wird aus der Risiko-Richtlinie eine Aussperrung.
CA005 – MFA bei hohem Anmelderisiko
| Einstellung | Wert |
|---|---|
| Benutzer | Alle Benutzer, ausgenommen Notfallkonten |
| Zielressourcen | Alle Ressourcen |
| Bedingungen | Anmelderisiko: Hoch |
| Gewähren | Authentifizierungsstärke: Multifaktor-Authentifizierung |
| Sitzung | Anmeldehäufigkeit: Jedes Mal |
CA006 – Risikobehebung bei hohem Benutzerrisiko
| Einstellung | Wert |
|---|---|
| Benutzer | Alle Benutzer, ausgenommen Notfallkonten |
| Zielressourcen | Alle Ressourcen |
| Bedingungen | Benutzerrisiko: Hoch |
| Gewähren | Risikobehebung verlangen – Authentifizierungsstärke und „Anmeldehäufigkeit: Jedes Mal“ werden automatisch gesetzt |
Das neuere Steuerelement „Risikobehebung verlangen“ ersetzt in vielen Fällen die alte „Kennwortänderung verlangen“. Es passt sich der Anmeldemethode an: Wer mit Kennwort arbeitet, muss es sicher ändern; wer kennwortlos arbeitet, wird abgemeldet und muss sich neu anmelden. Es funktioniert allerdings nicht für Gäste und externe Benutzer.
Alte Risikorichtlinien sind Geschichte
Die früheren Risikorichtlinien direkt in ID Protection hat Microsoft zum 1. Oktober 2026 abgekündigt. Falls ihr dort noch etwas aktiv habt: Legt gleichwertige Conditional-Access-Richtlinien im Berichtsmodus an, prüft sie und schaltet dann die alten Richtlinien ab.
Security-Tipp
Startet bei beiden Richtlinien mit der Stufe Hoch. Erst wenn das ein paar Wochen sauber läuft, erweitert ihr das Anmelderisiko auf Mittel. Und klickt in der Liste der riskanten Benutzer nicht reflexartig „Risiko schließen“ – damit bringt ihr dem System bei, dass das harmlos war.
Authentifizierungskontext: Schutz für einzelne Bereiche
Manchmal reicht der Schutz auf App-Ebene nicht. Die Speisekarte der Kantine in SharePoint ist etwas anderes als die Site mit den Gehaltsdaten. Für solche Fälle gibt es den Authentifizierungskontext: Ihr legt unter Conditional Access → Authentifizierungskontext ein Etikett an – zum Beispiel „c1 – Vertrauliche Daten“ – und verknüpft es mit einer Richtlinie, die etwa phishing-resistente MFA und ein konformes Gerät verlangt.
Das Etikett hängt ihr dann dort an, wo der Schutz greifen soll:
- an SharePoint-Sites über Vertraulichkeitsbezeichnungen oder direkt an der Site
- an die Aktivierung von Admin-Rollen in Privileged Identity Management
- an geschützte Aktionen in Entra ID, etwa das Ändern von Conditional-Access-Richtlinien
- an eigene Apps, die den Kontext unterstützen
Der Benutzer wird erst dann zur stärkeren Anmeldung aufgefordert, wenn er den geschützten Bereich wirklich betritt – nicht schon beim Öffnen von SharePoint. Ihr könnt bis zu 99 Kontexte anlegen; in der Praxis kommt man mit zwei oder drei aus.
Sitzungen: Schutz gegen Tokendiebstahl
Phishing-resistente MFA schützt die Anmeldung. Was aber, wenn Malware auf einem Gerät das Token stiehlt, das nach der Anmeldung ausgestellt wird? Dagegen gibt es mehrere Bausteine:
Anmeldehäufigkeit und beständige Browsersitzung
Mit der Anmeldehäufigkeit legt ihr fest, wie oft sich jemand neu anmelden muss – sinnvoll für sensible Apps oder nicht verwaltete Geräte. Die beständige Browsersitzung steuert, ob „Angemeldet bleiben“ möglich ist. Microsoft hat dafür eine Vorlage, die auf nicht verwalteten Geräten stündlich eine neue Anmeldung verlangt und Browsersitzungen nie dauerhaft speichert. Übertreibt es aber nicht: Zu viele Abfragen trainieren Benutzer darauf, jede Abfrage ungeprüft zu bestätigen.
Fortlaufende Zugriffsevaluierung (CAE)
Normalerweise gilt ein Zugriffstoken eine Stunde lang – auch wenn das Konto inzwischen gesperrt wurde. Mit der fortlaufenden Zugriffsevaluierung (Continuous Access Evaluation) reagieren Exchange Online, SharePoint und Teams fast in Echtzeit auf kritische Ereignisse: Konto deaktiviert, Kennwort geändert, Sitzungen widerrufen, hohes Benutzerrisiko. Laut Microsoft kann das bis zu 15 Minuten dauern, Änderungen des Netzwerkstandorts werden dagegen sofort durchgesetzt. CAE ist standardmäßig aktiv, ihr müsst nichts einschalten. Wer seine ausgehenden IP-Adressen genau kennt, kann mit „Standortrichtlinien strikt durchsetzen“ noch einen Schritt weiter gehen.
Tokenschutz
Der Tokenschutz sorgt dafür, dass Entra ID nur Anmeldetoken akzeptiert, die kryptografisch an das Gerät gebunden sind. Ein gestohlenes Token funktioniert dann auf einem anderen Gerät nicht. Stand heute gilt das für native Apps wie Outlook, Teams, OneDrive und die Office-Apps beim Zugriff auf Exchange Online, SharePoint und Teams – auf Windows allgemein verfügbar, auf iOS und macOS mit MDM und dem Enterprise-SSO-Plug-in. Für Browser gibt es eine Vorschau, die auf das Azure-Portal und die Admin Center beschränkt ist.
Hinweis zum Tokenschutz
Tokenschutz setzt registrierte Geräte voraus und blockiert Apps, die ihn nicht unterstützen – etwa die Mail- und Kalender-App von Apple oder ältere Office-Versionen. Führt ihn deshalb mit einer Pilotgruppe und lange im Berichtsmodus ein.
Fehlersuche: „Ich komme nicht mehr rein“
Früher oder später meldet sich jemand, der blockiert wird. So geht ihr systematisch vor:
- Details sichern. Auf der Fehlerseite gibt es den Link „Weitere Details“. Lasst euch Benutzer, Uhrzeit, App und vor allem die Korrelations-ID schicken.
- Anmeldeprotokoll öffnen. Unter Entra ID → Überwachung und Integrität → Anmeldeprotokolle filtert ihr nach Benutzer, Zeitraum oder direkt nach der Korrelations-ID. Schon die Rolle Berichtsleser reicht dafür.
- Reiter „Conditional Access“ prüfen. Hier steht, welche Richtlinien angewendet wurden, welche nicht – und mit einem Klick auf die drei Punkte auch, welche Bedingung zugetroffen hat. Der Reiter „Nur Bericht“ zeigt eure Testrichtlinien. Unter Zielgruppe (Audience) seht ihr, welche Ressourcen im Hintergrund mit angefragt wurden.
- Mit What If nachstellen. Spielt die Anmeldung mit genau diesen Werten im What-If-Tool durch, um zu sehen, welche Änderung die Lösung wäre.
- Gezielt anpassen. Lieber eine eng gefasste Ausnahme oder eine zusätzliche Richtlinie als eine pauschale Lockerung. Und alles im Richtlinienregister festhalten.
Die häufigsten Fehlercodes, die euch dabei begegnen:
| Code | Bedeutung |
|---|---|
| AADSTS53000 | Gerät ist nicht konform |
| AADSTS53001 | Gerät ist nicht in die Domäne eingebunden |
| AADSTS53002 | App ist keine genehmigte Client-App |
| AADSTS53003 | durch Conditional Access blockiert |
| AADSTS53004 | MFA-Registrierung wegen Risiko blockiert |
| AADSTS53009 | App muss Intune-App-Schutz erzwingen |
Security-Tipp
Wenn Benutzer „nur Teams“ öffnen und trotzdem blockiert werden, liegt es oft an Dienstabhängigkeiten: Teams ruft im Hintergrund auch Exchange und SharePoint auf. Eine Richtlinie auf SharePoint trifft dann auch Teams. Die Zielgruppe im Anmeldeprotokoll zeigt euch, welche Ressourcen beteiligt waren.
Was jetzt noch kommt
Conditional Access entwickelt sich ständig weiter. Ein paar Themen, die ihr im Blick behalten solltet:
- KI-Agenten haben eigene Identitäten in Microsoft Entra Agent ID und lassen sich mit eigenen Richtlinien steuern – Microsoft legt bereits eine verwaltete Richtlinie an, die Agenten mit hohem Risiko blockiert.
- Workload-Identitäten wie Dienstprinzipale lassen sich mit einer Workload-ID-Lizenz ebenfalls per Conditional Access einschränken, etwa auf bestimmte IP-Adressen.
- Global Secure Access bringt Conditional Access auf den Netzwerkverkehr, inklusive „konformes Netzwerk“ als Bedingung.
- Der Conditional Access Optimization Agent prüft euren Tenant täglich auf Lücken und schlägt passende Richtlinien vor.
Die Serie im Rückblick
In fünf Teilen haben wir uns von „Was ist das überhaupt?“ bis zur Fehlersuche vorgearbeitet. Wenn ihr nur drei Dinge mitnehmt, dann diese: Notfallkonten zuerst, jede Richtlinie zuerst im Berichtsmodus und eine MFA-Richtlinie auf alle Benutzer und alle Ressourcen. Der Rest kommt Schritt für Schritt.
Offizielle Microsoft-Quellen
- Risikobasierte Zugriffsrichtlinien
- Risikorichtlinien konfigurieren und migrieren
- Risikobehebung für Benutzer mit Risiko verlangen
- MFA bei erhöhtem Anmelderisiko
- Authentifizierungskontext
- Sitzungsverwaltung und Anmeldehäufigkeit
- Fortlaufende Zugriffsevaluierung
- Tokenschutz
- Anmeldeprobleme mit Conditional Access beheben
- Conditional Access für Agent-Identitäten
- Conditional Access für Workload-Identitäten
Serie: Conditional Access verstehen
- Teil 1: Was ist Conditional Access?
- Teil 2: Anatomie einer Richtlinie
- Teil 3: Sicher einführen
- Teil 4: Das Basis-Set
- Teil 5: Fortgeschritten & Betrieb – ihr seid hier
