Entra ID Deshabilitada, Sigue Conectada, Revocar Sesiones

Cuenta Entra ID Deshabilitada, Sigue Conectada, Revocar Sesiones: Qué Significa Cada Término

Si buscaste cuenta entra id deshabilitada sigue conectada revocar sesiones, ya tienes la conclusión: deshabilitar la cuenta de un empleado que se marcha no termina, por sí solo, con su acceso a Microsoft 365. La brecha entre "deshabilitada" y "desconectada" no es un error — es el comportamiento documentado y por diseño de tres sistemas separados que un proceso de baja típico asume que están conectados entre sí, pero que en realidad no lo están.

Dos indicadores se confunden constantemente. Active Directory local tiene userAccountControl con el bit ACCOUNTDISABLE (0x2) — el que un técnico de soporte activa con Disable-ADAccount. Microsoft Entra ID tiene su propia propiedad accountEnabled, separada, en el objeto de usuario, expuesta a través de Microsoft Graph y configurable con Update-MgUser -AccountEnabled:$false. Son dos atributos en dos directorios, conectados únicamente por el proceso de sincronización híbrida que se ejecuta entre ambos. Deshabilitar la cuenta local no cambia nada en Entra ID hasta que esa sincronización se ejecute — e incluso después de ejecutarse, "cuenta deshabilitada" y "sesión terminada" siguen siendo dos eventos distintos en la propia arquitectura de Microsoft.

Cómo funciona: las tres brechas entre "deshabilitada" y "desconectada"

Brecha 1 — el retraso de la sincronización híbrida

Si el proceso de baja empieza en local, la deshabilitación debe llegar a Entra ID antes de que nada en las capas posteriores pueda reaccionar. Microsoft Entra Connect Sync se ejecuta con un programador cuya frecuencia de sincronización predeterminada es de 30 minutos para la importación, sincronización y exportación. Nada en Entra ID ve la deshabilitación hasta que se ejecute ese ciclo — una cuenta deshabilitada a las 9:01 sigue estando, desde la perspectiva de la nube, plenamente habilitada hasta el siguiente paso programado, a menos que alguien active manualmente Start-ADSyncSyncCycle -PolicyType Delta.

Brecha 2 — deshabilitar no revoca los tokens ya emitidos

Una vez que accountEnabled pasa efectivamente a false en Entra ID, el refresh token ya emitido al usuario no se invalida automáticamente. La documentación de Microsoft sobre refresh tokens enumera exactamente los eventos que revocan un refresh token: cambio de contraseña, SSPR, un restablecimiento de contraseña por un administrador, una revocación explícita de sesiones por un usuario o administrador, o el cierre de sesión único (single sign-out). La deshabilitación de la cuenta no es una de las filas de esa tabla. Los refresh tokens tienen por defecto una vida útil de 90 días, y un access token ya emitido es un artefacto firmado y autocontenido en el que un proveedor de recursos confía hasta que caduca por sí solo — un intervalo aleatorio de entre 60 y 90 minutos, 75 de media — a menos que algo vuelva a verificar con Entra ID mientras tanto. En una sesión compatible con CAE, esa ventana es mucho más amplia, no más estrecha: Microsoft emite tokens de larga duración de hasta 28 horas, partiendo de la base de que la revocación se impulsará por eventos críticos y no por el reloj.

Esa "reverificación" es precisamente para lo que sirve la evaluación continua de acceso (CAE) — y ahí es también donde vive la tercera brecha.

Brecha 3 — el CAE cierra esto, pero solo para algunas aplicaciones, y no al instante

La lista de eventos críticos del CAE incluye explícitamente "la cuenta de usuario se elimina o deshabilita", junto con un cambio o restablecimiento de contraseña, la habilitación de la autenticación multifactor para el usuario, una revocación explícita de todos los refresh tokens por un administrador, y un riesgo de usuario alto detectado por Microsoft Entra ID Protection. La evaluación de eventos críticos "no depende de las políticas de acceso condicional, por lo que está disponible en cualquier tenant" — no se requiere ninguna licencia de acceso condicional para esta parte. Pero tres límites importan en un escenario de baja:

Microsoft indica que el objetivo es el tiempo casi real, "pero puede observarse una latencia de hasta 15 minutos debido al tiempo de propagación de eventos".
La implementación inicial "se centra en Exchange, Teams y SharePoint Online" — no en todas las aplicaciones en las que un empleado que se marcha podría seguir teniendo un token.
"El CAE no admite cuentas de usuario invitado" en absoluto — los eventos de revocación y el acceso condicional basado en IP no se aplican al instante para los invitados.

El caso inverso tiene su propia latencia, que importa para el escenario de "empleado equivocado" o deshabilitación accidental más que para el de baja: Microsoft documenta que volver a habilitar a un usuario justo después de deshabilitarlo tampoco es instantáneo — SharePoint Online y Teams tienen "normalmente un retraso de 15 minutos", y Exchange Online tiene "normalmente un retraso de 35 a 40 minutos", antes de que los servicios posteriores reconozcan la cuenta como habilitada de nuevo.

Sumando las tres brechas, la respuesta honesta a "cuánto tiempo puede seguir conectada una cuenta deshabilitada" es: al menos el retraso de sincronización restante, más hasta 15 minutos para que el CAE se ponga al día — si la aplicación es compatible con CAE, y el usuario no es un invitado. Fuera de esas condiciones, el access token simplemente agota su propio reloj.

La brecha del proceso de baja en la práctica

Esto no es un caso teórico — es el resultado predeterminado de la propia automatización de baja recomendada por Microsoft. La plantilla integrada "Offboard an employee" de Lifecycle Workflows ejecuta exactamente tres tareas por defecto: Disable User Account, Remove user from all groups, Remove user from all Teams. Una tarea separada, "Revoke all refresh tokens for user", existe en el catálogo de tareas de Lifecycle Workflows para las categorías Leaver y Mover — pero no forma parte de la plantilla por defecto. Una organización que ejecuta el flujo de baja listo para usar deshabilita la cuenta y se detiene ahí.

La misma asimetría aparece en el razonamiento habitual sobre control de sesión: como se trata en Controles de sesión de acceso condicional, frecuencia de inicio de sesión y ubicaciones con nombre, un control de sesión describe lo que ocurre la próxima vez que se evalúa una sesión — "no llega hasta un access token ya emitido para retirarlo". Deshabilitar una cuenta es, funcionalmente, el mismo tipo de control orientado hacia adelante, a menos que se le añadan el CAE o una revocación explícita.

También es el reflejo de un problema muy distinto que el catálogo ya cubre: la detección de repetición de tokens AiTM y viajes imposibles trata sobre la sesión robada de un atacante que sobrevive a los controles pensados para detenerla. Aquí es la propia sesión de un antiguo empleado legítimo la que sobrevive al control pensado para terminarla. El mismo mecanismo subyacente — un token activo que nadie eliminó explícitamente — pero un actor distinto.

Detección

Cuatro señales cubren tramos diferentes de esta brecha. Todas se pueden consultar mediante Microsoft Graph; leer signInActivity requiere una licencia Microsoft Entra ID P1 o P2 más los permisos AuditLog.Read.All y User.Read.All, según la guía de Microsoft sobre cuentas inactivas. Si el tenant ya paga por licencias de nivel P2, la misma licencia también desbloquea el disparador de CAE basado en riesgo de Identity Protection y las revisiones de acceso — ambos directamente útiles para cerrar esta brecha, y ambos habitualmente sin configurar incluso después de asignar la licencia. Como con otras detecciones impulsadas por Identity Protection, estos disparadores siguen inertes hasta que alguien los activa: consulta Azure Identity Protection: Bloqueo de Credenciales Filtradas para un ejemplo comparable de funcionalidad pagada pero dormida.

Señal	Qué encuentra	Patrón de consulta Graph
`USER_DISABLED_NOT_BLOCKED`	Todas las cuentas con `accountEnabled: false` — la población en la que esta brecha puede existir	`GET /users?$filter=accountEnabled eq false`
`USER_STALE_90_DAYS`	Sin actividad de inicio de sesión — interactiva o no interactiva — durante 90 días o más en una cuenta todavía habilitada, el extremo inferior de la propia "ventana razonable... entre 90 y 180 días" de Microsoft para la inactividad	`GET /users?$filter=signInActivity/lastSuccessfulSignInDateTime le {date-90d}`
`USER_NEVER_SIGNED_IN`	`signInActivity` presente pero vacío — una cuenta aprovisionada y nunca usada, o usada solo antes del inicio de la retención de registros de inicio de sesión interactivo de Entra ID (abril de 2020)	`GET /users?$select=displayName,signInActivity`, filtrado por un `lastSignInDateTime` nulo
`USER_NO_MANAGER`	Sin relación `manager` establecida en el objeto de usuario — rompe cualquier disparador de baja que dependa de una acción o notificación del responsable	`GET /users/{id}/manager`

Remediation / Remediación

Convierte la deshabilitación y la revocación en un único paso, no en dos. Nunca deshabilites a un usuario sin invalidar también sus tokens en la misma acción:
```
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
```
Esos dos ámbitos son los menos privilegiados que documenta Microsoft para las dos llamadas; sin la línea Connect-MgGraph, ambos cmdlets fallan con un error de autenticación. Fíjate en los dos puntos de -AccountEnabled:$false — es un parámetro switch, así que la forma con dos puntos es la única manera de establecerlo en false. Revoke-MgUserSignInSession invalida cada refresh token y cookie de sesión del navegador emitidos al usuario, con la advertencia documentada por Microsoft de que "puede haber un pequeño retraso de unos minutos antes de que se revoquen los tokens" — y no revoca sesiones de usuarios externos/invitados, que se autentican a través de su tenant de origen.
Añade la tarea que falta en Lifecycle Workflows. Si la baja se gestiona mediante la plantilla integrada "Offboard an employee", añade explícitamente la tarea "Revoke all refresh tokens for user" — está disponible para la categoría Leaver pero no viene conectada por defecto.
Comprueba que la evaluación continua de acceso está activada — no asumas que hay que activarla. El CAE basado en eventos críticos no necesita licencia de acceso condicional, y según la tabla de migración de Microsoft, los tenants nuevos se activan automáticamente. Dos grupos no lo están: los tenants que limitaron la antigua vista previa a algunos usuarios, y los tenants que la deshabilitaron explícitamente. Migrar cualquiera de los dos deja el nuevo control de sesión Personalizar la evaluación continua de acceso en Deshabilitado, de modo que esos tenants funcionan sin él mientras dan por hecho lo contrario. Verifica ese control en lugar de confiar en el valor predeterminado. El CAE no cerrará la Brecha 1 (el retraso de sincronización) ni el punto ciego de las cuentas invitadas, pero cierra automáticamente la mayor parte de las Brechas 2/3, dentro de la ventana documentada de unos 15 minutos, para las sesiones de Exchange, SharePoint y Teams.
No dejes que el proceso de baja espere al programador de sincronización. Para un despido, ejecuta Start-ADSyncSyncCycle -PolicyType Delta como parte del mismo runbook en lugar de esperar hasta 30 minutos al siguiente ciclo programado — o, mejor aún, ejecuta primero la deshabilitación y la revocación directamente contra Entra ID mediante Graph, y deja que Active Directory local se ponga al día según su propio calendario.
Cierra las brechas de gobierno que dejan esto pasar desapercibido. Un responsable ausente (USER_NO_MANAGER) rompe el disparador que debería haber iniciado la baja en primer lugar — la misma disciplina de gobierno se aplica a las cuentas invitadas no gobernadas que tampoco llegan a tener nunca un propietario ni una revisión. Ejecuta los cuatro detectores anteriores de forma programada, no solo en el momento de la baja: USER_STALE_90_DAYS y USER_NEVER_SIGNED_IN detectan las cuentas que nadie recordó dar de baja en absoluto.

Cómo lo detecta EtcSec

La auditoría de Azure Entra ID de EtcSec comprueba las cuatro brechas descritas anteriormente: USER_DISABLED_NOT_BLOCKED enumera las cuentas deshabilitadas cuyas sesiones nunca se cerraron de forma demostrable, USER_STALE_90_DAYS y USER_NEVER_SIGNED_IN sacan a la luz las cuentas que un proceso de baja nunca llegó a tocar, y USER_NO_MANAGER encuentra las cuentas que fallarán de la misma manera la próxima vez, porque tampoco habrá nada que dispare su baja.