Conditional Access verstehen, Teil 3: Sicher einführen

Die meisten Ausfälle mit Conditional Access haben nichts mit komplizierten Richtlinien zu tun. Sie entstehen, weil eine neue Richtlinie direkt auf „Ein“ und „Alle Benutzer“ gestellt wurde – und dann der Montagmorgen beginnt. In diesem Teil geht es deshalb nicht um was, sondern um wie: wie ihr Richtlinien so einführt, dass niemand ausgesperrt wird, ihr selbst am allerwenigsten.

In Teil 2 haben wir gesehen, dass alle zutreffenden Richtlinien zusammen wirken und eine Blockade alles schlägt. Genau deshalb braucht es einen sauberen Prozess.

Schritt 0: Notfallkonten anlegen

Bevor ihr die erste Richtlinie anlegt, braucht ihr Notfallkonten (Break-Glass-Konten). Das sind Konten mit der Rolle Globaler Administrator, die nur dann genutzt werden, wenn alle anderen Admins ausgesperrt sind – zum Beispiel durch eine fehlerhafte Richtlinie oder einen Ausfall des MFA-Anbieters. Microsoft empfiehlt dafür:

• mindestens zwei Konten, damit eines ausfallen darf
• nur in der Cloud, mit einer .onmicrosoft.com-Adresse, nicht aus dem lokalen AD synchronisiert
• keinem bestimmten Mitarbeiter zugeordnet und nicht für den Alltag genutzt
• eine phishing-resistente Anmeldemethode, am besten ein FIDO2-Sicherheitsschlüssel (Passkey), getrennt aufbewahrt
• aus allen Conditional-Access-Richtlinien ausgenommen, die sperren könnten
• jede Anmeldung überwacht und gemeldet, und die Konten regelmäßig getestet – Microsoft nennt mindestens alle 90 Tage

Legt außerdem eine Gruppe für die Notfallkonten an und schließt diese Gruppe aus jeder Richtlinie aus. So vergesst ihr bei neuen Richtlinien keine Ausnahme. Neben den Notfallkonten solltet ihr auch Synchronisationskonten wie das Konto von Entra Connect im Blick behalten – und Dienstkonten, die sich per Kennwort anmelden, möglichst durch verwaltete Identitäten ersetzen.

Schritt 1: Planen und aufschreiben

Microsoft empfiehlt, für jede Richtlinie vorab ein paar Fragen zu beantworten und das Ergebnis festzuhalten:

• Wer ist betroffen, wer ausgenommen – und warum?
• Welche Apps, Benutzeraktionen oder Authentifizierungskontexte?
• Unter welchen Bedingungen – Plattform, Netzwerk, Client-App, Risiko?
• Was soll passieren – gewähren mit welchen Anforderungen oder blockieren?
• Wer ist Ansprechpartner, und wann wird die Richtlinie wieder überprüft?

Eine einfache Tabelle oder SharePoint-Liste als Richtlinienregister reicht. Conditional-Access-Richtlinien haben kein Feld für einen Besitzer – ohne Register weiß in einem Jahr niemand mehr, warum es „Richtlinie 17“ gibt.

Schritt 2: Ein Namensschema, das man lesen kann

Microsoft schlägt vor, dass ein Richtlinienname auf einen Blick verrät: eine laufende Nummer, für wen die Richtlinie gilt, welche Apps sie betrifft, unter welcher Bedingung und was sie tut. Wir nutzen in Projekten ein Schema mit Nummernkreisen nach Zielgruppe:

Nummernkreis	Zielgruppe
CA0xx	alle Benutzer – die Basis
CA1xx	Administratoren und privilegierte Rollen
CA2xx	interne Mitarbeitende
CA3xx	Gäste und externe Benutzer
CA4xx	Dienstkonten und Workload-Identitäten
EM0x	Notfallrichtlinien – normalerweise aus, nur im Ernstfall einschalten

Für Notfallrichtlinien schlägt Microsoft selbst ein Schema mit dem Präfix „ENABLE IN EMERGENCY“ vor, zum Beispiel EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - …. Solche Richtlinien bleiben im Modus „Nur Bericht“ und werden nur aktiviert, wenn etwa der MFA-Dienst gestört ist.

Schritt 3: Immer zuerst „Nur Bericht“

Jede neue Richtlinie startet im Modus „Nur Bericht“ (Report-only). Entra ID wertet sie dann bei jeder Anmeldung aus, setzt sie aber nicht durch: Niemand wird blockiert, niemand bekommt eine MFA-Abfrage. In den Anmeldeprotokollen seht ihr stattdessen, was passiert wäre:

Ergebnis	Bedeutung
Nur Bericht: Erfolgreich	Bedingungen erfüllt, Anforderungen wären erfüllt gewesen – z. B. MFA war schon im Token
Nur Bericht: Fehler	Bedingungen erfüllt, Anforderungen nicht – der Benutzer wäre blockiert worden
Nur Bericht: Benutzeraktion erforderlich	der Benutzer hätte etwas tun müssen, z. B. MFA oder Nutzungsbedingungen bestätigen
Nur Bericht: Nicht angewendet	die Richtlinie traf nicht zu, z. B. weil der Benutzer ausgenommen ist

Microsoft empfiehlt, jede Richtlinie mindestens eine Woche im Berichtsmodus laufen zu lassen. Achtet darauf, dass der Bericht überhaupt Treffer zeigt – null ausgewertete Anmeldungen bedeuten meist einen Fehler in der Zuweisung.

Den Modus „Nur Bericht“ gibt es übrigens nicht für Richtlinien mit Benutzeraktionen wie „Sicherheitsinformationen registrieren“.

Schritt 4: Auswerten mit What If, Richtlinienauswirkung und Arbeitsmappe

Für die Auswertung habt ihr drei Werkzeuge:

• What If: Unter Conditional Access → Richtlinien → What If simuliert ihr eine Anmeldung – Benutzer, App, Plattform, Netzwerk, Risiko – und seht, welche Richtlinien greifen würden und warum nicht. Ideal für Ausnahmen und Sonderfälle. Es berücksichtigt aktive Richtlinien und Berichtsrichtlinien, aber keine Dienstabhängigkeiten: Teams braucht zum Beispiel im Hintergrund auch Exchange und SharePoint.
• Richtlinienauswirkung: Direkt in der Richtlinie zeigt euch die Ansicht Richtlinienauswirkung die Auswirkungen der letzten 24 Stunden, 7 Tage oder eines Monats auf interaktive Anmeldungen – samt Beispielen.
• Arbeitsmappe „Insights and Reporting“: Vergleicht mehrere Richtlinien über bis zu 90 Tage. Dafür müssen die Anmeldeprotokolle in einen Log-Analytics-Arbeitsbereich fließen.

Schritt 5: Pilot, dann alle

Funktioniert der Bericht, schaltet die Richtlinie für eine Pilotgruppe ein – am besten Leute aus der IT und ein paar freundliche Mitarbeitende aus den Fachbereichen. Erst wenn dort alles läuft, erweitert ihr auf alle Benutzer. Vorher solltet ihr:

• sicherstellen, dass alle Betroffenen die nötigen Anmeldemethoden registriert haben
• die Änderung ankündigen – Microsoft stellt dafür Kommunikationsvorlagen bereit
• den Support vorwarnen und eine Ansprechperson benennen

Schritt 6: Zurückrollen und überprüfen

Geht doch etwas schief, habt ihr mehrere Wege zurück: Richtlinie auf Aus stellen, betroffene Benutzer vorübergehend ausnehmen oder – wenn sie nicht mehr gebraucht wird – löschen. Gelöschte Richtlinien und benannte Standorte lassen sich 30 Tage lang wiederherstellen.

Plant außerdem regelmäßige Überprüfungen ein: Sind die Ausnahmen noch nötig? Gibt es Richtlinien, die sich überschneiden? Microsoft empfiehlt, Richtlinien periodisch zu konsolidieren. Mit Microsoft Security Copilot hilft dabei der Conditional Access Optimization Agent: Er findet Benutzer und Apps ohne Schutz und schlägt neue Richtlinien im Berichtsmodus vor. Er braucht allerdings Security-Compute-Units, die monatlich abgerechnet werden.

Wie es weitergeht

Der Prozess steht, die Notfallkonten sind da. In Teil 4 bauen wir das Basis-Set an Richtlinien auf, das jeder Tenant haben sollte – Schritt für Schritt, mit den genauen Einstellungen.

Offizielle Microsoft-Quellen

• Conditional-Access-Bereitstellung planen
• Notfallkonten verwalten
• Richtlinienauswirkung und Modus „Nur Bericht“
• What-If-Tool
• Arbeitsmappe „Insights and Reporting“
• Resiliente Zugriffssteuerung und Notfallrichtlinien
• Geschützte Aktionen
• Conditional Access Optimization Agent