Compare os Serviços de Domínio Ative Directory autogerenciados, a ID do Microsoft Entra e os Serviços de Domínio Microsoft Entra gerenciados

Para fornecer acesso a aplicativos, serviços ou dispositivos a uma identidade central, há três maneiras comuns de usar serviços baseados no Ative Directory no Azure. Essa escolha em soluções de identidade oferece a flexibilidade de usar o diretório mais apropriado para as necessidades da sua organização. Por exemplo, se você gerencia principalmente usuários somente na nuvem que executam dispositivos móveis, pode não fazer sentido criar e executar sua própria solução de identidade dos Serviços de Domínio Ative Directory (AD DS). Em vez disso, você pode simplesmente usar o Microsoft Entra ID.

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

  • Serviços de Domínio Ative Directory (AD DS) - Servidor LDAP (lightweight directory access protocol) pronto para a empresa que fornece recursos importantes, como identidade e autenticação, gerenciamento de objetos de computador, diretiva de grupo e relações de confiança.
  • Microsoft Entra ID - Gerenciamento de identidade e dispositivo móvel baseado em nuvem que fornece conta de usuário e serviços de autenticação 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 AD DS local para fornecer uma única identidade aos usuários que funciona nativamente na nuvem.
    • Para obter mais informações sobre o Microsoft Entra ID, consulte O que é o Microsoft Entra ID?
  • Serviços de Domínio Microsoft Entra - Fornece serviços de domínio gerenciados 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 Kerberos/NTLM.
    • Os Serviços de Domínio integram-se com o Microsoft Entra ID, que por sua vez pode sincronizar com um ambiente AD DS local. Essa capacidade estende os casos de uso de identidade central para aplicativos Web tradicionais que são executados no Azure como parte de uma estratégia de elevação e mudança.
    • Para saber mais sobre a sincronização com o Microsoft Entra ID e local, consulte Como objetos e 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 juntas ou seriam usadas de forma independente, dependendo das necessidades da sua organização.

Serviços de Domínio e AD DS autogerido

Se você tiver aplicativos e serviços que precisam de acesso a mecanismos de autenticação tradicionais, como Kerberos ou NTLM, há duas maneiras de fornecer Serviços de Domínio Ative Directory na nuvem:

  • Um domínio gerenciado que você cria usando os Serviços de Domínio do Microsoft Entra. A Microsoft cria e gerencia os recursos necessários.
  • Um domínio autogerenciado que você cria e configura usando recursos tradicionais, como máquinas virtuais (VMs), sistema operacional convidado do Windows Server e Serviços de Domínio Ative Directory (AD DS). Em seguida, você continua a administrar esses recursos.

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

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

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

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

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

  • AD DS autônomo somente na nuvem - as VMs do Azure são configuradas como controladores de domínio e um ambiente AD DS separado e 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 e administrar VMs na nuvem.
  • Estender o domínio local para o Azure - Uma rede virtual do Azure se conecta a uma rede local usando uma conexão VPN/ExpressRoute. As VMs do Azure se conectam a essa rede virtual do Azure, o que permite que elas ingressem no domínio no 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 AD DS local. Esses controladores de domínio são replicados por meio de uma conexão VPN/Rota Expressa para o ambiente AD DS local. O domínio do AD DS local é efetivamente estendido para o Azure.

A tabela a seguir descreve alguns dos recursos que você pode precisar para sua organização e as diferenças entre um domínio gerenciado ou um domínio AD DS autogerenciado:

Funcionalidade Domínio gerenciado AD DS autogerenciado
Serviço gerenciado
Implantações seguras O administrador protege a implantação
Servidor DNS ✓ (serviço gerenciado)
Privilégios de administrador de domínio ou Enterprise
Associação a um domínio
Autenticação de domínio usando NTLM e Kerberos
Delegação restrita de Kerberos Baseado em recursos Baseado em recursos & baseado em conta
Estrutura de UO personalizada
Política de Grupo
Extensões de esquema
Confianças de domínio/floresta do AD ✓ (somente trusts de floresta de saída unidirecional)
LDAP seguro (LDAPS)
Leitura LDAP
Gravação LDAP ✓ (dentro do domínio gerenciado)
Implantações distribuídas geograficamente

Serviços de Domínio e ID do Microsoft Entra

O Microsoft Entra ID permite gerenciar a identidade de dispositivos usados pela organização e controlar o acesso a recursos corporativos a partir desses dispositivos. Os usuários também podem registrar seu dispositivo pessoal (um modelo traga seu próprio (BYO)) com o Microsoft Entra ID, que fornece ao dispositivo uma identidade. Em seguida, o 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 Gerenciamento de Dispositivos Móveis (MDM), como o Microsoft Intune. Essa capacidade de gerenciamento permite restringir o acesso a recursos confidenciais a dispositivos gerenciados e compatíveis com políticas.

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

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

  • Logon único (SSO) para aplicativos protegidos pelo Microsoft Entra ID.
  • Roaming das configurações do usuário em conformidade com a política corporativa entre dispositivos.
  • Acesso à Windows Store para Empresas usando credenciais corporativas.
  • Windows Hello para Empresas.
  • Acesso restrito a aplicativos e recursos de dispositivos compatíveis com a política corporativa.

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

Tipo de dispositivo Plataformas de dispositivos Mecanismo
Dispositivos pessoais Windows 10, iOS, Android, macOS Registados no Microsoft Entra
Dispositivo de propriedade da organização não associado ao AD DS local Windows 10 Associados ao Microsoft Entra
Dispositivo de propriedade da organização associado a um AD DS local Windows 10 Associados ao Microsoft Entra híbrido

Em um dispositivo registrado ou ingressado no Microsoft Entra, a autenticação do usuário acontece usando protocolos modernos baseados em OAuth / OpenID Connect. Esses protocolos são projetados para funcionar pela internet, por isso são ótimos para cenários móveis onde os usuários acessam recursos corporativos de qualquer lugar.

Com dispositivos associados aos Serviços de Domínio, os aplicativos podem usar os protocolos Kerberos e NTLM para autenticação, portanto, podem dar suporte a aplicativos herdados migrados para serem executados em VMs do Azure como parte de uma estratégia de elevação e mudança. A tabela a seguir descreve as diferenças em como os dispositivos são representados e podem autenticar-se no diretório:

Aspeto Associados ao Microsoft Entra Ingressado nos Serviços de Domínio
Dispositivo controlado por Microsoft Entra ID Domínio gerenciado dos Serviços de Domínio
Representação no diretório Objetos de dispositivo no diretório Microsoft Entra Objetos de computador no domínio gerenciado dos Serviços de Domínio
Autenticação Protocolos baseados em OAuth / OpenID Connect Protocolos Kerberos e NTLM
Gestão Software de Gestão de Dispositivos Móveis (MDM) como o Intune Política de Grupo
Rede Funciona através da internet Deve estar conectado ou emparelhado com a rede virtual onde o domínio gerenciado é implantado
Ótimo para... Dispositivos móveis ou desktop do usuário final VMs de servidor implantadas no Azure

Se o AD DS local e a ID do Microsoft Entra estiverem configurados para autenticação federada usando o AD FS, não haverá 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 alimentada podem ter um hash de senha antigo, mas isso provavelmente não corresponde a um hash de sua senha local. Como resultado, os Serviços de Domínio não poderão validar as credenciais dos usuários

Próximos passos

Para começar a usar os Serviços de Domínio, crie um domínio gerenciado pelos Serviços de Domínio usando o centro de administração do Microsoft Entra.

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