Preventing escalation from initial access in your Active Directory (AD) environment to Domain Admins can feel impossible, especially after years of successful red team engagements finding new attack paths each time. While securing your critical assets is challenging, it is not impossible with the right approach.This blog post provides a high-level explanation of how to implement security boundaries in an on-prem AD and Azure environment to protect your critical assets based on the principle of tiered administration, including how BloodHound Enterprise can help you in the process. Finally, we will cover how to organize your AD objects and Azure resources in a structure that reflects your security boundaries.The blog post was produced as a collaboration between Teal and SpecterOps.We recommend that you have a basic understanding of attack paths before reading this blog post, which you can gain from the first section of wald0’s deep dive into the subject: The Attack Path Management Manifesto.Old and new Microsoft recommendationsHistorically, Microsoft recommended using the Enhanced Security Admin Environment (ESAE) architecture to provide a secure environment for AD administrators to prevent full compromise of a production forest in case of compromise of non-admin users. The AD tier model was part of ESAE. Because Microsoft created ESAE before they made Azure, ESAE was explicitly designed for on-prem AD. Thanks to the Internet Archive, you can still read Microsoft’s old version of Securing Privileged Access with EASE, the tier model, etc., here.On December 15, 2020, Microsoft published their new revised version of Securing Privileged Access on Microsoft docs, including the Enterprise Access Model, which encompasses both on-prem, Operational Technology (OT), Azure, and other cloud providers. Microsoft retied ESAE and took down their old recommendations.The principles for Microsoft’s old and new recommendations are effectively the same. They recommend tiered administration with dedicated admin accounts. Admins should use a hardened Privileged Access Workstation (PAW) when performing administrative tasks, and the admin session must require Multi-Factor Authentication (MFA) and Just-In-Time (JIT) restrictions. Deployment of PAWs and other critical assets must comply with the clean source principle.The main difference between the two sets of recommendations is the focus on Azure. The previous recommendations had a strong focus on preventing cached credentials, an extensive security challenge in on-prem environments. Microsoft’s latest recommendations include Azure technologies like Conditional Access, which is highly relevant for Azure as the control panels are Internet exposed.As the core fundamentals of each are the same (limiting access to privilege), we recommend using elements from ESAE as the underlying basis for creating security boundaries in on-prem AD and using Microsoft’s latest recommendations for Azure.In the following sub-sections, we will dive into the tier model from ESAE and the equivalent Enterprise Access Model from the latest Securing Privileged Access.Active Directory administrative tier modelThe purpose of the tier model is to implement security boundaries that will protect critical assets from high-risk devices like regular workstations adversaries frequently compromise.Tier Zero: Critical assets with direct or indirect control over the entire AD forest. Members of Enterprise Admins have direct control, whereas a SCOM admin account has indirect control if DCs have SCOM agents installed.Tier One: Enterprise servers and applications. These systems do not have direct or indirect control of the environment.Tier Two: Workstations and other devices.Assets of a higher tier (closer to zero) can control assets in a lower tier, but not the other way around. For example, Domain Admins in Tier Zero can have the privilege to reset the password of any user account. In contrast, tiering allows the help desk to reset the password of Tier Two users only and not the server admins in Tier One and Zero.The second principle of the tier model restricts users’ login rights such that user accounts are only allowed to login into a single tier. Naturally, Tier Two users cannot log in on critical servers in Tier Zero. Less intuitively, Domain Admins cannot log in on Tier One and Tier Two computers, despite full control over them. This restriction is because user credentials are (in most cases) cached on the computer where the user logs in. A malicious user with administrative rights on that computer can steal these credentials, e.g., using Mimikatz, and impersonate the victim user to log in on other systems where the victim user has access.The consequence of this principle is that employees with Tier Zero access must have a dedicated Tier Zero user and a separate Tier Two account they can use for their regular Tier Two workstation for emailing, web browsing, etc. The principle does not apply only to human user accounts but to any accounts, including service accounts.The yellow arrows in the illustration above indicate that users from a lower tier can log in on systems in higher tiers, but only as required. For example, if you have a file server in Tier 1 that Tier Two users use, the users must have network logon privilege on this server. Still, Tier Two users cannot perform an interactive login on the computer through RDP or any other network protocol, nor have administrative rights on the computer, as that would violate the tiering.As a consequence of the clean source principle, admins with privileged access to a given tier must establish the privileged session from a workstation belonging to the same tier. PAWs are therefore required, and admins cannot use their regular Tier Two workstations for managing Tier One and Zero.Enterprise Access ModelThe Enterprise Access Model is the replacement for the tier model in Microsoft’s latest recommendations:The concept is very similar to AD tiering. The Control Plane is the equivalent of Tier Zero, whereas the Management Plane and the Data/Workload Plane are Tier One. Access to the planes in Tier One and Tier Zero should happen from Privileged Devices and Workstations (aka PAWs), separate from regular User Access and App Access from devices in Tier Two.Privileged access should be completely isolated from user access, as illustrated in Microsoft’s Privileged Access Strategy:How to create security boundariesHow do we change your environments to comply with the concept of tiered administration? And very importantly, how do we do it effectively and securely? This section will cover the overall phases of implementing security boundaries in on-prem AD and Azure. We will use the tiering terminology for both on-prem AD and Azure.Classify your systemsIt is essential first to decide your security boundary, i.e., which tier your assets belong to, and which employees should have access to what assets. You cannot protect your critical assets from non-privileged users if you do not know your critical assets and which users you will allow access to.We recommend starting by implementing a single security boundary to isolate your Tier Zero from the rest of your environment, as Tier Zero gives full control over everything.Identify potential attack paths and set prioritizationIdentify possible attack paths crossing your security boundaries and set prioritization based on how critical the attack path is for the environment.You can use the FOSS (Free and Open-Source Software) version of BloodHound to identify critical attack paths using analysis functions like “Shortest Paths from Domain Users to High Value Targets”. BloodHound also enables you to enumerate the inbound control of your Tier Zero assets:You should aim to find all compromising permissions on Tier Zero assets granted to Non Tier Zero objects and prioritize those. FOSS BloodHound does not provide a severity score for attack paths, but you can prioritize the attack paths manually. An attack path exposed to very few users in the environment is not as urgent to remediate as attack paths that all users can exploit, e.g., if the Domain