Wer Conditional Access (CA) in Microsoft Entra ID konfiguriert, tappt schnell in die Falle, für jedes denkbare Szenario eine eigene Policy erstellen zu wollen. Das Ergebnis sind 30, 50, manchmal über 100 Richtlinien, die sich gegenseitig blockieren, Lücken produzieren und die niemand mehr durchschaut. Dabei braucht es für die meisten Umgebungen nur wenige. Mein in diesem Beitrag vorgestellter Vorschlag basiert auf exakt vier Richtlinien.
Die Magie der Reduktion besteht darin, nur die „richtigen“ Signale auszuwerten. Dabei ist es an erster Stelle wichtig zu verstehen, dass Conditional Access Richtlinien nicht sequenziell auswertet. In Wahrheit laufen sämtliche Richtlinien, deren Bedingungen zutreffen, gleichzeitig.
Von der Logik her müssen Sie sich nur zwei Dinge merken: Das schlechteste Ergebnis gewinnt und eine Block-Policy schlägt jede Grant-Policy.
Wie CA Entscheidungen trifft
Das klingt zwar simpel, ist es aber in der Praxis nicht, wenn man nicht weiß, was „gleichzeitig“ hier konkret bedeutet. Ein Nutzer, der von einer bestimmten IP-Range kommt, die sowohl in einer Blockierungs-Policy als auch in einer MFA-Grant-Policy erfasst ist, wird geblockt. Egal wie viele Allows sonst greifen.
In Summe verarbeitet CA vier Signalkategorien:
- Identität – Benutzer, Gruppe, Verzeichnisrolle
- Standort – IP-Range (Named Location), Land/Region (GeoIP-basiert)
- Gerät – Plattform, Compliance-Status (Intune), Hybrid Azure AD Joined
- Session-Risiko – Sign-in Risk, User Risk (Entra ID Protection)
Eine belastbare Architektur sollte alle vier Signalkategorien abdecken und zwar mit so wenig Richtlinien wie möglich. Die folgende Minimalstruktur hat sich in der Praxis bewährt:
Richtlinie 1: MFA für alle, außer Firmennetz + konformes Gerät
Hiermit erzwingen Sie MFA für jeden Anmeldeversuch, aber mit einer Ausnahme: Die Anmeldung kommt aus einem vertrauenswürdigen IP Adressbereich (Named Location= Firmennetz) UND es handelt sich um ein Intune-konformes Gerät. Nur wer beides erfüllt, kommt ohne zweiten Faktor durch. Das ist kein Komfort-Feature, sondern eine bewusste Entscheidung: Wer im Büro mit einem „verwalteten Gerät“ arbeitet, soll sich nicht am MFA-Prompt aufhalten müssen. Alle anderen schon.
Richtlinie 2: Länder-Block
Mein zweiter Vorschlag blockiert unerwünschte Länder. Das bilden Sie mit einer „Countries“-basierten „Named Location“ mit allen Regionen ab, aus denen keine legitimen Zugriffe zu erwarten sind. Diese können dann geblockt werden. Diese Richtlinie greift bewusst ohne Ausnahmen für MFA oder Gerätestatus. Sie wirkt, „bevor“ irgendetwas anderes ausgewertet wird. Allerdings müssen auch hier Break-Glass-Konten explizit ausgenommen sein (dazu später mehr).
Richtlinie 3: Geräte-Compliance für sensible Apps
Für Anwendungen mit erhöhtem Schutzbedarf wie z. B. Exchange Online, SharePoint, Microsoft Teams usw. wird zusätzlich zum zweiten Faktor auch der Gerätestatus geprüft. Zugang erhalten dann ausschließlich Geräte, die entweder als „konform“ (Intune) oder als „Hybrid Azure AD Joined“ markiert sind, also Unternehmensgeräte sind. Nicht verwaltete Geräte dagegen landen in einer Browser-only-Session ohne Download-Möglichkeit, geregelt mit Hilfe von „Session Controls“.
Richtlinie 4:Automatische Risiko-Reaktion
In der letzten Richtlinie berechnet Entra ID Protection für jede Anmeldung ein Risikoniveau (niedrig, mittel, hoch). Bei mittlerem Risiko wird MFA erzwungen, bei hohem Risiko wird die Anmeldung blockiert und eine Kennwortänderung angefordert. Diese Richtlinie wirkt unabhängig von Standort und Gerät. Sie fängt kompromittierte Zugangsdaten ab, auch wenn der Angreifer die korrekte IP-Adresse des Opfers kennt.
| Policy | Bedingung | Aktion | Lizenz |
| 1. MFA für alle | Jede Anmeldung außer Named Location + Compliant Device | MFA erzwingen | Entra ID P1 |
| 2. Länder-Block | Countries Named Location (Hochrisikoregionen) | Blockieren | Entra ID P1 |
| 3. Geräte-Compliance | Sensible Apps, nicht konformes Gerät | Block / Browser-only via Session Control | Entra ID P1 + Intune |
| 4. Anmelderisiko | Sign-in Risk mittel hoch |
MFA erzwingen Blockieren | Entra ID P2 |
Mit diesen vier Richtlinien verfügen Sie über ein solides Fundament. Mehr Policies bedeuten nicht automatisch mehr Sicherheit; oft bewirken mehr Richtlinien sogar das Gegenteil.
Für ein solides Verständnis der vier hiervorgestellten Regeln und ihrer Wirkungsweise ist es erforderlich, sich im Detail mit der Funktionsweise der verwendeten Signale vertraut zu machen.
Named Locations sauber pflegen
Named Locations sind der Ausgangspunkt für alle standortbasierten Entscheidungen. Entra ID CA stellt dazu zwei Typen stehen zur Verfügung:
- IP-Ranges: Diese werden in CIDR-Notation angegeben. Erlaubt sind maximal 2000 Bereiche pro Tenant
- Countries Locations: Sind GeoIP-basiert (ohne eigene IP-Pflege)
Beide müssen als separate Objekte gepflegt und in den Policies explizit referenziert werden. Ohne Referenz entfalten sie keine Wirkung.
Nutzer verwirrt dabei gelegentlich der Haken „Als vertrauenswürdigen Standort markieren“. Das Attribut hat jedoch für „moderne“ CA-Policies praktisch keine Auswirkung, denn es stammt aus einer älteren Auswertungslogik für Legacy-Szenarien. Für aktuelle Policies setzten Sie „Named Location“ immer explizit als Bedingung ein. Vertrauen Sie nicht auf das Attribut „vertrauenswürdig“. Es kann zu „stillen“ Fehlkonfigurationen führen.
VPN-Umgebungen hingegen sind ein eigenes Thema. Betreiben Sie Cloud-VPN mit wechselnden Exit-IPs, kann Homeoffice-Traffic nicht als Named Location erfasst werden. Dabei handelt es sich allerdings im ein eher strukturelles Problem, das mit CA allein nicht lösbar ist.
Geräte-Compliance aus Intune
Die Compliance-Richtlinien von Microsoft Intune definieren, wann ein Gerät als „konform“ gilt. Intune reicht diese Information dann an Entra ID CA weiter. Das umfasst beispielsweise den aktuellen Patch-Stand, ob BitLocker-Verschlüsselung aktiv ist, eine Mindestlänge für PINs, um nur einige Beispiele zu nennen. Conditional Access in Entra ID fragt diesen Status in Echtzeit ab. Das klappt jedoch nur dann, wenn das Gerät in Entra ID registriert oder eingebunden ist.
Damit schließt der Compliance-Status von Intune eine der häufigsten Schwachstellen in hybriden Umgebungen, denn Domain-joined Geräte ohne Intune-Enrollment haben einen solchen Status per se nicht. CA sieht sie dann entweder als „unbekannt“ oder wertet nur das Attribut „Hybrid Azure AD Joined“ aus. Das sagt aber nichts über den tatsächlichen Sicherheitszustand des Geräts aus.
Möchte Sie echte gerätebasierte Zugangskontrolle vollumfänglich umsetzen, kommen Sie eine vollständige Intune-Enrollment-Strategie nicht herum.
Tipp: Sie können jederzeit im „What-If“-Tool unter „Bedingter Zugriff → Richtlinien → Was-wäre-wenn“ den aktuellen Compliance-Status von Geräten und welche CA-Policy für welche Kombination aus Nutzer, App und Gerät greift, prüfen. Damit ist das What-If-Tool ein sehr nützliches Debugging-Werkzeug vor der Aktivierung neuer Regeln.
Session Controls für nicht verwaltete Geräte
Nicht jedes BYOD-Szenario lässt sich mit einem einfachen Block lösen. Die CA-Einstellungen im Abschnitt „Session Controls“ ermöglichen Ihnen im Zusammenarbeit mit „Microsoft Defender for Cloud Apps“ das Konfigurieren differenzierter Einschränkungen für nicht verwaltete Geräte, die quasi über den reinen Zeitpunkt der Login-Entscheidung hinaus live in die jeweiligen Session hinein wirken, wie z. B. „kein Download aus SharePoint oder OneDrive“, „kein Drucken“ oder „kein Kopieren sensibler Inhalte“. Der Nutzer sieht dann die Datei beispielsweise im Browser, ein lokales Speichern funktioniert dann aber trotzdem nicht.
Dafür muss in der CA-Policy unter Sitzung die Option App-Steuerung für bedingten Zugriff verwenden aktiviert sein, …
Bild: app-steuerung-fuer-CA.png
BU: Mit der „App-Steuerung für bedingten Zugriff“ wird die CA-Engine zum Session-Proxy für Defender for Cloud Apps
… und die entsprechenden Apps müssen in Defender for Cloud Apps mit einer Session Policy versehen werden.
Risk-Signale aus Entra ID Protection
Die Funktion „Entra ID Protection“ analysiert Anmeldesignale aus dem gesamten Microsoft-Ökosystem und erkennt Anomalien wie unmöglicher Travel (ein Nutzer meldet sich binnen Minuten aus München und Singapur an), anonyme IP-Adressen, bekannte Schad-IP-Ranges und kompromittierte Zugangsdaten aus Dark-Web-Leaks. Das Ergebnis dieser Analyse ist je ein Score für ein „Sign-in Risk“ oder ein „User Risk“. User Risk (Benutzerrisiko) und Sign-in Risk (Anmelderisiko) werden zwar vom gleichen Lernsystem berechnet, doch sie beantworten unterschiedliche Fragen.
Das User Risk fragt, wie wahrscheinlich es ist, dass diese Identität als Ganzes kompromittiert wurde, bewertet also den Benutzer über die Zeit. Das Sign-in Risk fragt, wie wahrscheinlich es ist, dass „diese“ eine konkrete Anmeldesitzung nicht vom rechtmäßigen Besitzer stammt, bewertet also eine einzelne Sitzung anhand ihres Kontextes. Beide unterscheiden sich auch im Bewertungszeitpunkt. Das User Risk wird in der Regel offline berechnet, während das Sign in Risk häufig „online“, d. h. nahezu in Echtzeit. berechnet wird.
Die korrekte Reaktion folgt direkt aus dieser Unterscheidung. Das Paradebeispiel für User Risk sind „Leaked Credentials“. Tauchen beispielsweise die bei einer Anmeldung verwendeten Login-Credentials in einem Datenleck oder im Dark Web auf, steigt das Benutzerrisiko, weil die Zugangsdaten als solche kompromittiert sind. Auf eine kompromittierte Identität antwortet man je nach Risk-Score mit seinem sicherem Passwortwechsel oder einem Block, etwa bei einem hohem Risiko, denn nur der sichere Passwortwechsel entzieht dem Angreifer die geleakten Zugangsdaten.
Bei einem Anmelderisiko Score von „Medium oder hoch“ verwendet man in der Regel die MFA-Erzwingung. Diese würde beim skizzierten User Risk nicht ausreichen, weil das kompromittierte Geheimnis – also das Passwort – weiter gültig bliebe. Daher der erzwungene Passwortwechsel oder Block beim User-Risk. Das Anmelderisiko entsteht aus dem Kontext einer Sitzung und wird bereits durch die MFA-Erzwingung wirkungsvoll entschärft, denn der zweite Faktor weist in diesem Fall nach, dass trotz des verdächtigen Kontexts der rechtmäßige Nutzer am Werk ist.
Ein typischer Fehler In diesem Zusammenhang besteht oft darin, beide Detection-Arten zu vermengen: Leaked Credentials sind immer ein User Risk, unmöglicher Ortswechsel ist immer ein Sign-in Risk. Die Reaktion muss sich also entsprechend unterscheiden.
Identitätsschutz klassisch versus CA-getrieben
Der skizzierte „klassische“ Identitätsschutz gilt schon seit 2025 als Legacy und wird von Microsoft nicht mehr empfohlen. Etwaige vorhandene „klassische“ IDP-Richtlinien werden von Microsoft derzeit automatisch auf „Read Only“ gesetzt. Stattdessen empfiehlt Microsoft, den Identitätsschutz indirekt mit Hilfe einer Conditional Access-Richtlinie zu triggern, wie in unserem Szenario skizziert. Hier stehen ihnen dann nicht nur 3 „starre“ Richtlinientypen (Benutzerrisiko, Anmelderisiko, MFA-Registrierung) für die festgelegten 3 Risiko-Klassen „Hoch“, „Mittel und höher“, „Niedrig und Höher“ zur Verfügung, sondern Sie können für jedes vorstellbare Anmelde-Szenario IP-Richtlinien mit beliebigen anderen CA-Signalen, wie Benutzergruppen, Zielanwendungen, Geräten usw. kombinieren. Allerdings erfordert Conditional Access an sich Entra-Premium P1 und nicht alle Risiko-Signale sind „free“; die meisten erfordern sogar P2 .
Break-Glass-Konten
Jede CA-Umgebung ohne Break-Glass-Konten provoziert den nächsten Konfigurationsfehler. Microsoft empfiehlt hierfür mindestens zwei globale Admin-Konten ohne Lizenzzuweisung (Admin-Konten sollten übrigens generell über keine Lizenzzuweisungen verfügen) und ein starkes zufälliges Passwort ohne Ablaufdatum, die aus sämtlichem CA-Richtlinien direkt oder besser indirekt über eine dedizierte Gruppe ausgenommen sind. Jede Nutzung dieser Konten muss über Entra ID Audit Logs und Alert-Regeln überwacht werden.
Ohne solche Break-Glass-Konten sperrt ein Konfigurationsfehler möglicherweise alle regulären Anmeldungen, sodass kein Zugang mehr zum Tenant besteht. Der Vollständigkeit halber muss man aber auch erwähnen, dass Microsoft seit Oktober 2025 für den Zugriff privilegierter Konten auf Microsoft-Admin-Portale einen zweiten Faktor zwingend macht. Im Zusammenhang mit Break-Glass-Konten bedeutet das, dass diese dann auch mit einem kilometerlangen Passwort ohne MFA nicht funktionieren, ob ausgenommen oder nicht. Hier verwendet man dann am besten eine andere, möglichst Phishing-resistente MFA Methode für solche Konten und legt die zugehörigen FIDO2-Keys in den Tresor des Geschäftsführers.
What-If
Bevor neue CA-Policies aktiviert werden, lohnt ein Blick in das „What-If-Tool“ (Conditional Access → Richtlinien → Was-wäre-wenn). Es simuliert, welche Policies für eine bestimmte Kombination aus Nutzer, App, Gerät und Standort-IP greifen würden – bevor irgendetwas produktiv geht. Das What-If-Tool ist kein „Nice-to-have”, sondern das wichtigste Debugging-Werkzeug in CA-Umgebungen, weil CA-Fehler schwer zu diagnostizieren und leicht zu provozieren sind. Wer es nicht kennt, sucht Fehler an der falschen Stelle.
Fazit
Mit nur vier CA-Richtlinien, klar abgegrenzt nach Standort, Gerätestatus, Anwendungs-Sensitivität und Anmelderisiko erreicht man einen soliden Grundschutz, ohne sich durch ein Übermaß von Richtlinien zu verzetteln oder zu blockieren. Zu viele Policies ohne klare Zuständigkeiten, fehlende Break-Glass-Konten oder Named Locations, die seit dem initialen Setup nie mehr aktualisiert wurden hingegen schwächen eher ihr Setup.
In meinem Beispiel wirkt jede Schicht unabhängig oder verstärkt die anderen. Dabei bilden „Named Locations“ und „Intune-Compliance“ die operative Basis, weil ohne sauber gepflegte Basisdaten auch die besten Policies nicht zuverlässig greifen.