Most intrusions do not end where they begin. A stolen password on a laptop or a compromised vendor account is only the opening move, and the real objective sits several steps away: the small set of identities and systems that control everything else. In Active Directory environments, that set is called Tier 0. Whoever holds it can create accounts, disable security tools, read stored credential hashes, and rewrite the rules that govern the network. Defenders therefore have good reason to treat it differently from the rest of the estate. The discussion below covers what belongs in Tier 0, why domain admins and domain controllers attract so much attention, how paths lead into the tier, and which hardening steps hold up in practice.
What Belongs in Tier 0 and What Often Slips In
Tier 0 comes from Microsoft’s tiered administration model, which separates assets by the damage their compromise would cause. The core is easy to name: domain controllers, the Domain Admins, Enterprise Admins, and Schema Admins groups, and the accounts that populate them. Beyond those sit the systems that can control the core, including Active Directory Certificate Services servers, synchronization servers such as Entra Connect, and privileged access management or backup systems that hold domain-level credentials.
The boundary tends to drift. A monitoring agent installed on a domain controller, a management server with administrator rights across all tiers, or an old service account once added to Domain Admins to fix a deployment all pull extra objects into the tier without anyone deciding they belong. Any system that can reach Tier 0 control is effectively Tier 0, whatever the architecture diagram says.
Because the boundary drifts, teams need an explicit definition and a recurring check against it. Start by listing the assets that are unambiguously Tier 0, then ask for each one what can administer it, log on to it, or change its configuration. Every answer expands the list until it stops growing. The final list is often longer than expected, and that surprise is useful because it shows the real size of the protection task.
Domain Admins and the Shortcut to Everything
A Domain Admins member can log on to every domain-joined machine, change any account, edit Group Policy, and read the directory database. Attackers know this, which is why credential theft campaigns so often aim at administrator accounts. Credentials entered interactively on a machine may remain in memory, where tools such as Mimikatz can extract them. That is the mechanism behind many lateral movement chains: the intruder waits on a lower-tier server until a privileged user connects, and one careless logon hands over the whole domain.
Persistence matters here too. Once an intruder holds domain admin rights, they can plant backdoors that survive a password reset, such as adding a hidden permission to the AdminSDHolder object or forging Kerberos tickets with the KRBTGT account’s key. Those techniques make the response far harder than simply disabling an account.
The practical lesson is to limit both the number and the exposure of these accounts. Standing membership in Domain Admins should be small, often only a handful of named people, and daily work should happen under separate, lower-privilege accounts. An administrator who reads email and browses the web from the same identity that holds domain rights has handed attackers a short route to the top.
Domain Controllers as the Prize
Domain controllers store the directory database, usually in a file called NTDS.dit, which holds password hashes for every account in the domain. An attacker with administrative access to a controller can copy that file, or can use replication rights to request credential data remotely in what is known as a DCSync attack. Neither method needs the attacker to sit at the console for long, and both produce material that can be cracked or replayed offline.
The KRBTGT account deserves specific mention. Its key signs every Kerberos ticket-granting ticket in the domain, so stealing it allows a forged ticket, often called a golden ticket, that grants access for as long as the key stays unchanged. Resetting the account password twice, with time between resets, is the standard way to invalidate that forgery after a compromise.
Finding the weak points around controllers is where tier 0 attack path analysis earns its place in a security program. Instead of asking only who belongs to Domain Admins, the analysis asks who can reach a controller through any chain of permissions, sessions, or delegations. A helpdesk group with rights over a controller’s computer object, or a backup operator on a poorly guarded server, may offer a shorter route than any direct admin account. Seeing those routes before an intruder does is the point.
Finding the Routes That Lead Into Tier 0
Direct membership is the easy part to audit. The harder part is indirect control: a permission to reset passwords, write to a group’s membership attribute, or modify a Group Policy linked to the domain controllers organizational unit. Any of those allows a lower-level account to influence a Tier 0 asset, so each one is effectively a Tier 0 permission.
Running tier 0 attack path analysis on a regular basis turns these relationships into a short list of exposures that someone can own. A useful output names the starting identity, the chain of steps, and the specific permission that makes each step possible. With that detail, an engineer can remove one edge rather than guess. Without it, reviewers tend to fall back on group membership lists, which miss most of the real exposure.
Timing also matters. A directory changes through hiring, migrations, application onboarding, and emergency fixes, and each can introduce a new route into the tier. Quarterly reviews leave attackers a long window. Teams that automate the analysis, or at least tie it to major change events, catch new routes while the person who made the change still remembers why.
Hardening Steps That Hold Up in Practice
Hardening works best as a set of reinforcing measures, because no single one stops a determined intruder. These steps cover the areas that most often decide the outcome:
- Create separate administrative accounts for Tier 0 work, used only on dedicated privileged access workstations.
- Block Tier 0 accounts from logging on to member servers and workstations through deny-logon rights and authentication policies.
- Place privileged users in the Protected Users group, which blocks NTLM authentication, weaker Kerberos encryption, and credential caching.
- Reduce the software on domain controllers, restrict their internet access, and patch them ahead of other systems.
- Review replication permissions and AdminSDHolder entries to remove rights nobody can justify.
- Reset the KRBTGT password on a schedule and after any suspected compromise, and keep tested directory backups offline.
Sequence matters. Account separation and logon restrictions usually reduce risk fastest because they cut the credential theft chain directly. Controller hardening and permission reviews follow. Each step should be tested in a lab or with a limited group first, since logon restrictions can break scheduled tasks and services that quietly relied on privileged accounts. Document exceptions with an owner and an expiry date so they do not become permanent.
Key Takeaways
Tier 0 draws attackers because it converts a single foothold into control over every identity and system in the domain. The tier is larger than its official membership, since anything that can administer a Tier 0 asset belongs in it. Domain admin accounts need limited standing use and strict logon boundaries, while domain controllers need minimal software and tight replication permissions. Path analysis closes the gap between what group lists show and what an intruder can actually reach. None of this demands a rebuild. It demands a clear definition of the tier, a habit of rechecking it, and the discipline to remove permissions that no longer have an owner.
