Implementar e configurar os Serviços de Domínio Microsoft Entra

Concluído

As organizações que usam a ID do Microsoft Entra somente na nuvem podem habilitar os Serviços de Domínio do Microsoft Entra para uma VNet do Azure e, em seguida, obter um novo domínio gerenciado. Os 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 Diretiva de Grupo, protocolo Kerberos e suporte a LDAP.

Você pode associar VMs do Azure que executam o Windows ao domínio recém-criado e pode gerenciá-las usando configurações básicas de Política de Grupo. Ao habilitar os Serviços de Domínio do Microsoft Entra, os hashes de credenciais necessários para a autenticação NTLM e Kerberos são armazenados na ID do Microsoft Entra.

Como a Contoso é uma organização híbrida, eles podem integrar suas identidades do AD DS local com os Serviços de Domínio Microsoft Entra 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 aos Serviços de Domínio Microsoft Entra.

Implementar os Serviços de Domínio do Microsoft Entra

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

Quando ativa os Serviços de Domínio Microsoft Entra para o seu inquilino, tem de selecionar o nome de domínio DNS que irá utilizar para este serviço. Você também precisa selecionar o domínio que sincronizará com seu ambiente local.

Atenção

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

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

Opção Description
Nome de domínio integrado Por padrão, o nome de domínio interno do diretório é usado (um sufixo .onmicrosoft.com). Se você quiser habilitar o acesso LDAP seguro ao domínio gerenciado pela Internet, 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, uma Autoridade de Certificação (CA) nã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á possui e é roteável. Quando você usa um domínio roteável e personalizado, o tráfego pode fluir corretamente conforme necessário para dar suporte aos seus aplicativos.
Sufixos de domínio não roteáveis Geralmente, recomendamos que você evite um sufixo de nome de domínio não roteável, como contoso.local. O sufixo .local não é roteável e pode causar problemas com a resolução de DNS.

Gorjeta

Talvez seja necessário criar registros DNS adicionais para outros serviços em seu ambiente ou encaminhadores DNS condicionais entre namespaces DNS existentes em seu 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: Grupo de recursos é ContosoResourceGroup, nome de domínio DNS é ContosoDemo.com e SKU é Enterprise.

Durante a implementação, você também deve selecionar qual tipo de floresta provisionar. Uma floresta é uma construção lógica usada pelo AD DS para agrupar um ou mais domínios. Há dois tipos de floresta, conforme descrito na tabela a seguir.

Tipo de floresta Description
User Esse tipo de floresta sincroniza todos os objetos da ID do Microsoft Entra, incluindo todas as contas de usuário criadas em um ambiente AD DS local.
Recurso Esse tipo de floresta sincroniza apenas usuários e grupos criados diretamente no Microsoft Entra ID.

Em seguida, você precisará escolher o local do Azure no qual o domínio gerenciado deve ser criado. Se você escolher uma região que ofereça suporte a zonas de disponibilidade, os recursos dos Serviços de Domínio Microsoft Entra serão distribuídos entre zonas para redundância adicional.

Nota

Não é necessário configurar os Serviços de Domínio Microsoft Entra para serem distribuídos entre zonas. A plataforma Azure gerencia automaticamente a distribuição de recursos por zona.

Você também deve selecionar uma VNet à qual você conectará este serviço. Como os Serviços de Domínio Microsoft Entra fornecem funcionalidades para recursos locais, você deve ter uma VNet entre seus ambientes locais e do Azure.

Uma captura de ecrã do separador 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, os Serviços de Domínio do Microsoft Entra criam dois aplicativos corporativos em seu locatário do Microsoft Entra. Esses aplicativos são necessários para atender seu domínio gerenciado e, portanto, você não deve excluir esses aplicativos. As aplicações empresariais são:

  • Serviços de Controlador de Domínio.
  • AzureActiveDirectoryDomainControllerServices.

Depois de implantar a instância dos Serviços de Domínio Microsoft Entra, você deve configurar a VNet para permitir que outras VMs e aplicativos conectados usem o domínio gerenciado. Para fornecer essa conectividade, você deve atualizar as configurações do servidor DNS para sua rede virtual para apontar para os endereços IP associados à sua instância dos Serviços de Domínio Microsoft Entra.

Para autenticar usuários no domínio gerenciado, os Serviços de Domínio Microsoft Entra precisam 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 necessário para autenticação NTLM ou Kerberos até que você habilite os Serviços de Domínio Microsoft Entra para seu locatário. Por motivos de segurança, o Microsoft Entra ID também não armazena credenciais de senha em formato de texto não criptografado. Portanto, o Microsoft Entra ID não pode gerar automaticamente esses 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 pelos Serviços de Domínio do Microsoft Entra.

Nota

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

As informações de credenciais sincronizadas no Microsoft Entra ID não podem ser reutilizadas se você criar posteriormente um domínio gerenciado pelos Serviços de Domínio do Microsoft Entra - você deve reconfigurar a sincronização de hash de senha para armazenar os hashes de senha novamente. VMs ou usuários anteriormente associados ao domínio não poderão se autenticar imediatamente - o ID do Microsoft Entra precisa gerar e armazenar os hashes de senha no novo domínio gerenciado dos Serviços de Domínio Microsoft Entra.

As etapas para gerar e armazenar esses hashes de senha são diferentes para contas de usuário somente na nuvem criadas no ID do Microsoft Entra versus contas de usuário sincronizadas do 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 cmdlets do Microsoft Graph PowerShell . Essas contas de usuário não são sincronizadas a partir de um diretório local.

Para contas de usuário somente na nuvem, os usuários devem alterar suas senhas antes de poderem usar os Serviços de Domínio Microsoft Entra. 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 ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra até que a senha seja alterada. Expire as senhas para todos os usuários de nuvem no locatário que precisam usar os Serviços de Domínio Microsoft Entra, o que força uma alteração de senha na próxima entrada, ou instrua os usuários de nuvem a alterar manualmente suas senhas.

Gorjeta

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

Leitura adicional

Para saber mais, consulte os seguintes documentos.