Conditional Access einführen, ohne sich auszusperren

Mit Conditional Access legen Sie in Microsoft Entra ID fest, wer sich unter welchen Bedingungen anmelden darf: mit welcher Methode, von welchem Gerät, aus welchem Netz. Das ist mächtig. Und genau deshalb gefährlich. Eine Richtlinie, die «alle Benutzer» und «alle Ressourcen» betrifft und eine Bedingung verlangt, die niemand erfüllt, sperrt den ganzen Tenant. Inklusive der Personen, die den Fehler beheben müssten.

Dieser Artikel beschreibt die Reihenfolge, in der wir Conditional Access einführen: zuerst die Absicherung gegen Aussperren, dann Auswerten ohne Wirkung, dann gestaffelt scharf schalten. Voraussetzung ist Microsoft Entra ID P1, enthalten etwa in Microsoft 365 Business Premium und E3. Die Sicherheitsstandards (Security Defaults) müssen dafür deaktiviert werden. Planen Sie deshalb, dass die Basisrichtlinien am selben Tag aktiv sind, an dem Sie die Sicherheitsstandards abschalten.

Zuerst: Notfallkonten einrichten und überwachen

Bevor die erste Richtlinie entsteht, braucht der Tenant mindestens zwei Notfallkonten (Emergency Access oder Break-Glass Accounts). Sie sind der Rückweg, wenn eine Richtlinie, ein Ausfall des MFA-Dienstes oder ein Fehler im Verbund alle anderen Administratoren aussperrt.

• Nur in der Cloud: Die Konten sind reine Cloud-Konten mit der Domain onmicrosoft.com, nicht synchronisiert und nicht an eine Person gebunden.
• Global Administrator, dauerhaft: Keine zeitlich begrenzte Aktivierung, die im Notfall selbst scheitern kann.
• Starke Anmeldung: Microsoft verlangt für die Admin-Portale inzwischen MFA, auch für Notfallkonten. Bewährt haben sich FIDO2-Sicherheitsschlüssel, die getrennt aufbewahrt werden, zum Beispiel im Tresor an zwei Orten.
• Von allen Richtlinien ausgeschlossen: Am einfachsten über eine eigene Gruppe, die in jeder Richtlinie unter «Ausschliessen» steht. Prüfen Sie das bei jeder neuen Richtlinie.
• Überwacht: Jede Anmeldung eines Notfallkontos muss einen Alarm auslösen. Das geht über die Anmeldeprotokolle, die an einen Log Analytics Workspace gesendet werden, und eine Warnungsregel in Azure Monitor oder über Microsoft Sentinel.

Report-only, What If und Anmeldeprotokolle

Jede neue Richtlinie startet bei uns im Modus Nur Bericht (Report-only). Entra ID wertet die Richtlinie dann bei jeder Anmeldung aus, setzt sie aber nicht durch. In den Anmeldeprotokollen sehen Sie pro Anmeldung im Reiter «Nur Bericht», ob die Richtlinie gegriffen hätte und mit welchem Ergebnis: erfolgreich, fehlgeschlagen oder Benutzeraktion erforderlich.

• Anmeldeprotokolle filtern: Suchen Sie gezielt nach Anmeldungen, bei denen eine Richtlinie im Report-only-Modus «fehlgeschlagen» wäre. Das sind die Personen und Applikationen, die nach dem Scharfschalten Probleme hätten.
• Insights-Arbeitsmappe: Die Arbeitsmappe «Conditional Access Insights and Reporting» fasst die Auswirkungen über Zeit zusammen. Sie setzt voraus, dass die Protokolle in einen Log Analytics Workspace fliessen.
• What If: Mit dem What-If-Werkzeug simulieren Sie eine konkrete Anmeldung, also Benutzer, Applikation, Plattform, Standort, und sehen, welche Richtlinien greifen würden. Ideal, um vor dem Scharfschalten die Notfallkonten und die Dienstkonten zu prüfen.

Lassen Sie Report-only mindestens eine bis zwei Wochen laufen, damit auch seltene Fälle auftauchen: Monatsabschluss, Aussendienst, Ferienvertretung, Skripte, die nur nachts laufen.

Gestaffelter Rollout: Admins, Pilot, alle

Statt alle Richtlinien auf einmal für alle zu aktivieren, gehen wir in drei Ringen vor:

1. Administratoren: Zuerst die privilegierten Rollen. Für sie gelten ohnehin die strengsten Regeln, und sie können Probleme selbst beheben. Die Richtlinie richtet sich dabei auf Verzeichnisrollen, nicht nur auf eine Gruppe, damit neue Admins automatisch erfasst werden.
2. Pilotgruppe: Eine Gruppe aus IT und einigen Personen aus den Fachbereichen, idealerweise mit unterschiedlichen Geräten und Arbeitsweisen. Die Pilotgruppe ist explizit eingeschlossen, alle anderen bleiben noch aussen vor.
3. Alle Benutzer: Erst wenn der Pilot ohne offene Punkte läuft, wird die Richtlinie auf «Alle Benutzer» erweitert, mit den definierten Ausschlüssen.

Ausschlüsse sind nötig, aber jeder Ausschluss ist eine Lücke. Führen Sie sie über Gruppen, dokumentieren Sie den Grund und überprüfen Sie die Mitgliedschaft regelmässig. Ein Dienstkonto, das «vorübergehend» ausgeschlossen wurde, ist nach zwei Jahren meist immer noch dort.

Die Bausteine: Standorte, Geräte, Authentifizierungsstärken

Benannte Standorte

Benannte Standorte (Named Locations) definieren IP-Bereiche oder Länder. Sie eignen sich, um Anmeldungen aus Ländern zu blockieren, in denen Ihr Unternehmen nicht tätig ist, oder um ein Firmennetz als vertrauenswürdig zu markieren. Verlassen Sie sich aber nicht allein darauf: Ein Firmennetz ersetzt keine MFA, und Länder-Blockaden lassen sich über VPN umgehen. Sie sind eine zusätzliche Hürde, kein Fundament.

Gerätebasierte Richtlinien

Die Bedingungen «Gerät muss als konform markiert sein» und «Microsoft Entra Hybrid Joined-Gerät erforderlich» sind sehr wirksam, haben aber Voraussetzungen:

• Für konforme Geräte müssen die Geräte in Intune verwaltet sein und Konformitätsrichtlinien erfüllen. Geräte ohne zugewiesene Konformitätsrichtlinie sollten nicht automatisch als konform gelten. Diese Einstellung finden Sie in den Intune-Konformitätseinstellungen.
• Für Hybrid Join muss die Geräteregistrierung über Entra Connect sauber eingerichtet sein und die Geräte müssen tatsächlich als hybrid verbunden erscheinen.
• Browser: Der Gerätestatus muss im Browser übermittelt werden. Unter Windows funktioniert das mit Microsoft Edge bei angemeldetem Profil, für Chrome braucht es eine Erweiterung von Microsoft. Andere Browser fallen durch.
• Mobile Geräte: Auf iOS und Android ist eine Broker-App nötig, je nach Szenario Microsoft Authenticator oder das Unternehmensportal.

Authentifizierungsstärken

«MFA erforderlich» akzeptiert jede registrierte Methode, auch SMS. Mit Authentifizierungsstärken legen Sie fest, welche Methoden zählen. Die integrierte Stärke «Phishing-resistente MFA» lässt nur Windows Hello for Business, FIDO2-Sicherheitsschlüssel und Passkeys sowie zertifikatbasierte Authentifizierung zu. Für Administratoren sollte das der Standard sein. Für alle anderen lohnt sich ein schrittweiser Übergang: zuerst die Registrierung von Passkeys fördern, dann die Stärke verlangen.

Gäste, B2B und Legacy-Authentifizierung

Gastbenutzer werden in Richtlinien oft vergessen oder pauschal ausgeschlossen. Beides ist falsch. Conditional Access bietet eine eigene Bedingung für Gäste und externe Benutzer, mit der Sie gezielt Regeln für sie setzen. Beachten Sie dabei:

• Gäste registrieren MFA standardmässig in Ihrem Tenant. Über die mandantenübergreifenden Zugriffseinstellungen können Sie MFA und Gerätestatus aus dem Heimat-Tenant des Gastes als vertrauenswürdig akzeptieren, gezielt für bestimmte Partnerorganisationen.
• Gerätebasierte Richtlinien funktionieren bei Gästen nur, wenn Sie dem Gerätestatus des Heimat-Tenants vertrauen. Sonst sperren Sie alle Gäste aus.
• Testen Sie Gastszenarien mit einem echten Gastkonto, nicht nur im What-If-Werkzeug.

Legacy-Authentifizierung kennt keine MFA. Eine Richtlinie, die die Client-Apps «Exchange ActiveSync-Clients» und «Andere Clients» für alle Benutzer blockiert, gehört zu den Basisrichtlinien. Vorher zeigen die Anmeldeprotokolle, gefiltert nach Client-App, wer noch alte Protokolle nutzt. Typische Kandidaten sind Multifunktionsgeräte und Fachapplikationen, die per SMTP AUTH senden.

Jede Richtlinie dokumentieren: Owner, Zweck, Rückweg

Nach einem Jahr hat ein Tenant schnell zwanzig Richtlinien, und niemand weiss mehr, warum CA-Test-3 existiert. Deshalb gilt bei uns:

• Namenskonvention: Nummer, Zielgruppe, Ressource und Wirkung im Namen, etwa CA010-Admins-AllApps-PhishingResistantMFA. Die Liste sortiert sich dann von selbst.
• Owner: Eine Person, die für die Richtlinie verantwortlich ist und Ausschlüsse freigibt.
• Zweck: In einem Satz, welches Risiko die Richtlinie adressiert.
• Rückweg: Was passiert, wenn sie Probleme macht? In der Regel: zurück auf Report-only, nicht löschen. Ein Export der Richtlinie als JSON, etwa über Microsoft Graph PowerShell mit Get-MgIdentityConditionalAccessPolicy, sichert den Stand vor jeder Änderung.
• Änderungsprotokoll: Die Entra-Überwachungsprotokolle zeigen, wer eine Richtlinie wann geändert hat. Ergänzen Sie das mit dem Grund.

Checkliste für die Einführung

Conditional Access ist kein Projekt mit Enddatum. Neue Applikationen, neue Partner und neue Geräte verändern die Lage laufend. Wer die Richtlinien einmal sauber strukturiert und dokumentiert hat, kann sie aber mit wenig Aufwand weiterentwickeln, ohne bei jeder Änderung das Risiko einzugehen, den eigenen Tenant zu sperren.

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen