Tiering de Active Directory: qué es el Tier 0 y cómo impide que un portátil comprometido llegue al dominio

Un administrador de dominio abre una sesión RDP en un portátil de usuario para resolver una incidencia. La desconecta sin cerrarla, y su credencial se queda en la memoria del equipo. Esa misma tarde el portátil recibe un phishing. A partir de ahí, el controlador de dominio cae en horas. El modelo de niveles de administración existe para que esa secuencia sea imposible. Microsoft lo documenta desde hace más de una década y la ANSSI francesa lo sitúa en el centro de su guía de Active Directory. Pocas organizaciones lo aplican completo.

Su versión actual es el Enterprise Access Model de Microsoft, y la regla es una sola: una credencial de alto privilegio no debe tocar jamás un sistema de menor confianza. Todo lo demás (los niveles, las estaciones dedicadas, los silos de autenticación) es la ingeniería necesaria para que esa regla se cumpla aunque alguien se equivoque.

¿Qué es el modelo de niveles y qué protege exactamente?

El modelo de niveles de AD DS separa identidades, estaciones de trabajo y activos administrados en tres niveles de confianza. El Tier 0 es el plano de control de la identidad: controladores de dominio, AD FS, AD CS, Microsoft Entra Connect y las cuentas y grupos que los administran. El Tier 1 agrupa los servidores miembro y las aplicaciones de empresa (Exchange, SharePoint, SQL Server, aplicaciones de negocio) con sus administradores. El Tier 2 son los equipos de usuario y las funciones que los soportan: el soporte a usuarios (help desk), la gestión de dispositivos y la de cuentas de usuario.

El principio que lo sostiene viene de los modelos de integridad clásicos: un sistema de menor confianza nunca debe poder influir sobre uno de mayor confianza. En términos de directorio, un administrador de dominio no inicia sesión en un servidor de aplicaciones ni en un portátil, porque en el momento en que teclea su contraseña en ese equipo la credencial queda expuesta a todo lo que ese equipo tenga dentro. Microsoft lo formula así: la confianza empieza en el primer teclado físico donde se inicia la sesión. Lo que fija el nivel es la credencial y el teclado, no la dirección IP.

Sobre esa base, el Enterprise Access Model amplía el alcance. El Tier 0 pasa a llamarse plano de control e incluye todos los sistemas de identidad y de control de acceso centralizado, también los de red cuando son la única opción, como en entornos industriales.

El antiguo Tier 1 se divide en un plano de gestión (herramientas de administración corporativa) y un plano de datos y cargas de trabajo (la administración de cada aplicación, que a veces hace TI y a veces el negocio). El Tier 2 se separa en acceso de usuarios y acceso de aplicaciones vía API, para cubrir la superficie que los modelos B2B, B2C y la automatización han añadido. Los principios se mantienen; el modelo sencillamente no termina en el perímetro del bosque de Active Directory.

¿Qué pertenece al Tier 0 y qué no debería estar ahí?

Es el punto donde más implantaciones fallan, por exceso y por omisión. Microsoft define el Tier 0 como todo activo o identidad que controla el servicio de directorio de forma directa o indirecta.

Eso cubre lo evidente (los controladores de dominio, Domain Admins, Enterprise Admins) y también lo que casi nadie clasifica bien: los grupos integrados Backup Operators y Server Operators, los servidores de federación y de certificados, el conector con Entra ID y los hipervisores donde corren los controladores. También cualquier sistema de copias, monitorización, parcheo o antivirus cuyo agente tenga control a nivel de sistema operativo sobre un controlador de dominio. Un servidor de salto (jump server) que se use para llegar a un controlador es Tier 0, esté en la red que esté.

SpecterOps mantiene una tabla pública de activos Tier Zero para Active Directory y Entra ID con un criterio de pertenencia útil: un activo es Tier Zero si existe una técnica de abuso pública que permita tomar el control del plano de identidad a partir de él. La tabla anota para cada activo si el riesgo aparece con la configuración por defecto o solo con una habitual pero no predeterminada, y si Microsoft lo incluye en su lista de roles privilegiados.

En Hard2bit la usamos como referencia cuando un cliente nos pide clasificar su directorio, porque convierte una cuestión de opiniones en una lista de técnicas documentadas.

El error contrario también es frecuente: meter en el Tier 0 todo lo que parece importante. Un ERP crítico para el negocio no es Tier 0 aunque lo administre un administrador de dominio; pertenece al plano de cargas de trabajo. Cada servidor o aplicación que no controla la identidad y aun así se mete en el Tier 0 amplía la superficie de ataque del plano de control y diluye los controles.

¿Por qué tantas organizaciones no lo aplican?

La objeción tiene fundamento. El modelo obliga a cada administrador a usar varias cuentas y, en el Tier 0, a trabajar desde una estación de administración dedicada sin correo ni navegación general. Obliga a la organización a revisar cada agente de copias, monitorización o EDR que hoy corre con privilegios de dominio en cientos de servidores, y a desdoblar cuentas de servicio que llevan años funcionando en varios niveles a la vez. En una organización con un directorio que ha crecido durante veinte años, ese inventario saca a la luz dependencias que nadie recordaba, y el equipo de sistemas lo siente como fricción diaria durante meses.

A eso se suma una creencia extendida: que el MFA, el EDR y la segmentación de red ya cubren el riesgo. Cubren una parte del riesgo. El MFA protege el inicio de sesión y deja intacta la credencial que queda en memoria después; el EDR detecta comportamiento en el equipo donde está instalado, y el protocolo no distingue la reutilización de un hash robado contra un controlador de dominio de una autenticación legítima; y la segmentación de red limita rutas, pero un administrador que entra por RDP desde un portátil de usuario acaba de atravesar el cortafuegos con su propia contraseña.

Lo que dicen los datos de los ataques

El informe conjunto de la NSA, la ASD australiana, CISA y sus socios, publicado en septiembre de 2024, recoge las diecisiete técnicas más usadas para comprometer Active Directory, AD FS y AD CS.

Van desde el robo y la falsificación de tickets Kerberos (Kerberoasting, AS-REP Roasting, Golden Ticket, Silver Ticket) hasta el abuso de AD CS y el Golden Certificate. En medio quedan DCSync, el volcado de ntds.dit, Golden SAML y el compromiso de Entra Connect; la delegación sin restricciones, las contraseñas en preferencias de directiva de grupo y la cuota de cuentas de equipo; y SID History, la elusión de confianzas, Skeleton Key y la pulverización de contraseñas (password spraying).

Salvo la pulverización de contraseñas y el AS-REP Roasting, que no requieren credencial previa (solo alcance de red, una lista de usuarios y, en el segundo caso, cuentas sin preautenticación Kerberos), todas exigen una credencial del dominio o una posición con privilegios.

Hay que separar dos grupos. Las que dependen de una credencial de Tier 0 robada (DCSync, el volcado de ntds.dit, Golden Ticket, Golden SAML, Golden Certificate, Skeleton Key) son las que el modelo cierra: si ninguna credencial de Tier 0 se usa fuera del Tier 0, un portátil comprometido no contiene nada con lo que ejecutar un DCSync ni falsificar un Golden Ticket.

Las demás (Kerberoasting, las plantillas mal configuradas de AD CS, las contraseñas en GPP, la cuota de cuentas de equipo, la delegación sin restricciones) escalan desde cualquier usuario del dominio explotando configuraciones, no credenciales expuestas, y el modelo por sí solo no las cierra. Por eso el análisis de rutas de ataque forma parte del modelo y no es un añadido. El informe subraya que quien controla el directorio puede sortear el MFA y establecer persistencia modificando la información de AD; el modelo busca que el atacante nunca llegue a ese punto.

La agencia francesa ANSSI llegó a la misma conclusión desde la respuesta a incidentes. Su guía de administración segura de sistemas basados en Active Directory, publicada en octubre de 2023 (166 páginas, 89 recomendaciones), parte de una constatación que la agencia dice hacer con regularidad: hay compromisos de sistemas basados en AD que resultan de malas prácticas de administración y de una compartimentación insuficiente.

La compartimentación en niveles es su medida central de arquitectura, con un capítulo dedicado a por qué NTLM y ciertos usos de Kerberos anulan la separación aunque los niveles existan sobre el papel. Por eso retirar NTLM y aislar el Tier 0 son dos partes del mismo trabajo.

Sobre la fricción operativa, la documentación de Microsoft distingue dos trabajos. Desplegar la estructura del modelo (unidades organizativas, grupos y directivas) suele ser rápido y puede hacerse en minutos con los scripts publicados; lo que lleva mucho más tiempo es la alineación organizativa, los roles y los procesos, y ahí entra la migración de agentes y cuentas de servicio descrita más arriba.

¿Qué controles y evidencias demuestran que el modelo existe?

Estos son los controles que separan una implantación real de una que solo existe sobre el papel; junto a cada uno, la evidencia que deja.

Inventario y clasificación del Tier 0

Antes de mover nada, la organización necesita una lista escrita de sus activos Tier 0 con el motivo de cada uno. La tabla de SpecterOps y un análisis de rutas de ataque con BloodHound o herramientas similares sirven para encontrar lo que no está en la lista: la cuenta de servicio del sistema de copias con derechos de replicación, el grupo anidado que termina en Administrators de un controlador, el servidor de gestión de hipervisores administrado con una cuenta de Tier 1. La evidencia es la lista misma, revisada y fechada, y el número de rutas de ataque hacia el Tier 0 que quedan abiertas después de cada revisión.

Cuentas separadas por nivel y estaciones de administración dedicadas

Cada administrador tiene una cuenta por nivel que administra. Las tareas de Tier 0 se hacen desde una estación de acceso privilegiado (PAW, Privileged Access Workstation), un equipo endurecido y dedicado, sin correo, sin navegación general y sin software no gestionado.

Desde esa estación se puede llegar al controlador directamente, a través de un servidor de salto que también sea Tier 0 o mediante un gestor de cuentas privilegiadas (PAM) con acceso bajo demanda (just-in-time), siempre que la sesión nazca en la propia estación. La evidencia es el inventario de cuentas por nivel y el registro de inicios de sesión de las cuentas Tier 0, donde los equipos Tier 0 deberían ser el único origen.

Silos de autenticación y el grupo Protected Users

Windows Server incorpora desde 2012 R2 dos mecanismos para que la separación se imponga en el controlador de dominio y no dependa de la disciplina de cada administrador. Las directivas y silos de autenticación agrupan las cuentas de Tier 0 en un contenedor y condicionan la emisión de sus tickets Kerberos a que la petición venga de un equipo del silo; si viene de otro, el controlador la rechaza.

Exigen dos cosas que a menudo se olvidan: el blindaje Kerberos (FAST) activado por directiva en controladores y clientes, y pasar la directiva de modo auditoría a modo aplicación. Y no afectan a NTLM, motivo por el que se despliegan junto con el grupo siguiente.

El grupo Protected Users añade restricciones a sus miembros, entre ellas la prohibición de autenticarse con NTLM, justo el mecanismo que un atacante con un hash robado necesita para reutilizarlo.

La ANSSI incluye en su guía el despliegue de un silo de Tier 0 por PowerShell como anexo técnico. La prueba es la pertenencia al silo y al grupo, y los eventos 4820 a 4823 de los controladores (ticket Kerberos o autenticación NTLM denegados por directiva o por Protected Users), que en un entorno sano deberían tender a cero, con cada uno explicado.

Cuentas locales, agentes y cuentas de servicio

Hay tres frentes en los que el diseño del modelo no basta por sí solo y hace falta una medida concreta. Las contraseñas de administrador local idénticas en todo el parque convierten un equipo comprometido en todos los equipos; Windows LAPS las gestiona y rota por equipo.

Los agentes que corren con derechos de dominio en servidores de Tier 1 crean una ruta de exposición hacia el plano de control desde cada uno de esos servidores; el modelo exige que cada herramienta opere dentro de un solo nivel. Y las cuentas de servicio compartidas entre niveles anulan la frontera: una cuenta que corre en un controlador y en un servidor de aplicaciones convierte ese servidor en un punto de exposición del Tier 0. La disciplina que describimos para las identidades no humanas se aplica aquí al directorio.

Detección de violaciones del modelo

La separación también hay que vigilarla después de diseñarla. La señal más útil es sencilla de describir: una cuenta clasificada como Tier 0 iniciando sesión, de forma interactiva o por RDP, en un equipo que no está clasificado como Tier 0. En el equipo de destino se ve en los eventos de inicio de sesión (4624) de tipo interactivo, remoto o servicio, que son los que dejan credencial reutilizable. En los controladores, y de forma más escalable, se ve en las solicitudes de ticket (4768 y 4769) y en las autenticaciones NTLM (4776) cruzadas con la lista de equipos Tier 0, además de los rechazos del silo.

Cualquier SIEM puede ejecutar esa regla de correlación si recibe los registros adecuados, y es una de las alertas de identidad con menos falsos positivos siempre que el inventario esté bien hecho. Las técnicas del informe conjunto tienen además sus detecciones específicas, que tratamos en otro artículo sobre la detección de Kerberoasting, abuso de AD CS y Golden Ticket.

El coste de no hacerlo

Sin separación de niveles, la secuencia con la que abre este artículo se completa en horas y sus etapas coinciden con las técnicas del informe conjunto: una credencial recogida en un portátil, un salto a un servidor, otra credencial mejor y, al final, acceso privilegiado a todos los sistemas del directorio, desde donde se despliega el ransomware. Cada uno de esos saltos es un movimiento lateral que necesita una credencial, y el modelo habría mantenido la última, la de Tier 0, fuera de cualquier equipo que no fuera Tier 0.

Hay también una dimensión de cumplimiento. NIS2 exige en su artículo 21 políticas de control de acceso como parte de las medidas mínimas. El ENS dedica su familia de medidas de acceso (op.acc) a la identificación, la segregación de funciones y la gestión de derechos de acceso. DORA pide a las entidades financieras políticas de gestión de accesos que cubran también los privilegiados. Ninguna de esas normas cita el modelo de niveles por su nombre, pero una auditoría que pregunte cuántas personas tienen derechos de administrador de dominio y desde qué equipos los ejercen está preguntando, con otras palabras, si el Tier 0 existe.

La decisión es de dirección

Separar niveles es una decisión de dirección que llega a la mesa como si fuera un proyecto técnico. Microsoft cita como objetivo habitual menos de cinco personas con derechos equivalentes a Domain Admins y ninguna cuenta de servicio en ese grupo.

Hay que reducir el grupo a esa cifra, quitar los derechos de dominio a los agentes que los tienen por comodidad y obligar a los administradores a trabajar desde estaciones dedicadas. Son decisiones que alguien con autoridad tiene que tomar y sostener cuando el equipo de sistemas proteste, que lo hará durante meses. Lo que se compra con eso es una respuesta verificable: un portátil comprometido esta noche no contiene ninguna credencial que valga para controlar el directorio.

En Hard2bit trabajamos ese recorrido desde la revisión de identidades y accesos hasta la búsqueda de amenazas que rastrea las rutas que quedan abiertas, y empezamos siempre por la misma lista: quién tiene el Tier 0 y por qué.

Este artículo describe una arquitectura de administración y controles de configuración con fines de defensa, a partir de la documentación pública de Microsoft, SpecterOps, la ANSSI y el informe conjunto de la NSA, la ASD y CISA disponible a 14 de septiembre de 2026. Las referencias normativas a NIS2, ENS y DORA son orientativas y no sustituyen el análisis jurídico de cada organización. Cada control debe probarse en un entorno controlado antes de aplicarlo en producción, y la clasificación de activos Tier 0 debe validarse contra el directorio concreto de cada organización.