ASD ISM 1934 Six-monthly review and removal of DCSync user permissions
What it says
User accounts with DCSync permissions are reviewed at least every six months, and those without an ongoing requirement for the permissions have them removed.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery six months, check which user accounts can perform DCSync replication and strip the permission from any account that no longer has an ongoing business need for it.
DCSync is a set of directory replication permissions (Replicating Directory Changes, Replicating Directory Changes All and Replicating Directory Changes In Filtered Set) that let an account ask a domain controller to hand over password data for any account in the domain, just as another domain controller would. Anyone who holds these permissions can, in effect, extract every credential in the directory, including the krbtgt account that underpins Kerberos. This control asks for two things. First, at least every six months, someone reviews the list of user accounts that hold DCSync permissions. Second, any account that does not have an ongoing requirement for those permissions has them removed. It matters because DCSync permissions tend to accumulate quietly. They are granted for a migration, a directory synchronisation tool, a vendor engagement or a troubleshooting task, and then nobody takes them away. Each leftover grant is a ready-made path to a full domain compromise: a malicious actor who compromises that one account can pull password hashes for every user and administrator without ever touching a domain controller's disk. A regular review keeps the list short, current and justified.
Free. Save your status, tasks and notes.
Why it matters
If DCSync permissions are not reviewed and pruned, accounts that no longer need them keep the ability to replicate password data from domain controllers. A malicious actor who phishes, buys or otherwise compromises any one of those accounts can extract password hashes for every account in the domain, forge Kerberos tickets and gain persistent, domain-wide administrative access. Because the extraction looks like ordinary replication traffic, it is hard to spot, and recovery usually means resetting every credential in the domain, including the krbtgt account twice, which is highly disruptive.
How to implement
The directory services lead sets a recurring review task with a due date at most six months after the last completed review, assigns a named owner, and records the task in the team's work tracker so it cannot silently lapse.
The reviewer enumerates every user account holding DCSync permissions by exporting the access control list on the domain naming context and listing all principals granted Replicating Directory Changes, Replicating Directory Changes All and Replicating Directory Changes In Filtered Set, including permissions inherited through group membership.
For each account on the list, the reviewer contacts the account owner and records whether there is an ongoing requirement for the permission, what it is used for, and who approved it, marking any account without a confirmed current need for removal.
A directory administrator removes the DCSync permissions from every account marked for removal, either by removing the direct access control entries or by taking the account out of the group that grants them, then re-runs the enumeration to confirm the removal took effect.
The review owner files the dated enumeration output, the justification for each retained account, the list of removals and the approver's sign-off in a single review record, and sets the due date for the next review no more than six months out.
Keep it running
Treat the review as a recurring calendar task owned by the identity or directory services team, with a due date no more than six months after the previous review. The review needs a current, tool-generated list of accounts holding the replication permissions on the domain naming context, not a list compiled from memory, and each account on it needs a named owner and a stated reason for keeping the permission.
Expect the list to include service accounts for directory synchronisation products and possibly a small number of administrator accounts. Anything else, and anything whose justification has lapsed, is removed during the review rather than deferred. Removals are made through normal change control and recorded, so the next review can start from a known state. Keep each review's sign-off, output list and removal records together so the six-monthly cadence can be demonstrated.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the records of the last two DCSync permission reviews, including their completion dates.
Look at
Check the interval between the two reviews and whether the most recent one is within the last six months.
Good evidence
Reviews are dated no more than six months apart and the latest one is current, showing the cadence is actually kept rather than planned.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the tool-generated list of accounts holding DCSync permissions that was used as the input to the most recent review.
Look at
Confirm the list was produced from the directory itself (for example, an export of the domain naming context access control list) and that it covers all three replication permissions and group-inherited grants.
Good evidence
The review started from a complete, machine-generated enumeration rather than a manually maintained spreadsheet that could miss accounts.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the justification recorded against each account that kept its DCSync permissions after the last review.
Look at
Look for a named owner, a description of the ongoing requirement and evidence that the owner confirmed it during this review cycle.
Good evidence
Every retained account has a specific, current reason to hold the permission, and there are no accounts with a blank or stale justification.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the list of accounts that had DCSync permissions removed as a result of the last review, with the associated change records.
Look at
Check that removals were carried out promptly after the review and that a follow-up enumeration confirms the permissions are gone.
Good evidence
Accounts identified as no longer needing the permission were actually removed, and the post-removal check shows a shorter list than the pre-review one.
- Check 5 of 5What an auditor asks for
Ask for
Ask to observe a live enumeration of DCSync permission holders on the production domain.
Look at
Compare the live result with the most recent review's retained-accounts list and note any account present in the directory but absent from the review.
Good evidence
The live list matches the reviewed list exactly, with no unreviewed accounts holding replication permissions.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-1934 requires periodic governance over a specific privileged permission (DCSync) by reviewing authorised accounts and removing access that is no longer required. Annex A 5.15 requires establishing and implementing access control policies and procedures based on business and information security requirements, under which review-and-removal processes for privileged rights would be defined. ISM-1934 is narrower because it prescribes a particular control activity for one permission rather than the broader policy and procedural framework.
This control partially meets A.5.16.
ISM-1934 requires a six-monthly review and removal of unnecessary DCSync permissions on user accounts to reduce excessive replication privileges. Annex A 5.16 requires the organisation to manage the full life cycle of identities, including changes in roles and revocation of entitlements as identities evolve. ISM-1934 is narrower because it focuses on one high-risk entitlement (DCSync) and a fixed review cadence rather than end-to-end identity lifecycle management.
This control partially meets A.5.18.
ISM-1934 requires organisations to review user accounts with DCSync permissions at least every six months and remove those permissions where there is no ongoing business requirement. Annex A 5.18 requires access rights to be provisioned, reviewed, modified and removed in accordance with access control rules, which directly encompasses periodic privileged-permission reviews and removals. ISM-1934 is a specific, technology-focused instance (Active Directory DCSync replication rights) of the broader access-rights lifecycle requirement in Annex A 5.18.
This control partially meets A.8.2.
ISM-1934 requires periodic (at least annual) review of DCSync permissions and removal if there is no ongoing requirement. Annex A 8.2 requires privileged access rights to be restricted and managed, covering governance across allocation, use and ongoing control. ISM-1934 is a specific privileged-access management practice for one particularly sensitive privilege (DCSync), fitting within the broader Annex A 8.2 requirement.
ASD Essential Eight: 2 mappings
This control partially meets E8-RA-ML3.1.
ISM-1934 requires user accounts with DCSync permissions to be reviewed at least annually and removed if not required. E8-RA-ML3.1 requires privileged access to systems, applications and data repositories to be limited to only what is necessary for duties. DCSync is a specific form of privileged access, so ISM-1934 is a targeted implementation of the broader least-privilege requirement in E8-RA-ML3.1.
This control partially overlaps E8-RA-ML2.1.
ISM-1934 requires that DCSync permissions are reviewed at least every six months and removed when no longer needed. E8-RA-ML2.1 requires privileged access to systems, applications and data repositories to be disabled after 12 months unless revalidated, which is also a periodic revalidation/removal mechanism for privileged access. They overlap on the principle of time-bound privileged access with periodic review, but ISM-1934 is more specific (DCSync replication permissions) and more frequent (six months), while E8-RA-ML2.1 is broader across privileged access and uses a 12-month threshold.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.