Identify Tier 0 assets: a complete AD inventory method

Every Tier 0 control you deploy afterward, from deny-logon GPOs to authentication silos, protects only the list of assets you feed it. Most tiering projects fail not because the controls are weak, but because the list is wrong: the backup server that can restore NTDS.dit, the vCenter that hosts the DCs, the helpdesk group that can reset a Domain Admin's password through a forgotten ACE. Attackers do not care which assets you labelled Tier 0. They follow control relationships until one reaches the domain.

This guide gives you a repeatable method to build that inventory: the definition to apply, the categories most teams miss, the PowerShell to enumerate them, and how to record the result so later controls can consume it. It goes deeper than the overview in Tier 0 and privileged access, which you should read first for the tier model itself.

The definition: control, not importance

A system is Tier 0 if compromising it lets an attacker take control of Active Directory. That control can be direct (logon to a DC, membership in Domain Admins) or indirect (writing a GPO linked to the Domain Controllers OU, issuing a certificate that authenticates as any user, reading a DC's virtual disk). The test is transitive: if A controls B and B is Tier 0, then A is Tier 0.

Two consequences follow. First, "business critical" is irrelevant: your ERP system is important but usually Tier 1. Second, Tier 0 is bigger than the Domain Controllers OU, and the goal of the inventory is to find everything in it, then shrink it deliberately by removing control paths you do not need.

Measure: the asset categories

Work through the categories below. Most of them can be discovered from AD itself.

Domain controllers and their platform

All writable DCs and RODCs, plus everything underneath them: hypervisor hosts, the virtualization management plane (vCenter, SCVMM, Hyper-V cluster admins), SAN or storage arrays that hold DC disks, out-of-band management (iLO, iDRAC) on physical DCs, and the DC backup repository.

# Every DC in the forest, with OS and RODC flag
(Get-ADForest).Domains | ForEach-Object {
    Get-ADDomainController -Filter * -Server $_ |
        Select-Object Domain, HostName, OperatingSystem, IsReadOnly, Site
}

Identity infrastructure

• AD CS: every enterprise CA, plus the offline root. A CA that issues client-authentication certificates can mint a logon for any account.
• AD FS servers and anyone who can read their token-signing key.
• Microsoft Entra Connect / Cloud Sync servers. The sync account holds replication rights (and password hash sync reads every hash).
• PAM and vault platforms (CyberArk, Delinea and similar) that store or inject Tier 0 credentials.

$config = (Get-ADRootDSE).configurationNamingContext

# Enterprise CAs registered in the forest
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config" `
    -Filter 'objectClass -eq "pKIEnrollmentService"' -Properties dNSHostName |
    Select-Object Name, dNSHostName

# Entra Connect footprint: sync accounts and the Seamless SSO computer object
Get-ADUser -Filter 'SamAccountName -like "MSOL_*" -or SamAccountName -like "Sync_*"' -Properties Description |
    Select-Object SamAccountName, Description
Get-ADComputer -Filter 'Name -eq "AZUREADSSOACC"' -Properties PasswordLastSet

The Description of MSOL_ accounts normally names the server running Entra Connect. That server is Tier 0.

Management planes that reach Tier 0

Anything that runs code on a Tier 0 machine is Tier 0: SCCM/MECM site servers whose collections include DCs, Intune if it manages PAWs, EDR consoles with remote shell or script execution on DCs, patching tools, monitoring agents that run as SYSTEM with central script push, and the PAWs and jump hosts used to administer Tier 0. Discovering these is mostly an interview exercise: list every agent installed on a DC and ask who controls its console.

# Services and their run-as accounts on each DC, a starting point for agent discovery
Get-ADDomainController -Filter * | ForEach-Object {
    Get-CimInstance Win32_Service -ComputerName $_.HostName |
        Where-Object { $_.PathName -notmatch '\\Windows\\' } |
        Select-Object PSComputerName, Name, StartName, PathName
}

Audit: accounts, groups and indirect control

Built-in privileged groups

Start from well-known SIDs rather than names, which vary by language:

Add DnsAdmins (no fixed RID) and any product groups with domain-level rights, such as Exchange's Exchange Windows Permissions in older deployments.

$domain = Get-ADDomain
$root   = Get-ADDomain -Identity (Get-ADForest).RootDomain
$d = $domain.DomainSID.Value
$r = $root.DomainSID.Value
$targets = @(
    'S-1-5-32-544','S-1-5-32-548','S-1-5-32-549','S-1-5-32-550','S-1-5-32-551',
    "$d-512","$d-516","$d-520","$d-526" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $domain.DNSRoot } }
) + @(
    # Schema Admins, Enterprise Admins and Enterprise Key Admins exist only in the forest root domain
    "$r-518","$r-519","$r-527" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $root.DNSRoot } }
)

foreach ($t in $targets) {
    $g = Get-ADGroup -Identity $t.Sid -Server $t.Server
    Get-ADGroupMember -Identity $g -Server $t.Server -Recursive |
        Select-Object @{n='Group';e={$g.Name}}, Name, objectClass, distinguishedName
}

Every member returned is a Tier 0 account, including service accounts and members of nested groups you did not expect. -Recursive returns only the leaf users and computers, so list the nested groups themselves with a non-recursive query if you need them.

Indirect control through ACLs and GPOs

This is where most inventories are incomplete. Look for:

• Replication rights on the domain head (DS-Replication-Get-Changes-All), covered in finding DCSync rights.
• Write access to GPOs linked to the Domain Controllers OU or the domain root, and gPLink write rights on those containers.
• Owners and write rights on AdminSDHolder, Tier 0 OUs and Tier 0 user objects (reset password, GenericAll, WriteDacl, WriteOwner).
• Readers of Tier 0 secrets: principals allowed to retrieve gMSA passwords used on Tier 0 servers, and principals that can read LAPS passwords of Tier 0 computers.

# GPOs linked to the Domain Controllers OU and who can edit them
$dcOu = (Get-ADDomain).DomainControllersContainer
(Get-GPInheritance -Target $dcOu).GpoLinks | ForEach-Object {
    $gpoName = $_.DisplayName
    Get-GPPermission -Guid $_.GpoId -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity' } |
        Select-Object @{n='GPO';e={$gpoName}}, @{n='Trustee';e={$_.Trustee.Name}}, Permission
}

# Principals that can read gMSA passwords, for gMSAs running on Tier 0 servers
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Manual ACL review does not scale past a few containers. Run BloodHound or an equivalent graph tool, mark your known Tier 0 objects, and list every principal with a path into them. The workflow is described in attack path management.

Common misses

Across assessments, the same assets are left out of Tier 0 again and again. Check each one explicitly.

Cloud identity with a path back on-premises. If Entra Connect runs with password writeback, or if cloud administrators can manage the Entra Connect server through Azure Arc, Intune or a cloud-hosted VM console, then some cloud roles can reach Tier 0. List who holds Global Administrator, Hybrid Identity Administrator and the owners of the subscription hosting any DC or sync server, and treat those roles as part of the inventory.

DnsAdmins and DNS zone rights. Membership in DnsAdmins, or write access to the DNS server configuration, has historically allowed code execution on DCs through server-level DNS plugin settings. Even where patched, write access to AD-integrated zones lets an attacker redirect traffic for DC names. Keep the group empty or Tier 0 only.

Certificate templates and PKI objects. The CA server is not the only AD CS asset. Write access to certificate templates, the NTAuthCertificates object or the Public Key Services container in the configuration partition can produce a template that authenticates as a Domain Admin. These objects live in the configuration partition and are easy to miss in an OU-based review.

Backup and snapshot consoles. Anyone who can restore a DC's system state, mount a snapshot or export a VM from backup can read NTDS.dit. This includes backup operators in the backup product, not only the AD Backup Operators group.

Service accounts running on DCs. Monitoring, backup and EDR agents often run under a domain account whose password is stored on dozens of Tier 1 servers. The account is Tier 0 because it runs on DCs, so every server that stores its password is now Tier 0 too. Replace such accounts with local SYSTEM, a gMSA restricted to DCs, or a dedicated per-tier account.

Old administrators. Former admins with adminCount=1, stale ACEs granted by name years ago, and disabled accounts that still own Tier 0 objects all keep control paths alive. Ownership in particular grants implicit WriteDacl, so check the Owner of Tier 0 objects, not only their DACL.

Enforce: record and contain the inventory

An inventory that lives in a spreadsheet drifts within weeks. Encode it in AD so policies can target it:

1. Create a dedicated Tier 0 OU structure (for example OU=Tier0 with Accounts, Groups, Servers, Devices children) and move every Tier 0 user, group and server object into it. Block inheritance only if you have reviewed what it removes.
2. Create a group such as Tier0-Servers and Tier0-Accounts containing the computer and user objects, so deny-logon GPOs and silos reference groups, not lists.
3. Restrict who can modify that OU tree to Tier 0 admins only. Remove inherited delegations from helpdesk and Tier 1 groups.
4. For each indirect path you found, decide: remove it (the common answer), or accept it and move the controlling principal into Tier 0.

# Tag Tier 0 servers for downstream policy targeting
$t0 = Get-ADGroup 'Tier0-Servers'
'DC01','DC02','PKI-ISSUING01','ENTRACONNECT01' | ForEach-Object {
    Add-ADGroupMember -Identity $t0 -Members (Get-ADComputer $_)
}

Verify

Verification means proving there are no unexplained control paths into the tagged set:

# Objects protected by SDProp: anything here that is not in your Tier 0 list needs explaining
Get-ADObject -LDAPFilter '(adminCount=1)' -Properties objectClass, whenChanged |
    Select-Object Name, objectClass, whenChanged, DistinguishedName

# Tier 0 OU: non-inherited ACEs granted to principals outside Tier 0
$ou = "OU=Tier0,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:$ou").Access | Where-Object { -not $_.IsInherited } |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Stale adminCount=1 accounts are common after people leave privileged groups. Clear adminCount and restore inheritance on those accounts once you have confirmed they no longer belong to a protected group. In the graph tool, the check is simple: the number of non-Tier 0 principals with a path to Domain Admins should trend toward zero, and every remaining path should have a ticket.

What it breaks

• Shared management tooling: once DCs are declared Tier 0, the enterprise SCCM, EDR or monitoring console that manages them is either promoted to Tier 0 (with its admins) or has to stop managing DCs. Both options change operational ownership and need a separate tool or scope for Tier 0.
• Virtualization operations: VMware or Hyper-V admins who can manage DC VMs become Tier 0 admins. Expect pushback, and plan a dedicated cluster or a restricted permission scope on the DC VMs.
• Delegated helpdesk rights: moving Tier 0 accounts into a protected OU removes password-reset and unlock delegations that previously applied to them. Admins who lock out their Tier 0 account now need a Tier 0 peer, not the helpdesk.
• Backup restores: restricting the backup platform to Tier 0 operators can slow routine file restores if the same console serves both. Split the DC backup job onto dedicated infrastructure, as described in protecting AD backups from ransomware.

Related reading: the Tier 0 and privileged access overview for the full area, privileged access workstations for the devices that administer this inventory, and ACL and object security for auditing the indirect control paths in depth.