Three Wrong AD Tier Model Assumptions: 8 Months in the Field

When I planned the transition to the Active Directory tier model, I looked at the Microsoft documentation and thought, "This will be done in three months, then life will return to normal." It took eight months. Three fundamental assumptions of mine were proven wrong, each costing me dearly in the field.

This post explains what someone transitioning to the T0/T1/T2 separation actually encountered, with the benefit of hindsight. I'll share the plan's breaking points, not the technical steps.

A Quick Recap: What the Tier Model Separates

The tier model (a simplified version of Microsoft's Enhanced Security Admin Environment / ESAE) defines three layers:

• T0: Domain controllers, ADFS, PKI, ESAE forest, T0 admin accounts
• T1: Servers (application, database, file, monitoring), T1 admin accounts
• T2: Workstations, end-user accounts

The rule appears very simple: credentials from one tier can descend to a lower tier but cannot ascend to a higher tier. A T0 admin cannot RDP to a T2 machine; a T2 user does not have local admin privileges on a T1 server.

It's logical, clean, and easy to draw. When it hit the field, three things were wrong with my understanding.

Wrong Assumption 1 — "This is a Technical Transition"

The first week, I set up jump hosts, and using GPOs, I restricted the Domain Admins group from logging in locally and logging in as a batch job on T1/T2 machines. I enabled Restricted Admin RDP. I added T0 accounts to the Protected Users group. I was following the Microsoft playbook meticulously.

By the second week, blockages began:

• A T1 admin messaged me, unable to connect directly to a file server from their workstation: "Now I have to connect to the jump host first and then go from there every time? Why has it become so complicated?"
• A database admin wanted to "quickly fix" a certificate issue on a T0 PKI server with their T1 account. The policy didn't allow it. They called, sounding stressed.
• The Helpdesk team used to provide workstation support from their own user sessions. After the tier separation, they could no longer connect because there was no "T2 support" role.

⚠️ Policies Aren't Rewritten, Behaviors Are

The real burden of the tier model isn't in the GPO lines but hidden within the phrase "I've been doing it this way for years." Technical setup took three weeks; rewriting habits took five months.

This is why the visible steps and invisible steps of the transition fell into separate timelines:

• Visible: jump host, GPO, restrictions, jump host failover, Protected Users
• Invisible: helpdesk role matrix rewrite, change request procedure, MFA on jump host, formalizing the definition of "T0 task," jump host silent timeout discipline

The unwritten part took twice as long as the written part.

Wrong Assumption 2 — "I Know My Account Inventory"

Before the transition began, I had conducted a two-week inventory. I reviewed privileged groups, and open T0 groups like Domain Admins, Enterprise Admins, and Schema Admins were clean. We collected service accounts in a separate OU and marked which service they belonged to. The plan was theoretically airtight.

In the fifth month, a graph dropped on a Splunk dashboard: a BI reporting tool's service account was RDPing to 17 different servers in the last 30 days. The tool had no documentation, it wasn't marked which tier it belonged to, and nobody had even considered which tier it should belong to.

I dug deep:

1. The service account was created five years ago for a data warehousing project.
2. Back then, it required local admin privileges on the SQL Server.
3. Later, privileges were added to multiple servers "for convenience."
4. Originally, it was only supposed to read data, but it was getting interactive logins on 17 servers.

This nightmare wasn't isolated. Within three months, I found four similar "ghost" accounts: no documentation, owner unknown, privilege level not in the plan.

ℹ️ Service Account Inventory = Half the Stage

Privileged group inventories are often done, but "service account inventories" are rare. Yet, the quietest path for lateral movement is often through a service account. Before the transition, for each account: which service, which tier, last login date, minimum required privilege—should be clear.

Then came the "linked account" problem. A T1 admin's daily user account and their T1 admin account were linked in AD via the "manager" field. Phishing email → compromise daily account → T1 account traceable via manager field → potential token replay. I had seen Microsoft's recommendation that "daily and admin accounts can be the same person but must be structurally separate," but I hadn't even realized where this link originated in the field's setup.

Wrong Assumption 3 — "The Transition Will Be Completed, and Maintenance Will Be Easy Afterward"

By the eighth month, I had completed the major technical steps. T0 was isolated, T1 was organized, T2 was disciplined. MFA was active on all jump hosts. Service accounts were distributed, and their privileges were minimal. The project plan appeared closed.

Two weeks later, during a new application deployment, an issue arose: the development team wanted the new service's Service Account to run under "Domain Admins." This time, it was rejected because the procedure was written down. But the developers' pressure continued—to their managers, then directly to the director.

The tier model is not a one-time transition; it's continuous discipline. Just because the structure is in place doesn't mean maintenance becomes automated; quite the opposite, every new service/system/project requires the model to be re-tested. If there's a structure where you can say, "Let's skip the extra step, let's get this done quickly this time," the tier model will erode over time.

I swore I would never overlook these three things:

• Quarterly tier audit: Every quarter, run a BloodHound + custom PowerShell script to verify that tier boundaries are still being enforced.
• New service onboarding checklist: When a new corporate service arrives, document which tier it belongs to, which service account it will run with, whether it requires a jump host.
• Quarterly red team simulation: Internal drills where we attempt to pivot from a T2 machine to T0. If we can pivot, there's a hole in the tier.

💡 Measuring the Tier Model = Attack Simulation

Compliance checks answer the question, "Are the GPOs correct, are the memberships clean?" But the real measure is: can you find a path from T2 to T0? Without BloodHound + manual discovery, you can't know if the tier model is truly working in the field.

Where the Tier Model is Also Valuable in "Small" Environments

Perhaps you're not at a corporate scale: 50 endpoints, 5 servers, a small office. The full Microsoft tier model might seem excessive. Still, two minimal disciplines are useful:

• Separate admin account usage: Don't RDP to a server with your daily user account. Create a separate "admin" account and use only that for management. This is 60% of the tier model.
• Stay away from Domain Admin: If local admin is sufficient, don't grant domain admin. A single Domain Admin account used only on DCs. It doesn't log into workstations. This is 30% of the tier model.

These two steps significantly reduce the compromise radius even in small environments. You can add the full tier model later.

Conclusion

Transitioning to the Active Directory tier model is not as linear as it appears in the plan. The book says three months; the field gave me eight. I paid the price through three fundamental assumptions:

1. "This is a technical transition" → It wasn't; it was a behavioral rewrite.
2. "I know my account inventory" → I didn't; ghost service accounts were lurking.
3. "The transition will be completed, and maintenance will be easy afterward" → It's never completed; it requires continuous discipline.

The tier model significantly reduces lateral movement risk—but for it to deliver value, it requires long-term organizational discipline. If you are in an environment where this discipline cannot be sustained, the model remains on paper; its real benefits are not realized.

If you are still managing an environment that hasn't transitioned to the tier model, plan for three months; prepare for eight. Be passionate, but don't rush.