Conditional Access in Microsoft 365
Ein starkes Passwort und selbst MFA reichen nicht, wenn sich ein Konto von jedem Ort, jedem Gerät und über jedes veraltete Protokoll anmelden darf. Conditional Access (auf Deutsch: bedingter Zugriff) schließt genau diese Lücke – es entscheidet bei jeder Anmeldung anhand von Bedingungen, ob und wie der Zugriff erlaubt wird. Dieser Leitfaden zeigt, wie MSPs Conditional Access in Microsoft 365 sinnvoll aufsetzen und über alle Mandanten prüfbar halten.
Was Conditional Access in Microsoft 365 ist
Conditional Access ist die Richtlinien-Engine von Microsoft Entra ID. Sie wertet bei jedem Anmeldeversuch Signale aus – wer sich anmeldet, von welchem Standort, mit welchem Gerät, auf welche App – und leitet daraus eine Entscheidung ab: Zugriff zulassen, blockieren oder unter Auflagen gewähren (etwa MFA erzwingen oder ein verwaltetes Gerät verlangen). Statt „Passwort stimmt, also rein" gilt: „Erst wenn die Bedingungen erfüllt sind."
Warum Legacy-Authentifizierung so gefährlich ist
Alte Protokolle wie POP3, IMAP, SMTP-Auth oder ältere Office-Clients kennen keine moderne Authentifizierung – und damit auch kein MFA. Angreifer wissen das: Wer per Password-Spray auf Legacy-Endpunkte zielt, umgeht die Multi-Faktor-Anforderung komplett, selbst wenn sie für das Konto eigentlich aktiv ist. Solange Legacy-Auth offen ist, bleibt MFA ein Versprechen mit Hintertür.
- Kein zweiter Faktor: Legacy-Clients fragen nur Benutzername und Passwort ab.
- Unauffällig: Solche Anmeldungen tauchen leicht übersehen in den Protokollen auf.
- Beliebtes Ziel: Ein Großteil der Kontoübernahmen läuft nachweislich über Legacy-Auth.
Basis-Richtlinien, die jeder Tenant braucht
Für die meisten Kunden bildet eine überschaubare Zahl an Richtlinien eine solide Grundlage. Als Conditional-Access-Audit lässt sich pro Mandant prüfen, ob sie existieren und greifen:
- MFA erzwingen: Für alle Benutzer, mindestens aber für Administratoren, wird Multi-Faktor-Authentifizierung verlangt.
- Legacy-Authentifizierung blockieren: Eine Richtlinie, die veraltete Clients ausnahmslos abweist – der wirksamste Einzelschritt gegen Password-Spray.
- Länder-/Standort-Bedingungen: Anmeldungen aus Regionen, in denen der Kunde gar nicht tätig ist, blockieren oder mit zusätzlicher Prüfung versehen.
- Geräte-Bedingungen: Zugriff auf sensible Apps nur von verwalteten oder konformen Geräten – oder zumindest mit erzwungenem MFA auf unbekannten Geräten.
- Break-Glass-Konto ausnehmen: Ein Notfallzugang bleibt bewusst außen vor, damit eine fehlerhafte Richtlinie euch nicht komplett aussperrt.
Wichtig: Richtlinien immer erst im Report-Only-Modus testen, bevor sie scharf geschaltet werden – sonst sperrst du im Zweifel echte Nutzer aus.
Voraussetzung: Entra ID P1 (ehrlich eingeordnet)
Conditional Access ist kein Gratis-Feature. Die frei konfigurierbaren Richtlinien setzen mindestens Entra ID P1 beim Kunden voraus (früher Azure AD Premium P1). Ohne diese Lizenz bleiben nur die Security Defaults – ein pauschaler Basisschutz, der MFA und das Blockieren von Legacy-Auth grob abdeckt, aber keine fein granularen Länder- oder Geräte-Bedingungen erlaubt. Risikobasierte Richtlinien (Sign-in-Risk) benötigen sogar Entra ID P2. Verkaufe deinen Kunden also keine Conditional-Access-Strategie, ohne die Lizenzfrage vorher zu klären – das gehört sauber ins Angebot.
Wie TenantSecure den CA- und Legacy-Auth-Status prüft
TenantSecure liest den Zustand pro Mandant aus und lässt ihn in den Härtungs-Score einfließen. Zwei der acht Härtungs-Checks drehen sich direkt um dieses Thema: ob Legacy-Authentifizierung per Conditional-Access-Block unterbunden ist und ob Security Defaults bzw. äquivalente CA-Richtlinien aktiv sind. So siehst du über dein gesamtes Portfolio, welche Kunden abgesichert sind und wo noch eine Lücke klafft – statt jeden Tenant einzeln durchzuklicken.
Ehrlich bleibt TenantSecure auch hier: Fehlt beim Kunden die Entra-ID-P1-Lizenz, lässt sich der CA-Status nicht sicher als erfüllt werten. Der Check zeigt dann „Unbekannt" statt eines geschönten Grüns. Wie der Score im Detail zustande kommt, steht in der Doku zu Härtung und Score. Den Zusammenhang mit einer portfolioweiten Baseline vertieft der Leitfaden zur Sicherheits-Baseline über alle Kunden.
Conditional Access und der Rest der Absicherung
Conditional Access steuert das Wie der Anmeldung – aber es sieht nicht, welche Drittanbieter-Apps sich einmal Zugriff erschlichen haben. Beides gehört zusammen: Ergänze deine CA-Richtlinien um ein laufendes Auge auf riskante OAuth-Apps, damit weder der Anmeldeweg noch die erteilten Berechtigungen zum offenen Tor werden.
Mit TenantSecure
TenantSecure prüft den Conditional-Access- und Legacy-Auth-Status über alle deine Mandanten, bewertet ihn im Härtungs-Score und macht Abweichungen im Portfolio-Überblick sichtbar – ohne Tenant-Hopping. Am schnellsten siehst du das an einem echten Beispiel: die Live-Demo ansehen.
Häufige Fragen
- Brauche ich für Conditional Access eine Lizenz?
- Ja. Frei konfigurierbare Conditional-Access-Richtlinien setzen mindestens Entra ID P1 voraus. Ohne P1 bleiben nur die Security Defaults als pauschaler Basisschutz; risikobasierte Richtlinien benötigen Entra ID P2.
- Was ist der wirksamste erste Conditional-Access-Schritt?
- Legacy-Authentifizierung blockieren. Alte Protokolle wie POP3, IMAP oder SMTP-Auth kennen kein MFA und sind ein Hauptweg für Kontoübernahmen per Password-Spray.
- Wie teste ich Conditional-Access-Richtlinien gefahrlos?
- Im Report-Only-Modus. Er zeigt, wie eine Richtlinie greifen würde, ohne Nutzer real auszusperren. Ein ausgenommenes Break-Glass-Konto verhindert zusätzlich, dass eine fehlerhafte Richtlinie alle aussperrt.
Weiterführende Links
Conditional-Access-Status über alle Mandanten prüfen?
TenantSecure bewertet den Conditional-Access- und Legacy-Auth-Status im Härtungs-Score und macht Abweichungen im Portfolio sichtbar – ohne Tenant-Hopping.