Cuando los equipos preguntan cuáles son las configuraciones incorrectas de seguridad de Active Directory más comunes, la respuesta útil no es una tabla de frecuencia. Es el conjunto de fallos de control que reaparecen en las guías de hardening de Microsoft, en las recomendaciones de ANSSI y en las revisiones recurrentes de AD porque siguen dejando rutas reales de escalada de privilegios, exposición de credenciales o pérdida de visibilidad.
Este artículo muestra la vista misconfigurations de Active Directory. No es una checklist completa como Auditar la seguridad de Active Directory: checklist práctica, y tampoco es una guía de orden de despliegue como Endurecimiento de Active Directory: qué bloquear primero y cómo validarlo. El objetivo es más acotado: identificar las configuraciones incorrectas de AD que siguen importando más, explicar por qué importan y mostrar qué validar antes y después de corregirlas.
¿Qué cuenta como una configuración incorrecta de seguridad de Active Directory?
Una configuración incorrecta de seguridad de Active Directory no es simplemente un ajuste distinto de un benchmark. En la práctica, es una debilidad de control que deja la autenticación, los privilegios, la replicación del directorio, la administración o la gestión de políticas más amplias de lo necesario para el entorno.
Por eso las mismas familias de problemas reaparecen una y otra vez: demasiadas cuentas privilegiadas, mala separación de rutas administrativas, derechos de replicación demasiado amplios, tráfico de directorio sin firma, secretos de administrador local reutilizables, cuentas de servicio con contraseñas estáticas, configuraciones de delegación inseguras y control de Group Policy demasiado permisivo. Son problemas de configuración, pero se convierten en problemas de rutas de ataque cuando permanecen en producción.
¿Cuáles son las configuraciones incorrectas de seguridad de Active Directory más comunes?
ℹ️ Nota: esta lista no es un ranking estadístico neutral del mercado. Es un Top 10 práctico de las familias de configuraciones incorrectas que reaparecen en la guía de Microsoft, ANSSI y en revisiones de AD, y que aún crean una exposición material en entornos reales.
| Configuración incorrecta | Exposición principal | Deep dive |
|---|---|---|
| Demasiadas cuentas privilegiadas | Deriva de privilegios y mayor blast radius | Endurecimiento de Active Directory |
| Sin separación de rutas administrativas | Robo de credenciales y reutilización de sesiones admin | Auditar la seguridad de Active Directory |
| Derechos de replicación demasiado amplios | Identidades DCSync-capable fuera del alcance previsto | Auditar la seguridad de Active Directory |
| LDAP signing no aplicado | Binds sin firma y controles de directorio más débiles | LDAP Signing Disabled |
| SMB signing no requerido | Exposición a NTLM relay y manipulación de tráfico | SMB signing deshabilitado |
| Windows LAPS no implementado | Reutilización de contraseñas de admin local | Windows LAPS no implementado |
| Controles de contraseña débiles | Credenciales predecibles o demasiado duraderas | Active Directory Password Security |
| Cuentas de servicio con contraseña estática | Secretos difíciles de rotar y mayor exposición | Active Directory Password Security |
| Delegación Kerberos insegura | Rutas de suplantación más amplias de lo necesario | Rutas de ataque AD |
| Permisos GPO peligrosos | Secuestro de políticas y control indirecto de sistemas privilegiados | GPO Misconfigurations |
1. Demasiadas cuentas privilegiadas y grupos sensibles
Esta es la familia de configuraciones incorrectas más básica en AD: demasiados usuarios, cuentas de servicio o cuentas de emergencia conservan membresía permanente en grupos muy sensibles o en derechos delegados equivalentes. Microsoft y ANSSI empujan aquí el mismo principio: minimizar el acceso privilegiado permanente y mantener explícito el alcance administrativo.
El riesgo es directo. Cada cuenta privilegiada adicional incrementa la exposición de credenciales, la superficie de inicio de sesión interactivo, el riesgo ligado a la delegación y el perímetro de recuperación cuando una identidad se compromete. En la práctica, el problema no suele ser una sola cuenta Domain Admin. Es la acumulación lenta de cuentas admin antiguas, cuentas de soporte, cuentas de emergencia que se volvieron permanentes y rutas de anidación que nadie depura.
Validar antes del cambio: inventario de grupos privilegiados, anidaciones, derechos delegados sobre activos Tier 0 y casos reales de uso administrativo. Retirar acceso sin revisar ownership y dependencia operativa crea interrupciones.
Pruebas que conservar después: exportación del inventario de grupos privilegiados, registros de eliminación de acceso y lista revisada de identidades que siguen necesitando privilegio permanente.
2. Falta de separación de rutas administrativas o de hosts administrativos seguros
Muchos entornos AD aún permiten que la misma identidad administre servidores, consulte correo, abra documentos e inicie sesión en estaciones de trabajo de menor confianza. La guía de Microsoft sobre secure administrative hosts existe porque el acceso privilegiado no depende solo de la membresía de grupo. También depende de dónde se exponen las credenciales administrativas.
Si los usuarios privilegiados administran desde endpoints de uso general, las credenciales y los tokens admin tienen más probabilidades de ser capturados, reutilizados o aprovechados en movimientos laterales. Por eso siguen siendo importantes estaciones administrativas dedicadas, cuentas separadas y una ruta administrativa limpia, incluso cuando la membresía de grupos sensibles ya parece razonable.
Validar antes del cambio: qué administradores ya usan cuentas separadas, qué sistemas se utilizan para administrar y qué flujos dependen aún de equipos de uso mixto. Muchas organizaciones descubren que la separación existe en el papel, pero no en el trabajo diario.
Pruebas que conservar después: inventario de hosts administrativos seguros o equivalentes, restricciones de inicio de sesión o asignación de hosts admin y evidencia de que la administración sensible ya no sale de equipos no gestionados o de uso general.
3. Derechos de replicación concedidos de forma demasiado amplia
DCSync no es solo una etiqueta ofensiva. Operativamente, es un problema de permisos: identidades que no necesitan derechos de replicación los tienen de todos modos. Microsoft Defender for Identity lo expone mediante la evaluación sobre cuentas no administrativas con permisos DCSync porque el impacto de fondo es muy alto.
Cuando Replicating Directory Changes, Replicating Directory Changes All u otros derechos relacionados se conceden demasiado ampliamente, una identidad puede solicitar datos de directorio extremadamente sensibles que deberían permanecer bajo un control estricto. La mentalidad correcta de remediación no es bloquear DCSync, sino reducir al conjunto mínimo previsto las identidades capaces de replicar.
Validar antes del cambio: revisar ACL sobre la raíz del dominio y otros objetos relevantes, identificar quién posee actualmente derechos de replicación y confirmar si cada titular es realmente necesario para backup, sincronización o tooling de seguridad.
Pruebas que conservar después: captura de revisión de ACL, lista final aprobada de identidades con capacidad de replicación y evidencia de que los principals eliminados ya no conservan esos derechos.
4. LDAP signing y channel binding mal aplicados
LDAP sin firma sigue siendo uno de los ejemplos más claros de un control AD antiguo pero todavía importante desde el punto de vista operativo. La guía de Microsoft sobre LDAP signing para AD DS existe porque los binds SASL sin firma y los simple binds pueden debilitar la integridad del tráfico de directorio, y las restricciones de compatibilidad suelen dejar despliegues a medio camino.
La configuración incorrecta rara vez es un único valor de registro. Más a menudo, es una aplicación incoherente entre controladores de dominio, aplicaciones que todavía dependen de comportamientos de bind más débiles o una validación incompleta de si los clientes se romperán cuando aumenten las exigencias.
Validar antes del cambio: inventario de clientes LDAP, identificación de uso de binds sin firma, confirmación de si LDAPS, signing o channel binding afectarán a aplicaciones heredadas, y despliegue gradual antes del enforcement.
Pruebas que conservar después: ajustes de política en los controladores de dominio, resultados de pruebas en aplicaciones críticas y telemetría que muestre que los clientes esperados usan un comportamiento conforme.
Para el mecanismo completo y los caveats de validación, consulte LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.
5. SMB signing no requerido donde todavía importa
SMB signing es otro control que los equipos conocen, pero aplazan por suposiciones de rendimiento, miedo a la compatibilidad o baselines heredadas en puestos y servidores. La guía de Microsoft se ha endurecido aquí porque SMB sin firma sigue dejando espacio para manipulación de tráfico y favorece condiciones de NTLM relay en entornos que no han reducido rutas de confianza heredadas.
La configuración incorrecta no es SMB existe. Es que la integridad no se exige donde debería exigirse, sobre todo en sistemas que todavía aceptan flujos de autenticación sensibles o que forman parte de rutas administrativas.
Validar antes del cambio: dispositivos heredados, sistemas embebidos, servidores antiguos o rutas de aplicación que todavía dependan de un comportamiento SMB más débil. Comprobar el estado real de la política en cliente y servidor en lugar de asumir que un lado la impone en todas partes.
Pruebas que conservar después: estado efectivo de la política de SMB signing, registro de excepciones para sistemas que aún no puedan cumplir y resultados de validación que demuestren que los sistemas sensibles ahora exigen firma.
Para la exposición de protocolo detallada, consulte SMB Signing Disabled: Why It Still Enables NTLM Relay.
6. Windows LAPS no implementado
Un gran número de entornos AD todavía protege mejor las credenciales de dominio que las contraseñas de administrador local. Eso deja intacto uno de los patrones de exposición Windows más antiguos: contraseñas de admin local estáticas o reutilizadas entre equipos y, en algunos entornos, una gestión débil de las contraseñas DSRM en controladores de dominio.
La guía de Microsoft sobre Windows LAPS importa porque esto no es solo higiene de estaciones de trabajo. Las contraseñas de admin local reutilizables apoyan el movimiento lateral, dificultan la contención tras una divulgación de contraseña y reducen el valor de otras medidas de hardening.
Validar antes del cambio: qué endpoints usan ya Windows LAPS, si LAPS heredado y Windows LAPS conviven, cómo se delega la lectura de contraseñas y si la gestión DSRM forma parte del alcance para controladores de dominio.
Pruebas que conservar después: estado del despliegue de la policy, cobertura de equipos gestionados, lectores autorizados y verificación muestral de que las contraseñas rotan y solo pueden recuperarse por roles aprobados.
Los detalles de despliegue y validación están cubiertos en Windows LAPS no implementado: por qué las contraseñas de administrador local compartidas siguen importando.
7. Políticas de contraseña débiles y excepciones para cuentas privilegiadas
Una política de contraseñas débil sigue siendo común, pero el problema operativo real es más amplio que un único ajuste a nivel de dominio. Normalmente incluye mínimos débiles, falta de fine-grained password policies dirigidas, contraseñas privilegiadas muy antiguas y excepciones que dejan silenciosamente cuentas críticas fuera de la baseline pretendida.
La guía de Microsoft sobre fine-grained password policies existe porque las cuentas de alto valor no siempre encajan en un solo modelo de policy. Al mismo tiempo, ANSSI insiste en que las cuentas privilegiadas y los usos administrativos requieren un tratamiento más estricto que los usuarios generales.
Validar antes del cambio: revisar la política efectiva por defecto del dominio, cualquier fine-grained password policy, cuentas privilegiadas con banderas de excepción, uso de Password never expires y cuentas de servicio que sigan tratándose como usuarios humanos.
Pruebas que conservar después: exportación de policy efectiva, asignación de usuarios o grupos con reglas reforzadas y artefactos de revisión para las excepciones restantes.
Para problemas adyacentes de credenciales, consulte Active Directory Password Security: Misconfigurations That Matter.
8. Cuentas de servicio heredadas con contraseñas estáticas en lugar de gMSA cuando sea posible
Las cuentas de servicio con contraseña estática siguen siendo comunes porque sobreviven a las migraciones, soportan aplicaciones antiguas y rara vez tienen ownership de extremo a extremo. Microsoft promueve gMSA porque reduce la carga operativa de la gestión de contraseñas para cargas compatibles, pero muchos entornos todavía mantienen cuentas de servicio privilegiadas o con SPN sobre contraseñas manuales y muy antiguas.
El riesgo no se limita a la antigüedad de la contraseña. Estas cuentas suelen estar sobreprivilegiadas, son difíciles de inventariar, quedan fuera de revisiones normales de ciclo de vida y son difíciles de rotar con seguridad. Cuando existen SPN, las credenciales de servicio de larga duración también aumentan el valor del cracking offline de tickets, por lo que este punto se solapa con la exposición tipo Kerberoasting.
Validar antes del cambio: inventario de cuentas de servicio, ownership, uso de SPN, nivel de privilegio, proceso de rotación y compatibilidad de aplicaciones con gMSA. No todo puede migrarse de inmediato, así que conviene priorizar primero las cuentas de mayor riesgo.
Pruebas que conservar después: inventario de cuentas de servicio, propietarios documentados, decisiones de migración para candidatos gMSA y evidencia de rotación o conversión para las cuentas que permanezcan con contraseñas estáticas.
9. Delegación Kerberos insegura
La delegación Kerberos se convierte en una configuración incorrecta cuando es más amplia de lo que el diseño del servicio realmente requiere. Microsoft Defender for Identity destaca la delegación insegura porque configuraciones demasiado abiertas amplían rutas de suplantación y cambian materialmente hasta dónde puede propagarse un compromiso.
Este es un buen ejemplo de por qué configuración incorrecta común no significa corrección simple. La delegación suele estar impulsada por requisitos de aplicación. Eliminarla o convertirla sin validar el comportamiento del servicio puede romper flujos de autenticación en producción.
Validar antes del cambio: inventario de delegación unconstrained, constrained y resource-based cuando exista, identificación de owners de aplicación y confirmación de qué sistemas siguen necesitando delegación.
Pruebas que conservar después: inventario revisado de delegación, configuraciones eliminadas o convertidas y evidencia de pruebas que demuestre que los flujos requeridos siguen funcionando después del endurecimiento.
Para el efecto de cadena más amplio, relacione este punto con Rutas de ataque AD: cómo se encadenan las malas configuraciones.
10. Permisos GPO peligrosos y control débil de cambios
Group Policy se convierte en una configuración incorrecta de seguridad cuando identidades de baja confianza o demasiado amplias pueden modificar GPO de alto impacto, vincular ajustes peligrosos o cambiar rutas de policy que afectan a sistemas privilegiados. Microsoft y ANSSI tratan la administración de GPO como un problema de control plane, no solo como gestión de escritorio.
El impacto va más allá de un valor de policy incorrecto. Permisos GPO peligrosos pueden permitir a un atacante o a un operador sobreprivilegiado impulsar ejecución de código, debilitar la seguridad del host, modificar grupos locales o alterar la postura de sistemas situados en rutas administrativas.
Validar antes del cambio: revisar quién puede editar, vincular o crear GPO, qué GPO se aplican a sistemas privilegiados y si el control de cambios distingue los GPO de alto impacto de los cambios rutinarios de escritorio.
Pruebas que conservar después: resultados de revisión de permisos GPO, listas restringidas de editores, registros de aprobación para policies de alto impacto y cobertura de monitorización de eventos de cambio de GPO.
Para el análisis directo de esta ruta, consulte GPO Misconfigurations: How Group Policy Becomes an Attack Vector.
⚠️ Si AD CS está desplegado: las debilidades de templates, enrollment y configuración de CA deben entrar en la misma revisión de primer nivel aunque no formen parte de este Top 10 principal. Use ADCS Attack Paths Explained como deep dive dedicado.
¿Por qué persisten estas configuraciones incorrectas?
Estos problemas persisten porque se sitúan en la intersección entre compatibilidad, ownership y excepciones acumuladas. El hardening de LDAP y SMB puede afectar aplicaciones antiguas. Las cuentas de servicio suelen sobrevivir a los equipos que las crearon. Las configuraciones de delegación se mantienen porque nadie quiere romper la autenticación. Los permisos GPO derivan porque la administración de policies está repartida entre varios equipos. Las cuentas privilegiadas siguen existiendo porque eliminarlas requiere evidencia operativa, no solo una opinión de seguridad.
Por eso una revisión anual no basta. Si solo comprueba estos controles una vez al año, la deriva de privilegios, de cuentas de servicio y de excepciones de policy puede volver más rápido de lo que el ciclo de revisión la detecta. Un proceso recurrente importa tanto como la primera limpieza. Consulte Auditoría recurrente de Active Directory: por qué los audits anuales derivan.
¿Cómo validarlas sin adivinar?
Una buena corrección no es solo un ajuste cambiado. Es un ajuste cambiado más una prueba de que el control realmente se aplica y de que los flujos requeridos siguen funcionando.
| Familia de control | Validar antes del enforcement | Pruebas que conservar después |
|---|---|---|
| Acceso privilegiado | Membresías, derechos delegados, workflows admin | Inventario revisado de privilegios y acceso permanente aprobado |
| Hardening LDAP y SMB | Compatibilidad cliente, sistemas heredados, pruebas escalonadas | Estado efectivo de policy y validación exitosa de aplicaciones |
| LAPS y contraseñas | Cobertura, lectores, excepciones, tipos de cuenta | Export de policy, cobertura gestionada, registro de excepciones |
| Cuentas de servicio y delegación | Owners, SPN, nivel de privilegio, dependencias | Inventario actualizado, decisiones de migración, pruebas de servicio |
| GPO y control plane | Listas de editores, alcance de enlaces, owners sensibles | Revisión de permisos, trazas de aprobación, monitorización |
Aquí es donde la visibilidad de logs y cambios importa. Si está modificando controles centrales de AD, también necesita saber si su policy de auditoría y su modelo de recopilación le permiten ver cambios de grupos, ACL de directorio, GPO y otros eventos críticos del control plane. Use Supervisión Seguridad AD: Event IDs y SIEM si su baseline de logs sigue siendo débil.
Cómo EtcSec ayuda a priorizar configuraciones incorrectas de AD
EtcSec resulta más útil aquí cuando el objetivo no es una checklist puntual, sino una vista repetible de qué configuraciones incorrectas de AD siguen creando la exposición más significativa. Findings como EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION y GPO_DANGEROUS_PERMISSIONS ayudan a convertir esta lista en una cola de remediación auditable.
La parte importante es la repetibilidad. Después de endurecer un control, necesita volver a medir si la exposición realmente ha desaparecido y si la deriva no la ha reintroducido después. Esa es la diferencia entre leer una guía de hardening una vez y mantener de verdad una postura de seguridad AD en el tiempo.
Referencias primarias
- Best practices for securing Active Directory
- Implementing Secure Administrative Hosts
- Privileged access strategy
- Security assessment: Remove non-admin accounts with DCSync permissions
- LDAP signing for Active Directory Domain Services
- Control SMB signing behavior
- Windows LAPS overview
- Group Managed Service Accounts overview
- Configure fine-grained password policies for AD DS
- Protected Users security group
- Authentication Policies and Authentication Policy Silos
- Security assessment: Unsecure Kerberos delegation
- Group Policy overview
- Configure Windows Event Forwarding
- Active Directory Certificate Services overview
- Guide ANSSI Active Directory
