Best Practices for Microsoft Tier Classification of Administrative Privileges

As mentioned in our recent podcast episode 3, reflecting on incidents we encountered over the past year, it was clear that bad actors are shifting their tactics. Rather than breaking in, attackers are increasingly logging in using compromised accounts.

Listen to podcast #3 to hear more about the incidents that have stuck with us the most over the past year:

Attackers are logging in using stolen or compromised credentials. Once inside, these attackers systematically escalate their privileges, moving from standard user accounts to more powerful administrative access (privileged accounts) . These actions include deleting backups, encrypting VMDK’s, domain take over, and more, as outlined below:

This underscores the need to put more effort into detection and protection on the Identity domain and do everything possible to implement additional layers of security here.

To address these challenges, Microsoft has developed a best practice for securing administrative privileges: the 3-tier model. This model enforces “Zero Trust Principles on all access,” emphasizing least privilege, assume breach, and explicit validation of trust.

Learn more about the 3-tier model for partitioning administrative privileges.

The model ensures that each tier has its own dedicated accounts, preventing cross-tier contamination. However, while the 3-Tier model sounds straightforward on paper, implementing it in practice often proves challenging leading to several common issues:

Problem 1: Limited visibility into cross-tier contamination
Problem 2: No simple way to prevent cross-tier contamination (virtual fencing)
Problem 3: Privileged accounts (Tier 0–1) are rarely used, so why keep them active all the time? (JIT: Just In Time)

Where there are problems, we naturally look for solutions and will discuss the typical attack chain in more detail and suggest a possible solution.

Problem 1: Limited visibility into cross-tier contamination

Many organizations use separate accounts for Tier 2 but combine accounts for Tier 0 and Tier 1. A clear improvement would be to fully separate Tier 0 and Tier 1 by assigning dedicated accounts to each.

However, organizations often lack the tools to identify where specific accounts are being used. They are also unable to detect whether Tier 0 or Tier 1 accounts are improperly used for Tier 2 activities, leading to contamination of Tier 2 by higher-tier accounts.

This lack of oversight creates opportunities for bad actors. A compromised Tier 2 account could allow attackers to access a Tier 0 or Tier 1 privileged account, enabling them to perform critical actions like accessing sensitive applications, servers, and data, as we discussed in podcast #3.

Visual representation of Problem 1: Lack of visibility into cross-tier contamination.

Solution 1: Enhanced insights and detection via Silverfort: We provide organizations with visibility and detection capabilities through the Silverfort tool (version 5.2).This tool lets you monitor which accounts operate in specific tiers and detect any cross-tier contamination.

Problem 2: : No simple way to prevent cross-tier contamination (virtual fencing)

We now receive alerts when these accounts are not used as intended, allowing us to identify which accounts are being misused. Wouldn’t it be even better if we could implement restrictions to guarantee these accounts are used solely for their intended purposes? This would eliminate the risk of oversight or human error entirely. Which brings us to the 2nd problem:

Solution 2: Virtual fencing through Silverfort: Silverfort version 5.2 introduces virtual fencing, allowing organizations to define clear policies that specify the purpose and tier of privileged accounts. These policies restrict accounts to their designated tier, ensuring they cannot cross into another and effectively preventing contamination.

Problem 3: Why keep privileged accounts constantly active?

Now that we have been able to segment these privileged accounts and restrict them to the playing field where they are needed, we can take one more step.

Privileged accounts are used infrequently and only for specific tasks. Keeping them constantly active unnecessarily increases the attack surface. A more secure approach would be to activate these accounts only when needed (preferably with MFA) and for a limited time, minimizing the window of opportunity for attackers.

Problem 3:Privileged accounts (Tier 0–1) are rarely used, so why keep them active all the time? (JIT: Just In Time)?

Solution 3: Just-In-Time (JIT) activation via Silverfort: Silverfort version 5.2 also introduces a JIT feature. This ensures privileged accounts are disabled by default in Active Directory and can only be enabled on request via MFA for a very limited time to complete the required task. The account is then automatically disabled, preventing misuse outside the defined time window. preventing misuse outside the defined time window.

Interested in learning more about Silverfort? Contact us at info@jarviss.be or give us a call at +32 9 394 99 11.