Pregunta:
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 dentro de la DMZ (relé SMTP, VPN, Citrix, etc.) y varios internos 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 comprobarlos individualmente.
Ahora suponga que, por alguna razón desconocida, una (o más) cuentas de usuario se bloquean 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 Windows estándar puro, sin herramientas de administración adicionales y con pocos cambios con respecto a los valores predeterminados, ¿existe alguna forma de que el proceso de búsqueda de la causa de dicho bloqueo pueda acelerarse o mejorarse?
- ¿Qué se podría hacer para mejorar la resistencia del sistema contra tal bloqueo de cuenta DOS? Deshabilitar el bloqueo de cuenta es una respuesta obvia, pero luego se encuentra con el problema de que los usuarios tienen forma de contraseñas fácilmente explotables, incluso con la complejidad impuesta.
Respuesta:
Añadiendo 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 con respecto a los bloqueos de cuentas para todo el dominio, no tiene la información sobre qué cliente (IP o hostname) de donde provienen los intentos fallidos de inicio de sesión, asumiendo 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 ocurrieron en otro DC del 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 los RODC en esta discusión).
Hay dos buenas formas 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 me encantan las herramientas de bloqueo de cuentas de Microsoft, así que ahora hay una buena manera.
Reenvío de eventos. Te va a encantar.
Suponiendo que la infraestructura es Windows estándar puro, sin herramientas de administración adicionales y con pocos cambios con respecto a los valores predeterminados, ¿existe alguna forma de que el proceso de búsqueda de la causa de dicho bloqueo pueda acelerarse o mejorarse?
Véase más arriba. Luego puede hacer que su sistema de monitoreo, como SCOM o Nagios o lo que sea que use, peine ese registro de eventos único y explote 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 contra tal bloqueo de cuenta DOS?
- Educación del usuario. Dígales que dejen de configurar los servicios de Windows para que se ejecuten en sus cuentas de usuario de dominio, cierre la sesión de RDP cuando hayan terminado, enséñeles cómo borrar las contraseñas almacenadas en caché de Windows Credential Vault para Outlook, etc.
- Utilice las cuentas de servicio administradas donde pueda para que los usuarios ya no tengan que administrar las contraseñas de esas cuentas de usuario. Los usuarios ensucian todo. Si le da una opción a un usuario, él o ella siempre tomará la decisión incorrecta. Así que no les des a elegir.
- Hacer cumplir los tiempos de espera de las sesiones remotas a través de GPO. Si un usuario está inactivo en una sesión RDP durante 6 horas, inícielo.