I build a number of large enterprise-scale Active Directory domains, so I thought it would be useful to write up the basic plan of the principles that I always adhere to when completing a design for a customer. These principles are built on the Microsoft standards, and provide a greenfield environment for the customer to then apply their specific configuration to.
Secure By Default – Tier Admin Model
The purpose of the Active Directory Tier Model is to protect identity systems using a set of buffer zones between full control of the Environment (Tier 0) and the high-risk workstation assets that attackers frequently compromise.
The Tier model is composed of three levels and only includes administrative accounts, not standard user accounts:
- Tier 0 – Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory Forest, Domains, or domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they are all effectively in control of each other.
- Tier 1 – Control of enterprise servers and applications. Tier 1 assets include server operating systems, cloud services, and enterprise applications. Tier 1 administrator accounts have administrative control of a significant amount of business value that is hosted on these assets. A common example role is server administrators who maintain these operating systems with the ability to impact all enterprise services.
- Tier 2 – Control of user workstations and devices. Tier 2 administrator accounts have administrative control of a significant amount of business value that is hosted on user workstations and devices. Examples include Help Desk and computer support administrators because they can impact the integrity of almost any user data.
The diagram below shows how each Tier can control resources.
We then look at Logon Restrictions, so what can an account in each Tier logon to. The principle behind this is that we don’t want our Tier 0 accounts to be able to logon to Tier 1 or 2 resources, which might have internet access and be more vulnerable
This table highlights the control and logon restrictions in place with the Tier admin model
|Tier 0 Admins||Can manage and control assets at any level. For example Domain Admins||Can only interactively logon to resources in Tier 0.|
|Tier 1 Admins||Can only manage and control assets in Tier 1 and 2. For example Server Operators||Can only interactively logon to resources in Tier 1.|
|Tier 2 Admins||Can only manage and control assets in Tier 2. For example Workstation Admins||Can only interactively logon to resources in Tier 2.|
Clean Source Principle
The clean source principle is simple in essence but require a greater understanding of the relationships of an asset and perform a dependency analysis of the asset to discover all of the security dependencies of that asset.
If we look at that in a more visual aspect;
What does this actually mean though?
An attacker that compromises A gets access to everything A controls (including B), and everything B controls (including C). Using the language of security dependencies on this same example, both B and A are security dependencies of C and have to be secured at the desired assurance level of C in order for C to have that assurance level.
For IT infrastructure and identity systems, this principle should be applied to the most common means of control including the hardware where systems are installed, the installation media for the systems, the architecture and configuration of the system, and daily operations.
Applying the clean source principle to installation media requires you to ensure that the installation media has not been tampered with since being released by the manufacturer (as best you can determine). This figure depicts an attacker using this path to compromise a computer:
Clean Admin Design
Applying the clean source principle to the system architecture requires you to ensure that the system is not dependent on lower trust systems. A system can be dependent on a higher trust system, but not on a lower trust system with lower security standards.
As an example, its acceptable for Active Directory to control a standard user desktop but it’s a significant escalation of privilege risk for a standard user desktop to be in control of the Active Directory.
The control relationship can be introduced through many means including security Access Control Lists (ACLs) on objects such as filesystems, membership in the local administrators group on a computer, or agents installed on a computer running as System (with the ability to run arbitrary code and scripts).
A frequently overlooked example is exposure through logon, which creates a control relationship by exposing administrative credentials of a system to another system. This is the underlying reason why credential theft attacks, such as pass the hash, are so powerful. When an administrator logs in to a standard user desktop with Tier 0 credentials, they are exposing those credentials to that desktop, putting it in control of AD, and creating an escalation of privilege path to AD.
Due to the large number of assets that depend on identity systems like Active Directory, you should minimize the number of systems your Active Directory and domain controllers depend on.
In part 2 we will look at Privilege Access Workstations