Esta seção fornece respostas para muitas perguntas frequentes sobre a Proteção por Senha do Microsoft Entra.
Questões gerais
Que orientações devem ser dadas aos utilizadores sobre como selecionar uma palavra-passe segura?
As orientações atuais da Microsoft sobre este tópico podem ser encontradas no seguinte link:
Diretrizes de senha da Microsoft
A Proteção por Senha do Microsoft Entra local é suportada em nuvens não públicas?
A Proteção por Senha do Microsoft Entra local é suportada nas nuvens Azure Global e Azure Government.
O centro de administração do Microsoft Entra permite a modificação da configuração "Proteção por senha para o Ative Directory do Windows Server" específica no local em nuvens não suportadas; Tais mudanças persistem, mas nunca entram em vigor. O registro de agentes proxy locais ou florestas não é suportado em nuvens sem suporte, e essas tentativas de registro sempre falham.
Como posso aplicar os benefícios da Proteção por Senha do Microsoft Entra a um subconjunto dos meus usuários locais?
Não suportado. Uma vez 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 um conjunto (ou redefinição) de senha?
Uma alteração de senha é 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 login no Windows e, em seguida, é solicitado a escolher uma nova senha.
Um conjunto de senhas (às vezes chamado de redefinição de senha) é quando um administrador substitui a senha em uma conta por uma nova senha, por exemplo, usando a ferramenta de gerenciamento Usuários e Computadores do Ative Directory. Esta 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 help-desk 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 se comporta da mesma forma, independentemente de uma alteração ou definição de senha estar sendo feita. O serviço Microsoft Entra Password Protection DC Agent registra eventos diferentes para informá-lo se uma alteração de senha ou operação de definição foi feita. Consulte Monitoramento e registro em log da Proteção por Senha do Microsoft Entra.
O Microsoft Entra Password Protection valida senhas existentes depois de instalado?
Não - A Proteção por Senha do Microsoft Entra só pode impor a política de senha em senhas de texto não criptografado durante uma operação de alteração ou definição de senha. Depois que o Ative Directory aceita uma senha, somente os hashes específicos do protocolo de autenticação dessa senha são persistentes. A senha de texto não criptografado nunca é persistida, portanto, a Proteção por 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 pelo Microsoft Entra Password Protection, pois suas senhas existentes expiram normalmente com o tempo. Se desejar, você pode acelerar esse processo por meio de uma expiração manual única das senhas da conta de usuário.
As contas configuradas com "a palavra-passe nunca expira" não são forçadas a alterar a palavra-passe, a menos que a expiração manual seja feita.
Por que os eventos de rejeição de senha duplicados são registrados ao tentar definir uma senha fraca usando o snap-in de gerenciamento Usuários e Computadores do Ative Directory?
O snap-in de gerenciamento Usuários e Computadores do Ative 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 por 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 Ative Directory suporta a capacidade de testar uma senha para ver se ela passa os requisitos atuais de complexidade de senha do domínio, por exemplo, usando a API NetValidatePasswordPolicy . Quando uma senha é validada dessa forma, o teste também inclui a validação por produtos baseados em password-filter-dll, como o Microsoft Entra Password Protection, mas os nomes de usuário passados para uma determinada dll de filtro de senha estão vazios. Nesse cenário, o Microsoft Entra Password Protection ainda valida a senha usando a diretiva 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 no Microsoft Entra ID 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 no local?
Quando um utilizador híbrido altera a sua palavra-passe no Microsoft Entra ID, seja através da SSPR do Microsoft Entra, MyAccount ou outro mecanismo de alteração da palavra-passe do Microsoft Entra, a sua palavra-passe é avaliada em relação às listas de palavras-passe globais e de palavras-passe personalizadas banidas na cloud. Quando a senha chega ao Ative Directory por meio de write-back de senha, ela já é validada no Microsoft Entra ID.
Redefinições de senha e 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. Consulte Solucionar problemas de redefinição de senha de autoatendimento na ID do Microsoft Entra.
É suportado para instalar o Microsoft Entra Password Protection lado a lado com outros produtos baseados em filtro de senha?
Sim. O suporte para várias dlls de filtro de senha registradas é um recurso principal do Windows e não específico da Proteção por Senha do Microsoft Entra. Todas as dlls de filtro de senha registradas devem concordar antes que uma senha seja aceita.
Como posso implantar e configurar a Proteção por Senha do Microsoft Entra no meu ambiente do Ative Directory sem usar o Azure?
Não suportado. A Proteção por Senha do Microsoft Entra é um recurso do Azure que oferece suporte à extensão para um ambiente local do Ative Directory.
Como posso modificar o conteúdo da política no nível do Ative Directory?
Não suportado. A política só pode ser administrada usando o centro de administração do Microsoft Entra. Ver também a pergunta anterior.
Por que o DFSR é necessário para a replicação sysvol?
FRS (a tecnologia antecessora do DFSR) tem muitos problemas conhecidos e não é suportado em versões mais recentes do Ative Directory do Windows Server. Nenhum teste da Proteção por Senha do Microsoft Entra é feito em domínios configurados pelo FRS.
Para obter mais informações, consulte os seguintes artigos:
O caso de migração da replicação sysvol para DFSR
Se o seu domínio ainda não estiver usando DFSR, você DEVE migrá-lo para usar DFSR antes de instalar a Proteção por Senha do Microsoft Entra. Para obter mais informações, consulte o seguinte link:
Guia de migração da replicação SYSVOL: FRS para replicação 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 FRS para replicação sysvol, mas o software NÃO funciona corretamente neste ambiente. Os efeitos colaterais negativos incluem arquivos individuais que não são replicados e procedimentos de restauração sysvol que parecem ter êxito, mas silenciosamente não conseguem replicar todos os arquivos. Você deve migrar seu domínio para usar o DFSR o mais rápido possível, tanto para os benefícios inerentes do DFSR quanto para desbloquear a implantação do Microsoft Entra Password Protection. As versões futuras do software são automaticamente desativadas quando executadas em um domínio que ainda está usando o FRS.
Quanto espaço em disco o recurso requer no domínio sysvol share?
O uso preciso do espaço varia, pois depende de fatores como o número e o comprimento dos tokens banidos na lista global de banidos da Microsoft e na lista personalizada por locatário, além da sobrecarga de criptografia. É provável que o conteúdo destas listas cresça 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 é necessária uma reinicialização para instalar ou atualizar o software do agente DC?
Este requisito é causado pelo comportamento principal do Windows.
Existe alguma maneira de configurar um agente DC para usar um servidor proxy específico?
N.º Como o servidor proxy é sem monitoração de estado, não é importante qual servidor proxy específico é usado.
Não há problema em implantar o serviço Microsoft Entra Password Protection Proxy lado a lado com outros serviços, como o Microsoft Entra Connect?
Sim. O serviço Microsoft Entra Password Protection Proxy e o Microsoft Entra Connect nunca devem entrar em conflito direto 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 Microsoft Entra. Essa incompatibilidade pode fazer com que o serviço Agent Updater não consiga entrar em contato com o Azure para obter atualizações de software. Não é recomendado instalar o Proxy de Proteção por Senha do Microsoft Entra e o proxy de aplicativo do Microsoft Entra na mesma máquina.
Em que ordem os agentes DC e proxies devem ser instalados e registrados?
Qualquer ordem de instalação de agente proxy, instalação de agente DC, registro de floresta e registro de proxy é suportada.
Devo me preocupar com o impacto de desempenho em meus controladores de domínio da implantação desse recurso?
O serviço Microsoft Entra Password Protection DC Agent não deve afetar significativamente o desempenho do controlador de domínio em uma implantação existente do Ative Directory íntegra.
Para a maioria das implantações do Ative 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. Como exemplo, imagine um domínio do Ative Directory com 10.000 contas de usuário e uma política MaxPasswordAge definida como 30 dias. Em média, este 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 potencial pior cenário: suponha que essas ~333 alterações de senha em um único DC foram feitas em uma única hora. Por exemplo, esse cenário pode ocorrer quando muitos funcionários chegam ao trabalho em uma manhã de segunda-feira. Mesmo nesse caso, ainda estamos olhando para ~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, maximizados 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 de espaço em disco sysvol acima.
Quero testar o Microsoft Entra Password Protection em apenas alguns DCs no meu domínio. É possível forçar alterações de senha de usuário para usar esses DCs específicos?
N.º O sistema operacional cliente 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 Ative Directory, configuração de rede específica do ambiente e assim por diante. A Proteção por Senha do Microsoft Entra não controla esses fatores e não pode influenciar qual controlador de domínio está selecionado para alterar a senha de um usuário.
Uma maneira de atingir parcialmente essa meta seria implantar a Proteção por Senha do Microsoft Entra em todos os controladores de domínio em um determinado site do Ative Directory. Essa abordagem fornece uma cobertura razoável para os clientes Windows atribuídos a esse site e para os usuários que estão fazendo login nesses clientes e alterando suas senhas.
Se eu instalar o serviço Microsoft Entra Password Protection DC Agent apenas no Controlador de Domínio Primário (PDC), todos os outros controladores de domínio no domínio também estarão protegidos?
N.º Quando a senha de um usuário é alterada em um determinado controlador de domínio não-PDC, a senha de texto não criptografado nunca é enviada para o PDC (essa ideia é um equívoco comum). Depois que uma nova senha é aceita em um determinado DC, esse DC usa essa senha para criar os vários hashes específicos do protocolo de autenticação dessa senha e, em seguida, persiste esses hashes no diretório. A senha de texto não criptografado não é persistente. Os hashes atualizados são então replicados para o PDC. As senhas de usuário podem, em alguns casos, ser alteradas diretamente no PDC, novamente dependendo de vários fatores, como topologia de rede e design de site do Ative Directory. (Ver pergunta anterior.)
Em resumo, a implantação do serviço Microsoft Entra Password Protection DC Agent no PDC é necessária para alcançar 100% de cobertura de segurança do recurso em todo o domínio. A implantação do recurso apenas no PDC não fornece benefícios de segurança da Proteção por Senha do Microsoft Entra para nenhum outro DCs no domínio.
Por que o bloqueio inteligente personalizado não está funcionando mesmo depois que os agentes são instalados no meu ambiente local do Ative Directory?
O bloqueio inteligente personalizado só é suportado no Microsoft Entra ID. As alterações nas configurações personalizadas de bloqueio inteligente no centro de administração do Microsoft Entra não têm efeito no ambiente local do Ative Directory, mesmo com os agentes instalados.
Um pacote de gerenciamento do System Center Operations Manager está disponível para a Proteção por Senha do Microsoft Entra?
N.º
Por que o Microsoft Entra ID ainda está rejeitando senhas fracas mesmo que eu tenha configurado a política para estar no modo de auditoria?
O modo de auditoria só é suportado no ambiente local do Ative Directory. O Microsoft Entra ID está implicitamente sempre no modo "enforce" 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 essa mensagem de erro para que os usuários saibam o que realmente aconteceu?
N.º A mensagem de erro vista pelos usuários quando uma senha é rejeitada por um controlador de domínio é controlada pela máquina cliente, não pelo controlador de domínio. Esse comportamento acontece se uma senha é rejeitada pelas diretivas de senha padrão do Ative Directory ou por uma solução baseada em filtro de senha, como o Microsoft Entra Password Protection.
Procedimentos de teste de senha
Você pode querer fazer alguns testes básicos de várias senhas, a fim de validar o funcionamento adequado do software e obter uma melhor compreensão do algoritmo de avaliação de senha. Esta seção descreve um método para esses testes que é projetado para produzir resultados repetíveis.
Por que é necessário seguir esses passos? Há vários fatores que dificultam a execução de testes controlados e repetíveis de senhas no ambiente local do Ative Directory:
- A política de senha é configurada e persistida no Azure, e as cópias da política são sincronizadas periodicamente pelo(s) agente(s) de DC local usando um mecanismo de sondagem. A latência inerente a este 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 de DC, seus testes podem não produzir os resultados esperados. Atualmente, o intervalo de sondagem é codificado para ser uma vez por hora, mas esperar uma hora entre as alterações de política não é ideal para um cenário de teste interativo.
- Depois que uma nova diretiva de senha é sincronizada com um controlador de domínio, mais latência ocorre enquanto ela é replicada para outros controladores de domínio. Esses atrasos podem causar resultados inesperados se você testar uma alteração de senha em relação a um controlador de domínio que não recebeu a versão mais recente da política.
- Testar alterações de senha por meio de uma interface de usuário torna difícil ter confiança em seus resultados. Por exemplo, é fácil digitar incorretamente uma senha inválida em uma interface de usuário, especialmente porque a maioria das interfaces de usuário de senha oculta a entrada do usuário (por exemplo, como a interface do usuário Ctrl-Alt-Delete -> Alterar senha do Windows).
- 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 sistema operacional cliente Windows seleciona um controlador de domínio com base em fatores como atribuições de site e sub-rede do Ative Directory, configuração de rede específica do ambiente e assim por diante.
Para evitar esses problemas, as etapas a seguir são baseadas em testes de linha de comando de redefinições de senha enquanto conectado a um controlador de domínio.
Aviso
Use esses procedimentos somente em um ambiente de teste. Enquanto o serviço do agente de 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 os riscos maiores de fazer login em um controlador de domínio.
As etapas a seguir pressupõem que você instalou o agente de 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 de DC instalado e foi reinicializado.
Abra o Visualizador de Eventos e navegue até o log de eventos do DC Agent Admin.
Abra uma janela de prompt de comando com privilégios elevados.
Criar uma conta de teste para fazer testes de senha
Há muitas maneiras de criar uma conta de usuário, mas uma opção de linha de comando é oferecida aqui como uma maneira de facilitar durante ciclos de teste repetitivos:
net.exe user <testuseraccountname> /add <password>Para 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 pelo menos um Administrador de Autenticação.
Navegue até Proteção > Métodos > de autenticação Proteção por senha.
Modifique a política de Proteção por Senha do Microsoft Entra conforme necessário para o teste que você deseja executar. Por exemplo, você pode decidir configurar o Modo Imposto ou o Modo de Auditoria, ou pode decidir modificar a lista de termos proibidos em sua lista de senhas proibidas personalizadas.
Sincronize a nova política parando e reiniciando o serviço do agente de DC.
Esta etapa pode ser realizada de várias maneiras. Uma maneira seria usar o console administrativo de Gerenciamento de Serviços, clicando com o botão direito do mouse no serviço Microsoft Entra Password Protection DC Agent e escolhendo "Reiniciar". Outra maneira pode ser executada a partir da janela do prompt de comando assim:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentVerifique o Visualizador de Eventos para verificar se uma nova política foi baixada.
Cada vez que o serviço do agente DC é interrompido e iniciado, você verá dois eventos 30006 emitidos em sucessão próxima. O primeiro evento 30006 refletirá a política que foi armazenada em cache no disco no compartilhamento sysvol. O segundo evento 30006 (se presente) deve ter uma data de política de locatário atualizada e, em caso afirmativo, refletirá a política que foi baixada do Azure. O valor da data da política de locatário está atualmente codificado para exibir o carimbo de data/hora aproximado que a política foi baixada do Azure.
Se o segundo evento 30006 não aparecer, você deve 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, alterar entre o modo Imposto e Auditoria resultará na modificação do sinalizador AuditOnly (a política listada com AuditOnly=0 está no modo Enforceed). 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 feita a partir da janela do prompt de comando assim:
net.exe user ContosoUser <password>Depois de executar o comando, você pode obter mais informações sobre o resultado do comando procurando no visualizador de eventos. Os eventos de resultado da validação de senha estão documentados no tópico do log de eventos do DC Agent Admin, você usará esses eventos para validar o resultado do teste, além da saída interativa dos comandos net.exe.
Vamos tentar um exemplo: tentar definir uma senha que é proibida pela lista global da Microsoft (observe que a lista não está documentada , mas podemos testar aqui contra um termo proibido conhecido). Este exemplo pressupõe que você configurou a política para estar no modo Imposto e adicionou zero termos à 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ê deve 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 proibida 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 "lacrimose" à lista de senhas proibidas personalizadas e sincronizou a nova política resultante com o controlador de domínio alternando o serviço do agente de 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 foi bem-sucedido porque a política está no modo de auditoria. Você deve ver um evento 10025 e um evento 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. Se você precisar 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 DC, conforme descrito anteriormente.
Abordamos os 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, tenha em mente o algoritmo de avaliação de senha, pois ele pode ajudar a explicar resultados que você não esperava.
Aviso
Quando todos os testes estiverem 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 do Microsoft Entra Password Protection, mas podem ser uma fonte útil de informações adicionais sobre o recurso.
O Microsoft Entra Password Protection já está disponível para o público em geral!
Treinamento de suporte Microsoft Premier\Unified disponível
Se quiser saber mais sobre a Proteção por Senha do Microsoft Entra e como implantá-la, você pode usar um serviço proativo da Microsoft. Este serviço está disponível para clientes com um contrato de suporte Premier ou Unificado. O serviço chama-se Microsoft Entra ID: Password Protection. Entre em contato com seu Gerente de Conta de Sucesso do Cliente para obter mais informações.
Próximos passos
Se você tiver uma pergunta sobre Proteção por Senha do Microsoft Entra local que não foi respondida aqui, envie um item de Comentários abaixo - obrigado!