Esta seção fornece respostas para perguntas frequentes sobre a Proteção de Senha do Microsoft Entra.
Perguntas gerais
Que diretrizes os usuários devem receber sobre como selecionar uma senha segura?
A diretriz atual da Microsoft sobre este tópico pode ser encontrada no seguinte link:
Diretrizes de Senha da Microsoft
O Microsoft Entra Password Protection local tem suporte em nuvens não públicas?
O Microsoft Entra Password Protection local tem suporte em nuvens do Azure Global e do Azure Governamental.
O centro de administração do Microsoft Entra permite a modificação da configuração específica do local "Proteção por senha para Windows Server Active Directory" em nuvens sem suporte; tais mudanças persistem, mas nunca entram em vigor. O registro de agentes proxy ou florestas locais não tem suporte em nuvens sem suporte e essas tentativas de registro sempre falham.
Como posso aplicar os benefícios da Proteção de Senha do Microsoft Entra a um subconjunto de meus usuários locais?
Não há suporte. Depois de implantada e habilitada, a Proteção por Senha do Microsoft Entra se aplica igualmente a todos os usuários.
Qual é a diferença entre uma alteração de senha e uma definição (ou redefinição) de senha?
Uma alteração de senha ocorre quando um usuário escolhe uma nova senha depois de provar que tem conhecimento da senha antiga. Por exemplo, uma alteração de senha é o que acontece quando um usuário faz logon no Windows e, em seguida, é solicitado a escolher uma nova senha.
Uma definição de senha (às vezes chamado de redefinição de senha) ocorre quando um administrador substitui a senha de uma conta por uma nova, por exemplo, usando a ferramenta de gerenciamento de usuários e computadores do Active Directory. Essa operação requer um alto nível de privilégio (geralmente Administrador de Domínio) e a pessoa que executa a operação geralmente não tem conhecimento da senha antiga. Os cenários de suporte técnico geralmente executam conjuntos de senhas, por exemplo, ao ajudar um usuário que esqueceu sua senha. Você também verá eventos de definição de senha quando uma nova conta de usuário for criada pela primeira vez com uma senha.
A política de validação de senha comporta-se do mesmo jeito, independentemente da execução de uma alteração ou definição de senha. O serviço Agente de DC da Proteção de Senha do Microsoft Entra registra em log eventos diferentes que indicam quando uma operação de alteração ou definição de senha é feita. Confira Monitoramento e registro em log da Proteção de Senha do Microsoft Entra.
O Microsoft Entra Password Protection valida as senhas existentes após a instalação?
Não – a Proteção de Senha do Microsoft Entra só pode impor a política de senha em senhas cleartext durante uma operação de alteração ou definição de senha. Depois que o Active Directory aceita uma senha, somente hashes específicos do protocolo de autenticação dessa senha são mantidos. A senha de texto não criptografado nunca é mantida, portanto, a Proteção de Senha do Microsoft Entra não pode validar senhas existentes.
Após a implantação inicial do Microsoft Entra Password Protection, todos os usuários e contas eventualmente começarão a usar uma senha validada pela Proteção de Senha do Microsoft Entra à medida que suas senhas existentes expirarem normalmente ao longo do tempo. Se desejar, você pode acelerar esse processo por meio de uma expiração manual única das senhas da conta do usuário.
As contas configuradas com "a senha nunca expira" não são forçadas a alterar sua senha, a menos que a expiração manual seja feita.
Por que os eventos de rejeição de senhas duplicadas são registrados ao tentar definir uma senha fraca usando o snap-in de gerenciamento de usuários e computadores do AD DS?
O snap-in de gerenciamento de Usuários e Computadores do Active Directory primeiro tenta definir a nova senha usando o protocolo Kerberos. Em caso de falha, o snap-in faz uma segunda tentativa de definir a senha usando um protocolo herdado (SAM RPC). Os protocolos específicos usados não são importantes. Se a nova senha for considerada fraca pela Proteção de Senha do Microsoft Entra, esse comportamento de snap-in produzirá dois conjuntos de eventos de rejeição de redefinição de senha sendo registrados.
Por que os eventos de validação de senha do Microsoft Entra Password Protection estão sendo registrados com um nome de usuário vazio?
O Active Directory permite testar uma senha para ver se ela passa pelos requisitos de complexidade de senha atuais do domínio, por exemplo, usando a API NetValidatePasswordPolicy. Quando uma senha é validada dessa maneira, o teste também inclui a validação por produtos baseados em DLL de filtro de senha, como a Proteção de Senha do Microsoft Entra, mas os nomes de usuário passados para uma determinada DLL de filtro de senha estão vazios. Nesse cenário, a Proteção de Senha do Microsoft Entra ainda valida a senha usando a política de senha atualmente em vigor e emite uma mensagem de log de eventos para capturar o resultado. No entanto, a mensagem do log de eventos terá campos de nome de usuário vazios.
Tenho usuários híbridos que tentam alterar sua senha na ID do Microsoft Entra e recebem a resposta "Já vimos essa senha muitas vezes antes. Escolha algo mais difícil de adivinhar. " Nesse caso, por que não vejo uma tentativa de validação local?
Quando um usuário híbrido altera sua senha na ID do Microsoft Entra, seja por meio do Microsoft Entra SSPR, MyAccount ou outro mecanismo de alteração de senha do Microsoft Entra, sua senha é avaliada em relação às listas de senhas proibidas globais e personalizadas na nuvem. Quando a senha chega ao Active Directory por meio de write-back de senha, ela já está validada na ID do Microsoft Entra.
As redefinições de senha e as alterações iniciadas na ID do Microsoft Entra que falham na validação para usuários híbridos podem ser encontradas nos logs de auditoria do Microsoft Entra. Confira Solucionar problemas de redefinição de senha self-service no Microsoft Entra ID.
Há suporte para instalar a Proteção de Senha do Microsoft Entra lado a lado com outros produtos baseados em filtro de senha?
Sim. O suporte a várias DLLs de filtro de senha registrada é um recurso importante do Windows e não é específico da Proteção de Senha do Microsoft Entra. Todas as dlls de filtro de senha registrados devem aceitar antes que uma senha seja aceita.
Como posso implantar e configurar o Microsoft Entra Password Protection no meu ambiente do Active Directory sem usar o Azure?
Não há suporte. A Proteção de Senha do Microsoft Entra é um recurso do Azure que pode ser estendido para um ambiente local do Active Directory.
Como faço para modificar o conteúdo da política no nível do Active Directory?
Não há suporte. A política só pode ser administrada usando o centro de administração do Microsoft Entra. Veja também a pergunta anterior.
Por que o DFSR é necessário para a replicação de SYSVOL?
FRS (a tecnologia do predecessor para DFSR) tem vários problemas conhecidos e é totalmente suportada em versões mais recentes do Windows Server Active Directory. O teste zero da Proteção de Senha do Microsoft Entra é feito em domínios configurados com FRS.
Para obter mais informações, consulte:
O caso para a replicação do sysvol migrando para DFSR
Se o seu domínio ainda não estiver usando o DFSR, você DEVE migrá-lo para usar o DFSR antes de instalar a Proteção por Senha do Microsoft Entra. Para obter mais informações, confira o seguinte link:
Guia de Migração de Replicação SYSVOL: Replicação FRS para DFS
Aviso
O software Microsoft Entra Password Protection DC Agent atualmente é instalado em controladores de domínio em domínios que ainda estão usando o FRS para replicação SYSVOL, mas o software NÃO funciona corretamente nesse ambiente. Os efeitos colaterais negativos incluem arquivos individuais que não são replicados e procedimentos de restauração SYSVOL que parecem ser bem-sucedidos, mas silenciosamente falham em replicar todos os arquivos. Você deve migrar seu domínio para usar o DFSR o quanto antes, tanto pelos benefícios inerentes ao DFSR quanto para desbloquear a implantação da Proteção de Senha do Microsoft Entra. Versões futuras do software são desabilitadas automaticamente ao serem executadas em um domínio que ainda está usando o FRS.
Quanto espaço em disco o recurso requer no compartilhamento sysvol de domínio?
O uso do espaço preciso varia, pois depende de fatores como o número e o tamanho dos tokens banidos na lista proibida global do Microsoft e a lista personalizada por locatário, além da sobrecarga de criptografia. O conteúdo dessas listas provavelmente aumentará no futuro. Com isso em mente, uma expectativa razoável é que o recurso exija pelo menos cinco (5) megabytes de espaço no compartilhamento SYSVOL do domínio.
Por que uma reinicialização é necessária para instalar ou atualizar o software do agente de controlador de domínio?
Esse requisito é causado pelo comportamento principal do Windows.
Há alguma maneira de configurar um agente de controlador de domínio para usar um servidor proxy específico?
Não. Uma vez que o servidor proxy é sem estado, não é importante saber qual servidor proxy específico é usado.
Não há problema em implantar o serviço Proxy de Proteção de Senha do Microsoft Entra lado a lado com outros serviços, como o Microsoft Entra Connect?
Sim. O serviço de Proxy da Proteção de Senha do Microsoft Entra e o Microsoft Entra Connect nunca devem entrar em conflito diretamente entre si.
Infelizmente, o software Microsoft Entra Password Protection Proxy instala uma versão do serviço Microsoft Entra Connect Agent Updater que é incompatível com a versão instalada pelo software Proxy de Aplicativo do Microsoft Entra. Essa incompatibilidade pode fazer com que o serviço de atualização do agente não consiga entrar em contato com o Azure para fazer atualizações de software. Não é recomendável instalar o Proxy de Proteção por Senha do Microsoft Entra e o proxy de aplicativo do Microsoft Entra no mesmo computador.
Em que ordem os agentes de DC e os proxies serão instalados e registrados?
Há suporte para qualquer ordem de instalação do agente de proxy, do agente de DC, do registro de floresta e do registro de proxy.
Devo me preocupar com o impacto ao desempenho de meus controladores de domínio ao implantar esse recurso?
O serviço agente DC de proteção de senha do Microsoft Entra não deve afetar significativamente o desempenho do controlador de domínio em uma implantação do Active Directory íntegra existente.
Para a maioria das implantações do Active Directory, as operações de alteração de senha são uma pequena proporção da carga de trabalho geral em qualquer controlador de domínio. Por exemplo, imagine um domínio do Active Directory com 10.000 contas de usuário e uma política MaxPasswordAge definida como 30 dias. Em média, esse domínio vê 10000/30=~333 operações de alteração de senha por dia, o que é um número menor de operações até mesmo para um único controlador de domínio. Considere um possível cenário de pior hipótese: suponha que essas ~333 alterações de senha em um único controlador de domínio tenham sido feitas em uma única hora. Por exemplo, esse cenário poderá ocorrer quando muitos funcionários voltam a trabalhar na segunda-feira pela manhã. Mesmo nesse caso, ainda estamos vendo ~ 333/60 minutos = seis alterações de senha por minuto, o que novamente não é uma carga significativa.
No entanto, se os controladores de domínio atuais já estiverem em execução em níveis de desempenho limitado (por exemplo, no máximo em relação à CPU, espaço em disco, E/S de disco e assim por diante), é aconselhável adicionar mais controladores de domínio ou expandir o espaço em disco disponível antes de implantar esse recurso. Consulte a pergunta anterior sobre o uso do espaço em disco SYSVOL acima.
Quero testar a Proteção de Senha do Microsoft Entra em apenas alguns DCs em meu domínio. É possível forçar alterações de senha de usuário para usar esses controladores de domínio específicos?
Não. O sistema operacional de cliente do Windows controla qual controlador de domínio é usado quando um usuário altera sua senha. O controlador de domínio é selecionado com base em fatores como atribuições de site e sub-rede do Active Directory, configuração de rede específica do ambiente e assim por diante. A Proteção de Senha do Microsoft Entra não controla esses fatores e não pode influenciar qual controlador de domínio é selecionado para alterar a senha de um usuário.
Uma maneira de atingir parcialmente essa meta seria implantar o Microsoft Entra Password Protection em todos os controladores de domínio em um determinado site do Active Directory. Essa abordagem fornece cobertura razoável para os clientes Windows atribuídos a esse site e para os usuários que estão fazendo logon nesses clientes e alterando suas senhas.
Se eu instalar o serviço do Agente DC da Proteção de Senha do Microsoft Entra apenas no PDC (Controlador de Domínio Primário), todos os outros controladores de domínio no domínio também serão protegidos?
Não. Quando uma senha do usuário for alterada em um controlador de domínio do PDC não fornecido, a senha com texto não criptografado nunca será enviada ao PDC (essa ideia é uma percepção incorreta comum). Depois que uma nova senha é aceita em um determinado controlador de domínio, esse controlador de domínio a usa para criar vários hashes específicos de protocolo de autenticação dessa senha e, em seguida, manter esses hashes no diretório. A senha de texto não criptografado não é mantida. Os hashes atualizados então são replicados para o controlador de domínio primário. As senhas de usuário podem, em alguns casos, ser alteradas diretamente no PDC dependendo de vários fatores, como topologia de rede e design de site do Active Directory. (Confira a pergunta anterior.)
Em resumo, a implantação do serviço agente DC de proteção de senha do Microsoft Entra no PDC é necessária para atingir 100% de cobertura de segurança do recurso em todo o domínio. A implantação do recurso somente no PDC não fornece benefícios de segurança da Proteção de Senha do Microsoft Entra para nenhum outro controlador de domínio no domínio.
Por que o bloqueio inteligente personalizado não funciona mesmo depois que os agentes são instalados em meu ambiente do Active Directory local?
O bloqueio inteligente personalizado só tem suporte na ID do Microsoft Entra. As alterações nas configurações personalizadas de bloqueio inteligente no centro de administração do Microsoft Entra não têm nenhum efeito no ambiente local do Active Directory, mesmo com os agentes instalados.
Um pacote de gerenciamento do System Center Operations Manager está disponível para o Microsoft Entra Password Protection?
Não.
Por que a ID do Microsoft Entra ainda está rejeitando senhas fracas mesmo que eu tenha configurado a política para estar no modo de auditoria?
O modo de auditoria só tem suporte no ambiente de Active Directory local. O Microsoft Entra ID está implicitamente sempre no modo de “imposição” quando avalia senhas.
Meus usuários veem a mensagem de erro tradicional do Windows quando uma senha é rejeitada pelo Microsoft Entra Password Protection. É possível personalizar a mensagem de erro para que os usuários saibam o que realmente aconteceu?
Não. A mensagem de erro vista pelos usuários quando uma senha é rejeitada por um controlador de domínio é controlada pelo computador cliente, não pelo controlador de domínio. Esse comportamento ocorre quando uma senha é rejeitada pelas políticas de senha padrão do Active Directory ou por uma solução baseada em filtro de senha, como a Proteção de Senha do Microsoft Entra.
Procedimentos de teste de senha
Talvez você queira fazer alguns testes básicos de várias senhas para validar a operação adequada do software e obter uma melhor compreensão do algoritmo de avaliação de senha. Esta seção descreve um método para esse teste que foi projetado para produzir resultados repetíveis.
Por que é necessário seguir essas etapas? Há vários fatores que dificultam a execução de testes controlados e repetíveis de senhas no ambiente local do Active Directory:
- A política de senha é configurada e mantida no Azure, e as cópias da política são sincronizadas periodicamente pelos agentes do DC local usando um mecanismo de sondagem. A latência inerente a esse ciclo de sondagem pode causar confusão. Por exemplo, se você configurar a política no Azure, mas esquecer de sincronizá-la com o agente do DC, seus testes poderão não produzir os resultados esperados. No momento, o intervalo de sondagem é codificado uma vez por hora, mas a espera de uma hora entre as alterações de política não é a ideal para um cenário de teste interativo.
- Depois que uma nova política de senha é sincronizada com um controlador de domínio, ocorre mais latência enquanto ela é replicada para outros controladores de domínio. Esses atrasos podem causar resultados inesperados se você testar uma alteração de senha em um controlador de domínio que não recebeu a versão mais recente da política.
- O teste de alterações de senha por meio de uma interface do usuário dificulta a confiança nos resultados. Por exemplo, é fácil digitar incorretamente uma senha inválida em uma interface do usuário, especialmente porque a maioria das interfaces do usuário de senha oculta a entrada do usuário (por exemplo, como a interface do usuário do Windows Ctrl-Alt-Delete -> Alterar senha).
- Não é possível controlar estritamente qual controlador de domínio é usado ao testar alterações de senha de clientes ingressados no domínio. O SO cliente do Windows seleciona um controlador de domínio com base em fatores como atribuições de site e sub-rede do Active Directory, configuração de rede específica do ambiente e assim por diante.
Para evitar esses problemas, as etapas a seguir são baseadas no teste de linha de comando de redefinições de senha enquanto estiver conectado a um controlador de domínio.
Aviso
Use esses procedimentos somente em um ambiente de teste. Enquanto o serviço do agente DC é interrompido, todas as alterações e redefinições de senha de entrada são aceitas sem validação. Isso também ajuda a evitar o aumento dos riscos de fazer logon em um controlador de domínio.
As etapas a seguir pressupõem que você instalou o agente DC em pelo menos um controlador de domínio, instalou pelo menos um proxy e registrou o proxy e a floresta.
Faça logon em um controlador de domínio usando credenciais de administrador de domínio ou outras credenciais que tenham privilégios suficientes para criar contas de usuário de teste e redefinir senhas. Verifique se o controlador de domínio tem o software do agente DC instalado e foi reinicializado.
Abra o Visualizador de Eventos e navegue até o log de eventos do administrador de agente do DC.
Abra uma janela de prompt de comando elevado.
Criar uma conta de teste para testar senhas
Há várias maneiras de criar uma conta de usuário, mas uma opção de linha de comando é oferecida aqui para facilitar o processo em ciclos de teste repetitivos:
net.exe user <testuseraccountname> /add <password>Para os fins de discussão abaixo, suponha que criamos uma conta de teste chamada "ContosoUser", por exemplo:
net.exe user ContosoUser /add <password>Entre no Centro de administração do Microsoft Entra como, no mínimo, um Administrador de Autenticação.
Navegue até Proteção > Métodos de autenticação > Proteção de senha.
Modifique a política de Proteção de Senha do Microsoft Entra conforme a necessidade para os testes que você deseja executar. Por exemplo, você pode decidir configurar o modo imposto ou de auditoria, ou pode decidir modificar a lista de termos proibidos na sua lista de senhas proibidas personalizadas.
Sincronize a nova política interrompendo e reiniciando o serviço de agente de DC.
Essa etapa pode ser realizada de várias maneiras. Por exemplo, usar o console administrativo do Gerenciamento de Serviços clicando com o botão direito do mouse no serviço Agente de DC da Proteção de Senha do Microsoft Entra e selecionando "Reiniciar". Outra maneira seria executada na janela do prompt de comando da seguinte forma:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentVerifique o Visualizador de Eventos para verificar se uma nova política foi baixada.
Sempre que o serviço de agente de DC for interrompido e iniciado, você verá dois eventos 30006 emitidos sucessivamente. O primeiro evento 30006 refletirá a política que foi armazenada em cache no disco no compartilhamento SYSVOL. O segundo evento 30006 (se presente) deverá ter uma data de política de locatário atualizada e, se for o caso, refletirá a política que foi baixada do Azure. O valor de data da política de locatário é codificado para exibir o carimbo de data/hora aproximado em que a política foi baixada do Azure.
Se o segundo evento 30006 não aparecer, você deverá solucionar o problema antes de continuar.
Os eventos 30006 serão semelhantes a este exemplo:
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1Por exemplo, alternar entre o modo Imposto e Auditoria resultará na modificação do sinalizador AuditOnly (a política listada com AuditOnly=0 está no modo Imposto). As alterações na lista de senhas proibidas personalizadas não são refletidas diretamente no evento 30006 acima e não são registradas em nenhum outro lugar por motivos de segurança. O download bem-sucedido da política do Azure após essa alteração também incluirá a lista de senhas proibidas personalizadas modificadas.
Execute um teste tentando redefinir uma nova senha na conta de usuário de teste.
Esta etapa pode ser realizada na janela do prompt de comando da seguinte maneira:
net.exe user ContosoUser <password>Depois de executar o comando, você poderá obter mais informações sobre o resultado analisando o Visualizador de Eventos. Os eventos de resultado da validação de senha estão documentados no tópico log de eventos do Administrador do Agente do DC; você usará esses eventos para validar o resultado do teste, além da saída interativa dos comandos net.exe.
Vamos experimentar um exemplo: tentar definir uma senha que é proibida pela lista global da Microsoft (observe que a lista não está documentada, mas podemos testá-la em relação a um termo proibido conhecido). Este exemplo pressupõe que você configurou a política para o modo imposto e adicionou termos zero à lista de senhas proibidas personalizadas.
net.exe user ContosoUser PassWord The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements. More help is available by typing NET HELPMSG 2245.De acordo com a documentação, como nosso teste foi uma operação de redefinição de senha, você deverá ver um evento 10017 e 30005 para o usuário ContosoUser.
O evento 10017 deve ser semelhante a este exemplo:
The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message. UserName: ContosoUser FullName:O evento 30005 deve ser semelhante a este exemplo:
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:Isso foi divertido – vamos tentar outro exemplo! Agora, tentaremos definir uma senha que seja banida pela lista de banidos personalizada enquanto a política estiver no modo de auditoria. Este exemplo pressupõe que você tenha concluído as seguintes etapas: configurou a política para estar no modo de auditoria, adicionou o termo "lacrimoso" à lista de senhas proibidas personalizadas e sincronizou a nova política resultante com o controlador de domínio alternando o serviço do agente DC, conforme descrito anteriormente.
Ok, defina uma variação da senha proibida:
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.Lembre-se, desta vez, teve êxito porque a política está em modo de auditoria. Você deverá ver um evento 10025 e 30007 para o usuário ContosoUser.
O evento 10025 deve ser semelhante a este exemplo:
The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:O evento 30007 deve ser semelhante a este exemplo:
The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:Continue testando várias senhas de sua escolha e verificando os resultados no Visualizador de Eventos usando os procedimentos descritos nas etapas anteriores. Caso precise alterar a política no centro de administração do Microsoft Entra, não se esqueça de sincronizar a nova política com o agente do controlador de domínio, conforme já descrito.
Abordamos procedimentos que permitem que você faça testes controlados do comportamento de validação de senha do Microsoft Entra Password Protection. Redefinir senhas de usuário da linha de comando diretamente em um controlador de domínio pode parecer um meio estranho de fazer esse teste, mas, conforme descrito anteriormente, ele foi projetado para produzir resultados repetíveis. Ao testar várias senhas, lembre-se do algoritmo de avaliação de senha pois pode ajudar a explicar resultados que você não esperava.
Aviso
Quando todos os testes forem concluídos, não se esqueça de excluir todas as contas de usuário criadas para fins de teste!
Conteúdo adicional
Os links a seguir não fazem parte da documentação principal da Proteção de Senha do Microsoft Entra, mas podem ser uma fonte útil de informações adicionais sobre o recurso.
A Proteção de Senha do Microsoft Entra agora está disponível em geral!
Treinamento em suporte da Microsoft Premier\Unified disponível
Se você quiser saber mais sobre a Proteção por Senha do Microsoft Entra e como implantá-la, poderá usar um serviço proativo da Microsoft. Este serviço está disponível para clientes com um contrato de suporte Premier ou Unified. O nome do serviço é Microsoft Entra ID: Proteção de Senha. Entre em contato com o gerente de conta de sucesso do cliente para obter mais informações.
Próximas etapas
Se você tiver uma pergunta sobre a Proteção de Senha do Microsoft Entra local que não foi respondida aqui, envie um item de Comentários abaixo – obrigado!