In den letzten Tagen erreichen mich immer wieder verwunderte Nachfragen von Administratoren. Im Tenant tauchen plötzlich Conditional-Access-Richtlinien auf, die niemand angelegt hat, und in der Spalte „Verwaltet von“ steht „Microsoft“. Im Modus „Nur Berichterstellung“ laufen diese Microsoft-verwalteten Richtlinien bereits mit. Was sie genau tun und wie man am besten mit ihnen umgeht, ordne ich hier aus meiner Praxis ein.

Microsoft verteilt seit November 2023 eigene Richtlinien an die Tenants

Seit November 2023 rollt Microsoft schrittweise sogenannte Microsoft-verwaltete Richtlinien an berechtigte Entra-ID-Tenants aus. Damit will der Hersteller Mindeststandards für die Sicherheit durchsetzen, etwa Multi-Faktor-Authentifizierung (MFA) für kritische Admin-Portale und einen besseren Schutz bei riskanten Anmeldungen. Angelegt werden die Richtlinien zunächst im Report-only-Modus; sie greifen also noch nicht, protokollieren aber ausführlich. Nach mindestens 90 Tagen werden sie automatisch aktiv, sofern kein Administrator sie deaktiviert oder anderweitig eingreift. Groß angekündigt hat Microsoft das nicht. Viele Verantwortliche bemerken die neuen Regeln erst beim Blick ins Portal oder weil jemand sie darauf hinweist.

Konkret geht es um diese Richtlinientypen:

  • MFA-Pflicht für Admin-Portale
  • Umstieg von der alten Per-User-MFA auf CA-basierte MFA
  • MFA und erneute Authentifizierung bei riskanten Anmeldungen

Löschen lassen sich diese Richtlinien nicht. Man kann sie aber deaktivieren, duplizieren und individuell anpassen. Einzelheiten stehen in der offiziellen Dokumentation zu Microsoft-verwalteten Richtlinien.

Der Report-only-Modus zeigt die Wirkung, ohne etwas durchzusetzen

Im Modus „Nur Berichterstellung“ (Report-only) halten die Richtlinien fest, welche Anmeldungen sie erfasst hätten und mit welchem Ergebnis, ohne tatsächlich etwas durchzusetzen. Auswerten könnt ihr das im Conditional Access Insights Workbook oder in den Anmeldeprotokollen. Vor allem das Workbook zeigt recht anschaulich, welche Konten und Anwendungen die neuen Policies treffen würden. Dort lässt sich gezielt nach Policies filtern, sodass ihr schnell seht, ob etwa wichtige Servicekonten oder Break-Glass-Konten betroffen wären. Für den Einstieg eignet sich die offizielle Anleitung zu Conditional Access Insights & Reporting.

In komplexen Umgebungen oder bei einer eigenen Sammlung von Policies empfiehlt es sich, den Berichtsmodus einige Wochen lang zu beobachten. Wechselwirkungen und unerwartete Nebeneffekte fallen so auf, bevor man etwas aktiviert oder deaktiviert.

Break-Glass-Konten und andere Ausnahmen müssen sauber ausgeschlossen werden

In den Microsoft-verwalteten Richtlinien lassen sich Ausschlüsse festlegen. Am wichtigsten sind dabei die Break-Glass-Konten, also die Notfall-Admin-Konten. Sie sollten ausdrücklich ausgenommen sein, damit man sich nicht versehentlich aus dem Tenant aussperrt. Gepflegt werden diese Ausschlüsse im jeweiligen Richtliniendialog, und genau dort solltet ihr sie auch hinterlegen. Ebenso lassen sich Servicekonten oder andere Sonderfälle (z. B. bestimmte Anwendungen) ausnehmen. Die Richtlinien können zwar nicht gelöscht werden, ein Klick auf „Deaktivieren“ schaltet sie aber vollständig ab. Diese Entscheidung trifft man dann allerdings in eigener Verantwortung.

Mein Tipp aus Projekten: Prüft die Richtlinien frühzeitig, auch wenn der automatische Aktivierungszeitpunkt noch nicht erreicht ist. Die Policies sind ziemlich restriktiv und verursachen schnell Supportaufwand, wenn die Ausnahmen nicht vorbereitet sind.

Die Wahl zwischen Aktivieren, Ersetzen und Abschalten ist eine Strategiefrage

Im Kern muss man entscheiden, ob man die Microsoft-verwalteten Richtlinien einfach übernimmt, sie vorzeitig aktiviert oder lieber eigene, passgenaue Policies pflegt und die von Microsoft verwalteten abschaltet. In vielen Tenants treffe ich auf gut gepflegte Conditional-Access-Richtlinien, die die Microsoft-Standards erfüllen und oft sogar übertreffen. Dann spricht einiges dafür, die Microsoft-Regeln zu deaktivieren und bei den eigenen Policies zu bleiben. Schwächer abgesicherte Tenants gewinnen dagegen spürbar an Sicherheit, wenn sie die Microsoft-Regeln einfach aktivieren.

Ein Vergleich mit den klassischen „Security Defaults“ liegt nahe. Die Microsoft-verwalteten Richtlinien sind flexibler und lassen sich genauer steuern, etwa über gezielte Ausschlüsse. Automatisch ersetzen sie die Security Defaults aber nicht, beide bestehen nebeneinander. Eine ausführlichere Diskussion zu Baseline-Richtlinien findet ihr im Artikel zu Best Practices für Conditional Access in Entra ID.

Ein Diagramm zeigt den Lebenszyklus der Richtlinien

Damit der Ablauf greifbarer wird, habe ich in einem Mermaid-Diagramm skizziert, wie Microsoft-verwaltete Richtlinien in den Tenant gelangen und an welchen Stellen Admins eingreifen können:

flowchart TD
    Start["Microsoft erstellt Richtlinie"] --> ReportOnly["Report-only im Tenant"]
    ReportOnly -->|"Admin prüft Bericht"| AdminAction["Admin schaltet um oder aus"]
    ReportOnly -->|"keine Aktion"| AutoEnable["Aktivierung nach 90 Tagen"]
    AdminAction -->|"frühzeitig aktivieren"| Enabled["Richtlinie aktiv"]
    AdminAction -->|"deaktivieren"| Disabled["Richtlinie deaktiv"]
    AutoEnable --> Enabled

Abbildung: Lebenszyklus einer Microsoft-verwalteten Richtlinie in Entra ID

Ich lasse neue Richtlinien nie ungeprüft laufen

Neue Policies einfach „laufen zu lassen“, halte ich für keine gute Idee. Gerade in produktiven Tenants kann eine automatisch aktivierte Standardrichtlinie schnell Benutzer aussperren oder eingespielte Prozesse stören. Ich prüfe deshalb zuerst gründlich im Report-only-Modus und setze dann gezielt Ausnahmen. Anschließend aktiviere ich die Richtlinien entweder bewusst, oder ich nutze eigene Policies und schalte die Microsoft-verwalteten ab. Wer bereits einen Conditional-Access-Baukasten betreibt, sollte sicherstellen, dass sich nichts überschneidet und keine unerwünschten Wechselwirkungen entstehen. So behaltet ihr die Kontrolle über eure Sicherheit, und der nächste automatische Rollout bringt keine Überraschungen.