Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Domain controllers should carry only Active Directory Domain Services and DNS, with any extra roles or software moved elsewhere, because every added component expands Tier 0 attack surface and recovery complexity, according to Semperis. The practical lesson is that DC hardening is less about adding tools than removing assumptions that a crown-jewel system can safely host general-purpose software.
NHIMG editorial — based on content published by Semperis: Which Windows Server roles should run on DCs?
Questions worth separating out
Q: What should be removed from a domain controller first when reducing Tier 0 risk?
A: Start with anything that is not required for Active Directory Domain Services, DNS, or essential management.
Q: Why do extra roles on domain controllers increase compromise impact?
A: Because a domain controller already sits at the centre of identity trust, every extra role creates another path an attacker can abuse before reaching directory data.
Q: What are the warning signs that a domain controller is being overloaded?
A: A DC that hosts browsers, extensions, file services, or nonessential software is drifting beyond its intended purpose.
Practitioner guidance
- Strip domain controllers to core identity services Limit DCs to Active Directory Domain Services, DNS, and the management tools that are essential for those functions.
- Ban general-purpose software and extensions on Tier 0 hosts Create a policy that blocks browsers, extension stores, third-party agents, and interactive applications on domain controllers unless there is a formally approved exception.
- Standardise a minimal rebuild image for every controller Keep the same base OS, patch level, software set, and approved roles across all DCs so replacement is fast and consistent.
What's in the full article
Semperis's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step rationale for which Windows Server roles belong on a domain controller and which should be moved off-host.
- The security trade-offs behind installing antivirus, EDR, logging tools, and other agents on Tier 0 systems.
- The recovery implications of keeping DCs minimal, including why rebuildability matters after compromise.
- Real-world examples showing how browser extensions and overprivileged agent access can turn a DC into an attack path.
👉 Read Semperis's guidance on keeping domain controllers minimal and recoverable →
Domain controllers and Tier 0 software sprawl: what should stay off them?
Explore further
02/09/2026 1:30 pm
Tier 0 systems fail when they are treated like convenience servers: Domain controllers are built to control identity, not to host general-purpose workloads. The more software, roles, and interactive tooling they absorb, the more the identity plane inherits endpoint-style attack paths. That is a governance failure, not just an operations preference, because Tier 0 discipline depends on boundary enforcement.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Secrets management gaps are not theoretical, because only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How should teams decide whether software belongs on a domain controller?
A: Only install software that is directly required for directory control or essential management, and treat everything else as an exception. If the tool introduces an agent, interactive access, or a new command path, it belongs on a separate server. The deciding question is whether the software helps control the domain or merely makes the host more convenient.
👉 Read our full editorial: Domain controllers should stay minimal to reduce Tier 0 exposure
