Considerações sobre o projeto da rede virtual e opções de configuração para o Microsoft Entra Domain Services
O Microsoft Entra Domain Services fornece serviços de autenticação e gerenciamento para outros aplicativos e cargas de trabalho. A conectividade de rede é um componente fundamental. Sem os recursos de rede virtual configurados corretamente, os aplicativos e as cargas de trabalho não podem se comunicar e usar os recursos fornecidos pelo Domain Services. Planeje seus requisitos de rede virtual para garantir que o Domain Services possa atender seus aplicativos e cargas de trabalho conforme necessário.
Este artigo descreve as considerações e os requisitos de design para uma rede virtual do Azure para dar suporte ao Domain Services.
Design de rede virtual do Azure
Para fornecer conectividade de rede e permitir que aplicativos e serviços se autentiquem em um domínio gerenciado do Domain Services, você usa uma rede virtual do Azure e uma sub-rede. O ideal é que o domínio gerenciado seja implantado em sua própria rede virtual.
Você pode incluir uma sub-rede de aplicativo separada na mesma rede virtual para hospedar sua VM de gerenciamento ou cargas de trabalho de aplicativo leves. Uma rede virtual separada para cargas de trabalho de aplicativos maiores ou complexos, emparelhada com a rede virtual do Domain Services, geralmente é o design mais apropriado.
Outras opções de designs são válidas, desde que você atenda aos requisitos descritos nas seções a seguir para a rede virtual e a sub-rede.
Conforme você projeta a rede virtual para o Domain Services, as seguintes considerações se aplicam:
- Os Domain Services devem ser implantados na mesma região do Azure que sua rede virtual.
- No momento, você só pode implantar um domínio gerenciado por locatário do Microsoft Entra. O domínio gerenciado é implantado em uma única região. Certifique-se de criar ou selecionar uma rede virtual em uma região que dê suporte ao Domain Services.
- Considere a proximidade de outras regiões do Azure e as redes virtuais que hospedam suas cargas de trabalho de aplicativo.
- Para minimizar a latência, mantenha seus aplicativos principais próximos ou na mesma região que a sub-rede da rede virtual para seu domínio gerenciado. Você pode usar o emparelhamento de rede virtual ou conexões de rede virtual privada (VPN) entre redes virtuais do Azure. Essas opções de conexão são discutidas em uma seção a seguir.
- A rede virtual não pode depender de serviços DNS que não sejam os serviços fornecidos pelo domínio gerenciado.
- O Domain Services fornece seu próprio serviço DNS. A rede virtual deve ser configurada para usar esses endereços de serviço DNS. A resolução de nomes para namespaces adicionais pode ser realizada usando encaminhadores condicionais.
- Você não pode usar configurações personalizadas do servidor DNS para direcionar consultas de outros servidores DNS, incluindo em VMs. Os recursos na rede virtual devem usar o serviço DNS fornecido pelo domínio gerenciado.
Importante
Você não pode mover o Domain Services para uma rede virtual diferente depois que tiver habilitado o serviço.
Um domínio gerenciado se conecta a uma sub-rede em uma rede virtual do Azure. Crie essa sub-rede para o Domain Services com as seguintes considerações:
Um domínio gerenciado deve ser implantado em sua própria sub-rede. O uso de uma sub-rede, sub-rede de gateway ou configurações de gateways remotos existentes no emparelhamento de rede virtual não tem suporte.
Um grupo de segurança de rede é criado durante a implantação de um domínio gerenciado. Esse grupo de segurança de rede contém as regras necessárias para a comunicação correta do serviço.
- Não crie nem use um grupo de segurança de rede existente com suas próprias regras personalizadas.
Um domínio gerenciado requer de 3 a 5 endereços IP. Verifique se o intervalo de endereços IP da sub-rede pode fornecer esse número de endereços.
- A restrição dos endereços IP disponíveis pode impedir que o domínio gerenciado mantenha dois controladores de domínio.
Observação
Você não deve usar endereços IP públicos para redes virtuais e suas sub-redes devido aos problemas a seguir:
Escassez de endereço IP: os endereços IP públicos IPv4 são limitados e sua demanda geralmente excede a oferta disponível. Além disso, há IPs potencialmente sobrepostos com pontos de extremidade públicos.
Riscos de segurança: o uso de IPs públicos para redes virtuais expõe seus dispositivos diretamente à Internet, aumentando o risco de acesso não autorizado e possíveis ataques. Sem medidas de segurança adequadas, seus dispositivos podem se tornar vulneráveis a várias ameaças.
Complexidade: gerenciar uma rede virtual com IPs públicos pode ser mais complexo do que usar IPs privados, pois exige lidar com intervalos de IPs externos e garantir a segmentação e a segurança adequadas da rede.
É altamente recomendável usar endereços IP privados. Se você usar um IP público, certifique-se de que você é o proprietário/usuário dedicado dos IPs escolhidos no intervalo público que você escolheu.
O diagrama de exemplo a seguir descreve um design válido em que o domínio gerenciado tem sua própria sub-rede, há uma sub-rede de gateway para conectividade externa e as cargas de trabalho do aplicativo estão em uma sub-rede conectada dentro da rede virtual:
Conexões com a rede virtual do Domain Services
Conforme observado na seção anterior, só é possível criar um domínio gerenciado em uma única rede virtual no Azure, e apenas um domínio gerenciado pode ser criado por locatário do Microsoft Entra. Com base nessa arquitetura, talvez seja necessário conectar uma ou mais redes virtuais que hospedem suas cargas de trabalho de aplicativo à rede virtual do seu domínio gerenciado.
Você pode conectar cargas de trabalho de aplicativo hospedadas em outras redes virtuais do Azure usando um dos seguintes métodos:
- Emparelhamento de rede virtual
- Rede virtual privada (VPN)
Emparelhamento de rede virtual
O emparelhamento de rede virtual é um mecanismo que conecta duas redes virtuais por meio da rede de backbone do Azure, permitindo que recursos como máquinas virtuais (VMs) se comuniquem entre si diretamente usando endereços IP privados. O emparelhamento de rede virtual dá suporte ao emparelhamento regional, que conecta VNets na mesma região do Azure e ao emparelhamento de rede virtual global, que conecta VNets em diferentes regiões do Azure. Essa flexibilidade permite que você implante um domínio gerenciado com suas cargas de trabalho de aplicativo em várias redes virtuais, independentemente de suas localizações regionais.
Para obter mais informações, consulte Visão geral do emparelhamento de rede virtual.
VPN (rede virtual privada)
Você pode conectar uma rede virtual a outra rede virtual (VNet a VNet) da mesma maneira que pode configurar uma rede virtual para um site local. Os dois tipos de conexão usam um gateway de VPN para criar um túnel seguro usando IPsec/IKE. Esse modelo de conexão permite implantar o domínio gerenciado em uma rede virtual do Azure e, em seguida, conectar locais ou outras nuvens.
Para obter mais informações sobre como usar a rede virtual privada, leia Configurar uma conexão de gateway de VPN de VNet a VNet usando o centro de administração do Microsoft Entra.
Resolução de nomes ao conectar redes virtuais
Normalmente, as redes virtuais conectadas à rede virtual do domínio gerenciado têm suas próprias configurações de DNS. Quando você conecta redes virtuais, a resolução de nomes não é configurada automaticamente para a rede virtual de conexão para resolver os serviços fornecidos pelo domínio gerenciado. A resolução de nomes nas redes virtuais de conexão deve ser configurada para permitir que as cargas de trabalho do aplicativo localizem o domínio gerenciado.
Você pode habilitar a resolução de nomes usando encaminhadores DNS condicionais no servidor DNS que dão suporte à conexão de redes virtuais ou usando os mesmos endereços IP DNS da rede virtual do domínio gerenciado.
Recursos de rede usados pelo Domain Services
Um domínio gerenciado cria alguns recursos de rede durante a implantação. Esses recursos são necessários para a operação e o gerenciamento bem-sucedidos do domínio gerenciado e não devem ser configurados manualmente.
Não bloqueie os recursos de rede usados pelo Domain Services. Se os recursos de rede forem bloqueados, eles não poderão ser excluídos. Quando os controladores de domínio precisam ser recriados nesse caso, novos recursos de rede com endereços IP diferentes precisam ser criados.
| Recursos do Azure | Descrição |
|---|---|
| Placa de interface de rede | O Domain Services hospeda o domínio gerenciado em dois controladores de domínio (DCs) executados no Windows Server como VMs do Azure. Cada VM tem uma interface de rede virtual que se conecta à sua sub-rede de rede virtual. |
| Endereço IP público padrão dinâmico | O Domain Services comunica-se com o serviço de sincronização e de gerenciamento usando um endereço IP público do SKU Standard. Para obter mais informações sobre endereços IP públicos, consulte Tipos de endereço IP e métodos de alocação no Azure. |
| Balanceador de carga padrão do Azure | O Domain Services usa um balanceador de carga SKU Standard para NAT (conversão de endereços de rede) e balanceamento de carga (quando usado com o LDAP seguro). Para obter mais informações sobre balanceadores de carga do Azure, consulte O que é o Azure Load Balancer? |
| Regras NAT (conversão de endereços de rede) | O Domain Services cria e usa duas regras NAT de entrada no balanceador de carga para comunicação remota segura com o PowerShell. Se um balanceador de carga SKU Standard for usado, ele também terá uma regra NAT de saída. Para o balanceador de carga de SKU Básico, nenhuma regra NAT de saída é necessária. |
| Regras do balanceador de carga | Quando um domínio gerenciado é configurado para LDAP seguro na porta TCP 636, três regras são criadas e usadas em um balanceador de carga para distribuir o tráfego. |
Aviso
Não exclua nem modifique nenhum recurso de rede criado pelo Domain Services, como configurar manualmente o balanceador de carga ou as regras. Se você excluir ou modificar qualquer um dos recursos de rede, poderá ocorrer uma interrupção do serviço do Domain Services.
Grupos de segurança de rede e portas necessárias
Um NSG (grupo de segurança de rede) contém uma lista de regras que permitem ou negam o tráfego de rede em uma rede virtual do Azure. Quando você implanta um domínio gerenciado, um grupo de segurança de rede é criado contendo um conjunto de regras que permitem que o serviço forneça funções de autenticação e gerenciamento. Esse grupo de segurança de rede padrão é associado à sub-rede da rede virtual na qual o seu domínio gerenciado está implantado.
As seções a seguir abrangem grupos de segurança de rede e requisitos de porta de entrada e saída.
Conexões de entrada
As regras de entrada do grupo de segurança de rede a seguir são necessárias para que o domínio gerenciado forneça serviços de autenticação e gerenciamento. Não edite nem exclua essas regras de grupo de segurança de rede para a sub-rede da rede virtual do domínio gerenciado.
| Fonte | Marca de serviço de origem | Intervalos de portas de origem | Destino | Serviço | Intervalos de portas de destino | Protocolo | Ação | Obrigatório | Finalidade |
|---|---|---|---|---|---|---|---|---|---|
| Marca de serviço | AzureActiveDirectoryDomainServices | * | Qualquer | WinRM | 5986 | TCP | Allow | Sim | Gerenciamento do seu domínio. |
| Marca de serviço | CorpNetSaw | * | Qualquer | RDP | 3389 | TCP | Allow | Opcional | Depuração para suporte |
Observe que a marca de serviço CorpNetSaw não está disponível usando o centro de administração do Microsoft Entra e a regra do grupo de segurança de rede para CorpNetSaw deve ser adicionada usando o PowerShell.
Domain Services também depende das regras de segurança padrão AllowVnetInBound e AllowAzureLoadBalancerInBound.
A regra AllowVnetInBound permite todo o tráfego dentro da VNet, o que permite que os DCs se comuniquem e se repliquem corretamente, bem como permitem a junção de domínio e outros serviços de domínio aos membros do domínio. Para obter mais informações sobre as portas necessárias para Windows, consulte Visão geral do serviço e requisitos de porta de rede para o Windows.
A regra AllowAzureLoadBalancerInBound também é necessária para que o serviço possa se comunicar corretamente pelo loadbalancer para gerenciar os DCs. Esse grupo de segurança de rede protege o Domain Services e é necessário para que o domínio gerenciado funcione corretamente. Não exclua este grupo de segurança de rede. O balanceador de carga não funcionará corretamente sem ele.
Se necessário, você pode criar o grupo de segurança de rede e as regras necessários usando o Azure PowerShell.
Aviso
Ao associar um grupo de segurança de rede configurado incorretamente ou uma tabela de rotas definida pelo usuário com a sub-rede na qual o domínio gerenciado está implantado, você pode interromper a capacidade da Microsoft de atender e gerenciar o domínio. A sincronização entre o locatário do Microsoft Entra e o domínio gerenciado também é interrompida. Siga todos os requisitos listados para evitar uma configuração sem suporte que possa prejudicar a sincronização, a aplicação de patch ou o gerenciamento.
Se você usar LDAP seguro, poderá adicionar a regra necessária da porta TCP 636 para permitir o tráfego externo, se necessário. A adição dessa regra não coloca as regras do grupo de segurança de rede em um estado sem suporte. Para obter mais informações, consulte Bloquear o acesso LDAP seguro pela Internet
O SLA do Azure não se aplica a implantações com bloqueio de atualização ou gerenciamento devido a um grupo de segurança de rede ou tabela de rotas definida pelo usuário configurados incorretamente. Uma configuração de rede interrompida também pode impedir a aplicação de patches de segurança.
Conectividade de saída
Para a conectividade de saída, mantenha AllowVnetOutbound e AllowInternetOutBound ou restrinja o tráfego de saída usando ServiceTags listadas na tabela a seguir. Se você usar o Log Analytics, adicione o EventHub aos destinos de saída.
Verifique se outros NSGs com prioridade mais alta negam a conectividade de Saída. Se a conectividade de Saída for negada, a replicação não funcionará entre os conjuntos de réplica.
| Número da porta de saída | Protocolo | Origem | Destino | Ação | Obrigatório | Finalidade |
|---|---|---|---|---|---|---|
| 443 | TCP | Qualquer | AzureActiveDirectoryDomainServices | Allow | Sim | Comunicação com o serviço de gerenciamento do Microsoft Entra Domain Services. |
| 443 | TCP | Qualquer | AzureMonitor | Allow | Sim | Monitoramento das máquinas virtuais. |
| 443 | TCP | Qualquer | Armazenamento | Allow | Sim | Comunicação com o Armazenamento do Azure. |
| 443 | TCP | Qualquer | ID do Microsoft Entra | Permitir | Sim | Comunicação com o Microsoft Entra ID. |
| 443 | TCP | Qualquer | GuestAndHybridManagement | Allow | Sim | Gerenciamento automatizado de patches de segurança. |
Observação
As marcas AzureUpdateDelivery e AzureFrontDoor.FirstParty foram preteridas a partir de 1º de julho de 2024. O Microsoft Entra Domain Services gerencia o WindowsUpdate de forma independente, o que remove a necessidade dessas marcas. Ajustes de NSG não são necessários, com ou sem marcas obsoletas.
Porta 5986 - gerenciamento usando a comunicação remota do PowerShell
- Usada para executar tarefas de gerenciamento por meio da comunicação remota do PowerShell no seu domínio gerenciado.
- Sem acesso a essa porta, o domínio gerenciado não pode ser atualizado, configurado, monitorado ou ter o backup feito.
- Você pode restringir o acesso de entrada a essa porta com a marca de serviço AzureActiveDirectoryDomainServices.
Porta 3389 - gerenciamento usando o desktop remoto
- São usados para conexões de área de trabalho remota com controladores de domínio em seu domínio gerenciado, essa porta não pode ser alterada ou encapsulada em outra porta.
- A regra de grupo de segurança de rede padrão usa a marca de serviço CorpNetSaw para restringir ainda mais o tráfego.
- Essa marca de serviço permite que apenas as estações de trabalho de acesso seguro na rede corporativa da Microsoft usem o desktop remoto para o domínio gerenciado.
- O acesso é permitido somente com justificativa comercial, como para cenários de gerenciamento ou de solução de problemas.
- Essa regra pode ser definida como Negar e somente ser definida como Permitir quando necessário. A maioria das tarefas de gerenciamento e monitoramento são executadas usando a comunicação remota do PowerShell. O RDP é usado apenas no caso raro de a Microsoft precisar se conectar remotamente ao seu domínio gerenciado para solução de problemas avançada.
Você não poderá selecionar manualmente a marca de serviço CorpNetSaw no portal se tentar editar essa regra de grupo de segurança de rede. Você deve usar o Azure PowerShell ou a CLI do Azure para configurar manualmente uma regra que usa a marca de serviço CorpNetSaw.
Por exemplo, você pode usar o seguinte script para criar uma regra que permite RDP:
Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange "3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup
Rotas definidas pelo usuário
As rotas definidas pelo usuário não são criadas por padrão e não são necessárias para que o Domain Services funcione corretamente. Se for necessário usar tabelas de rotas, evite fazer alterações na rota 0.0.0.0. As alterações nessa rota interrompem o Domain Services e colocam o domínio gerenciado em um estado sem suporte.
Você também deve rotear o tráfego de entrada dos endereços IP incluídos nas respectivas marcas de serviço do Azure para a sub-rede do domínio gerenciado. Para obter mais informações sobre marcas de serviço e seus endereços IP associados, consulte Intervalos de IP e marcas de serviço do Azure – Nuvem pública.
Cuidado
Esses intervalos de IP do datacenter do Azure podem ser alterados sem aviso prévio. Verifique se você tem processos para validar se tem os endereços IP mais recentes.
Próximas etapas
Para obter mais informações sobre alguns dos recursos de rede e opções de conexão usados pelo Domain Services, confira os seguintes artigos: