Domain Controller Hardening After Netlogon CVE-2026-41089: Reducing the Attack Surface Beyond Patching

CVE-2026-41089 is the most recent in a long series of vulnerabilities targeting Windows domain controllers via the Netlogon service. Patching is the priority, but each Netlogon-class vulnerability should prompt a review of whether domain controller architecture and access controls minimise the impact of the next one.

Domain controllers should be the most hardened, most monitored, and most isolated servers in the environment. Many organisations’ DC configurations fall short of this standard in ways that amplify the risk of any DC-level vulnerability.

Tier 0 Isolation: The Foundation

Microsoft’s Active Directory Tier Model classifies domain controllers as Tier 0 — the most privileged tier of the infrastructure. The model’s core principle is that Tier 0 assets (DCs, PKI infrastructure, AD Connect) should only be accessible from other Tier 0 assets.

In practice, this means:

• Administrators log in to domain controllers only from dedicated Privileged Access Workstations (PAWs), not from regular workstations
• Domain controllers do not have internet access
• Domain controllers are not managed through the same management infrastructure as regular servers
• No software is installed on DCs beyond what is required for their role

Most organisations violate several of these principles — managing DCs through general-purpose management servers, allowing DC internet access for Windows Update, or logging into DCs from standard admin workstations. Each violation expands the attack surface that a DC-level vulnerability like CVE-2026-41089 can access.

Network Access Controls for Domain Controllers

The Netlogon service listens on SMB (TCP 445) and dynamic RPC ports. Network access controls should restrict who can reach domain controllers on these ports:

Recommended DC firewall baseline:

For CVE-2026-41089 specifically, the exploit path requires TCP 445 access to the DC. Any firewall policy that prevents untrusted networks from reaching DC TCP 445 prevents exploitation from those networks.

Privileged Access Management for Domain Controllers

Domain controller administrative access should be strictly controlled:

Just-in-time access: Use Microsoft Privileged Identity Management (PIM) or a PAM solution to require elevation for domain admin access. Privileged accounts should not maintain persistent domain admin sessions.

Admin account separation: Domain admin accounts should not be used for any purpose other than Active Directory administration. Separate accounts for email, web browsing, and general administration.

Logon restrictions: Configure Group Policy to restrict interactive logon and remote logon to domain controllers to PAW computer objects only:

Computer Configuration → Policies → Windows Settings → Security Settings → 
Local Policies → User Rights Assignment → Allow log on locally → PAW-DomainAdmins group only

LAPS (Local Administrator Password Solution): Deploy Microsoft LAPS on all domain controllers to randomise the local Administrator account password. This prevents lateral movement from a compromised DC to another DC using the same local admin password.

Monitoring Domain Controllers

Domain controllers should generate logs that are forwarded to a SIEM for real-time analysis. Minimum required event IDs for DC monitoring:

• 4624/4625: Logon success/failure — watch for logons from unexpected sources
• 4720/4726: Account creation/deletion — new accounts in privileged groups
• 4728/4732/4756: Member added to privileged group — Domain Admins, Enterprise Admins
• 4769/4771: Kerberos service ticket requests and failures — Golden Ticket detection
• 7045: New service installed — persistence mechanisms
• 4103/4104: PowerShell script block logging — attacker tooling post-exploitation

The value of this monitoring is only realised if the SIEM rules are tuned to alert on anomalies and the alert response SLA is short enough to detect ongoing compromise. DC monitoring logs that sit unreviewed provide no security benefit.