🏢Active DirectoryComputers

Inventario de controladores de dominio AD: conciliar metadatos FSMO

Concilie las identidades de los DC y los titulares FSMO. Aclare los metadatos vacíos y compruebe el estado de la replicación por separado.

Younes AZABARPor Younes AZABAR11 min de lectura
Inventario de controladores de dominio AD: conciliar metadatos FSMO

Qué establece un inventario de controladores de dominio AD

Un inventario de controladores de dominio AD debe identificar los DC incluidos en el alcance y explicar de dónde procede cada entrada. Los nombres, sistemas operativos, sitios, indicadores de solo lectura, roles FSMO y asociados de replicación configurados ayudan al operador a comprender el directorio. Por sí solos, no demuestran que un DC sea accesible, que se hayan recopilado todos los DC esperados ni que los cambios del directorio se estén replicando correctamente.

La revisión práctica consiste en conciliar la instantánea del recopilador con lecturas independientes del directorio, conservando el dominio, el servidor consultado, los contextos de nomenclatura y los errores de recopilación. Una lista FSMO vacía debe seguir distinguiéndose de una lectura correcta que muestre que ese DC concreto no posee ningún rol. Del mismo modo, un asociado configurado aporta información de topología, no un resultado de replicación satisfactorio.

Esta guía se contrastó con Microsoft Learn y el código fuente de etc-collector el 4 de octubre de 2026. Los comandos son ejemplos documentados de inspección de solo lectura o adaptaciones de sintaxis documentadas. No se ejecutaron en el directorio de un cliente. El procedimiento siguiente propone una revisión de evidencias; no es el informe de un incidente observado.

Cómo afectan al resultado el alcance y los metadatos opcionales

Empiece por el registro de recopilación, no solo por la visualización. Identifique el dominio solicitado, el punto de conexión LDAP, el BaseDN, el contexto de la cuenta, la hora de recopilación y las exclusiones. Conserve los contextos de nomenclatura realmente utilizados en las lecturas, incluido el contexto de configuración empleado para el enriquecimiento. Una etiqueta de dominio sin el servidor ni el contexto de búsqueda no basta para explicar por qué difieren dos exportaciones.

En el recopilador inspeccionado, los DC se derivan de los objetos de equipo recopilados tras aplicar las exclusiones. El proveedor de metadatos enriquece esa lista suministrada. Esto implica que un asociado que no pueda vincularse con la lista de DC suministrada puede omitirse del campo de asociados resultante. Por tanto, una matriz vacía puede describir una correspondencia incompleta, en lugar de una ausencia de objetos de conexión.

El proveedor también construye su base de búsqueda de configuración anteponiendo CN=Configuration, al BaseDN. Al revisar una recopilación de un dominio secundario, compare ese contexto construido con el contexto real de configuración del bosque utilizado en su inspección independiente del directorio. La posible discrepancia de alcance es una inferencia estática a partir del código, no un fallo reproducido en el bosque de un cliente. Conserve el contexto y el resultado de búsqueda antes de decidir si explican un campo ausente.

Un registro de revisión útil vincula cada identificador de DC con su origen y un estado de lectura explícito. Los estados propuestos son lectura correcta, no recopilado, lectura fallida y aún no verificado. Son etiquetas del procedimiento, no valores emitidos por el detector. No convierta silenciosamente ninguno de los tres últimos estados en una lista vacía ni en un indicador falso.

Campo de inventarioEvidencias que compararConclusión que evitar
Nombre y dominio del DCEnumeración independiente correcta para el dominio indicadoUna lista recopilada cubre todos los dominios del bosque
Roles FSMOPropiedades de rol de cada DC y titulares de los roles del dominio y del bosqueUn campo vacío demuestra que un rol no tiene titular
Indicador RODCPropiedades independientes del DC y estado de recopilaciónUn valor predeterminado es una evaluación verificada de que el DC permite escritura
SitioPropiedades del DC en el directorio y correspondencia de sitios previstaUn nombre de sitio demuestra una replicación satisfactoria
Asociados de replicaciónEvidencias de configuración, con una lectura independiente del estado de replicaciónUna conexión configurada demuestra que la replicación funciona actualmente

Detección: conciliar los DC y los titulares FSMO de forma independiente

1. Enumerar el dominio previsto

Utilice un equipo de administración con el módulo PowerShell ActiveDirectory y una cuenta autorizada para leer los datos pertinentes del directorio. La referencia de Get-ADDomainController de Microsoft documenta el conjunto de parámetros Filter y -Server. La adaptación siguiente solicita los DC a un servidor de directorio nombrado explícitamente; sustituya el nombre de host ilustrativo por el servidor verificado de su dominio:

Get-ADDomainController -Filter * -Server "dc01.contoso.com"

Registre el servidor que realmente consultó junto con los objetos devueltos y los errores. Compare los identificadores y la pertenencia al dominio con las entradas del recopilador antes de examinar las diferencias de enriquecimiento. Conserve los objetos ausentes de cualquiera de las exportaciones como discrepancias que investigar, incluida cualquier exclusión conocida que explique una diferencia.

La referencia distingue la recuperación mediante Filter o Identity de la detección de DC. Una llamada de detección encuentra un DC que satisface sus criterios; no enumera todos los DC. Para una revisión de todo el bosque, mantenga resultados separados por dominio. La referencia de Get-ADForest incluye la enumeración a través de la colección Domains del bosque. No presente una exportación correcta de un solo dominio como cobertura completa del bosque.

2. Leer los roles de cada DC y contrastar después la titularidad del dominio y del bosque

La página de administración de roles FSMO de Microsoft proporciona este ejemplo exacto de inspección del dominio actual:

$domainControllers = Get-ADDomainController -Filter *
foreach ($dc in $domainControllers) {
    Write-Output "Name: $($dc.Name)"
    Write-Output "OperationMasterRoles:"
    foreach ($role in $dc.OperationMasterRoles) {
        Write-Output "- $role"
    }
}

Como ese ejemplo utiliza el contexto de conexión predeterminado, regístrelo explícitamente. Para preparar una comparación controlada, prefiera la enumeración anterior con servidor explícito. Conserve los objetos DC completos devueltos, además del resumen de roles, para que una decisión de formato no oculte la identidad de origen.

La documentación de Get-ADDomain expone PDCEmulator, RIDMaster e InfrastructureMaster. La salida de Get-ADForest expone SchemaMaster y DomainNamingMaster. Estas adaptaciones de solo lectura utilizan sus parámetros Identity y Server documentados:

Get-ADDomain -Identity "contoso.com" -Server "dc01.contoso.com"
Get-ADForest -Identity "contoso.com" -Server "dc01.contoso.com"

Sustituya el dominio y el bosque previstos de forma independiente; no tienen por qué compartir el mismo nombre DNS. Guarde la salida completa, incluida la identidad del dominio devuelta y su pertenencia al bosque. Compare cada titular con las propiedades de rol de cada DC y con los metadatos del recopilador. Un titular de rol del bosque fuera de una recopilación de dominio secundario plantea una cuestión de alcance, no demuestra que falte un rol.

3. Conservar los desacuerdos y los datos no leídos

Para cada discrepancia, adjunte ambas salidas, sus horas de recopilación, las identidades de los servidores y los resultados de lectura. Una lectura independiente correcta que identifique a otro titular puede explicar por qué un DC no tiene ningún rol. Una lectura fallida no puede hacerlo. Si las lecturas con servidor explícito discrepan, conserve ambas en vez de elegir la que dé al inventario una apariencia completa.

Asigne un responsable para investigar el contexto de recopilación y cualquier incoherencia del directorio. La cuestión inmediata sobre las evidencias es si el valor ausente refleja el alcance, una exclusión, metadatos no leídos o un estado verificado del directorio. Esa cuestión debe resolverse antes de planificar un cambio en AD.

Corregir las evidencias antes de cambiar el directorio (Remediation)

1. Resolver las lagunas de recopilación y repetir la comparación

Revise el punto de conexión registrado, el BaseDN del dominio, el contexto de configuración, las exclusiones y los permisos con el responsable del directorio. Corrija un problema confirmado de contexto de recopilación mediante el proceso de configuración admitido por el recopilador. Conserve juntos la instantánea original, el motivo de la corrección y los nuevos resultados de lectura.

Repita la enumeración de DC con alcance definido y los comandos de inspección del dominio y del bosque anteriores. Compare de nuevo los mismos identificadores y propiedades de rol. Si los metadatos siguen sin leerse, deje visible ese estado y asigne la investigación pendiente; rellenar manualmente el campo del informe destruiría la distinción entre una lectura del directorio y una suposición del operador.

Un registro de aceptación debe indicar qué dominio se concilió, qué DC siguen sin explicación, qué titulares de rol se leyeron de forma independiente y qué campos siguen siendo desconocidos. Trate un DC excluido como excluido, en vez de informar de que está ausente del directorio. Repetir una recopilación correctamente aporta evidencias útiles, pero no amplía su alcance más allá de los dominios y contextos realmente consultados.

2. Comprobar la replicación como un control independiente

La guía de solución de problemas de replicación de Microsoft documenta este comando exacto desde un símbolo del sistema con privilegios elevados:

repadmin /showrepl * /csv > showrepl.csv

El procedimiento documentado requiere pertenecer a Enterprise Admins o disponer de derechos equivalentes. Siga el proceso de diagnóstico autorizado de la organización. Conserve el CSV y los errores del comando. Revise los asociados de origen, los contextos de nomenclatura, la información del último resultado satisfactorio y los fallos por separado de la lista de asociados configurados del inventario.

La misma guía identifica el registro de eventos Directory Service y la salida de Repadmin como evidencias para solucionar problemas. Utilice el texto real del error para investigar un resultado de diagnóstico fallido. Una conexión incluida en un inventario no responde a esas cuestiones de estado, y un destino de diagnóstico inaccesible sigue sin resolverse aunque otros DC hayan devuelto resultados.

Registre el alcance y el resultado de la comprobación de replicación en su propio registro de evidencias. No sustituya el campo de asociados configurados por un veredicto sobre su estado ni considere correctas todas las conexiones porque una consulta haya funcionado. Este artículo de inventario no prescribe cambios de topología ni operaciones de recuperación a partir de una laguna de metadatos.

3. Vincular el inventario con sus limitaciones documentadas a la planificación de topología y recuperación

Utilice la información de sitios verificada junto con la selección de DC por los clientes y la correspondencia entre subredes y sitios. Esa revisión concilia la topología del directorio con las redes reales de los clientes y las observaciones de detección. Un nombre de sitio inventariado no demuestra por sí solo ni una selección adecuada por los clientes ni un buen estado de replicación.

Proporcione el registro conciliado de DC y titulares de rol como entrada para la planificación de la recuperación del bosque y la validación de copias de seguridad. La preparación de la recuperación requiere DC y roles conocidos, pero también la selección de copias de seguridad, evidencias de restauración y un procedimiento específico del entorno. Una exportación de inventario no valida una restauración ni establece que el estado del directorio recuperado sea fiable.

Cómo detecta esto EtcSec

El etc-collector de EtcSec emite INFO_DOMAIN_CONTROLLER como hallazgo de inventario. La implementación inspeccionada de dc-inventory.go produce un hallazgo Info con Count 1 por cada DC recopilado. No devuelve hallazgos cuando la lista de DC suministrada está vacía. Ese comportamiento no es un veredicto de vulnerabilidad ni demuestra que un directorio sin entradas devueltas carezca de DC.

Las entidades afectadas detalladas solo se adjuntan con IncludeDetails. Contienen los campos básicos de identidad del equipo y del sistema operativo, con roles FSMO, estado RODC, sitio y asociados de replicación opcionales. La ausencia de enriquecimiento deja matrices vacías o valores predeterminados. Quienes consuman esos datos deben determinar qué significan esos valores antes de tratarlos como observaciones negativas obtenidas correctamente.

El método GetDCMetadata del proveedor LDAP lee objetos de titularidad de roles y la configuración NTDS/de conexión. Los errores de búsqueda FSMO o los resultados vacíos se omiten. Un error de búsqueda NTDS deja sin rellenar los campos de sitio y asociados, mientras que el indicador RODC y los roles ya leídos siguen disponibles; los errores de búsqueda de conexiones se ignoran. Los identificadores de los asociados se vinculan con la lista de DC suministrada. El motor también asigna DCInfo únicamente cuando la llamada de metadatos tiene éxito.

Estas son limitaciones observadas en el código fuente en el commit afca1b9f7bba6f076d6a6493371486071001452b, no fallos reproducidos en clientes. La comprobación no prueba el estado de la replicación, no mide ningún intercambio satisfactorio de cambios ni toma decisiones sobre la preparación para la recuperación. Utilícela para mostrar los activos DC recopilados y, después, determine la cobertura y el significado de los metadatos opcionales con las lecturas independientes descritas anteriormente.

Explore las páginas de identidad que apoyan este tema