AD Security, Blog

Microsoft Tiering Model – Part 1/3

November 10, 2023

Survival guide for planning and implementing a concept for secure administration

Introduction

Securing the internal IT infrastructure against attacks is getting more and more important in the “assume breach” world we are living in right now. Once attackers get “in”, meaning getting past the perimeter defenses, as they usually do nowadays via phishing, other social engineering attacks or through exploiting not yet patched vulnerabilities in Internet-facing services, the attackers are able to interact with the internal IT infrastructure in the same way as regular users can in most cases.

In most environments, the internal IT infrastructure presents a vast attack surface to such an attacker because often a lot of time and money was spent in the past to secure the hardened perimeter but not so much on the soft internal core of the internal network.

To make this soft core of the internal network harder, different typical hardening activities and measures come to mind, such as:

Contemporary patching of systems and servers
Hardening services
Disabling services that are not needed
Disabling legacy protocols
Segmenting the internal network
Following all the password good practices
Yada, yada, yada, …

All those things are still important. However, the supreme discipline to thwart lateral movement and privilege escalation attacks is probably the development and introduction of a concept for the secure administration of the IT infrastructure. For this purpose, Microsoft proposes the tiering model or “Enterprise Access Model”( https://learn.microsoft.com/en-us/security/compass/privileged-access-access-model) a basic concept for protecting the Active Directory environment and, if necessary, other parts of the infrastructure from various classic vulnerabilities that can arise during administration.

This blog post series looks at different design decisions, considerations and options an organization should bear in mind when planning, implementing and maintaining a tiering model in order to administrate the IT infrastructure securely. It describes the various options for implementation, explains trade-offs that must be made and their residual risks, and outlines the technical measures that need to be taken.

Due to the amount of material necessary to cover the topic, the blog post was split into three different parts:

Part 1 (this blog post)

Introduction
Design phase
Different ways of implementing the tiering model
Classification of systems in (three) tiers

Part 2

PAW basics
Possible PAW implementations
Securing the PAW
Administrative access and tools

Part 3

Privileged account/access management (PAM)
Changes to AD structure and delegation
Network segmentation and restriction of administrative access
Practical benefits of the tiering model

The basic idea behind the tiering-model is that the strict separation of the rights and access of administrators makes it more difficult for attackers to extend their privileges in AD and to spread in AD. Compromising a client administrator, for example, then does not significantly help attackers to compromise regular servers or domain administrators.

If an attacker gains access to a Windows system, he can usually compromise other users logged on to that system. For example, if an attacker gains local administrative privileges on a terminal server after exploiting a privilege escalation vulnerability, he could compromise a server administrator (who has administrative privileges on many other servers) logging onto this terminal server.

The attacker may then be able to use a tool such as Mimikatz to read the server administrator’s credentials from the lsass.exe process or create a scheduled task to run in the context of any user who logs into the terminal server. There are almost no limits to the attacker’s creativity, as he can perform arbitrary manipulations on the terminal server with the local administrative privileges. After compromising the server administrator, the attacker is already one step closer to the crown jewels of his victim, for example, the domain controller.
If the server administrator also has administrative control over the hypervisor environment where the domain controllers are virtualized, the backup server where the backups of the domain controllers or PKI servers are stored, or the WSUS server that distributes updates to the domain controllers, then the attacker is only one step away from completely compromising the domain.

The “Credential Theft Shuffle” would also be a possibility, which allows attackers to gradually expand their privileges in AD until they have achieved their goal. The term Credential Theft Shuffle was coined by Sean Metcalf, operator of the website adsecurity.org and luminary in the area of AD security, in his blog entry “Attack Methods for Gaining Domain Admin Rights in Active Directory”:

Date

November 10, 2023

Navigation

Once an attacker has completely compromised a domain, in most cases the domain can never be fully trusted again. The only chance of recovering the existing domain and not having to completely rebuild it is if you notice the compromise very quickly, can determine the time and path of the compromise beyond doubt, and have backups and can restore the compromised systems and the domain.
This makes it all the more important to protect your domain from compromise. Implementing a tiering model is a very powerful tool for this.

The basic idea of the tiering model is to divide all systems in the domain into (typically) three levels, called tiers:

Tier 0: Domain controllers, PKI and other security-critical systems
Tier 1: Servers
Tier 2: Clients

Then the administration of the systems is adjusted so that the compromise of a higher tier does not facilitate the compromise of a lower tier.

The tiering model has long been illustrated by Microsoft with the following graphic:

Some time ago, Microsoft’s tiering model was further developed and renamed. It is now called “Enterprise Access Model” and is described with the following representation:

The underlying principle has remained the same; the various systems continue to be divided into categories and their administration is safeguarded. In these blog posts, the original designation of the system categories and measures is used, as these are cleaner, easier to understand and because the principle has hardly changed.

The introduction of a tiering model has a major impact on the way administrators work and on their access rights. It determines how and from where administration can be carried out in the future, and it generates costs through additional hardware and software licenses, if required, as well as through greater complexity of administration.

This is why there is not “the one” tiering model that “fits” all environments, but typically various trade-offs have to be made. In the design phase, for example, the security requirements for the environment, the budget and the company’s willingness to expend effort should be taken into account. The goal is to disproportionately increase the effort required by attackers with little investment of the company itself so that, in the best case, the attackers find an easier victim. Microsoft illustrates this principle in the following figure:

Design phase

The design phase begins with the consideration of how many tiers the systems of the IT infrastructure or the domain should be divided into. Microsoft provides for three tiers, but this can be adapted to the actual circumstances.

For example, in a DMZ domain, Tier 2 may not make sense because there may be no clients here. Tier 1 could also be split into Tier 1.1 (central infrastructure servers) and Tier 1.2 (servers for development/special applications) if a larger number of developers or external service providers are given administrative rights on one part of the servers and this is to be separated for security reasons.

Then the systems of the IT infrastructure or domain are assigned to the tiers. The following list contains typical systems of an IT landscape:

Domain controllers
ADFS servers, Entra ID Connect server
Virtualization hardware/software
Privileged access workstations (PAW)
Central password management
Monitoring system (e.g. SCOM)
Software distribution (e.g. SCCM, WSUS)
Backup system/storage
Antivirus solution, EDR
PKI
Terminal servers
Application servers
Clients
Infrastructure in the cloud, if applicable

During the design phase, it is also important to decide whether additional systems should be included in the tiering concept besides the domain-integrated systems, such as:

Linux systems
Infrastructure hardware (e.g. network hardware)
Cameras
Locking systems
Cloud users (e.g. Global Admin in Entra ID)
Other cloud providers, e.g.
- Cloud proxy
- Mail security

Among other things, this decision should take into account how the logon to these systems is authenticated, whether they are already connected to Active Directory, and how high the protection requirement is for these systems or users. The higher the importance of the systems from a security perspective, the more important their inclusion in the tiering concept.

Then comes the next step. The concept must provide for the strict separation of roles and accounts for the administrative tier users, i.e., there must be no cross-tier permission assignment for the administrative users. As a result, an administrator who administers systems in all three tiers, for example, will need at least four different user accounts in the future:

Regular user account: michael.mueller
(used, e.g., to read emails and surf the Internet; no administrative rights whatsoever)
Tier 0 administrator: T0-michael.mueller
Tier 1 administrator: T1-michael.mueller
Tier 2 administrator: T2-michael.mueller

The naming of future administrative accounts should reflect the tier affiliation. This greatly facilitates the detection of violations of the tiering model and simplifies its implementation.

In addition, it is also important in this context to deactivate the previous admin accounts and delete them as soon as the new tier admin accounts are used, so that no relics are left behind that undermine the tiering model again.

The separation of the tier admin accounts is intended to accomplish the following two goals.

1. Prevent cross-tier user logins:

2. Prevent cross-tier permission assignment:

Then it must be determined how much effort will be put into protecting these new highly privileged identities. Assuming that administrators use their new tier admin accounts on their regular clients – in addition to their regular user account – not much is gained. If an attacker succeeds in compromising an administrator’s regular client, there are quite a few ways to compromise the tier admin account used on it as well. For example, software keyloggers, screen monitoring software or, again, the lsass.exe process and the Mimikatz tool can be mentioned here.

The most secure option is to use specially protected privileged access workstations (PAWs) for users with tier admin accounts. PAWs are separate devices (workstations or notebooks) that are used exclusively for administration and to which only tier admin accounts can log on. PAWs will be discussed in detail in part two of the series.

For cost reasons, it seems obvious to combine the regular client and the PAW on one computer, e.g., using virtualization. However, a number of pitfalls must be taken into account here, so that you do not unknowingly tear larger security holes in your administrative concept. This will also be discussed in detail later in part two of the series.

Another option is to integrate a privileged access management (PAM) solution into the administrative concept. This can help to reduce the number of PAWs that have to be procured separately in the future, for example, and helps to ensure that administrators do not have to remember the many passwords for the new tier admin accounts. In addition, security can be enhanced through multi-factor authentication and frequent, automated password changes. This topic will be revisited in detail in part three of the series.

The future clear separation of systems achieved by means of the tiering model and the definition of which person has administrative access to which systems makes it easier to set up a strict filtering network segmentation and to allow access to the management ports of the systems only from where they are really needed. More on this will be explained later when network segmentation and restricting administrative access is discussed in detail in part three of the series.

Now that all the important core components of the tiering model have been presented, the inclined administrator may be intimidated by the potential effort of the overall project and wonder how all this is to be implemented alongside the day-to-day business. Depending on the size of the company’s IT landscape and the state of the previous administrative concept, this project is certainly one of the larger and more costly ones, but even this elephant can be eaten one bite at a time.

The first step should be to start with securing Tier 0. This has the advantage that relatively few systems and administrators are affected at first, namely only those that are particularly highly privileged. At the same time, the measures lead directly to a very high security benefit, since the particularly critical systems are secured first. The number of technical adjustments and the administrators’ working methods that need to be changed are therefore manageable compared to Tier 1 and Tier 2, and the team of administrators can gain valuable experience of what it means to change the administrative concept and administer according to the tiering model. These insights are worth a lot for the transition of the administration of Tier 1 and Tier 2.

Different ways of implementing the tiering model

As already mentioned, there is no universal tiering model; instead, each company must come up with the variant that suits them best and find appropriate compromises. Implementing tiering with maximum security benefit entails very high expenses, e.g., due to:

Higher administrative expenses
More complex (inefficient) ways of administrating
Additional hardware/software

On the other hand, a very pragmatic implementation of the tiering model reduces the security benefit:

Too many compromises on security increase the attack surface
Risk increases because easily exploitable vulnerabilities arise

Before we get to the different implementation types, we first need to shed light on the “Assume Breach” scenario. Assuming that AD has already been unknowingly compromised, it does little good to create and use the new admin tier accounts in the existing productive domain. The attacker has various ways to compromise the new identities and join the new way of administration undetected. This becomes more difficult if the tier admin accounts and the PAWs are not created in the productive (already potentially compromised) domain but in a newly created, separate administrative forest (red or bastion forest) and administration of the productive domain then takes place exclusively from this red forest.

There is or was also a design proposal from Microsoft for this principle, namely the Enhanced Security Admin Environment (ESAE), including detailed technical features. According to the Microsoft website (https://learn.microsoft.com/en-us/security/compass/esae-retirement), however, this proposal has been retired and replaced by the new and modern approaches “Privileged Access: Strategy” and “Rapid Modernization Plan (RAMP)” as the new standard recommendation. Nonetheless, Microsoft points out that ESAE is still a valid approach, e.g.

for isolated on-premises environments or when the use of cloud technologies is not possible or desired,
in highly regulated environments, or
if the security requirements are particularly high or the risk tolerance particularly low.

Implementing the tiering model according to ESAE is the most secure, but also the most complex variant. This is why it is typically used when the security requirements are particularly high or the company is particularly large.
This model is especially interesting for companies that operate a large number of internal domains or forests or for managed service providers (MSSPs) that manage many domains for their customers. If a large number of domains are managed from one red forest, this can even reduce the effort, as the administrators only need accounts in this one red forest domain instead of requiring an account in every managed domain.

The ESAE or red forest concept is already a complex topic in itself, which would go beyond the scope here.

Tiering model within the managed domain

By far the most common variant is the implementation of the tiering model in the existing domain, i.e., the tier admin accounts and the PAWs or the PAM solution are located in the productive domain to be administered. But even here, there are different variants that offer a higher or lower level of security.

All variants have in common that the objects within AD are divided into the already mentioned (three) tiers. Then it has to be decided how much effort the organization is willing to put into protecting the tier admin accounts. The safest way is to use all the tier admin accounts of all three tiers exclusively on PAWs.

Many weaker, but less expensive or more easily implemented compromises are imaginable. The following list shows some examples:

The following is an example of an overly pragmatic implementation, which was more common in the past in enterprises but does not address many risks:
All administrators are given, in addition to the regular user account, an additional administrator account that is used from the regular notebook to administer all tiers (including domain administrator accounts).
These are the penetration tests that are easy and in which it is often possible to compromise the domain the first time before lunch.

Classification of systems in (three) tiers

There is also a lot to consider when classifying systems into the individual tiers to ensure that the new construct provides the desired security benefit. The basic rule is:

A system that has control over another system must be at the same level or higher.

The reverse numerical order must be observed: Tier 0 is “highest tier” despite lowest number.

It is recommended to take the top-down approach to classification and start with Tier 0. The systems typically to be classified have already been listed at the beginning. On closer inspection, the classification is only obvious and indisputable for a few of these systems.

Thus, the following systems appear to be Tier 0:

Domain controllers
ADFS servers
Entra ID Connect server
PKI

Obviously, application servers belong to Tier 1, while clients obviously belong to Tier 2.

With the other central systems in the list, it becomes more difficult, and various questions arise:

Virtualization hardware/software
- Are Tier 0 systems being virtualized here
Privileged access workstations
- Are multiple tiers managed by one category of PAWs or are there separate PAWs by tier?
Central password management
- The passwords of which tiers are stored here and who needs access?
Monitoring system (e.g. SCOM)
- Are Tier 0 systems also monitored and is control over these systems possible from the monitoring system?
Software distribution (e.g. SCCM, WSUS)
- Are software or Windows updates also distributed to Tier 0 systems?
Backup system/storage
- Are Tier 0 systems or their data stored here?
Antivirus solution, EDR
- Is administrative control over Tier 0 systems possible via this?

When a company first thinks about this topic, it typically comes to the conclusion very quickly that many central systems must be counted as Tier 0. This shows that until now, many administrators have been unknowingly overprivileged. An example frequently encountered at companies illustrates this:

A company operates a central WSUS server that provides updates for all clients, servers and domain controllers. The release of updates and the administration of WSUS are performed by the regular help desk/server administrators. An attacker only needs to compromise one of these administrators to be able to inject a malicious WSUS update to compromise a domain controller. Compromising such an administrator (Tier 1 or 2) is often significantly easier than compromising a domain administrator (Tier 0) because these user accounts are used on a variety of easily compromised systems (such as regular clients or servers).

To create a malicious WSUS update, an attacker can use ready-made open-source tools such as SharpWSUS (https://github.com/nettitude/SharpWSUS), which are freely available on the Internet. With a few command line calls, the update is created, approved and the attacker only has to wait for the update process. However, the payload must be signed by Microsoft. But this is not a problem either, because programs like psexec.exe, msiexec.exe or msbuild.exe from Microsoft itself can be used for this purpose.

Comparable attack paths can often be developed for other systems on the aforementioned list with little effort.

There are three ways to solve this problem in the context of the tiering model:

Possibility 1

The central system gets the highest classification of systems it can control (e.g. Tier 0). All administrators who need access are given a Tier 0 admin account and use it to work according to Tier 0 standards (e.g. from PAWs). This is a secure solution because strict separation of administration of systems by tiers is implemented and administrative access to the central system over the network can be easily restricted.

The disadvantage is that the number of admin accounts belonging to Tier 0 can become very large, which may not be desirable in itself and can be expensive (e.g. because of the acquisition of many PAWs).

Possibility 2

Multiple instances of the central system are implemented, separated by tiers, e.g., a separate software administration per tier. This is also a secure solution, as there is again strict separation of the central systems by tiers and network access to the remote management interfaces can be easily restricted via the network.

But here, too, the disadvantage is that this solution can quickly become expensive, as additional hardware and software may have to be purchased and the administrative effort increases.

Possibility 3

This solution tries to find a compromise between security requirements and additional costs. Also, it is only suitable for systems that have extensive RBAC (role-based access control). It must therefore be possible to regulate the assignment of permissions within the central system on a granular basis.
Consideration can then be given to classifying the central system as a Tier 0 system but authorizing Tier 1 and Tier 2 admin accounts for the systems at their respective tiers via permission assignment.

A classic example of this is the assignment of permissions within VMware’s vCenter for the VMs of different tiers for the various tier users. Scrupulous care must be taken to ensure that, for example, no Tier 1 or Tier 2 admin accounts are given rights on Tier 0 systems. The advantages here are that there are fewer costs for hardware/software licenses and for the increased administrative overhead than with the previously mentioned options.

However, one of the big disadvantages of this option is that, for example, vulnerabilities in the system itself or in RBAC can endanger the systems of a higher tier starting from lower tiers or tier users. There have been vulnerabilities of this type in various solutions in the past, allowing exactly this attack.
Furthermore, the system is more difficult to isolate on the network side, since a larger number of lower-tier administrators need access to the remote management interfaces.
In addition, this is not a universal solution, as not all systems offer the possibility of granular rights restriction.

On the subject of terminal servers, it should be noted that even though systems in the terminal server category have the word “server” in their name, it is still imperative that they be counted as Tier 2 and treated as clients when used by regular users.

Typically, a large number of users have access to the servers, many different programs are often installed on the terminal servers, and the terminal servers are also often in use for a long time, so many vulnerabilities can accumulate over time. An attacker who manages to gain local administrative rights on a terminal server can compromise a large number of logged-in users at once. Consequently, administrators from higher Tier 1 and, of course, from Tier 0 should never log in here. To the author, privilege escalation vulnerabilities in typical terminal server or Citrix environments have served countless times as starting points for attack paths to compromise the domain.

Note: Parts of this blog post series have already been published in the German IT magazine called “iX” https://www.heise.de/ix

Further blog articles

AD Security

Microsoft Tiering Model – Part 3/3

January 10, 2024 – This is the third part of a three-part blog post series that looks at different design decisions, considerations and options an organization should bear in mind when planning, implementing and maintaining a tiering model in order to administrate the IT infrastructure securely. It describes the various options for implementation, explains trade-offs that must be made and their residual risks, and outlines the technical measures that need to be taken.

Author: Hagen Molzer

Mehr Infos »

AD Security

Microsoft Tiering Model – Part 2/3

December 10, 2023 – This is the second part of a three-part blog post series that looks at different design decisions, considerations and options an organization should bear in mind when planning, implementing and maintaining a tiering model in order to administrate the IT infrastructure securely. It describes the various options for implementation, explains trade-offs that must be made and their residual risks, and outlines the technical measures that need to be taken.

Author: Hagen Molzer

Mehr Infos »

Do you want to protect your systems? Get in touch with us.

Competent IT security consulting, pentests, incident response and training

Ferdinand-Braun-Straße 4
74074 Heilbronn, Germany