Principales de seguridad externos AD: clasificar SID antes de limpiar

Qué representan los principales de seguridad externos AD

Los principales de seguridad externos AD son objetos de representación que permiten a un dominio representar identidades de seguridad que no almacena como usuarios o grupos locales ordinarios. Su presencia es un dato de inventario. No demuestra un ataque, un permiso peligroso ni una relación de confianza averiada. Revise el SID de cada objeto y los grupos que lo utilizan antes de decidir si hay que cambiar algo.

La especificación de Microsoft del contenedor Foreign Security Principals en MS-ADTS explica el caso de AD DS: el contexto de nomenclatura del dominio contiene un contenedor de objetos foreignSecurityPrincipal que representan principales de dominios de confianza externos al bosque, lo que permite a esos principales incorporarse a grupos del dominio. Este artículo trata AD DS, no las reglas independientes del contenedor de AD LDS.

También existe un caso normal con SID conocidos. La explicación histórica de Microsoft sobre los FSP, actualizada por última vez el 24 de mayo de 2016, describe por qué añadir una identidad conocida al atributo member de un grupo puede crear un objeto de representación: la referencia de pertenencia necesita un nombre distintivo existente. El archivo recomienda revisar memberOf antes de eliminar un FSP. Documenta la pertenencia a grupos; no demuestra que cada referencia en una ACL cree un FSP.

Las fuentes técnicas y el comportamiento del recolector se revisaron el 4 de octubre de 2026. Los comandos siguientes son ejemplos basados en la documentación para un administrador autorizado; no se ejecutaron en un dominio de un cliente.

Cómo clasificar el SID y sus dependencias

Empiece con tres resultados: identidad conocida, identidad externa resuelta e indeterminado. Son decisiones de revisión, no niveles de gravedad inferidos de una cantidad de objetos. Conserve el SID en el registro aunque una herramienta muestre un nombre legible. Los nombres sirven para contactar con los responsables; el SID es la identidad referenciada.

La referencia actual de Microsoft sobre identificadores de seguridad enumera las siguientes identidades conocidas:

Es un conjunto de ejemplos, no una tabla de consulta completa. Compare cualquier otro SID con la referencia de Microsoft antes de asignarle una etiqueta. Conocido significa identidad reconocida, no acceso automáticamente apropiado. Una pertenencia amplia puede seguir mereciendo una revisión, pero eliminar su objeto de representación no sustituye la revisión de la decisión de pertenencia.

Para un SID de cuenta de dominio, identifique el dominio emisor y pida al administrador responsable de ese dominio que confirme el principal exacto. Registre el dominio de origen, la identidad actual, el responsable de negocio y el propósito de su pertenencia. Una resolución de nombre satisfactoria por sí sola no demuestra que el grupo siga siendo necesario. Una resolución fallida por sí sola no demuestra que el principal se haya eliminado.

Mantenga explícita la incertidumbre. El registro de revisión debe responder a cuatro preguntas: ¿finalizó la recopilación, qué grupos utilizan el objeto, se puede contactar con el socio de confianza pertinente y quién puede aprobar la decisión de negocio? Una pregunta sin respuesta mantiene el objeto en la categoría indeterminada.

Detección: inventariar SID, memberOf y contexto de confianza

Paso 1: recopilar objetos independientemente del recuento

Utilice un equipo de administración Windows autorizado con el módulo PowerShell ActiveDirectory. Seleccione deliberadamente un controlador de dominio y registre el equipo, el dominio, la hora de recopilación y cualquier error. La documentación de Microsoft de Get-ADRootDSE expone defaultNamingContext; úselo para construir el DN del contenedor específico del dominio en lugar de copiar la ruta de otro dominio.

El inventario siguiente adapta los parámetros documentados de consulta LDAP de Get-ADObject. El filtro es fijo, los atributos adicionales son explícitos y $null para ResultSetSize evita imponer un límite intencionado al número de resultados.

Import-Module ActiveDirectory
$dc = 'dc01.corp.example'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$base = 'CN=ForeignSecurityPrincipals,' + $root.defaultNamingContext
$fsps = @(Get-ADObject -Server $dc -SearchBase $base -SearchScope Subtree `
    -LDAPFilter '(objectClass=foreignSecurityPrincipal)' `
    -Properties objectSID,memberOf -ResultPageSize 256 `
    -ResultSetSize $null -ErrorAction Stop)
$fsps | Select-Object DistinguishedName,ObjectGUID,objectSID,memberOf

Para un cliente LDAP, la solicitud equivalente utiliza ese contenedor como base de búsqueda, ámbito de subárbol, (objectClass=foreignSecurityPrincipal) como filtro y distinguishedName, objectGUID, objectSid y memberOf como atributos solicitados. Complete la paginación, preserve los atributos multivalor y conserve los fallos por separado de los resultados vacíos. No fabrique cadenas SID a partir de los nombres mostrados.

No continúe con la limpieza si la consulta falla, se interrumpe o la cuenta no puede leer las propiedades necesarias. Un inventario vacío procedente de una lectura completada y un inventario no disponible son resultados diferentes. Para varios dominios, repita la recopilación con el contexto propio de cada dominio y mantenga esos registros separados.

Paso 2: inspeccionar los grupos que utilizan el objeto

La referencia de esquema de Microsoft de memberOf lo identifica como los nombres distintivos de los grupos a los que pertenece el objeto. Trate las referencias devueltas como la lista inicial de grupos que lo utilizan, no como un informe de acceso efectivo. Siga por separado el anidamiento de grupos y las dependencias de recursos antes de juzgar el impacto.

Seleccione un FSP por su DN registrado, no tomando la primera fila. Este ejemplo utiliza los parámetros documentados de identidad y propiedades adicionales de Get-ADGroup para inspeccionar cada grupo devuelto:

$fspDn = Read-Host 'Exact FSP distinguished name from the inventory'
$fsp = Get-ADObject -Identity $fspDn -Server $dc `
    -Properties objectSID,memberOf -ErrorAction Stop
foreach ($groupDn in $fsp.memberOf) {
    Get-ADGroup -Identity $groupDn -Server $dc `
        -Properties member,memberOf,managedBy,description -ErrorAction Stop |
        Select-Object DistinguishedName,GroupScope,GroupCategory, `
            member,memberOf,managedBy,description
}

Compruebe que los valores member del grupo contienen el DN exacto del FSP. Pregunte al responsable del grupo qué aplicación o recurso depende de él, si sigue activa una adquisición o migración y cómo probar el acceso previsto. managedBy y la descripción pueden aportar pistas de contacto; no sustituyen la confirmación de un responsable que asuma la decisión. Un campo de responsable vacío es una tarea de seguimiento, no un permiso para eliminar.

Paso 3: resolver sin convertir los fallos en un veredicto de huérfano

Microsoft documenta SecurityIdentifier.Translate y su IdentityNotMappedException cuando no se pueden traducir las referencias de identidad. Este ejemplo conserva el fallo como evidencia:

$sid = [System.Security.Principal.SecurityIdentifier]$fsp.objectSID
try {
    $account = $sid.Translate([System.Security.Principal.NTAccount])
    [pscustomobject]@{ SID = $sid.Value; Account = $account.Value }
} catch {
    [pscustomobject]@{ SID = $sid.Value; LookupError = $_.Exception.Message }
}

La resolución utiliza el contexto Windows del equipo de administración. No acepta un controlador de dominio socio seleccionado ni demuestra el buen estado de la relación de confianza. Conserve el equipo y el error, identifique el dominio emisor esperado, compruebe la resolución de nombres y la conectividad necesaria con sus administradores y confirme si el SID exacto sigue existiendo allí. Investigue los socios inaccesibles y las relaciones de confianza retiradas antes de usar la palabra huérfano. No debilite la configuración de confianza para conseguir que una resolución funcione.

La documentación de Microsoft de Get-ADTrust proporciona este comando exacto de enumeración:

Get-ADTrust -Filter *

Utilice los objetos de dominio de confianza devueltos como contexto y registre el dominio consultado. Su presencia es evidencia de configuración, no una prueba de conectividad de extremo a extremo ni una prueba de que se resuelva un SID externo concreto. Una vez identificada una identidad externa real, la auditoría de filtrado SID y autenticación selectiva de las relaciones de confianza ofrece la revisión independiente de los controles de confianza.

Si la pregunta es, en cambio, si un destinatario de permisos sin resolver posee un permiso peligroso, utilice la auditoría de ACE peligrosas para destinatarios sin resolver y entre dominios. Esta examina permisos DACL; este inventario clasifica objetos FSP existentes y los grupos que los utilizan. Ninguna revisión sustituye a la otra.

Remediación: retirar solo una referencia cuya inutilidad esté demostrada (Remediation)

Paso 1: aprobar la clasificación y el alcance

Conserve las pertenencias conocidas y externas necesarias. Deje los objetos indeterminados sin cambios mientras sigan abiertas las cuestiones de recopilación, conectividad o responsabilidad. Para una referencia candidata a retirada, conserve el SID exacto, el DN y el GUID del FSP, los DN de los grupos que lo utilizan, la confirmación del socio, la decisión del responsable y las pruebas pertinentes de la aplicación. Acuerde una ventana de cambio y una reversión que pueda restaurar la pertenencia prevista.

Concrete la decisión: ¿qué pertenencia a un grupo es innecesaria, por qué y qué accesos deben continuar después? Si solo un grupo ha retirado su dependencia, elimine únicamente esa pertenencia. Otros grupos todavía pueden necesitar el mismo objeto de representación. No convierta la eliminación del objeto en el primer paso de una revisión de pertenencias.

Paso 2: previsualizar un cambio de pertenencia aprobado

La documentación de Microsoft de Set-ADGroup permite eliminar un valor concreto de una propiedad por su nombre para mostrar LDAP, además de usar WhatIf y la confirmación. Este ejemplo adaptado apunta a un único DN member en un controlador de dominio con capacidad de escritura:

$groupDn = Read-Host 'Exact approved consuming group distinguished name'
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop
Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} -WhatIf

Revise primero el destino y la pertenencia guardada. WhatIf previsualiza la operación; no prueba el acceso de la aplicación ni garantiza que una escritura posterior vaya a funcionar. Solo después de que el responsable apruebe esta eliminación exacta, ejecute el cambio individual con confirmación y vuelva a leer el grupo:

Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} `
    -Confirm:$true -ErrorAction Stop
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop

Paso 3: validar el acceso antes de una limpieza opcional del objeto

Confirme que cambió la pertenencia aprobada, tenga en cuenta la replicación y el contexto de autenticación del entorno y pida al responsable de la aplicación que verifique tanto el acceso previsto como la dependencia retirada. Una escritura satisfactoria no es una prueba de acceso. Registre los resultados reales en el registro de cambios en lugar de declarar el éxito por una reducción del recuento del inventario.

Recopile de nuevo la pertenencia del FSP e investigue las dependencias restantes. Un memberOf vacío no demuestra por sí solo que un SID no se use en ACL de recursos o en la configuración de aplicaciones. Si se demuestra que el propio objeto es innecesario, su limpieza es una acción independiente y explícitamente aprobada. La referencia de Microsoft de Remove-ADObject documenta la eliminación de un único objeto; previsualice el GUID registrado solo después de esas comprobaciones:

Remove-ADObject -Identity $fsp.ObjectGUID -Server $dc -WhatIf

Esta previsualización no realiza ninguna eliminación. No la convierta en una canalización sobre el contenedor ni elimine el propio contenedor. Mantenga juntas la decisión de limpieza, el plan de restauración y la verificación final del acceso.

Cómo detecta EtcSec este caso

El control FOREIGN_SECURITY_PRINCIPALS de EtcSec informa de DomainInfo.ForeignSecurityPrincipalsCount. El método Detect() revisado inicializa el recuento a cero, copia el campo cuando existe DomainInfo y devuelve un hallazgo de gravedad Medium que contiene ese recuento. Por tanto, la ausencia de DomainInfo produce cero. Los detalles para un recuento positivo añaden una salvedad, no evidencia por objeto ni una clasificación de SID.

El proveedor LDAP realiza una búsqueda paginada de subárbol bajo CN=ForeignSecurityPrincipals,<baseDN> con (objectClass=foreignSecurityPrincipal). Solicita únicamente distinguishedName y asigna el número de entradas devueltas cuando la búsqueda tiene éxito. Un error de búsqueda deja el campo en su valor inicial de cero. Este campo no expone ningún indicador de éxito de recopilación que permita distinguir ese fallo de un resultado vacío obtenido correctamente.

El control no expone SID individuales, memberOf, responsables, nombres resueltos, conectividad de confianza ni permisos efectivos. Su recuento mezcla objetos de representación conocidos y referencias externas reales. No puede identificar un huérfano, contar relaciones de confianza, demostrar exposición entre bosques ni establecer que cero significa un inventario limpio. La recopilación y clasificación independientes anteriores aportan la evidencia necesaria para tomar una decisión. Este procedimiento no incluye ninguna eliminación automática.

El texto explicativo del recolector también generaliza la creación de objetos de representación a las referencias en ACL. La fuente histórica de Microsoft utilizada aquí establece el caso member; esa formulación más amplia no se repite como una regla verificada. Trate el hallazgo como una invitación a inspeccionar los objetos subyacentes y sus dependencias y, después, conserve o cambie solo lo que respalde la evidencia.