Active Directory Security – 5 Steps to Secure AD

In this guide about Active Directory security, we’re going to detail five steps that IT admins need to follow to secure Active Directory environments in an organization. There are many best practices you’ll need to be familiar with to ensure Active Directory security, including restricting the use of privileged accounts, monitoring Windows Event Log for signs of Active Directory security compromise, and more.

Why Active Directory security is important for IT admins

Many organizations use Microsoft’s Active Directory as their central tool for the authentication and authorization of their users and computers. Active Directory contains a database that holds all user accounts, administrative accounts, workstations, servers, and other objects. This database is stored on a special type of server called a domain controller (DC), which many attackers will focus their attacks on when trying to compromise an environment.

Because of its critical place in most organizations, Active Directory security is of the utmost importance, especially since nowadays many Active Directory environments are exposed to the Internet. Your on-premises Active Directory environment can be extended to the public cloud by using Azure Active Directory (Azure AD), which will give your organization more capabilities, but this also makes it more visible to the public Internet and as such increases its visibility.

Before you make the first change, you’ll need to decide on how you’ll document all your changes regarding Active Directory security. This will be critical, both from a troubleshooting point of view and for your peers to be able to continue where you left off. It’s not a question of if something will not work, but how much effort you’ll need to invest to revert to the last known good state.

1. Restrict use of privileged domain accounts

There’s little that privileged accounts cannot do, which makes them a primary target of attackers. Implementing the best practices described in the following steps will allow you to improve Active Directory security.

Limit privileged group membership

At a minimum, you need to ensure that your user accounts are separated from your administrative accounts. Standard user accounts enable your staff to carry out their everyday tasks like email and business apps, while administrative accounts can carry out a whole range of changes depending on their group memberships and access privileges. The most extreme example is the destruction of your whole Active Directory.

For the most privileged groups, the Enterprise Admins, Schema Admins, Domain Admins, and Administrators groups, you need to ensure that they only contain the built-in administrator account. No day-to-day user accounts should be anywhere near them.

Moreover, make sure you implement Microsoft’s recommendations on securing Enterprise Admins (Step-by-step instructions for removing all members from the Enterprise Admins group), d-Domain Admins (Step-by-step instructions for removing all members from the Domain Admins group) and Administrators (Step-by-step instructions for removing all members from the Administrators group) groups to reduce the attack surface of your privileged Active Directory groups.

Remove privileged AD groups from workstations and member servers

Once the privileged groups have been secured, you’ll make changes to ensure that your local admin groups are protected from your privileged AD groups.

First, add the Enterprise Admins and Domain Admins groups to all Organizational Units (OUs) which are linked to member servers and workstations:

• Deny access to this computer from the network
• Deny log on as a batch job
• Deny log on as a service
• Deny log on locally
• Deny log on through Remote Desktop Services

Then you’ll add the Active Directory Administrators group to all OUs which are linked to member servers and workstations:

• Deny access to this computer from the network
• Deny log on as a batch job
• Deny log on as a service

Then you’ll add the Administrators group to all your domain controllers OUs in all your domains throughout your forest:

• Access this computer from the network
• Allow log on locally
• Allow log on through Remote Desktop Services

This will ensure that your privileged accounts cannot – either maliciously or through human error – cause damage to your member servers and workstations. Also, consider using service accounts like standalone Managed Service Accounts (sMSAs) and Group Managed Service Accounts (gMSAs) to manage permissions for your services on your member servers and workstations and separate them by function. Your app A should not share an account with your app B, unless you have a very good reason to do so.

Implement approval process for accessing privileged AD accounts

Depending on your needs, which often will be determined by your organization’s size and budget, you have multiple options to implement an approval process for accessing privileged AD accounts.

For smaller environments, a manual process might be suitable. Your domain admins will request access from a small group of trusted persons – or even a single person – who will then add them to the relevant groups. It’s an incredibly cheap way of tackling this issue, but this method also has some serious downsides that need to be considered:

• Special care is required to ensure that privileged access is again removed. Since this is a manual process, it can be easily overlooked.
• The burden on the manual approvers might turn into privileged access being permanently assigned since the administrative overhead cannot be sustained.
• Human error might cause the Principle of Least Privilege to be missed.

PowerShell scripts and Task Scheduler allow for this to be streamlined, but it still remains a mostly manual and ad-hoc process that will only satisfy the smallest and most disciplined organizations.

Just Enough Administration (JEA) expands on the above method. JEA is a PowerShell solution provided by Microsoft, allowing you to specify what specific actions can be taken by your domain admins and other trusted users. You can specify the exact cmdlets, functions, and external commands that you want to permit your selected users to execute. Take a look at Microsoft’s documentation on Just Enough Administration.

For larger environments, you can implement a fully comprehensive solution called Privileged Access Management (PAM) which is a component of Microsoft Identity Manager (MIM). PAM allows you to set security controls like Just-In-Time Administration (JIT), granting your domain admins time-limited access with just enough access to get the job done.

Bear in mind that while PAM is a very capable tool, it is a complex piece of technology to implement, requiring multiple servers and a lengthy planning and deployment process to get it right. See Microsoft Docs’ Privileged Access Management for Active Directory Domain Services to get a better understanding of PAM’s capabilities and requirements. Then, when you’re ready, make sure to check out Russel Smith’s guide on Windows Server 2016: Set Up Privileged Access Management to deploy PAM in your organization.

2. Use secure administrative hosts for privileged AD access

Your servers, especially your domain controllers and other highly sensitive systems, should not be used for routine administrative tasks. For that, you need to consider deploying secure administrative hosts and protect them adequately. These workstations should contain all the tools and access required to carry out your typical administrative tasks.

Remember the following statement: “Never let your privileged users make use of an untrustworthy host!”

You need to ensure that your well-protected privileged domain user accounts don’t get compromised by a substandard administrative host. Your AD security is only as strong as its weakest link.

Make sure to limit logins to selected accounts and consider enforcing multi-factor authentication (MFA) on those accounts. Consider using Smart Cards, especially if you are happy to host this part of your infrastructure yourself. See Microsoft’s Smart Card Technical Reference for further information.

Alternatively, take a look at Getting started with the Azure Multi-Factor Authentication Server, especially if you are already using other Azure or Microsoft 365 services. Make sure to check out other vendors since your choice of identity provider will be critical for the protection of your ad users. There’s a great choice out there and you should choose one who fits your unique requirements.

Also, take special consideration on where your secure administrative hosts will be located. If they are dedicated physical machines then you need to ensure that they are in a tamper-proof location. If you plan on using virtual machines, then ensure that you place them on secure hosts and also consider how your privileged users will connect to them (on-premises or via the public Internet, or somewhere in-between). See Microsoft’s Implementing Secure Administrative Hosts for further information.

Implement virtualization-based security

Next, enable Hypervisor-protected code integrity (HVCI) on all your secure administrative hosts – and possibly all your other computers as well – to limit attack paths on your systems. It’ll allow Windows to separate a region of memory where it runs security solutions to fend off malware trying to exploit the Windows Kernel. You can turn it on manually or follow Microsoft’s Enable virtualization-based protection of code integrity to deploy it via Group Policy.

3. Monitor Windows Event Log for signs of Active Directory security compromise

Your event logs are only as useful as what you’ll do with them. Checking them for signs of your Active Directory security being compromised is a crucial part of your role as a domain admin.

There are numerous ways to centrally store all of your Active Directory security event logs, analyze them, and – if you want to – trigger an automated action to prevent or remediate a security incident. They range from a simple self-hosted Syslog server to a more advanced solution like Elastic Stack or Microsoft Sentinel, depending on your budget and appetite for getting hands-on.

Please see Microsoft’s Monitoring Active Directory for Signs of Compromise support page for further information. Also, see Microsoft’s Events to Monitor information page for a comprehensive list of event IDs to monitor. This list contains almost 400 different event IDs, so start with the ones in the High and Medium categories and monitor the ones listed as Low as per your unique requirements.

4. Audit Active Directory security periodically for misconfigurations and over-privileged users

At a minimum, you should periodically audit events in your Active Directory security log. Checking on your privileged user activities can be done by enabling some or all of the following audit policies:

• Audit account logon events
• Audit account management
• Audit directory service access
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events

You can deploy them manually or via a Group Policy.

Next, set up an access review procedure to verify your domain’s admin privileges, ensure that accounts haven’t become stale due to long-term leave or users having left your organization altogether. By carrying out regular access reviews, you can ensure that you close those gaps. It’ll also allow you to verify that your domain admin rights are just enough to get the job done.

Creating a default configuration for each privileged user class and comparing them can help you achieve this. See Microsoft’s Basic security audit policies for further information on how to plan for and implement an effective audit policy.

5. Harden domain controllers according to Microsoft best practices

Since Active Directory security is one of the most critical components of your infrastructure, your domain controllers should not run any other services or software. With virtualization technologies readily available and for any budget, creating dedicated virtual machines (VMs) per function will create an additional layer of delegation allowing you to limit breaches in case of a successful cyber-attack. You can read our best practices for installing Active Directory domain controllers in a virtual machine on Petri.

One of your servers being breached won’t automatically expose all your services and data to the attacker(s). It’ll also allow you to control your hardware resources by specifically sizing your domain controllers for their workload. Your DCs can host additional roles like Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP), especially since they tightly integrate with Active Directory.

Next, consider using the Server Core installation option in Windows Server when deploying your domain controllers. Server Core comes without the desktop experience (as in no GUI), which further reduces your attack surface.

Remote Desktop Protocol (RDP) connections to your domain controllers should be restricted to both select privileged users and secure administrative hosts. Group Policy and Internet Protocol Security (IPSec) rules will enable you to control who can access your DCs, and from where. See Microsoft’s blog entry on Securing RDP with IPSec for further information.

Lastly, consider blocking Internet access on your domain controllers if necessary. You need to decide if your DCs require Internet access and if you are happy with the risks that come with it.

Backup

How you’ll back up your DCs might depend on your current backup solution. If it offers this functionality then be sure to use it to your advantage. Alternatively, using the built-in Windows Server Backup provides you a free and efficient method to backup your Active Directory DCs. It isn’t installed by default, but it can easily be added through the Add Roles and Features Wizard. See Microsoft’s guide on How to install Windows Server Backup for further instructions.

Once installed, launch Windows Server Backup and familiarize yourself with the options. Make sure to select the best option for you, depending on if you want to run a once-off backup or schedule it to run at regular intervals.

When you’re ready to kick off your backup, make sure you either select Full Server (recommended) or System State under Custom to include your Active Directory database and associated data. Also, backup all your DCs, not just a single one. This will decrease the risk of losing your Active Directory database in case of a breach, especially a ransomware attack.

Finally, make sure to regularly run disaster recovery tests by restoring your Active Directory to verify that your backups work. A backup is only as good as its successful restore.

Apply security template

Microsoft’s Group Policy gives you great functionality and flexibility when it comes to deploying your preferred security settings throughout your environment as well as keeping it this way (it refreshes and rectifies your policies at regular intervals). It’s not the easiest tool to use, though, both in terms of which policies you should set and how you should deploy them. So, once you venture beyond a handful of Group Policy objects (GPOs), then your environment can quickly become a big frustrating mess.

The Microsoft Security Compliance Toolkit is the successor to Microsoft’s Security Compliance Manager 4.0 (SCM), and it allows you to lean on Microsoft best practices to deploy pre-defined security baselines throughout your environment. It includes specific baselines for your domain controllers, enabling you as the security expert in your organization to achieve a high level of security.

Microsoft Security Compliance Toolkit contains the following tools:

• Policy Analyzer (GUI-based)
• Local Group Policy Object (LGPO)
• GPO to PolicyRules
• Set Object Security

The Policy Analyzer tool lets you analyze and compare sets of Group Policy Objects (GPOs), showing you redundant and inconsistent settings between them. Just imagine having dozens or hundreds of GPOs in your environment and trying to troubleshoot an issue you’ve encountered. Whatever hair you happen to have left on your head will either turn grey or disappear altogether. See Microsoft’s New tool: Policy Analyzer page for a good overview of its Policy Analyzer.

With LGPO, which uses a command-line interface, you’ll automate the management of local group policies. You can import and export local GPOs, parse and build registry policies, and more. See Microsoft’s LGPO.exe – Local Group Policy Object Utility, v1.0 page for further information.

The GPO to PolicyRules tool allows you to automate the conversion of GPO backups to Policy Analyzer

The Set Object Security tool enables you to set the security descriptor for just about any type of Windows securable object (files, directories, registry keys, event logs, services, SMB shares, etc). For file system and registry objects, you can choose whether to apply inheritance rules. You can also choose to output the security descriptor in a .reg file compatible-representation of the security descriptor for a REG_BINARY registry value.

In addition, you can download security baselines for Windows versions including Windows 10/11 and Windows Server 2008-2022. Each baseline package contains the following:

• Documentation: It contains detailed descriptions of the settings applied in the security baseline. Microsoft also includes announcements here.
• GP Reports: It includes several HTML reports containing all GP Results for each policy. Very relevant to you are the MSFT Windows Server 2022 – Domain Controller.htm, MSFT Windows Server 2022 – Domain Controller Virtualization Based Security.htm, and the MSFT Windows Server 2022 – Domain Security.htm.
• GPOs: It holds the actual files that you can import through your Group Policy Management console.
• Scripts: It contains PowerShell scripts, allowing you to conveniently get all these settings into your environment.
• Templates: You’ll find here the relevant GPO Administrative Template files in .admx and .adml formats.

Please see the Microsoft Security Compliance Toolkit 1.0 – How to use page for further information.

Update and secure

You have a number of options to tackle your patch management. If you only have a few DCs, then Windows Update might suffice. Bear in mind that this is a fully manual process so make sure that you don’t update and reboot all your DCs simultaneously. Take one, ideally the least important one a test server, and test that all is still good before deploying updates throughout your environment.

Windows Server Update Services (WSUS) is the next step up. It comes free of charge with Windows Server and allows you to fine-tune your targeted devices (servers, clients). Since it’s a good idea and a Microsoft recommendation to patch your domain controllers separately from your other servers, WSUS allows you to target updates to groups of computers by using Computer Groups.

Group Policy allows you to efficiently manage your desired update settings in your domain. Under Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update, modify the following policies with your preferred settings and WSUS server location:

• Configure Automatic Updates
• Specify intranet Microsoft update service location

Fill in your WSUS details in the following format: http://Your_WSUS_Server_FQDN:PortNumber

If you are a larger organization, then you might already be using Configuration Manager. It used to be called System Center Configuration Manager (SCCM), but Microsoft renamed it to Microsoft Endpoint Configuration Manager (MECM). One of its additional strengths lies in its reporting capabilities. It also allows for third-party patches to be deployed.

Please see Microsoft’s Introduction to software updates in Configuration Manager for further information on how to use it to deploy your software updates.

Last but not least, you might want to manage your updates and patches from Azure, Microsoft’s public cloud. Azure Automation Update Management allows you to not only target your DCs hosted in Azure but also your on-premises ones located in your private data centers and office locations.

Bear in mind that this isn’t the most straightforward method to patch your domain controllers since it requires a good bit of preparation. Please see Microsoft’s article on Using Azure Update Management to Automate On-Premises Server Patching for further information.

Finally, ensure that you have a good anti-virus, aka anti-malware, aka anti-spyware (you get the point) solution in place. Smaller organizations will be fine with Microsoft’s Windows Defender antivirus on Windows Server which should be installed by default. Verify this by checking the Server Manager dashboard for your domain controllers.

Larger organizations will want to use a third-party anti-virus solution: There are many options available and everybody will have a different opinion about them, so make sure you do your research. Also, consider using Microsoft Defender for Endpoint, Microsoft’s enterprise endpoint security platform designed to help enterprise networks prevent, detect, investigate, and respond to advanced threats. Please check the Microsoft Defender for Endpoint page for further information and how to implement it.

Summary

There you have it, this completes the first steps of your long and never-ending Active Directory security journey. Make sure you stay up-to-date on exposures and exploits, always test your patches before deploying them throughout your environment, and keep your Windows versions as current as you can if you want Active Directory security to remain optimal.

Related Article:

• How to Access Active Directory