Considerações de design de rede virtual e opções de configuração para os Serviços de Domínio do Microsoft Entra
Os Serviços de Domínio Microsoft Entra fornecem serviços de autenticação e gerenciamento para outros aplicativos e cargas de trabalho. A conectividade de rede é um componente fundamental. Sem recursos de rede virtual configurados corretamente, os aplicativos e cargas de trabalho não podem se comunicar e usar os recursos fornecidos pelos Serviços de Domínio. Planeje seus requisitos de rede virtual para garantir que os Serviços de Domínio possam atender seus aplicativos e cargas de trabalho conforme necessário.
Este artigo descreve considerações de design e requisitos para uma rede virtual do Azure para dar suporte aos Serviços de Domínio.
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 dos Serviços de Domínio, use uma rede virtual e uma sub-rede do Azure. Idealmente, o domínio gerenciado deve ser 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 aplicativos leves. Uma rede virtual separada para cargas de trabalho de aplicativos maiores ou complexas, emparelhada à rede virtual dos Serviços de Domínio, geralmente é o design mais apropriado.
Outras opções de design são válidas, desde que você atenda aos requisitos descritos nas seções a seguir para a rede virtual e a sub-rede.
Ao projetar a rede virtual para Serviços de Domínio, as seguintes considerações se aplicam:
- Os Serviços de Domínio 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 ofereça suporte aos Serviços de Domínio.
- 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 da sub-rede de rede virtual do domínio gerenciado. Você pode usar 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 diferentes daqueles fornecidos pelo domínio gerenciado.
- Os Serviços de Domínio fornecem o 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.
- Não é possível usar configurações personalizadas do servidor DNS para direcionar consultas de outros servidores DNS, inclusive em VMs. Os recursos na rede virtual devem usar o serviço DNS fornecido pelo domínio gerenciado.
Importante
Não é possível mover os Serviços de Domínio para uma rede virtual diferente depois de ativar o serviço.
Um domínio gerenciado se conecta a uma sub-rede em uma rede virtual do Azure. Projete esta sub-rede para Serviços de Domínio com as seguintes considerações:
Um domínio gerido tem de ser implementado na sua própria sub-rede. Não há suporte para o uso de uma sub-rede, sub-rede de gateway ou configurações de gateways remotos existentes no emparelhamento de rede virtual.
Durante a implementação de um domínio gerido, é criado um grupo de segurança de rede. Este grupo de segurança de rede contém as regras necessárias para a comunicação correta do serviço.
- Não crie ou 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. Certifique-se de que o intervalo de endereços IP da sub-rede pode fornecer esse número de endereços.
- Restringir os endereços IP disponíveis pode impedir que o domínio gerenciado mantenha dois controladores de domínio.
Nota
Você não deve usar endereços IP públicos para redes virtuais e suas sub-redes devido aos seguintes problemas:
Escassez do endereço IP: Os endereços IP públicos IPv4 são limitados e a sua procura excede frequentemente 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, os seus dispositivos podem ficar 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 requer lidar com intervalos de IP externos e garantir a segmentação e a segurança adequadas da rede.
É altamente recomendável usar endereços IP privados. Se utilizar um IP público, certifique-se de que é o proprietário/utilizador dedicado dos IPs escolhidos no intervalo público que 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 dos Serviços de Domínio
Conforme observado na seção anterior, você só pode 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 hospedam as cargas de trabalho do aplicativo à rede virtual do domínio gerenciado.
Você pode conectar cargas de trabalho de aplicativos hospedadas em outras redes virtuais do Azure usando um dos seguintes métodos:
- Peering de rede virtual
- Rede privada virtual (VPN)
Peering 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 redes virtuais dentro da mesma região do Azure, e ao emparelhamento de rede virtual global, que conecta redes virtuais em diferentes regiões do Azure. Essa flexibilidade permite que você implante um domínio gerenciado com suas cargas de trabalho de aplicativos em várias redes virtuais, independentemente de seus locais regionais.
Para obter mais informações, consulte Visão geral do emparelhamento de rede virtual do Azure.
Rede Privada Virtual (VPN)
Você pode conectar uma rede virtual a outra rede virtual (VNet-to-VNet) da mesma forma que pode configurar uma rede virtual para um local de site local. Ambas as conexões usam um gateway VPN para criar um túnel seguro usando IPsec/IKE. Este modelo de conexão permite implantar o domínio gerenciado em uma rede virtual do Azure e, em seguida, conectar locais locais ou outras nuvens.
Para obter mais informações sobre como usar a rede virtual privada, leia Configurar uma conexão de gateway VPN VNet-to-VNet usando o centro de administração do Microsoft Entra.
Resolução de nomes ao conectar redes virtuais
As redes virtuais conectadas à rede virtual do domínio gerenciado normalmente têm suas próprias configurações de DNS. Quando você conecta redes virtuais, ele não configura automaticamente a resolução de nomes 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 suporta as redes virtuais de conexão ou usando os mesmos endereços IP DNS da rede virtual do domínio gerenciado.
Recursos de rede usados pelos Serviços de Domínio
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 pelos Serviços de Domínio. Se os recursos de rede forem bloqueados, eles não poderão ser excluídos. Quando os controladores de domínio precisam ser reconstruídos nesse caso, novos recursos de rede com endereços IP diferentes precisam ser criados.
Recurso do Azure | Description |
---|---|
Placa de interface de rede | Os Serviços de Domínio hospedam o domínio gerenciado em dois controladores de domínio (DCs) que são 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 | Os Serviços de Domínio se comunicam com o serviço de sincronização e gerenciamento usando um endereço IP público SKU padrão. Para obter mais informações sobre endereços IP públicos, consulte Tipos de endereços IP e métodos de alocação no Azure. |
Balanceador de carga padrão do Azure | Os Serviços de Domínio usam um balanceador de carga SKU padrão para NAT (conversão de endereços de rede) e balanceamento de carga (quando usado com LDAP seguro). Para obter mais informações sobre os balanceadores de carga do Azure, consulte O que é o Azure Load Balancer? |
Regras de conversão de endereços de rede (NAT) | Os Serviços de Domínio criam e usam duas regras NAT de entrada no balanceador de carga para comunicação remota segura do PowerShell. Se um balanceador de carga SKU padrão for usado, ele também terá uma regra NAT de saída. Para o balanceador de carga 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 pelos Serviços de Domínio, 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 de Serviços de Domínio.
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 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 com 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 está associado à sub-rede de rede virtual na qual 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.
Conectividade de entrada
As seguintes regras de entrada do grupo de segurança de rede 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 de rede virtual do seu domínio gerenciado.
Origem | Etiqueta de serviço de origem | Intervalo de portas de origem | Destino | Serviço | Intervalos de portas de destino | Protocolo | Ação | Necessário | Propósito |
---|---|---|---|---|---|---|---|---|---|
Etiqueta de serviço | AzureActiveDirectoryDomainServices | * | Qualquer | WinRM | 5986 | TCP | Permitir | Sim | Gestão do seu domínio. |
Etiqueta de serviço | CorpNetSaw | * | Qualquer | RDP | 3389 | TCP | Permitir | 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 de grupo de segurança de rede para CorpNetSaw deve ser adicionada usando o PowerShell.
Os Serviços de Domínio também dependem 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 repliquem corretamente, bem como permitam a associaçã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 o Windows, consulte Visão geral do serviço e requisitos de porta de rede para Windows.
A regra AllowAzureLoadBalancerInBound também é necessária para que o serviço possa se comunicar corretamente através do balanceador de carga para gerenciar os DCs. Esse grupo de segurança de rede protege os Serviços de Domínio 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árias usando o Azure PowerShell.
Aviso
Quando você associa um grupo de segurança de rede mal configurado ou uma tabela de rotas definida pelo usuário à sub-rede na qual o domínio gerenciado é 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 interromper a sincronização, a aplicação de patches ou o gerenciamento.
Se você usar LDAP seguro, poderá adicionar a regra de porta TCP 636 necessária para permitir o tráfego externo, se necessário. Adicionar esta regra não coloca as regras do grupo de segurança de rede num 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 bloqueadas de atualizações ou gerenciamento por um grupo de segurança de rede configurado incorretamente ou tabela de rotas definida pelo usuário. Uma configuração de rede quebrada também pode impedir a aplicação de patches de segurança.
Conectividade de saída
Para conectividade de saída, você pode manter AllowVnetOutbound e AllowInternetOutBound ou restringir 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.
Certifique-se de que nenhum outro NSG com prioridade mais alta negue a conectividade de saída. Se a conectividade de saída for negada, a replicação não funcionará entre conjuntos de réplicas.
Número da porta de saída | Protocolo | Origem | Destino | Ação | Necessário | Propósito |
---|---|---|---|---|---|---|
443 | TCP | Qualquer | AzureActiveDirectoryDomainServices | Permitir | Sim | Comunicação com o serviço de gestão dos Serviços de Domínio Microsoft Entra. |
443 | TCP | Qualquer | AzureMonitor | Permitir | Sim | Monitorização das máquinas virtuais. |
443 | TCP | Qualquer | Armazenamento | Permitir | Sim | Comunicação com o Armazenamento do Azure. |
443 | TCP | Qualquer | Microsoft Entra ID | Permitir | Sim | Comunicação com o Microsoft Entra ID. |
443 | TCP | Qualquer | GuestAndHybridManagement | Permitir | Sim | Gestão automatizada de patches de segurança. |
Nota
As tags AzureUpdateDelivery e AzureFrontDoor.FirstParty foram preteridas a partir de 1º de julho de 2024. Os Serviços de Domínio Microsoft Entra gerenciam o WindowsUpdate de forma independente, o que elimina a necessidade dessas tags. Os ajustes do NSG não são necessários, com ou sem tags obsoletas.
Porta 5986 - gerenciamento usando comunicação remota do PowerShell
- Usado para executar tarefas de gerenciamento usando a comunicação remota do PowerShell em seu domínio gerenciado.
- Sem acesso a essa porta, seu domínio gerenciado não pode ser atualizado, configurado, copiado ou monitorado.
- Você pode restringir o acesso de entrada a essa porta à marca de serviço AzureActiveDirectoryDomainServices .
Porta 3389 - gerenciamento usando área de trabalho remota
- Usada 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 tag de serviço CorpNetSaw para restringir ainda mais o tráfego.
- Esta etiqueta de serviço permite que apenas estações de trabalho de acesso seguro na rede corporativa da Microsoft usem a área de trabalho remota para o domínio gerenciado.
- O acesso só é permitido com justificativa comercial, como para cenários de gerenciamento ou solução de problemas.
- Esta regra pode ser definida como Negar e apenas como Permitir quando necessário. A maioria das tarefas de gerenciamento e monitoramento é executada usando a comunicação remota do PowerShell. O RDP só é usado no caso raro em que a Microsoft precisa se conectar remotamente ao seu domínio gerenciado para solução de problemas avançada.
Não é possível selecionar manualmente a tag 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 permita 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 utilizador
As rotas definidas pelo usuário não são criadas por padrão e não são necessárias para que os Serviços de Domínio funcionem 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 os Serviços de Domínio 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 respetivas tags de serviço do Azure para a sub-rede do domínio gerenciado. Para obter mais informações sobre tags de serviço e seu endereço IP associado, consulte Intervalos de IP do Azure e Tags de Serviço - Nuvem Pública.
Atenção
Esses intervalos de IP do datacenter do Azure podem ser alterados sem aviso prévio. Certifique-se de que tem processos para validar que tem os endereços IP mais recentes.
Próximos passos
Para obter mais informações sobre alguns dos recursos de rede e opções de conexão usados pelos Serviços de Domínio, consulte os seguintes artigos: