Conceitos de gerenciamento para contas de usuário, senhas e administração nos Serviços de Domínio do Microsoft Entra
Quando você cria e executa um domínio gerenciado dos Serviços de Domínio Microsoft Entra, há algumas diferenças de comportamento em comparação com um ambiente AD DS local tradicional. Você usa as mesmas ferramentas administrativas nos Serviços de Domínio como um domínio autogerenciado, mas não pode acessar diretamente os controladores de domínio (DC). Existem também algumas diferenças no comportamento das políticas de palavras-passe e hashes de palavras-passe dependendo da origem da criação da conta de utilizador.
Este artigo conceitual detalha como administrar um domínio gerenciado e o comportamento diferente das contas de usuário, dependendo da maneira como elas são criadas.
Gestão 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. Não é possível entrar nesses DCs para executar tarefas de gerenciamento. Em vez disso, crie uma VM de gerenciamento que ingresse no domínio gerenciado e instale suas ferramentas de gerenciamento regulares do AD DS. Você pode usar os snap-ins do Centro Administrativo do Ative Directory ou do MMC (Console de Gerenciamento Microsoft), como DNS ou objetos de Diretiva de Grupo, por exemplo.
Criação de conta de utilizador
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 a partir da ID do Microsoft Entra, que também pode incluir a conta de usuário sincronizada a partir de um ambiente AD DS local. Você também pode criar contas manualmente diretamente no domínio gerenciado. Alguns recursos, como a sincronização inicial de senha 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 contas de usuário somente na nuvem criadas diretamente no Microsoft Entra ID e contas de usuário híbridas sincronizadas a partir de um ambiente AD DS local usando o Microsoft Entra Connect.
- A maioria das contas de usuário em um domínio gerenciado é criada através do processo de sincronização do Microsoft Entra ID.
- A conta de usuário pode ser criada manualmente em um domínio gerenciado e 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, poderá criá-las manualmente no domínio gerenciado. Como a sincronização é uma forma de ID do Microsoft Entra, as contas de usuário criadas no domínio gerenciado não são sincronizadas de volta com o ID do Microsoft Entra.
Política de palavras-passe
Os Serviços de Domínio incluem uma política de senha padrão que define configurações para coisas como bloqueio de conta, idade máxima da senha e complexidade da senha. Configurações como a 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 comprimento mínimo da senha 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 específicos de usuários, conforme necessário.
Para obter mais informações sobre as diferenças na forma como as políticas de senha são aplicadas, dependendo da origem de criação do usuário, consulte Políticas de bloqueio de senha e conta em domínios gerenciados.
Hashes de palavras-passe
Para autenticar usuários no domínio gerenciado, os Serviços de Domínio precisam de hashes de senha em um formato adequado para autenticação NT LAN Manager (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 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.
Para contas de usuário somente na nuvem, os usuários devem alterar suas senhas antes de poderem usar o domínio gerenciado. Esse processo de alteração de senha faz com que os hashes de senha para autenticação Kerberos e 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 até que a senha seja alterada.
Para usuários sincronizados a partir de um ambiente AD DS local usando o Microsoft Entra Connect, habilite a sincronização de hashes de senha.
Importante
O Microsoft Entra Connect só sincroniza 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ê usar apenas o Microsoft Entra Connect para sincronizar um ambiente AD DS local com a ID do Microsoft Entra.
Se seus aplicativos herdados não usarem autenticação NTLM ou ligações simples LDAP, recomendamos que você desabilite a sincronização de hash de senha NTLM para Serviços de Domínio. Para obter mais informações, veja Desativar os conjuntos de cifras fracos e a sincronização do hash de credenciais NTLM.
Uma vez corretamente configurados, os hashes de palavra-passe utilizáveis são armazenados no domínio gerido. Se eliminar o domínio gerido, todos os hashes de palavras-passe armazenados nessa altura também serão eliminados. As informações de credenciais sincronizadas no Microsoft Entra ID não podem ser reutilizadas se você criar posteriormente outro domínio gerenciado - você deve reconfigurar a sincronização de hash de senha para armazenar os hashes de senha novamente. VMs ou usuários anteriormente ingressados no 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. Para obter mais informações, consulte Processo de sincronização de hash de senha para 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 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.
Florestas e confianças
Uma floresta é uma construção lógica usada pelos Serviços de Domínio Ative Directory (AD DS) 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.
Nos Serviços de Domínio, a floresta contém apenas um domínio. As florestas locais do AD DS geralmente contêm muitos domínios. Em grandes organizações, especialmente após fusões e aquisições, você pode acabar com várias florestas locais que, em seguida, contêm vários domínios.
Por padrão, um domínio gerenciado sincroniza todos os objetos da ID do Microsoft Entra, incluindo quaisquer contas de usuário criadas em um ambiente AD DS local. As contas de usuário podem se autenticar diretamente no domínio gerenciado, como para entrar em uma VM associada 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 exclusivos de entrada, como a autenticação de cartão inteligente.
Em um Serviços de Domínio, você também pode criar uma relação de confiança de floresta unidirecional para permitir que os usuários entrem a partir do AD DS local. Com essa abordagem, os objetos de usuário e hashes de senha não são sincronizados com os Serviços de Domínio. Os objetos de usuário e as credenciais só existem no AD DS local. Essa abordagem permite que as empresas hospedem recursos e plataformas de aplicativos no Azure que dependem da autenticação clássica, como LDAPS, Kerberos ou NTLM, mas quaisquer problemas ou preocupações de autenticação são removidos.
SKUs de Serviços de Domínio
Nos Serviços de Domínio, 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 à medida que seus requisitos de negócios mudam após a implantação do domínio gerenciado. A tabela a seguir descreve as SKUs disponíveis e as diferenças entre elas:
| Nome da SKU | Contagem máxima de objetos | Frequência de cópia de segurança |
|---|---|---|
| Standard | Ilimitado | De 5 em 5 dias |
| Grandes Empresas | Ilimitado | De 3 em 3 dias |
| Premium | Ilimitado | Diariamente |
Antes dessas SKUs de Serviços de Domínio, era usado um modelo de cobrança baseado no número de objetos (contas de usuário e 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 dos Serviços de Domínio.
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 sua empresa ou aplicativo exigir alterações e você precisar de poder de computação adicional para seu domínio gerenciado, você poderá alternar para uma SKU diferente.
Frequência de cópia de segurança
A frequência de backup determina a frequência com que um instantâneo do domínio gerenciado é tirado. Os backups são um processo automatizado gerenciado pela plataforma Azure. Caso ocorram problemas com o domínio gerido, o suporte do Azure pode ajudar a restaurar a partir da cópia de segurança. Como a sincronização ocorre apenas de uma forma a partir da ID do Microsoft Entra, quaisquer problemas em um domínio gerenciado não afetarão a ID do Microsoft Entra ou os ambientes e a funcionalidade do AD DS local.
À medida que o nível de SKU aumenta, a frequência desses snapshots de backup aumenta. Analise seus requisitos de negócios e RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para determinar a frequência de backup necessária para seu domínio gerenciado. Se os requisitos da sua empresa ou aplicativo mudarem e você precisar de backups mais frequentes, poderá alternar para uma SKU diferente.
Próximos passos
Para começar, crie um domínio gerenciado pelos Serviços de Domínio.