Credential Tiering - Implementing Tier 0

Credential Tiering

Implementing Tier 0

Marius Elmiger
by Marius Elmiger
on December 14, 2023
time to read: 22 minutes


Methods for implementing Tier 0

  • Creation of an implementation plan is important
  • Tier 0 should be implemented first
  • A large number of Tier 0 objects can be identified via the Active Directory
  • However, there are also Tier 0 objects outside the Active Directory
  • Tier 0 objects should be evaluated on an ongoing basis
  • The implementation of Tier 0 does not usually lead to downtimes
  • The difficulty in implementing tiering lies primarily in the existing administrative routine

IT projects often start well, but unfortunately sometimes end with a mediocre solution or too many exceptions. Implementing credential tiering, on the other hand, requires a continuous commitment to meeting the defined objectives and minimizing exceptions. A well-defined implementation strategy is essential, along with the determination of all involved parties to significantly improve the security of a critical IT service like Active Directory through credential tiering.

This second article in a two-part series provides guidance on transitioning to a credential tiered Active Directory environment, focusing on Tier-0. Additionally, it introduces a method to measure security enhancements during the process. The described methods can be replicated for other identity centric solutions. The following section is aligned to the tiering Model from Microsoft, which is described in the first part, and on our experience with the implementation and attacking of non-segregated environments during our engagements.

The plan

Before diving into implementation, it can be beneficial to have a plan. Implementing credential tiering is often a large project that requires a detailed overview of the strategy, objectives and tasks to implement credential tiering. A project plan helps to organize resources and risk management and ensures a systematic approach. The following fundamental aspects should be considered first:

  1. Everything starts with a goal. As an example: To enhance security against credential theft from privileged entities, we aim to identify privileged entities, categorise them, and protect them through strict identity-centric segregation measures.
  2. If you don’t already have the attention of higher management start pitching the security concept to gain their full support. This is crucial for facilitating the mindset transition that IT employees will need to undergo.
  3. Are there multiple Active Directory forests with trusts to each other? If yes, potential inter-forest security boundary violations need to be considered. This might necessitate implementing an Admin Forest or selecting an existing forest for administration, which could be considered a mediocre solution. In this article, we assume a scenario with a single forest and single domain.
  4. To secure Tier-0 effectively, it must be isolated from other tiers to avoid any control-up or exposure-down risks. If, for some reason, complete separation is not feasible, identify which components cannot be tiered, as these components present an upstream risk to Tier-0.
  5. Decide if you roll out Privileged Access Workstations (PAW) for all tiers or, for example, only for Tier-0. Define the high-level requirements for PAWs, i.e., Remote Access.
  6. Define responsibilities for the tiers. I.e. Tier-0 are the Active Directory engineers; Tier-1 is mostly the IAM team and server team; and Tier-2 is mostly the client team.
  7. Create a RACI matrix for the implementation phase and the time after the migration.
  8. Create a tiering concept. The concept should include the final architecture of the solution. The new solution has an impact on the existing Active Directory disaster recovery (DR) and incident response (IR) concepts. Therefore, both the DR and IR concepts require adaptation.
  9. Establish a rough timeline and allocate sufficient internal resources to the project. It is essential that at least one internal Active Directory engineer devote a minimum of 80% of their time to the implementation. This is critical due to the project’s nature. It goes beyond implementing a technical solution; it requires a mindset shift to understand, address, and permanently eliminate tiering violations. The whole endeavor would be in vain if the staff did not subsequently adhere to the rules on how Active Directory should be managed in accordance with the defined tiering ruleset.

These aspects could lead to extensive discussions in which some people may question the entire project. However, this is the first phase of a change in awareness that employees will go through. We recommend initially explaining the challenges in a broader context, detached from the organisation, and in particular avoiding a direct probability assessment. The problem of complex statements such as “if we do not carry out x, we have y number of direct or indirect attack paths to z” can be made clearer through examples. A real-life scenario could show how certain users use their daily user account to access an organisation’s password vault, which contains privileged Active Directory credentials. The daily user account is thereby an indirect domain admin along with any entity that has admin rights to the vault. This creates a risk that privileges can be escalated from any tier to Tier-0. Once the fundamental challenges are understood, the discussion can move to the business perspective to encourage nuanced conversations. The focus should consistently be on the separation of administrative access to Active Directory, which is one of the most important services in many organisations. Additional examples can be found in Credential Tiering: The Value of Containment Part 1.

Everything starts with Tier-0

A house needs a strong foundation, just like Tiering. If Tier-0 is compromised, the attacker gains downstream control over everything that is controlled by Active Directory. That’s why a robust Tier-0 should be prioritized first. The following high-level implementation steps can be used as a guideline:

From here on, the clock starts ticking. Implement these steps promptly to prevent potential tampering by not-yet-transferred Tier-0 entities during the transition.

Identify the unknown

The identification of Tier 0 entities is one of the first steps in the implementation of Tier 0 in order to demonstrate the impact of non-segregated Tier 0 entities and support the transition to Tier 0. To identify Tier 0 entities quickly and effectively, the Graph Theory can be used. Certain tools that use graph theory have already implemented the necessary logic and help enormously with the assessment of dependency-based solutions such as Active Directory. The best-known tool is BloodHound from SpecterOps and Adalanche from Lars Karlslund. The following approach can be used for A1, A2, A3, A7, B2 and B10.

Prepare BloodHound FOSS or BloodHound CE

GRANT ROLE admin TO bloodhoundce

Neo4j Desktop Setup

Run SharpHound

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c DCOnly
SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c ComputerOnly

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c Session --Loop --Loopduration 04:00:00

Import Data to BloodHound

Mark Tier-0 entities

// Reset highvalue property
Match (u)
SET u.highvalue=false;

// Assign three new properties (Tiering) to all nodes
SET u.tier0 = false,
    u.tier1 = false,
    u.tier2 = false;

// Set the Tier-0 property to true for well known Tier-0 objects
UNWIND ["500","502","512","516","518","519","520","526","527","544","548","549","550","551","555","557","562","569","580"] as TierZeroRid MATCH (u) where u.objectid ENDS WITH "-"+TierZeroRid Set u.tier0=true;

// Find all domain objects and set the tier0 property
MATCH (u:Domain) SET u.tier0=true;

//Find all objects that allow unconstrained delegation and set the tier0 property
MATCH (u{unconstraineddelegation:true}) Set u.tier0=true;

//Find all objects that can directly or indirectly manipulate objects that have the property tier0 set to true
Match p=allshortestpaths((u)-[r:MemberOf|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GPLink|AddAllowedToAct|AllowedToAct|SQLAdmin|ReadGMSAPassword|HasSIDHistory|SyncLAPSPassword|AddSelf|WriteSPN|AddKeyCredentialLink|DCSync*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//Identify all entities with remote access to Tier-0 assets. These entities matter because they could become indirect Tier-0 administrators by escalating privileges on the target. For example, if a user can RDP to a client where a Tier-0 administrator is active, it might lead to compromising the Tier-0 accounts.
Match p2=allshortestpaths((u)-[r2:HasSession|CanRDP|CanPSRemote|ExecuteDCOM*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//OPTIONAL: Set all Tier-0 marked nodes as highvalue to have a better visibility in the BloodHound GUI (All Tier-0 objects will receive a diamond icon in BloodHound)
MATCH (u{tier0:true})
SET u.highvalue = true;

Mark Tier-0 entities

Find and flag external Tier-0 services

All Tier-0 entities that are managed directly through Active Directory should now have been identified automatically. What is missing are applications or services that can manage Tier-0 objects indirectly, but whose access management is handled by an external application. For example, solutions such as backup (NetBackup, ARCserve, Veeam), virtualisation (ESX, Hyper-V), monitoring (SCOM, Ivanti), system management (SCCM, Ivanti), vulnerability scanner (Nessus), AV (McAfee, Symantec, Defender), EDR (MDE, Tanium, CrowdStrike, SentinelOne), IAM (One identity, Sailpoint, NetIQ), SIEM (Splunk, Microsoft Sentinel, Qradar) etc. These services often use an agent on the endpoints or service accounts and have their own Role-based access control (RBAC) implementation. Therefore, to find out who has access to what, it is necessary to first identify the services running on Tier-0 systems and then interview the solution owner. In addition, system management tools or vulnerability scanners can assist in identifying active services and processes on a Tier-0 system. Also, if you do not have access to system management tools or vulnerability scanners, you can identify possible Tier-0 relevant services by running a simple PowerShell script on a Tier-0 system.

# Get all running services and processes
$RunningServices = Get-Service | Select-Object @{Name="Type"; Expression={"Service"}}, Name, DisplayName, Status
$RunningProcesses = Get-Process | Select-Object @{Name="Type"; Expression={"Process"}}, Name, Id
# Combine and output to grid view
$RunningServices + $RunningProcesses | Out-GridView -Title "Running Services and Processes"

After identifying services or processes running on Tier-0 servers, the application owner should be able to provide the necessary information about which users have administrative permissions. Often, AD groups or AD users are used in the Application itself. The identified AD objects should be flagged as Tier-0. You can use the following cypher query to search for a particular samaccountname and set the tier0 flag:

// Example to set the tier0 and highvalue flag on the node with the samaccountname grp-TenableAdmin
MATCH (u) where toLower(u.samaccountname) = toLower("grp-TenableAdmin") Set u.tier0=true, u.highvalue = true

Besides getting in touch with the Tier-0 application owners, it is sometimes also helpful to search the Neo4j database for well-known services. The following cypher query can be used for that:

// Modify the following keywords with service terms to suit your specific environment
UNWIND ["nessus", "tenable", "sccm", "scom", "ivanti", "esx", "vmware", "mcafee", "symantec", "tanium", "splunk", "qradar", "netbackup", "arcserve", "veeam", "crowdstrike", "sentinelone", "sailpoint", "netiq"] AS word MATCH (n) WHERE toLower( CONTAINS toLower(word) OR 
toLower(n.description) CONTAINS toLower(word) OR 
any(x IN n.serviceprincipalnames WHERE toLower(x) CONTAINS toLower(word)) OR 
toLower(n.distinguishedname) CONTAINS toLower(word) 
RETURN word as keyword, LABELS(n)[1] as type,, n.description, n.distinguishedname 

Search for Tier-0 Services in the Neo4j Database

Create a list of the identified Tier-0 entities

After following the steps described above, most Tier-0 entities should have been identified. The very “popular” tool Excel is often used for further planning. A csv file can be generated via the Neo4j browser. If the data set is too large, the following cypher query can be used:

// Create a csv file with all Tier-0 entities
// Enable apoc.export.file.enabled=true in the neo4j.conf
// Will be saved to: C:\neo4j\Database\relate-data\dbmss\dbms-guid\import

CALL apoc.export.csv.query("Match (u) where u.tier0=true return distinct LABELS(u)[0] as type,, u.enabled,u.description,u.objectid, u.distinguishedname order by type", 'all-tier0-entities.csv', {quotes: true, delimiter: ','});

Evaluation and progress tracking

During the evaluation phase, identified unused Tier-0 entities can already be removed. Entities that have to be recreated or migrated can be flagged according to the implementation schedule. To track improvements before, during and after the implementation of Tier-0, the following dashboard may become handy. Measure how many entities have a path to Tier-0

The figure shows how many entities have a direct or indirect path to the Domain Admin group or other Tier-0 entities. The percentage may require adjustments depending on the size of the organization. The environment depicted in the demo has a total of 2489 enabled user accounts. Therefore, the target for the Tier-0 accounts should be around 0.4% to 0.5%, depending on the size of the Active Directory team and the service accounts that are required for the Tier-0 segregation.

Further down in the dashboard, the graph algorithms of closeness centrality and degree centrality were employed to display potential privileged entities.

Identify privileged entities with the help of graph algorithms

The degree centrality algorithm can help determine popular nodes in a graph database. The algorithm measures the number of incoming and outgoing edges from a node. If nodes have a high number of edges, in particular outgoing edges, the node respectively the AD entity may be highly privileged. In contrast, the closeness centrality measures the node’s average distance to all other nodes and generates a list of nodes that can propagate information efficiently through a graph. Therefore, nodes with a high closeness score have the shortest distances to all other nodes, which can be an indication that the entity is privileged. Further information regarding the two algorithms can be found on the official Neo4j website or in the paper Start thinking in graphs: using graphs to address critical attack paths in a Microsoft cloud tenant.

To use the above dashboard, get the NeoDash application and import the dashboard from GitHub. NeoDash can be downloaded through the Neo4j Desktop application from the graph app gallery or directly from GitHub. NeoDash works also with the Neo4j Community Edition.

Next steps

Tier-0 can normally be implemented without exception or downtime. It takes, depending on the technical level of the employees, 6-12 months (excluding political debates). The implementation of Tier-1 is more difficult and can take a long time. Maybe not everything can be fully segregated, but important is the prioritization of privileged Tier-1 administrators and business-critical applications. They must be segregated and protected from less important Tier-1 assets. Another approach is to add another Tier. That means Tier-1 is only for IT and business-critical solutions. Tier-2 is for the less critical server applications, and Tier-3 is for client administrators.

A topic that was not touched on in this article but is essential for the tiering implementation is hardening and access policies. The hardening should follow either the CIS or Microsoft guidelines. My colleague Michael Schneider wrote a tool named HardeningKitty with which the hardening policies can be verified. Even more important are the access policies, which allow or deny cross-tier access. The preferred way is to use Authentication Policies and Authentication Policy Silos in combination with Authentication Mechanism Assurance (AMA). But also starting just with SmarCards and Group Policies is sufficient.


Implementing tiering is a challenging task, not primarily because of the technical difficulty of such an implementation, but due to the existing routine of operating an Active Directory. It remains a challenge for organizations to alter this routine, establish transparency about which AD objects are now privileged and effectively protect them. Tiering is not an installable tool; rather, it is a defined method of operating an Active Directory more securely. It establishes a particular state based on a set of rules that must be followed. If an Active Directory does not have a set of rules that restrictively protects the privileged entities, the Active Directory is exposed to risk to get compromised. Indirect Tier-0 permissions in particular are growing exponentially in large organisations without tiering, as more and more tools are installed that typically affect all servers or clients, and therefore the Active Directory domain controllers or their administrators. The two articles Part 1 and Part 2 explore how to implement tiering with both theoretical and practical examples of how to get started with a tiering implementation. The focus of both articles was primarily on Active Directory, but all identity provider solutions share the same challenges, so the approach presented can be used with other solutions such as Microsoft Entra ID, Google Cloud Identity and AWS Identity to effectively protect privileged entities.

About the Author

Marius Elmiger

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)


You want to test the security of your firewall?

Our experts will get in contact with you!

Foreign Entra Workload Identities

Foreign Entra Workload Identities

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger



Marius Elmiger

Outsmarting the Watchdog

Outsmarting the Watchdog

Marius Elmiger

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here