Conta do Active Directory que “não desbloqueia” mesmo após trocar a senha quase sempre está sendo re‑bloqueada por tentativas com a senha antiga. Veja como rastrear, identificar o dispositivo ou serviço causador e corrigir de forma definitiva, com comandos e checklist prático.
Visão geral e causa mais provável
Quando um usuário informa que redefiniu a senha mas a conta permanece bloqueada, o cenário mais comum é o seguinte: algum dispositivo, serviço ou aplicativo continua tentando autenticar com a senha antiga. Cada tentativa inválida aumenta o contador de falhas até atingir o limite de bloqueio, e o ciclo se repete.
Fontes típicas de tentativas com credenciais obsoletas incluem: computadores antigos ou secundários, tarefas agendadas, serviços Windows, pools de aplicativos do IIS, unidades de rede mapeadas, credenciais salvas no Gerenciador de Credenciais, clientes de e‑mail, sincronizadores de arquivos, VPN, Wi‑Fi com 802.1X, sessões RDP persistentes e scripts de logon.
Caso real resumido: o bloqueio vinha de uma máquina antiga do usuário que continuava a enviar credenciais desatualizadas. Ao remover as credenciais e parar o serviço que as usava, o problema foi resolvido.
Sinais e sintomas
- O usuário redefine a senha e, pouco tempo depois, a conta volta a ficar bloqueada.
- Eventos de Segurança no controlador de domínio mostram falhas de autenticação imediatamente antes do bloqueio.
- Mensagens de erro comuns no cliente: “A senha está incorreta”, “A conta foi bloqueada”, falhas de Kerberos ou NTLM.
Passo a passo para diagnóstico e correção
Habilitar auditoria nos controladores de domínio
Garanta a auditoria detalhada de logon e bloqueio em todos os controladores de domínio via Advanced Audit Policy na GPO de Domain Controllers:
- Logon/Logoff: Audit Account Lockout — Failure; Audit Logon — Failure; Audit Kerberos Authentication Service — Failure; Audit Credential Validation — Failure.
- Account Management: Audit User Account Management — Success e Failure.
Após aplicar a política, atualize e confira o status diretamente nos DCs:
gpupdate /force
auditpol /get /category:*
Dica: se possível, habilite também Kerberos Authentication Ticket — Failure para enriquecer o contexto.
Descobrir em qual controlador o bloqueio surgiu primeiro
Use a ferramenta LockoutStatus.exe (Account Lockout Tools) para consultar o usuário afetado. Ela exibe o controlador que registrou o bloqueio e o horário. Sem essa ferramenta, obtenha a lista de DCs e varra os logs com PowerShell (exemplos mais abaixo). O bloqueio nasce em um DC e replica para os demais; atacar a origem acelera o diagnóstico.
Analisar os logs de segurança do controlador apontado
Pesquise os eventos imediatamente anteriores ao bloqueio. Os mais relevantes são:
- 4740 — Account lockout (confirma o bloqueio e o DC envolvido).
- 4771 — Kerberos pre-authentication failed (traz o endereço do cliente).
- 4776 — NTLM authentication (traz a estação de origem).
Erros típicos:
- 0x18 — pré‑autenticação inválida no Kerberos (senha incorreta).
- 0xC000006A — usuário correto, senha incorreta no NTLM.
Filtre por ID de evento e pelo nome da conta; foque nos registros anteriores ao 4740 para encontrar a origem das tentativas.
Rastrear a origem do cliente
- No evento de Kerberos, localize Client Address (normalmente um IP de origem; pode vir em IPv4, IPv6 ou notação mapeada).
- No evento de NTLM, veja Source Workstation (nome do host que apresentou a senha errada).
Com o IP/host em mãos, investigue o dispositivo: é o computador principal do usuário? Um notebook antigo? Uma VM esquecida? Um servidor de aplicações?
Eliminar credenciais antigas no dispositivo de origem
No equipamento identificado, faça um pente‑fino. Remova, atualize ou desabilite todo lugar que possa guardar a senha antiga:
- Gerenciador de Credenciais: apague entradas do tipo Windows Credentials e Enterprise. Alternativa em linha de comando:
cmdkey /list cmdkey /delete:TERMINAL.SERVER cmdkey /generic:delete:ad.example.local
- Unidades mapeadas:
net use net use * /delete /y PowerShell Get-SmbMapping | Remove-SmbMapping -Force
- Tarefas agendadas que executam com a conta do usuário:
# PowerShell - listar tarefas que usam a conta Get-ScheduledTask | Where-Object { $_.Principal.UserId -match 'DOMINIO\\usuario' } | Select-Object TaskName, TaskPath, State, @{n='User';e={$_.Principal.UserId}}
- Serviços configurados com a conta:
# PowerShell - serviços cujo StartName contém a conta Get-CimInstance Win32Service | Where-Object { $.StartName -match 'DOMINIO\\usuario' } | Select-Object Name, State, StartMode, StartName
- IIS — pools de aplicativos:
# PowerShell (módulo WebAdministration) Import-Module WebAdministration Get-ItemProperty 'IIS:\AppPools\*' | Select-Object name, @{n='UserName';e={$.processModel.userName}}, @{n='IdentityType';e={$.processModel.identityType}}
- Scripts e apps (logon, backup, sincronizadores, clientes de e‑mail, integrações):
# Procurar referências à conta em scripts Get-ChildItem C:\Scripts -Recurse -Include .ps1,.bat,.cmd,.vbs,*.config | Select-String -Pattern 'DOMINIO\\usuario','-Credential','UserName' -List
- VPN e Wi‑Fi 802.1X: atualize as credenciais salvas.
- RDP: apague credenciais e atalhos que as guardam:
mstsc /delete:SERVIDOR e remova entradas relacionadas via cmdkey (ver acima)
- Sessões antigas: desligue notebooks aposentados, VMs não usadas e sessões desconectadas. Remova do domínio o que não é mais necessário.
Dica: habilite no cliente a auditoria de falha de logon para registrar o evento correspondente (por exemplo, 4625) e, no campo Process Information, ver qual processo acionou a tentativa.
Aplicar a nova senha em todos os pontos e só depois desbloquear
Após higienizar todas as origens, aplique a nova senha onde necessário e então desbloqueie a conta. Opções:
# PowerShell (ActiveDirectory)
Unlock-ADAccount -Identity usuario
Forçar sincronização entre DCs (cautela em ambientes grandes)
repadmin /syncall /AdeP
Se o contador de falhas voltar a subir, é sinal de que ainda resta uma origem com senha antiga. Repita o rastreio concentrando-se nos eventos imediatamente anteriores ao novo bloqueio.
Checklist rápido
- Auditoria ativa nos controladores de domínio para logon, bloqueio de conta e validação de credenciais.
- Controlador que registrou o bloqueio identificado via LockoutStatus ou varredura de eventos.
- Eventos de Segurança analisados, com IP ou host de origem localizado.
- Credenciais antigas removidas: gerenciador de credenciais, unidades mapeadas, serviços, tarefas, pools de aplicativos e scripts.
- Dispositivos antigos verificados, desligados ou removidos do domínio.
- Conta desbloqueada somente após o saneamento completo.
Mapa de eventos e campos úteis
Evento | Protocolo | Onde aparece | Campos relevantes | Como usar |
---|---|---|---|---|
4740 | Bloqueio de conta | Segurança do controlador | Account Name, Caller Computer Name, Time | Confirma o bloqueio e indica o DC que registrou o fato. |
4771 | Kerberos | Segurança do controlador | Client Address, Failure Code | IP de origem e motivo da falha; rastreie o cliente pelo endereço. |
4776 | NTLM | Segurança do controlador | Source Workstation, Status | Nome da estação de origem; correlacione com o usuário. |
4625 | Falha de logon | Log de Segurança do cliente | Process Information, Target Account | Revela qual processo no cliente gerou a tentativa. |
Códigos comuns e seu significado:
Código | Descrição | Interpretação prática |
---|---|---|
0x18 | Pré‑autenticação inválida (Kerberos) | Senha incorreta ou relógio de sistema muito fora de sincronia. |
0xC000006A | Senha incorreta (NTLM) | Autenticação com senha antiga salva em algum lugar. |
0xC0000064 | Usuário inexistente | Nome de usuário errado (por exemplo, sufixo errado ou digitação). |
0xC0000234 | Conta já bloqueada | Falhas continuam mesmo após o bloqueio; a origem persiste. |
Comandos úteis para acelerar a investigação
Execute a partir de um administrador com as RSAT do Active Directory instaladas.
Enumerar controladores e varrer os eventos de bloqueio
# Listar controladores
Get-ADDomainController -Filter * | Select-Object HostName, IPv4Address, Site
Ultimos bloqueios em todos os DCs nas últimas 24h
\$since = (Get-Date).AddDays(-1)
\$dcs = (Get-ADDomainController -Filter \*).HostName
foreach (\$dc in \$dcs) {
Get-WinEvent -ComputerName \$dc -FilterHashtable @{LogName='Security'; Id=4740; StartTime=\$since} |
Select-Object MachineName, TimeCreated,
@{n='Conta';e={\$*.Properties\[0].Value}},
@{n='Chamador';e={\$*.Properties\[1].Value}}
}
Correlacionar falhas de Kerberos e NTLM
# Kerberos (falhas) — pegue Client Address e Failure Code
Get-WinEvent -ComputerName $env:LOGONSERVER.TrimStart('\') `
-FilterHashtable @{LogName='Security'; Id=4771; StartTime=$since} |
Select-Object TimeCreated,
@{n='Usuario';e={$_.Properties[0].Value}},
@{n='ClientAddress';e={$_.Properties[6].Value}},
@{n='FailureCode';e={$_.Properties[9].Value}}
NTLM (falhas) — pegue Source Workstation e Status
Get-WinEvent -ComputerName \$env\:LOGONSERVER.TrimStart('') \`
-FilterHashtable @{LogName='Security'; Id=4776; StartTime=\$since} |
Select-Object TimeCreated,
@{n='Usuario';e={\$*.Properties\[1].Value}},
@{n='Workstation';e={\$*.Properties\[2].Value}},
@{n='Status';e={$\_.Properties\[4].Value}}
Resolver IP para nome de máquina
# Se tiver o IP do cliente
Resolve-DnsName 10.10.10.25
ou
nbtstat -A 10.10.10.25
Verificar estado do usuário e facilidades para desbloqueio
# Conferir rapidamente o estado
Get-ADUser usuario -Properties LockedOut, LastBadPasswordAttempt, badPwdCount |
Select-Object SamAccountName, LockedOut, LastBadPasswordAttempt, badPwdCount
Desbloquear
Unlock-ADAccount -Identity usuario
Limpar tickets de Kerberos no cliente
# Útil após troca de senha para evitar tickets antigos
klist purge
Cenários menos óbvios que também causam re‑bloqueio
- Diferença de horário: relógio do cliente fora do limite aceito (skew) faz o Kerberos falhar; sincronize NTP corretamente.
- Perfis móveis e pastas sincronizadas: serviços de sincronização podem manter credenciais.
- Aplicativos em servidores de terceiros: integrações que usam a conta do usuário em servidores que você não administra diretamente.
- Dispositivos móveis: e‑mail corporativo e apps com senha antiga (incluindo perfis de Exchange ActiveSync).
- Conflitos de nomes: hosts clonados ou registros DNS antigos fazem o IP apontar para o dispositivo errado; valide com DNS e DHCP.
Boas práticas de prevenção
- Padronize a rotina de troca de senha com um checklist que inclua serviços, tarefas e unidades mapeadas.
- Evite usar contas pessoais para serviços. Prefira contas de serviço dedicadas com rotação controlada de senha (ou gMSA).
- Implemente alertas para eventos de interesse no Security Log (bloqueio e falhas de autenticação) e relatórios periódicos de bloqueio.
- Documente as dependências de contas críticas (tarefas, serviços, integrações) e revise a cada mudança de senha.
- Defina políticas de bloqueio e expiração de senha em níveis adequados ao risco para reduzir falsos positivos.
- Invista em higiene de DNS: limpeza de registros órfãos e verificação de reverso, para que IPs sempre resolvam para o host correto.
- Centralize logs via Windows Event Forwarding ou SIEM para acelerar correlação e busca.
Perguntas frequentes
Por que desbloquear sem investigar não resolve?
Porque a origem continua tentando a senha antiga, elevando o contador até novo bloqueio. Desbloquear sem remover a causa apenas reinicia o ciclo. Posso simplesmente redefinir a senha de novo?
Redefinir sem remover as credenciais antigas não ajuda. Em alguns casos, piora — vários dispositivos tentam alternadamente senhas diferentes, multiplicando as falhas. Qual é o melhor lugar para começar a investigação?
O controlador que registrou o evento de bloqueio. Consulte o evento de bloqueio e, imediatamente antes dele, os eventos de falha de Kerberos e NTLM para pegar IP e host. É possível que seja ataque externo?
Sim. Se as falhas vierem de endereços desconhecidos (por exemplo, VPN, proxies, fronteira), trate como incidente. Eleve a observabilidade e exija dupla verificação. Quanto tempo até a replicação refletir o desbloqueio?
Normalmente é rápido, mas depende da topologia e do agendamento de replicação. Para acelerar, sincronize os controladores e valide novamente o estado do usuário.
Fluxo de trabalho consolidado
Habilitar auditoria nos DCs
↓
Localizar o primeiro DC que registrou o bloqueio
↓
Extrair IP/host de origem nos eventos de falha anteriores
↓
Acessar o cliente e remover/atualizar todas as credenciais
↓
Aplicar a senha nova em todo lugar e desbloquear
↓
Monitorar: se falhas persistirem, repetir o rastreio
Resumo em uma frase
Contas que “não desbloqueiam” normalmente estão sendo re‑bloqueadas por algum dispositivo ou serviço que ainda usa a senha antiga; habilite auditoria, identifique a origem nos eventos de segurança, limpe as credenciais no cliente problemático (muitas vezes uma máquina antiga) e só então desbloqueie.