Filtrado de SID y autenticación selectiva, paso a paso

Una confianza extiende su límite de seguridad a todo lo que haya al otro lado. Si el dominio de confianza se ve comprometido, hay dos factores que deciden hasta dónde llega el atacante: qué SID aceptan sus controladores de dominio en los datos de autorización que llegan a través de la confianza, y cuáles de sus equipos aceptan siquiera la autenticación de entidades de seguridad de confianza. El filtrado de SID responde a la primera pregunta y la autenticación selectiva, a la segunda. Ambos son interruptores sencillos, y ambos se dejan habitualmente en la posición equivocada tras una migración o una integración apresurada con un socio.

El pilar sobre confianzas y límites de bosque explica por qué el límite es el bosque. Esta guía es la continuación operativa: cómo leer el estado real de cada confianza a partir de trustAttributes, cómo se comporta el filtrado de SID en las confianzas externas frente a las de bosque, cómo desplegar la autenticación selectiva sin romper el acceso entre bosques y cómo verificarlo con eventos.

Medir: leer los indicadores de la confianza, no la interfaz gráfica

El cuadro de diálogo de propiedades de la confianza oculta varias opciones. La fuente autorizada es la máscara de bits trustAttributes del objeto trustedDomain en CN=System.

Get-ADObject -SearchBase "CN=System,$((Get-ADDomain).DistinguishedName)" `
    -LDAPFilter "(objectClass=trustedDomain)" -Properties trustAttributes, trustDirection, trustType |
  Select-Object Name, trustDirection, trustType,
    @{n='Attr';e={'0x{0:X}' -f $_.trustAttributes}},
    @{n='Forest';e={[bool]($_.trustAttributes -band 0x8)}},
    @{n='Quarantined';e={[bool]($_.trustAttributes -band 0x4)}},
    @{n='SelectiveAuth';e={[bool]($_.trustAttributes -band 0x10)}},
    @{n='SIDHistoryAllowed';e={[bool]($_.trustAttributes -band 0x40)}},
    @{n='TGTDelegationEnabled';e={[bool]($_.trustAttributes -band 0x800)}}

En trustDirection, 1 es entrante (ellos confían en usted), 2 es saliente (usted confía en ellos y sus usuarios pueden llegar a sus recursos) y 3 es bidireccional. El hardening se aplica en el lado que confía: los controles siguientes protegen al dominio que confía frente a las entidades de seguridad del dominio de confianza. Ejecute la consulta en cada dominio que tenga confianzas.

Cómo se comporta realmente el filtrado de SID

El filtrado se produce en los controladores de dominio del lado que confía cuando procesan los datos de autorización (el PAC) que llegan a través de la confianza.

• Confianzas externas con cuarentena: solo se conservan los SID del propio dominio de confianza. Se descarta el historial de SID de cualquier otro dominio.
• Confianzas de bosque (valor predeterminado): se aceptan los SID que pertenecen a cualquier dominio del bosque de confianza; se descartan los SID que dicen pertenecer a su bosque o a un tercer bosque. Eso significa que se filtra el historial de SID que apunta a sus propios grupos, que es exactamente lo que neutraliza la inyección de historial de SID.
• Confianzas de bosque con /enablesidhistory:yes (TREAT_AS_EXTERNAL): se acepta el historial de SID procedente de fuera del bosque de confianza, salvo los SID con un RID inferior a 1000. Los grupos integrados como Domain Admins y Enterprise Admins quedan protegidos, pero los grupos de administración personalizados, los grupos de Exchange y los grupos delegados del servicio de asistencia tienen RID superiores a 1000 y pueden inyectarse.
• Confianzas dentro del bosque: sin filtrado. Las confianzas primario-secundario están dentro del límite; ponerlas en cuarentena no es compatible y rompe las operaciones del bosque.

Cuando un DC descarta SID, registra el evento 4675, «SIDs were filtered», que le da una señal directa de un efecto colateral de una migración o de un intento de inyección. El acceso legítimo entre bosques se describe con más detalle en la entrada del glosario sobre el filtrado de SID.

Auditar: quién depende de qué

Antes de endurecer, averigüe qué atraviesa cada confianza.

1. Pertenencia a grupos: las entidades de seguridad externas de CN=ForeignSecurityPrincipals representan usuarios y grupos del dominio de confianza incluidos en sus grupos. Resuélvalas y revíselas.
2. Inicios de sesión: el evento 4624 en los servidores con un TargetDomainName del dominio de confianza, y el 4769 en sus DC para los tickets de referencia, muestran qué equipos utilizan realmente las entidades de seguridad del socio.
3. Dependencia del historial de SID: cualquier cuenta del dominio de confianza cuyo sIDHistory contenga SID de su dominio, algo que solo funciona mientras se permita el historial de SID. Ese trabajo corresponde a la limpieza del historial de SID.

Get-ADObject -SearchBase "CN=ForeignSecurityPrincipals,$((Get-ADDomain).DistinguishedName)" -Filter * -Properties memberOf |
  ForEach-Object {
    $name = try { ([Security.Principal.SecurityIdentifier]$_.Name).Translate([Security.Principal.NTAccount]).Value } catch { 'unresolved' }
    [pscustomobject]@{ SID = $_.Name; Account = $name; MemberOf = ($_.memberOf -join '; ') }
  }

Las FSP que no se pueden resolver suelen apuntar a objetos eliminados del socio o a confianzas retiradas, y pueden quitarse de los grupos.

Aplicar: filtrado de SID

Ejecute netdom en un DC del dominio que confía, como Domain Admin de ese dominio. Para las confianzas externas:

netdom trust corp.example.com /domain:partner.example.net /quarantine
netdom trust corp.example.com /domain:partner.example.net /quarantine:yes

La primera forma informa del estado actual; la segunda habilita la cuarentena. Para las confianzas de bosque, restaure el filtrado predeterminado después de una migración:

netdom trust corp.example.com /domain:partner.example.net /enablesidhistory
netdom trust corp.example.com /domain:partner.example.net /enablesidhistory:no

Ya que está en netdom, compruebe la delegación de TGT. Desde las actualizaciones de julio de 2019, la delegación sin restricciones a través de confianzas de bosque está bloqueada de forma predeterminada, y el indicador 0x800 de la consulta de medición muestra si alguien la ha vuelto a habilitar. Las indicaciones de Microsoft para este modificador nombran primero el bosque de confianza; confirme el orden de los argumentos con netdom trust /? en su DC:

netdom trust <TrustedForestName> /domain:<TrustingForestName> /EnableTGTDelegation:No

Permitir la delegación de TGT haría posible que un servidor con delegación sin restricciones en un bosque capturara TGT del otro.

Aplicar: autenticación selectiva

La autenticación selectiva (CROSS_ORGANIZATION) cambia el comportamiento predeterminado para las entidades de seguridad de confianza de «los usuarios autenticados pueden llegar a cualquier equipo» a «a ningún equipo salvo que se permita explícitamente». Despliéguela en este orden.

1. Crear grupos de permiso en el lado de los recursos

Cree un grupo local de dominio por cada conjunto de recursos en el dominio que confía, por ejemplo SA-Partner-FileServers, y agregue a él los grupos globales del socio. Mantener el acceso en grupos que usted controla hace que las ACL sigan siendo legibles.

2. Conceder Allowed to Authenticate en cada equipo de destino

El derecho es el derecho extendido Allowed to Authenticate (68b1d179-0d15-4d4f-ab71-46152e79a7bc) sobre los objetos de equipo. Concédalo con PowerShell:

$group   = Get-ADGroup "SA-Partner-FileServers"
$sid     = [Security.Principal.SecurityIdentifier]$group.SID
$guid    = [Guid]"68b1d179-0d15-4d4f-ab71-46152e79a7bc"
$targets = "FS01","FS02"

foreach ($t in $targets) {
    $dn  = (Get-ADComputer $t).DistinguishedName
    $acl = Get-Acl "AD:$dn"
    $ace = New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, "ExtendedRight", "Allow", $guid)
    $acl.AddAccessRule($ace)
    Set-Acl "AD:$dn" $acl
}

Por lo general no necesita conceder este derecho en sus controladores de dominio para que los usuarios del socio lleguen a los servidores miembro. Concédalo en un DC solo si las entidades de seguridad del socio deben usar un recurso alojado en ese DC, y nunca de forma amplia sobre la OU Domain Controllers.

3. Activar el interruptor

netdom trust corp.example.com /domain:partner.example.net /SelectiveAuth:yes

El cambio surte efecto a medida que se replica. Tenga preparado /SelectiveAuth:no como reversión y realice el cambio en una ventana en la que el socio pueda hacer pruebas.

Planificar el despliegue con el socio

Los cambios en las confianzas afectan a personas que usted no administra, así que trátelos como un cambio conjunto y no como una configuración local.

• Comparta primero la evidencia. Envíe al socio la lista de entidades de seguridad externas y de los servidores en los que sus usuarios se autentican realmente, obtenida de los datos del evento 4624 anteriores. A menudo detectarán cuentas obsoletas y accesos sin uso que puede eliminar en lugar de concederlos.
• Reduzca la dirección antes de añadir controles. Si solo sus usuarios necesitan los recursos de usted, la confianza debería ser unidireccional saliente desde su dominio; una confianza bidireccional duplica la superficie sin ningún beneficio. Vuelva a crear la confianza en la dirección necesaria en lugar de endurecer un lado que nadie usa.
• Prefiera las confianzas de bosque a las externas entre bosques que usted controla, porque las confianzas de bosque usan Kerberos de forma predeterminada, admiten restricciones de enrutamiento de sufijos de nombre y filtran los SID teniendo en cuenta el bosque. Las confianzas externas recurren a NTLM con más frecuencia, lo que interfiere con cualquier plan para restringir NTLM.
• Restrinja el enrutamiento de sufijos de nombre en las confianzas de bosque para que el socio no pueda enrutar la autenticación de sufijos que usted no pretendía aceptar.
• Acuerde un ciclo de revisión. Las confianzas sobreviven a los proyectos que las crearon. Asigne un responsable y una fecha de revisión a cada confianza, y elimínela con netdom trust /remove cuando termine la necesidad de negocio.

Verificar

# Vuelva a ejecutar la consulta de trustAttributes anterior y compárela con Get-ADTrust
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

# Quién puede autenticarse en un servidor determinado
(Get-Acl "AD:$((Get-ADComputer FS01).DistinguishedName)").Access |
  Where-Object { $_.ObjectType -eq '68b1d179-0d15-4d4f-ab71-46152e79a7bc' } |
  Select-Object IdentityReference, AccessControlType

SIDFilteringForestAware con valor True en una confianza de bosque significa que se permite el historial de SID, el estado que quiere revertir. Después, pruebe desde el lado del socio: un usuario permitido llega a FS01; ese mismo usuario, al intentar llegar a otro servidor, debería fallar con el evento 4625 y el estado 0xC0000413 en ese servidor. Reenvíe los eventos 4675 y 4625 con ese estado a su SIEM con el diseño de recopilación descrito en Windows Event Forwarding.

Qué se rompe

• Todo lo que dependa del acceso implícito a través de una confianza abierta: los recursos compartidos de archivos, los inicios de sesión de SQL, las aplicaciones web que usan Kerberos y los servidores de impresión fallan para los usuarios del socio hasta que cada equipo de destino tenga un permiso Allowed to Authenticate.
• Los inicios de sesión interactivos de usuarios del socio en estaciones de trabajo o hosts RDS de su dominio necesitan un permiso en cada uno de esos equipos; si la lista es larga, el propio diseño de la confianza merece una revisión.
• Las migraciones en curso se rompen cuando vuelve el filtrado del historial de SID, ya que los usuarios migrados pierden el acceso concedido mediante los SID antiguos.
• Los escenarios de delegación sin restricciones entre bosques dejan de funcionar cuando se deshabilita la delegación de TGT; muévalos a delegación restringida o RBCD.
• Las herramientas de identidad de terceros que enumeran o se autentican a través de la confianza desde servidores arbitrarios necesitan sus propios permisos.

Lecturas relacionadas: el tema Confianzas y diseño de bosque, la entrada del glosario sobre el historial de SID y delegación restringida y RBCD de forma segura para sustituir la delegación sin restricciones entre bosques.