ASD ISM 1958 Block DCSync-permitted accounts from logging on to unprivileged environments
What it says
User accounts with DCSync permissions cannot be used to log on to unprivileged operating environments.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAccounts that hold DCSync permissions must be technically prevented from signing in to workstations and servers that are not part of the privileged environment.
DCSync is a permission set in Active Directory that lets an account ask a domain controller to replicate directory data, including the password hashes of every user in the domain. An account holding those permissions is effectively as powerful as a domain controller itself. This control says those accounts must not be able to log on to unprivileged operating environments, such as ordinary user workstations, general-purpose servers, or any system that is not part of the hardened privileged environment. It is not enough to tell administrators not to use the account there; the logon must actually be blocked so it cannot happen. It matters because unprivileged systems are exactly where attackers first land, through phishing, malicious documents or drive-by downloads. If a DCSync-permitted account signs in to a compromised workstation, its credentials and tickets sit in that machine's memory. An attacker who harvests them can replicate the entire directory, obtain every password hash, forge authentication tokens and take over the whole domain. Keeping these accounts out of unprivileged environments removes that opportunity.
Free. Save your status, tasks and notes.
Why it matters
If a DCSync-permitted account can log on to an unprivileged workstation or server, a single compromise of that low-trust system can expose the account's credentials. With DCSync rights the attacker can pull every password hash from the domain, including those of domain administrators and service accounts, leading to complete and often persistent compromise of Active Directory and everything that trusts it. Recovery typically requires a full domain rebuild or credential reset across the organisation.
How to implement
Identity administrators enumerate every account with DCSync permissions by querying the domain naming context ACL for the 'Replicating Directory Changes', 'Replicating Directory Changes All' and 'Replicating Directory Changes In Filtered Set' rights, and record the accounts in a managed security group.
Systems administrators create a Group Policy Object linked to all unprivileged workstation and server organisational units that assigns the DCSync-permitted group to 'Deny log on locally', 'Deny log on through Remote Desktop Services', 'Deny log on as a batch job', 'Deny log on as a service' and 'Deny access to this computer from the network'.
Identity administrators configure Active Directory authentication policies and an authentication policy silo for DCSync-permitted accounts so that Kerberos tickets for those accounts are only issued to privileged environment hosts such as domain controllers and privileged access workstations.
The change management team adds a mandatory step to the privileged access request process so that any account being granted DCSync permissions is placed in the restricted logon group and the GPO is verified before the replication rights are applied.
Security operations engineers configure the SIEM to alert on any logon attempt, successful or failed, by a DCSync-permitted account on a host outside the privileged environment, and the on-call analyst investigates each alert as a potential credential misuse.
Keep it running
Day to day, this control depends on knowing which accounts hold DCSync permissions and keeping the logon restrictions on those accounts current.
- Maintain a list of accounts with DCSync permissions (the replication rights on the domain naming context). Re-check it whenever directory permissions change, because these rights can be granted directly to an account rather than through an obvious group.
- Apply logon restrictions through mechanisms that are enforced on the unprivileged systems themselves, such as "Deny log on locally", "Deny log on through Remote Desktop Services", "Deny log on as a batch job" and "Deny log on as a service" rights, or authentication policies and silos, so an administrator cannot simply choose to sign in anyway.
- When a new account is granted DCSync permissions, add it to the restricted group before the permission is granted, not afterwards.
- Watch for failed logon attempts by these accounts on unprivileged systems. Repeated attempts may indicate a misconfigured process, an administrator working around the control, or an attacker testing stolen credentials.
- Periodically test the restriction by attempting a logon with a DCSync-permitted account on a standard workstation and confirming it is refused.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current list of accounts holding DCSync permissions and how it was produced.
Look at
Check that the list came from a query of the actual directory replication permissions rather than from memory or an old spreadsheet, and that it includes service accounts and directly granted rights, not just group members.
Good evidence
The list is generated from the directory ACL, is dated recently, and every account on it appears in the group used for the logon restrictions.
- Check 2 of 5What an auditor asks for
Ask for
Request the Group Policy Objects or authentication policies that restrict where DCSync-permitted accounts can log on.
Look at
Confirm the deny logon rights or authentication silo cover local, remote desktop, network, batch and service logons and are linked to the organisational units containing unprivileged workstations and servers.
Good evidence
The restriction is enforced technically on every unprivileged system, applies to all DCSync-permitted accounts, and is not dependent on administrators voluntarily following a procedure.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the result of a test logon with a DCSync-permitted account on a standard user workstation.
Look at
Watch or review evidence of the attempt being made through interactive, remote desktop and network logon paths and observe whether the system refuses it.
Good evidence
Every logon path is refused with a policy-based denial, and the test was performed recently enough to reflect the current configuration.
- Check 4 of 5What an auditor asks for
Ask for
Request logon event records for DCSync-permitted accounts over a recent period.
Look at
Look for any successful logons on hosts that are not domain controllers or privileged access workstations, and for failed attempts that show someone trying to use the account on unprivileged systems.
Good evidence
Successful logons appear only on privileged environment hosts, and any failed attempts on unprivileged systems were investigated and explained.
- Check 5 of 5What an auditor asks for
Ask for
Ask how the restriction is maintained when a new account is granted DCSync permissions or an existing one is changed.
Look at
Review the privileged access request process and a sample of recent grants to see whether the logon restriction was applied before or at the same time as the replication permission.
Good evidence
The process makes the logon restriction a prerequisite for granting DCSync permissions, and recent grants show no gap during which the account could log on to unprivileged systems.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1958 requires that accounts with DCSync permissions are technically prevented from logging on to unprivileged operating environments. Annex A 5.15 requires organisations to establish and implement rules for logical access based on business and security requirements, which would include defining where highly privileged identities may authenticate. ISM-1958 is a specific, Active Directory-centric enforcement of an access control policy rule that Annex A 5.15 expects at a higher level.
This control partially meets A.5.18.
ISM-1958 requires a specific access restriction: accounts granted DCSync permissions must be blocked from logging on to unprivileged environments. Annex A 5.18 requires provisioning, reviewing, modifying and removing access rights to information assets in accordance with access control rules, which includes managing high-risk directory replication permissions like DCSync. ISM-1958 is a concrete technical enforcement for a particular privilege, whereas Annex A 5.18 covers the broader access-rights lifecycle.
This control partially meets A.8.2.
Annex A 8.2 requires privileged access rights to be restricted and managed, including controlling where and how highly privileged rights can be used. ISM-1958 relates by imposing a specific constraint on accounts with DCSync permissions, preventing them from logging on to unprivileged operating environments to reduce credential theft and misuse. ISM-1958 is a targeted, AD-specific segregation control for one privileged permission set, while Annex A 8.2 is broader across all privileged rights and platforms.
ASD Essential Eight: 5 mappings
This control partially meets E8-RA-ML1.5.
E8-RA-ML1.5 requires privileged users to use separate privileged and unprivileged operating environments to reduce exposure of high-value credentials. ISM-1958 supports this by explicitly preventing accounts with DCSync permissions from logging on to unprivileged operating environments, enforcing strong separation for a particularly sensitive privilege set. ISM-1958 is narrower and targeted to DCSync-capable accounts, whereas E8-RA-ML1.5 applies to privileged users generally.
- E8-RA-ML1.6Unprivileged user accounts restricted from logging on to privileged environmentsPartially overlaps
This control partially overlaps E8-RA-ML1.6.
E8-RA-ML1.6 requires preventing unprivileged accounts from logging on to privileged operating environments. ISM-1958 requires that accounts with DCSync permissions cannot logon to unprivileged operating environments, which is a specialised privileged-account separation measure. Both reduce cross-context logon to limit credential theft pathways, but ISM-1958 is narrower and focused on a specific high-risk privilege and the privileged-to-unprivileged direction.
- E8-RA-ML1.7Prevent privileged user accounts from logging on to unprivileged environmentsPartially overlaps
This control partially overlaps E8-RA-ML1.7.
ISM-1958 requires that accounts with DCSync permissions cannot be used to log on to unprivileged operating environments. E8-RA-ML1.7 requires privileged accounts (excluding local administrator accounts) cannot log on to unprivileged operating environments, which covers a broader set of privileged identities than only DCSync-permitted accounts. They align on the same technical outcome (logon prevention to unprivileged environments), but ISM-1958 is specifically triggered by DCSync permission rather than general privilege status.
This control partially overlaps E8-RA-ML3.1.
E8-RA-ML3.1 requires privileged access to be limited to only what is necessary for duties across systems, applications and data repositories. ISM-1958 constrains highly privileged DCSync-capable accounts by preventing them from logging on to unprivileged operating environments, reducing opportunities for misuse of that privilege. ISM-1958 is more about privileged account use and environment separation for a specific permission set, while E8-RA-ML3.1 is broader entitlement scoping across all privileged access.
This control supports E8-RA-ML1.2.
ISM-1958 requires blocking DCSync-permitted accounts from logging on to unprivileged environments to reduce credential exposure pathways. E8-RA-ML1.2 requires dedicated privileged accounts for administrative tasks, which supports implementing ISM-1958 by separating high-privilege identities from day-to-day user logons and making logon restrictions easier to enforce. E8-RA-ML1.2 is about account separation, while ISM-1958 is about technical logon denial based on DCSync privilege.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.