Bloqueos de cuenta: por qué se bloquea una cuenta de Active Directory

El módulo de Bloqueos de cuenta responde, desde el panel y sin entrar por RDP al Domain Controller, por qué se bloquea una cuenta de Active Directory: qué equipo originó el último bloqueo, desde dónde llegan los intentos fallidos de autenticación y qué está reintentando con la contraseña vieja. El relevamiento corre a través del agente ya instalado en el Domain Controller y termina en un diagnóstico con hallazgos codificados y un informe PDF con tu marca.

El módulo se abre desde la ficha del Domain Controller y la búsqueda del usuario acepta nombre y apellido, nombre de cuenta, UPN o correo. Si el término coincide con varias cuentas, la pantalla lista las coincidencias con el estado de cada una y el técnico elige cuál relevar: nunca se releva una cuenta que el técnico no eligió.

El equipo que originó el bloqueo: evento 4740 del PDC Emulator

Windows escribe el evento 4740, el que registra el bloqueo de una cuenta, en un solo lugar del dominio: el PDC Emulator. KairosLink lo lee ahí y muestra el equipo de origen y la fecha exacta del último bloqueo. Si el relevamiento se hizo contra un Domain Controller que no es el PDC Emulator, el diagnóstico lo dice, nombra cuál es el PDC del dominio y ofrece repetir la consulta contra él.

Si la auditoría de bloqueos está apagada en el Domain Controller, el evento 4740 no se escribe nunca y el origen del bloqueo no se puede determinar. KairosLink detecta esa situación y permite activar la auditoría desde el panel, con motivo escrito obligatorio y registro en la auditoría de seguridad. Es la única acción del módulo que modifica el Domain Controller. Si una GPO del dominio gestiona esa política, el diagnóstico avisa que la GPO va a sobrescribir el cambio local.

De dónde vienen los intentos fallidos: eventos 4771 y 4625

El relevamiento cubre una ventana de 72 horas y agrupa los intentos fallidos de autenticación (eventos 4771 de Kerberos y 4625 de NTLM) por equipo de origen, con la cantidad de intentos y la fecha del último. Ahí aparece el patrón real: un solo equipo con decenas de fallos, o varios orígenes distintos fallando al mismo tiempo.

Cuando los fallos provienen de un Domain Controller, el diagnóstico lo marca aparte. Significa que un servicio intermediario está autenticando en nombre del usuario, y el equipo donde la persona trabaja no es el culpable.

Tres o más intentos fallidos del mismo origen dentro del mismo segundo se reportan como ráfaga automatizada. Nadie tipea mal una contraseña tres veces en un segundo: ese patrón es un dispositivo o un servicio reintentando en bucle con una credencial vieja.

El mismo relevamiento trae la política de contraseñas del dominio y la política granular (FGPP) que aplica a esa cuenta, que es la que define el umbral de bloqueo y la ventana de observación reales del usuario.

Qué sigue reintentando con la contraseña vieja

Saber qué equipo originó el bloqueo no alcanza: hay que encontrar qué corre dentro de ese equipo con la credencial vieja. Con un clic, KairosLink analiza el equipo de origen y releva sesiones abiertas o desconectadas, tareas programadas, servicios, credenciales guardadas, unidades de red y perfiles en disco asociados a esa cuenta.

La búsqueda se hace por SID además de por nombre de cuenta. Cuando el perfil de un usuario se borra de un equipo, sus tareas programadas no se borran: quedan referenciando el SID, porque ya no hay nombre que resolver. Por nombre no aparecen; por SID sí. Ese caso, perfil borrado con tareas vivas, se marca como hallazgo propio.

Cuando los fallos vienen de un Domain Controller, el análisis equivalente se hace sobre ese DC, para identificar qué servicio está mediando la autenticación. Los dos análisis son de solo lectura: relevan y describen, no borran tareas, no detienen servicios y no tocan credenciales.

Sobre la cuenta, el técnico puede desbloquear, habilitar y forzar el cambio de contraseña en el próximo inicio de sesión. Cada una de esas acciones queda en el historial de acciones de Active Directory, con el técnico que la ejecutó.

Dónde tiene sesión abierta el usuario: se le pregunta a cada equipo

Windows no lleva un registro central de dónde está logueado un usuario del dominio. La única fuente cierta es preguntarle a los equipos, y eso es exactamente lo que hace el panel: le consulta con quser a cada equipo online del cliente si esa cuenta tiene sesión abierta, y muestra lo que cada uno respondió.

El resultado nunca mezcla tres cosas distintas: los equipos donde hay sesión, los equipos que respondieron que la cuenta no tiene sesión, y los equipos a los que no se pudo preguntar, cada uno con el motivo escrito (estaba offline, no tiene agente, no respondió a tiempo). Un equipo que no contestó no es un equipo sin sesión, y la pantalla no lo cuenta como tal.

De cada sesión encontrada se informa si está activa o desconectada. La distinción importa en un diagnóstico de bloqueos: una sesión desconectada que quedó abierta hace semanas con la contraseña vieja sigue reintentando sola, y nadie la está mirando.

La consulta es de solo lectura: dice dónde hay sesión y no cierra ninguna. En este módulo no hay logoff remoto.

Historial de inicios de sesión: lo que vio cada Domain Controller

El atributo lastLogon de Active Directory no replica entre Domain Controllers: cada uno guarda el que él mismo autenticó. Preguntarle a uno solo da una respuesta parcial, y esa es la trampa clásica de este dato. KairosLink le pregunta a todos los Domain Controllers del dominio y muestra la respuesta de cada uno, con el nombre del DC al lado y los que no respondieron en su propia lista.

Junto a eso se muestra el lastLogonTimestamp, que sí replica, con el aviso de que arrastra un desfase de hasta 14 días por diseño de Active Directory. Sirve para saber si una cuenta se usa; no sirve para saber si se usó esta mañana.

También se suman los inicios de sesión que vio el Domain Controller (evento 4624 de la misma ventana), agrupados por equipo de origen, con el tipo de inicio, la cantidad y el último. El dato viene con su límite escrito al lado: un Domain Controller solo ve los inicios de sesión que pasaron por él, así que lo que la persona hizo contra su propia estación de trabajo no aparece ahí.

Esa diferencia es parte del diagnóstico, no una limitación que se esconde. Preguntarle a un equipo si la cuenta tiene sesión abierta es un dato cierto. Lo que Active Directory informa sobre inicios de sesión es una inferencia sobre lo que un Domain Controller alcanzó a ver. Las dos cosas se muestran por separado y cada pantalla dice de dónde salió el número.

Roles FSMO: quién es realmente el PDC Emulator

El diagnóstico muestra los cinco roles FSMO del dominio y qué Domain Controller tiene cada uno. Importa por una razón concreta: el evento 4740 se escribe solo en el PDC Emulator, así que relevar el Domain Controller equivocado deja el origen del bloqueo invisible.

El titular del rol PDC Emulator se corrobora contra dos fuentes distintas del propio dominio. Si las dos no coinciden, el diagnóstico lo informa como hallazgo en vez de elegir una por su cuenta. Cuando el dominio se contradice sobre quién es su PDC, eso es información para el técnico, no ruido para tapar.

Criterio determinista, sin IA en el análisis

La evaluación vive en el código del panel, no en un modelo de lenguaje: los mismos datos producen siempre los mismos hallazgos, cada uno con su código, su causa y la acción recomendada. Ninguna IA interviene en el análisis de un bloqueo.

El diagnóstico distingue siempre "no hay problema" de "no puedo verlo". Cuando falta un dato, la pantalla dice qué falta y por qué, en vez de mostrar un vacío que se pueda leer como un resultado: no encontrar un evento 4740 con la auditoría apagada no significa que la cuenta no se haya bloqueado.

El diagnóstico completo sale en un informe PDF con el logo y el encabezado de tu empresa, listo para entregarle al cliente.

Bloqueos de cuenta está disponible en los planes Business y Enterprise.

Preguntas frecuentes