Essa arquitetura de referência mostra como criar um domínio separado do Active Directory no Azure que é de confiança nos domínios na sua floresta local do AD.
Baixe um arquivo do Visio para a arquitetura "Floresta do AD DS".
O AD DS (Active Directory Domain Services) armazena informações de identidade em uma estrutura hierárquica. O nó superior na estrutura hierárquica é conhecido como uma floresta. Uma floresta contém domínios e domínios contêm outros tipos de objetos. Essa 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 local. A floresta no Azure contém um domínio que não existe localmente. Devido à relação de confiança, os logons realizados nos domínios locais pode ser confiáveis para acessar recursos em um domínio separado do Azure.
Usos típicos para essa arquitetura incluem manter uma separação segurança para objetos e identidades mantidos na nuvem e migrar os domínios individuais do local para a nuvem.
Para obter considerações adicionais, confira Escolher uma solução para a integração do Active Directory local ao Azure.
Arquitetura
A arquitetura tem os seguintes componentes.
- Rede local. A rede local contém sua própria floresta e domínios do Active Directory.
- Servidores do Active Directory. Esses são controladores de domínio que implementam serviços de domínio em execução como VMs na nuvem. Esses servidores hospedam uma floresta que contém um ou mais domínios, separados daqueles locais.
- Relação de confiança unidirecional. O exemplo no diagrama mostra uma relação de confiança unidirecional do domínio no Azure para o domínio local. Essa relação permite que os usuários locais acessem os recursos no domínio no Azure, mas não o oposto.
- Sub-rede do Active Directory. Os servidores do AD DS são hospedados em uma sub-rede separada. As regras de NSG (grupo de segurança de rede) protegem os servidores do AD DS e fornecem um firewall em tráfego de fontes inesperadas.
- Gateway do Azure. O gateway do Azure fornece uma conexão entre a rede local e a VNet do Azure. Essa pode ser uma conexão VPN ou do Azure ExpressRoute. Para obter mais informações, consulte Conectar uma rede local ao Azure usando um gateway de VPN.
Recomendações
Para obter recomendações específicas sobre como implementar o Active Directory no Azure, confiraEstender Active Directory Domain Services (AD DS) para o Azure.
Confiança
Os domínios locais estão contidos em uma floresta diferente dos domínios na nuvem. Para habilitar a autenticação de usuários locais na nuvem, os domínios no Azure precisam confiar no domínio de logon na floresta local. Da mesma forma, se a nuvem fornece um domínio de logon para usuários externos, pode ser necessário que a floresta local confie no domínio de nuvem.
Você pode estabelecer relações de confiança no nível de floresta criando relações de confiança de floresta ou no nível do domínio criando relações de confiança externas. Uma confiança no nível de floresta cria uma relação entre todos os domínios nas duas florestas. Uma relação de confiança no nível de domínio externo só cria uma relação entre dois domínios especificados. Você só deve criar relações de confiança no nível de domínio externo entre domínios de florestas diferentes.
As relações de confiança com um Active Directory local são apenas unidirecionais. Uma relação de confiança unidirecional permite que os usuários em um domínio ou floresta (conhecido como o domínio ou a floresta de entrada) para acessar os recursos contidos em outro (o domínio ou a floresta de saída).
A tabela a seguir resume as configurações de confiança para alguns cenários simples:
| Cenário | Relação de confiança local | Relação de confiança na nuvem |
|---|---|---|
| Os usuários locais precisam de acesso aos recursos na nuvem, mas não vice-versa | Unidirecional de entrada | Unidirecional de saída |
| Os usuários na nuvem precisam de acesso aos recursos locais, mas não vice-versa | Unidirecional de saída | Unidirecional de entrada |
Considerações sobre escalabilidade
O Active Directory é automaticamente escalonável para controladores de domínio que fazem parte do mesmo domínio. As solicitações são distribuídas por todos os controladores em um domínio. Você pode adicionar outro controlador de domínio e ele é sincronizado automaticamente com o domínio. Não configure um balanceador de carga separado para direcionar o tráfego para os controladores no domínio. Verifique se todos os controladores de domínio têm recursos de memória e armazenamento suficientes para lidar com o banco de dados do domínio. Deixe todas as VMs do controlador de domínio com o mesmo tamanho.
Considerações sobre disponibilidade
Provisione pelo menos dois controladores de domínio para cada domínio. Isso habilita a replicação automática entre os servidores. Crie um conjunto de disponibilidade para as VMs que atuam como servidores do Active Directory que tratam de cada domínio. Coloque pelo menos dois servidores neste conjunto de disponibilidade.
Além disso, considere a possibilidade de designar um ou mais servidores em cada domínio como mestres de operações em espera em caso de falha de conectividade com um servidor que atua na função de FSMO (operações principais únicas flexíveis).
Considerações sobre capacidade de gerenciamento
Para obter informações sobre as considerações de gerenciamento e monitoramento, consulte Estendendo o Active Directory para o Azure.
Para obter informações adicionais, consulte Monitoramento do Active Directory. Você pode instalar ferramentas como o Microsoft Systems Center em um servidor de monitoramento na sub-rede de gerenciamento para ajudar a executar essas tarefas.
Considerações de segurança
As relações de confiança no nível de floresta são transitivas. Se você estabelecer uma relação de confiança no nível de floresta entre uma floresta local e uma floresta na nuvem, essa relação de confiança é estendida para outros novos domínios criados em uma dessas florestas. Se você usar domínios para fornecer separação para fins de segurança, considere criar relações de confiança somente no nível de domínio. As relações de confiança no nível de domínio são não transitivas.
Para considerações de segurança específicas do Active Directory, consulte a seção de considerações de segurança em Estendendo o Active Directory para o Azure.
Considerações de DevOps
Para considerações sobre DevOps, confira Excelência operacional em Estender Active Directory Domain Services (AD DS) para o Azure.
Considerações de custo
Use a Calculadora de Preços do Azure para estimar os custos. Outras considerações são descritas na seção Custo em Microsoft Azure Well-Architected Framework.
Aqui estão as considerações de custo para os serviços usados nesta arquitetura.
AD Domain Services
Considere a possibilidade de usar o Active Directory Domain Services como um serviço compartilhado que é consumido por várias cargas de trabalho para reduzir os custos. Para mais informações, confira Preços do Active Directory Domain Services.
Gateway de VPN do Azure
O principal componente dessa arquitetura é o serviço de gateway de VPN. Você é cobrado com base no período de tempo em que o gateway é provisionado e fica disponível.
Todo o tráfego de entrada é gratuito, e todo o tráfego de saída é cobrado. Os custos de largura de banda da Internet são aplicados ao tráfego de saída da VPN.
Para saber mais, veja Preços do Gateway de VPN.
Próximas etapas
- Conheça as práticas recomendadas para estender seu domínio do AD DS local para o Azure
- Conheça as práticas recomendadas para criar uma infraestrutura do AD FS no Azure.