Active Directory & Office 365 Reporting Tool

Domain Controller Security Best Practices – Hardening (Checklist). In 2020 Microsoft released a patch that would fix Zerologon vulnerability that affected domain controllers. The vulnerability allowed attackers to gain access into domain controllers. How? By exploiting a flaw previously found in the Netlogon Remote Protocol cryptographic scheme.

In turn, this vulnerability served as a further reminder that despite the fact that domain controllers are often overlooked in terms of cybersecurity, they remain vital components of many businesses which are unfortunately, frequently targeted by sophisticated threat actors.

Most domain controllers are compromised due to poor cybersecurity hygiene such as misconfigurations, unpatched systems, open ports, stolen credentials, and poor user habits. However, while this remains to be true for most domain controller compromises, it is important to note that more sophisticated attackers can breach even the most secure and advanced setups. 

Image Source: Varonis

While compromising a domain controller is not the only option for the attacker, it is typically a strategy used by attackers to quickly achieve their desired objective. Actually, domain controller compromises are by far the most common denominator that is attributed to large scale breaches and sophisticated cyberattacks.

This is why it is crucial for all businesses to implement the best security practices for securing their domain controllers. This article is a detailed analysis of the best security practices to make sure that your systems are fool proof.

Best Security Practices for Hardening Domain Controllers

1. Make sure your Domain Controllers are secure

For many organizations, domain controllers are either virtual or physical machines stored in data centres, branch offices, or even in remote locations.

Therefore, there are unique security procedures you need to follow, to make sure that they are secure based on the various locations of your domain controllers. First, let’s start with physical domain controllers.

Physical Domain Controllers

If your physical domain controllers are located in data centers, ensure that they are installed in dedicated racks or cages. To put it explicitly, separate them from the general server population. This should be done to make sure that unauthorized access is limited as much as possible.

On the other hand, if your physical domain controllers are located in branch locations, ensure that they are stored in a locked room to prevent unauthorized access. If not, make sure that you only deploy read only domain controllers in such locations.

Virtual Domain Controllers

Alternatively, for virtual domain controllers, make sure that they operate on separate physical hosts from other virtual machines. Additionally, if you employ a third-party virtualization platform, consider deploying virtual domain controllers on Hyper-V in Windows Server. This is because it provides a small attack surface and is handled separately from the rest of the virtualization hosts. 

However, if you use System Center Virtual Machine Manager to manage your virtualization infrastructure, ensure that you delegate administration for both domain controller virtual machines. Then, their physical hosts to authorized administrators.

Additionally, it is also recommended to segregate virtual domain controller storage. This should be done to prevent unauthorised personnel from accessing virtual machine data.

Finally, for virtual domain controllers in branch positions, it is recommended to deploy read only domain controllers in case your virtual domain controllers cannot run on separate physical hosts from the other machines.

2. Ensure your data is encrypted

This should be a no brainer. This is because even if an attacker gained access to your data, the encrypted data would be worthless to them. Cyber security experts recommend having a two-pronged approach to this. First, make sure that your domain controllers are configured with Trusted Platform Module (TPM) chips. Additionally, also ensure your domain controllers are protected with BitLocker Drive Encryption.

In terms of data encryption and security, TPM chips are invaluable. BitLocker disc encryption, Windows Hello, and other services rely on TPM to generate and store cryptographic keys. Additionally, they also verify the integrity of the device’s software and hardware and prevent unauthorized access.

BitLocker is useful for protecting physical and virtual domain controllers from threats like rootkits. In effect, it boots the server into recovery mode, if the boot files is tampered with.

However, it is important to note that if your domain controllers are configured to use software such as RAID, SAN/NAS storage, dynamic volumes, or serial-attached SCSI, Bitlocker cannot be deployed for your domain controllers. To remedy this, employ locally attached storage (with or without hardware RAID), whenever possible in your domain controllers.

When it comes to performance, BitLocker has a tiny performance impact (in the single digit percentage range) on your machines. However, it is still very useful, as it prevents directory compromise even, if drives are removed from the system.

3. Update your systems regularly

Microsoft recommends that you run domain controllers on the latest version of Windows Server, supported by your organization. This is especially because, old systems are riddled with vulnerabilities. Subsequently, these loopholes provide an easy gate way that can be easily exploited even by the most unsophisticated threat actors.

So as a rule, always make sure that you decommission all legacy operating systems in your domain controller servers.

Maintaining current domain controllers and removing legacy domain controllers enables you to take advantage of new features and security. These benefits are not necessarily present in domain controllers with legacy operating systems.

Improve your Active Directory Security & Azure AD

Try us out for Free, Access to all features. – 200+ AD Report templates Available. Easily customise your own AD reports.

4. Use Appropriate security configurations

Lax security configurations are often exploited by cybercriminals to gain access to computer systems. Thankfully, there are tools such as the Security Policy snap-in (Secpol.msc), the Security Editor command-line tool (Secedit.exe), the Security Compliance Manager, and others to remedy this. It is prudent to utilize these tools to ensure that your security configurations are fool proof. 

Usually these tools are used to generate an initial security configuration baseline for domain controllers. This configuration can the in turn be enforced by GPOs. So which security configurations are necessary? Let’s have a look at them in full detail below.

Implement appropriate RDP restrictions

The end goal of any attack is to have remote control of your servers. Having lax remote desktop access policies only aids in that and makes your controllers vulnerable to attacks. Therefore, restricting Remote Desktop (RDP) access to your domain controllers is a highly recommended configuration. It is therefore necessary to make the appropriate group policy changes that make sure RDP restrictions are enforced.

To do this, ensure that Group Policy Objects are linked to all domain controller OUs in a forest and set to allow RDP connections from only authorized users and systems (for example, jump servers).

To ensure that the policy is consistently executed, administrators should utilize a combination of user rights settings and WFAS configuration enforced through GPOs. Basically, the advantage of doing this is that, in the event that the policy is modified, the next group policy refresh restores the system’s configuration to its original state.

Restrict internet access for domain controllers

As a safety measure, it is highly recommended that no web browser should be used on domain controllers. The internet is full of malware. Therefore, using a highly privileged account to browse the Internet or an infected intranet from one of the most powerful systems in a network’s architecture poses a significant danger to an organization’s security. This is well enumerated in Microsoft’s Avenues to Compromise

Actually, one of the Active Directory security assessments includes a check of Internet Explorer use and settings on domain controllers. Additionally, web browsers are often used for downloads that easily compromise your system.

Restriction is necessary because, whether through a drive by download or the installation of malware infected “utilities,” attackers can easily acquire access to everything they need to completely infiltrate or destroy the Active Directory system.

Therefore, it is imperative that internet access is restricted in domain controllers by using policy and technical controls to restrict web browsers on domain controllers. This is achieved by:

  • Perimeter Firewall Restrictions.
  • Preventing Web Browsing from Domain Controllers.

Perimeter Firewall Restrictions

Firewalls are an integral part of any comprehensive security architecture. The appropriate perimeter firewall configurations for domain controllers is to block all outbound connections to the internet.

However, to allow for communication within the organization, you can configure your domain controllers to allow communication across site boundaries by allowing intersite communication.

Prevent Web Browsing from Domain Controllers

To restrict domain controllers from accessing the Internet and the usage of web browsers, use a combination of AppLocker settings, a “black hole” proxy configuration, and WFAS configuration.

5. Patch Domain Controllers separately from other network systems

Interestingly, Microsoft recommends that you consider patching your domain controllers separately from other critical infrastructure components.

This is because when all of the computers in an infrastructure are managed by the same enterprise configuration management software, a vulnerability can be  leveraged to hack or compromise everything managed by that software. 

Additionally, domain controllers are also more efficiently managed and have less software loaded on them, if their patching and system management are handled independently from the rest of the network.

6. Adopt a cloud based approach to Identity and Access Management

Many businesses are transitioning to cloud based computing because of its inherent benefits. Cloud based computing is generally safer, more efficient, and always available.

Often, your on premises domain controller servers may be vulnerable to compromise due to employee mistakes, lax security configuration, and a host of other factors. On the other hand, transitioning your domain controllers to the cloud eases your maintenance costs, automates your computing, and generally guarantee the safety of your systems.

Microsoft also recommends that you migrate from Active Directory to Azure Active Directory (Azure AD). Evidently, Azure AD is a comprehensive cloud identity and access management solution for maintaining directories, providing access to on-premises and cloud apps. In addition, it safeguards identities from security threats.

Multi factor authentication, conditional access rules, identity protection, identity governance, and privileged identity management are just a few of the security features available in Azure AD to help protect identities.

7. Consider using Microsoft Defender for identity protection

It’s true that many organizations operate a hybrid identity model in their normal setting or as they transition to the cloud. Often, Azure AD Connect is used at this point to synchronize their on-premises Active Directory.

Therefore, while such a configuration exists, Microsoft recommends that you use Microsoft Defender for Identity for cloud powered protections for on premises identities.

Deploying the Microsoft Defender for Identity protection on domain controllers and Active Directory Federation Services (AD FS) servers ensures a highly secure, one-way connection to the cloud service. This should be done via proxy and only to the specific authorized endpoints. This is particularly helpful, since it mitigates the danger of connecting these servers to the cloud service and allows businesses to take advantage of the enhanced security provided by Defender for Identity.

Finally, Microsoft also recommends that you protect your on-premises servers with Microsoft Defender for Servers for cloud powered endpoint detection.

Domain Controller Security Best Practices - Hardening (Checklist) Conclusion

If a bad actor has unrestricted physical access to your computer, it’s not your computer anymore—Immutable Laws of Security Law 3.

To sum it up, domain controllers play a crucial role in the network architectures of many organizations as they are used for user authentication and authorization as well as a central storage for account information. They are very key elements of a network that, unfortunately, when compromised, would have a great negative impact on the whole network infrastructure.

With this in mind, organizations and network administrators must therefore ensure that they follow the best security practices to ensure that their domain controllers are hardened and immune to any attack. 


Try InfraSOS for FREE

Invite your team and explore InfraSOS features for free

Josiah Mutuma

Josiah Mutuma

Josiah is a tech security expert and has been a writer for over 5 years. Follow this blog to learn more on Microsoft and Cyber security.

Leave a comment

Your email address will not be published. Required fields are marked *