Esta arquitetura de referência mostra como criar um domínio separado do Active Directory no Azure considerado fidedigno pelos domínios na sua floresta do AD no local.
Transfira um ficheiro do Visio para a arquitetura "Floresta do AD DS".
O Active Directory Domain Services (AD DS) armazena informações de identidade numa estrutura hierárquica. O nó superior na estrutura hierárquica é conhecido como uma floresta. Uma floresta contém domínios, os quais contêm outros tipos de objetos. Esta arquitetura de referência cria uma floresta do AD DS no Azure com uma relação de confiança de saída unidirecional com um domínio no local. A floresta no Azure contém um domínio que não existe no local. Devido à relação de confiança, os inícios de sessão realizados nos domínios no local são fidedignos para aceder aos recursos no domínio separado do Azure.
Utilizações típicas desta arquitetura incluem manter a separação de segurança de objetos e identidades contidos na cloud e migrar domínios individuais do local para a cloud.
Para obter considerações adicionais, veja Escolher uma solução de integração do Active Directory no local com o Azure.
Arquitetura
A arquitetura é composta pelos seguintes componentes:
- Rede no local. A rede no local contém os seus próprios domínios e florestas do Active Directory.
- Servidores do Active Directory. Estes são os controladores de domínio que implementam serviços de domínio em execução como VMs na cloud. Estes servidores alojam uma floresta que contém um ou mais domínios, separados dos localizados no local.
- Confiança unidirecional. O exemplo no diagrama mostra uma confiança unidirecional entre o domínio no Azure e o domínio no local. Esta relação permite que os utilizadores no local acedam aos recursos no domínio no Azure, mas não o inverso.
- Sub-rede do Active Directory. Os servidores do AD DS estão alojados numa sub-rede separada. As regras do grupo de segurança de rede (NSG) protegem os servidores do AD DS e fornecem uma firewall contra o tráfego de origens inesperadas.
- Gateway do Azure. O gateway do Azure fornece uma ligação entre a rede no local e a VNet do Azure, que pode ser uma ligação VPN ou Azure ExpressRoute. Para obter mais informações, veja Ligar uma rede no local ao Azure com um gateway de VPN.
Recomendações
Para obter recomendações específicas sobre a implementação do Active Directory no Azure, veja Expandir Active Directory Domain Services (AD DS) para o Azure.
Confiança
Os domínios no local estão contidos numa floresta diferente dos domínios na cloud. Para ativar a autenticação de utilizadores no local na cloud, os domínios no Azure têm de confiar no domínio de início de sessão na floresta no local. De igual forma, se a cloud fornecer um domínio de início de sessão para utilizadores externos, poderá ser necessário que a floresta no local confie no domínio na cloud.
Pode estabelecer uma relação de confiança ao nível da floresta ao criar confianças de floresta ou ao nível do domínio ao criar confianças externas. Uma confiança ao nível da floresta cria uma relação entre todos os domínios nas duas florestas. Uma confiança ao nível do domínio externo apenas cria uma relação entre dois domínios especificados. Só deve criar confianças ao nível do domínio externo entre domínios em florestas diferentes.
As fidedignidades com um Active Directory no local são apenas unidirecionais (unidirecionais). Uma confiança unidirecional permite que os utilizadores num domínio ou numa floresta (conhecido como domínio ou floresta de entrada) acedam aos recursos contidos noutro domínio ou floresta (domínio ou floresta de saída).
A tabela seguinte resume as configurações de confiança para alguns cenários simples:
| Scenario | Confiança no local | Confiança na cloud |
|---|---|---|
| Os utilizadores no local precisam de acesso a recursos na cloud, mas não o contrário | Unidirecional, entrada | Unidirecional, saída |
| Os utilizadores na cloud precisam de acesso a recursos presentes no local, mas não o contrário | Unidirecional, saída | Unidirecional, entrada |
Considerações de escalabilidade
O Active Directory é automaticamente dimensionável para os controladores de domínio que fazem parte do mesmo domínio. Os pedidos são distribuídos por todos os controladores num domínio. Pode adicionar outro controlador de domínio e sincronizá-lo automaticamente com o domínio. Não configure um balanceador de carga separado para direcionar o tráfego para os controladores dentro do domínio. Verifique se todos os controladores de domínio têm recursos de memória e armazenamento suficientes para processar a base de dados do domínio. Dimensione todas as VMs do controlador de domínio com o mesmo tamanho.
Considerações de disponibilidade
Aprovisione, pelo menos, dois controladores de domínio para cada domínio. Este procedimento permitirá a replicação automática entre os servidores. Crie um conjunto de disponibilidade para as VMs que funcionam como servidores do Active Directory e processam cada um dos domínios. Coloque, pelo menos, dois servidores neste conjunto de disponibilidade.
Adicionalmente, considere designar um ou mais servidores em cada domínio como mestres de operações em espera no caso de uma falha de conectividade com um servidor a funcionar como uma função FSMO (Flexible Single Master Operation).
Considerações sobre a capacidade de gestão
Para obter informações sobre as considerações de gestão e monitorização, veja Expandir o Active Directory para o Azure.
Para obter informações adicionais, veja Monitoring Active Directory (Monitorizar o Active Directory). Pode instalar ferramentas como o Microsoft Systems Center num servidor de monitorização na sub-rede de gestão para ajudar a realizar estas tarefas.
Considerações de segurança
A confiança ao nível da floresta é transitiva. Se estabelecer uma confiança ao nível da floresta entre uma floresta no local e uma floresta na cloud, esta será expandida para outros novos domínios criados em qualquer uma das florestas. Se utilizar domínios para fornecer uma separação por motivos de segurança, considere criar confiança apenas ao nível do domínio. A confiança ao nível do domínio não é transitiva.
Para obter as considerações sobre a segurança do Active Directory, veja a secção de considerações de segurança em Expandir o Active Directory para o Azure.
Considerações de DevOps
Para obter considerações sobre o DevOps, veja Excelência operacional em Expandir Active Directory Domain Services (AD DS) para o Azure.
Considerações de custos
Utilize a calculadora de preços do Azure para prever os custos. Outras considerações estão descritas na secção Custo no Microsoft Azure Well-Architected Framework.
Seguem-se considerações de custos para os serviços utilizados nesta arquitetura.
Serviços de Domínio do AD
Considere ter o Active Directory Domain Services como um serviço partilhado que é consumido por várias cargas de trabalho para reduzir os custos. Para obter mais informações, veja Active Directory Domain Services preços.
Gateway de VPN do Azure
O componente principal desta arquitetura é o serviço de gateway de VPN. O montante cobrado baseia-se no número de vezes que esse gateway é aprovisionado e está disponível.
Todo o tráfego de entrada é gratuito, todo o tráfego de saída é cobrado. São aplicados os custos com a largura de banda da Internet ao tráfego de saída da VPN.
Para obter mais informações, veja Preços do Gateway de VPN.
Passos seguintes
- Aprenda as melhores práticas para expandir o domínio do AD DS no local para o Azure
- Aprenda as melhores práticas para criar uma infraestrutura do AD FS no Azure.