Comparar Active Directory Domain Services autogerenciadas, Microsoft Entra ID e Microsoft Entra Domain Services gerenciados

Para fornecer acesso a uma identidade central a aplicativos, serviços ou dispositivos, há três maneiras comuns no Azure de usar serviços baseados no Active Directory. Essa opção nas soluções de identidade proporciona a flexibilidade de usar o diretório mais apropriado para as necessidades da organização. Por exemplo, se você gerenciar principalmente usuários somente de nuvem que executam dispositivos móveis, talvez não faça sentido compilar e executar sua própria solução de identidade de AD DS (Active Directory Domain Services). Em vez disso, basta usar Microsoft Entra ID.

Embora as três soluções de identidade baseadas em Active Directory compartilhem um nome e uma tecnologia comuns, elas foram projetadas para fornecer serviços que atendem a diferentes demandas dos clientes. Em alto nível, essas soluções de identidade e conjuntos de recursos são:

• AD DS (Active Directory Domain Services) – servidor de protocolo LDAP pronto para empresas que fornece recursos importantes como identidade e autenticação, gerenciamento de objetos de computador, política de grupo e relações de confiança.
  • O AD DS é um componente central em muitas organizações com um ambiente de TI local e fornece autenticação de conta de usuário principal e recursos de gerenciamento de computador.
  • Para obter mais informações, confira Visão geral do Active Directory Domain Services na documentação do Windows Server.
• Microsoft Entra ID – Gerenciamento de dispositivo móvel e identidade baseada em nuvem que fornece serviços de autenticação e de conta de usuário para recursos como o Microsoft 365, o centro de administração do Microsoft Entra ou aplicativos SaaS.
  • O Microsoft Entra ID pode ser sincronizado com um ambiente de AD DS local para fornecer uma única identidade para os usuários que trabalham nativamente na nuvem.
  • Para obter mais informações sobre Microsoft Entra ID, consulte O que é Microsoft Entra ID?
• Microsoft Entra Domain Services: fornece serviços de domínio gerenciado com um subconjunto de recursos tradicionais do AD DS totalmente compatíveis, como ingresso no domínio, política de grupo, LDAP e autenticação de Kerberos/NTLM.
  • O Domain Services se integra ao Microsoft Entra ID, que, por si só, pode ser sincronizado com um ambiente do AD DS local. Essa capacidade estende os casos de uso da identidade central para aplicativos Web tradicionais que são executados no Azure como parte de uma estratégia de lift-and-shift.
  • Para saber mais sobre a sincronização com o Microsoft Entra ID e o local, confira Como os objetos e as credenciais são sincronizados em um domínio gerenciado.

Este artigo de visão geral compara e contrasta como essas soluções de identidade podem trabalhar em conjunto ou ser usadas de forma independente, dependendo das necessidades da organização.

Domain Services e AD DS autogerenciado

Se você tiver aplicativos e serviços que precisam ter acesso a mecanismos de autenticação tradicionais, como Kerberos ou NTLM, haverá duas maneiras de fornecer o Active Directory Domain Services na nuvem:

• Um domínio gerenciado que você cria usando o Microsoft Entra Domain Services. A Microsoft cria e gerencia os recursos necessários.
• Um domínio autogerenciado que você cria e configura usando recursos tradicionais, como VMs (máquinas virtuais), SO convidado do Windows Server e AD DS (Active Directory Domain Services). Em seguida, você continua administrando esses recursos.

Com o Domain Services, os principais componentes de serviço são implantados e mantidos para você pela Microsoft como uma experiência de domínio gerenciado. Você não implanta, não gerencia, não aplica patches e nem protege a infraestrutura de AD DS de componentes como as VMs, o sistema operacional Windows Server ou DCs (controladores de domínio).

O Domain Services fornece um subconjunto menor de recursos para o ambiente de AD DS tradicional autogerenciado, que reduz parte da complexidade do design e do gerenciamento. Por exemplo, não há florestas, domínios, sites e links de replicação do AD para criar e manter. Você ainda pode criar relações de confiança de floresta entre o Domain Services e os ambientes locais.

Para aplicativos e serviços que são executados na nuvem e precisam de acesso a mecanismos de autenticação tradicionais, como Kerberos ou NTLM, o Domain Services fornece uma experiência de domínio gerenciado com o mínimo de sobrecarga administrativa. Para obter mais informações, confira Conceitos de gerenciamento para contas de usuário, senhas e administração no Domain Services.

Ao implantar e executar um ambiente de AD DS autogerenciado, você precisa manter toda a infraestrutura e os componentes de diretório associados. Há uma sobrecarga de manutenção adicional com um ambiente de AD DS autogerenciado, mas com ele você pode executar tarefas adicionais, tais como estender o esquema e criar relações de confiança de floresta.

Os modelos de implantação comuns para um ambiente do AD DS autogerenciado que fornece identidade para aplicativos e serviços na nuvem incluem o seguinte:

• AD DS autônomo somente em nuvem – as VMs do Azure são configuradas como controladores de domínio e um ambiente separado do AD DS somente na nuvem é criado. Esse ambiente do AD DS não se integra a um ambiente do AD DS local. Um conjunto diferente de credenciais é usado para entrar em VMs na nuvem e administrá-las.
• Estender o domínio local para o Azure – uma rede virtual do Azure conecta-se a uma rede local usando uma conexão VPN/ExpressRoute. As VMs do Azure se conectam a essa rede virtual do Azure, que permite que elas ingressem no domínio do ambiente do AD DS local.
  • Uma alternativa é criar VMs do Azure e promovê-las como controladores de domínio de réplica do domínio do AD DS local. Esses controladores de domínio fazem replicação por uma conexão de VPN/ExpressRoute para o ambiente do AD DS local. O domínio do AD DS local é estendido efetivamente para o Azure.

A tabela a seguir descreve alguns dos recursos que podem ser necessários para sua organização e as diferenças entre um domínio gerenciado e um domínio autogerenciado do AD DS:

Domain Services e Microsoft Entra ID

O Microsoft Entra ID permite que você gerencie a identidade dos dispositivos usados pela organização e controle o acesso aos recursos corporativos desses dispositivos. Os usuários também podem registrar os dispositivos pessoais deles (um modelo BYO – traga o próprio) no Microsoft Entra ID, que fornece uma identidade ao dispositivo. Microsoft Entra ID autentica o dispositivo quando um usuário entra no Microsoft Entra ID e usa o dispositivo para acessar recursos protegidos. O dispositivo pode ser gerenciado usando o software de MDM (Gerenciamento de Dispositivo Móvel), como o Microsoft Intune. Essa capacidade de gerenciamento permite que você restrinja o acesso a recursos confidenciais somente a dispositivos gerenciados e em conformidade com a política.

Computadores e laptops tradicionais também podem ingressar no Microsoft Entra ID. Esse mecanismo oferece os mesmos benefícios de registrar um dispositivo pessoal com o Microsoft Entra ID, tais como permitir que os usuários entrem no dispositivo usando as credenciais corporativas deles.

Os dispositivos adicionados ao Microsoft Entra oferecem os seguintes benefícios:

• SSO (logon único) para aplicativos protegidos por Microsoft Entra ID.
• Roaming em conformidade com a política corporativa das configurações de usuário entre dispositivos.
• Acesso à Microsoft Store para Empresas usando credenciais corporativas.
• Windows Hello for Business.
• Acesso restrito aos aplicativos e recursos de dispositivos em conformidade com as políticas corporativas.

Os dispositivos podem ser ingressados no Microsoft Entra ID com ou sem uma implantação híbrida que inclui um ambiente do AD DS local. A tabela a seguir descreve os modelos de propriedade de dispositivo comuns e como eles normalmente seriam ingressados em um domínio:

Em um dispositivo registrado ou ingressado no Microsoft Entra, a autenticação de usuário ocorre por meio do uso de protocolos modernos baseados em OAuth/OpenID Connect. Esses protocolos são projetados para funcionarem pela Internet e são ótimos para cenários móveis, nos quais os usuários acessam recursos corporativos de qualquer lugar.

Com os dispositivos ingressados no Domain Services, os aplicativos podem usar os protocolos Kerberos e NTLM para autenticação e, portanto, podem dar suporte a aplicativos herdados migrados para execução em VMs do Azure como parte de uma estratégia de lift-and-shift. A tabela a seguir mostra as diferenças em como os dispositivos são representados e podem se autenticar no diretório:

Se o AD DS local e o Microsoft Entra ID forem configurados para autenticação federada usando o AD FS, então não haverá nenhum hash de senha (atual/válido) disponível no Azure DS. As contas de usuário do Microsoft Entra criadas antes da implementação da autenticação federada podem ter um hash de senha antigo, que, provavelmente, não corresponderá a qualquer hash da senha no local. Como resultado, o Domain Services não poderá validar as credenciais dos usuários

Próximas etapas

Para começara usar um Domain Services, crie um domínio gerenciado do Domain Services utilizando o centro de administração do Microsoft Entra.

Você também pode aprender mais sobre os conceitos de gerenciamento de para contas de usuário, senhas e administração no Domain Services e como os objetos e as credenciais são sincronizados em um domínio gerenciado.