Domain controllers should stay minimal to reduce Tier 0 exposure

At a glance

What this is: Semperis argues that domain controllers should be kept to a bare minimum, with AD DS and DNS as the core services, because additional roles and software increase Tier 0 exposure.

Why it matters: For IAM and identity security teams, this is a reminder that DC hardening is a governance decision about scope, recoverability, and blast radius, not just a server build standard.

Context

Domain controllers are the highest-value systems in a Windows identity estate because they control the domain and host the directory services that other access decisions depend on. When teams treat them as general-purpose servers, they blur the boundary between identity infrastructure and utility hosting, which makes compromise and recovery both harder to manage.

The article's core message is simple: reduce what runs on domain controllers so the platform stays replaceable and the identity tier stays defensible. That matters most where operational convenience tempts teams to add browsers, file services, agents, or other software onto systems that should remain tightly scoped.

In identity programmes, the practical question is not whether a tool is useful in isolation. The real question is whether that tool belongs on a Tier 0 asset whose compromise can expose the entire directory and accelerate recovery failure.

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. That increases the ways an attacker can reach Tier 0, makes recovery more complex, and raises the chance that a compromise exposes directory data and reusable credentials across the environment.

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. A browser, extension, file service, or agent can create a foothold, expand control paths, and increase the likelihood that a compromise reaches AD DS or related privileged material.

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.

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.

Technical breakdown

Why AD DS and DNS are the only baseline roles on a domain controller

A domain controller exists to provide directory authority, not to host general services. AD DS is the core identity database and authentication backbone, while DNS is often colocated because the domain depends on name resolution for reliable logon and service location. When those two functions sit on the same hardened platform, the server remains focused, predictable, and easier to rebuild. Once additional roles are added, the DC stops being a narrowly defined identity control plane and starts absorbing unrelated operational risk. That increases the number of processes, listeners, update paths, and attack paths that an adversary can abuse if the host is exposed.

Practical implication: Keep domain controllers limited to directory and naming services unless a role is unavoidable and explicitly accepted as Tier 0 risk.

Why extra software and agents expand the Tier 0 attack surface

Every application or agent installed on a domain controller introduces new code paths, permissions, and often its own update or management channel. Security tooling can be justified, but anything that requires broad system interaction or command execution raises the stakes on a system that already holds privileged identity assets. The article's caution about agents matters because agent-based software can create direct control channels into the host. On a DC, that does not merely add operational complexity. It widens the set of ways an attacker can reach directory services, access sensitive files like NTDS.DIT, or pivot from the host into the broader identity plane.

Practical implication: Treat any non-essential software on a DC as a Tier 0 risk decision, not a routine endpoint deployment.

Why minimal builds improve recovery and incident response

A minimal domain controller is easier to replace because there are fewer dependencies to reconstruct after a failure or compromise. That matters in incident response, where recovery speed depends on having clean, repeatable builds with consistent base OS, patch levels, software, and roles. If each DC differs materially from the others, rebuilds become bespoke projects and forensic confidence drops. The article's operational point is that consistency is itself a security control. Standardised DC builds reduce surprises during restoration and limit the chance that recovery work reintroduces the same exposed services that created the problem in the first place.

Practical implication: Standardise DC images and rebuild paths so the identity team can restore a controller without reintroducing unnecessary software.

Threat narrative

Attacker objective: The attacker aims to turn a single DC foothold into broad control over the domain and access to reusable identity material.

1. Entry occurs when unnecessary software, such as a browser extension or poorly vetted agent, creates a new way into the domain controller.
2. Credential access follows if the attacker reaches a host that contains directory services and related privileged material such as NTDS.DIT.
3. Escalation and lateral movement become easier because compromise of the DC exposes Tier 0 identity assets and can be used to crack or reuse credentials across the environment.
4. Impact is full domain compromise, where the attacker can extract identity data and undermine recovery by forcing the organisation to rebuild from a more fragile baseline.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Software sprawl on domain controllers creates identity blast radius, not just operational clutter. The real risk is not that the host becomes busier. The risk is that each extra role, agent, or browser adds another path an attacker can use to reach privileged directory assets. That makes the DC a multipurpose compromise target instead of a narrowly defended crown jewel. The practitioner conclusion is to measure software by its effect on blast radius, not by its convenience.

Minimalism on DCs is a resilience control as much as a security control. Recovery is faster and cleaner when every controller follows the same base OS, patch levels, software, and roles. That consistency reduces rebuild uncertainty and helps incident responders restore trust in the identity plane with fewer unknowns. The practitioner conclusion is to standardise rebuildable DC patterns and reject one-off exceptions unless they are formally accepted as Tier 0 risk.

Agentic software on a domain controller collapses the assumption that identity hosts only execute bounded administrative work. That assumption was designed for static server roles and controlled admin tooling. It fails when an agent can be manipulated into acting on privileged data or access from within the host itself. The implication is that identity governance must distinguish between tools that observe a DC and software that can meaningfully act through it.

Identity blast radius: the useful unit of analysis is not how many services a DC can technically support, but how much of the identity estate one compromise can expose. The article shows that extra functionality increases both compromise paths and recovery burden. The practitioner conclusion is to optimise DC design for minimal blast radius, not maximum local utility.

What this signals

Minimal DC design is a governance control, not a build preference. Teams that keep domain controllers tightly scoped reduce the number of ways Tier 0 can be reached and the number of dependencies they must unwind during recovery. The operational advantage is not subtle: fewer moving parts means fewer reasons for a controller to fail under pressure.

Identity teams should separate control-plane services from convenience workloads. If a workload is not necessary for directory authority, it should not share the host that provides it. That principle becomes more important as organisations layer endpoint agents, admin tools, and automation across the same infrastructure that protects authentication and domain integrity.

For practitioners

• 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.
• Separate security tooling from host utility Allow only the minimum security stack on DCs, such as antivirus, EDR or XDR, and logging collection if it is required by policy.

Key takeaways

• Domain controllers become materially harder to defend once teams treat them as general-purpose servers instead of identity authorities.
• The article's examples show how extra software can create both a compromise path and a recovery problem in the same host.
• The clearest preventive control is scope discipline: keep DCs minimal, consistent, and replaceable.

Key terms

• 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.
• Domain Controller: A domain controller is the server that authenticates users, machines, and services in an Active Directory environment. Because it anchors the trust fabric, compromise of a controller can affect every domain-joined system and turn a single host flaw into an enterprise identity incident.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.