Entra ID: Conta Desativada, Ainda Conectada, Revogar Sessões — A Lacuna no Processo de Desligamento

Entra ID: Conta Desativada, Ainda Conectada, Revogar Sessões — O Que Cada Termo Realmente Significa

Se você pesquisou por entra id conta desativada ainda conectada revogar sessões, já sabe a resposta: desativar a conta de um funcionário desligado não encerra, por si só, o acesso dele ao Microsoft 365. A lacuna entre "desativado" e "desconectado" não é um bug — é o comportamento documentado e intencional de três sistemas separados que um processo de desligamento típico presume que funcionam juntos, mas que, na prática, não estão conectados entre si.

Dois sinalizadores são constantemente confundidos. O Active Directory local possui userAccountControl com o bit ACCOUNTDISABLE (0x2) — o que um técnico de helpdesk altera com Disable-ADAccount. O Microsoft Entra ID tem sua própria propriedade accountEnabled, separada, no objeto de usuário, exposta via Microsoft Graph e configurável com Update-MgUser -AccountEnabled:$false. São dois atributos em dois diretórios distintos, conectados apenas pelo processo de sincronização híbrida que roda entre eles. Desativar a conta local não altera nada no Entra ID até que essa sincronização seja executada — e mesmo depois que ela roda, "conta desativada" e "sessão encerrada" continuam sendo dois eventos diferentes na própria arquitetura da Microsoft.

Como Funciona: As Três Lacunas Entre "Desativado" e "Desconectado"

Lacuna 1 — o atraso da sincronização híbrida

Se o processo de desligamento começa no ambiente local, a desativação precisa chegar ao Entra ID antes que qualquer sistema downstream possa reagir a ela. O Microsoft Entra Connect Sync roda em um agendamento cuja frequência padrão de sincronização é de 30 minutos para importação, sincronização e exportação. Nada no Entra ID enxerga a desativação até que esse ciclo rode — uma conta desativada às 9h01 está, do ponto de vista da nuvem, ainda totalmente ativada até a próxima passagem agendada, a menos que alguém dispare manualmente Start-ADSyncSyncCycle -PolicyType Delta.

Lacuna 2 — desativar não revoga os tokens já emitidos

Assim que accountEnabled realmente muda para false no Entra ID, o refresh token já emitido para o usuário não é invalidado automaticamente. A própria documentação de refresh token da Microsoft lista os eventos exatos que revogam um refresh token: troca de senha, SSPR, redefinição de senha por um administrador, revogação explícita de sessões por um usuário ou administrador, ou single sign-out. A desativação de conta não está entre essas linhas da tabela. Os refresh tokens têm, por padrão, vida útil de 90 dias, e um access token já emitido é um artefato assinado e autocontido no qual um provedor de recursos confia até que ele expire por conta própria — um período aleatório entre 60 e 90 minutos, em média 75 —, a menos que algo consulte novamente o Entra ID nesse meio tempo. Em uma sessão compatível com CAE, essa janela é muito mais ampla, não mais estreita: a Microsoft emite tokens de longa duração de até 28 horas, partindo do princípio de que a revogação será orientada por eventos críticos, e não pelo relógio.

Essa "consulta novamente" é justamente para o que serve a avaliação contínua de acesso (CAE) — e é também onde mora a terceira lacuna.

Lacuna 3 — o CAE fecha essa lacuna, mas só para alguns aplicativos, e não instantaneamente

A lista de eventos críticos do CAE inclui explicitamente "User Account is deleted or disabled" (conta de usuário excluída ou desativada), além de senha alterada ou redefinida, autenticação multifator ativada para o usuário, revogação explícita de todos os refresh tokens por um administrador, e alto risco de usuário detectado pelo Microsoft Entra ID Protection. A avaliação de eventos críticos "não depende de políticas de Acesso Condicional, portanto está disponível em qualquer locatário" — nenhuma licença de Acesso Condicional é necessária para essa parte. Mas três limitações importam para um cenário de desligamento:

• A Microsoft afirma que o objetivo é quase em tempo real, "mas uma latência de até 15 minutos pode ser observada devido ao tempo de propagação do evento".
• A implementação inicial "concentra-se em Exchange, Teams e SharePoint Online" — não em todos os aplicativos para os quais um funcionário desligado ainda possa manter um token.
• "O CAE não oferece suporte a contas de usuário convidado" de forma alguma — eventos de revogação e Acesso Condicional baseado em IP não são aplicados instantaneamente para convidados.

O caso inverso tem sua própria latência, mais relevante para o cenário de "funcionário errado" ou desativação acidental do que para o de desligamento: a Microsoft documenta que reativar um usuário logo após desativá-lo também não é instantâneo — SharePoint Online e Teams "normalmente têm um atraso de 15 minutos", e o Exchange Online "normalmente tem um atraso de 35 a 40 minutos", antes que os serviços downstream reconheçam a conta como ativada novamente.

Somando as três lacunas, a resposta honesta para "por quanto tempo uma conta desativada pode continuar conectada" é: pelo menos o atraso de sincronização restante, mais até 15 minutos para o CAE se atualizar — se o aplicativo for compatível com CAE e o usuário não for um convidado. Fora dessas condições, o access token simplesmente esgota seu próprio relógio.

A Lacuna do Desligamento na Prática

Isso não é um caso extremo teórico — é o resultado padrão da própria automação de offboarding recomendada pela Microsoft. O modelo integrado "Offboard an employee" do Lifecycle Workflows executa, por padrão, exatamente três tarefas: Disable User Account, Remove user from all groups, Remove user from all Teams. Uma tarefa separada, "Revoke all refresh tokens for user", existe no catálogo de tarefas do Lifecycle Workflows para as categorias Leaver e Mover — mas não faz parte do modelo padrão. Uma organização que usa o workflow de offboarding pronto para uso desativa a conta e para por aí.

A mesma assimetria aparece no raciocínio comum sobre controles de sessão: como abordado em Controles de sessão de Acesso Condicional, frequência de login e locais nomeados, um controle de sessão descreve o que acontece na próxima vez que uma sessão é avaliada — ele "não alcança um access token já emitido para revogá-lo". Desativar uma conta é, funcionalmente, o mesmo tipo de controle prospectivo, a menos que o CAE ou uma revogação explícita sejam adicionados por cima.

É também o espelho de um problema bem diferente que o catálogo já aborda: replay de token AiTM e detecção de viagem impossível trata de uma sessão roubada por um invasor que sobrevive aos controles feitos para impedi-la. Aqui, é a própria sessão de um ex-funcionário legítimo que sobrevive ao controle feito para encerrá-la. O mesmo mecanismo subjacente — um token ativo que ninguém encerrou explicitamente — mas um ator diferente.

Detecção

Quatro sinais capturam fatias diferentes dessa lacuna. Todos podem ser consultados via Microsoft Graph; ler signInActivity exige uma licença Microsoft Entra ID P1 ou P2, além das permissões AuditLog.Read.All e User.Read.All, conforme a orientação da Microsoft sobre contas inativas. Se o locatário já paga pelo licenciamento de nível P2, a mesma licença também libera o gatilho de CAE baseado em risco do Identity Protection e as Revisões de Acesso — ambos diretamente úteis para fechar essa lacuna, e ambos comumente deixados sem configuração mesmo depois que a licença é atribuída.

Remediation

1. Torne desativar e revogar a mesma etapa, não duas. Nunca desative um usuário sem também invalidar os tokens dele na mesma ação:

   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
   

   Esses dois escopos são os menos privilegiados documentados pela Microsoft para as duas chamadas; sem a linha Connect-MgGraph, ambos os cmdlets falham com um erro de autenticação. Observe os dois-pontos em -AccountEnabled:$false — é um parâmetro switch, então a forma com dois-pontos é a única maneira de defini-lo como falso. Revoke-MgUserSignInSession invalida todo refresh token e cookie de sessão de navegador emitido para o usuário, com a ressalva documentada pela Microsoft de que "pode haver um pequeno atraso de alguns minutos antes que os tokens sejam revogados" — e não revoga sessões de usuários externos/convidados, que se autenticam pelo locatário de origem deles.

2. Adicione a tarefa ausente do Lifecycle Workflows. Se o offboarding roda pelo modelo integrado "Offboard an employee", adicione explicitamente a tarefa "Revoke all refresh tokens for user" — ela está disponível para a categoria Leaver, mas não vem conectada por padrão.

3. Verifique se a avaliação contínua de acesso está ativa — não presuma que precisa ativá-la. O CAE para eventos críticos não exige licença de Acesso Condicional, e, segundo a tabela de migração da Microsoft, locatários novos vêm com ele ativado automaticamente. Dois grupos ficam de fora: locatários que restringiram a antiga versão de preview a alguns usuários, e locatários que a desativaram explicitamente. Migrar qualquer um dos dois define o novo controle de sessão Customize continuous access evaluation como Disabled, então esses locatários operam sem CAE enquanto presumem o contrário. Verifique esse controle em vez de confiar no padrão. O CAE não fecha a Lacuna 1 (o atraso de sincronização) nem o ponto cego das contas convidado, mas fecha automaticamente a maior parte da Lacuna 2/3, dentro da janela documentada de ~15 minutos, para sessões de Exchange, SharePoint e Teams.

4. Não deixe o processo de desligamento esperar pelo agendamento de sincronização. Em um desligamento involuntário, execute Start-ADSyncSyncCycle -PolicyType Delta como parte do mesmo runbook, em vez de esperar até 30 minutos pelo próximo ciclo agendado — ou, melhor ainda, execute primeiro a desativação e a revogação diretamente no Entra ID via Graph, e deixe o AD local se atualizar em seu próprio ritmo.

5. Feche as lacunas de governança que permitem que isso passe despercebido. Um gestor ausente (USER_NO_MANAGER) quebra o gatilho que deveria ter iniciado o offboarding em primeiro lugar — a mesma disciplina de governança se aplica também a contas convidado sem governança que nunca recebem um responsável ou uma revisão. Execute os quatro detectores acima de forma recorrente, não apenas no momento do desligamento: USER_STALE_90_DAYS e USER_NEVER_SIGNED_IN capturam as contas cujo offboarding simplesmente ninguém se lembrou de fazer.

Como a EtcSec Detecta Isso

A auditoria de Azure Entra ID da EtcSec verifica as quatro lacunas descritas acima: USER_DISABLED_NOT_BLOCKED lista as contas desativadas cujas sessões nunca foram comprovadamente encerradas, USER_STALE_90_DAYS e USER_NEVER_SIGNED_IN revelam as contas que um processo de desligamento nunca tocou, e USER_NO_MANAGER encontra as contas que falharão da mesma forma na próxima vez, porque nada disparará o offboarding delas também.