ASD ISM 1927 Limit identity server access to privileged users requiring it
What it says
Access to Microsoft AD DS domain controllers, Microsoft AD CS servers, Microsoft AD FS servers and Microsoft Entra Connect servers is limited to privileged users that require access.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnly privileged users with a genuine need can access domain controllers, AD CS, AD FS and Entra Connect servers. Everyone else, including other admins, is kept off these identity systems.
Four kinds of Microsoft server sit at the heart of an organisation's identity system: Active Directory Domain Services (AD DS) domain controllers, which hold every account and password hash; Active Directory Certificate Services (AD CS) servers, which issue the certificates that machines and people use to prove who they are; Active Directory Federation Services (AD FS) servers, which sign the tokens that let users into cloud and partner applications; and Microsoft Entra Connect servers, which synchronise on-premises identities to Entra ID and hold credentials for both environments. This control says that access to these servers must be limited to privileged users who actually require it. Two tests apply. The person must be a privileged user (not a standard user, service desk operator or general IT staff member), and they must have a specific need to work on that server. Holding a broad administrative role is not enough on its own. It matters because anyone who can log on to, or administer, one of these servers can effectively become anyone in the organisation. A compromised account with access to a domain controller can extract every credential in the domain. Access to AD CS can be used to mint certificates that impersonate any user. Access to AD FS or Entra Connect can forge or replay cloud sign-ins. Keeping the set of people who can reach these servers as small as possible shrinks the number of accounts an attacker can use as a stepping stone to complete takeover.
Free. Save your status, tasks and notes.
Why it matters
If access to domain controllers, AD CS, AD FS or Entra Connect servers is open to more people than genuinely need it, every one of those accounts becomes a route to full compromise of the identity system. Phishing or credential theft against any of them can lead to extraction of all domain credentials, forged certificates or federation tokens, and persistent, hard-to-detect control of both on-premises and cloud environments. Recovery typically means rebuilding trust in the entire directory and certificate infrastructure, which is costly and disruptive.
How to implement
Identity team: inventory every AD DS domain controller, AD CS server, AD FS server and Entra Connect server, and record for each one which groups, roles and local rights allow logon or administration, so you know exactly what "access" currently means on each system.
Identity team lead: define a short approved-access list per server class that names the privileged users who require access and the reason, and have the system owner sign it off so that need, not seniority or convenience, is the basis for inclusion.
Platform administrators: align group memberships and local security policy on each server with the approved list, removing standard users, general IT staff, nested groups and any accounts without a documented need, so that only the approved privileged users can reach these servers.
Service desk and HR process owners: add an explicit step to joiner, mover and leaver workflows that checks whether the person holds access to any of these four server types and removes it when their role or need changes.
Identity team: run a scheduled access review (for example quarterly) comparing actual memberships and rights on each server against the approved list, and record the removals or re-approvals that result so the list stays accurate over time.
Keep it running
Day to day, this control lives in the membership of the groups and roles that grant logon, remote management and administrative rights on the four server types. The identity or platform team owns a short, named list of privileged users approved for each server class (domain controllers, AD CS, AD FS, Entra Connect) and keeps it aligned with the actual group memberships and local rights on those servers.
Joiners, movers and leavers processes need a specific step for these servers: access is granted only on a documented need, removed promptly when the need ends, and re-confirmed at regular access reviews. Watch for drift such as nested groups, legacy "Domain Admins" style memberships that grant blanket access, service or vendor accounts with interactive rights, and Entra Connect or AD FS servers that were built by a project team and never brought under the same access rules as domain controllers.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current inventory of AD DS domain controllers, AD CS servers, AD FS servers and Entra Connect servers, together with the approved list of privileged users allowed to access each class.
Look at
Check that all four server types are covered and that each approved user is a privileged user with a stated reason for needing access.
Good evidence
Every server class has a short, named list with a business or technical justification per user, signed off by the system owner.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export of the groups, roles and local rights that grant logon or administrative access on a sample of these servers.
Look at
Compare the exported memberships, including nested groups, against the approved list and look for standard users, service desk staff or broad groups that grant access to people without a documented need.
Good evidence
Actual memberships match the approved list with no unexplained accounts, and any differences have already been identified and are being removed.
- Check 3 of 5What an auditor asks for
Ask for
Ask how Entra Connect and AD FS servers are treated compared with domain controllers.
Look at
Confirm these servers are under the same access rules rather than being managed by a separate team with wider access.
Good evidence
Entra Connect and AD FS servers are in scope of the same approved list and review process as domain controllers and AD CS.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the records of the most recent access reviews for these servers.
Look at
Look for evidence that memberships were compared against need, that removals were actioned and that the review happens on a set cadence.
Good evidence
Reviews are documented, recent, show reviewers' decisions and include removals where access was no longer required.
- Check 5 of 5What an auditor asks for
Ask for
Ask for examples of recent leavers or role changes involving people who had access to these servers.
Look at
Trace whether their access to domain controllers, AD CS, AD FS or Entra Connect servers was removed promptly after the change.
Good evidence
Access was removed close to the date of the role change, with a ticket or record showing who removed it and when.
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-1927 requires limiting access to specific identity systems (domain controllers, AD CS/AD FS servers, and Entra Connect) to only privileged users who require it. ISO/IEC 27001:2022 Annex A 5.15 requires an organisation-wide set of access control policies and procedures governing physical and logical access based on business and security requirements. ISM-1927 is a specific, technical access-control restriction that would typically be implemented under the broader policy framework required by Annex A 5.15.
This control partially meets A.5.18.
Annex A 5.18 requires organisations to manage access rights across their lifecycle in line with access control rules. ISM-1927 relates by mandating that access to critical identity infrastructure (AD DS/CS/FS and Entra Connect servers) is limited to privileged users who require it, which is an access provisioning and restriction decision. Annex A 5.18 is broader because it also requires periodic review, modification and removal processes for all assets and roles, not only these servers.
This control partially meets A.8.2.
ISM-1927 requires that access to AD DS domain controllers and related identity servers is limited to privileged users who genuinely require it. ISO/IEC 27001:2022 Annex A 8.2 requires that the allocation and use of privileged access rights is restricted and managed across the organisation. ISM-1927 is a concrete, technology-specific application of privileged access management focused on identity infrastructure, whereas Annex A 8.2 is broader and does not single out identity servers.
This control partially meets A.8.3.
ISM-1927 requires restricting access to AD DS domain controllers, AD CS CA servers, AD FS servers and Entra Connect servers to privileged users who require access. ISO/IEC 27001:2022 Annex A 8.3 requires access to information and associated assets to be restricted in accordance with the access control policy, which covers restricting access to these identity assets. ISM-1927 is a specific asset-focused application of the broader access restriction requirement in Annex A 8.3.
ASD Essential Eight: 6 mappings
This control partially meets E8-RA-ML3.1.
ISM-1927 requires limiting access to specific identity servers (AD DS domain controllers, AD CS/AD FS, and Entra Connect) to privileged users who genuinely need it. E8-RA-ML3.1 requires least-privilege for privileged access across systems, applications and data repositories more generally. ISM-1927 is a focused application of that broader least-privilege principle to the highest-value identity infrastructure components.
This control partially overlaps E8-RA-ML1.4.
ISM-1927 requires that only privileged users with a genuine need can access key identity servers (AD DS/AD CS/AD FS/Entra Connect). E8-RA-ML1.4 focuses on limiting what privileged accounts are explicitly authorised to access in online services to only what is required. They overlap on least-privilege restrictions for privileged accounts, but E8-RA-ML1.4 is oriented to online service access entitlements while ISM-1927 is specifically about restricting interactive/administrative access to on-prem/hybrid identity infrastructure servers.
- 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 that unprivileged accounts cannot logon to privileged operating environments. ISM-1927 limits access to key identity infrastructure servers to privileged users who require access, which strengthens protection of privileged environments by reducing who can reach them. ISM-1927 is broader in that it governs authorisation to access particular server classes, while E8-RA-ML1.6 is specifically a logon restriction based on account privilege level.
This control supports E8-RA-ML1.1.
ISM-1927 requires that access to core identity infrastructure (AD DS domain controllers, AD CS, AD FS and Entra Connect servers) is restricted to privileged users with a genuine need. E8-RA-ML1.1 supports this by requiring privileged access requests to be validated at the time they are first raised, which helps justify and document who should be granted access to those identity servers. E8-RA-ML1.1 does not itself enforce the technical restriction or define the specific identity-server scope that ISM-1927 mandates.
This control supports E8-RA-ML1.2.
ISM-1927 requires restricting access to domain controllers and related identity servers to only those privileged users who require it. E8-RA-ML1.2 supports this by requiring privileged users to use dedicated privileged accounts for administrative duties, which makes it easier to enforce and audit who can access identity servers. E8-RA-ML1.2 does not itself restrict which systems can be accessed, whereas ISM-1927 sets a specific restriction for identity server access.
- E8-RA-ML3.3Just-in-time administration is used for administering systems and applications.Depends on
This control depends on E8-RA-ML3.3.
ISM-1927 requires limiting access to key Microsoft identity servers (AD DS/CS/FS and Entra Connect) to privileged users who need it. E8-RA-ML3.3 supports this outcome by using just-in-time administration to minimise standing privileged access, reducing the window in which users can access or administer those servers. E8-RA-ML3.3 is not server-specific, but it materially strengthens the access limitation required by ISM-1927.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.