Ordem de replicação dos objetos

Introdução

Fala pessoal! Recentemente realizar um estudo para mover um conjunto de aplicações legadas — cheias de dependências de Kerberos, NTLM e GPO — para o Azure, sem manter aquele par de Domain Controllers IaaS que sempre acaba virando débito técnico. A resposta foi o Microsoft Entra Domain Services (o velho conhecido Azure AD Domain Services / AADS).

Neste artigo compartilho o passo a passo que uso em projetos reais: da arquitetura de rede ao domain join, passando pelas armadilhas que só aparecem na hora do deploy. Parte do conteúdo foi organizada com apoio do GitHub Copilot, mas cada recomendação vem de campo — tenant real, VNet real e aquela ligação às 2h da manhã quando o DNS decidiu não resolver.

💡 NOTA: Se você já opera um domínio on-premises com AD DS clássico, encare o AADS como um domínio gerenciado read-mostly: você ganha Kerberos/NTLM/LDAP/GPO, mas abre mão de Domain Admin e de mudanças de schema.

1. O que é o Entra Domain Services e para quem serve

O Entra ID (antigo Azure AD) é excelente para autenticação moderna: OAuth 2.0, OIDC, SAML, MFA, Conditional Access. Só que aplicações legadas geralmente não falam nenhum desses protocolos — elas exigem Kerberos, NTLM, LDAP simples e Group Policy. É aí que o AADS entra em cena.

O AADS provisiona dois controladores de domínio gerenciados pela Microsoft dentro da sua VNet, sincronizados com o seu tenant Entra ID. Você não enxerga essas VMs, não faz patching, não configura replicação — mas as máquinas da sua VNet conseguem fazer domain join tradicional, aplicar GPO e autenticar via Kerberos.

Quando o AADS é a escolha certa

• Lift-and-shift de aplicações legadas que exigem domain join (SQL Server com autenticação integrada, file servers, aplicações .NET Framework antigas).
• Migração de file servers com permissões NTFS baseadas em SIDs de domínio.
• Ambientes AVD (Azure Virtual Desktop) quando não há AD DS on-premises via VPN/ExpressRoute.
• Redução de OPEX: eliminar 2 VMs de DC IaaS + backup + monitoração + patching.
• Aplicações que exigem LDAP (LDAPS opcional) para autenticação de usuários do Entra ID.

Quando o AADS não é a resposta

• Você precisa de trust bidirecional com o AD on-premises (o AADS suporta apenas forest trust unidirecional de saída, em SKUs Enterprise/Premium).
• Sua aplicação exige alterações de schema ou classes customizadas.
• Você depende de Domain Admin ou Enterprise Admin para operar (não existe no AADS).
• Só há aplicações modernas (OAuth/OIDC) — nesse caso, Entra ID puro basta.

Entra ID vs. Entra Domain Services vs. AD DS on-premises

2. Requisitos de rede e pré-requisitos

A parte mais subestimada — e a que mais dá dor de cabeça depois. O AADS não permite mudar a VNet ou a subnet depois do deploy sem recriar o domínio. Então, planeje com carinho.

Tabela de pré-requisitos

NSG: o que liberar e o que não bloquear

A Microsoft mantém uma NSG default gerenciada na sub-rede do AADS. Não apague, não substitua, e cuidado com Azure Policy que force uma NSG customizada nessa subnet — já vi cliente derrubar o domínio inteiro assim.

⚠️ ATENÇÃO: Se você precisar customizar a NSG, mantenha as regras AllowSyncWithAzureAD, AllowRD, AllowPSRemoting e AllowPortIndexed intactas. Bloquear qualquer uma delas quebra a sincronização com o tenant.

Rotas padrão (UDR): armadilha clássica

Se sua VNet tem rota 0.0.0.0/0 apontando para um Azure Firewall ou NVA, o tráfego de gerência da Microsoft para os DCs gerenciados pode ser bloqueado. Solução: crie uma UDR específica para a subnet do AADS com next hop = Internet para os prefixos de gerência do Azure, ou publique exceções no firewall para os service tags AzureActiveDirectoryDomainServices e AzureUpdateDelivery.

3. Grupo AAD DC Administrators

Como não existe Domain Admin no AADS, a Microsoft criou um grupo específico no Entra ID chamado AAD DC Administrators. Membros desse grupo ganham privilégios administrativos nas VMs unidas ao domínio gerenciado — inclusive para editar GPOs no console Group Policy Management.

💡 NOTA: O grupo é criado automaticamente no primeiro deploy. Adicione ali apenas as contas administrativas dedicadas (idealmente com PIM/eligibility). Nunca coloque usuários finais.

Passos rápidos:

1. Portal Entra ID → Groups → busque por AAD DC Administrators.
2. Adicione o(s) usuário(s) que serão administradores do domínio gerenciado.
3. Se o usuário for cloud-only, force um reset de senha para que o hash Kerberos/NTLM seja gerado.

4. Provisionamento do serviço

Passo 1 — Criar o Managed Domain no portal

1. Portal do Azure → Create a resource → busque por Microsoft Entra Domain Services.
2. Selecione Subscription, Resource Group e Region.
3. No campo DNS domain name, informe um domínio roteável de sua propriedade (ex: aadds.desdentrue.store).
4. Escolha o SKU: Standard, Enterprise (Default) ou Premium. Standard atende a maioria dos cenários lift-and-shift.
5. Escolha o tipo de Forest: User (padrão, sincroniza usuários e grupos do tenant) ou Resource (apenas SKU Premium, para cenários de trust com AD on-prem).

Clique em OK para confirmar

Passo 2 — Networking

1. Selecione a VNet e a subnet dedicada (mínimo /27).
2. Se a VNet ainda não existe, crie durante o wizard — mas prefira criar antes, em IaC (Bicep/Terraform), para não deixar recurso “órfão” de tag e governança.

Passo 3 — Administração e sincronização

1. Confirme que o grupo AAD DC Administrators será criado (ou já existe).
2. Escolha o escopo de sincronização: All (recomendado para começar) ou Scoped (grupos específicos — útil em tenants grandes).
3. Usuário:

4. Grupo

Passo 4 — Revisar e criar

⚠️ ATENÇÃO — TEMPO DE PROVISIONAMENTO: Conforme a documentação oficial da Microsoft, a criação do managed domain leva em média 1 a 2 horas. Em regiões com alta demanda já vi levar mais. Não cancele nem tente recriar durante esse período.

Todos os recursos criados

5. DNS e conectividade

Ao final do provisionamento, o AADS expõe dois endereços IP na sub-rede escolhida — são os endpoints dos controladores de domínio gerenciados. Sem apontar o DNS da VNet para esses IPs, nenhuma VM conseguirá localizar o domínio.

Passos

1. Portal → recurso do Entra Domain Services → aba Properties.
2. Anote os dois IPs em IP address on virtual network.
3. Portal → sua Virtual Network → DNS servers → selecione Custom.
4. Cole os dois IPs do AADS.
5. Salve. Reinicie ou renove o DHCP das VMs já provisionadas para pegarem os novos DNS.

💡 DICA CLI: Para automatizar:

az network vnet update \
  --resource-group rg-aadds \
  --name vnet-aadds \
  --dns-servers 10.0.2.4 10.0.2.5

6. Gerenciamento hands-on: VM de gerenciamento

Como você não tem acesso direto aos DCs gerenciados, o padrão é provisionar uma VM Windows Server dedicada à administração — pense nela como sua “jump box” de identidade.

6.1 Provisionamento da VM

• Crie uma VM Windows Server 2025 Datacenter em uma sub-rede diferente da do AADDS, na mesma VNet, neste caso na sub-prod .

• Use tamanho enxuto: Standard_B2s já resolve para RSAT + GPMC.

• Habilite Azure Bastion ou acesso via Just-in-Time (Defender for Cloud) — nada de RDP aberto na Internet.
• Confirme que a VM está pegando os DNS customizados (ipconfig /all).

6.2 Domain Join

1. Faça logon local na VM com a conta admin local.
2. Painel do Sistema → Rename this PC (advanced) → Change….
3. Selecione Domain e informe o FQDN do managed domain (ex: aadds.desdentrue.store).
4. Ao pedir credenciais, use uma conta que esteja no grupo AAD DC Administrators e que já tenha resetado a senha após o AADS ser habilitado.

usuário exemplo: admin.aadds + senha

1. Reinicie a VM. No próximo logon, use o formato DOMINIO\usuario ou UPN.

⚠️ ATENÇÃO: Se o join falhar com “An Active Directory Domain Controller could not be contacted”, 99% das vezes é DNS. Rode nslookup dominio.com.br e confirme que resolve para os IPs do AADS.

6.3 Instalação do RSAT (ferramentas administrativas)

Com a VM no domínio, instale o RSAT via PowerShell (como administrador):

Install-WindowsFeature -Name GPMC, RSAT-AD-Tools, RSAT-DNS-Server -IncludeManagementTools

Isso habilita:

• Active Directory Users and Computers (ADUC) — leitura dos usuários/grupos sincronizados;

6.4 GPOs no AADS: o que muda

O AADS entrega duas GPOs pré-criadas (AADDC Users GPO e AADDC Computers GPO), aplicadas às OUs correspondentes. Você pode:

• ✅ Criar novas GPOs e linká-las às OUs AADDC Users e AADDC Computers;
• ✅ Criar OUs customizadas dentro do domínio para segmentar workloads;
• ❌ Não modificar OUs de sistema (AADDSDomainAdmin, etc.);
• ❌ Não aplicar GPO no nível do domínio raiz.

DNS Manager — visualização da zona do domínio gerenciado

7. Deep dive: os blocos de configuração que importam

8. Troubleshooting: os erros que aparecem 90% das vezes

9. Limitações e armadilhas que valem estar no seu radar

• Sem Domain Admin / Enterprise Admin: você não sobe DC adicional, não altera FSMO, não faz seize.
• Schema fixo: nada de estender atributos para aplicações que exigem isso.
• Uma única floresta, uma única região por managed domain no SKU Standard.
• Trust apenas outbound e apenas em SKU Enterprise/Premium — se você precisa de trust bidirecional com AD on-prem, o AADS não atende.
• Sincronização é unidirecional: mudanças feitas no AADS (ex: alterar um atributo via ADUC) não voltam para o Entra ID. O tenant é a fonte da verdade.
• Não pode ser migrado entre VNets/subnets: mudança implica delete + recreate + rejoin de todas as VMs.
• Não tem backup nativo gerenciado pelo cliente. A Microsoft mantém redundância interna, mas você não tem “System State backup” para restore point-in-time.

10. Boas práticas de produção

• 🔐 PIM + Conditional Access no grupo AAD DC Administrators — ele é o novo “Domain Admin”.
• 🌐 Nome de domínio DNS roteável e de sua propriedade — evite onmicrosoft.com e .local.
• 🧱 Sub-rede dedicada, sem NSG customizada, sem UDR que force egress via firewall.
• 📊 Diagnostic settings do AADS enviando para Log Analytics — monitore Account Logon, Account Management e Policy Change.
• 🔔 Notification recipients com a DL do time de identidade + integração com Service Health alerts.
• 🧪 Domain controller-less testing: mantenha uma VM de gerenciamento de baixo custo com RSAT sempre pronta — nada pior que descobrir que precisa de GPMC em plena madrugada.
• 💰 Custo: o SKU Standard fica em torno de US$ 110/mês por managed domain (varia por região). Compare com o custo de manter 2 DCs IaaS + backup + Defender + patching — quase sempre vale a pena.
• 🔄 Sincronização: comece com All e mude para Scoped só se realmente precisar segmentar. Trocar o modo exige recriação em algumas configurações.

Conclusão

O Entra Domain Services é uma daquelas peças que passam despercebidas até você precisar mover uma aplicação legada para o Azure e perceber que não quer manter Domain Controllers IaaS. Quando bem planejado — VNet correta, DNS ajustado, grupo administrativo com PIM e monitoração ativa — ele entrega o “sabor” de AD DS clássico com uma fração do esforço operacional.

As armadilhas quase sempre são as mesmas: DNS não configurado, NSG customizada quebrando regras gerenciadas, UDR forçando tráfego pelo firewall e usuários cloud-only sem reset de senha. Se você tratar esses quatro pontos no dia zero, seu deploy passa suave.

Repositório e comunidade

Vou publicar no meu GitHub os templates Bicep e os scripts PowerShell para provisionamento automatizado do AADS + VM de gerenciamento com RSAT pré-instalado. Se este conteúdo te ajudou, deixa uma ⭐ no repo — isso ajuda demais na visibilidade e me motiva a publicar mais.

👉 github.com/ErickMedeiros

E se você tem cenário de AADS com armadilha diferente das que listei aqui, me chama no LinkedIn — quero muito ouvir.

Forte abraço pessoal 👊