¿Cómo rastrear y resolver una cuenta de Active Directory bloqueada? Descubra qué ocurre, cómo encontrar eventos específicos y cómo analizar los eventos.
Active Directory (AD) es un servicio maravilloso. Puede iniciar sesión desde cualquier lugar de la red utilizando el mismo nombre de usuario y contraseña. No podría ser más fácil – es decir, hasta que se olvida de cerrar una sesión de escritorio remoto, o un gusano se propaga a través de la red, o se olvida de que está ejecutando una tarea programada como su cuenta de usuario, o … Bueno, ya se entiende. AD es un producto extremadamente útil; por eso su tasa de adopción es tan alta. El problema es cuando una cuenta empieza a bloquearse sin motivo alguno. O eso crees.
Políticas de bloqueo de cuentas de AD
Muchas organizaciones tienen (o deberían tener) políticas de bloqueo de cuentas. Esta política es una medida de seguridad para evitar que personas no autorizadas intenten adivinar la contraseña continuamente o hacer fuerza bruta con una contraseña. Las políticas de bloqueo de cuentas son habituales en Active Directory y consisten en un enfoque sencillo para combatir un problema de seguridad importante. Si se intenta la contraseña incorrecta un cierto número de veces, la cuenta queda inutilizada hasta que un administrador la vuelva a habilitar manualmente. La intención es cierta, pero en algunos casos, la implementación no lo es.
En algunas situaciones, especialmente cuando se cambia una contraseña, una cuenta puede empezar a bloquearse de repente de forma consistente sin razón aparente. Un usuario llama a la mesa de ayuda, la mesa de ayuda vuelve a habilitar la cuenta, y un poco más tarde, la cuenta se bloquea de nuevo. Es una experiencia frustrante tanto para el usuario como para el servicio de asistencia. A veces el problema se agrava por el origen desconocido de los bloqueos. En algún lugar, de alguna manera, hay una persona, un script o un proceso que intenta continuamente la misma contraseña errónea una y otra vez, pero nadie sabe dónde.
Entonces, ¿cómo se pueden rastrear estos molestos bloqueos? Una forma es utilizando un script de PowerShell. Pero primero, repasemos lo que sucede cuando una cuenta está bloqueada.
Resolución de una cuenta de AD bloqueada
En un entorno de Windows Server 2008 o posterior, hay un breve ida y vuelta entre el sistema cliente, el controlador de dominio del sistema cliente y el controlador de dominio que tiene el rol de emulador de controlador de dominio principal (PDC). Esto ocurre de la siguiente manera:
- Cuando se intenta la autenticación de una cuenta de usuario, las credenciales se envían al controlador de dominio apropiado para la subred del sistema cliente.
- Si la contraseña es incorrecta, el controlador de dominio del sistema cliente reenvía la solicitud al controlador de dominio que tiene el rol de emulador de PDC. Esto se debe a que el controlador de dominio del sistema cliente podría no tener la contraseña más actualizada y, como característica de diseño de Active Directory, el controlador de dominio que tiene el rol de emulador de PDC siempre la tendrá.
- El emulador de PDC vuelve a intentar la contraseña y, si sigue siendo incorrecta, el emulador de PDC incrementa el atributo badPwdCount de la cuenta de usuario.
- Se genera un ID de evento 4740 en el emulador de PDC con la dirección IP del sistema cliente que inició la solicitud original y con la cuenta de usuario.
- El emulador PDC entonces informa al controlador de dominio del sistema cliente que la contraseña es, de hecho, incorrecta.
- El controlador de dominio del sistema cliente entonces notifica al sistema cliente que la contraseña era incorrecta.
¿Dónde sería el mejor lugar para encontrar la fuente? La respuesta es en el emulador del CDP. La razón es que cada bloqueo de cuenta se registra allí en el registro de eventos de seguridad. El emulador PDC es un lugar central que puede ser consultado para todos los eventos de bloqueo de cuentas.
Using PowerShell To Track Down The Source Of AD Account Lockouts
Para consultar el emulador PDC, utilizaremos el cmdlet Get-WinEvent de PowerShell. Este es un cmdlet extremadamente útil para analizar rápidamente uno o más registros de eventos en un servidor. Estamos buscando un ID de evento de 4740. En primer lugar, tenemos que encontrar el controlador de dominio que tiene el rol de emulador PDC. Una forma de hacerlo es utilizando el cmdlet Get-AdDomain.
Una vez que conocemos el emulador PDC, entonces es sólo cuestión de consultar su registro de eventos de seguridad para el ID de evento 4740.
Tengo una cuenta llamada abertram que está bloqueada. Vamos a ver cómo localizar al culpable.
Ahora tenemos el emulador PDC, así que vamos a consultar su registro de seguridad con un script de PowerShell.
## Definir el nombre de usuario que está bloqueado$Username = ‘abertram’## Encontrar el rol PDCe del controlador de dominio$Pdce = (Get-AdDomain).PDCEmulator
## Construir los parámetros para pasar a Get-WinEvent$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security»FilterXPath’ = «* y EventData=’$Username’]]»
}# Consultar el registro de eventos de seguridad$Events = Get-WinEvent @GweParams
Esto nos da el evento de bloqueo.
Pero aún no tenemos el sistema cliente de origen. Para obtener eso, tendremos que cavar un poco más profundo. El nombre de usuario real está enterrado en el valor de las Propiedades de cada evento. Para encontrar el nombre de usuario en cada evento, podemos simplemente usar esta línea.
$Events.Properties.Value
Esto encuentra el nombre de usuario en el primer evento y en la primera instancia del valor Properties. Por suerte, el sistema cliente está justo en la segunda instancia de Properties.
$Events.Properties.Value
Una vez que se sabe dónde se encuentra el nombre del sistema cliente, sólo es cuestión de insertarlo en un bucle, y hemos encontrado al culpable.
Ahora está armado y listo para ir la próxima vez que el servicio de asistencia le llama con esa cuenta de usuario AD incesante que sigue siendo bloqueado.