Sitios y subredes AD: verificar la selección del DC

Sitios y subredes AD: qué verificar antes de cambiar la topología

La revisión de sitios y subredes AD debe responder a una pregunta práctica: ¿un cliente representativo identifica el sitio de Active Directory previsto y descubre un controlador de dominio adecuado? Un sitio sin objetos de servidor recopilados y un sitio sin objetos de subred asociados son puntos de partida útiles para investigar. Ninguno de esos resultados demuestra por sí solo un ataque ni determina qué cambio de configuración está justificado.

Esta guía se contrastó con Microsoft Learn y la implementación de etc-collector el 3 de octubre de 2026. Los comandos siguientes son ejemplos documentados de inspección y configuración; no se ejecutaron en un dominio de un cliente. Utilice su inventario de red, los resultados del directorio y las observaciones de los clientes para establecer la causa antes de cambiar una asociación.

Una sucursal puede carecer deliberadamente de un DC local. A la inversa, un sitio puede tener un objeto de subred mientras otras redes reales de clientes siguen sin declarar. Distinga estos casos: un recuento de objetos del directorio no comprueba la cobertura de red ni el éxito de la autenticación.

Cómo la asociación al sitio afecta a la selección del DC y a la replicación

La documentación de Microsoft sobre DC locator describe el descubrimiento mediante Netlogon, anuncios DNS y respuestas LDAP UDP. Durante la negociación, un DC identifica el sitio del cliente a partir de su subred IP. Si el primer DC está fuera del sitio adecuado, la información devuelta sobre el sitio del cliente puede provocar otra búsqueda específica de ese sitio. El descubrimiento también utiliza información en caché; un único DC devuelto es una observación de esa solicitud, no un historial completo de la autenticación de las aplicaciones.

Una subred de cliente sin asociación deja incompleta la selección del sitio y puede conducir a un DC fuera de la ubicación prevista. Esto justifica investigar la dirección real del cliente y su asociación, en vez de suponer que todos los clientes eligen un DC al azar. Un DC remoto también puede ser el servicio previsto para una sucursal que no tenga uno local.

Los conceptos de replicación de Microsoft distinguen los objetos de subred, que asocian direcciones de red con sitios, de los vínculos de sitio y los objetos de conexión usados para la replicación. El objeto de servidor de un DC tiene un objeto secundario NTDS Settings que representa al DC que replica. El KCC crea las conexiones de replicación; los vínculos de sitio describen las rutas lógicas y los costes de replicación.

En esta revisión, mantenga dos preguntas separadas. El descubrimiento del cliente determina qué DC puede localizar una máquina desde su red actual. El diseño de replicación determina cómo intercambian los DC los cambios del directorio. Una asociación correcta del cliente con el sitio no demuestra que la replicación funcione correctamente, y una replicación satisfactoria no demuestra que todas las redes de clientes tengan la asociación al sitio prevista.

La guía de seguridad de zonas DNS AD trata las transferencias, las actualizaciones dinámicas y los permisos de los registros. Estos controles de los datos de resolución complementan la investigación, pero no definen la asociación de subredes a sitios. Investigue DNS cuando falle el descubrimiento, manteniendo separadas las pruebas de topología.

Detección: conciliar el inventario del directorio con las observaciones de los clientes

1. Establecer qué devolvieron realmente las consultas al directorio

Utilice un equipo de administración con el módulo PowerShell ActiveDirectory y una cuenta autorizada a leer los objetos de configuración pertinentes. Las referencias de Microsoft documentan Get-ADReplicationSubnet y Get-ADReplicationSite. Los siguientes ejemplos de solo lectura solicitan los objetos y sus propiedades:

Get-ADReplicationSubnet -Filter * -Properties *
Get-ADReplicationSite -Filter * -Properties *

Registre el servidor de directorio consultado, el contexto de la cuenta, el éxito de la consulta y la hora de recopilación junto con los resultados. Examine los nombres de las subredes y sus asociaciones Site, y compare después el sitio asociado con el nombre distintivo del sitio. No convierta un error de acceso o una exportación incompleta en la conclusión de que los objetos no existen.

Concilie esa exportación con el inventario actual del equipo de red: redes de sucursales, redes de oficinas, rangos de clientes VPN y otras redes desde las que se conectan realmente los clientes del dominio. Para cada rango pertinente, identifique el sitio esperado y el responsable que puede confirmarlo. Esta comparación es un paso de revisión manual; los dos controles de EtcSec que se explican más abajo no la realizan.

Empiece con un conjunto pequeño y representativo de clientes que incluya las redes relacionadas con el hallazgo. Registre la dirección activa y el contexto de conexión de cada observación. Un portátil probado en una oficina y el mismo portátil probado mediante una VPN son observaciones de red diferentes. Conserve el sitio esperado y el motivo de esa expectativa antes de comparar la salida de los comandos.

2. Observar la pertenencia al sitio y el resultado de DC locator

La página de Microsoft para solucionar problemas de sincronización del directorio documenta estos comandos para comprobar a qué sitio pertenece un equipo y localizar un DC. Sustituya el dominio del ejemplo por su dominio DNS real:

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Lea el sitio obtenido, el DC seleccionado y los campos Our Site Name y DC Site Name cuando se devuelvan. Conserve los fallos como tales, incluido su texto de error. Un resultado de sitio no disponible requiere investigación; no demuestra que el cliente pertenezca a la oficina geográficamente más cercana.

Para comparar deliberadamente un nuevo descubrimiento, la referencia de Nltest documenta /force como forma de evitar la información de descubrimiento en caché:

nltest /dsgetdc:contoso.com /force

Conserve ambos resultados en lugar de sobrescribir la primera observación. Compare el sitio del cliente indicado con la asociación esperada y el sitio del DC con el diseño documentado de la sucursal. Si difieren, investigue la asociación, el descubrimiento y la excepción WAN prevista antes de editar nada. Estos comandos ejercitan el descubrimiento; valide por separado el comportamiento de la aplicación afectada si una queja de autenticación motivó la revisión.

3. Correlacionar las pruebas de clientes sin asociación

Microsoft documenta el evento NETLOGON 5807 en Respuesta demorada del DC a solicitudes LDAP o Kerberos. El evento describe conexiones desde direcciones de clientes que no corresponden a sitios existentes. Esa página identifica %SystemRoot%\debug\netlogon.log y su archivo de rotación .bak como ubicaciones de los nombres y direcciones de clientes, con NO_CLIENT_SITE: para identificar las entradas pertinentes.

Cuando estén presentes este evento o sus entradas de registro asociadas, concilie las direcciones observadas con el inventario de red y las subredes declaradas. Compruebe qué conexión produjo la dirección antes de asignarla a un sitio. La ausencia de este evento no sustituye la comparación con el inventario, y su presencia no identifica a un atacante.

Corrección: arreglar la asociación o documentar la excepción prevista (Remediation)

1. Resolver primero la incertidumbre del inventario

Antes de editar la topología, concilie la instantánea del recopilador con lecturas satisfactorias del directorio. Si falló la enumeración de servidores o subredes, investigue el contexto de recopilación y repita el inventario. No despliegue un DC, elimine un sitio ni invente una subred solo para borrar una ausencia aparente producida por una consulta fallida.

Para un sitio sin DC local, pregunte a los responsables del dominio y de la red si es deliberado. Documente la ubicación del DC que presta el servicio, la dependencia WAN esperada, el responsable y el desencadenante de revisión. Conserve esa excepción junto con las observaciones de los clientes para que otro revisor pueda comprender por qué allí es aceptable el descubrimiento entre sitios.

2. Corregir una asociación ausente o errónea confirmada

Identifique la red real de clientes y el sitio existente que debe representarla. Revise la asociación propuesta con el responsable de red, incluidas otras redes que podrían verse afectadas. Una definición de subred debe expresar el diseño de red acordado, no limitarse a copiar la dirección de la primera máquina que produjo un error.

Para una subred realmente ausente, Microsoft documenta este ejemplo de creación en New-ADReplicationSubnet:

New-ADReplicationSubnet -Name "10.10.0.0/22" -Site Asia -Location "Tokyo,Japan"

Se trata de la red y el sitio ilustrativos de Microsoft, no de una configuración propuesta para su entorno. Sustituya por una red verificada y un sitio existente previsto solo después de comprobar que el objeto de subred realmente falta. Para un objeto existente con la asociación equivocada, corrija su asociación Site en Active Directory Sites and Services mediante su proceso habitual de cambios. Conserve los valores originales y la sustitución aprobada en el registro del cambio.

Si un servidor está realmente retirado, siga las recomendaciones separadas de higiene de objetos DC y limpieza de metadatos. Confirme su retirada antes de la limpieza. Una lista vacía de servidores recopilados no demuestra que deba eliminarse un DC activo, y añadir o quitar objetos de servidor no sustituye la corrección de la asociación de subredes de clientes.

3. Volver a comprobar los clientes representativos y conservar las pruebas

Repita el inventario del directorio y los comandos de descubrimiento del cliente después de que el cambio sea visible en el servidor de directorio utilizado para la validación. Pruebe las mismas redes representativas, incluidos los casos previstos de servicio remoto. Registre el sitio esperado, el sitio observado, el DC devuelto y la excepción restante para cada cliente.

Vuelva a comprobar el flujo de la aplicación que motivó la investigación y revise por separado la replicación si cambió la topología. La desaparición de un hallazgo de inventario confirma de forma útil los objetos recopilados, pero no demuestra que todas las redes o aplicaciones utilicen ya la ruta deseada.

Cómo detecta EtcSec estas situaciones

La implementación de etc-collector de EtcSec evalúa dos controles Network sobre el inventario recopilado de sitios y subredes:

• SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 recorre data.Sites y recoge cada sitio cuyo len(site.Servers) == 0. Devuelve un hallazgo cuyo Count es el número de esos sitios, con sus nombres en sitesWithoutDc. Cuando el recuento es positivo, añade entidades de los sitios afectados. También devuelve el hallazgo cuando el recuento es cero; esta rama no contiene ninguna condición de latencia medida.
• SUBNET_MISSING — Info. subnet-missing.go:24 busca entre las subredes recopiladas un Subnet.SiteDN que coincida con cada Site.DistinguishedName mediante strings.EqualFold. Un sitio sin coincidencias contribuye a Count y a sitesWithoutSubnets; los detalles también incluyen los recuentos totales de sitios y subredes. Las entidades de sitios afectados solo se añaden cuando IncludeDetails está habilitado y el recuento es positivo. Una sola subred asociada satisface este predicado aunque otras redes reales sigan sin asociación.

El proveedor LDAP importa para la interpretación. En client.go:1872, GetSitesAndSubnets busca en el contenedor Servers de cada sitio con (objectClass=server). Aunque su comentario menciona nTDSDSA, el código no verifica un objeto secundario NTDS Settings ni comprueba el estado del DC. Añade el dNSHostName de un servidor, recurriendo a name como alternativa, solo cuando hay un valor no vacío.

Un fallo de la consulta de sitios devuelve un error. Un fallo de la consulta de servidores de un sitio se ignora y puede dejar Servers vacío. Un fallo de la consulta de subredes devuelve sites, nil, nil, sin error. Estas últimas ramas pueden simular una ausencia en los datos enviados a los detectores. Por tanto, una lista de sitios o subredes aparentemente vacía exige pruebas de inventario independientes y satisfactorias.

Ninguno de los controles analiza la cobertura CIDR, valida las direcciones IP de los clientes, mide la latencia, evalúa costes de vínculos de sitio o conexiones de replicación, ni comprueba la accesibilidad de los DC. Ninguno demuestra que todos los servidores declarados sean DC en buen estado. Un sitio deliberadamente sin DC puede producir el hallazgo Low, mientras que un sitio con una subred puede evitar el recuento Info pese a lagunas en otras redes.