Domain Controller Network Architecture: How DC Placement Determines Netlogon Attack Surface

The scope of CVE-2026-41089’s risk in any specific organisation is determined by a question of network architecture: which networks can reach domain controllers on TCP 445? The answer to this question, shaped by infrastructure decisions often made years ago, determines whether the vulnerability is exploitable from the internet, from cloud environments, from partner networks, or only from internal trusted segments.

DC Reachability: The Architecture Audit

Before assessing the Netlogon patch urgency in your environment, map DC reachability:

Step 1: Identify all domain controllers

Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, Site, IsGlobalCatalog, IsReadOnly

Step 2: Test reachability from each network segment For each DC, run a port scan or use the network access control policy to determine which source segments can reach TCP 445. In most environments, the result should be “all domain-joined subnets and management networks only.” In practice, the result is often more permissive.

Common reachability issues discovered during this audit:

• Cloud-hosted workloads (Azure VMs, AWS EC2) that joined the domain via site-to-site VPN and have DC access from cloud subnets
• Partner network connections with implicit DC access inherited from broad internal network trust
• Internet-accessible DCs in DMZs configured for remote authentication (less common but observed in some legacy architectures)
• Guest Wi-Fi networks that reach internal subnets, including DC subnets, due to poor VLAN segmentation
• Development environments connected to production AD for developer convenience with DC access

DC Deployment Patterns and Their Risk Profiles

Centralised DC model (all DCs in HQ data centre):

• High risk if the DC subnet is poorly isolated from other internal segments
• Lower risk if the DC subnet has strict firewall controls limiting inbound 445 to known subnets
• Single point of failure for branch office authentication if WAN connectivity fails

Distributed DC model (DCs in each branch office):

• Each branch DC extends the attack surface — branch network security determines whether the branch DC is reachable from untrusted sources
• Branch office DC exposure requires branch-level network controls matching HQ data centre standards
• RODC deployment in branches reduces branch DC exposure (RODCs have limited cached credentials and restricted writeable access)

Cloud DC model (Azure AD DS, DCs on Azure VMs):

• Cloud-hosted DCs on VNet segments may be reachable from cloud workloads that are semi-trusted
• Azure Network Security Groups must explicitly restrict port 445 to authorised source prefixes
• Cloud DCs should not have public IP addresses — all management should be via private network

Hybrid model (on-premises DCs + Azure AD Connect sync):

• The AD Connect server has a privileged relationship with both the on-premises AD and Azure Entra ID — compromise of the AD Connect server is equivalent to DC compromise
• AD Connect should have the same tier 0 isolation as domain controllers

Designing for Resilience Against Future Netlogon-Class Vulnerabilities

CVE-2026-41089 will not be the last vulnerability in the Netlogon service. The protocol is fundamental to Windows domain authentication and has been an attack target for decades (CVE-2020-1472 Zerologon is the most prominent prior example). Designing DC architecture to minimise the impact of future vulnerabilities:

Network micro-segmentation: Firewall rules that explicitly enumerate which subnets can reach each DC on each required port. This eliminates implicit “all internal traffic trusted” rules that allow unexpected network paths to DCs.

Read-Only Domain Controller (RODC) deployment for untrusted locations: RODCs do not cache credential material by default (beyond explicitly allowed accounts) and have restricted replication rights. A Netlogon-class RCE against an RODC provides less value to an attacker than against a full DC.

DC RPC port restriction: Netlogon uses dynamic RPC port allocation (49152–65535). Configuring Netlogon to use static RPC ports allows more precise firewall rules:

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DCTcpipPort = <static_port>

Then allow only that static port from authorised segments, rather than the full 49152–65535 dynamic range.

Zero Trust network architecture: A Zero Trust implementation that requires explicit authentication and authorisation for each connection — regardless of source network — eliminates the implicit trust that makes DC-to-workstation paths exist. In a mature Zero Trust environment, even if a Netlogon vulnerability exists, the attack path from an untrusted source to a DC requires explicit permission that was never granted.