Esta arquitetura de referência mostra como criar um domínio do Ative Directory separado no Azure que é confiável por domínios em sua floresta do AD local.
Baixe um de arquivo do Visio para a arquitetura "Floresta do AD DS".
Os Serviços de Domínio Ative Directory (AD DS) armazenam informações de identidade numa estrutura hierárquica. O nó superior na estrutura hierárquica é conhecido como 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, logons feitos em domínios locais podem ser confiáveis para acesso a recursos no domínio separado do Azure.
Os usos típicos dessa arquitetura incluem a manutenção da separação de segurança para objetos e identidades mantidos na nuvem e a migração de domínios individuais do local para a nuvem.
Para obter considerações adicionais, consulte Escolher uma solução para integrar o Ative Directory local com o Azure.
Arquitetura
A arquitetura tem os seguintes componentes.
- Rede local. A rede local contém sua própria floresta e domínios do Ative Directory.
- servidores do Ative Directory. Estes são controladores de domínio que implementam serviços de domínio executados como VMs na nuvem. Esses servidores hospedam uma floresta que contém um ou mais domínios, separados daqueles localizados localmente.
- 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 recursos no domínio no Azure, mas não o contrário.
- sub-rede do Ative Directory. Os servidores AD DS são hospedados em uma sub-rede separada. As regras do NSG (grupo de segurança de rede) protegem os servidores AD DS e fornecem um firewall contra o 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. Pode ser uma conexão VPN ou Azure ExpressRoute. Para obter mais informações, consulte conectar uma rede local ao Azure usando um gateway VPN.
Recomendações
Para obter recomendações específicas sobre como implementar o Ative Directory no Azure, consulte Estendendo os Serviços de Domínio Ative Directory (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 devem confiar no domínio de logon na floresta local. Da mesma forma, se a nuvem fornecer um domínio de logon para usuários externos, pode ser necessário que a floresta local confie no domínio da nuvem.
Você pode estabelecer relações de confiança no nível da floresta criando relações de confiança florestaou no nível do domínio criando relações de confiança externas . Uma confiança no nível da floresta cria uma relação entre todos os domínios em duas florestas. Uma relação de confiança de nível de domínio externo cria apenas 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 em florestas diferentes.
As relações de confiança com um Ative Directory local são apenas unidirecionais (unidirecional). Uma relação de confiança unidirecional permite que os usuários de um domínio ou floresta (conhecidos como domínio de entrada ou floresta) acessem os recursos mantidos em outro (a de saída ou floresta).
A tabela a seguir resume as configurações de confiança para alguns cenários simples:
| Cenário | Confiança local | Confiança na nuvem |
|---|---|---|
| Os usuários locais precisam de acesso a recursos na nuvem, mas não vice-versa | Só de ida, entrada | Só de ida, de saída |
| Os utilizadores na nuvem necessitam de acesso a recursos localizados no local, mas não vice-versa | Só de ida, de saída | Só de ida, entrada |
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para Confiabilidade.
Provisione pelo menos dois controladores de domínio para cada domínio. Isso permite a replicação automática entre servidores. Crie um conjunto de disponibilidade para as VMs que atuam como servidores do Ative Directory que manipulam cada domínio. Coloque pelo menos dois servidores neste conjunto de disponibilidade.
Além disso, considere designar um ou mais servidores em cada domínio como mestres de operações em espera caso a conectividade com um servidor que atua como uma função FSMO (operação mestre única) flexível falhe.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança .
Os trusts de nível florestal são transitivos. Se você estabelecer uma confiança no nível da floresta entre uma floresta local e uma floresta na nuvem, essa confiança será estendida a outros novos domínios criados em qualquer uma das florestas. Se você usar domínios para fornecer separação para fins de segurança, considere a criação de relações de confiança somente no nível do domínio. As relações de confiança no nível do domínio não são transitivas.
Para obter considerações de segurança específicas do Ative Directory, consulte a seção de considerações de segurança em Estendendo o Ative Directory para o Azure.
Otimização de Custos
A Otimização de Custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.
Use o da calculadora de preços do Azure para estimar custos. Outras considerações são descritas na seção Custo em Microsoft Azure Well-Architected Framework.
Aqui estão considerações de custo para os serviços usados nessa arquitetura.
Serviços de Domínio do AD
Considere ter os Serviços de Domínio Ative Directory como um serviço compartilhado que é consumido por várias cargas de trabalho para reduzir custos. Para obter mais informações, consulte de preços dos Serviços de Domínio Ative Directory.
Azure VPN Gateway
O principal componente dessa arquitetura é o serviço de gateway VPN. Você é cobrado com base na quantidade de tempo que o gateway está provisionado e disponível.
Todo o tráfego de entrada é gratuito, 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 obter mais informações, consulte de preços do gateway de VPN.
Excelência Operacional
A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de projeto para o Operational Excellence.
DevOps
Para obter considerações sobre DevOps, consulte Excelência operacional em estendendo os Serviços de Domínio Ative Directory (AD DS) para o Azure.
Capacidade de gestão
Para obter informações sobre considerações de gerenciamento e monitoramento, consulte Estendendo o Ative Directory para o Azure.
Siga as orientações em Monitoramento do Ative Directory. Você pode instalar ferramentas como Microsoft Systems Center em um servidor de monitoramento na sub-rede de gerenciamento para ajudar a executar essas tarefas.
Eficiência de desempenho
Eficiência de desempenho é a capacidade de sua carga de trabalho de atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para Eficiência de desempenho.
O Ative Directory é automaticamente escalável para controladores de domínio que fazem parte do mesmo domínio. As solicitações são distribuídas por todos os controladores dentro de um domínio. Você pode adicionar outro controlador de domínio e ele sincroniza automaticamente com o domínio. Não configure um balanceador de carga separado para direcionar o tráfego para controladores dentro do domínio. Verifique se todos os controladores de domínio têm memória e recursos de armazenamento suficientes para lidar com o banco de dados de domínio. Faça com que todas as VMs do controlador de domínio tenham o mesmo tamanho.
Próximos passos
- Conheça as práticas recomendadas para estender seu domínio do AD DS local para o Azure
- Aprenda as práticas recomendadas para a criação de um de infraestrutura do AD FS no Azure.