Active Directory Domain Services (ADDS) is the on-premises identity solution that Microsoft released back in 1999. Although Microsoft has been providing updates and extra functionality since 1999 as part of the Windows Server releases, the solutions rely on fewer modern protocols and capabilities, which, if not configured and monitored correctly, can open doors to compromise.
Now when organizations have environments originally architected over 20 years ago, the environment they originally planned for, is not the same today. In this article, we will look at the 8 best practices to secure Domain Controllers.
Table of Contents
Secure Domain Controllers
Nobody intentionally builds an infrastructure with configurations that expose the environment. When it comes to securing your Active Directory Domain Services, you must start by understanding that threat actors tend to perform credential theft and that they target some specific accounts.
Credential theft attacks are those in which an attacker initially gains highest-privilege (root, Administrator, or SYSTEM, depending on the operating system in use) access to a computer on a network and then uses freely available tooling to extract credentials from the sessions of other logged-on accounts. Depending on the system configuration, these credentials can be extracted in the form of hashes, tickets, or even plaintext passwords.
Because the target of credential theft is usually highly privileged domain accounts and “Very Important Person” (VIP) accounts, it’s important for administrators to be conscious of activities that increase the likelihood of success of a credential-theft attack. Although attackers also target VIP accounts, if VIPs are not given high levels of privilege on systems or in the domain, theft of their credentials requires other types of attacks, such as socially engineering the VIP to provide secret information.
Let’s discuss the eight best practices that you can put in place to secure your Active Directory Domain Services (ADDS).
#1. Block Internet Access
No web browser should be used on domain controllers. An analysis of thousands of domain controllers has revealed numerous cases where privileged users used Internet Explorer to browse the organization’s intranet or the Internet.
Launching web browsers on domain controllers should be restricted by policy and technical controls. Further to this, general Internet access to and from domain controllers should also be strictly controlled.
Microsoft encourages organizations to move to a cloud-based approach to identity and access management and migrate from Active Directory to Azure Active Directory (Azure AD) if possible. Azure AD also offers a robust and granular set of security controls to help protect identities, such as multi-factor authentication, Conditional Access policies, Identity Protection, identity governance, and Privileged Identity Management.
If you have regulatory or other policy-driven requirements in your company to maintain an on-premises-only implementation of Active Directory, Microsoft recommends entirely restricting internet access to and from domain controllers.
#2. Secure the Control Plane
The control plane is one of the most critical systems that need to be secured. These include Domain Controllers, certificate servers, federation servers, servers used to sync identities across environments, and servers/services that backup, control configuration, and monitor those systems. This is because these systems can perform changes on those servers.
Microsoft has released guidance specifically to help secure Active Directory Domain Services (AD DS or AD) under the Securing privileged access documentation.
It’s highly recommended that you implement an enterprise access model in the production environment to segregate the critical assets, users, and security groups. This separation helps minimize lateral movement and privileged escalation and enables opportunities for the different access checks to generate alerts that help catch suspicious events.
To further reduce lateral movement capabilities, review the registry locations for the following User Right Assignments on all endpoints and reduce accounts with that access:
- Deny Access To This Computer From The Network
- Deny Log On As A Batch Job
- Deny Log On As A Service
- Deny Log On Through Remote Desktop Services
- Access This Computer From The Network
- Allow Log On Locally
- Allow Log On Through Remote Desktop Services
- Log On As A Batch Job
- Log On As A Service
For example, the domain controller default setting for Allow Log On Locally includes Account Operators, Administrators, Backup Operators, Print Operators, and Server Operators. It is a best practice to have the Print Spooler service disabled for all Domain Controllers.
Therefore, you should also remove Print Operators from having access to Log On Locally on the DCs. Print Operators have other rights for domain controllers, including Load And Unload Device Drivers and Shut Down the System. Be aware that the spooler service is responsible for removing stale print queue objects from Active Directory, so there is a tradeoff between security and the ability to perform print pruning. To address the issue, periodically review and remove stale print queue objects from AD.
For example, you can use Group Policy Objects (GPOs) to change DC configuration and provide access to a security group or user. With a backup account, you can build a DC from a backup and read all the account’s information offline, and Print Operators can install drivers in any server, which means that malicious payloads can be included within the drivers. Also, monitoring applications can change the systems they monitor.
It’s highly recommended that you use a Privileged Access Workstation (PAW) for all privileged users. Check securing devices as part of the privileged access story documentation.
#3. Privileged Access Management
Microsoft Identity Manager (MIM) has a functionality called Privileged Access Management (PAM) that helps organizations isolate privileged accounts using a Bastion environment. This Bastion environment is a separate AD Forest, normally 2-3 DCs, where the Privilege Users log in and use the MIM server to request time-bound privileges to the main production environment.
The diagram below shows a highly available configuration of the MIM PAM environment. Smaller environments that might not be too concerned about availability might be able to use this environment with only 1 DC and 1 MIM Server running all the roles.
To protect the privileged user (referred to as Priv users in the image below), the user logs into the Bastion forest with normal user rights. Then, they access the PAM user interface to request privileged access to the production server.
A special object representing the user that logged in from the Bastion forest is given membership in the production’s privileged group requested for a predefined amount of time. This object is referred to as a shadow principal. When the time expiration is reached, the user is removed from the group.
Whenever possible, use cloud monitoring and configuration management capabilities. With threat intelligence, cross-service collaboration, and AI and ML capabilities such as Microsoft Sentinel (SIEM/SOAR), cloud services can offer much more orchestration, automation, and reporting than on-premises services.
#4. Update Your Domain Controllers
You should run all domain controllers on the newest version of Windows Server that is supported within your organization and prioritize decommissioning of legacy operating systems in the domain controller
population.
You should prioritize decommissioning legacy operating systems in the domain controller population.
#5. Keeping Domain Controllers Current
You should keep your domain controllers current and eliminate legacy domain controllers in your environment, this allows you to take advantage of new functionality and security that may not be available in domains or forests with domain controllers running legacy operating systems.
Although it may seem counterintuitive, you should consider patching domain controllers and other critical infrastructure components separately from your general Windows infrastructure. If you use enterprise configuration management software for all computers in your infrastructure, compromise of the systems management software can be used to compromise or destroy all infrastructure components managed by that software.
By separating patch and systems management for domain controllers from the general population, you can reduce the amount of software installed on domain controllers, in addition to tightly controlling their management.
#6. Upgrade Domain and Forest Functional Level
In Active Directory Domain Services (AD DS), domain controllers can run different versions of Windows Server operating systems. The functional level of a domain or forest depends on which versions of Windows Server operating systems are running on the domain controllers in the domain or forest. The functional level of a domain or forest controls which advanced features are available in the domain or forest.
You should make sure that you upgrade your Domain and Forest Functional Level whenever possible.
Raising the functional level allows the introduction of advanced features, but also limits the versions of Windows Server that can run on domain controllers in the environment.
Now a question that you may ask is, are there any concerns about upgrading Domain or Forest Functional Level?
The answer is NO. Microsoft did a review of over a decade of support calls, and NOT ONE involves a case where changing the Domain or Forest Function Level was responsible as the root cause of any issue.
Learn More: What is the impact of upgrading the Domain or Forest Functional Level?
At this point in time, your domain controllers should all be running at Windows Server 2016 Functional Level. There’s a good chance that future AD features will require a 2016 Domain Function Level.
Learn More: How to raise Active Directory domain and forest functional levels.
#7. Microsoft Defender for Identity
Consider implementing Microsoft Defender for Identity (MDI). MDI is a cloud security solution that monitors, detects, and helps remediate on-premises Identity-based threats. It monitors DCs and AD FS infrastructure for reconnaissance events such as account enumeration, attributes reconnaissance, network mapping reconnaissance, security group reconnaissance, user and IP address reconnaissance, and so on.
MDI also checks for compromised credentials activities such as suspicious modification of the sAMNameAccount attribute, honeytoken activity, brute-force attack, Kerberos SPNexposure, Netlogon privileged elevation attempt, Metasploit framework, VPN connections, WannaCry attack, and others.
Microsoft Defender for Identity (MDI) protects against Active Directory Domain Services (ADDS) type of attacks. It is recommended for all DCs, AD FS, certificates, and other servers to also have Microsoft Defender for Endpoint (MDE) installed since it extends the checks to include server threats.
MDI requires a minimum of one domain service account to work. Microsoft recommends that the account be a Group Managed Service Account (gMSA) since Active Directory will manage the account automatically. This account needs read permissions for all the domains in the forest. If the service has the option to use multiple domain service accounts, which might be needed for multi-domain architecture, MDI has a process to figure out which domain service account to use.
MDI relies heavily on collecting Windows Event logs to perform the required analysis. And if you have Active Directory Federation Services (AD FS) in the environment, then the server’s auditing level on AD FS needs to be set to Verbose.
#8. Secure Active Directory Federation Services (AD FS)
AD FS extends web single sign-on (SSO) functionality across enterprise boundaries to enable customer and partner collaboration when accessing claims-based applications or resources in a partner organization.
Organizations tend to use AD FS if there is a sign-in requirement that is not natively supported by Azure AD, including requiring sign-in using on-premises MFA Server or using a third-party authentication, or needing multi-side on-premises authentication.
For example, smart card use was one of the reasons many organizations used AD FS. Azure AD recently added support for X.509 certificates on smart cards, so Microsoft recommends that you use Azure AD for smart card authentication instead.
Learn More: AD FS Deployment Topology Considerations.
Following are some design considerations that will help secure your AD FS environment:
* Consider upgrading your AD FS environment to Windows Server 2019, if not done already, since it provides many SSO improvements, SAML updates, authentication/policy, and protected login capabilities.
* Place the AD FS servers in a brand-new top-level OU that does not have other servers, which minimizes delegation issues.
* When configuring GPOs to manage AD FS configuration, those GPOs should be solely used for AD FS. This minimizes extra permissions given to support other applications or devices.
* Remove any unnecessary protocols, Windows features, and applications from these servers to reduce the attack surface.
* Use Group Managed Service Account (gMSA) for the AD FS Service.
* The AD FS Servers should be placed on-premises, while the Web Application Proxy (WAP) should be placed in the DMZ, both protected by firewalls in the middle.
* Monitor the AD FS trust with Azure AD for changes made to the federation configuration. You can do this by Configuring Azure AD audit logs to flow into an Azure Log Analytics Workspace and creating an alert rule that triggers based on the log.
See Also: Best Practices for Secure Planning and Deployment of AD FS.
Conclusion
In this article, we described the eight best practices for securing your Active Directory Domain Services (ADDS).
The core vulnerability that allows credential theft attacks to succeed, is the act of logging on to computers that are not secure with accounts that are broadly and deeply privileged throughout the environment. This means that among the requirements to secure Active Directory Domain Services, you need to ensure that you’re reducing the attack surface, by:
- Implementing Least-Privilege Administrative Models.
- Implementing Secure Administrative Hosts.
- Securing Domain Controllers Against Attack.
In addition, you should never administer a trusted system (that is, a secure server such as a domain controller) from a less-trusted host (that is, a workstation that isn’t secured to the same degree as the systems it manages). Also, do not rely on a single authentication factor when performing privileged activities; that is, username and password combinations should not be considered acceptable authentication because only a single factor (something you know) is represented. You should consider where credentials are generated and cached or stored in administrative scenarios.
See Also: Best Practices for Securing Active Directory by Microsoft.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
