Search
Send enquiry
  • AD Security

Microsoft Tiering Model – Part 3/3

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.

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

Part 1

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

Can be found here

Part 2

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

Can be found here

Part 3 (this blog post)

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

Privileged account/access management (PAM)

Integrating a PAM solution into the tiering model can solve several problems.

Due to the separation of administrative rights on the tiers, the administrators need additional user accounts, depending on the distribution of roles, in order to be able to perform their various tasks after the administration has been switched to the tiering model. This could include up to five user accounts in total if the administrator is active in all three tiers and has a local administrator account on his regular client in addition to his regular user account.

The requirement that these user accounts have very strong (and therefore long), unique and unrelated passwords does not make it easier to remember the many passwords and also to change them regularly (for example once a year). This is where implementing a PAM solution can help manage the high number of accounts. The administrator may then only need to remember two of the five passwords, depending on the implementation, namely that of the regular user account, which he uses to log on to the regular client, and that of the Tier 0 admin account, which he uses to log on to the PAW and PAM. From there, he can access the PAM solution and the other accounts it contains.
In addition, the PAM solution can automate the regular password change of the highly privileged accounts using particularly long and cryptic passwords, which further increases security.

In general, a good PAM solution can solve many other security-related problems.

For example, it can help replace default or predictable passwords. Unique passwords for each individual service and account can hardly be realized without special tools, since even in a small company hundreds of accounts quickly accumulate when all systems are considered, e.g., components of the network infrastructure, printers, IP cameras, time recording terminals, locking systems, web applications, service users on servers and other services in the network. All of these passwords need to be securely encrypted as well as stored and secured (in terms of a backup) in an access-protected manner. In particular, changing these passwords on a regular basis is not something that can be done manually, but it is an important administrative security measure. Just think of former employees, for instance, who still know an important password after having left the company years ago, or of script files in which the plain text password of a highly privileged service account was left long ago in order to test something.
This can typically be well automated in PAM solutions. It also solves many problems, especially if the administration of various systems that are not domain-integrated or not connected to the domain for authentication is also included in the tiering concept.

Using the PAM solution in the regular administration of these systems can then, for example, look like this: The administrator logs on to the PAW and accesses the PAM solution with a tier admin account. There he sees an entry, e.g., for a particularly important DMZ web server that is not a member of the domain. Depending on the configuration and the PAM solution, he can now either transfer the current password of the DMZ server’s administrator to his PAW with a single click and access the system, or ideally the desktop of a jump server belonging to the PAM solution opens along with the tools required for administration, which are already pre-equipped with the correct login credentials. After the administrator has finished working on the system, the PAM solution then automatically changes the password on the DMZ server and saves the new value.

Changes to AD structure and delegation

This section presents the changes required in the existing domain in order to implement the assignment of rights according to tiers as efficiently and securely as possible.

In order to separate the assignment of permissions to the objects in AD according to tiers, it is very likely that the existing OU structure must be adapted. Typically, the OU structure of a domain that has not previously been administered according to the tiering model tends to reflect the organizational structure of the company, such as the geographical subdivision from continent to location, or it represents a construct that has grown historically (the author is also a penetrationtester and therefore loves and hates this phrase at the same time).

An appropriate new structure depends heavily on how the company is set up. For example, answers to the following questions must be incorporated into the new design: How many tiers does the tiering concept encompass? Is the IT infrastructure distributed globally, in multiple countries or at multiple locations? Is there a central IT for the entire company or are there also self-sufficient IT departments in the countries? What does the existing OU and GPO structure look like? How are rights delegated in AD to date?

A possible new OU structure is shown below:

Hagen Molzer

Managing Consultant

Category

  • AD Security

Date

Navigation

Possible new OU structure

The exact structure is not important, as long as it efficiently allows for the delegation of rights or linking of GPOs separated by tier.
The domain controllers should not be moved from their default “Domain Controllers” OU to the Tier 0 OU, as this is not intended by Microsoft and can lead to problems.

In Active Directory, all authenticated users have very extensive read permissions for a large part of the objects present in the domain. This is also the reason why it is possible to read so much information with regular user permissions and the BloodHound tool and then visualize corresponding attack paths. However, this generous permission assignment in AD can also be adjusted by administrators. To conceal the existence and structure of the tier accounts, read access to the corresponding OUs could be revoked from authenticated users. This makes them invisible, e.g., in BloodHound, unless the attacker has performed the data collection with a user who has other group memberships that allow him to read information on those OUs again. The following figure shows the described permission assignment for the authenticated users and how it can be changed:

Permission assignment for the authenticated users

Revoking these permissions should be tested first, e.g., on a sub-OU containing only a few principals, to avoid problems. Also, in the exemplary OU structure shown in the figure above, permissions should not be revoked on the entire Admin OU, since most of the regular computer accounts such as terminal, file, PKI or web servers are also included, and applications or services may rely on being able to read certain information on those computer accounts.

It is therefore worth starting with the OUs where the tier admin accounts and PAWs are located. These are particularly valuable targets for an attacker and the customization is less likely to cause problems.

After restructuring the Active Directory structure and adapting the permission assignment separately according to tiers, it must still be ensured that administrators have full control over their environment at all times, which ensures that in the event of technical problems and failures, the systems of all tiers can still be administered despite the restrictions imposed by the tiering model. For this purpose, it is recommended to store break-glass accounts with full administrative rights per tier, e.g., in a safe and/or an encrypted off-premises password database (e.g. KeePass).

It should be ensured that the safe is accessible and can be opened even if the IT systems fail (building locking system, available physical keys, number combination of the safe, available backup batteries in case of an electronic pin pad, etc.). The off-premises password database should be stored in several places, be securely encrypted, and several people should have access to it. Furthermore, it must be ensured that the password is not forgotten.

Network segmentation and restriction of administrative access

After the implementation of the tiering model, administrative access is strongly regulated and defined. This means that it is clearly regulated which administrators administer which systems from where via which method.
This makes it much easier to restrict administrative access on a large scale at the network level than was previously the case. This means, administrative access such as RDP, PowerShell Remoting, other administrative interfaces (HTTPS, SSH), NetBIOS over TCP/IP (NBT) and SMB should now only be allowed from where they are really needed.

The NetBIOS over TCP/IP (NBT) and SMB protocols are a special case here. Administrative access to these protocols/ports is potentially required for administrators, but the ports are also needed (e.g. for SMB) by regular users to access file shares on file servers or the domain controllers (e.g. for the SYSVOL share). Access to these ports for regular users should therefore also only be allowed where it is actually needed (e.g. on file servers and not the PKI servers). The same is true for HTTPS access to a web application for a regular user versus HTTPS access to an admin interface of an infrastructure component for a tier administrator.

Examples of necessary administrative access and the respective source include:

  • from PAWs from PAW networks
  • from the PAM solution from the PAM network
  • from the monitoring solution
  • from the software distribution
  • possibly from the IT infrastructure network
  • possibly from the client help desk network (Tier 2)

Restricting network access and eliminating flat networks has been recommended for a very long time as an effective means of containing attacks and reducing the attack surface but often not implemented due to the large amount of effort involved. So, the question now is: What is the best way to do this?

Basically, a distinction can be made between two approaches. The classic method is to use network firewalls to filter traffic at the network/VLAN boundaries. The disadvantage of this method is that it is not possible to restrict network traffic within a network segment (VLAN). Two systems located in the same network can therefore still communicate with each other unfiltered.

The alternative method is to introduce some form of micro-segmentation. In this approach, the firewall ruleset is brought to the operating system. The client or server operating system thus filters the network traffic itself.

Again, there are two options for implementing this, using either the Windows Firewall already included in the Windows operating system or a dedicated solution for micro-segmentation. The Windows Firewall is “free of charge” and much more powerful than many administrators believe. Once you have understood the functionality and individual configuration options of the Windows Firewall, it can be surprisingly flexible and versatile. The lecture “Demystifying the Windows Firewall” by a Microsoft employee, which is available as a YouTube video (https://www.youtube.com/watch?v=InPiE0EOArs), offers an excellent one-hour crash course on the Windows Firewall.

In small to medium-sized environments, the functional scope of the Windows Firewall may be sufficient, but in medium to large environments, the Windows Firewall quickly reaches its limits. Especially in complex scenarios with different requirements, the Windows Firewall becomes uncomfortable to configure, operate and monitor. Dedicated solutions for micro-segmentation, for example from the manufacturers Guardicore or Illumio, can help here.

These bring the firewall functionality into the operating system through agents, either in the form of their own software firewall or by managing the already integrated firewall. The solutions offer a convenient management interface, support in creating the ruleset, and are easier to manage and monitor than the Windows Firewall – but they are not free of charge.

The Windows Firewall and dedicated micro-segmentation solutions have in common that they cannot be deployed everywhere. By its nature, the Windows Firewall is only present on Windows systems. Third-party micro-segmentation solutions typically support other operating systems as well, such as Linux or Mac.
However, a network firewall must still be used to isolate printers, for example, and other systems.

Regardless of whether a company uses classic network firewalls, the Windows Firewall, or a third-party micro-segmentation solution, the following network segmentation requirements should be considered during the implementation of the tiering model.
The PAWs and the systems belonging to the PAM solution should be located in specially isolated network segments. Access to the administrative interfaces of the Tier 0 systems should be possible only from the Tier 0 PAWs or other Tier 0 systems. Systems of different tiers should not be located in the same network segment, and the network traffic allowed between segments should be minimized. This means, for example, that access from Tier 2 systems to Tier 1 systems and from Tier 2 and Tier 1 systems to Tier 0 systems is generally restricted at the IP address/port level, if possible, and only what is really necessary is allowed.

The very limited network access for non-admin principals reduces the attack surface enormously and makes it more difficult for an attacker to spread. What is not reachable of the network can hardly be attacked …
To a similar extent, however, the administrators are also restricted in their work.

Therefore, due to the limitation of systems and access possibilities, an alternative must be created for file and data exchange. For instance, despite all the security precautions, it is necessary from time to time to download files from the Internet and transfer them to Tier 0 or to the PAWs – or data must be transferred between systems in different tiers or exchanged with external service providers.

The requirements for such a central system for data exchange (also called data hub) may be, for example:

  • Scanning the files with different antivirus scanner engines
  • Dynamic analysis of files (sandbox analysis)
  • Granular rights system for restricting access
  • MFA

What are the practical benefits of all this?

Finally, the question arises as to what added value all the changes, all the effort and all the additional complexity actually brings.

Specifically, if attackers have already gained access to a regular domain user or a domain-integrated system, the measures significantly hinder the attackers’ attempts to expand their privileges and spread further in the network. In the best case, the attackers will abandon this infrastructure and look for an easier victim. But if the attackers are motivated and competent, the measures will buy defenders valuable time to detect and stop attackers before they reach their target. In addition to implementing the tiering model, however, this requires the presence of appropriate attack detection solutions, such as antivirus protection and an EDR solution on the clients and servers, an AD monitoring solution that can detect attacks, and also good visibility of what is happening at the network level.

If the solutions raise an alarm, the appropriate incident response processes must be started promptly so that no valuable time is wasted and the attackers, along with their initial entry vector, can be thrown out of the network before they reach their goal.

From a penetration tester’s perspective, pentesting a domain with an implemented and “mature” tiering concept often stops being fun quickly. Even in very large environments, the BloodHound graphs “Shortest Path to Domain Admins” and “Shortest Path to High Value Targets”, which represent possible attack paths to high-value targets in an environment, are then very limited. It is virtually impossible that any regular user account will serve as an entry point to such an attack path. This means, the penetration tester must make a much greater effort and first compromise other admin accounts or systems to find an entry point.

Even if a real attacker – starting from his initial entry point – manages to compromise a user who has, for example, (administrative) access rights for an interesting system, he will probably not be able to reach either the remote administration ports or the system itself, because of the restricted network access and micro segmentation. And what you cannot reach, you typically cannot easily attack either.

For attackers, this means they have to get creative if there are no easy ways to reach their goals. Which is exactly what often triggers alarms in security solutions since it deviates from regular user or administrator behavior.

But there are still opportunities for us penetration testers, too. The most promising way is to look for violations of the tiering model in day-to-day administration or the compromises a company has made on the conceptual level. 
SharpHound (the data collection component of BloodHound), for example, can be started with the parameters “-c session –loop –loopinterval 00:15:00 –loopduration 12:00:00” to collect new session data every 15 minutes for the next 12 hours, hoping to catch the login of a tier admin account of a higher tier on a system in a lower tier that can already be accessed. Perhaps a tier admin’s session is “reachable”, which helps to move along within a tier. But obviously, this session enumeration is very noisy and typically detected by EDR or Active Directory security solutions if present.

Another approach is to mark additional objects as high-value targets in BloodHound. In the default configuration, BloodHound already knows that, for example, members of the Domain Admins or Domain Controllers group are of high value and marks them as “High Value”. For many other systems or AD groups that could be used to compromise other tiers, manual work, experience and the creativity of the penetration tester is required. For example, the penetration tester can analyze the configuration of already compromised systems and link these findings with the BloodHound data to identify the WSUS server, for instance, which may also distribute updates to domain controllers, or to identify an AD group whose members have administrative rights in the VMware environment. If these objects are additionally marked as “High Value”, the attack paths to high-value targets identified by BloodHound may already look more promising.

You may also be lucky as a penetration tester and find “relics” on lower tier systems from before the tiering model was introduced, e.g., in the form of passwords in scripts, cached credentials, or backups of systems that now belong to higher tiers. If you are very lucky, you compromise a Tier 2 admin account, for example, and then find out that the administrator is using the same password, or a predictable variation of it, for his Tier 1 or Tier 0 account as well.

To add weight to the concepts and measures addressed in this series of blog posts and to illustrate the need for their implementation, it is worth reading Gavin Ashton’s personal account of the devastating attack on Maersk’s IT infrastructure. Gavin Ashton witnessed the attack on the maritime logistics giant first-hand as an administrator. The article is available at the following URL: https://gvnshtn.com/posts/maersk-me-notpetya/

Some lessons learned by Ashton from this event and other quotes from his report related to the tiering model are listed below:

  • Basics #1 Stop talking. Start doing
    You can accept risks forever and a day but at some point, it WILL bite you and someone WILL end up doing the work in the end. Call this technology debt or whatever you like. But please, for your own sake, get on with the basics.
  • Basics #6 Get your privileged access baseline in order
    If your administrators are used to having access to all things, at all times, it’s high time for them to change.
  • No amount of risk acceptance can really get you around this. Whether this is by strictly adhering to the Microsoft Tiered Access Model or going for something a little lighter, at the very least you should:
  • Now I can just hear a hundred people all saying (because I’ve heard these voices before):
    Yes but, that sounds difficult. Yes but, that sounds expensive. Yes but, that will take a long time. Yes but, we ‘need’ (like) having access all the time.
  • Losing everything will be much more difficult, will be a lot more expensive, and will take a much greater length of time, and will cost peoples jobs, relationships, or worse. These are basics. Like locking your front door. Or having a PIN on your bank card. It’s a shame Microsoft didn’t bake these controls in deeper out of the box back in 2000, but here we are. Get to it.

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 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.

Send Enquiry
Contact Details

Competent IT security consulting, pentests, incident response and training

Ferdinand-Braun-Straße 4
74074 Heilbronn, Germany
Quicklinks
Social Media
Legal
Search
Search