Which directory rights permit DCSync, and why is 'only Domain Admins can do this' wrong?
answer
- two extended rights on the domain
- the '-All' one releases secrets
- it is an ACL entry, not a group
- sync and backup accounts hold it
basics
~20 sTwo extended rights over the domain object grant it: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Domain Admins hold them by default, but the rights are delegable and often sit on directory-sync connectors and backup accounts nobody counts as privileged.
solid answer
~40 sDCSync requires two control-access (extended) rights on the domain naming context: `DS-Replication-Get-Changes` and `DS-Replication-Get-Changes-All`. The plain right replicates most attributes; the `-All` variant is the one that releases *secret* attributes like password hashes, so it is the one that turns replication into credential theft. These rights are granted by an entry in the domain object's access-control list and are fully **delegable** to any principal — they do not require membership in an admin group. In practice a directory-synchronisation service account, a backup or monitoring account, or a connector was often granted them years ago. So the reviewer who says 'only Domain Admins can do this and we have three' is wrong: the real set is whoever holds those two rights, which you find by auditing the domain's access-control list, not by counting group members.
code
text · 6 linesDACL on DC=corp,DC=local (domain naming context head)
...
ALLOW CORP\svc-dirsync <- plain service account, in no admin group
DS-Replication-Get-Changes (control access right)
DS-Replication-Get-Changes-All (control access right -> secret attrs)
...go deeper
Know that DCSync needs specific replication permissions rather than a general 'admin' status, and that more than the named admins can hold them.
Be able to name the two extended rights, explain that the '-All' variant is what releases password hashes, and that they live in the domain object's ACL.
Show you would measure the real attack surface by auditing the domain DACL for these rights, catching sync, backup, and connector accounts that no admin group lists.
Own the argument that any principal holding these delegable rights is effectively domain-secrets privileged and must be governed as such, whatever their title.
## Control-access rights, not group membership Active Directory permissions are more granular than 'admin or not'. A category called **extended rights** (control-access rights) grants specific privileged operations, and each entry lives in an **access-control list** (ACL) on a directory object. DCSync depends on two extended rights held over the **domain naming context** — the head of the domain, e.g. `DC=corp,DC=local`: - `DS-Replication-Get-Changes` — replicate changes to most attributes. - `DS-Replication-Get-Changes-All` — replicate **secret** attributes, including password hashes (`unicodePwd`, Kerberos keys). (A third, *Replicating Directory Changes In Filtered Set*, matters in some configurations.) The `-All` right is the load-bearing one: without it a replication request returns ordinary attributes; with it, the request returns the hashes. That distinction is a frequent interview probe. ## Why the rights are delegable These rights are held **by default** by Domain Admins, Enterprise Admins, and the Administrators group — which is where the 'only Domain Admins' belief comes from. But nothing confines them to those groups. Because they are just entries in the domain object's ACL, an administrator can **delegate** them to any account. And they routinely do: - a **directory-synchronisation service account** granted replication so it can push on-premises password hashes to another identity system; - a **backup or monitoring** account delegated replication years ago for a since-forgotten reason; - a **connector or migration** account left in place after a project ended. None of these appears in a privileged group. Each can perform DCSync. ## The correcting fact So the answer to 'we have three Domain Admins, therefore three accounts can do this' is that **group membership is the wrong measurement**. Removing an account from Domain Admins does not strip a directly delegated ACL entry. The only reliable way to know who can DCSync is to read the **DACL on the domain object** and enumerate every principal granted the two replication extended rights — directly or through a nested group. That is what surfaces the sync, backup, and connector accounts a roster of named admins will never show. ## Why this is a middle-level question A junior knows DCSync steals hashes. The middle-level step is understanding the *mechanics of the permission*: which two rights, why the `-All` variant is the secret-bearing one, that they are an ACL entry rather than a group, and therefore that the true attack surface is discovered by auditing the ACL. It is the difference between naming the attack and knowing what actually enables it.
- Why does the '-Get-Changes-All' right matter specifically?The plain `Get-Changes` right replicates most attributes but not confidential ones; the `-All` variant (and the filtered-set right) is what releases secret attributes such as `unicodePwd` and Kerberos keys. Without it a replication request returns metadata, not hashes, so it is the right that turns replication into credential theft.
- How would you enumerate who can actually DCSync, if group membership is not enough?Read the discretionary ACL on the domain object and list every principal granted the two replication extended rights, directly or through a nested group. That surfaces synchronisation, backup, and connector accounts that no privileged-group roster shows, which is where the real, undercounted attack surface lives.
saying these in an interview costs you the question
- Says only members of Domain Admins can perform DCSync.
- Believes removing an account from Domain Admins strips a directly delegated replication ACE.
- Treats the two replication rights as equivalent, missing that '-All' exposes secrets.
- Audits privilege by counting group members instead of reading the domain ACL.