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.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “What Should You Install on Your Domain Controllers?”.
Key questions
Q: What breaks when domain controllers host extra software and roles?
A: Extra roles and software turn a domain controller from a narrowly scoped identity host into a larger attack surface.
Q: Why do domain controller exceptions create so much risk in practice?
A: Because DCs hold the keys to the domain, even small exceptions have outsized impact.
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.
Practitioner guidance
- Limit domain controllers to core identity services Keep AD DS and DNS on DCs, and move DHCP, file sharing, browsing, and other utility roles to separate servers.
- Treat agents and browsers as Tier 0 exceptions Review any software that requires an installed agent, especially tools with command-and-control or broad system access capabilities, before allowing it on a DC.
- Standardise rebuildable controller baselines Use the same base OS, patch levels, software, and roles across all DCs so any controller can be replaced without bespoke reconstruction.
Bottom line: Domain controllers become materially harder to defend once teams treat them as general-purpose servers instead of identity authorities.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/09/2026 1:30 pm
Tier 0 systems should be treated as constrained identity infrastructure, not general-purpose servers. The article reinforces a core governance principle: the closer a system sits to authoritative identity data, the less functionality it should host. When organisations blur that boundary, they create avoidable exposure that is hard to unwind during a crisis. The practitioner conclusion is to govern DC scope as a policy decision, not a local admin preference.
A question worth separating out:
Q: What should identity teams do after a domain controller is overbuilt?
A: Inventory every non-core role and application, then move utility services off the controller and rebuild the DC image around a minimal baseline. The goal is to shrink the compromise surface before an incident forces an emergency cleanup.
👉 Read our full editorial: Domain controllers should stay minimal to reduce Tier 0 exposure