Este artigo compara as opções para integrar seu ambiente do AD (Active Directory) local com uma rede do Azure. Para cada opção, uma arquitetura de referência mais detalhada está disponível.
Muitas organizações usam o AD DS (Active Directory Domain Services) para autenticar identidades associadas a usuários, computadores, aplicativos ou outros recursos incluídos em um limite de segurança. Os serviços de diretório e identidade normalmente são hospedados localmente, mas se o aplicativo estiver hospedado parcialmente localmente e em parte no Azure, poderá haver latência ao enviar solicitações de autenticação do Azure de volta para o local. Implementar serviços de diretório e identidade no Azure pode reduzir essa latência.
O Azure fornece duas soluções para implementar serviços de diretório e identidade no Azure:
Use microsoft entra ID para criar um domínio do Active Directory na nuvem e conectá-lo ao seu domínio do Active Directory local. Microsoft Entra Connect integra seus diretórios locais à ID do Microsoft Entra.
Estenda sua infraestrutura existente do Active Directory local para o Azure, implantando uma VM no Azure que executa o AD DS como um Controlador de Domínio. Essa arquitetura é mais comum quando a rede local e a VNet (rede virtual) do Azure são conectadas por uma conexão VPN ou ExpressRoute. Várias variações dessa arquitetura são possíveis:
- Crie um domínio no Azure e junte-o à floresta do AD local.
- Crie uma floresta separada no Azure confiável por domínios em sua floresta local.
- Replicar uma implantação dos Serviços de Federação do Active Directory (AD FS) no Azure.
As próximas seções descrevem cada uma dessas opções com mais detalhes.
Integrar seus domínios locais à 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 que contém os mesmos objetos e identidades. As alterações feitas nesses itens locais 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 a ID do Microsoft Entra sem usar um diretório local. Nesse caso, a ID do Microsoft Entra atua como a principal fonte de todas as informações de identidade, em vez de conter dados replicados de um diretório local.
benefícios
- Você não precisa manter uma infraestrutura do AD na nuvem. A ID do Microsoft Entra é totalmente gerenciada e mantida pela Microsoft.
- A ID do Microsoft Entra fornece as mesmas informações de identidade disponíveis localmente.
- A autenticação pode acontecer no Azure, reduzindo a necessidade de aplicativos externos e usuários contatarem o domínio 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 da ID do Microsoft Entra.
- Se você quiser autenticar contas de serviço e computador, também precisará implantar Microsoft Entra Domain Services.
arquitetura de referência
O AD DS no Azure ingressou em uma floresta local
Implante servidores do AD DS (AD Domain Services) no Azure. Crie um domínio no Azure e junte-o à floresta do AD local.
Considere essa opção se você precisar usar recursos do AD DS que não são implementados atualmente pela ID do Microsoft Entra.
benefícios
- Fornece acesso às mesmas informações de identidade que estão disponíveis localmente.
- Você pode autenticar contas de usuário, serviço e computador local e no Azure.
- Você não precisa gerenciar uma floresta separada do AD. O domínio no Azure pode pertencer à floresta local.
- Você pode aplicar a política de grupo definida por objetos de política de grupo locais ao domínio no Azure.
desafios
- Você deve implantar e gerenciar seus próprios servidores E domínios do AD DS na nuvem.
- Pode haver alguma latência de sincronização entre os servidores de domínio na nuvem e os servidores em execução no local.
arquitetura de referência
AD DS no Azure com uma floresta separada
Implante servidores do AD DS (AD Domain Services) no Azure, mas crie uma floresta de do Active Directory separada separada da floresta local. Essa floresta é confiável por domínios em sua floresta local.
Os usos típicos dessa arquitetura incluem manter a separação de segurança para objetos e identidades mantidos na nuvem e migrar domínios individuais do local para a nuvem.
benefícios
- Você pode implementar identidades locais e identidades separadas somente do Azure.
- Você não precisa replicar da floresta do AD local para o Azure.
desafios
- A autenticação no Azure para identidades locais requer saltos de rede extras para os servidores do AD locais.
- Você deve implantar seus próprios servidores E florestas do AD DS na nuvem e estabelecer as relações de confiança apropriadas entre florestas.
arquitetura de referência
Estender o AD FS para o Azure
Replique uma implantação dos Serviços de Federação do Active Directory (AD FS) no Azure para executar a autenticação federada e a autorização para componentes em execução no Azure.
Usos típicos para esta arquitetura:
- Autenticar e autorizar usuários de organizações parceiras.
- Permitir que os usuários se autentiquem de navegadores da Web em execução fora do firewall organizacional.
- Permitir que os usuários se conectem de dispositivos externos autorizados, como dispositivos móveis.
benefícios
- Você pode aproveitar aplicativos com reconhecimento de declarações.
- Fornece a capacidade de confiar em parceiros externos para autenticação.
- Compatibilidade com um grande conjunto de protocolos de autenticação.
desafios
- Você deve implantar seus próprios servidores proxy de aplicativo Web do AD DS, AD FS e AD FS no Azure.
- Essa arquitetura pode ser complexa de configurar.
arquitetura de referência