Cuenta de Active Directory que se bloquea: causas y solución

Desbloqueas la cuenta de un usuario en Active Directory y a los diez minutos vuelve a estar bloqueada. Lo haces otra vez, y otra. Es uno de los problemas más desesperantes del soporte en entornos Windows, porque desbloquear es trivial pero encontrar por qué ocurre exige seguir un rastro. En esta guía verás cómo desbloquear una cuenta (con la consola y con PowerShell), cómo funcionan las directivas de bloqueo, cómo localizar el equipo o el servicio que está enviando la contraseña incorrecta y cuáles son las causas más comunes, desde una unidad de red olvidada hasta un ataque de adivinación de contraseñas.

Desbloquear una cuenta rápidamente

Con la consola Usuarios y equipos de Active Directory: busca al usuario, abre sus propiedades, ve a la pestaña Cuenta y marca Desbloquear cuenta. Con PowerShell, que es más rápido y se puede automatizar:

# Ver qué cuentas están bloqueadas ahora mismo
Search-ADAccount -LockedOut -UsersOnly | Select-Object Name, SamAccountName, LockedOut, LastLogonDate

# Desbloquear una cuenta
Unlock-ADAccount -Identity l.gomez

# Información detallada del usuario
Get-ADUser -Identity l.gomez -Properties LockedOut, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet, PasswordExpired |
    Select-Object Name, LockedOut, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet, PasswordExpired

Un matiz que conviene saber: BadLogonCount y LastBadPasswordAttempt no se replican entre controladores de dominio, de modo que el valor que ves depende del controlador al que te conectas. Si necesitas el dato completo, consulta cada controlador (con -Server) o, mejor, usa los registros de eventos, como veremos más abajo.

Cómo funciona el bloqueo de cuentas

El bloqueo se controla con tres valores de la directiva de contraseñas del dominio (Directiva de bloqueo de cuenta):

Umbral de bloqueo de la cuenta: cuántos intentos fallidos se permiten antes de bloquear.
Duración del bloqueo de la cuenta: cuánto tiempo permanece bloqueada (0 significa que hasta que un administrador la desbloquee).
Restablecer el bloqueo de la cuenta tras: el periodo (ventana de observación) tras el cual el contador de intentos fallidos vuelve a cero.

Para consultar la directiva efectiva:

# Directiva predeterminada del dominio
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

# Directiva que realmente se aplica a un usuario concreto (si tiene una directiva de contraseña específica)
Get-ADUserResultantPasswordPolicy -Identity l.gomez

# Directivas específicas definidas en el dominio
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, LockoutThreshold, AppliesTo

Si un usuario tiene aplicada una directiva de contraseña específica (Fine-Grained Password Policy), esta prevalece sobre la del dominio. Un umbral razonable suele estar entre 5 y 10 intentos, con una ventana y una duración de 15 a 30 minutos: lo bastante estricto para frenar un ataque y lo bastante permisivo para que un despiste no deje a un usuario sin cuenta.

Paso 1: encuentra en qué controlador se produce el bloqueo

Cuando un usuario escribe mal la contraseña, el controlador que la recibe la reenvía al emulador de PDC antes de rechazarla definitivamente. Por eso el emulador de PDC es el que mejor conoce los intentos fallidos y el que registra el bloqueo en su registro de seguridad. Localízalo y busca ahí:

$pdc = (Get-ADDomain).PDCEmulator
$usuario = 'l.gomez'

Get-WinEvent -ComputerName $pdc -FilterHashtable @{ LogName = 'Security'; Id = 4740; StartTime = (Get-Date).AddDays(-1) } |
    Where-Object { $_.Properties[0].Value -eq $usuario } |
    Select-Object TimeCreated, @{N='Equipo origen';E={$_.Properties[1].Value}}

El evento 4740 (se bloqueó una cuenta de usuario) incluye el nombre del equipo de origen («Caller Computer Name»): el equipo desde el que llegaron las contraseñas incorrectas. Ese es el dato clave. Si la búsqueda no devuelve nada, comprueba que la auditoría de administración de cuentas está activada en los controladores (Auditar administración de cuentas de usuario) y que tienes permisos para leer el registro de seguridad. Para repasar cómo se consultan los eventos con Get-WinEvent, tienes ejemplos en los 10 comandos de PowerShell imprescindibles.

Paso 2: investiga el equipo de origen

Una vez que sabes qué equipo envía las contraseñas erróneas, ve a ese equipo (o consulta su registro de seguridad) y busca los eventos de inicio de sesión fallido:

Get-WinEvent -ComputerName PC-ORIGEN -FilterHashtable @{ LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6) } |
    Where-Object { $_.Properties[5].Value -eq 'l.gomez' } |
    Select-Object TimeCreated,
        @{N='Tipo de inicio';E={$_.Properties[10].Value}},
        @{N='Proceso';E={$_.Properties[18].Value}},
        @{N='Estado';E={'0x{0:X}' -f $_.Properties[7].Value}}

Los datos más reveladores son el tipo de inicio de sesión y el proceso que lo solicita:

Tipo 2 (interactivo): alguien escribió mal la contraseña delante del equipo.
Tipo 3 (red): una conexión a un recurso compartido o a un servicio. Típico de unidades de red mapeadas con credenciales antiguas.
Tipo 4 (por lotes): una tarea programada que usa esa cuenta con una contraseña caducada.
Tipo 5 (servicio): un servicio de Windows configurado para iniciar con esa cuenta.
Tipo 7 (desbloqueo): alguien intentó desbloquear una sesión con la contraseña equivocada.
Tipo 10 (remoto interactivo): una conexión de Escritorio remoto, incluyendo sesiones desconectadas que quedaron abiertas.

El código de estado 0xC000006A indica contraseña incorrecta, y 0xC0000234 significa que la cuenta ya estaba bloqueada. En los controladores de dominio, otros dos eventos aportan información: el 4771 (error de preautenticación Kerberos, con el código 0x18 para una contraseña incorrecta) y el 4776 (validación de credenciales NTLM).

Las causas más habituales

Servicios y tareas programadas con credenciales antiguas. Si cambias la contraseña de una cuenta usada por un servicio o una tarea, esos procesos siguen intentando entrar con la anterior, cada pocos minutos. Revisa los servicios (services.msc, columna «Iniciar sesión como») y las tareas programadas del equipo origen.
Unidades de red mapeadas y credenciales guardadas. El Administrador de credenciales de Windows (control keymgr.dll) guarda contraseñas antiguas que se reenvían una y otra vez. Elimina las entradas obsoletas.
Dispositivos móviles y correo. Un teléfono o una tableta con la cuenta de correo configurada y la contraseña antigua, un cliente de Outlook, una aplicación de correo en otro equipo o un perfil de Teams. Son una causa frecuentísima tras un cambio de contraseña.
Sesiones de Escritorio remoto desconectadas en servidores, que conservan credenciales anteriores y siguen intentando conectarse a recursos de red.
Aplicaciones que guardan credenciales: grupos de aplicaciones de IIS, trabajos de SQL Server, programas de copia de seguridad, navegadores o clientes de sincronización.
Un usuario con varias sesiones en equipos distintos, donde en uno de ellos la contraseña no se ha actualizado.
Un ataque de adivinación de contraseñas. Si el origen es una dirección desconocida o el bloqueo afecta a muchas cuentas a la vez, puede tratarse de un ataque. Las señales son muchos eventos 4625 o 4771 contra cuentas distintas desde la misma dirección o con pocos intentos por cuenta (para no llegar al umbral). En ese caso, bloquea el origen en el cortafuegos, revisa los accesos externos y aplica verificación en dos pasos; consulta también nuestra guía sobre qué es el phishing y cómo detectarlo.

Cuando el evento 4740 no basta: registro de Netlogon

En algunos casos, el origen del bloqueo no es un equipo de la red sino un servicio que se autentica contra el controlador. Para obtener más detalle, puedes activar temporalmente el registro de depuración de Netlogon en el controlador (o controladores) donde se producen los intentos:

# Activar el registro detallado de Netlogon
nltest /dbflag:0x2080ffff

# El registro se escribe en:
notepad "$env:windir\debug\netlogon.log"

# Desactivarlo al terminar (importante: genera mucho volumen)
nltest /dbflag:0x0

Busca en netlogon.log las líneas con el nombre del usuario y el código 0xC000006A (contraseña incorrecta): indican el equipo y el momento de cada intento. Actívalo solo el tiempo necesario, porque el registro crece rápido y consume disco y rendimiento.

Una rutina de resolución en cinco pasos

Desbloquea la cuenta y espera a que se vuelva a bloquear (anota la hora).
En el emulador de PDC, busca el evento 4740 de esa hora y anota el equipo de origen.
En el equipo de origen, busca los eventos 4625 y fíjate en el tipo de inicio de sesión y el proceso.
Según el tipo, revisa servicios, tareas, unidades de red, credenciales guardadas o sesiones remotas, y corrige la contraseña en cada lugar.
Desbloquea de nuevo y comprueba que no se repite durante una o dos horas.

Cómo evitar que se repita

Usa cuentas de servicio dedicadas y, siempre que sea posible, cuentas de servicio administradas de grupo (gMSA), que cambian su contraseña solas y no se bloquean por olvidos humanos. No uses cuentas personales para servicios ni tareas.
Documenta dónde se usa cada cuenta de servicio, para actualizar todos los sitios cuando cambie la contraseña.
Pide a los usuarios que actualicen la contraseña en todos sus dispositivos (móvil, tableta, correo, unidades de red) cuando la cambien.
Ajusta el umbral a un valor razonable: uno demasiado bajo (3 intentos) provoca bloqueos innecesarios, y uno demasiado alto facilita los ataques.
Delega solo el permiso de desbloqueo en el equipo de soporte, sin darles permisos de administrador del dominio; así pueden resolver el problema sin riesgos. Si quieres organizar los grupos de soporte, consulta la guía de usuarios y grupos de Active Directory.
Supervisa los bloqueos: una tarea programada que consulte el evento 4740 cada hora y avise de las cuentas bloqueadas con frecuencia permite detectar el problema antes de que llegue al usuario.
Protege las cuentas con contraseñas robustas: el mejor modo de frenar los ataques no es un umbral bajo sino contraseñas largas y verificación en dos pasos. Tienes recomendaciones en nuestra guía para crear contraseñas seguras.

Si el bloqueo se origina por Escritorio remoto

Los servidores accesibles por RDP desde Internet son el origen más habitual de bloqueos masivos, porque reciben miles de intentos automáticos. La solución no es subir el umbral, sino no exponer el servicio y reforzarlo: lee la guía de cómo proteger el Escritorio Remoto (RDP) en Windows Server.

Preguntas frecuentes

¿Por qué se bloquea la cuenta si el usuario no ha hecho nada?

Porque algún proceso (un servicio, una tarea, un móvil, una unidad de red) sigue intentando entrar con una contraseña antigua. El usuario no lo ve, pero cada intento fallido cuenta para el umbral.

¿Puedo desactivar el bloqueo de cuentas?

Técnicamente sí (umbral 0), pero no es recomendable: dejas la cuenta expuesta a ataques de fuerza bruta sin ninguna barrera. Es preferible mantenerlo con un umbral razonable y compensarlo con contraseñas largas y verificación en dos pasos.

¿Cuánto tiempo permanece bloqueada la cuenta?

Depende de la duración configurada en la directiva. Si es 0, hasta que un administrador la desbloquee; en otro caso, el tiempo indicado, tras el cual se desbloquea sola.

Conclusión

Desbloquear una cuenta es un comando (Unlock-ADAccount); resolver el bloqueo exige encontrar la causa. Busca el evento 4740 en el emulador de PDC para saber de qué equipo viene, investiga en ese equipo los eventos 4625 para identificar el tipo de inicio de sesión y corrige la contraseña en el servicio, tarea, unidad de red o dispositivo que la tiene guardada. A partir de ahí, usa cuentas de servicio administradas, supervisa los bloqueos y protege las cuentas con contraseñas largas y verificación en dos pasos.

La cuenta de Active Directory se sigue bloqueando: cómo encontrar la causa