If backup and snapshot access equal domain-secret theft, how should you scope the privileged tier?
answer
- measure by capability, not title
- replication, backup, snapshot, storage
- the union is tier-zero
- the auditor's count hides the gap
- cost versus certain exposure
basics
~20 sDefine the privileged tier by capability, not title: every principal that can replicate the directory, back up a domain controller, or snapshot its VM can reconstruct all password hashes and is therefore tier-zero. Counting named admins undercounts the real privileged set.
solid answer
~50 sThe set of principals who can obtain all domain secrets is far wider than Domain Admins. It includes accounts with delegated directory-replication rights, backup and restore roles, virtualization admins who can snapshot a controller's VM, and storage admins who can read its volume — each reaches the same hashes by a different door. As the architect you define **tier-zero by capability, not by job title**: audit the domain's access-control list for replication rights, inventory who holds controller backups and snapshots, and then either remove those paths or bring those accounts under the same protection (separate admin identities, hardened workstations, monitored access) as Domain Admins. The organisational friction is real: the virtualization and backup teams do not see themselves as security-critical, budget owners resist the added controls, and an auditor counting three named admins will sign off on a gap. The judgment is holding the line that their access already equals Domain Admin, whatever the chart says.
go deeper
Understand that more people than the named admins can reach the domain's secrets, so a simple admin count does not describe the risk.
Explain the specific capabilities — replication rights, backup, snapshot, storage — that each reach all domain hashes, so the privileged set is their union.
Show how you would enumerate that real set by audit and remove or restrict the paths, treating every copy of a controller's disk as privileged.
Own the tradeoff and the politics: extend tier-zero by capability, fund the controls, and defend that scope to infrastructure teams and auditors who would rather count three admins.
## The question behind the question A reviewer says: 'Only Domain Admins can steal the directory, and we have three; we are fine.' Everything about the domain database shows why that is a dangerous miscount — and turning that into an operating decision is a leadership call, not a technical one. The task is to define **who belongs in the most-privileged tier** (often called *tier-zero*: the accounts and systems that, if compromised, compromise the whole domain). ## Capability, not title The principle is that tier-zero membership is decided by **what an account can do**, not what group it is in or what its job description says. For the domain database, every one of these capabilities ends at the same prize — all long-term keys at once: - **Delegated replication rights** — an account granted the two replication extended rights on the domain object, e.g. a directory-synchronisation service account. - **Backup and restore** — anyone who can produce or read a controller's backup image. - **Virtualization admin** — anyone who can snapshot or clone the controller's virtual machine. - **Storage/SAN admin** — anyone who can read the controller's underlying volume. None of these need to be a Domain Admin. All of them are, in effect, domain-secret superusers. So the privileged tier is the *union* of these capabilities, discovered by audit, not the membership of one group. ## What you actually do 1. **Enumerate the real set.** Read the domain object's ACL for replication rights; inventory backup jobs and repositories that touch controllers; list who can snapshot the controller VMs; list who can read their storage. 2. **Remove what you can.** Strip stale delegated replication rights, isolate controller backups, and restrict snapshot/storage access to a minimal, named set. 3. **Govern the rest as tier-zero.** The capabilities you cannot remove (someone must back up the controllers) get the same controls as Domain Admins: separate privileged identities, hardened administrative workstations, restricted and monitored access paths. ## The organisational friction — the heart of the principal call This is where it stops being a technical problem: - The **virtualization and backup teams** consider themselves infrastructure, not security, and resent being pulled into privileged-access controls and change friction. - **Budget and ownership**: hardening those paths costs money and slows those teams; someone with authority must decide that cost is worth it against a certainty of exposure. - **The auditor**: a compliance review that counts named Domain Admins and reports 'three privileged accounts, all compliant' produces a green result over a real gap. Part of the job is refusing that framing and insisting the scope match capability. There is no single right answer to *how far* to extend the tier or *how much* control to impose — it is a genuine tradeoff between operational cost and the certainty that unmanaged access already equals Domain Admin. Owning that tradeoff, and defending it to teams and auditors who would rather not hear it, is the principal-level work. ## Why this sits above the senior question The senior engineer can prove that backup access equals replication rights. The principal must decide **what the organisation does about it** under real constraints of budget, ownership, and audit — and hold that line when the easy answer ('we have three admins') is the one everyone wants to accept.
- An auditor reports 'three privileged accounts, all compliant.' Why might that be dangerously wrong?It counts named Domain Admins and misses delegated replication rights, backup operators, and virtualization admins — each of whom can reconstruct every hash. The true privileged set may be dozens of accounts across teams that never appear in the report, so a green result sits over a wide-open path to all domain secrets.
- What is the tradeoff in bringing the backup and virtualization teams into tier-zero?It closes the real attack surface but imposes separate admin identities, hardened workstations, and restricted, monitored access on teams that resist being treated as security-critical, adding cost and change friction. You weigh that against the certainty that their access already equals Domain Admin — which usually decides it.
saying these in an interview costs you the question
- Believes the count of Domain Admins is the size of the privileged tier.
- Treats backup and virtualization teams as outside security scope.
- Defines tier-zero by job title rather than by capability.
- Accepts an audit that counts named admins as proof the domain is safe.