Entra ID Conditional Access Named Locations und Compliance-Policies richtig einsetzen

In meinen Azure-Kursen taucht dieses Szenario regelmäßig auf: Ein Unternehmen hat Conditional Access (bedingter Zugriff auf Microsoft-365- und Azure-Ressourcen) bereits aktiviert, aber die Richtlinien greifen nicht so, wie erwartet. Der Klassiker: Named Locations (benannte Standorte) fehlen oder sind falsch befüllt, und Compliance-Policies (Konformitätsrichtlinien) für Geräte sind zwar in Intune angelegt, aber im Conditional Access nicht als Bedingung verknüpft. Das Ergebnis ist ein Sicherheitskonzept mit Lücken, die von außen nicht sofort sichtbar sind.

Named Locations (Benannte Standortesind IP-Adressbereiche oder Länderlisten, die Sie in Entra ID (früher Azure Active Directory) hinterlegen und anschließend in Conditional-Access-Richtlinien als Bedingung nutzen. Der typische Anwendungsfall: Zugriffe aus dem eigenen Firmennetz sollen weniger streng geprüft werden als Zugriffe aus dem öffentlichen Internet.

Was Named Locations leisten – und wo die Fallstricke liegen

Technisch gesehen gibt es zwei Typen:

Achtung: Eine Named Location ist zunächst nur ein Label. Wirkung entfaltet sie erst, wenn Sie in einer Conditional-Access-Richtlinie unter Bedingungen → Standorte explizit auf diese Location verwiesen wird – entweder als eingeschlossener oder als ausgeschlossener Standort.

Ein häufiger Fehler, den ich in der Praxis sehe: Die Firmen-IP-Range wird als Named Location angelegt und als „vertrauenswürdig“ markiert. Dann aber vergessen die Administratoren, diese Location in der MFA-Richtlinie (Multi-Faktor-Authentifizierung) als Ausnahme zu definieren. Resultat: Mitarbeitende im Büro werden trotzdem nach dem zweiten Faktor gefragt, obwohl das so nicht gewollt war.

Umgekehrt gilt: Named Locations können gezielt genutzt werden, um Anmeldungen aus bestimmten Ländern grundsätzlich zu blockieren. Hier empfehle ich, zusätzlich die Sign-in Risk Policy zu aktivieren, damit nicht allein das GeoIP-Mapping als Sicherheitsnetz herhalten muss.

Compliance-Policies in Intune und ihre Rolle im Conditional Access

Compliance-Policies (Konformitätsrichtlinien) werden in Microsoft Intune definiert und legen fest, wann ein Gerät als „konform“ gilt – also beispielsweise ob BitLocker aktiv ist, ob ein aktuelles Betriebssystem-Patchlevel vorliegt oder ob ein PIN konfiguriert wurde. Entscheidend ist: Intune allein reicht nicht. Die eigentliche Zugangsentscheidung fällt im Conditional Access.

Die Verknüpfung sieht so aus: Im Conditional Access legen Sie als Zugriffsbedingung fest, dass das Gerät als konform markiert sein muss. Entra ID fragt Intune in Echtzeit ab, ob das Gerät des anmeldenden Nutzers diese Marke trägt. Fehlt die Verknüpfung, ignoriert Conditional Access den Compliance-Status vollständig – das Gerät darf sich anmelden, egal in welchem Zustand es ist.

Für meine Azure-Kurse habe ich eine Checkliste entwickelt, die diesen Zusammenhang in drei Schritten abbildet:

1. Compliance-Richtlinie in Intune anlegen und den relevanten Gerätegruppen zuweisen.
2. Warten, bis Geräte den Status konform oder nicht konform erhalten haben – das dauert je nach Synchronisierungsintervall bis zu 8 Stunden.
3. Conditional-Access-Richtlinie anlegen: Bedingung Geräteplattformen setzen, unter Zugriffssteuerung → Gewähren die Option Markierung des Geräts als konform anfordern aktivieren.

Praxistipp: Nutzen Sie den What If-Modus im Conditional Access, um zu simulieren, welche Richtlinien für einen bestimmten Nutzer, ein bestimmtes Gerät und eine bestimmte App greifen würden. Das spart stundenlange Fehlersuche im Anmeldeprotokoll.

Zusammenspiel: Named Locations und Compliance kombiniert nutzen

Der eigentliche Mehrwert entsteht, wenn beide Konzepte gemeinsam eingesetzt werden. Ein Beispiel aus der Praxis, das ich in Beratungsprojekten oft umsetze:

Diese Staffelung deckt die häufigsten Angriffsvektoren ab, ohne Mitarbeitende im Alltag übermäßig zu belasten. Wichtig dabei: Jede Richtlinie sollte mit einer Ausnahmegruppe (Exclusion Group) versehen sein, in der mindestens ein Break-Glass-Konto (Notfallkonto ohne MFA-Pflicht) hinterlegt ist. Ohne diese Absicherung riskieren Sie, sich bei einem Konfigurationsfehler selbst aus dem Tenant auszusperren.

Noch mal in Kürze – kurz, knapp und strukturiert zum Abharken:

• Named Locations anlegen: IP-Ranges für Firmennetz, Länder-Blockliste für Hochrisikoregionen.
• Compliance-Policies in Intune definieren und Gerätegruppen zuweisen.
• Conditional-Access-Richtlinien verknüpfen: Standortbedingung + Gerätekompliance als kombinierte Zugangshürde.
• What-If-Simulator zur Verifikation nutzen, bevor die Richtlinien scharf geschaltet werden.
• Break-Glass-Konten in Ausnahmegruppen pflegen – immer.

Wer das Thema in einem strukturierten Umfeld vertiefen möchte, findet in meinen Azure-Kursen praxisnahe Lab-Szenarien, in denen Named Locations und Compliance-Policies gemeinsam konfiguriert und getestet werden – inklusive der typischen Fehlerbilder, die in realen Projekten auftauchen.

Praxisempfehlung für KMUs: Starten Sie mit genau zwei Conditional-Access-Richtlinien: einer, die MFA für alle Zugriffe außerhalb der Firmen-IP erzwingt, und einer, die den Zugriff auf nicht-konforme Geräte blockiert. Diese beiden Richtlinien decken den größten Teil der realen Bedrohungsszenarien ab und lassen sich in einem Nachmittag sauber konfigurieren und testen – ohne dass Ihre Mitarbeitenden im Alltag davon etwas merken, solange ihre Geräte verwaltet und aktuell sind.

💡 Tipp: Sie möchten SC-300 professionell lernen? Ich biete den offiziellen Microsoft-Kurs SC-300 (Microsoft Identity and Access Administrator) als Online- oder Präsenz-Training an. → Zum Kurs SC-300