Casos de uso e cenários comuns para o Microsoft Entra Domain Services

O Microsoft Entra Domain Services fornece serviços de domínio gerenciado, como ingresso no domínio, política de grupo, protocolo LDAP e autenticação Kerberos/NTLM. O Microsoft Entra Domain Services se integra ao locatário existente do Microsoft Entra, o que permite aos usuários entrarem usando suas credenciais atuais. É possível usar serviços de domínio sem a necessidade de implantar, gerenciar e aplicar patch nos controladores de domínio na nuvem, o que permite um lift-and-shift mais suave dos recursos locais para o Azure.

Este artigo descreve alguns cenários de negócios comuns em que o Microsoft Entra Domain Services agrega valor e atende a essas necessidades.

Maneiras comuns de fornecer soluções de identidade na nuvem

Ao migrar cargas de trabalho existentes para a nuvem, os aplicativos reconhecidos pelo diretório poderão usar o LDAP para acesso de leitura e gravação a um diretório local do AD DS. Aplicativos em execução no Windows Server normalmente são implantados em VMs (máquinas virtuais) ingressadas em domínio, para que possam ser gerenciados com segurança usando a Política de Grupo. Para autenticar usuários finais, os aplicativos também podem depender da autenticação integrada do Windows, como a autenticação Kerberos ou NTLM.

Geralmente, os administradores de TI usam uma das seguintes soluções para fornecer um serviço de identidade a aplicativos executados no Azure:

  • Configurar uma conexão VPN site a site entre as cargas de trabalho executadas no Azure e o ambiente local do AD DS.
    • Os controladores de domínio locais, por sua vez, fornecem autenticação por meio da conexão VPN.
  • Criar réplica dos controladores de domínio usando as VMs (máquinas virtuais) do Azure para estender o domínio/floresta do AD DS do local.
    • Os controladores de domínio executados em VMs do Azure fornecem autenticação e replicam informações de diretório entre o ambiente do AD DS local.
  • Implantar um ambiente autônomo do AD DS no Azure usando controladores de domínio executados em VMs do Azure.
    • Os controladores de domínio executados em VMs do Azure fornecem autenticação, mas as informações de diretório não são replicadas entre o ambiente do AD DS local.

Com essas abordagens, as conexões VPN com o diretório local tornam os aplicativos vulneráveis a falhas de rede ou interrupções transitórias. Se você implantar controladores de domínio usando VMs no Azure, a equipe de TI precisará gerenciar as VMs e, então, proteger, aplicar patches, monitorar, fazer backup e solucionar os problemas delas.

O Microsoft Entra Domain Services oferece alternativas para a necessidade de criar conexões VPN de volta para um ambiente local do AD DS ou executar e gerenciar VMs no Azure para fornecer serviços de identidade. Como um serviço gerenciado, o Microsoft Entra Domain Services reduz a complexidade da criação de uma solução de identidade integrada para ambientes híbridos e somente em nuvem.

Microsoft Entra Domain Services para organizações híbridas

Muitas organizações executam uma infraestrutura híbrida que inclui cargas de trabalho locais e de aplicativo. Aplicativos herdados migrados para o Azure como parte de uma estratégia de lift-and-shift podem usar conexões LDAP tradicionais para fornecer informações de identidade. Para apoiar essa infraestrutura híbrida, as informações de identidade de um ambiente local do AD DS podem ser sincronizadas com um locatário do Microsoft Entra. Então, o Microsoft Entra Domain Services fornece esses aplicativos herdados no Azure com uma origem de identidade, sem a necessidade de configurar e gerenciar a conectividade do aplicativo com os serviços de diretório local.

Veja um exemplo da Litware Corporation, uma organização híbrida que executa no local e em recursos do Azure:

Microsoft Entra Domain Services for a hybrid organization that includes on-premises synchronization

  • Os aplicativos e as cargas de trabalho de servidor que exigem serviços de domínio são implantados em uma rede virtual no Azure.
    • Isso pode incluir aplicativos herdados migrados para o Azure como parte de uma estratégia de lift-and-shift.
  • A Litware Corporation implantou o Microsoft Entra Connect para sincronizar informações de identidade do diretório local para seu locatário do Microsoft Entra.
    • As informações de identidade sincronizadas incluem contas de usuário e associações de grupo.
  • A equipe de TI da Litware habilita o Microsoft Entra Domain Services para seu locatário Microsoft Entra nesta ou em uma rede virtual emparelhada.
  • Os aplicativos e as VMs implantados na rede virtual do Azure podem utilizar recursos do Microsoft Entra Domain Services como ingresso no domínio, leitura LDAP, associação LDAP, autenticação NTLM e Kerberos e Política de Grupo.

Importante

O Microsoft Entra Connect só deve ser instalado e configurado para sincronização com ambientes do AD DS local. Não há suporte para instalar o Microsoft Entra Connect em um domínio gerenciado para sincronizar objetos de volta para o Microsoft Entra ID.

Microsoft Entra Domain Services para organizações somente na nuvem

Um locatário somente em nuvem do Microsoft Entra não tem uma origem de identidade local. Contas de usuário e associações de grupo, por exemplo, são criadas e gerenciadas diretamente no Microsoft Entra ID.

Agora, vamos ver um exemplo da Contoso, uma organização somente em nuvem que usa o Microsoft Entra ID para gerenciar identidades. Todas as identidades de usuário, suas credenciais e associações de grupo são criadas e gerenciadas no Microsoft Entra ID. Não há outras configurações do Microsoft Entra Connect para sincronizar informações de identidade de um diretório local.

Microsoft Entra Domain Services for a cloud-only organization with no on-premises synchronization

  • Os aplicativos e as cargas de trabalho de servidor que exigem serviços de domínio são implantados em uma rede virtual no Azure.
  • A equipe de TI da Contoso habilita o Microsoft Entra Domain Services para seu locatário Microsoft Entra nesta ou em uma rede virtual emparelhada.
  • Os aplicativos e as VMs implantados na rede virtual do Azure podem utilizar recursos do Microsoft Entra Domain Services como ingresso no domínio, leitura LDAP, associação LDAP, autenticação NTLM e Kerberos e Política de Grupo.

Administração segura de máquinas virtuais do Azure

Você pode unir as VMs (máquinas virtuais) do Azure a um domínio gerenciado do Microsoft Entra Domain Services e assim usar um único conjunto de credenciais do AD. Essa abordagem reduz os problemas de gerenciamento de credenciais, como a manutenção de contas de administrador local em cada VM ou a contas e senhas separadas entre ambientes.

As VMs que ingressaram em um domínio gerenciado também podem ser administradas e protegidas usando a política de grupo. As linhas de base de segurança necessárias podem ser aplicadas às VMs para bloqueá-las de acordo com as diretrizes de segurança corporativa. Por exemplo, você pode usar as funcionalidades de gerenciamento da política de grupo para restringir os tipos de aplicativos que podem ser iniciados na VM.

Streamlined administration of Azure virtual machines

Vejamos um cenário comum. À medida que servidores e outras infraestruturas atingem o fim da vida útil, a Contoso tem movido muitos aplicativos atualmente hospedados localmente para a nuvem. Os padrões de TI atuais exigem que os servidores que hospedam aplicativos corporativos estejam ingressados no mesmo domínio e gerenciados usando a política de grupo.

O administrador de TI da Contoso dá preferência ao ingresso no domínio de VMs implantadas no Azure para facilitar a administração, pois os usuários podem entrar usando suas credenciais corporativas. Quando ingressadas no domínio, as VMs também podem ser configuradas para atender às linhas de base de segurança necessárias usando objetos de política de grupo (GPOs). A Contoso prefere não ter que implantar, monitorar e gerenciar controladores de domínio próprios no Azure.

O Microsoft Entra Domain Services é uma grande vantagem para esse caso de uso. Um domínio gerenciado permite que você ingresse em VMs de domínio, use um único conjunto de credenciais e aplique políticas de grupo. Por se tratar de um domínio gerenciado, você não precisa configurar e manter os controladores de domínio por conta própria.

Observações de implantação

As seguintes considerações de implantação se aplicam a este exemplo de caso de uso:

  • Por padrão, os domínios gerenciados usam uma única estrutura de UO (unidade organizacional) simples. Todas as VMs conectadas ao domínio estão em uma só UO. Se desejar, você poderá criar UOs personalizadas.
  • O Microsoft Entra Domain Services usa um GPO interno para os contêineres de usuários e computadores. Para controle adicional, você pode criar GPOs personalizados e direcioná-los para UOs personalizadas.
  • O Microsoft Entra Domain Services dá suporte ao esquema do objeto de computador AD base. Não é possível estender o esquema do objeto de computador.

Aplicativos locais de lift-and-shift que usam a autenticação de associação LDAP

Como cenário de amostra, a Contoso dispõe de um aplicativo local comprado de um ISV há muitos anos. O aplicativo está atualmente no modo de manutenção pelo ISV e é extremamente caro solicitar alterações. Este aplicativo tem um front-end baseado na Web que coleta credenciais de usuário usando um formulário da Web e autentica usuários executando uma associação LDAP para o ambiente do AD DS local.

LDAP bind

A Contoso pretende migrar esse aplicativo para o Azure. O aplicativo deve continuar funcionando no estado em que se encontra, sem necessidade de alterações. Além disso, os usuários devem ser capazes de autenticar usando suas credenciais corporativas existentes e sem treinamento adicional. Deve estar transparente para os usuários finais onde o aplicativo está em execução.

Nesse cenário, o Microsoft Entra Domain Services permite que os aplicativos executem associações LDAP como parte do processo de autenticação. Os aplicativos locais herdados podem realizar lift-and-shift para o Azure e continuar a autenticar os usuários sem nenhuma alteração à configuração ou à experiência do usuário.

Observações de implantação

As seguintes considerações de implantação se aplicam a este exemplo de caso de uso:

  • Certifique-se de que o aplicativo não precise modificar/gravar no diretório. Não há suporte ao acesso de gravação LDAP em um domínio gerenciado.
  • Você não pode alterar as senhas diretamente em um domínio gerenciado. Os usuários finais podem alterar suas senhas seja usando o Mecanismo de alteração de senha de autoatendimento do Microsoft Entra, seja no diretório local. Essas alterações são automaticamente sincronizadas e disponibilizadas no domínio gerenciado.

Aplicativos locais de lift-and-shift que usam leitura do LDAP para acessar o diretório

Como no cenário de exemplo anterior, vamos supor que a Contoso tenha um aplicativo de linha de negócios (LOB) local que foi desenvolvido há quase uma década. Este aplicativo tem reconhecimento de diretório e foi projetado para usar LDAP para ler informações/atributos sobre os usuários do AD DS. O aplicativo não modifica atributos nem grava no diretório.

A Contoso deseja migrar esse aplicativo para o Azure e desativar o hardware local obsoleto que atualmente hospeda o aplicativo. O aplicativo não pode ser reescrito para usar APIs de diretório modernas, como a API do Microsoft Graph baseada em REST. É desejada uma opção de lift-and-shift em que o aplicativo possa ser migrado para execução na nuvem, sem que precise ser modificado o código ou reescrito o aplicativo.

Para ajudar nesse cenário, o Microsoft Entra Domain Services permite que os aplicativos executem leituras LDAP no domínio gerenciado para obter as informações de atributo de que precisa. O aplicativo não precisa ser reescrito, portanto, um lift-and-shift para o Azure permite que os usuários continuem a usar o aplicativo sem perceber que há uma alteração no local em que ele é executado.

Observações de implantação

As seguintes considerações de implantação se aplicam a este exemplo de caso de uso:

  • Certifique-se de que o aplicativo não precise modificar/gravar no diretório. Não há suporte ao acesso de gravação LDAP em um domínio gerenciado.
  • Verifique se o aplicativo não requer um esquema do Active Directory estendido/personalizado. O Microsoft Entra Domain Services não dá suporte a extensões de esquema.

Migrar um aplicativo de serviço ou daemon local para o Azure

Alguns aplicativos incluem várias camadas, em que uma das camadas precisa executar chamadas autenticadas para uma camada de back-end, como um banco de dados. As contas de serviço do AD costumam ser usadas nesses cenários. Ao realizar o lift-and-shift dos aplicativos para o Azure, o Microsoft Entra Domain Services permite que você continue a usar contas de serviço da mesma maneira. Você pode optar por usar a mesma conta de serviço que está sincronizada em seu diretório local para o Microsoft Entra ID ou criar uma UO personalizada e criar uma conta de serviço separada nessa UO. Com qualquer abordagem, os aplicativos continuam a funcionar da mesma maneira para fazer chamadas autenticadas para outras camadas e serviços.

Service account using WIA

Neste cenário de exemplo, a Contoso tem um aplicativo de vault de software personalizado que inclui um front-end da Web, um SQL Server e um servidor FTP de back-end. A autenticação integrada do Windows de contas de serviço é usada para autenticar o front-end da Web para o servidor FTP. O front-end da Web é configurado para execução como uma conta de serviço. O servidor back-end está configurado para autorizar o acesso da conta de serviço para o front-end da Web. A Contoso não pretende implantar e gerenciar suas próprias VMs do controlador de domínio na nuvem para mover esse aplicativo para o Azure.

Nesse cenário, os servidores que hospedam o front-end da Web, o SQL Server e o servidor FTP podem ser migrados para VMs do Azure e ingressados em um domínio gerenciado. As VMs podem usar a mesma conta de serviço no diretório local para fins de autenticação do aplicativo, que é sincronizado no Microsoft Entra ID usando o Microsoft Entra Connect.

Observações de implantação

As seguintes considerações de implantação se aplicam a este exemplo de caso de uso:

  • Certifique-se de que os aplicativos usem um nome de usuário e senha para autenticação. Não há suporte para autenticação com base em certificado ou cartão inteligente no Microsoft Entra Domain Services.
  • Você não pode alterar as senhas diretamente em um domínio gerenciado. Os usuários finais podem alterar suas senhas seja usando o Mecanismo de alteração de senha de autoatendimento do Microsoft Entra, seja no diretório local. Essas alterações são automaticamente sincronizadas e disponibilizadas no domínio gerenciado.

Implantações de serviços de área de trabalho remota do Windows Server

Você também pode usar o Microsoft Entra Domain Services para fornecer serviços de domínio gerenciado aos servidores de área de trabalho remota implantados no Azure.

Para saber mais sobre esse cenário de implantação, veja como integrar o Microsoft Entra Domain Services com a implantação do RDS.

Clusters HDInsight ingressados no domínio

Você pode configurar um cluster do Azure HDInsight que tenha ingressado em um domínio gerenciado com o Apache Ranger habilitado. Você pode criar e aplicar políticas de Hive por meio do Apache Ranger e permitir que usuários, como cientistas de dados, se conectem ao Hive usando ferramentas baseadas em ODBC como o Excel ou o tableau. Estamos trabalhando para adicionar outras cargas de trabalho, como HBase, Spark e Storm ao HDInsight ingressado no domínio.

Para obter mais informações sobre esse cenário de implantação, consulte como configurar clusters do HDInsight ingressados em domínio

Próximas etapas

Para começar, Crie e configure um domínio gerenciado do Microsoft Entra Domain Services.