ASD ISM 1933 Restrict DCSync permissions on service accounts
What it says
Service accounts configured with an SPN do not have DCSync permissions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure service accounts with SPNs can't simulate domain controller operations.
This control is all about making sure certain service accounts in your organisation's computer network don't have too much power. These accounts often need to do specific tasks but if they can pretend to be a domain controller, it could allow someone to steal or change sensitive data. Keeping these permissions in check prevents major security risks.
Free. Save your status, tasks and notes.
Why it matters
If SPN service accounts have DCSync rights, attackers can replicate AD data, steal credentials and compromise the domain.
How to implement
IT team should review permissions: Go through all service accounts with Service Principal Names (SPNs) and ensure they do not have permissions that allow them to act like a domain controller.
Use a directory management tool to list these accounts and adjust permissions where necessary.
System owner should organise regular reviews: Schedule regular reviews of service account permissions, at least quarterly, to ensure no new permissions have been inappropriately granted.
Document these reviews and keep them on file.
Managers should request training: Arrange for your IT team to receive training on identifying and securing high-risk permissions.
Check for local courses or consult the Australian Cyber Security Centre (ACSC) guidelines.
IT team should set up alerts: Use your network's auditing tools to create alerts for unusual permission changes to service accounts, which might indicate a potential security incident.
Test these alerts monthly to ensure they're working properly.
HR and IT should work together: When an employee leaves, ensure their network permissions, including any for service accounts they may have managed, are promptly reviewed and removed if no longer necessary.
Set this as a standard part of the exit process.
Keep it running
Audit SPN service accounts and confirm they lack DCSync/replication rights (Get-ADPermission), removing any found.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A permissions audit report: Request the latest detailed report showing permissions for service accounts with SPNs.
Look at
Whether any accounts have permissions typically reserved for domain controllers.
Good evidence
Shows none of these accounts have such permissions.
- Check 2 of 5What an auditor asks for
Ask for
A review schedule: Request the document outlining the schedule for regular service account reviews.
Look at
The frequency and recent entries for completed reviews.
Good evidence
Schedule shows reviews happen at least quarterly.
- Check 3 of 5What an auditor asks for
Ask for
Training records: Request proof of staff training related to this control.
Look at
Certificates or training logs of the IT team completing relevant training.
Good evidence
Record includes recent completion dates and training topics.
- Check 4 of 5What an auditor asks for
Ask for
Alert setup details: Request documentation on alerts set up for detecting unusual permission changes.
Look at
The alert criteria and test logs.
Good evidence
Setup includes detailed criteria and regular testing.
- Check 5 of 5What an auditor asks for
Ask for
To see the exit protocol: Request the HR procedure for when employees leave.
Look at
How it covers reviewing these employees' permissions.
Good evidence
Protocol clearly integrates IT in the handover process to review and revoke permissions.
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-1933 requires an explicit logical access restriction: SPN service accounts must not have DCSync (directory replication) permissions. Annex A 5.15 requires establishing and implementing access control policies and procedures, which would include rules governing assignment of highly privileged directory rights and prohibiting risky privilege combinations on service identities. ISM-1933 is a specific technical policy outcome for Active Directory, whereas Annex A 5.15 is a high-level requirement covering policy and procedural controls for access more generally.
This control partially meets A.5.18.
ISM-1933 requires removing/avoiding DCSync permissions for SPN-configured service accounts to prevent directory replication abuse. Annex A 5.18 covers provisioning, reviewing, modifying and removing access rights, which directly includes governance over who is granted AD replication rights and periodic review to ensure service accounts do not retain them. ISM-1933 is a specific control outcome for one dangerous permission set, while Annex A 5.18 addresses the full access-rights lifecycle across the organisation.
This control partially meets A.8.3.
ISM-1933 requires that service accounts configured with an SPN are not granted DCSync permissions (i.e. replication rights that can simulate domain controller behaviour). Annex A 8.3 requires organisations to restrict access to information and associated assets according to an access control policy, which would include restricting high-impact directory replication privileges to only authorised principals. ISM-1933 is a very specific Active Directory access restriction, whereas Annex A 8.3 is a broad access control requirement covering many asset types and access scenarios.
ASD Essential Eight: 1 mapping
This control partially meets E8-RA-ML3.1.
ISM-1933 requires that service accounts with SPNs are not granted DCSync permissions, limiting a high-risk privilege that enables domain replication. E8-RA-ML3.1 requires privileged access to systems, applications and data repositories to be limited to what is necessary for users and services, which encompasses not granting unnecessary AD replication rights to service accounts. ISM-1933 is a concrete, AD-specific least-privilege requirement, while E8-RA-ML3.1 is a broader least-privilege control across many privileged access types.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.