Cómo encontrar la causa de la cuenta de usuario bloqueada en el dominio de Windows AD


18

Después de un incidente reciente con Outlook, me preguntaba cómo resolvería de manera más eficiente el siguiente problema:

Suponga una infraestructura de AD de tamaño pequeño a mediano bastante típica: varios DC, varios servidores internos y clientes de Windows, varios servicios que usan AD y LDAP para la autenticación de usuarios desde la DMZ (retransmisión SMTP, VPN, Citrix, etc.) y varios servicios internos. todos los servicios que dependen de AD para la autenticación (Exchange, servidor SQL, servidores de archivos e impresión, servidores de servicios de terminal). Tiene acceso completo a todos los sistemas, pero son demasiado numerosos (contando los clientes) para verificarlos individualmente.

Ahora suponga que, por alguna razón desconocida, una (o más) cuenta de usuario se bloquea debido a la política de bloqueo de contraseña cada pocos minutos.

  • ¿Cuál sería la mejor manera de encontrar el servicio / máquina responsable de esto?
  • Suponiendo que la infraestructura es pura, Windows estándar sin herramienta de administración adicional y pocos cambios por defecto, ¿hay alguna forma de acelerar o mejorar el proceso de encontrar la causa de dicho bloqueo?
  • ¿Qué se podría hacer para mejorar la resistencia del sistema frente a un bloqueo de cuenta de DOS? Desactivar el bloqueo de la cuenta es una respuesta obvia, pero luego se encuentra con el problema de que los usuarios tienen la posibilidad de utilizar contraseñas fácilmente explotables, incluso con la complejidad impuesta.

1
Mire en el registro de seguridad en el PDCe
Mathias R. Jessen

Impresionante pregunta. Bien desarrollado.
Pecos Bill

Respuestas:


13

Agregar algo que no veo en las respuestas dadas.

¿Cuál sería la mejor manera de encontrar el servicio / máquina responsable de esto?

No puede simplemente mirar el registro de seguridad en el PDCe, porque, si bien el PDCe tiene la información más actualizada sobre los bloqueos de cuentas para todo el dominio, no tiene la información sobre qué cliente (IP o nombre de host) de los intentos fallidos de inicio de sesión, suponiendo que los intentos fallidos de inicio de sesión ocurrieron en otro DC además del PDCe. El PDCe dirá que "la cuenta xyz fue bloqueada", pero no dirá desde dónde, si los inicios de sesión fallidos ocurrieran en otro DC en el dominio. Solo el DC que realmente validó el inicio de sesión registrará el error de inicio de sesión, incluida la dirección del cliente. (Tampoco incluir RODC en esta discusión).

Hay dos buenas maneras de averiguar de dónde provienen los intentos fallidos de inicio de sesión cuando tiene varios controladores de dominio. Reenvío de eventos y herramientas de bloqueo de cuentas de Microsoft .

Prefiero el reenvío de eventos a una ubicación central. Reenvíe los intentos fallidos de inicio de sesión de todos sus controladores de dominio a un servidor de registro central. Entonces solo tiene un lugar para buscar inicios de sesión fallidos en todo su dominio. De hecho, personalmente no amo las herramientas de bloqueo de cuentas de Microsoft, así que ahora hay una buena manera.

Reenvío de eventos. Te encantará.

Suponiendo que la infraestructura es pura, Windows estándar sin herramienta de administración adicional y pocos cambios por defecto, ¿hay alguna forma de acelerar o mejorar el proceso de encontrar la causa de dicho bloqueo?

Véase más arriba. Luego, puede tener su sistema de monitoreo, como SCOM o Nagios o lo que sea que use, peinar ese registro de eventos y hacer explotar su teléfono celular con mensajes de texto o lo que sea. No se acelera más que eso.

¿Qué se podría hacer para mejorar la resistencia del sistema frente a un bloqueo de cuenta de DOS?

  1. Educación del usuario. Dígales que dejen de configurar los servicios de Windows para que se ejecuten bajo sus cuentas de usuario de dominio, que cierren sesión en las sesiones de RDP cuando hayan terminado, enséñeles cómo borrar la bóveda de credenciales de Windows de las contraseñas almacenadas en caché para Outlook, etc.
  2. Utilice las cuentas de servicio administrado donde pueda para que los usuarios ya no tengan que administrar contraseñas para esas cuentas de usuario. Los usuarios arruinan todo. Si le da una opción a un usuario, él o ella siempre tomará la decisión equivocada. Así que no les des otra opción.
  3. Aplicación de tiempos de espera de sesiones remotas a través de GPO. Si un usuario está inactivo en una sesión RDP durante 6 horas, retírelo.

1
+1 para "dar una opción a un usuario, él o ella siempre tomará la decisión equivocada"
Devon_C_Miller

Gracias por señalar Cuentas de servicio administrado . No podía recordar la descripción hace un par de días cuando buscaba una forma de omitir las cuentas de usuario que se ejecutan como servicios.
John aka hot2use

3

Tuvimos el mismo problema al limpiar las cuentas de administrador en un entorno más grande hace un tiempo. Aunque los registros de auditoría de DC proporcionan técnicamente la información necesaria, decidimos implementar el producto ADAudit Plus de ManageEngine, que escanea estos registros y busca intentos de inicio de sesión, junto con cualquier cambio en AD. Utilizando una función de informes incorporada y un poco de trabajo de Excel, pudimos rastrear (con bastante facilidad) de dónde provenían los inicios de sesión. En nuestro caso, se relacionó principalmente con los administradores que utilizaron cuentas de administrador en lugar de cuentas de servicio al implementar varias aplicaciones.


¿Algún comentario sobre la edición gratuita vs el profesional?
Bozojoe

3

¿Qué se podría hacer para mejorar la resistencia del sistema frente a un bloqueo de cuenta de DOS?

No puedes

Hay muchas cosas que pueden incendiar su casa. Como código simple para solicitar repetidamente direcciones IP hasta que se agote el alcance de DHCP. O código simple que crea directorios hasta que la MFT esté llena y tenga que formatear su partición para restaurarla. No puedes protegerte contra todo.

Un escenario más común con los bloqueos son las personas que ingresan sus credenciales en una variedad de dispositivos mucho más amplia de lo que era común hace solo unos años. Como impresoras (para escaneos por correo electrónico) o un teléfono inteligente o tableta. Si olvidan dónde ingresaron sus credenciales, o si ya no tienen acceso al dispositivo, es posible que el dispositivo continúe intentando la autenticación para siempre. La autenticación por correo electrónico es un vector difícil de rastrear estos dispositivos, e incluso si lo hace, el usuario puede no tener acceso a él o saber dónde está. IP 10.4.5.27? Sé de un usuario que tuvo que llamar a la mesa de ayuda todos los días para desbloquear su cuenta, luego iniciarían sesión de inmediato y luego su cuenta se bloquearía nuevamente. Lo hicieron durante meses. Les dije que cambiaran el nombre de su cuenta.

La vida tiene desincentivos, no podemos eliminarlos a todos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.