Active Directory Tiered Admin Model: guía completa (de ESAE a RAMP)

Qué es el Active Directory Tiered Admin Model

El Active Directory Tiered Admin Model es la arquitectura de seguridad que impide que un atacante que ha comprometido un portátil del help desk llegue directo a Domain Admin. Divide cada identidad, estación de trabajo y servidor en niveles de confianza — Tier 0 (el propio plano de control de identidad), Tier 1 (servidores y aplicaciones de negocio) y Tier 2 (estaciones de trabajo de usuario final y cuentas estándar) — y aplica una regla en ambas direcciones: las credenciales de un tier superior nunca deben exponerse a un tier inferior, y las credenciales de un tier inferior nunca deben poder controlar un tier superior (Microsoft Learn, AD DS Tier Model).

La mayoría de los entornos que dicen tener un modelo por tiers no lo aplican realmente. Los Domain Admins hacen RDP a servidores miembro para "comprobar algo rápido". Una GPO del service desk de Tier 1 se vincula una OU más arriba de lo debido y termina en la OU de los controladores de dominio. Una cuenta break-glass queda fuera de Protected Users porque nadie se acordó de añadirla. Cada uno de estos casos es pequeño por separado; juntos, derrumban el límite entre tiers que el modelo existe para proteger — exactamente el tipo de deriva de acceso privilegiado que vuelve a colarse tras un endurecimiento a menos que algo lo siga revisando.

Equivocarse en ese límite sale caro, porque un compromiso de Tier 0 no es un incidente localizado — es total. Un atacante que consigue una credencial de Tier 0 (mediante un logon cross-tier, una GPO mal delimitada o una cuenta olvidada fuera de Protected Users) normalmente puede hacer DCSync de todo el directorio y forjar tickets Kerberos para cualquier identidad del dominio. El modelo por tiers existe precisamente para contener ese resultado a una brecha de Tier 0, en lugar de dejar que una simple estación de helpdesk comprometida escale hasta ahí.

ℹ️

ℹ️ Nota: el modelo ha pasado por un cambio de nombre que conviene conocer antes de leer guías más antiguas. El patrón original de bosque de administración reforzado — el Enhanced Security Admin Environment (ESAE), también llamado "red forest" — es ahora una recomendación de Microsoft retirada, reservada para casos de excepción concretos. Microsoft lo sustituyó por el Rapid Modernization Plan (RAMP) y el Enterprise Access Model más amplio, que mantienen la misma lógica de tiers pero parten de que la mayoría de las organizaciones no deberían levantar un segundo bosque completo solo para conseguirlo (Microsoft Learn, ESAE retirement). Si en 2026 un proveedor o consultor te sigue proponiendo montar un red forest, pregunta por qué — RAMP da el mismo aislamiento de Tier 0 con mucha menos carga operativa.

De las OU a la aplicación real: cómo funciona el tiering en la práctica

El tiering no es un diagrama — es una estructura de OU, un conjunto de GPO con un alcance bien definido, y un límite estricto sobre dónde pueden iniciar sesión interactiva las cuentas privilegiadas.

Estructura de OU

Los activos de Tier 0 (controladores de dominio, AD FS, servidores PKI/ADCS, infraestructura de backup capaz de restaurar un DC, y las cuentas/grupos que los administran) viven en un árbol de OU de Tier 0 dedicado, separado de los servidores de Tier 1 y las estaciones de Tier 2. La delegación y los vínculos de GPO siguen el mismo límite — una GPO de endurecimiento de estaciones de Tier 2 nunca debe vincularse cerca de la OU de Tier 0, y viceversa (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).

Privileged Access Workstations (PAW)

Las cuentas admin de Tier 0 solo deberían poder iniciar sesión interactiva en un conjunto pequeño y dedicado de dispositivos Tier 0 — PAW vinculadas a su propia OU, con GPO de endurecimiento (sin navegación por internet, sin correo, allow-listing de aplicaciones) restringidas exclusivamente a esa OU (Microsoft Learn, PAW legacy guidance). Esta es la aplicación práctica de la Regla n.º 1: si una credencial de Tier 0 puede autenticarse en un dispositivo de Tier 1 o Tier 2, el límite ya está roto, sin importar lo que diga el organigrama o el diagrama del wiki.

Disciplina en el alcance de las GPO

Vincula las GPO de endurecimiento de seguridad solo en la OU correspondiente a su tier — nunca en la raíz del dominio, nunca en la Default Domain Policy. Vincular una GPO cruzando OU de distintos tiers es una de las formas más habituales en que el límite entre tiers se erosiona silenciosamente durante meses, porque nadie nota la adición de un vínculo como notaría una cuenta admin nueva.

💡

💡 Consejo: Microsoft ofrece ahora una implementación de referencia oficial para esto — el repositorio de GitHub microsoft/ActiveDirectoryTierModel, con scripts de despliegue para la estructura de OU de Tier 0/1/2 y un script Audit-TierModel.ps1 que compara tu estructura actual de OU y GPO con el modelo de referencia. Es una forma rápida de ver dónde se ha desviado tu entorno del diseño de referencia antes de empezar una remediación manual.

Detección: identificar violaciones de tier antes de que se exploten

Una violación de tier no es un evento aislado — es un patrón en el que una identidad privilegiada o un vínculo de GPO aparece donde no debería. Construye tus detecciones en torno a estas señales:

Indicador	Event ID / Fuente	Qué detecta
Una cuenta de Tier 0 inicia sesión interactiva fuera de una PAW	4624 (logon type 2/10) + 4672 correlacionados por Logon ID	Exposición de credencial cross-tier — un Domain Admin autenticándose en una estación estándar
Privilegios especiales asignados en un host que no es Tier 0	4672 en activos de Tier 1/2	Token privilegiado emitido donde no debería — se combina con 4624 como regla de alta fiabilidad y bajo ruido
Cierre de sesión de un logon cross-tier	4634 / 4647	Confirma la duración y el alcance de la sesión una vez señalada la violación
Vínculo de GPO añadido o modificado fuera del alcance esperado	5136 (objeto del servicio de directorio modificado) en el atributo `gPLink`	Una GPO de endurecimiento o de derechos de logon fue reencuadrada silenciosamente cruzando un límite de tier
Domain Admin / Enterprise Admin ausente de Protected Users	Consulta LDAP sobre cuentas `adminCount=1` frente a la pertenencia a Protected Users	Cuentas que se saltan las protecciones de NTLM/DES/delegación y caché de credenciales que aplica el grupo
Cuentas privilegiadas fuera de una OU de admin dedicada	Consulta LDAP: `distinguishedName` de cuentas `adminCount=1` frente a la OU de admin de Tier 0	Cuentas admin creadas o movidas fuera del límite de OU del que depende todo el modelo

Por qué el Event ID 4672 es la señal de alta fiabilidad

El Event ID 4672 ("privilegios especiales asignados a un nuevo logon") se dispara inmediatamente después de un 4624 exitoso para cualquier cuenta con derechos equivalentes a admin, y su Logon ID es la clave de unión en todo el ciclo de vida de la sesión — 4624 → 4672 → actividad → 4634/4647 (Microsoft Learn, Event 4672). En una estación donde un Domain Admin nunca debería iniciar sesión interactiva, un único 4672 para esa cuenta es una alerta de alta fiabilidad y bajo esfuerzo — no hace falta herramientas de UEBA para atrapar el caso obvio, solo la regla de correlación correcta en el alcance de OU correcto.

⚠️

⚠️ Advertencia: no construyas esta detección solo sobre los controladores de dominio. Las violaciones de tier aparecen con más frecuencia en servidores miembro de Tier 1 o estaciones de Tier 2, donde un admin hizo RDP "solo esta vez". Si tu monitorización de logons solo vigila los DC, te perderás justo el comportamiento que el modelo por tiers está diseñado para prevenir.

Remediación: construir tiers que aguanten

💡

💡 Acción rápida: ejecuta Audit-TierModel.ps1 del repositorio ActiveDirectoryTierModel de Microsoft (o una consulta LDAP equivalente sobre cuentas adminCount=1 y su OU/DN) para obtener una línea base de todas las cuentas privilegiadas y vínculos de GPO que hoy están fuera del límite de tier previsto — antes de cambiar nada.

Mueve las cuentas privilegiadas a una OU de admin de Tier 0 dedicada. Este es el control que ANSSI señala directamente — las cuentas con adminCount=1 que viven fuera de una OU dedicada y estrictamente delegada rompen la segmentación de la que depende el resto del modelo (ANSSI-PA-099, "Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory", oct. 2023).
Añade todas las cuentas de Tier 0 a Protected Users. Esto bloquea la autenticación NTLM, el cifrado Kerberos DES/RC4, la delegación unconstrained/constrained y los TGT de larga duración para esas cuentas — cerrando varias de las rutas de robo de credenciales que abren los huecos de delegación.
Aplica una Fine-Grained Password Policy a los grupos de Tier 0. Los Domain y Enterprise Admins no deberían heredar la política de contraseñas por defecto del dominio; una PSO dedicada, con requisitos de longitud y rotación más estrictos, limita el radio de impacto si aun así se expone una credencial de Tier 0.
Restringe cada GPO estrictamente a su OU de tier. Audita los vínculos de GPO existentes en busca de cualquiera que toque tanto una OU de Tier 0 como una de Tier 1/2, y sepáralos. Nunca añadas configuraciones de aplicación de tiering a la Default Domain Policy — crea GPO dedicadas y vincúlalas solo a la OU de tier correspondiente.
Despliega PAW para el logon interactivo de Tier 0, y luego aplícalo técnicamente. Usa GPO de derechos de logon (Deny log on locally / Deny log on through Remote Desktop Services) en activos de Tier 1/2 para cuentas de Tier 0, no solo como documentación de política — una regla escrita que nadie puede violar técnicamente no sobrevive a un incidente.
Rehaz la línea base trimestralmente, no una sola vez. Los límites entre tiers se desvían con el trabajo admin rutinario — un nuevo admin de servidor añadido al grupo equivocado, una GPO revinculada durante una migración, o cuentas privilegiadas obsoletas que nadie dio de baja desde Tier 0. Un proyecto de tiering puntual sin auditoría recurrente degenera de vuelta a administración plana en menos de un año; consulta la guía más amplia de prioridades de endurecimiento para ver cómo encaja esto en una secuencia más amplia de endurecimiento de AD, y las recomendaciones de ANSSI en la práctica para la checklist completa orientada a cumplimiento de la que forma parte este modelo.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec comprueba las violaciones del modelo por tiers directamente contra tu directorio en vivo: ANSSI_R15_TIER_MODEL_VIOLATION señala cuentas privilegiadas fuera de una OU de admin dedicada, ANSSI_R40_NO_PSO_TIER0 señala grupos de Tier 0 sin una Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION comprueba la segregación de confianza del bosque de administración cuando se usa uno, NOT_IN_PROTECTED_USERS señala cuentas privilegiadas ausentes del grupo Protected Users, y EXCESSIVE_PRIVILEGED_ACCOUNTS señala límites de tier que han crecido demasiado para auditarse manualmente.

ℹ️

ℹ️ Nota: EtcSec comprueba automáticamente estos huecos del modelo por tiers en cada auditoría de Active Directory. Ejecuta una auditoría gratuita para ver dónde se ha desviado tu entorno actual del modelo de admin por tiers que se supone que sigue.