Conceitos de gerenciamento para contas de usuário, senhas e administração no Microsoft Entra Domain Services

Quando você cria e executa um domínio gerenciado do Microsoft Entra Domain Services, há algumas diferenças no comportamento em comparação com um ambiente do AD DS local tradicional. Você usa as mesmas ferramentas administrativas no Domain Services como um domínio autogerenciado, mas não pode acessar diretamente os controladores de domínio (DC). Há também algumas diferenças no comportamento de políticas de senha e hashes de senha, dependendo da origem da criação da conta de usuário.

Este artigo conceitual fornece detalhes sobre como administrar um domínio gerenciado e o comportamento diferente de contas de usuário, dependendo da maneira como eles são criados.

Gerenciamento de domínios

Um domínio gerenciado é um namespace DNS e um diretório correspondente. Em um domínio gerenciado, os controladores de domínio (DCs) que contêm todos os recursos, como usuários e grupos, credenciais e políticas, fazem parte do serviço gerenciado. Para redundância, dois DCs são criados como parte de um domínio gerenciado. Você não pode entrar nesses DCs para executar tarefas de gerenciamento. Em vez disso, você cria uma VM de gerenciamento que ingressou no domínio gerenciado e, em seguida, instala suas ferramentas de gerenciamento do AD DS regulares. Você pode usar o Centro Administrativo do Active Directory ou snap-ins do MMC (Console de Gerenciamento da Microsoft), como o DNS ou objetos da Política de Grupo, por exemplo.

Usuário da conta de usuário

As contas de usuário podem ser criadas em um domínio gerenciado de várias maneiras. A maioria das contas de usuário é sincronizada no Microsoft Entra ID, que também pode incluir a conta de usuário sincronizada de um ambiente do AD DS local. Você também pode criar manualmente as contas diretamente no domínio gerenciado. Alguns recursos, como a sincronização de senha inicial ou a política de senha, se comportam de forma diferente dependendo de como e onde as contas de usuário são criadas.

• A conta de usuário pode ser sincronizada a partir do Microsoft Entra ID. Isso inclui as contas de usuário somente em nuvem criadas diretamente no Microsoft Entra ID e contas de usuário híbridas sincronizadas de um ambiente de AD DS local usando o Microsoft Entra Connect.
  • A maioria das contas de usuário em um domínio gerenciado é criada por meio do processo de sincronização do Microsoft Entra ID.
• A conta de usuário pode ser criada manualmente em um domínio gerenciado – ela não existe no Microsoft Entra ID.
  • Se você precisar criar contas de serviço para aplicativos que só são executados no domínio gerenciado, você pode criá-los manualmente no domínio gerenciado. Como a sincronização é unidirecional a partir do Microsoft Entra ID, as contas de usuário criadas no domínio gerenciado não são sincronizadas de volta para Microsoft Entra ID.

Política de senha

O Domain Services inclui uma política de senha padrão que define as configurações de itens como o bloqueio de conta, a duração máxima da senha e a complexidade da senha. Configurações como política de bloqueio de conta se aplicam a todos os usuários em um domínio gerenciado, independentemente de como o usuário foi criado, conforme descrito na seção anterior. Algumas configurações, como o tamanho mínimo e a complexidade da senha, só se aplicam a usuários criados diretamente em um domínio gerenciado.

Você pode criar suas próprias políticas de senha personalizadas para substituir a política padrão em um domínio gerenciado. Essas políticas personalizadas podem ser aplicadas a grupos de usuários específicos, conforme necessário.

Para obter mais informações sobre as diferenças de como as políticas de senha são aplicadas dependendo da origem da criação do usuário, confira Políticas de bloqueio de senha e conta em domínios gerenciados.

Hashes de senha

Para autenticar os usuários no domínio gerenciado, o Azure AD DS precisa de hashes de senha em um formato adequado para a autenticação NTLM (Gerenciador de LAN NT) e Kerberos. O Microsoft Entra ID não gera nem armazena hashes de senha no formato necessário para autenticação na NTLM ou Kerberos até que você ative o Domain Services para o 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.

Para contas de usuário somente de nuvem, os usuários devem alterar suas senhas antes de usar o domínio gerenciado. Esse processo de alteração de senhas faz com que as hashes de senha para a autenticação Kerberos e NTLM sejam geradas e armazenadas no Microsoft Entra ID. A conta não é sincronizada do Microsoft Entra ID para os Serviços de Domínio até que a senha seja alterada.

Para usuários sincronizados de um ambiente do AD DS local usando o Microsoft Entra Connect, habilite a sincronização de hashes de senha.

Importante

O Microsoft Entra Connect sincroniza apenas hashes de senha herdados quando você habilita os Serviços de Domínio para seu locatário do Microsoft Entra. Os hashes de senha herdados não serão usados se você utilizar o Microsoft Entra Connect apenas para sincronizar um ambiente do AD DS local com o Microsoft Entra ID.

Se os aplicativos herdados não usam autenticação NTLM ou associações simples LDAP, recomendamos desabilitar a sincronização de hash de senha NTLM para o Domain Services. Para obter mais informações, confira Desabilitar pacotes de codificação baixa e sincronização de hash de credencial NTLM.

Uma vez configurado adequadamente, as hashes de senha utilizáveis são armazenadas no domínio gerenciado. Se você excluir o domínio gerenciado, todas as hashes de senha armazenadas nesse ponto também serão excluídas. As informações de credenciais sincronizadas no Microsoft Entra ID não poderão ser reutilizadas se você criar posteriormente outro domínio gerenciado – você precisa reconfigurar a sincronização de hash de senha para armazenar os hashes de senha novamente. As VMs ou os usuários previamente unidos ao domínio não poderão autenticar imediatamente – o Microsoft Entra ID precisa gerar e armazenar as hashes de senha no novo domínio gerenciado. Para obter mais informações, confira Processo de sincronização de hash de senha para os Serviços de Domínio e Microsoft Entra Connect.

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.

Florestas e relações de confiança

Uma floresta é um constructo lógico usado pelo AD DS (Active Directory Domain Services) para agrupar um ou mais domínios. Em seguida, os domínios armazenam objetos para usuários ou grupos e fornecem serviços de autenticação.

No Domain Services, a floresta contém apenas um domínio. As florestas do AD DS locais geralmente contêm muitos domínios. Em grandes organizações, especialmente depois de fusões e aquisições, você poderá terminar com várias florestas locais que contêm vários domínios.

Por padrão, um domínio gerenciado sincroniza todos os objetos do Microsoft Entra ID, incluindo quaisquer contas de usuário criadas em um ambiente do AD DS local. As contas de usuário podem se autenticar diretamente no domínio gerenciado, por exemplo, para entrar em uma VM conectada ao domínio. Essa abordagem funciona quando os hashes de senha podem ser sincronizados e os usuários não estão usando métodos de conexão exclusivos, como a autenticação de cartão inteligente.

Nos Serviços de Domínio, também é possível criar uma relação de confiança entre florestas com outro domínio para permitir que os usuários acessem os recursos. Dependendo de seus requisitos de acesso, você pode criar a relação de confiança entre florestas em diferentes direções.

Direção da relação de confiança	Acesso do usuário
Bidirecional	Permite que os usuários no domínio gerenciado e no domínio local acessem recursos em ambos os domínios.
Unidirecional de saída	Permite que os usuários no domínio local acessem recursos no domínio gerenciado, mas não vice-versa.
Unidirecional de entrada	Permite que usuários no domínio gerenciado acessem recursos no domínio local.

SKUs dos Serviços de Domínio

No Domain Services, o desempenho e os recursos disponíveis são baseados na SKU. Você seleciona uma SKU ao criar o domínio gerenciado e pode alternar SKUs conforme os requisitos de negócios mudam após o domínio gerenciado ter sido implantado. A tabela a seguir descreve as SKUs disponíveis e as diferenças entre elas:

Nome do SKU	Contagem máxima de objetos	Frequência de backup
Standard	Ilimitado	A cada 5 dias
Enterprise	Ilimitado	A cada 3 dias
Premium	Ilimitado	Diariamente

Antes dessas SKUs do Domain Services, foi usado um modelo de cobrança baseado no número de objetos (contas de usuário e de computador) no domínio gerenciado. Não há mais preços variáveis com base no número de objetos no domínio gerenciado.

Para obter mais informações, consulte a página de preços do Domain Services.

Desempenho do domínio gerenciado

O desempenho do domínio varia de acordo com a forma como a autenticação é implementada para um aplicativo. Recursos de computação adicionais podem ajudar a melhorar o tempo de resposta da consulta e reduzir o tempo gasto em operações de sincronização. À medida que o nível de SKU aumenta, os recursos de computação disponíveis para o domínio gerenciado são aumentados. Monitore o desempenho de seus aplicativos e planeje os recursos necessários.

Se suas demandas de negócios ou aplicativos mudarem e você precisar de poder de computação adicional para seu domínio gerenciado, você poderá alternar para um SKU diferente.

Frequência de backup

A frequência de backup determina com que frequência um instantâneo do domínio gerenciado é obtido. Os backups são um processo automatizado gerenciado pela plataforma do Azure. No caso de um problema com seu domínio gerenciado, o suporte do Azure pode ajudá-lo na restauração a partir do backup. Como a sincronização ocorre apenas unidirecionalmente a partir do Microsoft Entra ID, quaisquer problemas em um domínio gerenciado não afetarão o Microsoft Entra ID ou os ambientes e funcionalidades do AD DS local.

À medida que o nível de SKU aumenta, a frequência desses instantâneos de backup aumenta. Examine os requisitos de negócios e o objetivo de ponto de recuperação (RPO) para determinar a frequência de backup necessária para seu domínio gerenciado. Se seus requisitos de negócios ou aplicativos forem alterados e você precisar de backups mais frequentes, você poderá alternar para um SKU diferente.

Os Serviços de Domínio fornecem as seguintes diretrizes para períodos de recuperação para diferentes tipos de problemas:

• O RPO (objetivo de ponto de recuperação) é o período máximo em que há uma perda potencial de dados ou transações de um incidente.
• O RTO (objetivo de tempo de recuperação) é o período de tempo de destino que ocorre antes que os níveis de serviço voltem a ficar operacionais após um incidente.

Problemas	RPO	RTO
Problemas causados por perda ou corrupção de dados em controladores de domínio dos Serviços de Domínio, serviços dependentes, uma exploração que comprometeu o domínio ou outro incidente que exija a restauração de um controlador de domínio.	Cinco dias antes da ocorrência do evento	Duas horas a quatro dias, dependendo do tamanho do locatário
Problemas identificados por nosso diagnóstico de domínio.	Zero (0 minutos)	Duas horas a quatro dias, dependendo do tamanho do locatário

Próximas etapas

Para começar, crie um domínio gerenciado do Domain Services.