Implementar e configurar o Microsoft Entra Domain Services

Concluído

As organizações que usam o Microsoft Entra ID somente na nuvem podem habilitar o Microsoft Entra Domain Services para uma VNet do Azure e, em seguida, obter um novo domínio gerenciado. Usuários e grupos no Microsoft Entra ID estão disponíveis no domínio recém-criado, que tem serviços de diretório semelhantes ao AD DS local, incluindo a Política de Grupo, o protocolo Kerberos e o suporte ao LDAP.

Você pode unir VMs do Azure executando o Windows ao domínio recém-criado e gerenciá-las usando as configurações básicas de Política de Grupo. Ao habilitar o Microsoft Entra Domain Services, os hashes de credencial necessários para autenticação NTLM e Kerberos são armazenados no Microsoft Entra ID.

Como a Contoso é uma organização híbrida, ela pode integrar suas identidades do AD DS local com o Microsoft Entra Domain Services usando o Microsoft Entra Connect. Os usuários em organizações híbridas podem ter a mesma experiência ao acessar recursos baseados em domínio em uma infraestrutura local ou ao acessar recursos de VMs executadas em uma rede virtual do Azure que se integra ao Microsoft Entra Domain Services.

Implementar o Microsoft Entra Domain Services

Para implementar, configurar e usar o Microsoft Entra Domain Services, você deve ter um locatário do Microsoft Entra criado em uma assinatura do Microsoft Entra. Além disso, para usar o Microsoft Entra Domain Services, você deve ter a sincronização de hash de senha implantada com o Microsoft Entra Connect. Isso é necessário porque o Microsoft Entra Domain Services fornece autenticação NTLM e Kerberos, portanto, as credenciais dos usuários são necessárias.

Ao habilitar o Microsoft Entra Domain Services para o seu locatário, você precisa selecionar o nome de domínio DNS que usará para esse serviço. Você também precisa selecionar o domínio que será sincronizado com seu ambiente local.

Cuidado

Você não deve usar um espaço de nome de domínio DNS local ou do Azure existente.

A tabela a seguir descreve as opções de nome de domínio DNS disponíveis.

Opção Descrição
Nome de domínio interno Por padrão, o nome de domínio interno do diretório é usado (sufixo. onmicrosoft.com). Se quiser habilitar o acesso LDAP Seguro ao domínio gerenciado pela Internet, você não poderá criar um certificado digital para proteger a conexão com esse domínio padrão. A Microsoft é proprietária do domínio .onmicrosoft.com, portanto, nenhuma AC (Autoridade de Certificação) emitirá um certificado.
Nomes de domínio personalizados A abordagem mais comum é especificar um nome de domínio personalizado, normalmente um que você já tenha e seja roteável. Quando você usa um domínio roteável personalizado, o tráfego pode fluir corretamente conforme necessário para dar suporte aos seus aplicativos.
Sufixos de domínio não roteáveis De modo geral, recomendamos que você evite sufixos de nome de domínio não roteáveis, tal como contoso.local. O sufixo .local não é roteável e pode causar problemas com a resolução DNS.

Dica

Talvez seja necessário criar alguns registros DNS adicionais para outros serviços no ambiente ou encaminhadores DNS condicionais entre os namespaces DNS no ambiente.

Uma captura de tela da guia Noções básicas no Assistente para criar serviços de domínio do Microsoft Entra no portal do Azure. As configurações foram definidas da seguinte forma: O grupo de recursos é ContosoResourceGroup, o nome de domínio DNS é ContosoDemo.com e o SKU é Enterprise.

Durante a implementação, você também deve selecionar o tipo de floresta a ser provisionada. Uma floresta é um constructo lógico usado pelo AD DS para agrupar um ou mais domínios. Há dois tipos de floresta, conforme descrito na tabela a seguir.

Tipo de floresta Descrição
Usuário Esse tipo de floresta sincroniza todos os objetos do Microsoft Entra ID, incluindo qualquer conta de usuário criada em um ambiente do AD DS local.
Recurso Esse tipo de floresta sincroniza somente usuários e grupos criados diretamente no Microsoft Entra ID.

Em seguida, será necessário escolher a localização do Azure no qual o domínio gerenciado deve ser criado. Se você escolher uma região que dê suporte a zonas de disponibilidade, os recursos do Microsoft Entra Domain Services serão distribuídos entre zonas para redundância adicional.

Observação

Você não precisa configurar o Microsoft Entra Domain Services para ser distribuído entre zonas. A plataforma do Azure gerencia automaticamente a distribuição de recursos em zonas.

Você também deve selecionar uma VNet à qual vai conectar esse serviço. Como o Microsoft Entra Domain Services fornece funcionalidades para recursos locais, você deve ter uma VNet entre seus ambientes locais e do Azure.

Uma captura de tela da guia Rede no Assistente para Criar Serviços de Domínio Microsoft Entra no portal do Azure. O administrador inseriu os detalhes da rede virtual e da sub-rede.

Durante o provisionamento, o Microsoft Entra Domain Services cria dois aplicativos empresariais em seu locatário do Microsoft Entra. Esses aplicativos são necessários para atender ao domínio gerenciado, portanto, você não deve excluí-los. Os aplicativos empresariais são:

  • Serviços do controlador de domínio.
  • AzureActiveDirectoryDomainControllerServices.

Depois de implantar a instância do Microsoft Entra Domain Services, você deve configurar a VNet para habilitar outras VMs e aplicativos conectados a usar o domínio gerenciado. Para fornecer essa conectividade, você deve atualizar as configurações do servidor DNS para sua VNet para apontar para os endereços IP associados à instância do Microsoft Entra Domain Services.

Para autenticar usuários no domínio gerenciado, o Microsoft Entra Domain Services precisa de hashes de senha em um formato adequado para autenticação NTLM e Kerberos. O Microsoft Entra ID não gera nem armazena hashes de senha no formato exigido para autenticação NTLM ou Kerberos até que você habilite o Microsoft Entra Domain Services para seu locatário. Por motivos de segurança, a ID do Microsoft Entra também não armazena nenhuma credencial de senha no formato de texto não criptografado. Portanto, o Microsoft Entra ID não pode gerar automaticamente essas hashes de senha NTLM ou Kerberos com base nas credenciais existentes dos usuários. Depois que os hashes de senha utilizáveis são configurados, eles são armazenados no domínio gerenciado pelo Microsoft Entra Domain Services.

Observação

Se você excluir o domínio gerenciado do Microsoft Entra Domain Services, todos os hashes de senha armazenados nesse ponto também serão excluídos.

As informações de credencial sincronizadas no Microsoft Entra ID não poderão ser reutilizadas se você criar posteriormente um domínio gerenciado pelo Microsoft Entra Domain Services. Você deve reconfigurar a sincronização de hash de senha para armazenar os hashes de senha novamente. Anteriormente, VMs ou usuários ingressados no domínio não poderão se autenticar imediatamente – o Microsoft Entra ID precisa gerar e armazenar os hashes de senha no novo domínio gerenciado do Microsoft Entra Domain Services.

As etapas para gerar e armazenar esses hashes de senha são diferentes para as contas de usuário somente em nuvem criadas no Microsoft Entra ID versus as contas de usuário sincronizadas do seu diretório local usando o Microsoft Entra Connect. Uma conta de usuário somente na nuvem é uma conta que foi criada no diretório do Microsoft Entra usando o portal do Azure ou os cmdlets do Microsoft Graph PowerShell. Essas contas de usuário não são sincronizadas de um diretório local.

Para contas de usuário somente na nuvem, os usuários devem alterar suas senhas antes de poderem usar o Microsoft Entra Domain Services. Esse processo de alteração de senha faz com que os hashes de senha para autenticação Kerberos e autenticação NTLM sejam gerados e armazenados no Microsoft Entra ID. A conta não é sincronizada do Microsoft Entra ID para o Microsoft Entra Domain Services até que a senha seja alterada. Expire as senhas para todos os usuários de nuvem no locatário que precisam usar o Microsoft Entra Domain Services, o que forçará uma alteração de senha na próxima entrada, ou instrua os usuários de nuvem a alterar manualmente suas senhas.

Dica

Antes que um usuário possa redefinir sua senha, você deve configurar o locatário do Microsoft Entra para redefinição de senha self-service.

Leituras adicionais

Para saber mais, examine os documentos a seguir.