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.
Em um Domain Services, você também pode criar uma relação de confiança de floresta unidirecional para permitir que os usuários entrem do AD DS local. Com essa abordagem, os objetos de usuário e os hashes de senha não são sincronizados com o Domain Services. Os objetos de usuário e as credenciais existem somente no AD DS local. Essa abordagem permite que as empresas hospedem recursos e plataformas de aplicativo no Azure que dependem da autenticação clássica, tais como LDAPS, Kerberos ou NTLM, mas todas as preocupações ou problemas de autenticação são removidos.
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.
Próximas etapas
Para começar, crie um domínio gerenciado do Domain Services.