El ABC del bloqueo de cuentas.

Por: Cristhian Uribe

 

A 6 años de que los administradores de sistemas se empezaron a familiarizar con el Directorio Activo de Windows 2000, ya no es ningún secreto que la forma de trabajar en problemas de bloqueos inesperados de cuentas es utilizando el documento de Account Passwords and Policies, sin embargo; aun así no dejan de ser comunes las dudas e incidentes relacionados con este tema.

Curiosamente, un 99% de las veces he encontrado la respuesta a esas dudas en el mismo documento.
Cuando uno se introduce en la lectura del mismo, puede darse cuenta de porque es que tanta información es ignorada: se trata de un documento con 42 páginas. A partir de esto surgió la idea de  escribir un documento que resumiera los pasos para resolver casos de bloqueos de cuentas en dominios con Windows 2000 y Windows Server 2003, sin que éste se convierta en un sustituto, sino más bien una guía rápida para resolver casos de bloqueos de cuentas complementada por el documento de Account Passwords and Policies.

 

¿Por qué 10 intentos y no 3?

          Si bien el dilema más común es el de por qué se debe de configurar la política de bloqueos de cuentas a utilizar a 10 intentos con contraseña incorrecta, cuando por lo general las auditorias de seguridad recomiendan el uso de únicamente 3; en éste documento no entraremos en demasiado detalles y únicamente remarcaremos que la recomendación de Microsoft no termina en utilizar 10 intentos con contraseña incorrecta, sino que es parte de una serie de recomendaciones como la complejidad de la contraseña, la ventana de observación, la duración del bloqueo, etc. los cuales hacen que las probabilidades de descifrar la contraseña sean mínimas. Así mismo, recordemos que muchas aplicaciones pueden tomar más de 3 intentos con la contraseña que se los provee, lo cual propiciará que los bloqueos sean más comunes aumentando por lo tanto los costos de operación tanto del help desk como del usuario, debido al tiempo que le tomará al personal de help desk el estar desbloqueando cuentas y el que le tomará a los usuarios el esperar hasta que ésta sea desbloqueada. Para más detalles utilizar el documento de Account Passwords and Policies

 

EL ABC.

La metodología para detectar la causa de un bloqueo de cuentas es tan simple que se puede resumir en 3 pasos:

 

a.              Activar auditoria y logging.

b.             Detectar la máquina causando los intentos con contraseña incorrecta.

c.              Detectar el servicio, aplicación o configuración culpable.

 

a. Activar auditoria y logging.

            El primer paso para detectar la causa de un bloqueo de cuenta inesperado consiste simplemente en configurar los controladores de dominio para capturar información que nos pueda guiar a encontrar desde dónde vienen los intentos con contraseña incorrecta, cuando estos ocurran nuevamente.
Contamos con dos tipos disponibles:

1.      Auditoria

2.      Log de Netlogon.

 

1.      Auditoria.

La activación de auditoria consiste de:
1.1 Editar la política de Default Domain policy.

1.2 Dentro de la política ir a Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

1.3 Activar las siguientes opciones:

·         Account Logon Events – Failure

·         Account Management – Success

·         Logon Events – Failure

        Debido a que esta información aparecerá en el log de seguridad de todos los controladores de dominio, se recomienda cambiar estos para que el tamaño sea cuando menos 10,000KB y con la opción de “Overwrite events as needed”.

 

2.      Log de Netlogon.

      Este se activa de la siguiente forma::

2.1  Ejecutar en una ventana de comandos:
nltest /dbflag:2080ffff

2.2  Reiniciar el servicio de netlogon:
net stop netlogon & net start netlogon

El log se generará en Systemroot\Debug\Netlogon.log en cada controlador de dominio.
Cuando netlogon.log alcanza 20 MB se renombra a netlogon.bak y un nuevo netlogon.log se generará. El tamaño máximo puede ser modificado en el registry cambiando el valor MaximumLogFileSize:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\Parameters

Value: MaximumLogFileSize

Value Type: REG_DWORD

Value Data: 0 min, 0xffffffff max

Value Data Default: DEFAULT_MAXIMUM_LOGFILE_SIZE (~20 MB)

 

 

b. Detectar la máquina causando los intentos con contraseña incorrecta.

Una vez que se ha activado auditoria y logging, el siguiente paso es detectar desde qué máquina están viniendo los intentos con contraseña incorrecta, la cual llamaremos la máquina culpable.
Esto se realiza a través del análisis del log de Seguridad de todos los controladores de dominio y/o del log de Netlogon de los mismos.


Antes de comenzar el análisis, hay que escoger una cuenta que haya presentado el bloqueo para enfocar el análisis hacia ella. Una vez que se determine la causa del bloqueo se puede emplear la misma solución a las demás máquinas, si alguna presenta nuevamente el bloqueo; se realizará el mismo procedimiento esta vez escogiendo esta nueva cuenta.

 

Si bien los logs de Seguridad resultan ser más sencillos de analizar que los logs de Netlogon, cualquiera de los dos métodos es útil.

El log de seguridad se puede analizar con eventcombmt.exe y el de netlogon con nlparse.exe, ambas herramientas incluidas en los Account Lockout Tools. En el caso de que uno no contenga la información, se puede intentar buscar en el otro.


Logs de seguridad.

Cómo se mencionó anteriormente, podemos usar eventcombmt.exe con la opción de Searches\Built In Searches\Account lockouts para analizar los logs de Seguridad. Esta opción automáticamente selecciona todos los controladores de dominio del dominio y busca por los event IDs 529, 644, 675, 676, y 681, los cuales están relacionados con bloqueos de cuentas. El Event ID 644 muestra que la cuenta ha sido bloqueada y los demás muestran intentos con contraseña incorrecta. Delimitemos la búsqueda a solamente la cuenta escogida, escribiendo el nombre en la sección de Text. Eventcombmt hará la búsqueda y creará un log por cada controlador de dominio que se haya revisado y que contenga eventos que cumplan con el criterio especificado. Estos eventos nos indicarán cuál es la máquina que está causando los intentos con contraseña incorrecta. Por lo general los intentos causados por un programa, script o servicio pueden ser identificados por presentar varios intentos dentro del mismo segundo. Un bloqueo causado por un usuario se verá separado por varios segundos.


Es importante entender que cada intento con contraseña incorrecta es verificado una vez por el controlador de dominio que recibió la solicitud y una vez más por el controlador de dominio con el rol de PDC Emulator, por lo que si el que log que estamos revisando es el del PDC Emulator y el intento refleja que el causante fue otro controlador de dominio, tendremos que verificar los logs de éste otro controlador de dominio a la misma hora. Si los eventos en éste controlador de dominio reflejan que el causante es otra máquina entonces habremos encontrado la máquina culpable.

 

Logs de Netlogon.

Para analizar los logs de Netlogon, hay que recolectar los logs de todos los controladores de dominio y después analizarlos con NLParse.exe o con findstr.
Cuando se utilice NLParse.exe seleccione las opciones 0xC000006A (intento con contraseña incorrecta y 0xC0000234 (Cuenta bloqueada) y después haga clic en Extract. En el resultado final hay que identificar aquellos intentos que sean con la cuenta que escogimos y detectar la máquina desde la cuál viene el intento.
Para analizar varios logs a la vez se puede utilizar findstr.exe, el cual viene incluido con Windows 2000, Windows XP y Windows Server 2003. Posteriormente hay que renombrar los logs de netlogon, ponerlos en un solo directorio y correr el siguiente comando:

FindStr /I User1 *netlogon*.log >c:\user1.txt

 

De los logs resultantes hay que analizar cuál es la máquina desde la cual provienen la mayoría de los intentos con contraseña incorrecta. La máquina culpable será la que presente un intento que no diga “via”, si dice que el logon fue “via” computername, entonces hay que analizar el netlogon.log de computername.

Si la máquina que dice “via” no es un controlador de dominio verifique que tipo de servicios provee, para que sepa que analizar en la máquina cliente. Por ejemplo, si se trata de un servidor de Exchange, entonces hay que analizar el Outlook de la máquina cliente.

 

c. Detectar el servicio, aplicación o configuración culpable.

          Una vez que detectemos desde qué máquina vienen los intentos el siguiente paso es activar logging en la máquina culpable y esperar a que vuelvan a ocurrir intentos con contraseña incorrecta con la cuenta del usuario y desde esta máquina.

Dependiendo del tipo de máquina es el tipo de logging:

  • Estación de trabajo con Windows 2000 o Windows XP

o        Alockout.txt
 - Registrar alockout.dll de los
Account Lockout Tools:

1.      Copiar la versión correcta de alockout.dll a %systemroot%\System32

2.      Hacer doble clic al archivo appinit.reg

3.      Reiniciar la computadora.

Esto generará un archivo %systemroot%\Debug\alockout.txt

 

o        Logging de eventos de Kerberos.

o        Para activar  Logging de eventos de Kerberos en los clientes

3.1 Agregar el siguiente valor del registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

      • Registry value: LogLevel
      • Value type: REG_DWORD
      • Value data: 0x1

Nota: Si la llave de Parameters no existe; hay que crearla.

3.2 Reiniciar la computadora.

Para automatizar el proceso se puede usar EnableKerbLog.vbs el cual viene en los Account Lockout Tools.

o        Dejar capturando un Network trace con Network Monitor con un buffer amplio y detenerlo inmediatamente después de que se bloquee la cuenta.

Esto puede ser desde:

    • Una máquina dedicada. (Recomendado). Conectar una máquina dedicada a un puerto de un hub en el cual la máquina culpable se encuentra conectada o a un puerto del switch haciendo mirroring del puerto de la máquina culpable. Para más información ver el siguiente documento:

244209          How to Perform Network Tracing in a Switched Environment

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244209

    • En el controlador de dominio del site que validó a la máquina (en el caso de que haya sólo un controlador de dominio en ese site), 
    • En la misma máquina culpable. Sólo útil en el caso de que los intentos no ocurran al momento de logon.

Para más información de cómo capturar tráfico con Network Monitor:

812953     How to use Network Monitor to capture network traffic

http://support.microsoft.com/default.aspx?scid=kb;EN-US;812953

 

  • Servidor

o        Logging de eventos de Kerberos. Ver sección anterior.

Dejar capturando un Network trace utilizando los pasos listados anteriormente.

 

Cuando ocurra nuevamente el problema y se tenga todo el logging activado el proceso para detectar el servicio culpable es el siguiente:

  1. Encontrar en los eventos de seguridad o en los logs de netlogon la hora y fecha en que ocurrieron los intentos con contraseña incorrecta desde la máquina en donde se activó el alockout.txt, el kerberos logging y/o el network trace.
  2. Analizar el alockout.txt, el log de sistema por los eventos de kerberos y/o el network trace, buscando por eventos o paquetes correspondientes a la misma hora y fecha en que ocurrió el bloqueo. Estos deberían de proveernos con algún rastro del servicio causando el problema.
  3. Una alternativa en caso de que los logs no provean suficiente información es buscar por lo obvio en la máquina cliente culpable. Revisar lo recomendado en la sección de Common Causes for Account Lockouts del documento Account Passwords and Policies