Red Forest (ESAE) o modelo de acceso empresarial en 2026

Durante años, la respuesta a «cómo protegemos a los Domain Admins» en los entornos exigentes fue ESAE, el Enhanced Security Admin Environment, más conocido como Red Forest: un bosque administrativo independiente y endurecido cuyas cuentas tenían privilegios en producción a través de una confianza unidireccional, de modo que las credenciales de Tier 0 nunca tocaban una estación de trabajo de producción. Funcionaba contra los ataques de su época, pero era caro, lento de construir y no hacía nada por las identidades, que cada vez vivían más en la nube. Microsoft lo retiró como recomendación predeterminada y publicó en su lugar el modelo de acceso empresarial.

Esta guía es una guía de decisión de diseño, no un tutorial de configuración. Explica frente a qué protegía ESAE, por qué se retiró, qué le pide construir el modelo de acceso empresarial en un entorno centrado en AD en 2026 y los casos concretos en los que un bosque bastión con una confianza PAM sigue siendo la decisión correcta. Se apoya en el pilar sobre confianzas y límites de bosque y en el pilar sobre Tier 0.

Qué hacía realmente ESAE

ESAE combinaba varios controles en una sola arquitectura:

• Un bosque administrativo independiente con sus propios DC, endurecido más allá de las líneas de base de producción, sin acceso a Internet y con el mínimo software.
• Una confianza unidireccional: producción confía en el bosque administrativo; el bosque administrativo no confía en producción. Las cuentas de administración residen únicamente en el bosque administrativo y reciben derechos en producción mediante la pertenencia a grupos.
• Estaciones de trabajo de acceso privilegiado unidas al bosque administrativo y utilizadas solo para administrar.
• Autenticación selectiva y restricciones de inicio de sesión para que las cuentas del bosque administrativo solo pudieran autenticarse en sistemas de producción concretos.

Su valor era el aislamiento: comprometer una estación de trabajo o un servidor de producción no permitía obtener credenciales del bosque administrativo, porque esas credenciales nunca se exponían allí, y los administradores de producción no podían llegar al bosque administrativo.

Por qué Microsoft lo retiró como opción predeterminada

El razonamiento de Microsoft, publicado junto con su estrategia de acceso privilegiado, se reducía a cuatro puntos:

1. Coste y complejidad. Un segundo bosque con sus propios DC, PKI, aplicación de parches, supervisión, copias de seguridad y recuperación. Muchas implementaciones se quedaron a medias y dejaron un Red Forest parcial que añadía superficie de ataque sin aportar el aislamiento.
2. No arreglaba producción. Los atacantes escalaban habitualmente por rutas que ESAE no cubría: ACL mal configuradas, plantillas de AD CS, cuentas de servicio, servidores de copia de seguridad, hipervisores y agentes de administración con SYSTEM en los DC. El bosque administrativo no detenía a un atacante que llegaba a Tier 0 a través de esos activos.
3. La identidad en la nube. Cuando Entra ID, Entra Connect y los roles de administración en la nube controlan el correo, los archivos y la administración de dispositivos, un plano de control que solo existe en el entorno local protege la mitad del reino.
4. Los mismos beneficios se obtienen con menos. PAW limpias, niveles estrictos, directivas de autenticación y elevación just-in-time proporcionan la mayor parte del aislamiento de credenciales sin un segundo bosque.

ESAE no se declaró inseguro. Se declaró que era la primera inversión equivocada para la mayoría de las organizaciones.

El modelo de acceso empresarial en términos de AD

El modelo replantea los niveles como planos y añade las rutas que siguen los usuarios y las aplicaciones:

También define el acceso privilegiado como una ruta: cuentas, dispositivos, intermediarios (servidores de salto, VPN, PIM) e interfaces. Cada elemento de esa ruta necesita un nivel de seguridad al menos tan alto como el del recurso al que llega. Microsoft define tres niveles: empresarial, especializado y privilegiado.

En un entorno de AD, construir el modelo significa cosas concretas que se pueden comprobar.

Cuentas privilegiadas

Cuentas de administración separadas por plano, miembros de Protected Users, sin buzón y sin acceso a Internet. La pertenencia permanente a Domain Admins y Enterprise Admins debería ser prácticamente nula, con cuentas de emergencia (break-glass) supervisadas.

"Domain Admins","Enterprise Admins","Schema Admins","Administrators" | ForEach-Object {
    [pscustomobject]@{
        Group   = $_
        Members = (Get-ADGroupMember $_ -Recursive | Measure-Object).Count
    }
}
Get-ADGroupMember "Protected Users" | Select-Object Name

Dispositivos privilegiados

Estaciones de trabajo de acceso privilegiado para el trabajo en el plano de control, administradas a su vez desde el plano de control, con listas de aplicaciones permitidas y sin navegación ni correo electrónico. Una PAW administrada por un servidor SCCM de Tier 1 no es una PAW de Tier 0.

Intermediarios e interfaces

Un servidor de salto es tan fiable como quien lo administra. Si los administradores de Tier 0 usan un host de salto RDS, ese host es Tier 0. Siempre que sea posible, prefiera Remote Credential Guard o el modo Restricted Admin para RDP, de modo que no queden credenciales reutilizables en el intermediario.

Aplicación en AD

Los niveles deben aplicarse técnicamente, no solo documentarse. Eso significa asignaciones de derechos de usuario Deny log on por nivel y, de forma más robusta, directivas y silos de autenticación, que restringen dónde pueden obtener tickets Kerberos las cuentas de Tier 0 y acortan la duración de su TGT.

# Cobertura de silos para las cuentas de Tier 0
Get-ADAuthenticationPolicySilo -Filter * | Select-Object Name, Enforce
Get-ADUser -Filter 'adminCount -eq 1' -Properties msDS-AssignedAuthNPolicySilo |
  Select-Object SamAccountName, @{n='Silo';e={$_.'msDS-AssignedAuthNPolicySilo'}}

Plano de control en la nube

Los Global Administrators y Privileged Role Administrators de Entra ID y el servidor de Entra Connect pertenecen al mismo plano de control que Domain Admins. Use cuentas de administración solo en la nube, PIM para la activación just-in-time y MFA resistente al phishing. Nunca sincronice cuentas de administración locales con roles privilegiados en la nube, y nunca permita que una cuenta de administración en la nube se controle desde el entorno local.

Cuándo sigue teniendo sentido un bosque bastión o una confianza PAM

Microsoft Identity Manager 2016 introdujo una forma más ligera del bosque administrativo: un bosque bastión conectado a producción mediante una confianza PAM, con entidades de seguridad de sombra (objetos msDS-ShadowPrincipal en el bosque bastión que contienen los SID de los grupos de producción) y pertenencia a grupos limitada en el tiempo. El bosque bastión requiere el nivel funcional de bosque Windows Server 2016 y la característica opcional Privileged Access Management, que no se puede deshabilitar una vez habilitada.

# Compruébelo, no lo habilite a la ligera: esta característica es irreversible
Get-ADOptionalFeature -Filter 'Name -like "Privileged*"' | Select-Object Name, EnabledScopes

# Con la característica habilitada, la pertenencia puede caducar automáticamente
Add-ADGroupMember -Identity "Tier0-Operators" -Members "adm-jdoe" -MemberTimeToLive (New-TimeSpan -Hours 2)

Plantéese un bosque bastión cuando:

• El entorno está desconectado: redes OT, clasificadas o aisladas en las que un plano de control en la nube con PIM no es una opción.
• Un gran entorno multibosque necesita pertenencia privilegiada limitada en el tiempo en varios bosques desde un único origen administrativo, y la consolidación no es realista.
• Un regulador exige un directorio administrativo separado física y lógicamente.
• Una migración larga necesita mantener aislado Tier 0 mientras producción está demasiado comprometida o desordenada como para confiar en ella.

En todos los casos, el bosque bastión se convierte en la nueva cúspide de su plano de control: necesita su propio plan de recuperación del bosque, su propia supervisión y la misma disciplina de PAW. MIM no recibe nuevas inversiones en funcionalidades, así que planifique la vida útil del diseño en consecuencia.

Una ruta de decisión para 2026

1. Inventaríe el plano de control, incluido el control indirecto a través de copias de seguridad, virtualización, agentes y ACL. La mayoría de los entornos descubren que su Tier 0 real es entre cinco y diez veces mayor que los grupos de administración.
2. Elimine las rutas de ataque hacia él con la gestión de rutas de ataque: ACL, delegación, AD CS, cuentas de servicio, vínculos de GPO.
3. Aplique los niveles con restricciones de inicio de sesión, silos y Protected Users.
4. Construya PAW para el trabajo en el plano de control y traslade a ellas las tareas de administración.
5. Añada elevación just-in-time, con Entra PIM para los roles en la nube y pertenencia temporal o un producto PAM en el entorno local.
6. Solo entonces evalúe si un bosque bastión aporta un aislamiento que los pasos 1 a 5 no hayan logrado.

Verificar

Mida resultados, no diagramas de arquitectura:

• Miembros permanentes de los grupos de Tier 0, con tendencia a quedar solo las cuentas de emergencia.
• Los inicios de sesión de Tier 0 (evento 4624 en equipos que no son de Tier 0 para cuentas de grupos de Tier 0) deberían ser cero; genere una alerta ante cualquiera. La referencia de ID de evento enumera los campos.
• Aplicación de los silos: los errores de autenticación de las cuentas incluidas en silos aparecen en los DC en Applications and Services Logs > Microsoft > Windows > Authentication > AuthenticationPolicyFailures-DomainController y, durante un despliegue en modo solo auditoría, señalan cada lugar en el que un administrador todavía se autentica fuera de la directiva.
• Rutas de ataque de Domain Users a Tier 0 en BloodHound, notificadas como recuento y tendencia.
• Si existe un bosque bastión: la confianza es unidireccional, la autenticación selectiva y el filtrado de SID están configurados como se espera y la pertenencia de las entidades de seguridad de sombra caduca.

Qué se rompe

• Los hábitos diarios de los administradores. Las cuentas separadas, las PAW y la prohibición de administrar desde el portátil del correo añaden fricción; cuente con resistencia y planifíquela.
• Las herramientas de administración con agentes de amplio alcance. Las herramientas de supervisión, copia de seguridad e implementación que se ejecutan con SYSTEM en los DC pasan a Tier 0 o pierden el acceso a los DC.
• Los silos de autenticación impiden que los administradores inicien sesión en equipos fuera del silo, incluida la resolución de problemas de emergencia en servidores miembro; cree y pruebe procedimientos de emergencia.
• Retirar un ESAE existente exige devolver los derechos de administración a cuentas de producción protegidas por los nuevos controles, eliminar la confianza y limpiar los grupos que hacían referencia a entidades de seguridad del bosque administrativo; no deje el bosque antiguo funcionando sin administrar.
• Los bosques bastión se rompen cuando fallan su confianza o sus DC, y con ellos el acceso privilegiado; mantenga cuentas de emergencia documentadas en producción.

Lecturas relacionadas: el tema Confianzas y diseño de bosque, la entrada del glosario sobre el modelo de niveles y Filtrado de SID y autenticación selectiva para configurar cualquier confianza que conserve.