Entra ID vs Azure Bastion: O Desafio dos Objetos de Dispositivo Stale após Recriação de VMs

No ecossistema de nuvem, a adoção do Microsoft Entra ID (antigo Azure AD) para autenticação em máquinas virtuais Windows é uma das práticas recomendadas de segurança mais sólidas. Ela elimina a dependência de credenciais locais, simplifica a governança de identidades e integra-se perfeitamente ao Azure Bastion, oferecendo acesso seguro, sem a necessidade de expor portas RDP publicamente.

Contudo, times de engenharia frequentemente se deparam com um cenário peculiar: após a destruição e recriação de uma VM Windows — um procedimento comum em pipelines de CI/CD ou ambientes de desenvolvimento que utilizam Infrastructure as Code (IaC) —, o login via Entra ID através do Bastion para de funcionar. O comportamento é frustrante: o log de backend aponta sucesso na autenticação, mas a sessão é encerrada instantaneamente, resultando em um erro genérico para o usuário.

O Cenário de Conflito

Em infraestruturas gerenciadas via Terraform, é comum que VMs sejam deletadas e recriadas com o mesmo hostname para otimizar custos ou limpar o ambiente. Nesse fluxo, a configuração de IaC parece impecável:

• Extensão AADLoginForWindows aplicada corretamente;
• Role assignments (RBAC) de Virtual Machine Administrator/User Login configuradas;
• Bastion devidamente configurado para Entra ID authentication.

No entanto, ao investigar o status do join no Windows via dsregcmd /status, descobrimos que a propriedade IsDeviceJoined retorna NO. A raiz do problema não está no código, mas em um resquício de estado no Entra ID.

A Causa: Objetos Stale

Quando uma VM Windows é unida ao Entra ID, um objeto de dispositivo é criado, tendo como chave primária o hostname do Windows. Se a VM é excluída no Azure, o objeto correspondente no Entra ID não é removido automaticamente. Ao recriar uma nova VM com o mesmo nome, ocorre um conflito de identidade. O registro falha silenciosamente, e, embora o usuário consiga se autenticar (via credenciais master, por exemplo), a autorização falha imediatamente na criação da sessão.

Resolução Prática

Para restaurar o acesso, é necessário purgar o objeto obsoleto:

1. Identificação: No Azure Portal, navegue até Microsoft Entra ID → Devices → All devices. Busque pelo hostname da VM afetada e verifique se o Object ID coincide com o log de erro.
2. Remoção: Exclua o objeto stale (isso não impacta qualquer outro recurso do Azure, apenas o registro da identidade do dispositivo). Você pode fazê-lo via CLI:
   az ad device delete --id <ObjectId>
3. Habilitação do Novo Join: Reinicie a VM ou a própria extensão AADLoginForWindows via a aba de extensões da máquina no portal ou via CLI/Terraform recriando o provisioning.
4. Validação: Verifique o status novamente executando dsregcmd /status dentro da VM. O parâmetro IsDeviceJoined deve retornar YES.

Insights para times de Engenharia

Este problema ilustra um ponto cego comum: automações de delete/recreate que não contemplam o ciclo de vida da identidade do dispositivo no Entra ID. Em ambientes de non-prod, onde a rotatividade de instâncias é alta, essa falha pode gerar chamados técnicos frequentes. A principal lição é monitorar o state da relação dispositivo-identidade, tratando-o como um ativo de nuvem tão crítico quanto o networking ou o armazenamento.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.