Este artigo compara opções para integrar o ambiente do Active Directory (AD) no local com uma rede do Azure. Para cada opção, está disponível uma arquitetura de referência mais detalhada.
Muitas organizações utilizam o Active Directory Domain Services (AD DS) para autenticar identidades associadas a utilizadores, computadores, aplicações ou a outros recursos incluídos num limite de segurança. Os serviços de diretório e de identidade estão, normalmente, alojados no local. Porém, se a sua aplicação estiver alojada parcialmente no local e parcialmente no Azure, poderá verificar alguma latência no envio de pedidos de autenticação do Azure para o local. A implementação dos serviços de diretório e de identidade no Azure pode reduzir essa latência.
O Azure fornece duas soluções para implementar os serviços de diretório e de identidade no Azure:
Use o Microsoft Entra ID para criar um domínio do Ative Directory na nuvem e conectá-lo ao seu domínio do Ative Directory local. O Microsoft Entra Connect integra seus diretórios locais com a ID do Microsoft Entra.
Expanda a sua infraestrutura atual do Active Directory no local para o Azure ao implementar uma VM no Azure que execute o AD DS como controlador de domínio. Esta arquitetura é mais comum quando a rede no local e a rede virtual (VNet) do Azure estão ligadas através de uma ligação VPN ou ExpressRoute. Estão disponíveis algumas variações desta arquitetura:
- Crie um domínio no Azure e associe-o à sua floresta do AD no local.
- Crie uma floresta separada no Azure que seja considerada fidedigna pelos domínios na sua floresta no local.
- Replique uma implementação dos Serviços de Federação do Active Directory (AD FS) para o Azure.
As secções seguintes descrevem cada uma destas opções mais detalhadamente.
Integre seus domínios locais com o ID do Microsoft Entra
Use a ID do Microsoft Entra para criar um domínio no Azure e vinculá-lo a um domínio do AD local.
O diretório do Microsoft Entra não é uma extensão de um diretório local. Em vez disso, é uma cópia com os mesmos objetos e identidades. As alterações feitas nesses itens no local são copiadas para a ID do Microsoft Entra, mas as alterações feitas na ID do Microsoft Entra não são replicadas de volta para o domínio local.
Você também pode usar o Microsoft Entra ID sem usar um diretório local. Nesse caso, o Microsoft Entra ID atua como a fonte primária de todas as informações de identidade, em vez de conter dados replicados de um diretório local.
Benefícios
- Não precisa de manter uma infraestrutura do AD na cloud. O Microsoft Entra ID é totalmente gerenciado e mantido pela Microsoft.
- O Microsoft Entra ID fornece as mesmas informações de identidade que estão disponíveis localmente.
- Pode ocorrer a autenticação no Azure, o que reduz a necessidade de as aplicações externas e os utilizadores contactarem o domínio no local.
Desafios
- Você deve configurar a conectividade com seu domínio local para manter o diretório do Microsoft Entra sincronizado.
- Os aplicativos podem precisar ser reescritos para habilitar a autenticação por meio do Microsoft Entra ID.
- Se desejar autenticar contas de serviço e de computador, você também terá que implantar os Serviços de Domínio Microsoft Entra.
Arquitetura de referência
AD DS no Azure associado a uma floresta no local
Implemente servidores dos Serviços de Domínio do AD (AD DS) no Azure. Crie um domínio no Azure e associe-o à sua floresta do AD no local.
Considere essa opção se precisar usar recursos do AD DS que não estão atualmente implementados pela ID do Microsoft Entra.
Benefícios
- Fornece acesso às mesmas informações de identidade que estão disponíveis no local.
- Pode autenticar as contas de utilizador, de serviço e de computador no local e no Azure.
- Não precisa de gerir uma floresta do AD separada. O domínio no Azure pode pertencer à floresta no local.
- Pode aplicar a política de grupo definida pelos Objetos de Política de Grupo no local ao domínio no Azure.
Desafios
- Tem de implementar e gerir os seus próprios servidores do AD DS e o domínio na cloud.
- Pode ocorrer alguma latência de sincronização entre os servidores do domínio na cloud e os servidores em execução no local.
Arquitetura de referência
AD DS no Azure com uma floresta separada
Implemente servidores do AD Domain Services (AD DS) no Azure, mas crie uma floresta do Active Directory diferente que esteja separada da floresta no local. Esta floresta é considerada fidedigna pelos domínios na floresta no local.
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.
Benefícios
- Pode implementar identidades no local e separar identidades apenas do Azure.
- Não precisa de replicar da floresta do AD no local para o Azure.
Desafios
- No Azure, a autenticação de identidades no local requer saltos de rede adicionais para os servidores do AD no local.
- Tem de implementar os seus próprios servidores do AD DS e a floresta na cloud e estabelecer as relações de confiança adequadas entre as florestas.
Arquitetura de referência
Expandir o AD FS para o Azure
Replique uma implementação dos Serviços de Federação do Active Directory (AD FS) para o Azure, para obter uma autenticação federada e uma autorização para os componentes em execução no Azure.
Utilizações típicas desta arquitetura:
- Autenticar e autorizar utilizadores de organizações parceiras.
- Permitir que os utilizadores sejam autenticados a partir de browsers em execução fora da firewall organizacional.
- Permitir aos utilizadores estabelecer uma ligação a partir de dispositivos externos autorizados, tal como dispositivos móveis.
Benefícios
- Pode tirar partido das aplicações com suporte para afirmações.
- Permite confiar em parceiros externos para a autenticação.
- Compatibilidade com um grande conjunto de protocolos de autenticação.
Desafios
- Tem de implementar os seus próprios servidores do AD DS, AD FS e Proxy de Aplicações Web do AD FS no Azure.
- A configuração desta arquitetura pode ser complexa.
Arquitetura de referência