There are plenty of questions on the internet regarding which software should be installed on a domain controller (DC). Which roles should be deployed? Which applications are required? To answer these questions, you must consider what a DC should do in the first place.
Which Windows Server roles should you run on a DC?
Ultimately, a domain controller should have only one purpose: to control a domain. It hosts Active Directory Domain Services (ADDS) and usually the Domain Naming System (DNS). That’s really all it needs.
Any server roles over and above that should be on separate servers. Because DCs host Active Directory, they host the keys to the kingdom. DCs are typically the crown jewels of your identity environment and must be protected at all costs.
Here at Semperis, we believe that DCs should be kept to the bare minimum. That way, if something happens to one DC, you simply build out another to replace it. Here’s the rule of thumb when it comes to DCs: Always use the same base OS, the same patch levels, the same software, and the same roles.
What software should you install on a DC?
What about software installed on your DCs? This topic is a bit trickier and really relies on the security requirements of your organization.
Remember, a DC should be easily replaceable. At a bare minimum (from a security perspective) you should use antivirus software and an EDR or XDR solution. These might be built into the OS (e.g., Microsoft Defender), or you could use a third-party tool. Additionally, you might want something to collect logs. That’s the limit of what we would recommend.
Each and every piece of software that is deployed on a DC presents another avenue of attack. This is especially true for anything that requires an agent (AI or otherwise) to be installed. An agent can open direct command and control of whichever system it is installed on.
This is why during any Identity Forensics and Incident Response (IFIR) engagement, Semperis builds out DCs with a bare minimum installation. Only after the dust settles do we allow customers to start rolling out additional software … provided that they accept the risk of doing so.
What could go wrong?
Unfortunately, many environments do not follow these guidelines, instead deploying additional roles and all kinds of software (browsers, applications, file shares, and so on) on their DCs. Not only does this approach increase complexity during times of recovery, it also increases the attack surface of your domain controllers. The last thing you want to do is grant a threat actor more ways to compromise Tier 0.
Here’s an example. Let’s say someone decides that it would be a good idea to install Google Chrome on a domain controller so that they can surf the internet. They go even further and deploy some Chrome extensions … but one of those extensions has embedded C2 code that enables a threat actor to walk right in and take over the DC. From there, the attacker can simply copy and extract the NTDS.DIT file, leaving the bad actor all the time in the world to crack every user account and password.
Another example: Your organization is trying to stay current with AI agents, but your agentic AI of choice hasn’t yet been fully vetted. Still, someone provides agentic access to an overprivileged account. And AI being the helpful tool that it is, when an attacker tries to manipulate it to provide information or access from that account, the AI happily complies. Needless to say, bad stuff then hits the fan. We are already starting to see this issue in real-world environments.
The bottom line: Protect your domain controllers
So, to recap: You need ADDS and DNS (along with their corresponding management tools) on your DCs. That’s it. Deploy roles like DHCP, File Server, and anything else on separate servers.
Just keep things as simple as possible when it comes to domain controllers, and you’ll automatically improve your identity security posture.
More resources for DC security and identity defense
