ASD ISM 1839 Secure account properties in Active Directory
What it says
Account properties accessible by unprivileged users are not used to store passwords.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDo not use account fields that everyone can see to store passwords.
This control is about making sure people don't store passwords in places where they can be easily accessed by anyone who shouldn't have them, like general account information in Active Directory. The risk here is that if sensitive data like passwords are stored where just anyone can see them, it becomes much easier for them to be misused, leading to security breaches and potentially serious consequences for the organisation.
Free. Save your status, tasks and notes.
Why it matters
If passwords are stored in AD account attributes readable by unprivileged users, attackers can harvest credentials and escalate access, leading to broader compromise.
How to implement
IT team should identify which fields in Active Directory are visible to all users.
This can be done by reviewing the permissions of account attributes and understanding the default settings to know what information is publicly accessible.
System administrators should update documentation to clearly state which fields should never contain passwords or sensitive data.
They can achieve this by adding notes to existing user management guides and ensuring they are distributed to all relevant staff.
Managers should provide training to all employees involved in managing user accounts to reinforce the importance of not storing passwords in common fields.
Organise a workshop or a short training session where this policy is thoroughly explained.
IT support staff should audit existing accounts to ensure passwords are not stored in easily accessible fields.
They can do this by sampling a portion of accounts and checking the common fields for the presence of password-like data.
The organisation's security officer should enforce regular reviews of account properties.
Establish a quarterly review process where account configurations are checked for compliance with this control.
Keep it running
Audit AD user attributes (e.g., description, comment, notes) and remove any stored passwords or secrets from fields readable by unprivileged users.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of all Active Directory attributes and who can view them.
Look at
What fields are publicly accessible by all users.
Good evidence
Is a clear list showing restricted access to fields not meant for general viewing.
- Check 2 of 5What an auditor asks for
Good evidence
Includes a well-maintained document with clear prohibitions on storing passwords in visible fields.
- Check 3 of 5What an auditor asks for
Ask for
Records of training sessions or workshops provided to employees.
Look at
Attendance records and session content.
Good evidence
Is a document showing regular training with topics covering account property security.
- Check 4 of 5What an auditor asks for
Look at
Checks on account fields for password storage and resulting actions.
Good evidence
Details audits with recommendations and follow-up actions completed.
- Check 5 of 5What an auditor asks for
Ask for
The schedule of regular reviews of account fields.
Look at
Logs or plans that show when and how the reviews are done.
Good evidence
Is a recurring entry in the organisational calendar with an assigned responsible person.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.15.
ISM-1839 requires that Active Directory account properties visible to unprivileged users are not used to store passwords. Annex A 5.15 requires organisations to establish and implement access control policies and procedures governing logical access more broadly, within which prohibiting password storage in visible directory attributes is a specific rule. ISM-1839 is a concrete, directory-specific implementation detail, while Annex A 5.15 is policy/procedure-level and technology-agnostic.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.