Conditional Access Session Controls, Sign-In Frequency, Benannte Standorte: Was ein aktives Token wirklich widerruft

Conditional Access Session Controls Sign-In Frequency Benannte Standorte: Was jede einzelne Einstellung bewirkt

Wenn du nach conditional access session controls sign-in frequency benannte standorte gesucht hast, verfolgst du mit ziemlicher Sicherheit eine einzige Frage: Wirft das Verschärfen einer Sitzungssteuerung tatsächlich jemanden hinaus, der bereits angemeldet ist? Die kurze Antwort lautet nein. Eine Sitzungssteuerung beschreibt, was beim nächsten Mal passiert, wenn Microsoft Entra ID die Sitzung auswertet — sie greift nicht in ein bereits ausgestelltes Zugriffstoken ein, um es zurückzuholen.

Microsofts Referenz zu Sitzungssteuerungen listet acht Steuerungen auf: anwendungserzwungene Einschränkungen, Conditional Access App Control, Sign-in-Häufigkeit, persistente Browsersitzung, Anpassung der kontinuierlichen Zugriffsauswertung, Deaktivieren der Resilienz-Standardeinstellungen, Tokenschutz für Anmeldesitzungen erforderlich und Verwendung des Sicherheitsprofils von Global Secure Access. Zwei davon — Sign-in-Häufigkeit und persistente Browsersitzung — verhalten sich über die Zeit hinweg so, wie es auf einer eigenen Seite dokumentiert ist, adaptive Sitzungslebensdauer-Richtlinien, wo Microsoft auch festhält, dass „Conditional Access eine Microsoft Entra ID P1- oder P2-Funktion ist, die eine Premium-Lizenz erfordert.“

Wenn du diese Einstellungen über Microsoft Graph statt über das Portal prüfst, wird das Bild noch enger. Die v1.0-Ressource conditionalAccessSessionControls stellt genau fünf Eigenschaften bereit — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency —, sodass ein Skript, das v1.0-Sitzungssteuerungen aufzählt, Tokenschutz oder den CAE-Schalter überhaupt nicht sieht.

Der Standard ist großzügiger, als die meisten Admins annehmen. Microsoft stellt unmissverständlich fest: „Die Standardkonfiguration von Microsoft Entra ID für die Sign-in-Häufigkeit von Benutzern ist ein gleitendes Fenster von 90 Tagen.“ Die Begründung ist explizit: „Fordern Sie Benutzer nicht zur erneuten Angabe ihrer Anmeldedaten auf, wenn sich die Sicherheitslage ihrer Sitzungen nicht geändert hat.“

Funktionsweise: Wann eine Richtlinie tatsächlich ausgewertet wird

Das ist der Satz, der alles andere bestimmt. Aus Microsofts Dokumentation zu Netzwerksignalen:

Conditional-Access-Richtlinien werden ausgewertet, wenn: sich ein Benutzer erstmals bei einer Web-App, einer mobilen oder Desktop-Anwendung anmeldet. Eine mobile oder Desktop-Anwendung, die moderne Authentifizierung verwendet, ein Refresh Token nutzt, um ein neues Zugriffstoken zu erhalten. Standardmäßig erfolgt diese Prüfung einmal pro Stunde.

Und für Browser: „Bei Web-Anwendungen gelten Richtlinien bei der Erstanmeldung und sind für die Lebensdauer der Sitzung bei der Web-Anwendung gültig.“ Microsoft ergänzt die praktische Konsequenz: „Standardmäßig stellt Microsoft Entra ID Token stündlich aus. Nachdem Benutzer das Unternehmensnetzwerk verlassen haben, wird die Richtlinie innerhalb einer Stunde für Anwendungen durchgesetzt, die moderne Authentifizierung verwenden.“

Eine Standort-Richtlinie ist also eine Prüfung zum Zeitpunkt der Erneuerung, keine live auslösende Stolperdraht — es sei denn, kontinuierliche Zugriffsauswertung kommt ins Spiel.

Sign-in-Häufigkeit, einschließlich „Jedes Mal“

Die Sign-in-Häufigkeit „legt fest, wie lange ein Benutzer auf eine Ressource zugreifen kann, bevor er sich erneut anmelden muss.“ Die Auswahl von Jedes Mal bedeutet nicht kontinuierlich. Microsoft: „Wenn Sie Jedes Mal auswählen, verlangt die Richtlinie eine vollständige erneute Authentifizierung, wenn die Sitzung ausgewertet wird. Das bedeutet: Wenn der Benutzer seinen Browser während der Sitzungslebensdauer schließt und wieder öffnet, wird er möglicherweise nicht zur erneuten Authentifizierung aufgefordert.“ Die Steuerung „berücksichtigt außerdem fünf Minuten Zeitabweichung, wenn Jedes Mal ausgewählt ist, damit Benutzer nicht öfter als einmal alle fünf Minuten aufgefordert werden.“

Die Durchsetzung wird auch für alles Nicht-Interaktive verschoben: „Wenn die Client-App (unter Aktivitätsdetails) ein Browser ist, verschiebt das System die Durchsetzung der Sign-in-Häufigkeit für Ereignisse und Richtlinien bei Hintergrunddiensten bis zur nächsten Benutzerinteraktion. Bei vertraulichen Clients verschiebt das System die Durchsetzung der Sign-in-Häufigkeit bei nicht interaktiven Anmeldungen bis zur nächsten interaktiven Anmeldung.“

Bei eingebundenen Geräten gibt es eine zweite Uhr: „Das Entsperren des Geräts oder die interaktive Anmeldung aktualisiert das Primary Refresh Token (PRT) alle vier Stunden.“ Microsofts eigenes Beispiel zeigt eine Richtlinie mit einstündiger Sign-in-Häufigkeit, die den Benutzer um 05:45 Uhr auffordert — fünf Stunden und 45 Minuten nach der ursprünglichen Anmeldung um 00:00 Uhr —, weil das PRT um 04:45 Uhr aktualisiert wurde.

Kontinuierliche Zugriffsauswertung ist der Teil, der widerruft

Kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE) verwandelt eine Richtlinie in einen nahezu echtzeitfähigen Widerruf, und zwar für eine abgeschlossene Liste kritischer Ereignisse: Ein Benutzerkonto wird gelöscht oder deaktiviert; ein Kennwort wird geändert oder zurückgesetzt; MFA wird für den Benutzer aktiviert; ein Administrator widerruft explizit alle Refresh Token; hohes Benutzerrisiko wird durch ID Protection erkannt. Microsofts angegebene Latenz: „Das Ziel für die Auswertung kritischer Ereignisse ist eine nahezu Echtzeit-Reaktion, aber aufgrund der Ereignisausbreitungszeit kann eine Latenz von bis zu 15 Minuten auftreten; die Durchsetzung der IP-Standorte-Richtlinie erfolgt jedoch sofort.“

Der Kompromiss sind längere Token: „Die Token-Lebensdauer erhöht sich in CAE-Sitzungen auf langlebig, bis zu 28 Stunden.“ Ohne CAE-fähige Clients „bleibt die Standard-Zugriffstoken-Lebensdauer bei 1 Stunde.“ Und entscheidend für diesen Artikel: „Die Sign-in-Häufigkeit wird mit oder ohne CAE eingehalten.“

Die Lücke: Wo ein aktives Token deine Richtlinie überlebt

1. Länderbasierte benannte Standorte sind für CAE unsichtbar

Das ist die wertvollste einzelne Zeile in der CAE-Dokumentation:

CAE hat nur Einblick in IP-basierte benannte Standorte. CAE hat keinen Einblick in andere Standortbedingungen wie vertrauenswürdige MFA-IPs oder länder-/regionsbasierte Standorte. Wenn ein Benutzer von einer vertrauenswürdigen MFA-IP, einem vertrauenswürdigen Standort, der vertrauenswürdige MFA-IPs einschließt, oder einem Land/einer Region kommt, wird CAE nicht durchgesetzt, nachdem sich dieser Benutzer an einen anderen Standort bewegt hat. In diesen Fällen stellt Microsoft Entra ein einstündiges Zugriffstoken ohne sofortige IP-Durchsetzungsprüfung aus.

Eine Richtlinie „Zugriff von außerhalb dieser Länder blockieren“ setzt den Tenant damit auf das Vor-CAE-Stundenmodell zurück. Microsofts eigene Anleitung ist eindeutig: „Verwenden Sie keine Land-/Regionsstandortbedingungen oder die Funktion für vertrauenswürdige IPs, die auf der Seite mit den Dienst­einstellungen der Microsoft Entra Multi-Faktor-Authentifizierung verfügbar ist.“

2. Zu viele IP-Bereiche deaktivieren die Live-Standortdurchsetzung lautlos

„Wenn die Summe aller in Standort-Richtlinien angegebenen IP-Bereiche 5.000 überschreitet, kann CAE den Ablauf bei Standortwechsel des Benutzers nicht in Echtzeit durchsetzen. In diesem Fall stellt Microsoft Entra ein einstündiges CAE-Token aus.“ Der Schwellenwert gilt tenant-weit — die Summe über alle Standort-Richtlinien hinweg, nicht eine Obergrenze pro Richtlinie —, sodass er durch Anhäufung überschritten wird, nicht durch eine einzelne Änderung. Nur die Standortdurchsetzung wird schwächer: „CAE setzt weiterhin alle anderen Ereignisse und Richtlinien durch, außer Ereignissen zum Standortwechsel des Clients.“ Auch die strukturellen Grenzen sind endlich: höchstens 195 benannte Standorte, höchstens 2.000 IP-Bereiche pro benanntem Standort und nur CIDR-Masken größer als /8.

3. Getrennte Ausgangspfade lösen die IP-Abweichungs-Ausnahme aus

Wenn die von Entra gesehene IP und die vom Ressourcenanbieter gesehene IP voneinander abweichen — Proxys, Split-Tunnel-VPN, SD-WAN, SNAT, IPv6 — „interpretiert Microsoft Entra, dass der Client sich weiterhin an einem zulässigen Standort befindet und Zugriff gewährt werden sollte. Daher stellt Microsoft Entra ein einstündiges Token aus, das IP-Adressprüfungen bei der Ressource bis zum Ablauf des Tokens aussetzt.“ Das ist der Standardmodus, standardmäßig aktiv. Microsofts strengere Alternative, die auf der CAE-Seite noch als Public Preview gekennzeichnet ist, ist die strikte Standortdurchsetzung: „den Zugriff sofort zu stoppen, wenn die vom Ressourcenanbieter erkannte IP-Adresse nicht durch die Conditional-Access-Richtlinie zugelassen ist.“

4. Persistente Browser-Cookies überleben die Richtlinie

Microsofts Warnung zur Persistenz ist unmissverständlich: „Bei persistenten Browsern bleiben Cookies auf dem Gerät des Benutzers gespeichert, selbst nachdem der Browser geschlossen wurde. Diese Cookies können auf Microsoft-Entra-Artefakte zugreifen, die bis zum Ablauf des Tokens nutzbar bleiben, unabhängig von den auf die Ressourcenumgebung angewendeten Conditional-Access-Richtlinien.“ Ein Adversary-in-the-Middle-Proxy, der genau dieses Cookie abgreift, erbt exakt diese Eigenschaft — siehe Entra ID AiTM-Token-Replay und Erkennung unmöglicher Reisen und Device-Code-Phishing dafür, wie der Diebstahl überhaupt erst geschieht.

5. Die Geräteplattform-Bedingung ist unverifizierte Eingabe

„Conditional Access identifiziert die Geräteplattform anhand von Informationen, die das Gerät bereitstellt, etwa User-Agent-Strings. Da User-Agent-Strings verändert werden können, ist diese Information nicht verifiziert.“ Eine Plattformbedingung ist ein Eingrenzungsmechanismus, keine Authentifizierungskontrolle. Microsofts Empfehlung ist, sie „zusammen mit Microsoft-Intune-Gerätekonformitätsrichtlinien oder als Teil einer Blockierungsanweisung“ einzusetzen.

6. Richtlinienänderungen gelten nicht rückwirkend

„Änderungen an Conditional-Access-Richtlinien und an der Gruppenmitgliedschaft, die von Administratoren vorgenommen werden, können bis zu einem Tag benötigen, um wirksam zu werden … Für Richtlinienaktualisierungen erfolgt eine gewisse Optimierung, die die Verzögerung auf zwei Stunden reduziert.“ Das Verschärfen einer Richtlinie nach einem Vorfall wirft die bereits bestehenden Sitzungen nicht hinaus. Zwei weitere blinde Flecken sind erwähnenswert: „CAE unterstützt keine Gastbenutzerkonten“, und „Teams besteht aus mehreren Diensten; die Anruf- und Chat-Dienste halten sich nicht an IP-basierte Conditional-Access-Richtlinien.“

Erkennung

Beginne mit der Konfiguration, dann mit der Telemetrie.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Richtlinien ganz ohne Sitzungssteuerungen, sowie solche, die auf Länderstandorte setzen
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Benannte Standorte: welche sind IP-basiert (für CAE sichtbar) und welche sind vertrauenswürdig
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Beide Cmdlets benötigen nur Policy.Read.All; Microsoft listet Global Reader, Security Reader, Security Administrator und Conditional Access Administrator als am wenigsten privilegierte Rollen für diese Lesevorgänge. Die entsprechenden REST-Aufrufe sind GET /identity/conditionalAccess/policies und GET /identity/conditionalAccess/namedLocations.

In der Graph-Antwort ist ein IP-basierter Standort #microsoft.graph.ipNamedLocation mit isTrusted und ipRanges[].cidrAddress; ein Länderstandort ist #microsoft.graph.countryNamedLocation mit countriesAndRegions und includeUnknownCountriesAndRegions. Nur die erste Art wird von CAE live durchgesetzt. Eine persistente Browser-Steuerung erscheint als persistentBrowser mit mode gleich always oder never, und Sign-in-Häufigkeit als signInFrequency mit frequencyInterval gleich timeBased oder everyTime.

Die Azure-Monitor-Tabelle SigninLogs enthält all das. Eine erste Abfrage für das Problem getrennter Pfade:

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

Microsofts Referenz zur Tabelle SigninLogs beschreibt IPAddressFromResourceProvider als „die IP-Adresse, die ein Benutzer verwendet hat, um einen Ressourcenanbieter zu erreichen, verwendet, um die Conditional-Access-Konformität für einige Richtlinien zu bestimmen … Dieser Wert ist oft null“ — null ist der gesunde Fall, das heißt, beide Sichten stimmen überein. Das Pendant im Portal ist die Spalte IP-Adresse (von Ressource gesehen) in den Anmeldeprotokollen, und Microsoft liefert eine öffentliche Workbook-Vorlage, Continuous Access Evaluation Insights, um genau diese Abweichungen sichtbar zu machen.

Behebung (Remediation)

1. Wandle durchsetzungskritische Standorte in IP-basierte benannte Standorte um. Microsoft: „Wenn Ihre Standort-Richtlinien in Echtzeit durch kontinuierliche Zugriffsauswertung durchgesetzt werden sollen, verwenden Sie nur die IP-basierte Conditional-Access-Standortbedingung und konfigurieren Sie alle IP-Adressen — sowohl IPv4 als auch IPv6 —, die von Ihrem Identitätsanbieter und Ihren Ressourcenanbietern gesehen werden können.“ Behalte Länderstandorte nur für grobe Blockierungen bei, und denke daran, dass ein als vertrauenswürdig markierter Standort „nicht gelöscht werden kann, ohne zuerst die vertrauenswürdige Kennzeichnung zu entfernen.“

2. Erfasse jede Ausgangs-IP — aus beiden Blickwinkeln. Berücksichtige die Adressen, die Entra bei der Authentifizierung sieht, und die Adressen, die Exchange Online, SharePoint Online, Teams und Microsoft Graph sehen. Fülle die Liste nicht unnötig auf: „Fügen Sie keine nicht dedizierten oder nicht aufzählbaren Ausgangs-IPs zu vertrauenswürdigen benannten Standorten in Conditional-Access-Regeln hinzu, da dies die Sicherheit schwächen kann.“ Halte die tenant-weite Gesamtsumme unter 5.000 Bereichen.

3. Behebe den blinden Proxy-Fleck richtig. Bei einem Cloud-Proxy oder VPN „ist die IP-Adresse, die Microsoft Entra ID bei der Auswertung einer Richtlinie verwendet, die IP-Adresse des Proxys. Der X-Forwarded-For-Header (XFF) … wird nicht verwendet, weil keine Validierung erfolgt, dass er von einer vertrauenswürdigen Quelle stammt.“ Microsoft empfiehlt die Wiederherstellung der Quell-IP über Global Secure Access oder eine geräteschutzbasierte Steuerung statt einer IP-Liste.

4. Ziehe strikte Standortdurchsetzung erst danach in Betracht. Validiere zuerst mit dem CAE-Workbook und dem Filter IP-Adresse (von Ressource gesehen). Microsofts Vorbehalt: „Wenn der Datenverkehr zu Microsoft Entra ID oder einer CAE-fähigen Ressource über eine gemeinsam genutzte oder nicht eindeutig bestimmbare Ausgangs-IP läuft, aktivieren Sie keine strikte Standortdurchsetzung in Ihren Conditional-Access-Richtlinien.“ Rolle sie gruppenweise aus.

5. Setze die persistente Browsersitzung auf never — und grenze sie korrekt ab. Graph dokumentiert die Einschränkung direkt bei der Eigenschaft: „Für diese Sitzungssteuerung müssen alle Apps ausgewählt sein, damit sie korrekt funktioniert.“ Eine auf eine Teilmenge von Apps eingegrenzte Richtlinie zur persistenten Browsersitzung tut nicht das, was ihr Name suggeriert.

6. Verlasse dich nicht allein auf die Plattformbedingung. Kombiniere Geräteplattformen mit Intune-Konformität oder der Bedingung Filter für Geräte. Beachte, dass die ältere Bedingung Gerätestatus veraltet ist und „Gerätestatus und Filter für Geräte in einer Conditional-Access-Richtlinie nicht zusammen verwendet werden können.“

7. Beseitige zwei bekannte Konflikte, bevor du die Sign-in-Häufigkeit aktivierst. Deaktiviere zuerst „MFA auf vertrauenswürdigen Geräten merken“ — „die gemeinsame Verwendung dieser beiden Einstellungen kann Benutzer unerwartet zur Anmeldung auffordern“ — und vermische Sitzungssteuerungen nicht mit dem veralteten Feature der konfigurierbaren Token-Lebensdauer, das „Microsoft am 30. Januar 2021 für Refresh- und Sitzungstoken-Lebensdauern eingestellt hat.“

8. Widerrufe während eines Vorfalls explizit. Da Richtlinienänderungen bis zu einem Tag (zwei Stunden mit Optimierung) benötigen, um Ressourcenanbieter zu erreichen, verwende die direkte Aktion:

Import-Module Microsoft.Graph.Users.Actions

# Ein UPN kann ebenfalls als -UserId verwendet werden.
Revoke-MgUserSignInSession -UserId $userId

Revoke-MgUserSignInSession „macht alle Refresh Token ungültig, die für Anwendungen eines Benutzers ausgestellt wurden (sowie Sitzungscookies im Browser des Benutzers), indem die Benutzereigenschaft signInSessionsValidFromDateTime auf das aktuelle Datum/die aktuelle Uhrzeit zurückgesetzt wird.“ Es benötigt mindestens User.RevokeSessions.All. Das Pendant im Portal ist Sitzung widerrufen auf der Benutzerprofilseite. Vergewissere dich, dass deine Break-Glass-Konten von jeder Standort-Richtlinie ausgeschlossen sind, bevor du sie verschärfst.

9. Füge Tokenschutz hinzu, wo der Client ihn unterstützt. Tokenschutz „versucht, Angriffe durch Token-Diebstahl zu reduzieren, indem sichergestellt wird, dass ein Token nur vom vorgesehenen Gerät aus nutzbar ist“, und die Spalte TokenProtectionStatusDetails in SigninLogs gibt an, ob ein Anmeldetoken an sein Gerät gebunden war.

Wie EtcSec das erkennt

Ein EtcSec-Azure-Audit liest deine Conditional-Access-Richtlinien und benannten Standorte über Microsoft Graph aus und kennzeichnet die Konfigurationslücken hinter jedem der oben genannten Szenarien: CA_NO_SESSION_CONTROLS, wenn keine aktivierte Richtlinie eine Sign-in-Häufigkeit oder einen persistenten Browsermodus festlegt, CA_PERSISTENT_BROWSER_ENABLED, wenn Browser-Cookies persistieren dürfen, CA_NO_NAMED_LOCATIONS und CA_NO_TRUSTED_LOCATIONS, wenn dem Tenant das Standort-Vokabular fehlt, das CAE zur Durchsetzung braucht, CA_NO_LOCATION_BLOCK, wenn keine Richtlinie überhaupt nach Standort blockiert, und CA_NO_PLATFORM_FILTER, wenn keine Richtlinie nach Geräteplattform eingrenzt. Diese passen gut zur breiteren Betrachtung in Lücken im Conditional Access von Entra ID, Lücken in der Baseline-Richtlinienabdeckung und dem durchgängigen Leitfaden zur Entra-ID-Sicherheitsprüfung.