Menu
What Is Active Directory Tiering?

What Is Active Directory Tiering? Why Does Your Company Need It

Time to read 9 Minutes

The First Thing They Did Was Give Me Domain Admin

I still remember the exact moment. New Project, new client, first morning. I had not yet found the kitchen. I did not know where the bathrooms were. I was still carrying my jacket because I had not found somewhere to hang it.

And someone from IT walked over, handed me a sticky note with credentials on it, and said, “Here you go. Domain Admin. Should give you everything you need.”

That was it. No conversation about what I was there to do. No discussion about what systems I would actually be touching. No question about whether Domain Admin was even appropriate for what they had brought me in for. Just a sticky note, a handshake, and a assumption that more access is always better than less.

I smiled, thanked them, sat down at the workstation they had set up, and thought nothing of it. Because at that point in my career, I had seen it so many times that it felt completely normal. It was normal. That was the problem.

Why That Moment Matters Than It Seems

Twenty-five years in this industry. Helpdesk engineer at Getronics back when organizations were migrating away from Novell to Microsoft Active directory. Contractor across financial services, healthcare, agriculture, education.
Organizations from twenty people to twenty thousand. Different industries, different cultures, different levels of technical maturity.
 
The sticky note was everywhere
 
Sometimes it was a formal ticket. Sometimes it was an Email message. Sometimes someone just added your account to the Domain Admins group without telling you, and you only found out when you went to do something that should have required elevated access and it just worked. No friction. No checkpoint. Nothing
 
The reason was always practical, always well-intentioned, and almost always completely disconnected from the actual risk. “We need you to be able to do your job.” “We don’t have time to figure out the minimum access right now.” “It’s easier this way.” “We’ll sort out permissions properly once things settle own.”
 
Things never quite settled down, of course. The next contractor came in and got their sticky note too. And the first-line engineers had Domain Admin as wel. because at some point years ago someone had decided it was the path of least resistance, and that decision had simply never been revisited.
 
Nobody was reckless. That is the part that takes time to fully appreciate. Everyone involved was trying to do the right thing in the moment, under pressure of the moment. The problem was structural. The problem was that Active Directory had become central to everything: authentication, group policy, application access, server management, identity, the whole fabric of the IT environment. And yet the security model governing who could touch it had never been designed to reflect that reality.
 

What Active Directory Tiering Actually Is

There is no elegant way to introduce this concept, so I will say it plainly first and then explain what it actually means in practice.

Active Directory tiering is the practice of splitting you AD environment into distinct layers, each with its own accounts, its own access controls, and its own strict rules about what can interact with what. The whole point is that a compromise at one layer should not automatically become a compromise at every layer.
 
That is te version you will find in Microsoft’s documentation, in security frameworks, in compliance requirements. It is accurate. it is also a bit like describing surgery by saying “a doctor uses tools to fix things inside the body” true, but it does not quite prepare you for the room.
 

The model has three tiers. Tier 0 is your control plane: Domain Controllers, AD Connect, your Public Key Infrastructure, password management solutions. The things that, if compromised, mean everything else is compromised. Tier 1 is your server layer: application servers, database systems, the infrastructure that runs your business applications. Tier 2 is the user layer: workstation, end-user devices, standard accounts.

The rules are straightforward in principle. A Tier 2 account cannot authenticate to a Tier 0 system. A Tier 1 admin account cannot be used to log into a workstation. Credentials do not flow freely between layers. Anattacker who compromises a laptop in Tier 2 hits a wall before they can reach your Domain Controllers. 

Link
What Is Active Directory Tiering

The Military Complex, Explained over Coffee

Explaining this concept to people. Technical architects, project managers, CFO’s, Board members. The documentation version works for engineers. For everyone else, this analogy works.

Imagine a military complex. A physical building with multiple floors, each one with different access controls and different purpose.

At the top floor, the generals meet to discuss classified missions. Not everyone in the building knows those conversations are happening. Not everyone has a badge that opens doors. The people who do have access are few, trusted, and that access exist for one reason only.

On floor down, the officers are working on executions plans. They know the mission exist. They are building the operational detail. Their access is broader that the floor above, but it is still defined, still controlled, still separate.

And then there is everyone else. The general workforce, doing their jobs, going about their day. Necessary. Valued. But not involved in the classified conversation and not walking into rooms where those conversations happen.

That is Tier 0, Tier 1, and Tier 2. The analogy lands every time, across every audience, in every industry. Sometimes about the physical separation, the intuitive logic of it, People get it immediately.

The harder conversation is always what comes next. “So if that’s the model, what does your current environment look like”

What a Real Implementation Looks Like

In 2024, I was brought into a financial organization to implement tiering from start to finish. The trigger was an audit finding tied to DORA, the EU’s Digital Operational Resilient Act, which was coming into effect for financial entities and bringing real regulatory teeth with it. This was not voluntary security improvement project. This was a compliance requirement with timeline.
 
when I first mapped out their Active Directory environment, it looked exactly like every other AD i have worked in over the years. A top-level OU named after the organization. Under it: Users, Devices, Severs, Groups. Clean enough structure on the surface. But no privilege separation, no naming convention for administrative accounts, no process defining how admin access was provisioned or reviewed.
 
The senior engineers and the security team were brought in from the beginning, which was the right call. Communication was not a nice-to-have on this project. With no dedicated testing environment, changes were going directly into production AD. Every decision needed to be documented, understood, and agreed before it was executed. One wrong GPO applied to the wrong OU in a live environment is not an academic problem.
 
We built the new OU structure for each tier. we designed Group Policy Objects to enforce the boundary controls. For the domain Controllers, rather than relocating them to a new OU and introducing unnecessary risk during the migration, we applied the appropriate policy in place. The servers and the privileged admin accounts moved to their respective tiered structures once the framework was validated.
 
The work with the IAM team to define how tiered account would be created, named and managed turned out to be as important as the technical design itself. Naming conventions feel like a small detail until you are three months into an implementation, and nobody can tell at a glance which account operates at which tier. We produced a high-level design, a low-level design, and a naming convention document that the IAM team owned and maintained going forward.
 
What the environment looked like at the end: three defined tiers, enforced boundaries, tiered administrative accounts following consistent naming convention, a creation process owned by the IAM team, and documentation that could survive the departure od any individual involved in the project.
 
What it felt like on the way there: careful, methodical, occasionally tense, and exactly the kind of work that does not make headlines but quietly determines whether an organization van defend itself.
 
What Is Active Directory Tiering

The Objection That Always Comes Up

There is one conversation I have had more times than I can count, in dome form or another, on almost every project where privilege separation is on the table.
 
“This is going to block our workflow. Some of our applications need high-level access. This will slow everything down.”
 
It is a legitimate concern, framed as a fatal objection. The response is not to argue against it. the response is to take it seriously, because it points to a real gap in the planning.
 
Before you implement Active directory tiering, you need to know what level of access each process, application, and role actually requires. Not what it assumes it requires. Not what it has historically been given. What is actually requires. Does that application genuinely need Tier 0 access? maybe it does. If it does, that needs to be understood, documented, and factored into the design. Most of the time, when you do that analysis honestly, you find that Tier 0 access was granted at some point in the past because it was easier, not because it was necessary.
 
The other half of the answer is testing. Not because testing eliminates your entire AD environment exposed to lateral movement through any compromised accoutn.
 

Who Actually Needs This

The hones answer is that it depends, and anyone who tells you differently is either oversimplifying or selling something.
 
Full Active directory tiering as I have described it is most appropriate for organizations of meaningful size and complexity: enter prises with multiple servers, multiple administrative roles, regulatory obligations, and real exposure to targeted attacks.
Financial services, healthcare, critical infrastructure, education institutions with sensitive research data.
 
But the principle behind tiering are not exclusive enterprises. Least privilege. Separation of administrative duties. making lateral movement difficult. These are not enterprise-scale ideas. They are sound thinking that scales down.
 
For small organizations where full tiering is not yet practical, there are adjacent measures worth taking seriously, Just-in-time access, where privileged credentials exist only when task requires them and are automatically revoked when it is done.
Monitoring and alerting on privileged account usage. Dedicated administrative workstations that are not used for browsing, email, or anything else. Staff who understand why these controls exist and what they are protecting against.
 
Active Directory is the portal to your environment. That is true whether you have twenty users or twenty thousand. The question is not really whether you can afford to secure it. The question is whether you can afford what happens if you do not.
 

Where to Begin

If this has been useful, if something in here felt familiar or has named something you already knew was a problem, then there are three places to start.
 
First understand your current state. Before you design anything, audit who has administrative access, at what level, and whether that access is still appropriate. The sticky note problem is only fixable once you see the full picture of who has been handed sticky notes.
 
Second, build the structure before you enforce it. design you tiering model in a test environment where possible. If that is not available, plan your production changes in careful, documented phases. Agree your naming conventions early, with the people who will own them long after the project is finished.
 
Third, invest in communication. The technical work is traceable. What derails AD projects, and what derails IT security projects, is the human layer. Engineers who do not understand why thei workflows are changing. Manager who see compliance as a destination rather than a posture. Communication is not a project management nicety. It is load-bearing.
 
The boundaries between tiers only work if they are maintained. The biggest mistake I see in implementations that start well and drift over time is the introduction of exception. One account that needs to cross a tier boundary just once. One process that does not quite fit the model so it gets a pass. Each exception is a small gap. Small gaps accumulate.
 
The model is only as strong as the discipline behind it.
 
If your organization is working through an Active Directory security review, a tiering implementation, or a compliance project tied to frame works like DORA, NIS2, or ISO 27001, that is work we do. Not from a template. From years of being in rooms exactly like the ones described above.
 
 
Link
Get in Touch to talk through where you are

Get in Touch to talk through where you are

| |

Recent Posts

Categories

Technology (1)

Security (55)

Migrations (7)

Identity (3)

Table of Content