Taking the right steps to secure your Active Directory (AD) has never been more important. Because AD controls who can get into your network and what they can do once they’re inside, failure to implement proper controls will dramatically increase your risk of costly breaches and extended downtime.
But what does a broad, defense-in-depth Active Directory security look like? At high level, your goals are to:
- Minimize your attack surface area by cleaning up your Active Directory and keeping it orderly.
- Gain clear visibility into activity across your IT environment so you can promptly spot and respond to threats.
- Be prepared to recover from both accidental changes and full-on disasters to minimize their impact on the business.
This blog post details eight best practices that can help you achieve these goals and secure your Active Directory.
1. Clean up the IT environment and keep it clean.
The first step to secure your Active Directory is attack surface reduction. Multiple Active Directory security best practices can help here, including the following:
Declutter your Active Directory.
A simpler structure is easier to understand and manage, so start by cleaning up anything you don’t need. Consider reducing the number of forests and domains, and ensure that you have the right trusts between them. Then identify and remove unnecessary Active Directory security groups, since they make it harder to understand permissions and give adversaries opportunities to escalate their privileges. In addition, disable and then delete any AD objects that are unused or violate policy, such as user and computer accounts that have not logged in for 90 days.
Streamline and automate ongoing cleanup.
Once you get your AD in optimal shape, the best way to keep it there is to build processes for identifying and remediating issues. Automate as much as possible. For example, it’s vital to establish a workflow for deprovisioning users who are leaving the company that ensures their accounts are promptly disabled or deleted, removing the accounts from all groups and distribution lists, and removing remote VPN access. In addition, be sure to set account expiration dates when creating accounts for temporary staff such as contractors.
Implement both patch management and vulnerability management.
Another way to reduce your attack surface area is to ensure that your Windows Server operating systems and other software are up to date on patches and that you’re using only versions that are fully supported by the vendor. But even if a system is fully patched and updated, misconfigurations can leave it open to attack.
Accordingly, to secure your Active Directory, you also need to identify and remediate those improper settings through vulnerability management. This process can be quite complicated and time consuming. There are hundreds or thousands of settings to worry about, and it’s not always easy to know what values should be assigned. For example, which events should be logged? What types of firewall connections should be allowed? Which users should have to complete a multifactor authentication (MFA) step, and under what circumstances? The answers depend heavily on your organization’s unique IT environment, priorities, risk tolerance and other factors.
For help with vulnerability management, IT teams often rely on long checklists of settings based on best practices and industry standards, such as Microsoft’s Security Compliance Toolkit, the Center for Internet Security (CIS) benchmarks and the U.S. Department of Defense Security Technical Implementation Guides (STIGs). Dedicated tools are also available that can automate some of the work and provide scorecards assessing an organization’s compliance with standards.
Avoid weak authentication protocols.
Another key strategy to secure your Active Directory is to reduce or eliminate the use of the older and weaker NTLM authentication protocol. NTLMv1 dates back to Windows NT 3.1, and the updated NTLMv2 protocol was introduced a few years later. Because of its design and its reliance on the outdated MD4 cryptographic hash function, NTLM is very vulnerable to brute-force attacks, pass the hash attacks and more.
Although Microsoft replaced NTLM with Kerberos as the default authentication protocol in Windows 2000, NTLM — especially v1— remains a huge security vulnerability for any IT environment where it is enabled. But since important business applications and processes might will be relying on NTLM authentication, don’t rush to simply disable it. Instead, determine exactly where it’s being used and work to systematically reconfigure or replace the applications that need it. Third-party solutions can help streamline the implementation of this Active Directory security best practice.
Protect your domain controllers.
Every Active Directory environment has at least one domain controller (DC), and most have more than one. DCs provide the authentication and authorization services that enable users and processes to access IT resources, which makes them a top target for cyberattacks. Accordingly, it’s essential to do everything you can to protect your domain controllers. In particular, be sure to:
- Limit who has local administrative rights on each DC and minimize the accounts that can log in interactively. In addition, strictly adhere to best practices for password complexity and expiration for all accounts that can access a DC.
- Install only applications and services that are essential for the DC’s functionality and security.
- Minimize network access to all your domain controllers and never permit a DC to access the internet.
- Tightly control physical access to all DCs.
2. Enforce least privilege.
Another key to reducing your attack surface area is to enforce the least-privilege principle. Indeed, least privilege is perhaps the most fundamental of all Active Directory security best practices. By granting each user exactly the access they need to do their job, no more and no less, you limit the damage that user can do either deliberately or accidentally. Moreover, you limit the power the account delivers into the hands of an adversary who compromises it — including how far a ransomware infection can spread using the account.
A core technique for implementing least privilege is to place users with similar roles (such as all helpdesk admins or all HR staff) into an Active Directory security group and manage them together, rather than directly assigning permissions to each account in an ad-hoc fashion. This strategy simplifies the permissions structure, making it far easier to understand exactly what access each user has been granted and to empower data owners to regularly perform permissions review and attestation. Moreover, it help you keep rights up to date as new applications are deployed, individuals change roles within the organization, and so on.
Don’t limit your attention to accounts assigned to individuals. Any IT environment also has service accounts, special user accounts that applications and services use log on and perform actions in your IT environment. All too often, service accounts have far more permissions than they actually need. Common reasons for this overprovisioning include blithely accepting the permissions requirements specified by the application vendor, failing to properly work through operational challenges, and simply cloning an existing service instead of creating a new one with the appropriate set of permissions. Taking the time to ensure that service accounts have only the permissions they actually need can dramatically reduce your attack surface area.
3. Pay special attention to highly privileged accounts.
Accounts that have access to sensitive systems and data require additional controls in addition to strict enforcement of least privilege to help secure your Active Directory. This includes both admin accounts and many service accounts:
Admin accounts
Establish an effective privileged access management (PAM) strategy. Often the best approach is to invest in a third-party PAM solution helps you control the process of granting privileged credentials and also manage and audit the activity of privileged accounts. Whenever possible, instead of permanently granting elevated privileges to an account, empower users to complete tasks by assigning temporary membership in the required security groups and removing it automatically at the designated end date/time. Requiring multifactor authentication (MFA) can make it harder for attackers to use stolen credentials in your network, so it’s especially important to mandate MFA for accounts attempting to access sensitive IT resources.
In addition, closely control which endpoints privileged accounts can log on to. Administrators should never use their privileged accounts to log into workstations, not even their personal machines, because doing so leaves their password hash in memory for attackers to steal and use in pass the hash attacks. (This is important even if you have a PAM solution in place because there is still a window of vulnerability before the admin credentials are reset.) Instead, privileged accounts should only log into secure privileged account workstations (PAWs).
Finally, access to servers should be based on a user’s roles; for instance, SQL admins should be able to access only SQL Server machines and not any other servers.
Service accounts
After you reduce service account permissions in accordance with least privilege, you may find that some service accounts do actually require some elevated privileges. These situations warrant special precautions. You should never make a service account a member of a standard administrative group, such as the local Administrator or Domain Admins group. Better options are to run the service under the LocalSystem account or to create a custom group for the service account and explicitly deny access to other accounts for that group. In addition, it’s often prudent to configure service accounts so they can log on only during a specified period during the day.
Moreover, whenever possible, use managed service accounts (MSAs) — either standalone MSAs (sMSAs) or group MSAs (gMSAs). Organizations often fail to change service account passwords regularly (or at all!) because of the hassle and risk involved. As a result, an adversary who compromises a service account’s credentials will retain access to the environment for a long time. MSAs provide automated password management to ensure that service account passwords change on a regular basis, limiting their value to attackers. In addition, gMSAs are restricted from being used interactively, adding a layer of protection to help secure your Active Directory without any effort on the part of your IT team.
4. Implement attack path management and attack path monitoring.
The preceding best practices will do a great deal to secure your Active Directory. But the reality is, Active Directory is a complicated beast. In particular, AD allows groups to be members of other groups, and the nesting can go multiple layers deep (group A is a member of group B which is a member of group C). You can even nest groups that aren’t part of the same domain. Add in years of technical debt from previous builds of Windows Server, high turnover in IT staffing and a global shortage of AD security expertise, and the result is often a highly complex Active Directory that is at high risk because it is nearly impossible to determine exactly who has elevated permissions in your environment.
Even more alarming, it can be easy for adversaries to elevate their permissions without being noticed. In fact, in many IT environments, an adversary who compromises a regular user account can often become a Domain Admin in just a handful of steps! The only way to understand and block these attack paths is through attack path management and attack path monitoring.
Attack path management exposes the complex chains of abusable privileges and user behaviors that create direct and indirect connections between computers and users, enabling an adversary to elevate their privileges to control over the AD domain. Moreover, it identifies the choke points, the critical last segments in the attack paths. By closing off those choke points, you block the attack paths that rely on them, protecting your critical assets.
However, organizations often cannot quickly remediate some of the choke points because of the risk of disrupting important business processes, such as a critical application that relies on a particular permission. Therefore, it’s crucial to also implement attack path monitoring — continuously watching to see if any attack paths are actually being leveraged so you can take action promptly.
For more information, see the ebook, “Level up your Active Directory security with attack path management.”
5. Collect and consolidate audit data from multiple sources.
Using the preceding strategies can dramatically reduce your attack surface area to help secure your Active Directory. But even the best defense strategy cannot guarantee that no attacker will penetrate your network, or that no insider will ever misuse their privileges deliberately or make a serious mistake that leads to downtime or data loss.
Therefore, you also need to collect comprehensive audit data about activity across your IT environment. Microsoft logs contain a great deal of valuable information, but they are not sufficient to secure your Active Directory. You also need to collect critical audit information that is not captured by system-provided logs. For example, native logs often record that a change happened, but not the critical who, what, when, where and workstation details or the vital before and after values.
Moreover, all that data must be consolidated and normalized to provide the context you need to quickly and accurately spot threats and conduct thorough forensic analysis across all stages of an event. The cryptic data in system-provided logs needs to be translated into a simple, normalized format and combined with additional audit information to deliver a clear, 360-degree view of all related activities across users and resources, both on premises and in the cloud.
For more details about the limitations of native logs and what to include in the scope of your auditing, reference the blog post, “Active Directory auditing: What it entails and how to implement it effectively.”
6. Spot and investigate suspicious activity promptly.
The purpose of collecting, consolidating and normalizing audit data is, of course, to spot threats in time to take action to prevent or at least minimize damage to your organization. As with many of the other best practices detailed above, automation is essential here: There is far too much activity in even the smallest Active Directory environment to spot threats effectively by manual means. Rather, you need an Active Directory auditing solution designed to help secure your Active Directory.
One of the most important types of suspicious activity to look for is attempts at privilege escalation. A common way that attackers gain elevated privileges is by becoming members of built-in admin groups. The most powerful of the groups include Enterprise Admins, Schema Admins and Domain Admins. But it’s equally important to keep a close eye on groups at the local Windows system level, such as Administrators, Backup Operators, Power Users and Hyper-V Administrators. Note that adversaries can elevate their privileges not only by making direct changes to privileged groups (which can be tracked in native security logs), but also by adding themselves as members to nested groups (which Windows servers do not log). At a minimum, you need to get real-time alerts on changes to the membership of any of these groups. Ideally, implement a solution that can prevent anyone from making such changes in the first place.
In addition to privilege escalation, you should also look out for other suspicious activity, including the following:
- Unusual logons to sensitive servers after regular business hours
- Account lockouts, as well as a successful logon after several failed attempts
- Creation of new AD accounts
- A change to the password of a powerful or sensitive account
- Direct assignment of administrative rights to a user
- Use of Kerberos tickets with long lifetimes
- Excessive LDAP queries
- Attempts to obtain a copy of the NTDS.dit file, which stores password hashes
- Changes to registry settings
Whenever you spot a threat, you need to be prepared to investigate it quickly and respond appropriately. You need to be able to quickly determine where the breach originated, how it unfolded, and exactly what systems and data were involved. That way, you can hold individuals accountable for their actions and take steps to prevent similar incidents from occurring in the future to further secure your Active Directory.
7. Pay special attention to Group Policy.
You might have been wondering about the conspicuous lack of attention to Group Policy in all the preceding discussion of how to secure your Active Directory. Certainly it could have been mentioned before now, but the truth is, Group Policy is so powerful that it merits an entire section of its own.
Group Policy is an integral feature of Active Directory, designed to empower IT admins to centrally manage users and computers across the domain. For example, they can use Group Policy objects (GPOs) to enforce strong password policies, prohibit the use of removable media drives, deploy software, disable weak authentication protocols, and run particular scripts on computer startup or shutdown. In fact, there are literally thousands of settings available to help secure your Active Directory.
This incredible power makes Group Policy a useful tool for enhancing productivity and strengthening security — and also makes it a top target of hackers, who exploit GPOs to steal valuable data and deploy malware, and even destroy the evidence of their activity afterwards. For instance, a single change to a GPO could enable users to insert a USB drive that releases ransomware into your systems.
Group Policy is inherently vulnerable because the design of Active Directory ensures that every user can see the policies you have, where they’re applied and who has access to them. Plus, to simplify administration, IT teams usually assign descriptive names to GPOs, a gift to any hacker looking to hone their attack.
Still, there are proven strategies to reducing your risk. Effective Group Policy management starts with careful review of your GPOs. Make sure they are clear and well organized; in particular, actively look for redundant or conflicting settings and clean them up. In addition, just as you want to avoid directly assigning one-off permissions to particular users, you also want to avoid creating GPOs that apply settings only to certain users on certain computers; such complexity makes it harder to understand both what your Group Policy is supposed to be doing and what it is actually doing.
Remember that a GPO has no effect until it is linked to an Active Directory container, such as a site, domain or organizational unit (OU), so to understand the impact of a GPO, you need to determine where it is linked. Also keep in mind that Group Policy review is not a one-and-done effort. You should carefully review your GPOs both on regular schedule and any time there are significant changes to your IT ecosystem.
Yes, there’s more! You also need to uncover exactly who has the ability to create, modify and delete GPOs. All members of the Domain Admins and Enterprise Admins groups have that power, but most organizations delegate GPO management to other admins, such as server teams or desktop teams. All those accounts need to be managed and tracked closely, as detailed in best practice #3 above.
Finally, to keep your Group Policy in order and secure your Active Directory, build approval-based Group Policy workflows that help ensure all changes are both authorized and accurate. Even with that in place, however, you still need to ensure that you can quickly spot and revert any improper or unauthorized changes. Ideally, you should be able to prevent any changes from being made to your most critical GPOs.
8. Have a solid AD backup and recovery strategy.
Granular recovery
No matter how many steps you take to secure your Active Directory, issues are inevitable. A hurried admin might accidentally modify or delete an important user account, disrupting an urgent business task. Or adversaries could slip into your network and change a critical GPO or add themselves to the Domain Admin group, putting security at immediate risk. Therefore, it’s critical to have the ability to granularly restore specific objects and attributes, quickly and efficiently.
Native tools can help here, but they are not a complete solution. In particular, the AD Recycle Bin was designed to offer a quick and easy way to quickly restore a limited set of deleted AD objects, for a limited period of time. But it was never intended to be a comprehensive AD recovery strategy. For example, if the CEO’s user account was changed rather than deleted, the Recycle Bin cannot help you restore it in time for the important client meeting that’s about to begin. If an account was deleted more than 30 days ago, you’re also out of luck; you’ll have to rebuilt it from scratch when the employee comes back from leave and deal with the fallout from the delay. Accordingly, to secure your Active Directory and ensure business continuity, you need a third-party solution that enables quick granular recovery.
Disaster recovery
As serious as angry calls from a CEO unable to log on might be, other scenarios are far worse. For example, malware hidden in a standard business application can bring down your entire network in minutes, as happened to shipping giant Maersk during the infamous NetPetya attack. Or an overworked user might forget their security awareness training and click on an attachment to a phishing email, unleashing ransomware that encrypts your DCs in minutes. Similarly, a natural disaster or even a critical mistake by a hurried admin can also bring down your entire Active Directory forest.
Because of the vital role AD plays in authentication and authorization, every second that your Active Directory is down, your business is down as well. The costs can be staggering: 40% of enterprises say that a single hour of downtime costs $1 million to over $5 million. In a worst-case scenario, losses can reach millions of dollars per minute.
What does an effective Active Directory disaster recovery strategy look like? Well, manual recovery is possible, but it is prohibitively slow. Indeed, Microsoft’s AD recovery procedure includes 40+ steps that must be performed on each DC you plan to recover, correctly and in the proper sequence, and the process must be coordinated across the forest. In addition, many of the steps aren’t operations that AD administrators are familiar with; they are tedious, often command-line based steps, so it’s very easy to make mistakes and have to start over.
Reduce your AD attack surface.
A comprehensive Active Directory disaster recovery solution can be invaluable. It should automate the recovery process as much as possible, including not just restoring individual DCs but also coordinating the configuration effort across those DCs to ensure that Active Directory functions properly after the recovery.
The solution should also offer a variety of backups options. In particular, look for a solution that offers backups that include only AD-specific components; excluding the many other components in a native System State or bare metal recovery (BMR) backup dramatically reduces the risk of reinfection by malware after the recovery process to help secure your Active Directory. In a hybrid AD environment, you also need a backup strategy for cloud-only objects and attributes, such as Microsoft 365 licenses, application role assignments, Office 365 and Azure AD groups, and Azure AD MFA settings and Conditional Access policies.
Also look for flexible recovery options so you can choose the method that works best in a given situation, whether that’s phased recovery, restore to a clean OS or BMR. Make sure you can restore to a clean OS on any machine: a physical machine, an on-prem virtual machine or a cloud-hosted VM. To further secure your Active Directory, choose a solution with automated malware detection that minimizes the risk of reintroducing infected files to recovered DCs.
Conclusion
Following the best practices outlined here will help you secure your Active Directory. However, remember that security is not a one-time configuration event but an ongoing process. In addition to actively auditing for suspicious activity, be sure to periodically review the membership of security groups, clean up inactive and disabled accounts, keep systems patched and properly configured, and identify and remediate attack paths in your environment. If you’re interested in going even further in your quest to secure your Active Directory, consider implementing a Zero Trust model.
