Microsoft Tiering Model – Part 2/3

Survival guide for planning and implementing a concept for secure administration

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.

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

Part 2 (this blog post)

  • 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

PAW basics

The Microsoft documentation describes PAWs and their tasks very aptly:
Privileged Access Workstations (PAWs) provide a dedicated operating system for sensitive tasks that is protected from Internet attacks and threat vectors.

The very specific purpose of a PAW and the strict restrictions significantly reduce the attack surface of these devices. For instance, PAWs should not be able to access the Internet or receive emails, and they should not be able to open PDF or Office files from untrusted sources.

In addition, the clean-source principle should be observed for the software used. For example, the operating system image should be downloaded directly from the manufacturer and then the hash checksum of the downloaded file should be compared with the value specified by the manufacturer. The same also applies to third-party tools such as Notepad++ or 7Zip.

Furthermore, when procuring new PAW hardware, care must be taken to ensure that it meets all the important safety-related requirements wherever possible:

  • 64-bit CPU
    (possibly already based on Pluton architecture when available[1])
  • CPU with Intel VT-x or AMD-V
  • CPU instruction set for DMA protection (IOMMU)
  • TPM 2.0
    (preferably integrated into the CPU and not as a separate component on the mainboard)
  • UEFI Secure Boot
  • Memory soldered to the mainboard

When it comes to the physical security of the PAW, the companies must again find the compromise that suits them best. For companies with particularly high security requirements, a PAW can, for example, be a workstation housed in a metal cage in a specially secured “PAW room” with an access control system based on more than one factor (such as a key and a biometric authentication mechanism). Other companies use a mobile notebook as a PAW and specify via organizational rules that administrators may use the PAW when working from home, but not in a hotel Wi-Fi or on the train.

Possible PAW implementations

Depending on which implementation type of the tiering model has been chosen in the section “Different ways of implementing the tiering model” in part one of the blog post series (i.e. which tiers may be administered exclusively from PAWs), and depending on the number of administrators of the affected tiers, the number of PAWs to be procured and operated in the future can quickly become quite large. Therefore, once again, a compromise must be found.

PAW implementation with two separate devices

The safest solution is to purchase a second physical device that is used exclusively for administration. The first device, which may already exist, is then used for regular work (including Internet and email use). This allows a strict separation between administrative and regular work, and there is no attack surface of the PAW through Office software, for example, or through websites. In addition, the clean-keyboard principle is adhered to for administration, which dictates that the first computer in the possibly longer access chain for administration (i.e. the computer to which the physical keyboard is connected that the administrator operates) is a particularly secure system. Why this principle is especially important will be discussed in more detail in the following scenarios.
Due to the very specific purpose of the PAW, particularly strict hardening measures can be implemented without causing major technical problems.

The disadvantages of this solution are that the additional computers incur costs for hardware, software and the administrative effort. It is also more cumbersome for administrators to work with, as they now have to use and possibly transport two devices. Depending on how strictly PAW security is implemented, administrators’ collaboration options may be limited because there is no Teams on the PAW and no Internet access.

Host PAW with office VM

A possible alternative, which does not require procurement of new PAW computers, is to format the regular computer already used by the administrators and install it as a PAW after reinstallation. Then a hypervisor is installed on the PAW (e.g. VirtualBox, VMware Workstation or Hyper-V), and the regular computer is virtualized in the form of a VM. Logging in with the tier admin account and all administrative activities are then done directly from the host PAW, and email processing and web browsing are done in the office VM.

This saves the purchase of a second computer, and the administrator always has the PAW and his regular workstation system with him, which makes work more comfortable and flexible.
However, the last point also represents a disadvantage. The administrator then no longer has the option of not taking the PAW into possibly insecure environments. In larger meetings, for example, the PAW might even remain in the meeting room at lunchtime while being switched on, or it requires the discipline of the administrator not to let his computer out of his sight in dangerous situations and to always lock the screen.

Another major drawback of this solution is that there is no strict separation of the two devices, which means that the PAW and the office VM may share a network interface, making isolation of the PAW in a PAW network more difficult or impossible to implement.
Furthermore, the PAW can potentially be attacked via the hypervisor. Using a VM guest-to-host exploit, it may be possible for an advanced attacker to break out of the office VM and compromise the underlying hypervisor and thus the PAW. Other potential problems exist for the regular work on the office VM. For example, there can be performance issues when playing videos or graphically demanding applications because often the GPU cannot be used within VMs or problems occur in general due to the additional virtualization layer. There can also be problems with Bluetooth headsets or other peripherals, e.g., in Teams or Zoom.

Host PAW with an office VDI (Virtual Desktop Infrastructure)

A further development of the latter implementation is to run the office VM not on the PAW itself, but in the company network, e.g., as a Citrix VM. This has further advantages: Due to the stronger separation of the two systems than in the previous scenario, there is no attack surface through guest-to-host exploits, and isolating the PAW in a PAW network becomes much easier to implement. However, the potential performance and peripheral issues still exist. One disadvantage is that “offline work”, i.e., working in the office VM without a connection to the company network, is no longer an option.

Access to PAW from regular office client (not recommended)

An often-discussed approach is to virtualize the PAW on the regular work notebook and perform administration from the PAW VM. This, however, contradicts the clean-keyboard principle, since an attacker who was able to compromise the regular notebook has many opportunities to compromise the PAW as well. For example, he could install keylogger or screen monitoring software or simply copy the PAW VM away.

Summary of possible implementations of the PAW:

Hagen Molzer

Managing Consultant




Securing the PAW

The measures for securing and hardening the PAW are manifold. Most of them are often already known from the normal catalogs of measures for hardening Windows operating systems. However, due to the higher security requirements of the PAW, the focus here should be on the stricter implementation of hardening measures and not on laxer settings to solve compatibility problems or making compromises in terms of conveniences in administration that entail greater risks. Due to the very specific purpose of the PAW, the implementation of hardening recommendations should be more straightforward than on regular clients, which have to meet very different requirements.

The following list contains the most important measures from the world of client hardening but does not claim to be exhaustive:

  • Clean source principle for any hardware and software
    • But also for basic installation
      • For example, PAWs should not be installed via RDP from an already potentially compromised machine but from a secure and “clean” environment
    • Basic hardening of the operating system, e.g., according to
      • Microsoft Security Baseline
      • CIS (Center for Internet Security) Benchmark
    • Special focus on minimal installations
      • Limitation and standardization of installed software
    • Hard disk encryption (e.g. BitLocker with pre-boot authentication)
      • TPM 2.0
    • Principle of least privilege
      • Regular tier administrators do not have local administrator rights on the PAW
    • System-specific password of the local administrator (e.g. via LAPS)
    • Timely and regular installation of security updates
      • Operating system
      • Third-party software
    • UEFI Secure Boot
    • Antivirus software
    • EDR software
    • Windows Defender
      • Credential Guard
      • Exploit Guard – Exploit Protection
      • Exploit Guard – attack surface reduction rules
      • Windows Defender Advanced Firewall (Windows Firewall – more details will follow in Blog post part three)
        • Possibly with IPSec encryption of particularly sensitive network traffic
      • Application whitelisting (e.g. via AppLocker)
      • Kernel DMA Protection (IOMMU)
      • Explicitly prohibit logins from non-tier admins (and admins of other tiers)
        • Deny logon restrictions

Administrative access and tools

By using the tier admin accounts, an important measure to protect the highly privileged identities has been implemented. But these accounts must now be protected on the managed systems or in the network as well. Since the user accounts are used to manage other systems, they must be able to be used on systems in their respective tiers. An attacker who has already compromised a system (e.g. client, terminal server or web application server) can compromise a tier admin account under certain conditions after the administrator connects to that system for administration. For example, depending on the administrator’s logon type used, the attacker may be able to read password hashes or Kerberos tickets of the privileged accounts on the managed systems if they are located there. 
In a scenario where an attacker has compromised a Tier 1 web server by exploiting a vulnerability in the web application, the attacker initially has privileges only on that one server. If the attacker is then able to read the NTLM hash of a Tier 1 admin account because the administrator connected to the server via RDP for administration, the number of servers over which the attacker gains administrative control potentially increases dramatically. In the worst case, the Tier 1 admin account has administrative privileges on all servers, causing the entire Tier 1 to fall.

To reduce this risk, it is necessary to know the different logon types in a Windows system. The following information on logon types is an excerpt from Microsoft’s “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft” articles. Source:

The articles are almost ten years old but have hardly lost any of their relevance, which is why reading the two documents is strongly recommended.

For remote administration of a system, Windows roughly distinguishes between the following two logon types:

  • Interactive Logon and Remote Interactive
  • Network Logon and Network Cleartext

Access types with interactive logon type include:

  • Remote Desktop (RDP)
  • Log on at console (also remote lights-out hardware), (network) KVM, VM console at hypervisor
    • (access to network resources)
  • PsExec \\MyServer -u Admin -p Secret123! Cmd.exe
    • (PsExec with explicit credentials)

The problem when access types with interactive logon type are used is that reusable credentials of the administrator are transferred to the target system and then reside in the system’s memory. An attacker can then extract and reuse, for example, the NTLM hash or Kerberos tickets of the tier admin account.

Examples of network logins are:

  • Connection to the target server via MMC snap-in
  • net use \\server\share /u Admin
  • PowerShell Remoting: Enter-PSSession MyServer
  • Remote Registry
  • Remote Desktop Gateway (authentication takes place at the RDP gateway)
  • PSExec \MyServer exe
    • (without explicit login credentials)

The advantage of this logon type is that no reusable administrator credentials are left behind on the system that was accessed. However, single sign-on (SSO), to which users in the Windows environment have become accustomed, is not possible on principle. The SSO functionality is also the reason why the login credentials are transferred to the target system at all with interactive logon types. If this were not implemented, it would not be possible, for example, to access a terminal server via RDP and from there to access a file server in the internal network without having to enter one’s login credentials again at the file server. Authentication can be taken over by the terminal server at this point because the terminal server has received the login credentials when logging in via RDP. Further details on the different logon methods can be found in the tables in the document “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques_English-2.pdf”:

Source: - Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques_English-2.pdf (not available anymore)

Accordingly, the administrator should, wherever possible, refrain from using interactive logons (meaning, for instance, RDP) for administration and use access possibilities based on network logons. Although this often requires administrators to get used to a new way of working, it can also speed up administration in the end, since the “more time-consuming” interactive logon via RDP is no longer required with the corresponding mmc.exe tools, with the remote server administration tools (RSAT) or with PowerShell Remoting.

Remote administration of a server via mmc.exe with network logon

Microsoft never planned to use RDP for the regular administration of a server anyway. This can also be seen in the fact that only two RDP sessions are possible on a server at the same time by default. Especially in larger companies, administrators would hardly be able to get any work done if RDP was indispensable for regular administration. The administrators’ main activity would then be to call other administrators and beg for one of the two RDP slots.

Nevertheless, there are cases where the graphical user interface of the operating system is required, for instance, when a wizard has to be operated for a software installation or when interaction with installed software that can only be accessed locally is necessary. In these cases, RDP is still an effective means, but the RDP connection should be additionally secured. Microsoft has created two mechanisms for this in the form of Remote Credential Guard and Restricted Admin Mode. With both mechanisms, the accessing user’s credentials are not transferred to the target system.

To ensure that SSO to third-party systems (e.g. file servers) is still possible from the RDP target when using Remote Credential Guard, corresponding Kerberos requests are forwarded to the RDP source.

When using Restricted Admin Mode, a context switch occurs automatically during logon. The accessing user is switched to a local virtual account that has local administrative rights on the RDP target, but access to third-party resources on the network occurs in the context of the Active Directory computer account of the RDP target.

Microsoft recommends using Restricted Admin Mode instead of Remote Credential Guard for scenarios where an RDP target may already be compromised. This is because while the RDP connection exists using Remote Credential Guard, the attacker has the ability to start new sessions in the context of the accessing user for a limited time window.

Source: (not available anymore)

Configuring RDP security can be implemented via group policies. Under “Computer Configuration → Administrative Templates  → System  → Credentials Delegation”, the policy “Restrict delegation of credentials to remote servers” can be found. This policy offers the following three settings:

  • Restrict Credential Delegation
    • Preferred: Remote Credential Guard
    • Fallback: Restricted Admin Mode
  • Require Remote Credential Guard
  • Require Restricted Admin Mode

Another important measure to protect tier admin accounts is to include them in the Active Directory “Protected Users” group. This automatically implements several hardening measures for these particularly highly privileged users. However, this measure should be tested in detail before productive use, as it can have an impact on the way administrators work. Inclusion in the group enables different protections on the Windows devices in the domain and on the domain controllers. 

On the Windows devices, for example, the plaintext password is no longer cached if Windows Digest is enabled, even if it was manually enabled by the attacker, and Kerberos also no longer caches the plaintext password after having received the initial TGT (Ticket Granting Ticket).

Regarding domain controllers, among other things, NTLM authentication is disabled for members of the “Protected Users” group, and renewing TGTs after the initial four-hour validity period is no longer possible.

Note: Parts of this blog post series have already been published in the German IT magazine called “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 »
Do you want to protect your systems? Get in touch with us.