Active Directory tiering: protecting domain admin in a small agency

Reference article · 5 min read

Most Active Directory compromises in small organizations follow the same path. An attacker gets code running on an ordinary workstation, waits for someone with elevated rights to log in or connect to that machine, harvests the credential left behind, and uses it to reach a domain controller. The details change from year to year. The pattern does not.

Microsoft originally described the countermeasure as the administrative tier model and has since folded it into what it calls the Enterprise Access Model. Agencies with a small IT staff often conclude it assumes a team they do not have and set it aside. The core of it does not require a redesign. It requires deciding which systems hold the keys to the domain, then refusing to let the credentials that open them touch anything else.

The three tiers in plain terms

Tier 0. Anything that can take control of the directory: domain controllers, the AD database and its backups, certificate services, the identity sync servers bridging to cloud tenants, and the accounts that administer them.
Tier 1. Member servers and the data they hold: file servers, the finance system, the permit system, hypervisors, line of business databases.
Tier 2. End user devices: staff laptops, desktops, kiosks, and the helpdesk accounts that support them.

The tiers rank blast radius, not importance. A police records system may matter more to daily operations than a domain controller does, but control of a tier 0 asset gives an attacker every other tier for free.

The rule that makes it work

A privileged credential never authenticates to a machine at a lower tier.

That is the whole model. A domain admin account signs in only to domain controllers and to a dedicated admin workstation. It does not log into a file server, does not run a helpdesk session on a user's laptop, and is not the service account for a backup job. The reason is mechanical: Windows keeps credential material in memory when an account authenticates, and anyone with administrative control of that machine can reuse it. A tier 0 credential typed on a tier 2 laptop has effectively turned that laptop into a domain controller.

The corollary matters as much: tier 0 systems accept administration only from tier 0 sources, and should not depend on lower tier services for management, patching, or monitoring.

A sequence for an agency that cannot start over

Inventory tier 0 honestly. List every system that can issue or reset credentials, sign tokens, or reach domain controller storage. Backup servers and virtualization hosts belong on it, because whoever can restore or mount a domain controller owns the directory.
Split the accounts. Every administrator gets a separate privileged account with no mailbox, no browsing, and no daily use. Naming should make the tier obvious at a glance. Daily driver accounts lose all administrative rights.
Give privileged accounts somewhere safe to run. A dedicated privileged access workstation is the strongest option. A hardened jump host that only tier 0 accounts may reach is the realistic starting point for most small agencies. Either way, build and patch it independently of the general fleet, and keep internet and email off it.
Clean out stale membership. Domain Admins and Enterprise Admins accumulate former staff, vendor accounts, and service accounts added years ago to make something work. Keep Enterprise Admins and Schema Admins empty except during a change that requires them, and size service account rights to the task.
Disable unconstrained delegation. A computer or account flagged as trusted for delegation can impersonate users who authenticate to it, including administrators. Enumerate it, remove it, and move anything that genuinely needs delegation to constrained or resource based delegation. Put sensitive accounts in the Protected Users group and set the flag marking them ineligible for delegation.
Stop reusing local administrator passwords. One shared local admin password across the fleet turns a single compromised workstation into all of them. Windows LAPS or an equivalent that randomizes and escrows them closes that path.

Monitoring the handful of groups that matter

Full directory auditing is not the prerequisite. Watch membership changes on Domain Admins, Enterprise Admins, Schema Admins, the built in Administrators group, Account Operators, Backup Operators, Server Operators, Print Operators, Group Policy Creator Owners, and DnsAdmins. Security event IDs 4728, 4732, and 4756 record additions to global, domain local, and universal groups. Alert on each one, to a person, not only to a dashboard.

Also review objects carrying the adminCount attribute, which marks accounts AdminSDHolder protected at some point and often reveals forgotten privilege. Then review interactive logons by tier 0 accounts, treating a logon to any non tier 0 machine as an incident rather than an exception to record.

What to ask vendors and put in the contract

Applications are a common reason tiering quietly collapses. Before signing, ask directly:

Does the product require a domain administrator account to install, run, or update, and why?
What are the minimum rights the service account needs, stated as specific permissions rather than a group name?
Does it require Kerberos delegation, and will constrained or resource based constrained delegation work?
Does it support group managed service accounts, and does it store credentials in reversible form?

In the contract, require a least privilege installation and operation guide, written justification for any elevated rights, and vendor remote support that connects through your jump host using your accounts rather than a vendor maintained tunnel. Policies that apply to agency systems, including the FBI CJIS Security Policy, address privileged access and least privilege, but control language changes across revisions, so confirm current requirements with the official source before citing them in a solicitation.

HQT works with state and local agencies on Active Directory hardening and privileged access design.

Frequently asked questions

What is the Active Directory tier model?

It is a way of grouping systems and accounts by how much damage their compromise would cause. Tier 0 covers domain controllers, the directory database and backups, certificate services, and identity sync systems. Tier 1 covers member servers and applications, and tier 2 covers workstations and the helpdesk accounts that support them. The model works by keeping credentials from one tier from ever authenticating to a machine in a lower tier.

Can a small agency implement tiering without redesigning Active Directory?

Yes. Most of the benefit comes from separating daily accounts from privileged accounts, giving privileged accounts a hardened workstation or jump host to run from, cleaning stale membership out of the top administrative groups, and disabling unconstrained delegation. Those steps do not require a new forest, new domains, or a large reorganization of organizational units. A formal administrative forest is an advanced option, not a starting point.

Do we need a privileged access workstation, or is a jump host enough?

A dedicated privileged access workstation gives stronger protection because the administrator's endpoint itself is hardened and separated from email and general web browsing. A hardened jump host that only privileged accounts may reach is a common and reasonable first step for agencies that cannot issue second devices. Whichever you choose, build and patch it independently of the general workstation fleet, and do not manage it from a lower tier system.

Why is unconstrained delegation a problem?

A computer or account trusted for unconstrained delegation receives forwardable tickets from anyone who authenticates to it, which lets it impersonate those users elsewhere. If an administrator connects to such a system, whoever controls it can act as that administrator. Replace it with constrained or resource based constrained delegation, and place sensitive accounts in the Protected Users group with the flag that marks them ineligible for delegation.

What should we require from a vendor whose software asks for domain admin rights?

Ask for a written technical justification and the specific minimum permissions the software actually needs, stated as permissions rather than as a group name. Require a least privilege installation and operation guide as a contract deliverable, and ask whether the product supports group managed service accounts. Also require that vendor remote support connect through your jump host with accounts you control rather than through a vendor maintained tunnel.