Domain controllers should stay minimal to reduce Tier 0 exposure

At a glance

What this is: This is an analysis of why domain controllers should remain minimal, with the key finding that extra roles, software, and agents expand Tier 0 attack surface and make recovery harder.

Why it matters: For identity teams, the lesson is that DC sprawl creates a broader path to domain compromise, so hardening, recovery design, and Tier 0 governance all depend on strict role minimisation.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Semperis's guidance on keeping domain controllers minimal and recoverable

Context

Domain controllers are the systems that host Active Directory Domain Services, and in most environments they also provide DNS. Because they sit at the centre of authentication and directory control, they are not ordinary servers. When DCs start carrying browsers, file shares, agent software, or other general-purpose roles, the identity plane stops being tightly controlled and starts inheriting unnecessary risk.

The core governance issue is Tier 0 sprawl. A domain controller should be replaceable, predictable, and stripped to the minimum required function. That principle is typical of well-run environments, but the article argues that many organisations drift far from it by treating DCs like convenient all-purpose Windows hosts.

Domains controllers are also where recovery pressure is highest after compromise. Extra software makes incident response slower, rebuilds messier, and the blast radius larger when an attacker reaches the directory layer.

Key questions

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. Browsers, file shares, utility services, and third-party agents add attack surface without improving the controller’s primary purpose. The safest default is to make the DC easy to rebuild and hard to misuse.

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. Once the controller is compromised, credential exposure and domain-wide escalation become much easier. The cost is not just complexity, it is wider blast radius.

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. Another warning sign is when recovery would require untangling multiple roles before the server can be trusted again. Those conditions show that Tier 0 boundaries are weakening.

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.

Technical breakdown

Why domain controllers should only run AD DS and DNS

A domain controller is not just another Windows server. It is the authoritative identity and directory control plane for the domain, which means every additional role or application increases the number of things that can be exploited, misconfigured, or left behind during recovery. AD DS and DNS are the core functions; everything else adds attack paths without improving the DC’s primary job. The architectural goal is replaceability, not utility. If a DC can be rebuilt from a known baseline quickly, identity operations survive better when one node is compromised or degraded.

Practical implication: move nonessential roles off DCs and standardise a minimal rebuild image for every controller.

Why agents and interactive software create disproportionate risk on DCs

Software that requires an installed agent, browser, or interactive runtime on a DC expands the surface area in ways identity teams often underestimate. Agents can establish direct command-and-control channels, and browser extensions or similarly injected components can become a path into Tier 0. On a domain controller, that risk is amplified because the attacker is no longer fighting for a foothold on a random endpoint. They are standing at the doorway to directory trust itself, where access to NTDS.DIT or privileged token material changes the game.

Practical implication: treat any agent, browser, or extension request for a DC as a Tier 0 exception requiring explicit risk acceptance.

How recovery gets harder when DCs are overloaded with extra roles

The recovery problem is not only exploitation, it is rebuild complexity. The more roles and software a DC carries, the harder it becomes to know what is necessary, what is trusted, and what must be removed before the server is returned to service. That matters because DC recovery is usually a race to restore authoritative identity services while limiting residual compromise. A stripped-down controller reduces uncertainty, shortens validation, and makes forensic scoping cleaner after an incident.

Practical implication: define a clean DC baseline now so incident response teams are not forced to untangle role sprawl during a crisis.

Threat narrative

Attacker objective: The attacker wants control over the domain controller so they can harvest identity data, crack credentials, and expand compromise across the domain.

1. Entry occurs when unnecessary software on a domain controller, such as a browser extension or injected agent, provides an attacker with an execution path into Tier 0. Escalation follows when that foothold reaches privileged directory services or overprivileged accounts on the controller. Impact occurs when the attacker extracts directory data such as NTDS.DIT or manipulates identity services to enable broader domain compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity blast radius is created before the breach, not after it: A DC with browsers, file services, extensions, or agents has already widened the attacker’s path before any intrusion occurs. Once that system is compromised, directory trust and credential harvest become much easier to scale. The practitioner conclusion is that blast radius is reduced by removal of unnecessary functionality, not by relying on post-compromise tooling.

Agent software changes the trust model of the DC itself: The article’s warning about AI agents and other installed agents is not about novelty, it is about command-path creation on a crown-jewel system. If an overprivileged account can be manipulated through an installed agent, the controller is no longer a tightly bounded identity platform. The implication is that agent governance and DC governance intersect at Tier 0, and both must be treated as exclusion zones.

Minimal DC architecture is a resilience control, not just a hardening preference: Bare-minimum controllers are easier to rebuild, easier to validate, and easier to recover under pressure. That makes the model operationally superior during incident response because it limits ambiguity about what belongs on the host. Practitioners should treat DC minimisation as part of identity resilience, not an optional hygiene exercise.

DC sprawl is a symptom of weak Tier 0 governance: When organisations accept extra roles on domain controllers, they are signalling that convenience has overtaken privilege separation. That weakens every downstream control that assumes directory infrastructure is stable, predictable, and narrowly scoped. The field should read this as a reminder that identity security begins with strict host purpose, especially for the systems that define the domain.

From our research:

• 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.
• For teams hardening Tier 0, the forward lesson is that 52 NHI Breaches Analysis shows how quickly exposed identity controls become organisational problems.

What this signals

Identity blast radius: DC hardening is really about deciding which services are allowed to sit inside the directory trust boundary at all. Once general-purpose workloads land on a controller, the recovery model becomes slower, the attack surface becomes broader, and the identity programme starts relying on host hygiene instead of purpose-built Tier 0 design.

The next governance step is to treat DC placement decisions as architecture decisions, not server-build preferences. That means linking Tier 0 policy to host role inventories, rebuild baselines, and exception approvals, then validating those controls against the same discipline used for privileged access and sensitive secrets.

For practitioners

• 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. Move DHCP, file services, browsing, and other utility workloads to separate servers so the controller stays rebuildable and predictable.
• 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. Review every exception as a Tier 0 risk decision, not a convenience request.
• 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. That baseline should be tested as part of recovery planning, not assembled during an incident.
• Treat agent deployment on DCs as a privileged access decision If an installed agent can open a command path or expand remote control, require the same scrutiny you would apply to high-risk administrative access. Do not allow experimental or unvetted agentic access to a controller that already holds directory trust.

Key takeaways

• Domain controllers should be purpose-built identity systems, not multipurpose Windows servers.
• Every added role, browser, or agent on a DC expands the path to directory compromise and slows recovery.
• The right control is strict Tier 0 minimisation supported by a standard rebuild baseline and exception governance.

Key terms

• Domain Controller Hardening: Domain controller hardening is the practice of reducing a controller’s exposed functionality to the minimum needed to run directory services securely. In identity environments, this means keeping the host predictable, replaceable, and free of software that expands Tier 0 attack paths.
• Tier 0: Tier 0 is the set of identity assets whose compromise can control or undermine the entire environment. In Active Directory programs, this usually includes domain controllers, directory synchronization components, certificate services, and key management systems that must be isolated from routine administrative workflows.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Controller Rebuildability: Controller rebuildability is the ability to replace a compromised domain controller quickly from a known-good baseline. It matters because recovery is faster and safer when the host is simple, standardised, and free of unrelated software that complicates validation.

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.

👉 Semperis's full article explains the DC role boundaries, software exceptions, and compromise examples in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.