Active Directory: como corrigir o erro “Your password does not meet the requirements” (GPO, FGPP, filtros e replicação)

Ao tentar trocar senhas no Active Directory, mesmo com senhas complexas, aparece “Your password does not meet the requirements”? Este guia explica as causas mais comuns (FGPP, filtros, replicação) e traz um passo a passo prático para diagnosticar e resolver o problema com segurança.

Índice

Contexto e sintomas

Num ambiente com vários controladores de domínio (por exemplo, 13 DCs) que replicam entre si, é possível que toda tentativa de alteração de senha falhe com a mensagem “Your password does not meet the requirements”, apesar de o administrador afirmar que a política vigente é simples: mínimo de 8 caracteres, complexidade habilitada e idade mínima da senha igual a 0. Quando isso acontece de forma generalizada, a causa quase nunca é “apenas a complexidade”; normalmente há um fator adicional: uma Fine‑Grained Password Policy (FGPP) não mapeada, um filtro de senha de terceiros, inconsistências de replicação de GPO/SYSVOL, ou mesmo uma interpretação equivocada de onde a política de senha realmente se aplica.

Como o AD valida a senha (visão rápida)

Política de domínio (Account Policies): definida no GPO com maior precedência vinculado à raiz do domínio (geralmente a Default Domain Policy). Configurações em OUs não afetam senhas de contas de domínio; afetam apenas contas locais das máquinas naquela OU.
Fine‑Grained Password Policies (FGPP): objetos msDS-PasswordSettings armazenados em “Password Settings Container”. Podem impor mínimos mais rigorosos (ex.: 14+ caracteres, histórico maior, complexidade) para grupos/usuários específicos. A FGPP, quando aplicável ao usuário, substitui a política do domínio.
Filtros de senha (password filters): DLLs carregadas pelos DCs (chave HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages). Podem implementar regras extras (listas proibidas, dicionário, bloqueio de padrões). Se presentes, o DC recusa a senha mesmo que as políticas “oficiais” pareçam permissivas.
Histórico e idade: histórico de senhas e idade mínima podem resultar na mesma mensagem genérica de falha, dependendo da interface usada para trocar a senha.

Causas prováveis para a mensagem “Your password does not meet the requirements”

FGPP mais rígida aplicada ao usuário ou a um grupo ao qual ele pertence (mínimo maior, histórico extenso, complexidade diferenciada).
Filtro de senha de terceiros (ex.: Azure AD Password Protection on‑premises, soluções de auditoria/segurança) rejeitando padrões ou palavras banidas.
Replicação inconsistente (GPO/SYSVOL/AD) entre os 13 DCs: alguns DCs avaliam com regras diferentes.
Política de domínio diferente do que se imagina: a conta de domínio só obedece ao GPO vinculado à raiz do domínio; alterações em OUs não têm efeito sobre usuários de domínio.
Requisitos de complexidade não atendidos por detalhes específicos (nome de usuário ou partes do nome completo presentes na senha, categorias de caracteres insuficientes).
Histórico de senhas/idade mínima impedindo a troca e devolvendo a mesma mensagem genérica.
Hora do sistema divergente entre DCs (NTP), causando efeitos colaterais em validações e replicação.

Tabela‑resumo: passos, ações e objetivos

Passo	Ação	Objetivo / Detalhes
Testar sem a exigência de complexidade	Desabilite temporariamente a política “Passwords must meet complexity requirements” no GPO vinculado ao domínio (ou em ambiente de teste isolado) e peça a um usuário de teste para trocar a senha. Reative após o teste.	Se a troca funcionar, o problema está na verificação de complexidade ou em filtros adicionais.
Confirmar diretivas efetivas e políticas sobrepostas	Use `net accounts /domain` em um DC e `Get-ADDefaultDomainPasswordPolicy` / `Get-ADUserResultantPasswordPolicy` no PowerShell.	Detecta se existe uma FGPP ou outro GPO no domínio impondo requisitos mais rígidos sem que o admin tenha percebido.
Sincronização e atualização	Execute `repadmin /replsummary` nos DCs e verifique DFSR/FRS (SYSVOL). Atualize a política nos DCs (`gpupdate /force` neles).	Garante que todos os DCs estejam com configurações coerentes. Obs.: atualização no cliente não altera a validação de senha no DC.
Procurar filtros de senha	Nos DCs, verifique `HKLM\System\CurrentControlSet\Control\Lsa\Notification Packages` e a pasta `%SystemRoot%\System32`. Procure DLLs de password filter.	Extensões de segurança podem recusar senhas fora do que a política padrão exige. Remova/atualize conforme o fabricante.
Conferir requisitos exatos de complexidade	Lembre: a senha não pode conter o nome da conta nem três caracteres consecutivos do nome completo; deve incluir caracteres de pelo menos 3 das 4 categorias.	Ao testar, utilize algo claramente fora do padrão (ex.: `Xp7$!kL#zR2@`).
Validar perfis e estação	Crie um usuário de teste novo e/ou troque a senha a partir de outra máquina ou diretamente no DC.	Descarta cache ou problema local. Para isolar, tente também via ADUC/ADAC/PowerShell.
Revisar logs	Em Event Viewer dos DCs/clientes: Security e System (IDs comuns: 4625, 4723, 4724, 4740). Examine também logs de produtos de terceiros (se houver).	Os eventos indicam o motivo exato (ex.: falha na verificação de complexidade, histórico, bloqueio, filtro externo).
Ajustes recomendados	Considere mínimo de 12–14 caracteres, uso de FGPP por grupo, e sincronização de hora via NTP em todos os DCs.	Fortalece a segurança e reduz recusas inesperadas.

Importante: para contas de domínio, mudar a complexidade numa GPO de OU não altera a validação feita pelos DCs. Ajuste a política no GPO vinculado à raiz do domínio ou use FGPP.

Fluxo de decisão para diagnóstico rápido

Tente uma senha altamente randômica e longa (ex.: Xp7$!kL#zR2@).
Se falhar, verifique imediatamente se o usuário tem FGPP aplicável: Get-ADUserResultantPasswordPolicy -Identity <usuario>
Se houver FGPP, valide os mínimos/complexidade/histórico. Ajuste a FGPP ou a associação do usuário.
Se não houver FGPP, liste filtros de senha no DC que processou a tentativa: reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"
Cheque replicação: repadmin /replsummary
Faça um teste direcionando a alteração para um DC específico (para detectar inconsistências): Set-ADAccountPassword -Identity <usuarioTeste> -Reset ` -NewPassword (ConvertTo-SecureString "Xp7$!kL#zR2@" -AsPlainText -Force) ` -Server <DC-alvo>
Analise eventos Security (4723/4724) e logs de produtos de segurança (se instalados).

Requisitos de complexidade: o que realmente conta

Quando a complexidade está habilitada, a senha deve:

Não conter o nome de usuário (samAccountName) nem três ou mais caracteres consecutivos de qualquer parte do nome completo (displayName).
Usar caracteres de pelo menos 3 das 4 categorias: maiúsculas, minúsculas, números, símbolos.
Atender ao tamanho mínimo e ao histórico definidos (pela política de domínio ou FGPP).

Exemplo	Passa?	Por quê
`Xp7$!kL#zR2@`	Sim	Aparentemente aleatória; atende 3/4 categorias e não contém nome.
`Joao!2025@` (usuário “joao”)	Não	Contém “joa” do nome; falha na regra de partes do nome.
`m4rG@r1d4` (usuária “Margarida”)	Não	Mesmo com trocas de caracteres, contém sequência do nome.
`SenhaFort3#`	Depende	Se o mínimo for 12 via FGPP, falha por tamanho insuficiente.

FGPP: quando, onde e como verificar

FGPPs permitem requisitos diferentes por grupo/usuário e exigem nível funcional de domínio Windows Server 2008+. O conflito entre múltiplas FGPPs é resolvido pelo atributo Precedence (número menor vence). Para diagnosticar:

# Ver política padrão do domínio
Get-ADDefaultDomainPasswordPolicy

Listar FGPPs

Get-ADFineGrainedPasswordPolicy -Filter *

FGPP efetiva para o usuário

Get-ADUserResultantPasswordPolicy -Identity

Se uma FGPP exigir, por exemplo, 14 caracteres, qualquer senha < 14 será recusada mesmo que a política de domínio fale em 8. Ajuste a FGPP (Set-ADFineGrainedPasswordPolicy) ou a associação do usuário ao grupo‑alvo.

Filtros de senha: sinais e como lidar

Senha sendo recusada “sem motivo”? Verifique filtros:

Registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages (valor REGMULTISZ com DLLs carregadas).
Sistema: DLLs correspondentes em %SystemRoot%\System32.
Logs do fornecedor: muitos filtros registram o motivo em logs próprios (ex.: “senha contém palavra banida”).

Se o filtro for corporativo (ex.: bloqueio de senhas fracas, proteção contra dicionário), alinhe as expectativas com a equipe de segurança: é isso que está rejeitando. Atualize as listas proibidas, ajuste limiares, ou documente a exigência real (p.ex., “mínimo de 14 e sem palavras do dicionário”).

Replicação: garantindo a coerência entre 13 DCs

Quando as recusas ocorrem em todo o domínio, verifique se todos os DCs têm a mesma visão de política e os mesmos filtros carregados. Use:

repadmin /replsummary
repadmin /showrepl * /csv > C:\temp\repl.csv
dfsrdiag ReplicationState

Inconsistências em SYSVOL (GPO), AD DS ou diferenças na presença de DLLs de filtro entre DCs causam resultados imprevisíveis. Padronize a instalação e execute uma checagem pós‑correção.

Logs que revelam o motivo

No Event Viewer dos DCs:

Security 4723: tentativa de alteração de senha.
Security 4724: tentativa de redefinição por administrador.
Security 4625: falha de logon (útil quando a UI de troca de senha mascara o motivo).
Security 4740: conta bloqueada (pode ocorrer após várias tentativas).

Abra o evento e verifique campos detalhados: motivo de falha, DC envolvido, conta, estação de origem, etc. Se houver filtro de terceiros, busque também a árvore de logs do produto.

Checklist de comandos úteis

# Qual DC me autenticou?
echo %LOGONSERVER%

Política de conta do domínio (no DC)

net accounts /domain

Política padrão do domínio (PowerShell do AD)

Get-ADDefaultDomainPasswordPolicy

FGPP aplicável a um usuário

Get-ADUserResultantPasswordPolicy -Identity 

Todas as FGPPs

Get-ADFineGrainedPasswordPolicy -Filter *

Replicação AD

repadmin /replsummary

Ver DLLs de filtro notificadas ao LSA

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"

Hora e origem de NTP no DC

w32tm /query /status
w32tm /query /peers

Playbooks de correção (do mais provável ao menos provável)

Playbook A — FGPP está mais rígida do que o esperado

Rodar Get-ADUserResultantPasswordPolicy para o usuário impactado.
Se o mínimo for > 8, alinhar com segurança e comunicar o requisito real. Se não for intencional, ajustar a FGPP (Set-ADFineGrainedPasswordPolicy).
Re‑testar com uma senha randômica e longa (≥ novo mínimo).

Playbook B — Filtro de senha de terceiros bloqueando padrões

Inspecionar Notification Packages e a pasta System32 em um DC.
Identificar o produto e coletar logs específicos. Ajustar política/lista proibida conforme diretriz de segurança.
Garantir que todos os DCs tenham a mesma versão e configuração do filtro.

Playbook C — Replicação inconsistente

Executar repadmin /replsummary e resolver falhas (latência alta, erros de autenticação, conexões quebradas).
Validar sincronismo do SYSVOL (DFSR). Corrigir blocos pendentes.
Reiniciar o ciclo de teste apontando a alteração para DCs diferentes (parâmetro -Server no PowerShell) para confirmar uniformidade.

Playbook D — Interface/cliente mascara o motivo real

Repetir o teste usando outra via: ADUC/ADAC, PowerShell (Set-ADAccountPassword), Ctrl+Alt+Del em outra máquina.
Checar logs Security 4723/4724 no DC que processou a alteração.

Boas práticas (evite retrabalho e falhas silenciosas)

Defina o mínimo em 12–14 caracteres e promova senhas/passphrases robustas; documente claramente o requisito.
Use FGPP para diferenciar exigências por grupos (TI, terceiros, contas privilegiadas), mantendo a política de domínio mais simples.
Padronize a instalação/versão de filtros de senha em todos os DCs (se usados) e monitore seus logs.
Mantenha os DCs com hora sincronizada via NTP; divergências atrapalham auditoria e podem gerar sintomas estranhos.
Automatize um healthcheck pós‑mudança: repadmin, w32tm, dfsrdiag e um teste de troca de senha com usuário de laboratório.
Evite alterar senha de domínio confiando em GPOs aplicadas em OUs; para usuários de domínio isso não tem efeito.

Erros comuns a evitar

Desabilitar complexidade em produção por longos períodos. Se precisar testar, faça em horário controlado e reverta de imediato.
Concluir pelo “gpresult” do cliente que a política está correta. A validação ocorre no DC — verifique no DC.
Ignorar FGPP: muitos ambientes têm FGPPs antigas esquecidas que ainda atingem grupos específicos.
Assumir que todos os DCs são idênticos: falhas de replicação e DLLs ausentes resultam em comportamento diferente por site.

Exemplos reais de causas e correções

FGPP exigindo 14+ caracteres

Um grupo “Contas Administrativas” tinha FGPP com MinPasswordLength=14. Usuários desse grupo viam a mensagem mesmo ao usar 10–12 caracteres “complexos”. Ao identificar a FGPP via Get-ADUserResultantPasswordPolicy, ajustou‑se a política e tudo voltou ao normal.

Filtro corporativo de palavras banidas

Uma solução de password filter bloqueava meses do ano e nomes de times locais. Senhas “Agosto2025!” e “Flamengo#85” eram recusadas apesar de cumprirem as regras padrão. A equipe de segurança atualizou a lista e publicou um guia interno de boas senhas sem termos banidos.

Replicação do SYSVOL atrasada em dois DCs

Dois DCs em site remoto ficaram sem atualizações de GPO por dias. Usuários autenticados nesses DCs viam requisitos diferentes. Após corrigir DFSR e forçar a replicação, as trocas de senha passaram a obedecer o mesmo conjunto de regras.

Procedimento completo sugerido (passo a passo)

Isolar o problema:
- Crie um usuário de teste e tente alterar a senha com um valor claramente randômico e longo (≥ 16).
- Teste por duas vias: ADAC/ADUC e PowerShell.
Verificar políticas efetivas: net accounts /domain Get-ADDefaultDomainPasswordPolicy Get-ADUserResultantPasswordPolicy -Identity <usuario>
Auditar filtros de senha: reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages" Compare a saída entre DCs. Se divergir, padronize a instalação/remoção e reinicie o serviço LSASS (requer reboot).
Checar replicação e hora: repadmin /replsummary w32tm /query /status
Repetir o teste apontando para DCs distintos: Set-ADAccountPassword -Identity <usuarioTeste> -Reset ` -NewPassword (ConvertTo-SecureString "Xp7$!kL#zR2@Y5" -AsPlainText -Force) ` -Server <DC1> Depois repita com -Server <DC2>, -Server <DC3>, etc. Se só alguns DCs falham, foque neles.
Decidir e corrigir:
- FGPP fora do esperado → Ajustar a FGPP ou o escopo (grupos) e comunicar o novo requisito.
- Filtro bloqueando padrões legítimos → Revisar lista de palavras banidas e exceções com segurança.
- Replicação/hora → Normalizar, confirmar coerência e documentar verificação contínua.

Resultado esperado

Após identificar e corrigir o ponto responsável (FGPP oculta, falta de replicação, filtro extra ou regra de complexidade), a mensagem de bloqueio desaparece e os usuários conseguem alterar senhas normalmente. Para manter a saúde do ambiente, formalize um checklist pós‑mudança e monitore periodicamente políticas e replicação.

Nota de operação segura: se precisar desabilitar a complexidade para teste, faça em ambiente de laboratório ou janela controlada, com aprovação e registro. Reversão imediata é mandatória.

Dica de comunicação com usuários: publique um guia rápido de criação de senhas que reflita os requisitos reais (mínimo, categorias, palavras banidas) para reduzir chamados e retrabalho.