Casos de uso e cenários comuns para os Serviços de Domínio Microsoft Entra
Os Serviços de Domínio Microsoft Entra fornecem serviços de domínio gerenciados, como ingresso no domínio, política de grupo, protocolo LDAP (lightweight directory access protocol) e autenticação Kerberos/NTLM. Os Serviços de Domínio do Microsoft Entra integram-se com o locatário existente do Microsoft Entra, o que possibilita que os usuários entrem usando suas credenciais existentes. Você usa esses serviços de domínio sem a necessidade de implantar, gerenciar e corrigir controladores de domínio na nuvem, o que fornece uma transferência mais suave de recursos locais para o Azure.
Este artigo descreve alguns cenários de negócios comuns em que os Serviços de Domínio Microsoft Entra fornecem valor e atendem a essas necessidades.
Formas comuns de fornecer soluções de identidade na nuvem
Quando você migra cargas de trabalho existentes para a nuvem, os aplicativos com reconhecimento de diretório podem usar LDAP para acesso de leitura ou gravação a um diretório do AD DS local. Os aplicativos executados no Windows Server geralmente são implantados em máquinas virtuais (VMs) associadas ao domínio para que possam ser gerenciados com segurança usando a Diretiva de Grupo. Para autenticar os usuários finais, os aplicativos também podem contar com a autenticação integrada ao Windows, como autenticação Kerberos ou NTLM.
Os administradores de TI geralmente usam uma das seguintes soluções para fornecer um serviço de identidade para aplicativos executados no Azure:
- Configure uma conexão VPN site a site entre cargas de trabalho executadas no Azure e um ambiente AD DS local.
- Em seguida, os controladores de domínio locais fornecem autenticação por meio da conexão VPN.
- Crie controladores de domínio de réplica usando máquinas virtuais (VMs) do Azure para estender o domínio/floresta do AD DS local.
- Os controladores de domínio executados em VMs do Azure fornecem autenticação e replicam informações de diretório entre o ambiente AD DS local.
- Implante um ambiente AD DS autônomo 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 não há informações de diretório replicadas de um ambiente AD DS local.
Com essas abordagens, as conexões VPN com o diretório local tornam os aplicativos vulneráveis a falhas ou interrupções transitórias da rede. Se você implantar controladores de domínio usando VMs no Azure, a equipe de TI deverá gerenciar as VMs e, em seguida, protegê-las, corrigi-las, monitorá-las, fazer backup e solucioná-las.
Os Serviços de Domínio Microsoft Entra oferecem alternativas à necessidade de criar conexões VPN de volta a um ambiente AD DS local 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 para criar uma solução de identidade integrada para ambientes híbridos e somente em nuvem.
Serviços de Domínio Microsoft Entra para organizações híbridas
Muitas organizações executam uma infraestrutura híbrida que inclui cargas de trabalho de aplicativos locais e na nuvem. Os aplicativos herdados migrados para o Azure como parte de uma estratégia de elevação e mudança podem usar conexões LDAP tradicionais para fornecer informações de identidade. Para dar suporte a essa infraestrutura híbrida, as informações de identidade de um ambiente AD DS local podem ser sincronizadas com um locatário do Microsoft Entra. Em seguida, os Serviços de Domínio Microsoft Entra fornecem esses aplicativos herdados no Azure com uma fonte de identidade, sem a necessidade de configurar e gerenciar a conectividade de aplicativos de volta aos serviços de diretório locais.
Vejamos um exemplo para a Litware Corporation, uma organização híbrida que executa recursos locais e do Azure:
- Aplicativos e 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 elevação e mudança.
- Para sincronizar as informações de identidade do diretório local com o locatário do Microsoft Entra, a Litware Corporation implanta o Microsoft Entra Connect.
- As informações de identidade sincronizadas incluem contas de usuário e associações de grupo.
- A equipe de TI da Litware habilita os Serviços de Domínio Microsoft Entra para seu locatário do Microsoft Entra nesta ou em uma rede virtual emparelhada.
- Os aplicativos e VMs implantados na rede virtual do Azure podem usar os recursos dos Serviços de Domínio Microsoft Entra, como ingresso no domínio, leitura LDAP, ligaçã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 AD DS locais. Não há suporte para instalar o Microsoft Entra Connect em um domínio gerenciado para sincronizar objetos de volta ao Microsoft Entra ID.
Serviços de domínio do Microsoft Entra para organizações somente na nuvem
Um locatário do Microsoft Entra somente na nuvem não tem uma fonte 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 para a Contoso, uma organização somente na nuvem que usa o Microsoft Entra ID para identidade. 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á nenhuma configuração adicional do Microsoft Entra Connect para sincronizar quaisquer informações de identidade de um diretório local.
- Aplicativos e 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 os Serviços de Domínio Microsoft Entra para seu locatário do Microsoft Entra nesta ou em uma rede virtual emparelhada.
- Os aplicativos e VMs implantados na rede virtual do Azure podem usar os recursos dos Serviços de Domínio Microsoft Entra, como ingresso no domínio, leitura LDAP, ligação LDAP, autenticação NTLM e Kerberos e Política de Grupo.
Administração segura de máquinas virtuais do Azure
Para permitir que você use um único conjunto de credenciais do AD, as máquinas virtuais (VMs) do Azure podem ser associadas a um domínio gerenciado dos Serviços de Domínio Microsoft Entra. Essa abordagem reduz problemas de gerenciamento de credenciais, como a manutenção de contas de administrador local em cada VM ou contas e senhas separadas entre ambientes.
As VMs que ingressaram em um domínio gerenciado também podem ser administradas e protegidas usando a diretiva 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 corporativas. Por exemplo, você pode usar os recursos de gerenciamento de diretiva de grupo para restringir os tipos de aplicativos que podem ser iniciados na VM.
Vejamos um cenário de exemplo comum. À medida que os servidores e outras infraestruturas atingem o fim da vida útil, a Contoso deseja mover os aplicativos atualmente hospedados no local para a nuvem. Seu padrão de TI atual determina que os servidores que hospedam aplicativos corporativos devem ingressar no domínio e ser gerenciados usando a política de grupo.
O administrador de TI da Contoso prefere ingressar 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 cumprir as linhas de base de segurança necessárias usando GPOs (objetos de diretiva de grupo). A Contoso preferiria não implantar, monitorar e gerenciar seus próprios controladores de domínio no Azure.
Os Serviços de Domínio Microsoft Entra são uma ótima opção para este caso de uso. Um domínio gerenciado permite que você ingresse em VMs de domínio, use um único conjunto de credenciais e aplique a política de grupo. E como é um domínio gerenciado, você não precisa configurar e manter os controladores de domínio por conta própria.
Notas de implantação
As seguintes considerações de implantação se aplicam a este caso de uso de exemplo:
- Os domínios gerenciados usam uma estrutura única e simples de Unidade Organizacional (UO) por padrão. Todas as VMs associadas ao domínio estão em uma única UO. Se desejar, você pode criar UOs personalizadas.
- Os Serviços de Domínio Microsoft Entra usam um GPO interno para os contêineres de usuários e computadores. Para obter controle adicional, você pode criar GPOs personalizados e direcioná-los para UOs personalizadas.
- Os Serviços de Domínio Microsoft Entra suportam o esquema de objeto de computador do AD base. Não é possível estender o esquema do objeto de computador.
Aplicativos locais de elevação e deslocamento que usam autenticação de associação LDAP
Como um cenário de exemplo, a Contoso tem um aplicativo local que foi comprado de um ISV há muitos anos. O aplicativo está atualmente em modo de manutenção pelo ISV e solicitar alterações no aplicativo é proibitivamente caro. Este aplicativo tem um frontend baseado na Web que coleta credenciais de usuário usando um formulário da Web e, em seguida, autentica os usuários executando uma associação LDAP ao ambiente AD DS local.
A Contoso gostaria de migrar este aplicativo para o Azure. O aplicativo deve continuar a funcionar como está, 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. Ele deve ser transparente para os usuários finais onde o aplicativo está sendo executado.
Para esse cenário, os Serviços de Domínio do Microsoft Entra permitem que os aplicativos executem associações LDAP como parte do processo de autenticação. Os aplicativos locais herdados podem migrar para o Azure e continuar a autenticar usuários sem qualquer alteração na configuração ou na experiência do usuário.
Notas de implantação
As seguintes considerações de implantação se aplicam a este caso de uso de exemplo:
- Certifique-se de que o aplicativo não precisa modificar/gravar no diretório. O acesso de gravação LDAP a um domínio gerenciado não é suportado.
- Não é possível alterar senhas diretamente em um domínio gerenciado. Os usuários finais podem alterar suas senhas usando o mecanismo de alteração de senha de autoatendimento do Microsoft Entra ou no diretório local. Essas alterações são então sincronizadas automaticamente e ficam disponíveis no domínio gerenciado.
Aplicativos locais de elevação e deslocamento que usam leitura LDAP para acessar o diretório
Como o 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 reconhece diretório e foi projetado para usar LDAP para ler informações/atributos sobre usuários do AD DS. O aplicativo não modifica atributos ou grava no diretório.
A Contoso deseja migrar esse aplicativo para o Azure e desativar o hardware local antigo que atualmente hospeda esse aplicativo. O aplicativo não pode ser reescrito para usar APIs de diretório modernas, como a API do Microsoft Graph baseada em REST. Uma opção lift-and-shift é desejada onde o aplicativo pode ser migrado para ser executado na nuvem, sem modificar o código ou reescrever o aplicativo.
Para ajudar com esse cenário, os Serviços de Domínio do Microsoft Entra permitem que os aplicativos executem leituras LDAP no domínio gerenciado para obter as informações de atributo necessárias. O aplicativo não precisa ser reescrito, portanto, um lift-and-shift no Azure permite que os usuários continuem a usar o aplicativo sem perceber que há uma mudança no local onde ele é executado.
Notas de implantação
As seguintes considerações de implantação se aplicam a este caso de uso de exemplo:
- Certifique-se de que o aplicativo não precisa modificar/gravar no diretório. O acesso de gravação LDAP a um domínio gerenciado não é suportado.
- Verifique se o aplicativo não precisa de um esquema do Ative Directory personalizado/estendido. As extensões de esquema não são suportadas nos Serviços de Domínio Microsoft Entra.
Migrar um serviço local ou aplicativo daemon para o Azure
Alguns aplicativos incluem várias camadas, onde 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 são normalmente utilizadas nestes cenários. Quando você eleva e desloca aplicativos para o Azure, os Serviços de Domínio do Microsoft Entra permitem que você continue a usar contas de serviço da mesma maneira. Você pode optar por usar a mesma conta de serviço sincronizada do diretório local para a ID do Microsoft Entra ou criar uma UO personalizada e, em seguida, criar uma conta de serviço separada nessa UO. Com qualquer uma das abordagens, os aplicativos continuam a funcionar da mesma maneira para fazer chamadas autenticadas para outros níveis e serviços.
Neste cenário de exemplo, a Contoso tem um aplicativo de cofre de software personalizado que inclui um front-end da Web, um servidor SQL e um servidor FTP de back-end. A autenticação integrada ao Windows usando contas de serviço autentica o front-end da Web no servidor FTP. O front-end da Web está configurado para ser executado 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 deseja implantar e gerenciar suas próprias VMs de controlador de domínio na nuvem para mover esse aplicativo para o Azure.
Para esse 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 em seu diretório local para fins de autenticação do aplicativo, que é sincronizado por meio do Microsoft Entra ID usando o Microsoft Entra Connect.
Notas de implantação
As seguintes considerações de implantação se aplicam a este caso de uso de exemplo:
- Certifique-se de que os aplicativos usam um nome de usuário e senha para autenticação. A autenticação baseada em certificado ou cartão inteligente não é suportada pelos Serviços de Domínio Microsoft Entra.
- Não é possível alterar senhas diretamente em um domínio gerenciado. Os usuários finais podem alterar suas senhas usando o mecanismo de alteração de senha de autoatendimento do Microsoft Entra ou no diretório local. Essas alterações são então sincronizadas automaticamente e ficam disponíveis no domínio gerenciado.
Implantações de serviços de área de trabalho remota do Windows Server no Azure
Você pode usar os Serviços de Domínio do Microsoft Entra para fornecer serviços de domínio gerenciado para servidores de área de trabalho remota implantados no Azure.
Para obter mais informações sobre esse cenário de implantação, consulte como integrar os Serviços de Domínio Microsoft Entra à sua implantação do RDS.
Clusters HDInsight ingressados no domínio
Você pode configurar um cluster do Azure HDInsight que ingressa em um domínio gerenciado com o Apache Ranger habilitado. Você pode criar e aplicar políticas do 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 Excel ou Tableau. Continuamos a trabalhar para adicionar outras cargas de trabalho, como HBase, Spark e Storm, ao HDInsight associado ao domínio.
Para obter mais informações sobre esse cenário de implantação, consulte como configurar clusters HDInsight ingressados no domínio
Próximos passos
Para começar, crie e configure um domínio gerenciado dos Serviços de Domínio Microsoft Entra.