Entra ID: Deaktiviertes Konto trotzdem angemeldet, Sitzungen widerrufen – die Lücke im Leaver-Prozess

Entra ID Konto deaktiviert, trotzdem angemeldet, Sitzungen widerrufen: Was jeder Begriff wirklich bedeutet

Wenn Sie nach entra id deaktiviertes konto trotzdem angemeldet sitzungen widerrufen gesucht haben, kennen Sie die Pointe bereits: Das Deaktivieren des Kontos eines ausgeschiedenen Mitarbeiters beendet nicht automatisch dessen Zugriff auf Microsoft 365. Die Lücke zwischen „deaktiviert" und „abgemeldet" ist kein Bug — es ist das dokumentierte, so vorgesehene Verhalten dreier getrennter Systeme, von denen ein typischer Leaver-Prozess annimmt, dass sie zusammenarbeiten, obwohl sie tatsächlich nicht miteinander verdrahtet sind.

Zwei Flags werden ständig verwechselt. Das lokale Active Directory besitzt userAccountControl mit dem ACCOUNTDISABLE-Bit (0x2) — das, was ein Helpdesk-Techniker mit Disable-ADAccount umschaltet. Microsoft Entra ID hat eine eigene, separate Eigenschaft accountEnabled am Benutzerobjekt, die über Microsoft Graph verfügbar ist und mit Update-MgUser -AccountEnabled:$false gesetzt werden kann. Das sind zwei Attribute in zwei Verzeichnissen, die nur durch den jeweils laufenden Hybrid-Sync-Prozess miteinander verbunden sind. Das Deaktivieren des lokalen Kontos ändert in Entra ID nichts, bis dieser Sync läuft — und selbst danach sind „Konto deaktiviert" und „Sitzung beendet" in Microsofts eigener Architektur weiterhin zwei unterschiedliche Ereignisse.

So funktioniert es: Die drei Lücken zwischen „deaktiviert" und „abgemeldet"

Lücke 1 — die Verzögerung beim Hybrid-Sync

Wenn der Leaver-Prozess lokal beginnt, muss die Deaktivierung erst Entra ID erreichen, bevor nachgelagerte Systeme überhaupt reagieren können. Microsoft Entra Connect Sync läuft nach einem Zeitplan, dessen standardmäßige Synchronisationsfrequenz 30 Minuten für Import, Sync und Export beträgt. In Entra ID ist von der Deaktivierung nichts zu sehen, bis dieser Zyklus läuft — ein um 9:01 Uhr deaktiviertes Konto ist aus Sicht der Cloud bis zum nächsten geplanten Durchlauf weiterhin vollständig aktiviert, sofern nicht jemand manuell Start-ADSyncSyncCycle -PolicyType Delta auslöst.

Lücke 2 — die Deaktivierung widerruft keine bereits ausgestellten Token

Sobald accountEnabled in Entra ID tatsächlich auf false wechselt, wird das bereits ausgestellte Refresh-Token des Benutzers nicht automatisch ungültig. Microsofts eigene Refresh-Token-Dokumentation listet genau die Ereignisse auf, die ein Refresh-Token widerrufen: Passwortänderung, SSPR, ein durch einen Administrator zurückgesetztes Passwort, ein von einem Benutzer oder Administrator explizit ausgelöster Sitzungswiderruf oder ein Single Sign-Out. Die Kontodeaktivierung gehört nicht zu diesen Zeilen in dieser Tabelle. Refresh-Token haben standardmäßig eine Gültigkeitsdauer von 90 Tagen, und ein bereits ausgestelltes Zugriffstoken ist ein in sich geschlossenes, signiertes Artefakt, dem ein Ressourcenanbieter vertraut, bis es von selbst abläuft — zufällig zwischen 60 und 90 Minuten, im Schnitt 75 —, sofern in der Zwischenzeit nichts erneut bei Entra ID nachfragt. Bei einer CAE-fähigen Sitzung ist dieses Zeitfenster nicht kleiner, sondern deutlich größer: Microsoft stellt langlebige Token von bis zu 28 Stunden aus, in der Annahme, dass der Widerruf durch kritische Ereignisse statt durch die Uhr gesteuert wird.

Genau für dieses „Nachfragen" ist Continuous Access Evaluation (CAE) gedacht — und genau dort liegt auch die dritte Lücke.

Lücke 3 — CAE schließt diese Lücke, aber nur für manche Apps und nicht sofort

Die Liste der kritischen Ereignisse von CAE umfasst explizit „User Account is deleted or disabled" (Benutzerkonto wird gelöscht oder deaktiviert), zusammen mit einer geänderten oder zurückgesetzten Passwort, einer für den Benutzer aktivierten Multi-Faktor-Authentifizierung, einem von einem Administrator explizit ausgelösten Widerruf aller Refresh-Token sowie einem von Microsoft Entra ID Protection erkannten hohen Benutzerrisiko. Die Auswertung kritischer Ereignisse „hängt nicht von Conditional-Access-Richtlinien ab und ist daher in jedem Mandanten verfügbar" — für diesen Teil ist keine Conditional-Access-Lizenz erforderlich. Für ein Leaver-Szenario sind jedoch drei Einschränkungen relevant:

• Microsoft gibt als Ziel nahezu Echtzeit an, „aber aufgrund der Ausbreitungszeit von Ereignissen kann eine Latenz von bis zu 15 Minuten auftreten".
• Die anfängliche Implementierung „konzentriert sich auf Exchange, Teams und SharePoint Online" — nicht auf jede App, für die ein ausgeschiedener Mitarbeiter möglicherweise noch ein Token besitzt.
• „CAE unterstützt Gastbenutzerkonten" überhaupt nicht — Widerrufsereignisse und IP-basierter Conditional Access werden bei Gästen nicht sofort durchgesetzt.

Der umgekehrte Fall hat seine eigene Latenz, die eher für das Szenario „falscher Mitarbeiter" oder eine versehentliche Deaktivierung relevant ist als für den Leaver-Fall: Microsoft dokumentiert, dass auch das Wiederaktivieren eines Benutzers direkt nach der Deaktivierung nicht sofort erfolgt — SharePoint Online und Teams haben „typischerweise eine Verzögerung von 15 Minuten", Exchange Online „typischerweise eine Verzögerung von 35–40 Minuten", bevor nachgelagerte Dienste das Konto wieder als aktiviert erkennen.

Rechnet man die drei Lücken zusammen, lautet die ehrliche Antwort auf die Frage „Wie lange kann ein deaktiviertes Konto angemeldet bleiben": mindestens die verbleibende Sync-Verzögerung plus bis zu 15 Minuten, bis CAE nachzieht — sofern die App CAE-fähig ist und es sich beim Benutzer nicht um einen Gast handelt. Außerhalb dieser Bedingungen läuft das Zugriffstoken einfach auf eigene Faust ab.

Die Leaver-Lücke in der Praxis

Das ist kein theoretischer Grenzfall — es ist das Standardergebnis von Microsofts eigener empfohlener Offboarding-Automatisierung. Die integrierte Vorlage „Offboard an employee" von Lifecycle Workflows führt standardmäßig genau drei Aufgaben aus: Disable User Account, Remove user from all groups, Remove user from all Teams. Eine separate Aufgabe, „Revoke all refresh tokens for user", existiert im Aufgabenkatalog von Lifecycle Workflows für die Kategorien Leaver und Mover — ist aber nicht Teil der Standardvorlage. Eine Organisation, die den Offboarding-Workflow unverändert einsetzt, deaktiviert das Konto und beendet den Vorgang damit.

Dieselbe Asymmetrie zeigt sich auch beim gewöhnlichen Umgang mit Sitzungskontrollen: Wie in Conditional Access-Sitzungskontrollen, Anmeldefrequenz und benannte Standorte beschrieben, legt eine Sitzungskontrolle fest, was beim nächsten Mal passiert, wenn eine Sitzung ausgewertet wird — sie „greift nicht in ein bereits ausgestelltes Zugriffstoken ein, um es zurückzuholen". Das Deaktivieren eines Kontos ist funktional dieselbe Art von vorausschauender Kontrolle, sofern nicht zusätzlich CAE oder ein expliziter Widerruf greift.

Es ist zugleich das Spiegelbild eines ganz anderen Problems, das im Katalog bereits behandelt wird: Bei AiTM-Token-Replay und der Erkennung unmöglicher Reisen geht es darum, dass die gestohlene Sitzung eines Angreifers die eigentlich dafür vorgesehenen Kontrollen überlebt. Hier überlebt die eigene Sitzung eines legitimen ehemaligen Mitarbeiters die Kontrolle, die sie eigentlich beenden sollte. Derselbe zugrunde liegende Mechanismus — ein aktives Token, das niemand explizit beendet hat — nur ein anderer Akteur.

Erkennung

Vier Signale erfassen jeweils unterschiedliche Ausschnitte dieser Lücke. Alle sind über Microsoft Graph abfragbar; das Auslesen von signInActivity erfordert gemäß Microsofts Leitfaden zu inaktiven Konten eine Microsoft Entra ID P1- oder P2-Lizenz sowie die Berechtigungen AuditLog.Read.All und User.Read.All. Zahlt der Mandant bereits für P2-Lizenzierung, schaltet dieselbe Lizenz auch den risikobasierten CAE-Trigger von Identity Protection sowie Access Reviews frei — beide sind unmittelbar nützlich, um diese Lücke zu schließen, und beide bleiben häufig unkonfiguriert, selbst nachdem die Lizenz zugewiesen wurde.

Remediation

1. Deaktivieren und Widerrufen sind ein Schritt, nicht zwei. Deaktivieren Sie einen Benutzer niemals, ohne im selben Vorgang auch dessen Token zu invalidieren:

   Import-Module Microsoft.Graph.Users
   Import-Module Microsoft.Graph.Users.Actions
   
   Connect-MgGraph -Scopes "User.EnableDisableAccount.All","User.RevokeSessions.All"
   
   Update-MgUser -UserId $userId -AccountEnabled:$false
   Revoke-MgUserSignInSession -UserId $userId
   

   Diese beiden Scopes sind die von Microsoft dokumentierten, am wenigsten privilegierten für die beiden Aufrufe; ohne die Zeile Connect-MgGraph schlagen beide Cmdlets mit einem Authentifizierungsfehler fehl. Beachten Sie den Doppelpunkt in -AccountEnabled:$false — es handelt sich um einen Switch-Parameter, sodass nur die Doppelpunkt-Schreibweise ihn auf false setzen kann. Revoke-MgUserSignInSession invalidiert jedes dem Benutzer ausgestellte Refresh-Token und jedes Browser-Sitzungscookie, mit dem von Microsoft dokumentierten Hinweis, dass „es zu einer kleinen Verzögerung von einigen Minuten kommen kann, bevor Token widerrufen werden" — und es widerruft keine Sitzungen für externe Benutzer bzw. Gäste, die sich stattdessen über ihren Heimatmandanten authentifizieren.

2. Fügen Sie die fehlende Lifecycle-Workflows-Aufgabe hinzu. Läuft das Offboarding über die integrierte Vorlage „Offboard an employee", fügen Sie die Aufgabe „Revoke all refresh tokens for user" explizit hinzu — sie ist für die Kategorie Leaver verfügbar, wird aber standardmäßig nicht eingebunden.

3. Prüfen Sie, ob Continuous Access Evaluation aktiv ist — gehen Sie nicht automatisch davon aus, dass Sie es einschalten müssen. CAE für kritische Ereignisse benötigt keine Conditional-Access-Lizenz, und gemäß Microsofts Migrationstabelle wird es bei neuen Mandanten automatisch aktiviert. Zwei Gruppen sind davon ausgenommen: Mandanten, die die alte Vorschauversion auf bestimmte Benutzer beschränkt hatten, und Mandanten, die es explizit deaktiviert hatten. Bei der Migration wird in beiden Fällen die neue Sitzungskontrolle Customize continuous access evaluation auf Disabled gesetzt — diese Mandanten laufen also ohne CAE, obwohl sie das Gegenteil annehmen. Überprüfen Sie diese Einstellung, statt sich auf den Standardwert zu verlassen. CAE schließt weder Lücke 1 (die Sync-Verzögerung) noch den blinden Fleck bei Gastkonten, aber es schließt automatisch den größten Teil von Lücke 2/3 innerhalb des dokumentierten Fensters von ~15 Minuten für Exchange-, SharePoint- und Teams-Sitzungen.

4. Lassen Sie den Leaver-Prozess nicht auf den Sync-Zeitplan warten. Führen Sie bei einer unfreiwilligen Kündigung Start-ADSyncSyncCycle -PolicyType Delta als Teil desselben Runbooks aus, statt bis zu 30 Minuten auf den nächsten geplanten Zyklus zu warten — oder, besser noch, führen Sie Deaktivierung und Widerruf zunächst direkt über Graph gegen Entra ID aus und lassen Sie das lokale AD nach seinem eigenen Zeitplan nachziehen.

5. Schließen Sie die Governance-Lücken, durch die dies unbemerkt bleibt. Ein fehlender Vorgesetzter (USER_NO_MANAGER) unterbricht den Trigger, der das Offboarding überhaupt erst hätte auslösen sollen — dieselbe Governance-Disziplin gilt auch für nicht verwaltete Gastkonten, die ebenfalls nie einen Owner oder ein Review erhalten. Führen Sie die vier oben genannten Detektoren regelmäßig aus, nicht nur zum Kündigungszeitpunkt: USER_STALE_90_DAYS und USER_NEVER_SIGNED_IN erfassen die Konten, deren Offboarding schlicht vergessen wurde.

Wie EtcSec dies erkennt

Das Azure-Entra-ID-Audit von EtcSec prüft auf alle vier oben beschriebenen Lücken: USER_DISABLED_NOT_BLOCKED listet die deaktivierten Konten auf, deren Sitzungen nie nachweislich beendet wurden, USER_STALE_90_DAYS und USER_NEVER_SIGNED_IN decken die Konten auf, die ein Leaver-Prozess nie berührt hat, und USER_NO_MANAGER findet die Konten, bei denen es beim nächsten Mal genauso schiefgehen wird, weil auch dort nichts das Offboarding auslösen wird.