AD sites subnets: verify DC selection before changing topology

AD sites subnets: what to verify before changing topology

AD sites subnets reviews should answer a practical question: does a representative client identify the intended Active Directory site and discover an appropriate domain controller? A site with no collected server objects and a site with no associated subnet objects are useful investigation prompts. Neither result, by itself, demonstrates an attack or tells you which configuration change is justified.

This guide was checked against Microsoft Learn and the etc-collector implementation on October 3, 2026. The commands below are documented inspection and configuration examples; they were not executed against a customer domain. Use your network inventory, directory results, and client observations to establish the cause before changing a mapping.

A branch can deliberately have no local DC. Conversely, a site can have a subnet object while additional real client networks remain undeclared. Keep these cases separate: a directory object count is not a test of network coverage or successful authentication.

How site mapping affects DC selection and replication

Microsoft's DC locator documentation describes discovery through Netlogon, DNS advertisements, and LDAP UDP responses. During negotiation, a DC identifies the client's site from its IP subnet. If the first DC is outside the appropriate site, the returned client-site information can drive another, site-specific lookup. Discovery also uses cached information; a single returned DC is an observation of that request, not a complete history of application authentication.

An unmapped client subnet leaves site selection incomplete and can lead to a DC outside the intended location. That is a reason to investigate the actual client address and mapping, rather than assume that every client chooses a DC randomly. A remote DC can also be the intended service for a branch without one locally.

Microsoft's replication concepts distinguish subnet objects, which map network addresses to sites, from site links and connection objects used for replication. A DC's server object has a child NTDS Settings object representing the replicating DC. The KCC builds replication connections; site links describe logical replication paths and costs.

For this review, maintain two separate questions. Client discovery asks which DC a machine can locate from its current network. Replication design asks how DCs exchange directory changes. A correct client-site mapping does not establish replication health, and successful replication does not establish that every client network has the intended site mapping.

The AD DNS zone security guide covers transfers, dynamic updates, and record permissions. Those resolution-data controls complement this investigation, but they do not define the subnet-to-site mapping. Investigate DNS when discovery fails, while keeping the topology evidence distinct.

Detection: reconcile directory inventory with client observations

1. Establish what the directory queries actually returned

Use a management host with the ActiveDirectory PowerShell module and an account permitted to read the relevant configuration objects. Microsoft's references document Get-ADReplicationSubnet and Get-ADReplicationSite. The following read-only examples request the objects and their properties:

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

Record the queried directory server, account context, query success, and collection time alongside the results. Inspect subnet names and their Site associations, then compare the associated site with the site's distinguished name. Do not convert an access error or an incomplete export into a conclusion that the objects do not exist.

Reconcile that export with the network team's current inventory: branch networks, office networks, VPN client ranges, and other networks from which domain clients actually connect. For each relevant range, identify the expected site and the owner who can confirm it. This comparison is a manual review step; the two EtcSec checks below do not perform it.

Start with a small, representative set of clients that includes the networks behind the finding. Record the active address and connection context for each observation. A laptop tested in an office and the same laptop tested over a VPN are different network observations. Preserve the expected site and the reason for that expectation before comparing command output.

2. Observe site membership and the DC locator result

Microsoft's directory synchronization troubleshooting page documents these commands for checking computer-site membership and locating a DC. Replace the example domain with your actual DNS domain:

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Read the site result, selected DC, and the Our Site Name and DC Site Name fields when returned. Preserve failures as failures, including their error text. An unavailable site result needs investigation; it is not evidence that the client belongs to the nearest office by geography.

For a deliberate fresh-discovery comparison, the Nltest reference documents /force as avoiding the cached discovery information:

nltest /dsgetdc:contoso.com /force

Keep both results rather than overwriting the first observation. Compare the reported client site with the expected mapping and the DC site with the documented branch design. If they differ, investigate mapping, discovery, and the intended WAN exception before editing anything. These commands exercise discovery; validate the affected application's behavior separately if an authentication complaint triggered the review.

3. Correlate unmapped-client evidence

Microsoft documents NETLOGON event 5807 in DC delayed response to LDAP or Kerberos requests. The event describes connections from client addresses that do not map to existing sites. That page identifies %SystemRoot%\debug\netlogon.log and its rotated .bak file as locations for client names and addresses, with NO_CLIENT_SITE: identifying relevant entries.

Where this event or its accompanying log entries are present, reconcile the observed addresses with the network inventory and declared subnets. Check which connection produced the address before assigning it to a site. Absence of this event is not a substitute for the inventory comparison, and its presence does not identify an attacker.

Remediation: fix the mapping or document the intended exception

1. Resolve inventory uncertainty first

Before editing topology, reconcile the collector snapshot with successful directory reads. If server or subnet enumeration failed, investigate the collection context and repeat the inventory. Do not deploy a DC, delete a site, or invent a subnet merely to clear an apparent absence produced by a failed query.

For a site without a local DC, ask the domain and network owners whether this is deliberate. Document the servicing DC location, expected WAN dependency, owner, and review trigger. Keep that exception with the client observations so another reviewer can understand why cross-site discovery is acceptable there.

2. Correct a confirmed missing or wrong mapping

Identify the real client network and the existing site that should represent it. Review the proposed mapping with the network owner, including other networks that could be affected. A subnet definition should express the agreed network design, not simply copy the address of the first machine that produced an error.

For a genuinely missing subnet, Microsoft documents this creation example in New-ADReplicationSubnet:

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

This is Microsoft's illustrative network and site, not a proposed configuration for your estate. Substitute a verified network and an existing intended site only after checking that the subnet object is actually missing. For an existing object with the wrong association, correct its Site association in Active Directory Sites and Services through your normal change process. Preserve the original values and the approved replacement in the change record.

If a server is truly retired, follow the separate DC object hygiene and metadata cleanup guidance. Confirm retirement before cleanup. An empty collected server list is not evidence that a live DC should be removed, and adding or removing server objects is not a substitute for fixing client subnet mapping.

3. Recheck representative clients and keep the evidence

Repeat the directory inventory and the client discovery commands after the change is visible to the directory server involved in validation. Test the same representative networks, including the intended remote-service cases. Record the expected site, observed site, returned DC, and remaining exception for each client.

Recheck the application workflow that motivated the investigation and review replication separately if topology was changed. A cleared inventory finding is useful confirmation of the collected objects, but it does not establish that every network or every application now uses the desired path.

How EtcSec Detects This

EtcSec's etc-collector implementation evaluates two Network checks against the collected site and subnet inventory:

• SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 iterates over data.Sites and collects each site whose len(site.Servers) == 0. It returns a finding whose Count is the number of such sites, with their names in sitesWithoutDc. When the count is positive, it adds affected site entities. It also returns the finding when the count is zero; there is no measured latency condition in this branch.
• SUBNET_MISSING — Info. subnet-missing.go:24 searches the collected subnets for a Subnet.SiteDN that matches each Site.DistinguishedName using strings.EqualFold. A site without any match contributes to Count and sitesWithoutSubnets; the details also include total site and subnet counts. Affected site entities are added only when IncludeDetails is enabled and the count is positive. A single associated subnet satisfies this predicate even if other real networks remain unmapped.

The LDAP provider matters to interpretation. In client.go:1872, GetSitesAndSubnets searches each site's Servers container with (objectClass=server). Although its comment mentions nTDSDSA, the code does not verify an NTDS Settings child or test DC health. It appends a server's dNSHostName, falling back to name, only when a nonempty value is available.

A site-query failure returns an error. A per-site server-query failure is ignored and can leave Servers empty. A subnet-query failure returns sites, nil, nil, without an error. Those latter branches can simulate absence in the data passed to the detectors. An apparently empty site or subnet list therefore requires independent, successful inventory evidence.

Neither check analyzes CIDR coverage, validates client IP addresses, measures latency, evaluates site-link costs or replication connections, or tests DC reachability. Neither proves that every declared server is a healthy DC. A site intentionally without a DC can produce the Low finding, while a site with one subnet can avoid the Info count despite gaps elsewhere.