Implementing a tiered administration model in Active Directory

Implementing a tiered administration model in Active Directory demands significant effort and perseverance. In case you ask yourself whether it is worth the effort, have a look at Microsoft’s Digital Defense Report 2022. On page 90, it lists the key issues impacting organizations’ cyber resiliency and points out that 98% of customers hit by cyberattacks had “no privilege isolation in Active Directory via a tiered model.” This issue is topped only by organizations not having privileged access workstations (PAWs) in place.

As you consider the variety of recommendations for Active Directory hardening, it’s crucial to maintain focus on the primary goal: enforcing the clean source principle. This principle requires all security dependencies to be as trustworthy as the object being secured. In practice, this means that you should identify all of an object’s security dependencies and make sure that they are as trusted as the object you are trying to secure.

In this article, I will focus on one aspect of the clean source principle: preventing the exposure of high-privileged credentials to lower-tier systems, where attackers could potentially steal and misuse them. This can be achieved through logon restrictions enforced through either Group Policy or Kerberos authentication policies.

Tiered administration and the enterprise access model

Microsoft replaced the tiered administration model documentation with the enterprise access model documentation — which gives the incorrect impression that the latter model replaces the former. The truth is, the evolving security landscape and the complexities of modern IT environments, including hybrid and multi-cloud environments, need to be addressed through the enterprise access model. However, Active Directory remains the main source of authentication in many organizations, and therefore securing AD through tiered administration is a critical prerequisite for implementing the enterprise access model.

In other words: In most organizations, the number of dependencies between Azure, Entra ID and Active Directory makes it impossible to secure one without the other.

In the context of Active Directory and Entra ID, the term “credential” refers to authentication artifacts, typically created or converted to a form required by the authentication protocols available on a computer. The most common examples include password in cleartext or hashed (LM or NTLM hash), certificates, and the corresponding private keys, Kerberos tickets, multifactor authentication (MFA) tokens or primary refresh tokens (PRTs).

Rules for logon restrictions

The underlying rules are as follows:

• Credentials from a higher-privileged tier should never be exposed on lower-tier system.
• Lower-tier credentials can use services provided by higher tiers, but not the other way around.
• Any system or user account that can manage a higher tier is also a member of that tier, whether you intended it to be or not.

These rules are summarized in the following diagram:

Applying Tier 0 rules

When a virtual machine (VM) that will serve as a domain controller (DC) is deployed, these rules must be applied to it from the very beginning of its existence. In particular, a Tier 1 controlled deployment or management system must not be used to deploy or manage any Tier 0 VM. In addition, the virtualization environment hosting the DC VM must be classified as a Tier 0 system and administered accordingly. There are similar effects on backup, antivirus, monitoring and many other areas.

Here are some additional examples of applying the rules:

• A Tier 2 system or user is allowed to log on to a Tier 1 server (e.g., to access some data) or to a Tier 0 system (e.g., to download Group Policies or request certificates).
• A Tier 0 system or user must not log on to a Tier 1 or Tier 2 system.

Understanding the term “log on”

From my experience, the main source of confusion in this context is the term “log on”. When hearing that term, most of us think about sitting in front of the computer and hitting Ctrl + Alt + Del. However, in Windows there are different logon types that accept different authenticators, and some of them send reusable credentials to the destination system while others don’t.

Let me illustrate this through some examples:

• Using RUNAS to open a command prompt in the context of a Domain Admin account (Tier 0) on a workplace computer (Tier 2) results in the Domain Admin’s credentials being exposed to a Tier 2 system. This is because RUNAS is technically an interactive logon.
• Accessing a file server via SMB results in a network logon that does not send reusable credentials to the target system.

A table with many details and a lot of examples is provided by Microsoft.

Logon types and credential exposure

Credentials may be stored in Windows LSASS process memory to provide single sign-on (SSO) to Active Directory resources. Credentials may also be stored on disk in authoritative databases such as the Security Account Manager (SAM), LSA secrets or the Active Directory database. From the attacker’s perspective, credential theft makes sense only if the stolen credentials are reusable, meaning that credentials can be stolen on one computer and reused on another computer. It is obvious that a cleartext password for an Active Directory domain account stolen on one computer can be reused on another member of the same Active Directory forest. The same is true for password hashes (Pass the Hash attacks) and Kerberos tickets (Pass the Ticket attacks). That’s the purpose of SSO in Active Directory.

Attackers take everything they can, and as stealing credentials from lsass.exe is still very common Microsoft has introduced different protection mechanisms for lsass.exe over the years:

• Credential Guard
• Remote Credential Guard
• Additional LSA protection

If you do not have these options enabled, you can reduce your attack surface by blocking credential stealing from the Windows local security authority subsystem.

Implementing these mechanisms is considered mitigation but does not obviate the need to implement a tiered administration model!

Identifying highly privileged accounts and computers (Tier 0)

Tier 0 refresher

Tier 0 means direct or indirect control of identities, systems that can control identities and systems that store identities (even when offline). Tier 0 includes admin and service accounts, groups, and other assets (e.g., computer accounts) that have direct or indirect administrative control of the Active Directory forest, domains or domain controllers, along with all the assets in them. The security sensitivity of all Tier 0 assets is equivalent, as they are all effectively in control of each other.

Unfortunately, there is no definitive list of Tier 0 accounts and computers in Active Directory. Many Active Directory environments were implemented almost 25 years ago, and a lot of recommendations have changed during that period. What most Active Directories have in common is:

• There are too many Tier 0 accounts.
• Responsible admins are unaware of many of those Tier 0 accounts.

This list of privileged accounts and groups is a good starting point for building a list Tier 0 assets. Other regular players include Active Directory Federation Services (ADFS), Active Directory Certificate Services (ADCS) and Entra ID Connect, along with the corresponding service and admin accounts.

However, other Tier 0 assets are not straightforward and therefore harder to identify. You must think like attackers do to reveal hidden and often unintended relationships within an Active Directory environment, as shown in the (simplified) example below:

In this example, the identity management system (IDM) has FULL CONTROL permissions on the domain root level. This was most likely configured to allow the IDM to create and manage accounts anywhere in Active Directory. However, from the attacker’s perspective, it means that compromising the IDM Admin account on the left provides different paths to domain domination:

Reduce your AD attack surface.

See where you’re exposed and how to remediate it.

Try Security Guardian

• Reset the password of the Domain Admin account. This is the most obvious option, but it is very noisy.
• Reset the password of the PKI Admin account and issue a certificate with the Domain Admin’s UPN in the security context of PKI Admin, which will allow logon in the Domain Admin’s security context.
• Apply a Group Policy to the domain controller that runs a script which installs random malware, creates a new Domain Admin account, opens a back door, etc.

Because of the dependencies depicted above, the IDM is a Tier 0 system, and so is the PKI Admin account.

Tier 0 implementation options for tiered administration

As mentioned earlier, Tier 0 restrictions can be achieved through logon restrictions enforced in either of two ways:

• Group Policy — My colleague Daniel Metzger provides details here on how to implement logon restrictions leveraging Group Policy.
• Kerberos authentication policies — This option is described in the article, Protecting Tier 0 the modern way.

The following table compares these two options for Tier 0 isolation:

Summary

Implementing a tiered administration model in Active Directory demands significant effort. When it comes to preventing exposure of Tier 0 credentials to lower tier systems, you have two options: Group Policy or Kerberos authentication policies. We recommend Kerberos authentication policies because of the advantages described above.