Censo de hijos directos de OU AD: verificar antes de reestructurar

Qué establece un censo de hijos directos de OU AD

Un censo de hijos directos de OU AD registra qué objetos están inmediatamente debajo de una unidad organizativa concreta. Antes de reestructurarla, úselo para responder a una pregunta acotada: ¿qué contiene esta OU en este nivel, en la vista del directorio que realmente hemos leído? Mantenga un inventario independiente de la jerarquía inferior. Un recuento de hijos directos sirve para planificar, pero un contador aparentemente vacío nunca debe convertirse en una decisión automática de eliminación.

Esta guía se revisó el 4 de octubre de 2026 con Microsoft Learn y la revisión del recopilador identificada más abajo. Ofrece un procedimiento de conciliación para administradores que revisan un inventario de OU. Los comandos PowerShell son ejemplos documentales para el lector, adaptados de la sintaxis documentada de los parámetros; no se ejecutaron contra un dominio AD para este artículo. No se afirma que haya habido una recopilación satisfactoria, una OU de producción vacía ni un cambio completado.

El problema práctico es la discrepancia entre la etiqueta de un contador y su población. Un informe puede mostrar Users, Computers, Groups y OUs mientras el revisor supone que describe todos los objetos bajo la OU. También puede omitir objetos por límites de recopilación, exclusiones o una comparación del DN del padre. Conserve esos límites antes de utilizar el informe en una solicitud de cambio.

Funcionamiento: separar los recuentos de un nivel de la jerarquía

La referencia de Get-ADObject de Microsoft distingue OneLevel, que busca hijos inmediatos, de Subtree, que incluye la base y los descendientes. SearchBase establece la ruta de destino y Server selecciona la instancia del directorio. Especifique ambos al generar pruebas.

Prepare dos registros para el mismo destino: un inventario de hijos directos para la población local y un inventario del subárbol para las dependencias más profundas de la jerarquía. Etiquete sus ámbitos explícitamente. No compare la suma de los contadores de clases de hijos directos con un total de subárbol sin precisar su alcance. Una OU que contiene otra OU puede tener pocas identidades directas mientras la jerarquía subordinada contiene los objetos relevantes para el cambio.

Para cada inventario, conserve los identificadores de objetos, los DN originales, la clase, el contexto de recopilación y el estado de finalización. Mantenga la lista de objetos sin procesar junto a cualquier recuento resumido para investigar una discrepancia sin adivinar qué objetos contribuyeron. Una lista también permite separar una clase inesperada de una relación con el padre inesperada.

Decidir qué significan las etiquetas de clase

Trate Users, Computers, Groups y OUs como cuatro poblaciones del recopilador, no como una garantía de haber leído todas las clases del directorio. Defina las consultas independientes antes de compararlas. Registre las demás clases devueltas por separado; no las integre silenciosamente en Users ni las ignore porque el panel no tenga un contador correspondiente.

La población de usuarios LDAP revisada incluye una rama de cuentas de servicio administradas de grupo en su filtro predeterminado. Por tanto, la consulta de usuarios de categoría person siguiente y el conjunto Users del recopilador pueden diferir aunque ambas lecturas se completen. Compare las definiciones reales de los filtros y los identificadores de objetos devueltos. Mantenga visibles las subclases de cuentas de servicio y cualquier otra clase sin correspondencia en el registro de conciliación, en lugar de forzar una coincidencia numérica.

Nuestra guía de contenedores predeterminados y ámbito de la directiva de grupo explica por qué los destinos predeterminados y el ámbito de directiva previsto necesitan una revisión independiente de la ubicación. Su ejemplo OneLevel realiza un inventario de los equipos del contenedor Computers predeterminado. No proporciona un censo de las cuatro poblaciones de una OU, no abarca todas las clases ni resuelve el problema de los DN con caracteres de escape tratado aquí.

Detección: leer los objetos antes de comparar los contadores

1. Establecer el contexto de las consultas

Seleccione la OU aprobada y un servidor de directorio explícito. Registre el contexto de lectura del operador, las horas de inicio y finalización, la base de búsqueda, el ámbito, el filtro de clase y cualquier error. Utilice un equipo de administración autorizado con el módulo AD PowerShell. El DN de OU siguiente aparece en el ejemplo 5 de la referencia de Get-ADObject; el nombre del servidor es un FQDN ficticio de ejemplo. Sustituya ambos por el destino revisado.

Los ejemplos siguientes adaptan los parámetros documentados Filter, LDAPFilter, SearchBase, SearchScope, Server y Properties de Get-ADObject. Solicitan identificadores para la conciliación. Guarde los objetos devueltos y el resultado de la operación mediante su flujo de administración antes de calcular un resumen.

Primero lea la población directa sin restringir la clase:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Utilice esta lista para descubrir las clases que los cuatro contadores no describen. El inventario sigue limitado por la vista seleccionada y el contexto de lectura. Si falla o termina antes de tiempo, conserve ese resultado; los objetos ya mostrados no prueban que el censo esté completo.

2. Mantener separadas las consultas de clase

Estos ejemplos para el lector definen poblaciones de revisión independientes; no reproducen todos los filtros del recopilador. El primero combina objectClass=user con objectCategory=person, como documenta Microsoft en su guía para consultar usuarios. Un filtro solo de clase user también coincide con equipos porque la clase computer deriva de user:

Get-ADObject -LDAPFilter '(&(objectClass=user)(objectCategory=person))' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "computer"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "group"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "organizationalUnit"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Mantenga identificables por separado las cuatro salidas. Registre si cada consulta se completó y compare su conjunto de objetos con la lista OneLevel sin restricciones. Si aparece otra clase, añada una población de revisión con una etiqueta independiente. Si un conjunto del recopilador utiliza un filtro más amplio, documente la población adicional antes de conciliar su recuento.

3. Leer el subárbol como una prueba diferente

Utilice una operación independiente para la jerarquía:

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope Subtree -Server 'dc01.fabrikam.com' -Properties objectGUID

Etiquete esta salida como Subtree y distinga la OU base de los objetos situados debajo. Revise las OU subordinadas y su contenido con sus responsables. No sume este total a los contadores de hijos directos ni lo describa como una segunda medición de la misma población.

4. Conciliar los identificadores y los DN con caracteres de escape

Learn documenta objectGUID como identificador aceptado por Get-ADObject. Úselo como clave de comparación en los inventarios independientes y conserve el DN como prueba de ubicación. Cuando la carga útil del recopilador no tenga GUID, resuelva su DN registrado en el mismo contexto y conserve la vinculación; no invente un identificador ni establezca correspondencias solo por el nombre mostrado.

La referencia de nombres distinguidos de Microsoft explica que los RDN se separan con comas y que una coma dentro del valor de un atributo debe llevar un carácter de escape. Por ello, una coma sin interpretar no basta para decidir dónde termina un nombre y comienza su padre.

Por ejemplo, Learn proporciona este DN con una coma escapada en el RDN de la OU:

CN=Litware,OU=Docs\, Adatum,DC=Fabrikam,DC=COM

Prefiera el resultado OneLevel del directorio al establecer la relación inmediata con el padre. Si debe procesarse localmente una exportación, utilice un analizador de DN que gestione los caracteres de escape y conserve la cadena original. No divida por todas las comas ni elimine las barras inversas antes de decidir la relación con el padre.

Conciliar el censo antes de reestructurar (Remediation)

1. Precisar cada observación

Utilice el registro de conciliación para decidir qué está establecido y qué sigue abierto. Una discrepancia es motivo para investigar el ámbito, los filtros, los identificadores o la recopilación, en lugar de alterar objetos hasta que los recuentos coincidan.

Adjunte esta clasificación a la OU y a la clase concretas. Una etiqueta de fila completa como «vacía» pierde la distinción entre un cero de clase verificado y una lectura de clase ausente. Si distintas consultas se completaron en momentos diferentes, conserve esa diferencia en lugar de presentarlas como una única instantánea simultánea.

2. Explicar las diferencias antes de cambiar la jerarquía

Compare primero los objetos individuales y después los totales. Registre si cada diferencia procede de otra clase, un descendiente más profundo, una exclusión, un filtro, una recopilación incompleta o una correspondencia con el padre sin resolver. Mantenga abiertas las diferencias sin explicación, con un revisor responsable y las pruebas necesarias para resolverlas.

Utilice el mismo servidor y contexto de destino para la primera conciliación. Si la revisión incluye otro servidor, etiquete su inventario de forma independiente. Una diferencia entre vistas exige investigación; este procedimiento no permite adivinar un resultado de replicación ni tratar un recuento conveniente como autoritativo.

Documente las exclusiones del recopilador y los límites de recopilación junto a las lecturas independientes. Mantenga separado un censo administrativo sin restricciones de un subconjunto alineado deliberadamente con las entradas del recopilador. Un objeto excluido sigue siendo relevante para la reestructuración aunque no contribuya a un contador filtrado.

3. Conservar la responsabilidad y las protecciones contra la eliminación

Entregue al responsable el registro de objetos, la revisión del subárbol, las diferencias sin resolver y el ámbito propuesto. Obtenga una decisión sobre el destino exacto y sus dependencias. Un nombre de OU, un recuento pequeño o un campo vacío del panel no identifica quién puede aprobar un traslado o una limpieza.

Siga la guía complementaria de revisión independiente de permisos y decisión del responsable antes de limpiar una OU. Esa guía aborda las protecciones contra la eliminación y las excepciones acotadas. Mantenga esa revisión en el proceso de cambio; este censo no evalúa los permisos correspondientes ni autoriza retirar la protección.

Antes de aprobar la reestructuración, identifique las consecuencias previstas para las directivas y la administración de los objetos afectados. Mantenga la ubicación en contenedores predeterminados y el ámbito de GPO en la revisión de ubicación, y las protecciones contra la eliminación en la revisión complementaria de permisos. El censo aporta la población de objetos de la que dependen esas decisiones.

4. Verificar el resultado aprobado

Después de un cambio autorizado, repita las lecturas OneLevel y Subtree pertinentes con el contexto de destino registrado. Concilie los objetos conservados por identificador y registre sus ubicaciones actuales. Conserve la decisión del responsable y el resultado real de la operación junto a las pruebas anteriores y posteriores.

Cierre la tarea de inventario cuando las poblaciones acordadas y las incertidumbres restantes estén documentadas. Cierre la tarea de cambio según sus propios criterios de resultado, incluida la revisión complementaria de protecciones. Un recuento que parezca más limpio no basta para demostrar que se abordaron las dependencias, el ámbito de las directivas y la protección de los objetos conservados.

Cómo detecta esto EtcSec

Esta sección describe únicamente INFO_DOMAIN_OU_INVENTORY, revisado en el commit afca1b9f7bba6f076d6a6493371486071001452b de etc-collector. El detector pertinente es public/internal/audit/detectors/ad/permissions/organization/ou-inventory.go:31.

Su método Detect() emite un hallazgo Info con Count=1 por cada OU recopilada. Ese recuento identifica una entrada del inventario, no el número de hijos ni un veredicto de vulnerabilidad. No devuelve hallazgos cuando la entrada de OU está vacía. Los detalles de las entidades afectadas solo se rellenan cuando IncludeDetails está habilitado; la ausencia de detalles no demuestra la ausencia de hijos.

El método GetOUs del proveedor LDAP, en public/internal/providers/ldap/client.go:946, lee las unidades organizativas mediante su función auxiliar de búsqueda de subárbol. Una recopilación de OU por subárbol no convierte los contadores de hijos emitidos en recuentos de descendientes ni demuestra una integridad universal.

En public/internal/audit/gpo_policy.go:365–436, OUEntity construye ChildCounts a partir de las matrices Users, Computers, Groups y OUs proporcionadas. La función auxiliar solo cuenta hijos inmediatos. Las exclusiones de activos aplicadas antes de la detección afectan a esas poblaciones; las demás clases del directorio no constituyen un quinto contador de todos los objetos. El recuento debe interpretarse según lo que realmente se recopiló.

La prueba del padre comprueba un sufijo de OU sin distinguir mayúsculas de minúsculas y después rechaza una parte inicial que contenga cualquier coma. Inferencia estática: una coma escapada en el RDN inicial puede hacer que se omita un verdadero hijo directo. Esto se deriva del predicado de cadena revisado y del escape de DN documentado; no se demostró aquí ejecutando una prueba de dominio.

Por último, OUEntity inicializa Delegations como una matriz vacía provisional, porque la conexión de delegaciones DACL de OU no se rellena en esta ruta. No aporta pruebas de ausencia de derechos delegados. Utilice el inventario para seleccionar y conciliar OU; establezca el contenido, los permisos y el resultado aprobado de la reestructuración mediante las pruebas independientes descritas anteriormente.