Migrar o Active Directory para o Azure é uma decisão de arquitetura de identidade, não uma simples mudança de servidor. Quem chega até aqui normalmente já percebeu que o termo esconde caminhos diferentes — Entra ID puro, Entra Domain Services ou um modelo híbrido com Entra Connect — e que a escolha errada aparece justamente na fase de piloto, quando aplicações internas deixam de autenticar.
Este texto foi escrito para decisores de TI que precisam justificar a decisão tecnicamente, e não apenas escolher um fornecedor. O foco está no que costuma faltar nas discussões iniciais: o inventário de dependências legadas (Kerberos, LDAP, NTLM), os riscos de segurança que se abrem durante a janela de migração e os critérios objetivos para definir o modelo de destino. Também trata do que raramente é planejado com antecedência — o descomissionamento seguro do AD local e a validação de dependências residuais antes de desligar o último controlador de domínio.
Nenhuma das etapas substitui uma avaliação técnica do ambiente. O objetivo é dar repertório para conduzir essa avaliação com critério e reduzir risco ao longo do processo.
O que realmente significa migrar o Active Directory para o Azure
Migrar o Active Directory para o Azure raramente significa "copiar o AD local para a nuvem e desligar o servidor". Na prática, trata-se de um reposicionamento da autoridade de identidade: parte da autenticação e da autorização passa a viver no Microsoft Entra ID, enquanto protocolos legados como Kerberos, LDAP e NTLM continuam exigindo um domínio tradicional — seja ele mantido on-premises, seja executado como serviço gerenciado no Azure. Empresas que iniciam o projeto sem entender essa distinção costumam descobrir, já na fase de piloto, que dezenas de aplicações internas não conseguem autenticar contra o Entra ID puro.
O termo "Active Directory" também carrega uma ambiguidade herdada do histórico de nomenclatura da Microsoft. O que existia como Azure Active Directory foi renomeado para Microsoft Entra ID em 2023, e o serviço de domínio gerenciado passou a se chamar Entra Domain Services. Decisores de TI que buscam fornecedores ou documentação ainda encontram farto material com os nomes antigos, o que gera confusão sobre qual componente resolve qual problema. A clareza conceitual é o primeiro entregável de qualquer projeto sério de migração.
Entra ID, Entra Domain Services e AD híbrido: o que cada um resolve
O Microsoft Entra ID é um diretório de identidade nativo da nuvem, baseado em padrões como OAuth 2.0, OpenID Connect e SAML. Ele autentica usuários para Microsoft 365, aplicações SaaS e aplicações modernas registradas no Azure, mas não oferece suporte nativo a Kerberos, LDAP ou NTLM. O Entra Domain Services, por sua vez, provisiona um domínio gerenciado com dois controladores de domínio invisíveis, compatível com autenticação integrada do Windows e LDAP — sem que a empresa administre, atualize ou faça backup desses controladores.
O modelo híbrido combina o AD local com o Entra ID por meio do Entra Connect (ou do Entra Connect Cloud Sync), sincronizando identidades e, opcionalmente, hashes de senha. Nesse arranjo, o AD local permanece como fonte de autoridade para objetos e políticas de grupo, enquanto a nuvem assume a autenticação de aplicações modernas. A escolha entre os três modelos depende menos de preferência arquitetural e mais do inventário de dependências legadas que a empresa ainda mantém.
- Entra ID puro: aplicações modernas, SaaS, Microsoft 365 e dispositivos ingressados na nuvem.
- Entra Domain Services: aplicações legadas que exigem Kerberos/LDAP, mas sem equipe para manter AD local.
- Híbrido com Entra Connect: coexistência prolongada entre AD local e nuvem, com sincronização de identidades.
O que não dá para migrar (e por que o AD local costuma permanecer)
Nem tudo que depende do Active Directory local pode ser movido para o Entra ID. GPOs completas, trusts entre florestas, extensões de schema personalizadas, autoridade certificadora integrada ao AD e aplicações que usam autenticação integrada do Windows via NTLM ou Kerberos são exemplos clássicos de dependências que ancoram o AD on-premises. O Entra Domain Services cobre parte desses cenários, mas impõe restrições: não há acesso de administrador de domínio, não há extensão de schema e a floresta é isolada por padrão.
Além disso, dispositivos ingressados em domínio tradicional com GPOs complexas de segurança — como restrições de software via AppLocker, configurações de BitLocker e mapeamento de impressoras — não migram automaticamente para o gerenciamento via Intune. A migração dessas políticas exige reescrevê-las como políticas de conformidade e perfis de configuração, um trabalho que pode levar meses em ambientes com centenas de GPOs. Por isso, o AD local costuma permanecer ativo por anos após a "migração", operando em paralelo com o Entra ID.
Diagnóstico antes de migrar: inventário de identidades, aplicativos e dependências
O erro mais caro em projetos de migração de AD para Azure é decidir o modelo de destino antes de mapear o que realmente depende do diretório local. Um inventário bem executado responde a três perguntas: quais identidades precisam existir na nuvem, quais aplicações autenticam contra o AD e quais protocolos essas aplicações exigem. Sem esse levantamento, o projeto vira uma sucessão de descobertas desagradáveis durante o piloto, com prazos estourando e aplicações críticas fora do ar.
Ferramentas de descoberta como o Microsoft Entra Connect Health, scripts de inventário via PowerShell e soluções de terceiros conseguem identificar padrões de autenticação nos controladores de domínio. A análise dos logs de segurança do AD — especialmente os eventos de logon 4624, 4768 e 4771 — revela quais servidores e estações ainda usam NTLM, quais contas de serviço autenticam via Kerberos e quais aplicações dependem de LDAP simples. Esse mapeamento é a base para qualquer decisão arquitetural minimamente responsável.
Mapeando autenticação legada: Kerberos, LDAP, NTLM e aplicações que dependem delas
Protocolos legados são a principal razão pela qual migrações para nuvem pura falham. O NTLM, embora desencorajado pela Microsoft há mais de uma década, ainda aparece em ambientes corporativos por causa de aplicações antigas, servidores de arquivos e dispositivos de rede. O Kerberos, mais seguro, continua sendo o padrão para autenticação integrada em domínios Windows. Já o LDAP é amplamente usado por sistemas de RH, firewalls, soluções de VPN e aplicações de terceiros para consultar atributos de usuários e validar credenciais.
O mapeamento deve classificar cada aplicação em uma de três categorias: compatível com SAML/OIDC (pode migrar para SSO no Entra ID), dependente de Kerberos/LDAP (candidata ao Entra Domain Services ou à permanência no AD híbrido) e incompatível com qualquer modelo de nuvem (exige modernização ou substituição). Aplicações de missão crítica que dependem de NTLM, por exemplo, não funcionam contra o Entra Domain Services em todos os cenários e precisam de avaliação individual antes de qualquer decisão.
Avaliando o estado do AD local: florestas, domínios, GPOs e nível funcional
O estado de saúde do AD local influencia diretamente a estratégia de migração. Florestas com múltiplos domínios, trusts complexos e nível funcional antigo (2008 R2 ou inferior) exigem etapas preparatórias antes de qualquer sincronização com o Entra ID. O Entra Connect, por exemplo, suporta sincronização de múltiplas florestas e exige que os atributos de âncora estejam consistentes.
O inventário de GPOs é outro ponto negligenciado. Empresas com centenas de políticas de grupo precisam decidir, uma a uma, o que será reescrito no Intune, o que será abandonado e o que permanecerá no AD local. O nível funcional do domínio também importa: recursos como o Protected Users group e a delegação granular de administração dependem de níveis funcionais mais recentes e afetam a postura de segurança durante a janela de migração.
Escolhendo o modelo: nuvem pura, híbrido ou domínio gerenciado
A decisão entre nuvem pura, híbrido e Entra Domain Services não é binária nem definitiva. Muitas organizações começam híbridas, migram gradualmente aplicações para autenticação moderna e só então avaliam o descomissionamento do AD local. Outras descobrem que o Entra Domain Services resolve as dependências legadas e permite aposentar os controladores de domínio locais. O critério de escolha deve ser técnico, não aspiracional: o inventário de dependências dita o modelo, e não o contrário.
Também pesam fatores operacionais: uma empresa com equipe interna experiente em AD pode preferir manter o híbrido por mais tempo, enquanto uma organização que terceiriza a TI ou que perdeu o conhecimento interno sobre o diretório tende a se beneficiar do domínio gerenciado. O custo de manter servidores, licenças Windows Server, backups e patches de controladores de domínio é um componente relevante dessa equação — e frequentemente subestimado em comparações superficiais.
Quando o Entra Domain Services substitui controladores de domínio locais
O Entra Domain Services é a opção natural quando a empresa precisa de Kerberos, LDAP e autenticação integrada do Windows, mas não quer mais operar controladores de domínio físicos ou virtuais. O serviço replica automaticamente os dados entre dois controladores gerenciados, aplica patches de segurança e oferece backup integrado. Para aplicações legadas hospedadas em máquinas virtuais no Azure, o domínio gerenciado elimina a necessidade de VPN ou conectividade estendida com o datacenter local.
No entanto, o Entra Domain Services não é um substituto universal. Ele não suporta extensões de schema, não oferece privilégios de Domain Admin ou Enterprise Admin, e o acesso administrativo é limitado a uma OU gerenciada. Aplicações que exigem controle total sobre o diretório, como algumas soluções de gestão de identidade de terceiros ou sistemas legados com requisitos específicos de schema, não funcionam nesse modelo. O domínio gerenciado também impõe uma relação de confiança unidirecional com o Entra ID, o que limita cenários de autenticação complexos.
Quando o AD híbrido com Entra Connect é a única opção viável
O modelo híbrido se impõe quando a empresa mantém aplicações críticas que exigem AD local e não podem ser movidas para o Azure em curto prazo. Sistemas de automação industrial, aplicações bancárias legadas, infraestrutura de telefonia e soluções que dependem de certificados emitidos pela CA interna do AD são exemplos que mantêm o diretório local vivo por anos. Nesses cenários, o Entra Connect sincroniza identidades para a nuvem, permitindo que os mesmos usuários acessem tanto recursos locais quanto Microsoft 365 e SaaS.
O híbrido também é a única opção quando a organização precisa de coexistência prolongada entre dispositivos ingressados em domínio tradicional e dispositivos ingressados no Entra ID. A autenticação híbrida — com PHS (hash sync), PTA (pass-through) ou federação via AD FS — define como as credenciais são validadas, e cada método tem implicações de segurança e disponibilidade. O PHS é o mais simples e permite detecção de credenciais vazadas no Entra ID, enquanto o PTA mantém a validação de senha no AD local, útil para empresas com políticas rígidas de residência de credenciais.
Plano de migração em fases: do piloto à produção
Migrações de identidade não são projetos big-bang. A abordagem em fases reduz o risco de interrupção, permite validar cada componente antes de expor o próximo e cria janelas naturais de rollback. Um plano típico começa pela sincronização de identidades, evolui para dispositivos e políticas, migra aplicações para SSO e termina com o descomissionamento do AD local — que pode levar de seis meses a vários anos, dependendo da complexidade do ambiente.
Cada fase deve ter critérios de saída objetivos: percentual de usuários sincronizados sem erro, cobertura de políticas no Intune, número de aplicações migradas para autenticação moderna e zero eventos de autenticação legada nos últimos 90 dias, por exemplo. Sem esses critérios, o projeto avança por inércia e o descomissionamento final nunca acontece, deixando a empresa presa ao custo e ao risco de manter dois diretórios indefinidamente.
Fase 1: sincronização de identidades e autenticação na nuvem
A primeira fase instala e configura o Entra Connect (ou Cloud Sync) para sincronizar usuários, grupos e contatos do AD local para o Entra ID. A decisão sobre o método de autenticação — PHS, PTA ou federação — deve ser tomada aqui, considerando requisitos de latência, disponibilidade e conformidade. O PHS é recomendado para a maioria das organizações por sua simplicidade e por habilitar recursos de segurança como o Smart Lockout e a detecção de credenciais comprometidas.
É nesta fase que surgem os primeiros conflitos de atributos: UPNs inconsistentes, proxyAddresses duplicados, contas órfãs e objetos com âncoras de sincronização mal definidas. A correção desses problemas no AD local antes de ampliar a sincronização evita retrabalho em fases posteriores. O Entra Connect Health deve ser ativado desde o primeiro dia para monitorar a sincronização e alertar sobre falhas.
Fase 2: dispositivos, estações de trabalho e políticas de acesso
Com as identidades sincronizadas, a fase 2 aborda os dispositivos. Estações de trabalho podem ser ingressadas no Entra ID (Entra Joined) ou registradas (Entra Registered), enquanto servidores legados permanecem no domínio local. O Intune assume o gerenciamento de políticas, e as GPOs relevantes são reescritas como políticas de conformidade e perfis de configuração. O SSO para aplicações modernas começa a funcionar de forma integrada para dispositivos ingressados na nuvem.
O acesso condicional do Entra ID entra em cena nesta fase, permitindo políticas baseadas em risco, localização, estado do dispositivo e autenticação multifator. Para empresas que lidam com dados sensíveis — como ambientes financeiros com transações Pix —, o acesso condicional é um dos ganhos de segurança mais imediatos da migração, pois centraliza políticas que antes estavam dispersas em GPOs, firewalls e configurações de aplicação.
Fase 3: aplicativos, SSO e federação (aposentando o AD FS)
A terceira fase migra aplicações de autenticação legada para SSO baseado em SAML ou OpenID Connect. Aplicações que suportam autenticação moderna são registradas no Entra ID e passam a receber tokens da nuvem, eliminando a dependência do AD FS. O AD FS, quando presente, é um dos componentes mais complexos de aposentar: exige mapeamento de todas as relying parties, migração de regras de claims e validação de cada aplicação em paralelo antes do corte.
Para aplicações que não suportam autenticação moderna, o Entra Application Proxy oferece acesso remoto seguro via nuvem, mantendo a autenticação legada no AD local. Essa abordagem reduz a exposição de servidores on-premises à internet e elimina a necessidade de VPN para aplicações web internas. Aplicações que exigem Kerberos podem ser movidas para máquinas virtuais no Azure com Entra Domain Services, encerrando a dependência de controladores de domínio locais para esses casos.
Fase 4: descomissionamento seguro do AD local
O descomissionamento é a fase mais negligenciada e a mais arriscada. Antes de desligar o último controlador de domínio, a empresa precisa comprovar que nenhuma aplicação, dispositivo ou serviço depende mais do AD local. Isso exige semanas ou meses de monitoramento dos logs de autenticação, buscando eventos de logon Kerberos, NTLM ou LDAP residuais. Qualquer evento de autenticação legada após a data de corte indica uma dependência não mapeada.
O processo formal de descomissionamento inclui: remover a sincronização do Entra Connect, converter usuários sincronizados para nuvem pura, transferir funções FSMO, revogar trusts, desativar a CA interna e, por fim, desligar os controladores de domínio. O ethical hacking pode validar a postura final do ambiente, simulando ataques que explorariam resquícios do AD desativado. Manter um backup offline do AD por um período de quarentena é uma prática recomendada para cenários de rollback emergencial.
Segurança durante a migração: os riscos que os guias ignoram
A janela de migração é um período de vulnerabilidade aumentada. A coexistência entre AD local e Entra ID cria superfícies de ataque que não existiam em nenhum dos dois mundos isoladamente: o Entra Connect concentra credenciais de sincronização, contas privilegiadas locais continuam ativas enquanto a nuvem assume funções de autenticação, e a equipe de segurança precisa monitorar dois ambientes com modelos de auditoria distintos. Atacantes sofisticados conhecem essa janela e a exploram ativamente.
Guias genéricos de migração focam em passos técnicos e ignoram a necessidade de endurecer o AD local durante a transição. A realidade é que o AD on-premises permanece como alvo de alto valor enquanto existir, especialmente em organizações do setor financeiro. A migração para o Azure não reduz automaticamente o risco do AD local — na verdade, pode aumentá-lo se a atenção da equipe se voltar integralmente para a nuvem e o diretório legado ficar sem monitoramento adequado.
Contas privilegiadas, tiering administrativo e proteção do Entra Connect
O Entra Connect armazena credenciais com privilégios elevados no AD local para executar a sincronização. Se essas credenciais forem comprometidas, o atacante ganha um caminho direto para o diretório local e, potencialmente, para a nuvem. A conta de sincronização deve ser tratada como Tier 0 — o nível mais alto de privilégio — e protegida com os mesmos controles aplicados a administradores de domínio: autenticação multifator, acesso restrito por IP, monitoramento contínuo e rotação de credenciais.
O tiering administrativo, formalizado pela Microsoft no modelo de Red Forest (ESAEs), separa contas e estações de trabalho por nível de privilégio. Durante a migração, o tiering precisa ser revisado: contas que administravam o AD local e agora administram o Entra ID devem ser segregadas, e o acesso entre nuvem e on-premises deve seguir o princípio do privilégio mínimo. Um teste de invasão focado em Microsoft 365 e Azure pode identificar caminhos de escalonamento entre os dois ambientes antes que um atacante o faça.
Ataques que se aproveitam da janela de migração (Golden Ticket, DCSync, Kerberoasting)
Três ataques merecem atenção especial durante a transição. O Golden Ticket explora o hash da conta KRBTGT do AD local para forjar tickets Kerberos com validade arbitrária — e permanece eficaz enquanto o AD local existir, independentemente do progresso da migração para a nuvem. O DCSync simula o comportamento de um controlador de domínio para extrair hashes de senha de qualquer conta, incluindo administradores. Já o Kerberoasting mira contas de serviço com SPNs, extraindo tickets que podem ser quebrados offline para revelar senhas fracas.
A migração para o Azure não elimina esses riscos; ela os concentra em um período de transição em que as defesas podem estar fragmentadas. A mitigação exige: rotação periódica da senha da KRBTGT (idealmente duas vezes, com intervalo), remoção de contas de serviço desnecessárias, uso de gMSAs para serviços compatíveis, monitoramento de eventos 4662 e 4769 no AD local, e detecção de padrões anômalos de replicação. O modelo Red Team/Blue Team é particularmente eficaz para validar essas defesas durante a janela de migração.
Monitoramento, auditoria e plano de recuperação do AD
O monitoramento durante a migração precisa cobrir os dois ambientes simultaneamente. No AD local, logs de segurança dos controladores de domínio, eventos de replicação e alterações em grupos privilegiados devem alimentar um SIEM ou ferramenta de auditoria. Na nuvem, o Microsoft Entra ID oferece logs de auditoria, logs de sign-in e o Entra ID Protection, que detecta riscos como viagem impossível, credenciais vazadas e uso de endereços IP anônimos.
O plano de recuperação do AD local deve ser revisado antes do início da migração, não depois. Backups regulares do System State, teste de restauração de controladores de domínio e um processo documentado de resposta a incidentes são pré-requisitos. Para organizações sujeitas a normas como a ISO 27001, a continuidade do serviço de identidade precisa estar operacional durante toda a transição.
Custos, licenciamento e esforço operacional comparados
Comparar o custo total dos três modelos exige ir além do preço das licenças. O AD local "gratuito" embute servidores físicos ou virtuais, licenças Windows Server, backups, energia, refrigeração, patches e horas de administração. O Entra ID cobra por usuário em tiers (Free, P1, P2), com o P1 sendo o mínimo recomendado para acesso condicional e o P2 adicionando o Identity Protection e o Privileged Identity Management. O Entra Domain Services é cobrado por hora de diretório provisionado, independentemente do número de usuários.
O esforço operacional varia drasticamente. Manter AD local exige administração de controladores, monitoramento de replicação, gestão de GPOs e resposta a incidentes de segurança legados. O Entra Domain Services elimina quase toda essa carga, mas introduz limitações funcionais que podem exigir reescrita de aplicações. O híbrido, por definição, soma os custos dos dois mundos — e, por isso, deve ser tratado como estado de transição, não como destino final.
- AD local: CAPEX de servidores + licenças Windows Server + horas de administração + custo de segurança legada.
- Entra ID puro: custo por usuário (P1/P2) + reescrita de aplicações legadas + migração de GPOs para Intune.
- Entra Domain Services: custo por hora de diretório + VMs no Azure + eventuais limitações funcionais.
- Híbrido: soma de AD local + Entra ID + complexidade operacional de dois diretórios.
Para empresas que avaliam montar um business case para serviços gerenciados de TI, o custo de identidade deve entrar na conta como componente de infraestrutura crítica. A decisão de migrar sozinho ou com parceiro também afeta o TCO: projetos de identidade mal executados geram retrabalho, indisponibilidade e risco de segurança que raramente aparecem em planilhas iniciais.
Erros comuns em migrações de AD para o Azure e como evitá-los
O primeiro erro é migrar sem inventário. Decidir pelo Entra ID puro sem mapear dependências legadas resulta em aplicações fora do ar no piloto e pressão para reverter a migração. O segundo é subestimar a complexidade das GPOs: reescrever políticas de segurança no Intune é um projeto em si, com curva de aprendizado e risco de lacunas de proteção durante a transição. O terceiro é manter o AD local ativo sem monitoramento adequado, assumindo que a nuvem "resolveu" a segurança.
Outro erro frequente é tratar o Entra Connect como componente periférico, sem proteção de Tier 0 para a conta de sincronização. A conta do Entra Connect, se comprometida, permite manipular identidades nos dois ambientes. Também é comum ignorar a higiene de atributos: UPNs inconsistentes, contas duplicadas e grupos aninhados mal estruturados são importados para a nuvem e geram problemas de autorização que só aparecem quando uma aplicação nega acesso indevidamente — ou pior, concede acesso além do necessário.
- Migrar sem inventário de dependências legadas (Kerberos, LDAP, NTLM).
- Subestimar o esforço de reescrever GPOs no Intune.
- Abandonar o monitoramento do AD local durante a transição.
- Tratar a conta do Entra Connect sem proteção de Tier 0.
- Ignorar a higiene de atributos antes da sincronização.
- Manter o híbrido indefinidamente sem critérios de saída.
O erro final — e talvez o mais comum em empresas que terceirizam a TI — é não documentar o estado do ambiente durante a migração. Quando a equipe interna muda ou o contrato com o provedor é encerrado, a organização descobre que ninguém sabe exatamente quais dependências ainda existem no AD local. A documentação contínua, com inventário atualizado de aplicações, contas de serviço e políticas, é o que permite terceirizar a TI mantendo o controle do ambiente sem herdar uma caixa-preta.
Checklist final: perguntas para responder antes de desligar o último controlador de domínio
Desligar o último controlador de domínio é um ponto sem retorno. Antes desse passo, cada uma das perguntas abaixo precisa ter resposta documentada e validada por evidências — logs, testes e aprovações formais. A ausência de resposta não significa "sim"; significa que a dependência ainda não foi descartada e o descomissionamento deve ser adiado.
- Todas as aplicações que usavam Kerberos, LDAP ou NTLM foram migradas ou desativadas?
- Os logs de autenticação dos últimos 90 dias mostram zero eventos legados?
- Todas as GPOs críticas foram reescritas no Intune e validadas em produção?
- A CA interna do AD foi desativada e os certificados migrados para uma autoridade alternativa?
- Os trusts entre florestas e domínios foram removidos formalmente?
- As contas de serviço legadas foram migradas para gMSAs ou identidades gerenciadas?
- O Entra Connect foi removido e os usuários convertidos para nuvem pura?
- Existe backup offline do AD para rollback emergencial por um período de quarentena?
- O plano de resposta a incidentes foi atualizado para o novo modelo de identidade?
- As equipes de segurança e operação foram treinadas no ambiente pós-migração?
Responder a essas perguntas com rigor é o que separa uma migração concluída de uma migração abandonada no meio do caminho. O AD local desligado sem validação de dependências residuais é um incidente em potencial; o AD local desligado após um checklist documentado é o encerramento de um ciclo — e o início de uma operação de identidade verdadeiramente nativa da nuvem.
