Account Entra ID Disabilitato, Ancora Connesso, Revocare Sessioni: il divario del processo di offboarding

Account Entra ID Disabilitato, Ancora Connesso, Revocare Sessioni: Cosa Significa Ogni Termine

Se hai cercato account entra id disabilitato ancora connesso revocare sessioni, hai già la risposta: disabilitare l'account di un dipendente che se ne va non termina, di per sé, il suo accesso a Microsoft 365. Il divario tra "disabilitato" e "disconnesso" non è un bug — è il comportamento documentato e voluto di tre sistemi separati che un tipico processo di offboarding presume collegati tra loro, ma che in realtà non lo sono affatto.

Due flag vengono continuamente confusi. Active Directory on-premise ha userAccountControl con il bit ACCOUNTDISABLE (0x2) — quello che un tecnico dell'helpdesk attiva con Disable-ADAccount. Microsoft Entra ID ha una propria proprietà accountEnabled, separata, sull'oggetto utente, esposta tramite Microsoft Graph e impostabile con Update-MgUser -AccountEnabled:$false. Sono due attributi in due directory, collegati solo dal processo di sincronizzazione ibrida che gira tra di esse. Disabilitare l'account on-premise non cambia nulla in Entra ID finché quella sincronizzazione non viene eseguita — e anche dopo l'esecuzione, "account disabilitato" e "sessione terminata" restano due eventi distinti nell'architettura stessa di Microsoft.

Come funziona: i tre divari tra "disabilitato" e "disconnesso"

Divario 1 — il ritardo della sincronizzazione ibrida

Se il processo di offboarding parte on-premise, la disabilitazione deve raggiungere Entra ID prima che qualcosa a valle possa reagire. Microsoft Entra Connect Sync gira su uno scheduler la cui frequenza di sincronizzazione predefinita è di 30 minuti per import, sync ed export. Nulla in Entra ID vede la disabilitazione finché quel ciclo non viene eseguito — un account disabilitato alle 9:01 è, dal punto di vista del cloud, ancora pienamente abilitato fino al passaggio pianificato successivo, a meno che qualcuno non attivi manualmente Start-ADSyncSyncCycle -PolicyType Delta.

Divario 2 — disabilitare non revoca i token già emessi

Una volta che accountEnabled passa effettivamente a false in Entra ID, il refresh token già emesso all'utente non viene invalidato automaticamente. La documentazione Microsoft sui refresh token elenca esattamente gli eventi che revocano un refresh token: cambio password, SSPR, un reset della password da parte di un amministratore, una revoca esplicita delle sessioni da parte di un utente o amministratore, o il single sign-out. La disabilitazione dell'account non è una delle righe di quella tabella. I refresh token hanno per default una durata di 90 giorni, e un access token già emesso è un artefatto firmato e autonomo di cui un resource provider si fida fino alla sua scadenza naturale — un intervallo casuale tra 60 e 90 minuti, 75 in media — a meno che qualcosa non verifichi nel frattempo con Entra ID. In una sessione compatibile con CAE, questa finestra è molto più ampia, non più stretta: Microsoft emette token a lunga durata fino a 28 ore, partendo dal presupposto che la revoca sarà guidata da eventi critici piuttosto che dall'orologio.

Questa "riverifica" è esattamente lo scopo della valutazione continua dell'accesso (CAE) — ed è anche dove vive il terzo divario.

Divario 3 — il CAE chiude questo divario, ma solo per alcune app, e non istantaneamente

L'elenco degli eventi critici del CAE include esplicitamente "l'account utente viene eliminato o disabilitato", insieme a un cambio o reset della password, all'abilitazione dell'autenticazione a più fattori per l'utente, a una revoca esplicita di tutti i refresh token da parte di un amministratore, e a un rischio utente elevato rilevato da Microsoft Entra ID Protection. La valutazione degli eventi critici "non dipende dai criteri di accesso condizionale, quindi è disponibile in qualsiasi tenant" — per questa parte non è richiesta alcuna licenza di accesso condizionale. Ma tre limiti contano in uno scenario di offboarding:

• Microsoft afferma che l'obiettivo è il quasi tempo reale, "ma è possibile osservare una latenza fino a 15 minuti a causa del tempo di propagazione degli eventi".
• L'implementazione iniziale "si concentra su Exchange, Teams e SharePoint Online" — non su ogni app in cui un dipendente uscito potrebbe ancora detenere un token.
• "Il CAE non supporta gli account utente guest" in alcun modo — gli eventi di revoca e l'accesso condizionale basato su IP non vengono applicati istantaneamente per gli ospiti.

Il caso inverso ha una propria latenza, che conta per lo scenario del "dipendente sbagliato" o della disabilitazione accidentale più che per l'offboarding: Microsoft documenta che riabilitare un utente subito dopo averlo disabilitato non è istantaneo nemmeno in quel caso — SharePoint Online e Teams hanno "generalmente un ritardo di 15 minuti", ed Exchange Online ha "generalmente un ritardo di 35-40 minuti", prima che i servizi a valle riconoscano l'account come nuovamente abilitato.

Sommando i tre divari, la risposta onesta a "per quanto tempo un account disabilitato può restare connesso" è: almeno il ritardo di sincronizzazione residuo, più fino a 15 minuti perché il CAE si allinei — se l'app è compatibile con CAE, e l'utente non è un guest. Al di fuori di queste condizioni, l'access token esaurisce semplicemente il proprio orologio.

Il divario del processo di offboarding nella pratica

Non è un caso teorico — è il risultato predefinito della stessa automazione di offboarding raccomandata da Microsoft. Il modello integrato "Offboard an employee" di Lifecycle Workflows esegue di default esattamente tre attività: Disable User Account, Remove user from all groups, Remove user from all Teams. Un'attività separata, "Revoke all refresh tokens for user", esiste nel catalogo attività di Lifecycle Workflows per le categorie Leaver e Mover — ma non fa parte del modello predefinito. Un'organizzazione che esegue il workflow di offboarding pronto all'uso disabilita l'account e si ferma lì.

La stessa asimmetria emerge nel ragionamento ordinario sul controllo di sessione: come trattato in Controlli di sessione di accesso condizionale, frequenza di accesso e posizioni denominate, un controllo di sessione descrive ciò che accade la prossima volta che una sessione viene valutata — "non arriva fino a un access token già emesso per riprenderselo". Disabilitare un account è, funzionalmente, lo stesso tipo di controllo rivolto al futuro, a meno che non vi si aggiungano il CAE o una revoca esplicita.

È anche lo specchio di un problema molto diverso già trattato nel catalogo: il rilevamento del replay di token AiTM e dei viaggi impossibili riguarda la sessione rubata di un attaccante che sopravvive ai controlli pensati per fermarla. Qui è invece la sessione di un ex dipendente legittimo a sopravvivere al controllo pensato per terminarla. Lo stesso meccanismo di fondo — un token attivo che nessuno ha esplicitamente ucciso — ma un attore diverso.

Rilevamento

Quattro segnali coprono porzioni diverse di questo divario. Tutti sono interrogabili tramite Microsoft Graph; leggere signInActivity richiede una licenza Microsoft Entra ID P1 o P2 più le autorizzazioni AuditLog.Read.All e User.Read.All, secondo le linee guida Microsoft sugli account inattivi. Se il tenant paga già per licenze di livello P2, la stessa licenza sblocca anche il trigger CAE basato sul rischio di Identity Protection e le Access Review — entrambi direttamente utili per colmare questo divario, ed entrambi spesso lasciati non configurati anche dopo l'assegnazione della licenza. Come per altre rilevazioni guidate da Identity Protection, questi trigger restano inerti finché nessuno li attiva: vedi Azure Identity Protection: blocco delle credenziali compromesse per un esempio analogo di funzionalità pagata ma dormiente.

Remediation / Rimedio

1. Rendi la disabilitazione e la revoca un unico passaggio, non due. Non disabilitare mai un utente senza invalidare anche i suoi token nella stessa azione:

   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
   

   Questi due scope sono i meno privilegiati documentati da Microsoft per le due chiamate; senza la riga Connect-MgGraph entrambi i cmdlet falliscono con un errore di autenticazione. Nota i due punti in -AccountEnabled:$false — è un parametro switch, quindi la forma con i due punti è l'unico modo per impostarlo su false. Revoke-MgUserSignInSession invalida ogni refresh token e cookie di sessione del browser emessi all'utente, con l'avvertenza documentata da Microsoft secondo cui "potrebbe esserci un piccolo ritardo di qualche minuto prima che i token vengano revocati" — e non revoca le sessioni degli utenti esterni/guest, che si autenticano tramite il proprio tenant di origine.

2. Aggiungi l'attività mancante in Lifecycle Workflows. Se l'offboarding passa dal modello integrato "Offboard an employee", aggiungi esplicitamente l'attività "Revoke all refresh tokens for user" — è disponibile per la categoria Leaver ma non è collegata di default.

3. Verifica che la valutazione continua dell'accesso sia attiva — non dare per scontato che vada attivata. Il CAE basato su eventi critici non richiede alcuna licenza di accesso condizionale e, secondo la tabella di migrazione di Microsoft, i nuovi tenant vengono abilitati automaticamente. Due gruppi non lo sono: i tenant che avevano limitato la vecchia anteprima a solo alcuni utenti, e i tenant che l'avevano esplicitamente disabilitata. Migrare l'uno o l'altro imposta il nuovo controllo di sessione Customize continuous access evaluation su Disabled, quindi quei tenant funzionano senza CAE pur dando per scontato il contrario. Verifica quel controllo invece di fidarti del default. Il CAE non colmerà il Divario 1 (il ritardo di sincronizzazione) né il punto cieco degli account guest, ma colma automaticamente la parte più ampia dei Divari 2/3, entro la finestra documentata di circa 15 minuti, per le sessioni Exchange, SharePoint e Teams.

4. Non lasciare che il processo di offboarding aspetti lo scheduler di sincronizzazione. Per un licenziamento, esegui Start-ADSyncSyncCycle -PolicyType Delta come parte dello stesso runbook invece di aspettare fino a 30 minuti il ciclo pianificato successivo — oppure, meglio ancora, esegui prima la disabilitazione e la revoca direttamente su Entra ID tramite Graph, e lascia che Active Directory on-premise si allinei secondo il proprio calendario.

5. Colma le lacune di governance che lasciano tutto questo inosservato. Un manager mancante (USER_NO_MANAGER) spezza il trigger che avrebbe dovuto avviare l'offboarding fin dall'inizio — la stessa disciplina di governance si applica agli account guest non governati che non ottengono mai un owner né una review. Esegui i quattro detector sopra descritti su base pianificata, non solo al momento dell'offboarding: USER_STALE_90_DAYS e USER_NEVER_SIGNED_IN individuano gli account che nessuno si è mai ricordato di disattivare del tutto.

Come EtcSec rileva questo problema

L'audit Azure Entra ID di EtcSec verifica tutti e quattro i divari descritti sopra: USER_DISABLED_NOT_BLOCKED elenca gli account disabilitati le cui sessioni non sono mai state chiuse in modo dimostrabile, USER_STALE_90_DAYS e USER_NEVER_SIGNED_IN fanno emergere gli account che un processo di offboarding non ha mai toccato, e USER_NO_MANAGER trova gli account che falliranno allo stesso modo la prossima volta, perché anche in quel caso nulla attiverà il loro offboarding.