Entra ID Conditional Access: Dein Zero-Trust-Schutzschild

Moin, liebe Admins und Homelab-Enthusiasten!

Als jemand, der seit Jahren mit Proxmox, Docker, Home Assistant und dem ganzen Netzwerk-Kram jongliert, weiß ich: Identität ist das neue Perimeter. Gerade in der heutigen, oft hybriden Welt, wo Ressourcen nicht mehr nur im lokalen Rechenzentrum liegen, ist der Schutz der Identitäten unserer Nutzer das A und O. Wer das ignoriert, hat schon verloren. Deshalb ist das Thema "Identitäten in Entra ID mit Conditional Access Policies schützen" nicht nur etwas für große Unternehmen, sondern für jeden, der seine Daten ernst nimmt – sei es im Business oder im ambitionierten Heimlabor.

In meiner Erfahrung stolpern viele, wenn sie das erste Mal mit Entra ID (dem früheren Azure AD) und vor allem Conditional Access (CA) in Berührung kommen. Die Möglichkeiten sind schier unbegrenzt, aber genau das kann am Anfang auch überfordern. Mein Ziel ist es, dir hier einen praxisnahen Guide an die Hand zu geben, der dir hilft, diese mächtigen Werkzeuge effektiv einzusetzen. Wir reden hier über die Umsetzung einer Zero-Trust-Architektur, bei der jeder Zugriffsversuch – egal von wo und von wem – explizit verifiziert wird. Kein Vertrauen, immer prüfen. Das ist der Kern.

Was ist Conditional Access in Entra ID und warum ist es so wichtig?

Stell dir Conditional Access als eine Art intelligenten Türsteher für deine Cloud-Ressourcen vor. Er prüft bei jedem Zugriffsversuch eine Reihe von Bedingungen und entscheidet dann, ob der Zugang gewährt, verweigert oder unter zusätzlichen Auflagen (wie Multi-Faktor-Authentifizierung) erlaubt wird. Es ist im Grunde ein "Wenn-Dann"-Regelwerk:

Wenn ein Benutzer X von Standort Y mit Gerät Z auf Anwendung A zugreifen will...
Dann erfordere Multi-Faktor-Authentifizierung, blockiere den Zugriff oder erlaube ihn nur mit einem kompatiblen Gerät.

Das Schöne daran: Die Entscheidung basiert auf Kontext. Ist der Benutzer bekannt? Kommt er aus einem vertrauenswürdigen Netzwerk? Ist das Gerät sicher? Ist der Anmeldeversuch riskant? All diese Signale fließen in die Entscheidung ein. Für uns Admins bedeutet das eine enorme Steigerung der Sicherheit, ohne die Benutzerfreundlichkeit unnötig zu beeinträchtigen.

Voraussetzungen für den Start

Bevor wir loslegen, lass uns sicherstellen, dass du die notwendigen Werkzeuge und Berechtigungen hast. Das ist wie beim Proxmox-Server aufsetzen: Ohne die richtige Hardware und ISO wird's nix.

Azure Subscription: Du brauchst eine aktive Azure-Subscription. Ich gehe davon aus, dass du diese bereits hast, um Entra ID zu nutzen.
Entra ID P1 oder P2 Lizenz: Das ist ganz wichtig! Conditional Access ist keine kostenlose Funktion. Du benötigst mindestens eine Entra ID P1 Lizenz für die Benutzer, für die du CA-Richtlinien anwenden möchtest. Für erweiterte Funktionen wie Identity Protection (risikobasierte Richtlinien) brauchst du sogar P2. Ohne die entsprechende Lizenz sind die CA-Einstellungen im Portal entweder ausgegraut oder die Richtlinien werden nicht angewendet.
Administrator-Rollen: Du benötigst eine der folgenden Rollen in Entra ID:
- Global Administrator: Hat volle Kontrolle über alles, aber Vorsicht!
- Conditional Access Administrator: Die dedizierte Rolle, um nur CA-Richtlinien zu verwalten. Das ist die bevorzugte Rolle, um das Prinzip der geringsten Rechte (Least Privilege) zu befolgen.
- Security Administrator: Kann ebenfalls CA-Richtlinien verwalten.
Grundverständnis von Entra ID: Du solltest wissen, wie man Benutzer und Gruppen anlegt und wie Anwendungen in Entra ID registriert werden.
Netzwerkgrundlagen: Ein Verständnis von IP-Adressen und Netzwerkbereichen ist hilfreich, besonders wenn du standortbasierte Richtlinien definieren möchtest.
Multi-Faktor-Authentifizierung (MFA): Idealerweise hast du MFA für deine Benutzer bereits aktiviert oder planst, dies im Rahmen der CA-Einführung zu tun. CA ist der perfekte Weg, MFA gezielt und nur bei Bedarf zu erzwingen.

Planung ist alles: Dein Fahrplan für Conditional Access Policies

Einfach draufloslegen ist selten eine gute Idee, besonders bei Sicherheitsrichtlinien, die dich im schlimmsten Fall aussperren können. Mein Tipp: Nimm dir Zeit für die Planung. Überlege dir genau, welche Szenarien du abdecken möchtest.

Stell dir folgende Fragen:

Wer soll geschützt werden? Alle Benutzer? Nur Administratoren? Bestimmte Abteilungen?
Welche Ressourcen sollen geschützt werden? Alle Cloud-Apps? Nur sensible Anwendungen wie die Finanzsoftware oder das HR-System?
Woher darf zugegriffen werden? Nur aus dem Büro? Von überall mit MFA? Bestimmte Länder blockieren?
Welche Geräte sind erlaubt? Nur unternehmensverwaltete Geräte? Nur solche mit einer bestimmten Compliance-Stufe (z.B. aus Intune)?
Welche Sicherheitsanforderungen gibt es? Immer MFA? Nur bei riskanten Anmeldungen? Nur bei Zugriff von außerhalb?

Wichtig zu wissen: Entra ID verarbeitet Conditional Access Policies in einer bestimmten Reihenfolge. Blockierende Richtlinien haben immer Vorrang vor gewährenden Richtlinien. Das ist ein wichtiger Punkt, den ich in meiner Karriere schon oft gesehen habe, wie er zu Kopfzerbrechen führen kann.

Ein Beispiel für eine gute Strategie ist, mit den kritischsten Identitäten und Anwendungen zu beginnen und dann schrittweise zu erweitern. Denk immer an deine Break-Glass-Accounts!

Schritt-für-Schritt-Anleitung: Conditional Access Policies einrichten

Jetzt wird's praktisch. Wir gehen die Einrichtung exemplarisch durch. Ich zeige dir, wie ich das in meinem „Produktivsystem“ (oder besser gesagt, meinem ambitionierten Test-Entra-ID) angehen würde.

1. Vorbereitung in Entra ID

Bevor wir die ersten Policies erstellen, sollten wir die Grundlagen legen.

1.1. Named Locations definieren

Vertrauenswürdige IP-Bereiche sind essenziell, um zum Beispiel MFA nur bei Zugriff von außerhalb des Büros zu erzwingen. In meinem Homelab würde ich hier die öffentliche IP meines Routers eintragen.


# Eine Named Location (vertrauenswürdiger IP-Bereich) erstellen
# Ersetze die IP-Adresse(n) durch deine eigenen
az ad named-location ip create \
  --name "Büro-Netzwerk" \
  --ip-ranges "[{ \"cidr\": \"203.0.113.0/24\" }, { \"cidr\": \"198.51.100.1/32\" }]" \
  --is-trusted true

Dieser Befehl erstellt eine Named Location namens "Büro-Netzwerk" mit den angegebenen IP-Bereichen. Markiere sie als `is-trusted`, damit du sie später in deinen Policies als vertrauenswürdig ausschließen kannst.

1.2. Sicherheitsgruppen vorbereiten

Es ist gute Praxis, Conditional Access Policies auf Gruppen anzuwenden, nicht auf einzelne Benutzer. Das macht die Verwaltung skalierbar und übersichtlicher. Erstelle Gruppen für Administratoren, normale Benutzer, Testbenutzer, etc.


# Eine neue Sicherheitsgruppe erstellen
az ad group create \
  --display-name "CA-Admins" \
  --mail-nickname "caadmins" \
  --description "Gruppe für Conditional Access Administratoren"

az ad group create \
  --display-name "CA-Testuser" \
  --mail-nickname "catestuser" \
  --description "Gruppe für Conditional Access Testbenutzer"

Nachdem die Gruppen erstellt sind, füge entsprechende Benutzer hinzu. Denk daran, dich selbst (oder zumindest einen Test-Account) zur `CA-Testuser`-Gruppe hinzuzufügen, um die Policies auszuprobieren.


# Einen Benutzer zu einer Gruppe hinzufügen
# Ersetze die Object IDs mit den tatsächlichen IDs deiner Gruppe und deines Benutzers
# Die Object ID der Gruppe findest du mit 'az ad group show --group "CA-Testuser" --query id -o tsv'
# Die Object ID des Benutzers findest du mit 'az ad user show --id "testuser@yourdomain.com" --query id -o tsv'
GROUP_OBJECT_ID=$(az ad group show --group "CA-Testuser" --query id -o tsv)
USER_OBJECT_ID=$(az ad user show --id "testuser@yourdomain.com" --query id -o tsv)

az ad group member add \
  --group-id $GROUP_OBJECT_ID \
  --member-id $USER_OBJECT_ID

2. Erstellen der ersten Conditional Access Policy: MFA für Administratoren

Dies ist eine der grundlegendsten und wichtigsten Policies. Administratoren sind ein bevorzugtes Ziel für Angreifer, daher sollte MFA für sie immer erzwungen werden.

Navigiere im Azure-Portal zu Entra ID > Protection > Conditional Access.
Klicke auf New policy.
Gib der Policy einen aussagekräftigen Namen, z.B. "CA001 - Admins: MFA Required for All Cloud Apps".
Assignments > Users or workload identities:
- Wähle Include > Directory roles > Global Administrator (oder deine spezifische Admin-Gruppe, z.B. "CA-Admins").
- WICHTIG: Unter Exclude füge mindestens einen Break-Glass Account oder eine Testgruppe (z.B. "CA-Testuser") hinzu. Das ist deine Lebensversicherung, falls du dich versehentlich aussperrst! In meiner Erfahrung ist das der häufigste Fehler, der zu Panik führt.
Cloud apps or actions > Cloud apps:
- Wähle All cloud apps. So stellst du sicher, dass die Richtlinie für alle Anwendungen gilt, auf die sich Admins über Entra ID authentifizieren.
Conditions:
- Locations: Konfiguriere dies auf Any location. Wenn du möchtest, kannst du hier auch "Any location" auswählen und unter "Exclude" deine zuvor definierten "Büro-Netzwerk"-Locations ausschließen. Das würde bedeuten, dass Admins im Büro kein MFA benötigen, außerhalb aber schon. Für Admins würde ich persönlich immer MFA erzwingen, unabhängig vom Standort.
Grant:
- Wähle Require multi-factor authentication.
- Stelle sicher, dass Require one of the selected controls ausgewählt ist.
Enable policy:
- Setze den Status zunächst auf Report-only. Das ist dein Audit-Modus. Die Richtlinie wird nicht erzwungen, aber du kannst im Sign-in Log sehen, wie sie sich auswirken würde. Das ist Gold wert für die Fehlersuche!
Klicke auf Create.

3. Eine weitere Policy erstellen: Zugriff von außerhalb blockieren

Dieses Beispiel zeigt, wie du den Zugriff aus bestimmten, nicht vertrauenswürdigen Regionen oder von außerhalb deiner Named Locations blockieren kannst.

Klicke wieder auf New policy.
Name: "CA002 - Block access from untrusted locations"
Assignments > Users or workload identities:
- Wähle Include > All users.
- WICHTIG: Unter Exclude füge wieder deine Break-Glass Accounts oder Testgruppen hinzu!
Cloud apps or actions > Cloud apps:
- Wähle All cloud apps.
Conditions > Locations:
- Konfiguriere dies. Setze Include > Any location.
- Setze Exclude > Selected locations > Büro-Netzwerk (oder deine zuvor definierte Named Location).
- Optional kannst du hier auch Selected locations > All countries/regions > Exclude > Selected countries/regions wählen, um bestimmte Länder zu blockieren.
Grant:
- Wähle Block access.
Enable policy:
- Setze den Status zunächst auf Report-only.
Klicke auf Create.

4. Testen und Überwachen der Policies

Das ist der entscheidende Schritt, bevor du Policies scharf schaltest. Vertrauen ist gut, Kontrolle ist besser!

Mit Test-Accounts anmelden: Melde dich mit einem Benutzer an, der von den Policies betroffen sein sollte (aber nicht in den ausgeschlossenen Gruppen ist). Probiere verschiedene Szenarien aus: von einem vertrauenswürdigen Standort, von einem nicht vertrauenswürdigen Standort, mit und ohne MFA.
Sign-in Logs prüfen: Navigiere in Entra ID zu Monitoring & Health > Sign-in logs.
- Hier siehst du jeden Anmeldeversuch. Klicke auf einen Eintrag, um Details zu sehen.
- Unter Conditional Access siehst du, welche Policies angewendet wurden und ob sie im "Report-only"-Modus waren oder erzwungen wurden. Das ist unglaublich hilfreich, um zu verstehen, warum ein Zugriff erlaubt oder blockiert wurde.
"What If"-Tool nutzen: Im Conditional Access Blade gibt es ein What If-Tool. Hier kannst du einen Benutzer, eine App, eine IP-Adresse usw. simulieren und sehen, welche Policies angewendet würden und welches Ergebnis (Grant/Block) dabei herauskäme. Das ist dein bester Freund bei der Planung und Fehlerbehebung.


# Eine Liste der Conditional Access Policies und ihren Status abrufen
# Dies hilft dir, schnell zu prüfen, welche Policies aktiv oder im Report-only-Modus sind.
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --query "value[].{displayName:displayName,state:state,id:id}" -o table

Dieser Befehl listet dir die Namen und den aktuellen Status (Enabled, Disabled, Report-only) deiner Conditional Access Policies auf. Eine schnelle Möglichkeit, den Überblick zu behalten.

5. Anpassen und Aktivieren

Nachdem du ausgiebig getestet hast und sicher bist, dass die Policies wie gewünscht funktionieren, kannst du sie aktivieren.

Navigiere zurück zu Entra ID > Protection > Conditional Access.
Wähle die Policy aus, die du aktivieren möchtest.
Ändere den Status von Report-only auf On.
Klicke auf Save.

Behalte die Sign-in Logs auch nach der Aktivierung im Auge. Manchmal tauchen erst im Echtbetrieb Szenarien auf, die du im Test nicht bedacht hast.

Häufige Fehler und Lösungen

Wie so oft im Admin-Alltag lauern auch hier ein paar typische Fallen. Keine Sorge, ich bin da schon reingetappt, damit du es nicht musst!

1. Aussperrung (Self-Lockout)

Problem: Du hast eine zu aggressive Richtlinie erstellt, die dich selbst oder alle Admins aussperrt, weil keine Ausnahmen definiert wurden. Ein Klassiker!
Lösung:
- Vorbeugung: Immer eine Notfall-Administrator-Gruppe (oft als "Break-Glass Accounts" bezeichnet) in jeder Conditional Access Policy unter "Exclude" hinzufügen. Diese Accounts sollten nur im Notfall verwendet werden und sind von allen CA-Richtlinien ausgenommen.
- Aktuter Fall: Wenn du dich bereits ausgesperrt hast, versuche, dich mit einem dieser Break-Glass Accounts anzumelden. Wenn du keine hast, musst du möglicherweise den Azure Support kontaktieren, was zeitaufwändig ist.
- Mein Tipp: Beginne JEDE neue Policy im "Report-only"-Modus und teste sie gründlich, bevor du sie aktivierst.

2. Richtlinienkonflikte und unerwartetes Verhalten

Problem: Mehrere Policies wirken sich auf denselben Benutzer oder dieselbe Anwendung aus und führen zu einem Ergebnis, das du nicht erwartet hast (z.B. MFA wird nicht erzwungen, obwohl es sollte, oder umgekehrt).
Lösung:
- Klarheit bei der Benennung: Gib deinen Policies aussagekräftige Namen (z.B. "CA001-Block-UnsafeLocations", "CA002-MFA-for-Admins").
- Prioritäten verstehen: Denke daran, dass blockierende Richtlinien immer Vorrang haben. Wenn eine Policy den Zugriff blockiert, werden gewährende Policies nicht mehr ausgewertet.
- "What If"-Tool: Nutze es exzessiv! Es ist das beste Werkzeug, um Konflikte zu identifizieren und die Auswirkung von Policies zu verstehen.
- Sign-in Logs analysieren: Schau dir genau an, welche Policies auf einen Anmeldeversuch angewendet wurden und warum.

3. Fehlende Lizenzen

Problem: Die Conditional Access Einstellungen sind im Azure Portal ausgegraut oder die Policies werden nicht angewendet, obwohl sie auf "On" stehen.
Lösung:
- Überprüfe, ob die betroffenen Benutzer über eine Entra ID P1- oder P2-Lizenz verfügen. Conditional Access ist keine kostenlose Funktion. Ohne die korrekte Lizenzierung bleiben die Funktionen deaktiviert oder die Policies bleiben wirkungslos.
- Stelle sicher, dass die Lizenzen auch den Benutzern zugewiesen sind, nicht nur im Tenant vorhanden sind.

Fazit und nächste Schritte

Conditional Access in Entra ID ist ein unglaublich mächtiges Werkzeug in deinem Admin-Arsenal, um deine Identitäten und somit deine gesamte IT-Infrastruktur zu schützen. Es ist der Grundpfeiler einer modernen Zero-Trust-Architektur. Wer das einmal sauber aufgesetzt hat, schläft ruhiger – das kann ich dir aus eigener Erfahrung versprechen.

Beginne klein, plane sorgfältig, teste rigoros im "Report-only"-Modus und skaliere dann schrittweise hoch. Unterschätze niemals die Macht des "What If"-Tools und der Sign-in Logs. Sie sind deine besten Freunde auf diesem Weg.

Was sind die nächsten Schritte, nachdem du die Grundlagen gemeistert hast?

Integration mit Identity Protection: Wenn du eine Entra ID P2 Lizenz hast, kannst du risikobasierte Conditional Access Policies erstellen, die auf Anomalien im Anmeldeverhalten reagieren. Extrem effektiv!
Geräte-Compliance mit Intune: Erzwinge den Zugriff nur von Geräten, die als "compliant" in Microsoft Intune markiert sind.
Session Controls: Nutze Session Controls, um zum Beispiel den Download von Daten zu blockieren oder eine kontinuierliche Sitzungsüberprüfung zu erzwingen.
Weitere Anwendungen schützen: Erweitere die Policies auf alle kritischen Anwendungen in deinem Entra ID.

Ich hoffe, dieser Guide hilft dir dabei, deine Entra ID-Umgebung sicherer zu machen. Bleib dran, die Reise in die Welt der sicheren Identitäten ist eine kontinuierliche – aber eine, die sich lohnt!