Hardening de confianzas y límites de bosque en AD

La documentación de Active Directory y buena parte de las herramientas que lo rodean siguen hablando de «seguridad del dominio» como si un dominio fuera un límite de aislamiento. No lo es. Cada controlador de dominio de un bosque contiene una réplica completa y grabable de las particiones de esquema y de configuración, todos los dominios confían implícitamente en la raíz del bosque, y Enterprise Admins, en el dominio raíz, tiene derechos sobre todos los dominios del bosque. Tratar un dominio secundario o de recursos como límite de seguridad y escatimar en el hardening de las confianzas es uno de los errores de diseño más persistentes en los entornos de AD, y es precisamente lo que permite a un atacante que aterriza en un dominio de poco valor pivotar hacia el dominio que de verdad importa.

Este artículo explica cómo inventariar y endurecer las confianzas dentro de sus bosques y entre ellos: tipos de confianza y transitividad, filtrado de SID y cuarentena, autenticación selectiva, y cuándo está realmente justificado un bosque administrativo dedicado o una confianza PAM frente a cuándo el modelo moderno de acceso empresarial ya le cubre.

El límite es el bosque, no el dominio

Algunos hechos que deberían guiar cada decisión sobre confianzas:

• La partición de esquema y la partición de configuración se replican en todos los DC del bosque. Un cambio de esquema o un objeto malicioso en la partición de configuración (por ejemplo, un contenedor de directiva de grupo fraudulento o un vínculo de sitio falsificado) afecta a todos los dominios.
• Enterprise Admins y Schema Admins (dominio raíz del bosque) tienen derechos en todo el bosque, incluida la capacidad de modificar el esquema y agregar dominios.
• Cualquier compromiso de un controlador de dominio, en cualquier dominio, es una vía creíble hacia el compromiso total del bosque mediante abuso de la replicación, manipulación del esquema o explotación de confianzas.

Consecuencia práctica: si necesita un aislamiento real (una filial que no debe afectar a su entorno principal, una adquisición en una fusión con una higiene desconocida, un requisito normativo de administración separada), necesita un bosque independiente con una confianza de alcance cuidadosamente acotado, no un dominio secundario en el mismo bosque.

Tipos de confianza y transitividad, en resumen

Las confianzas de bosque y las externas son las que atraviesan un límite de seguridad real y merecen los controles que se describen a continuación. Las confianzas dentro del bosque ya están dentro de su radio de impacto; eso se corrige con el modelo de niveles (Tier 0 y acceso privilegiado), no con la configuración de las confianzas.

Inventariar primero las confianzas existentes

Antes de cambiar nada, sepa qué tiene:

Get-ADTrust -Filter * -Properties * |
  Select-Object Name, Direction, TrustType, ForestTransitive, SIDFilteringForestAware, SIDFilteringQuarantined, SelectiveAuthentication, IntraForest, DisallowTransivity |
  Format-Table -AutoSize

Para cada confianza, compruebe también con netdom:

netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify
netdom query trust

Marque cualquier confianza en la que:

• SIDFilteringQuarantined sea False en una confianza externa, o SIDFilteringForestAware sea True en una confianza de bosque (se permite el historial de SID a través de ella).
• SelectiveAuthentication sea False en una confianza externa o de bosque con un socio no fiable o de un nivel inferior.
• La dirección de la confianza sea bidireccional cuando en realidad solo se necesita una dirección: una confianza unidireccional saliente desde el lado sensible elimina una ruta de ataque completa.
• La confianza sea antigua, no esté documentada o esté ligada a un dominio de un socio ya retirado. Las confianzas obsoletas son habituales en entornos que pasaron por fusiones, desinversiones o migraciones y nunca se sanearon después.

Filtrado de SID y cuarentena

El historial de SID (sIDHistory) existe para conservar el acceso durante las migraciones de dominio: un usuario trasladado del dominio A al dominio B conserva sus SID antiguos para que las ACL existentes sigan resolviéndose. Ese mismo mecanismo es la base de la inyección de historial de SID: si un atacante compromete el dominio A (o un DC de ese dominio) y la confianza no filtra el historial de SID, puede asociar el SID de, por ejemplo, Enterprise Admins del dominio B a una entidad de seguridad del dominio A y autenticarse como si tuviera privilegios en B.

El filtrado de SID está activado de forma predeterminada en las confianzas de bosque (se descartan los SID que no pertenecen al bosque de confianza) y, en forma de cuarentena, en las confianzas externas creadas con versiones modernas de Windows Server, pero con frecuencia se relaja durante las migraciones (/quarantine:no o /enablesidhistory:yes) y nunca se revierte. Verifíquelo y aplíquelo:

:: Enable quarantine (SID filtering) on an external trust
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:yes /userD:<Admin> /passwordD:*

:: On a forest trust: explicitly disable SID history acceptance (only re-enable temporarily during a real migration)
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:no

Verifíquelo mediante script:

Get-ADTrust -Filter {Name -eq "<TrustedDomainName>"} | Select-Object Name, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware

SIDFilteringQuarantined debe ser True en todas las confianzas externas y SIDFilteringForestAware debe ser False en todas las confianzas de bosque, salvo que se encuentre en una ventana de migración activa y acotada en el tiempo en la que el historial de SID sea necesario. En ese caso, trate esa ventana como un periodo de alto riesgo, supervise de cerca los eventos de pertenencia a grupos 4728/4732/4756 y vuelva a deshabilitar la aceptación del historial de SID en cuanto termine la migración.

Autenticación selectiva

El filtrado de SID controla qué afirmaciones de identidad se aceptan. La autenticación selectiva controla a qué recursos pueden siquiera intentar llegar las entidades de seguridad del dominio de confianza. En una confianza de bosque o externa con la autenticación selectiva habilitada, una entidad de seguridad del dominio de confianza no obtiene acceso a ningún recurso del dominio que confía hasta que un administrador le concede explícitamente el permiso «Allowed to Authenticate» (Se permite autenticar) sobre objetos de equipo concretos.

Habilítela:

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth:yes

A continuación, conceda acceso solo donde sea necesario, objeto de equipo por objeto de equipo, desde la pestaña Seguridad → Allowed to Authenticate, o con dsacls:

dsacls "CN=<TargetComputer>,OU=Servers,DC=trusting,DC=example,DC=com" /G "TRUSTEDDOMAIN\SomeGroup:CA;Allowed to Authenticate"

Esto convierte una confianza abierta, en la que cualquier usuario autenticado del dominio del socio puede intentar iniciar sesión en cualquier sitio, en una lista de permitidos explícita. Es el control de mayor valor en una confianza externa o de bosque y debería ser la postura predeterminada para cualquier confianza con un socio que no controle por completo.

Abuso del historial de SID: qué vigilar

Incluso con la cuarentena habilitada, supervise las anomalías en lugar de dar por hecho que el control es infalible:

• Aparición repentina de valores de sIDHistory en cuentas fuera de una migración conocida y planificada.
• Tickets Kerberos de tipo golden ticket que incluyen historial de SID de grupos privilegiados: aparecen como contenido anómalo del PAC en las herramientas de detección y en las alertas de Microsoft Defender for Identity.
• Eventos de autenticación desde un dominio de confianza contra activos Tier 0 que quedan fuera de los permisos «Allowed to Authenticate» que haya configurado.

Consulte Auditoría, registro y detección para conocer los ID de evento y la configuración de SACL que hacen visible todo esto.

Cuándo necesita realmente un Red Forest o una confianza PAM

El ESAE (Enhanced Security Admin Environment) original de Microsoft, conocido popularmente como «Red Forest», utilizaba un bosque administrativo dedicado y endurecido con una confianza PAM (Privileged Access Management) unidireccional hacia el bosque de producción, de modo que las credenciales de Tier 0 nunca tocaban estaciones de trabajo unidas al bosque de producción. Microsoft retiró ESAE como recomendación general a finales de 2020, junto con su estrategia de acceso privilegiado, en favor del modelo moderno de acceso empresarial basado en Azure AD / Microsoft Entra ID, Privileged Access Workstations y administración Just-In-Time/Just-Enough-Administration, porque un bosque administrativo independiente es caro de operar, se convierte a su vez en un objetivo y no aborda en absoluto las rutas de ataque de la identidad en la nube.

Aun así, plantéese un bosque administrativo dedicado o una confianza PAM cuando:

• Esté en un entorno aislado (air-gapped) o no pueda adoptar un plano de control de identidad en la nube (entornos regulados, clasificados u OT).
• Tenga un entorno multibosque muy grande en el que un límite de confianza administrativo realmente separado reduzca el radio de impacto entre bosques con más eficacia que el modelo de niveles por sí solo.
• Necesite un puente durante una migración prolongada de identidad de AD a la nube y quiera mantener aislado Tier 0 mientras tanto.

En la mayoría de los entornos, invierta primero en el modelo de niveles de Tier 0 y acceso privilegiado, en Privileged Access Workstations y en el hardening de confianzas de este artículo: eso cierra la mayoría de las rutas de ataque a las que apuntaba ESAE, con una fracción de su coste operativo.

Qué se rompe

• El acceso entre bosques o entre dominios que dependía de una confianza abierta (no selectiva). Las aplicaciones, los recursos compartidos o las cuentas de servicio que se autentican a través de la confianza desde el dominio del socio fallarán hasta que conceda explícitamente «Allowed to Authenticate» en cada objeto de equipo de destino. Inventaríe los patrones de acceso a través de la confianza (mediante los eventos de inicio de sesión 4624/4625 filtrados por dominio de origen) antes de activar la autenticación selectiva en producción.
• Las migraciones que dependen del historial de SID se romperán si deshabilita enablesidhistory mientras la migración sigue en curso. Aplique la cuarentena al historial de SID solo cuando el trabajo de migración en esa relación de confianza haya terminado por completo.
• Las confianzas heredadas con dominios de socios retirados o con una higiene deficiente quizá simplemente deban eliminarse en lugar de endurecerse: netdom trust /remove suele ser la respuesta correcta una vez confirmado que la confianza no tiene dependencias activas.

Combine esto con el hardening de controladores de dominio y la seguridad de objetos y ACL: el hardening de confianzas limita lo que puede alcanzar un dominio de un socio comprometido, pero no sustituye al hardening de los DC y de los objetos de su lado de la confianza.