Cómo configurar y proteger las relaciones de confianza Active Directory

Qué son las relaciones de confianza de Active Directory

Una relación de confianza de Active Directory (trust) permite que un controlador de dominio de un dominio dé fe de la identidad de una cuenta autenticada en un dominio o bosque diferente. Internamente, cada relación de confianza se almacena como un objeto TDO (Trusted Domain Object) que registra el nombre del dominio de confianza, la dirección, la transitividad y un secreto compartido — la contraseña de la relación de confianza — utilizado para proteger el tráfico de autenticación que la atraviesa. Las relaciones de confianza de Active Directory son lo que hace utilizable un bosque multidominio: sin ellas, cada dominio sería una isla de autenticación aislada, sin forma de hacer referencia a usuarios o grupos de ningún otro lugar.

Una relación de confianza por sí sola no otorga ningún acceso. Solo extiende la ruta de autenticación — lo que la cuenta solicitante puede alcanzar realmente al otro lado sigue estando gobernado por las ACL, la pertenencia a grupos y la configuración de delegación. Dicho esto, una relación de confianza mal configurada amplía el radio de impacto de un compromiso en cualquiera de los dos lados, por lo que la configuración de las relaciones de confianza merece la misma disciplina que cualquier otro cambio Tier 0.

Tipos de relaciones de confianza y transitividad

No todas las relaciones de confianza se comportan igual. Dos propiedades determinan hasta dónde llega realmente una relación de confianza: la dirección (qué lado puede autenticar a sus usuarios hacia el otro) y la transitividad (si la relación se extiende implícitamente a los dominios en los que confía el propio lado de confianza).

Dos consecuencias importan para el fortalecimiento (hardening):

• Las cadenas de transitividad. Una relación de confianza de bosque transitiva no se detiene en la raíz del bosque — se extiende a cada dominio dentro de ese bosque. Confiar en un bosque significa confiar en cada administrador de dominio que contiene, no solo en el equipo que solicitó la integración.
• La dirección limita la exposición. Una relación de confianza unidireccional donde el dominio A confía en el dominio B permite que los usuarios de B se autentiquen en A, pero no al revés. Donde la necesidad del negocio es unidireccional, configurar una relación bidireccional "por si acaso" solo añade una ruta de autenticación que nadie pidió. TRUST_BIDIRECTIONAL en el catálogo de EtcSec señala toda relación de confianza bidireccional externa, de bosque o entre árboles (las relaciones padre-hijo quedan excluidas, ya que son bidireccionales por diseño) — una señal de configuración a revisar, no una certeza de que el tráfico solo fluye en un sentido en la práctica.

Cómo configurar una relación de confianza segura paso a paso

Los siguientes pasos se centran en las relaciones externas y de bosque — los casos que necesitan un endurecimiento deliberado. Las relaciones padre-hijo y de raíz de árbol se crean automáticamente durante el proceso de promoción de dominio y bosque y heredan los valores predeterminados del bosque; el filtrado SID no se aplica a ellas por diseño, porque se espera el historial SID entre dominios del mismo bosque.

Paso 1 — Planificar la relación de confianza antes de crearla

Anote, antes de abrir cualquier consola: qué lado inicia la autenticación, si debe ser unidireccional o bidireccional, qué recursos necesita alcanzar realmente el lado de confianza, quién es el propietario de la relación, y una fecha de revisión. Una relación de confianza sin propietario y sin fecha de revisión es la que seguirá abierta cinco años después de que termine el proyecto que la solicitó.

Paso 2 — Crear la relación de confianza

Cree la relación de confianza desde la consola Dominios y confianzas de Active Directory (asistente de nueva relación de confianza), o de forma no interactiva con netdom:

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Quite /twoway para una relación unidireccional — haga que coincida con lo que realmente exige el Paso 1, no con lo más rápido de configurar.

Paso 3 — Restringir el cifrado de la relación de confianza a AES

Las nuevas relaciones de confianza nunca deben dejarse con el cifrado predeterminado. Compruebe el atributo msDS-SupportedEncryptionTypes de la cuenta de confianza entre dominios y configúrelo solo a AES (0x18) en cuanto todos los sistemas que se autentican a través de la relación admitan AES:

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Un atributo indefinido tampoco es un valor predeterminado seguro que asumir en ningún sentido — la propia documentación de Microsoft señala que AES se admite de forma predeterminada en controladores de dominio, controladores de dominio de solo lectura y relaciones de confianza solo una vez que el controlador de dominio de despliegue está parcheado para los cambios de Kerberos RC4 de 2022, y que una relación de confianza obsoleta o nunca modificada aún puede negociar RC4. TRUST_AES_DISABLED se activa siempre que el atributo no indique compatibilidad con AES, incluso cuando simplemente no está definido. TRUST_RC4_ONLY es más estrecho: solo se activa cuando la relación de confianza indica explícitamente compatibilidad con RC4 sin AES, de modo que un atributo simplemente indefinido no lo activará.

Paso 4 — Habilitar el filtrado SID (cuarentena)

El filtrado SID está habilitado de forma predeterminada para las nuevas relaciones de confianza externas y de bosque, pero se desactiva habitualmente durante migraciones que dependen de sIDHistory y luego nunca se vuelve a activar. Confírmelo explícitamente:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

TRUST_SID_FILTERING_DISABLED señala cualquier relación de confianza externa o de bosque donde esto esté desactivado. No lo cambie a ciegas — si una migración en curso depende del historial SID para preservar el acceso, la cuarentena romperá ese acceso hasta que termine la migración.

Paso 5 — Delimitar la autenticación selectiva

La autenticación selectiva convierte "cualquier usuario autenticado del lado de confianza puede intentar acceder a cualquier cosa de este lado" en una lista de permitidos con nombre. Actívela en el lado saliente de la relación de confianza, y luego conceda el derecho extendido Permitido para autenticar únicamente en los objetos de equipo concretos que las cuentas del lado de confianza realmente necesitan alcanzar:

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

TRUST_EXTERNAL_NO_SELECTIVE_AUTH se activa cuando una relación de confianza externa no tiene configurada ninguna autenticación selectiva — la brecha más común en relaciones de confianza creadas para una integración puntual con un socio.

Paso 6 — Validar la relación de confianza

Confirme que la relación de confianza se comporta como pretendía el Paso 1 antes de dar el cambio por terminado:

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

Luego, fuerce un intento de autenticación real a través de la relación de confianza y lea el tipo de cifrado negociado con klist. El estado de configuración y lo que realmente se negocia en la red pueden divergir si una GPO posterior o un miembro heredado sobrescribe la configuración propia de la relación de confianza.

Detección

La creación y modificación de relaciones de confianza son eventos registrados, no cambios silenciosos — si la deriva de las relaciones de confianza solo aparece en una auditoría periódica en lugar de generar una alerta, el problema está en la canalización de registro, no en la visibilidad.

Un solo evento prueba muy poco por sí mismo — un 4716 que desactiva SidFilteringEnabled es rutinario durante una migración planificada y alarmante en cualquier otro contexto. Genere una alerta sobre el evento y luego contrástelo con el ticket de cambio.

Remediation y checklist de fortificación

1. Inventaríe cada relación de confianza con Get-ADTrust -Filter * y registre un propietario, una justificación de negocio y una fecha de revisión para cada una.
2. Haga coincidir la dirección con la necesidad real — no mantenga una relación bidireccional donde la autenticación solo fluye en un sentido.
3. Habilite el filtrado SID en toda relación de confianza externa y de bosque que no esté activamente en migración.
4. Delimite la autenticación selectiva a los sistemas específicos que necesita el lado de confianza, no a todo el dominio.
5. Pase a cifrado solo AES en cuanto todos los sistemas que se autentican lo admitan.
6. Elimine las relaciones de confianza sin propietario ni necesidad de negocio actual en lugar de dejarlas "documentadas" indefinidamente.

Para la checklist completa con PowerShell para cada control y el mapeo de cumplimiento, vea auditoría de filtrado SID y autenticación selectiva de las relaciones de confianza de Active Directory. Para la narrativa de ataque frente a la que protegen estos controles, vea ataques de confianza AD: del dominio hijo a la raíz del bosque.

Ciclo de vida de las relaciones de confianza: bidireccionales, transitivas e inactivas

Las relaciones de confianza son fáciles de crear y fáciles de olvidar. Tres hallazgos del catálogo apuntan exactamente a esa brecha de ciclo de vida:

• TRUST_BIDIRECTIONAL — señala toda relación de confianza bidireccional fuera de las padre-hijo, por configuración, independientemente del uso observado. Si la necesidad de negocio es unidireccional, reducirla a un solo sentido elimina una ruta de autenticación sin pérdida de funcionalidad.
• TRUST_FOREST_TRANSITIVE — una relación de confianza de bosque hereda cada dominio dentro del bosque de confianza, no solo el dominio que solicitó la integración. Antes de aprobar una relación de confianza de bosque, revise la propia lista de dominios del bosque de confianza y su higiene administrativa, no solo el recurso que necesita quien la solicita.
• TRUST_INACTIVE — una relación de confianza cuya contraseña entre dominios no ha rotado en más de 180 días. Windows rota automáticamente la contraseña de una relación de confianza activa aproximadamente cada 30 días, así que un pwdLastSet obsoleto es un indicador de una relación de confianza abandonada que nadie mantiene, más que una medida directa del tráfico de autenticación. Una relación de confianza inactiva que nadie usa sigue siendo una ruta de autenticación activa que nadie vigila. Si la necesidad de negocio terminó, elimine la relación de confianza mediante el proceso de cambio normal en lugar de dejarla "por si acaso".

Ninguno de estos tres hallazgos requiere un compromiso para importar — son problemas de configuración e higiene de ciclo de vida que reducen la superficie de ataque antes de un incidente, no después de uno.

Cómo EtcSec detecta esto

EtcSec lee directamente el bitmask trustAttributes de cada objeto TDO (Trusted Domain Object) y el atributo msDS-SupportedEncryptionTypes de la cuenta de confianza entre dominios — las mismas propiedades que exponen Get-ADTrust y Get-ADObject mostrados arriba. Señala TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY y TRUST_AES_DISABLED en cada relación de confianza del entorno, con hallazgos vinculados al objeto de confianza concreto para que la remediation apunte exactamente al comando necesario.

Para profundizar

Para la narrativa de ataque frente a la que protegen estos controles, vea ataques de confianza AD: del dominio hijo a la raíz del bosque. Para la checklist de auditoría en profundidad sobre filtrado SID, autenticación selectiva y cifrado, vea auditoría de filtrado SID y autenticación selectiva de las relaciones de confianza de Active Directory. La rotación de la contraseña de la relación de confianza se cubre en rotación de la contraseña krbtgt, la cuenta de confianza y la contraseña de máquina del controlador de dominio, y el riesgo de delegación que a menudo cruza un límite de confianza se cubre en delegación Kerberos no restringida a abuso RBCD. Para saber dónde encaja la revisión de relaciones de confianza en una auditoría completa del entorno, vea auditoría de seguridad de Active Directory: qué revisar primero y cómo demostrar la remediation.

Referencias principales

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack