ASD ISM 1944 Remove EDITF_ATTRIBUTESUBJECTALTNAME2 flag from AD CS certification authorities
What it says
The EDITF_ATTRIBUTESUBJECTALTNAME2 flag is removed from Microsoft AD CS certification authority configurations.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery Microsoft AD CS certification authority runs without the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, so requesters cannot inject their own Subject Alternative Names into issued certificates.
Microsoft Active Directory Certificate Services (AD CS) is the part of Windows that issues certificates used to prove who a user or computer is. Each certification authority (CA) has a set of configuration flags that change how it handles certificate requests. One of those flags, EDITF_ATTRIBUTESUBJECTALTNAME2, lets anyone submitting a request add their own Subject Alternative Name (SAN) values, which the CA then writes into the certificate. That is dangerous because a SAN can name a completely different identity from the one making the request. With the flag turned on, an ordinary user who is allowed to request any certificate from the CA can ask for one that also names a domain administrator, and the CA will sign it. The resulting certificate can then be used to log on as that administrator. Attackers actively look for this misconfiguration because it turns a routine certificate request into a domain-wide takeover. This control requires that the flag is removed from every AD CS certification authority in the organisation, so the CA never accepts requester-supplied SANs through this mechanism.
Free. Save your status, tasks and notes.
Why it matters
If the EDITF_ATTRIBUTESUBJECTALTNAME2 flag remains enabled on any AD CS certification authority, a low-privileged user or a compromised account that can enrol for certificates can obtain a certificate bearing the identity of a privileged account. That certificate is trusted for authentication, so the attacker can escalate to domain administrator, move laterally without needing passwords, and persist for as long as the certificate remains valid. Because the CA behaved as configured, the activity looks like legitimate certificate issuance and may go unnoticed for a long time.
How to implement
The PKI administrator inventories every AD CS certification authority in the environment (root, intermediate and issuing CAs) and records the current EditFlags value for each, using certutil -getreg policy\EditFlags on each CA.
The PKI administrator removes the flag on each CA that has it set by running certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2, after taking a backup of the CA configuration and registry.
The PKI administrator restarts the Active Directory Certificate Services service on each changed CA so the new EditFlags value takes effect, then re-runs certutil -getreg policy\EditFlags to confirm the flag is no longer listed.
The PKI or platform engineering team adds the flag check to the CA build standard and to any automation or configuration-management script used to deploy or rebuild CAs, so new CAs never start with the flag enabled.
The security operations team schedules a recurring configuration check (for example a script or monitoring rule) that queries EditFlags on every CA and raises an alert if EDITF_ATTRIBUTESUBJECTALTNAME2 ever reappears.
Keep it running
Treat the flag setting as part of the baseline configuration for every AD CS CA, including subordinate and issuing CAs, not just the root. Check it whenever a CA is built, restored from backup, migrated to a new server, or upgraded, because these events are where an old or default setting can reappear. Include the check in routine configuration reviews of the public key infrastructure, and make sure that any change to CA edit flags goes through change management with a clear record of who changed what and when. If a business process previously depended on requester-supplied SANs, address that need through properly controlled certificate templates rather than reintroducing the flag.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request a current list of all AD CS certification authorities in the organisation, including root, intermediate and issuing CAs.
Look at
Compare the list against Active Directory (for example the Enrollment Services container) to confirm no CA has been left out of scope.
Good evidence
The list is complete and each CA is named with its host and role, so every CA can be checked for the flag.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the output of certutil -getreg policy\EditFlags captured from each CA within the last review period.
Look at
Check the listed flags on every CA for EDITF_ATTRIBUTESUBJECTALTNAME2, and confirm the capture date and CA name appear in the output.
Good evidence
No CA's EditFlags output includes EDITF_ATTRIBUTESUBJECTALTNAME2 and the captures are recent and cover all CAs.
- Check 3 of 5What an auditor asks for
Ask for
Request the CA build standard or hardening baseline used when deploying or rebuilding certification authorities.
Look at
Look for an explicit step or setting that ensures the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is absent, and see whether it applies to all CA roles.
Good evidence
The standard clearly requires the flag to be removed or never set, and it is applied to every new or rebuilt CA.
- Check 4 of 5What an auditor asks for
Ask for
Ask for change records relating to CA EditFlags modifications, including any removal of the flag.
Look at
Verify the change was approved, who performed it, when the service was restarted, and that post-change verification was recorded.
Good evidence
Changes are traceable to named administrators with approval and evidence that the flag was verified as removed afterwards.
- Check 5 of 5What an auditor asks for
Ask for
Ask how the organisation would know if the flag were re-enabled on a CA in future.
Look at
Review any monitoring rule, scheduled script or periodic review procedure that checks EditFlags, and look at recent results or alerts.
Good evidence
A recurring check runs against every CA, its results are retained, and there is a defined response if the flag is detected.
Mappings
Closest match in ISO/IEC 27001: A.8.9, Configuration management for secure IT systems, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.9.
ISM-1944 requires a specific secure configuration on Microsoft AD CS certification authorities by removing the EDITF_ATTRIBUTESUBJECTALTNAME2 flag to prevent requester-supplied SAN injection. Annex A 8.9 requires organisations to establish, document, implement, monitor and review secure configurations across IT systems, which would include AD CS CA configuration baselines and hardening. ISM-1944 is a single, product-specific hardening requirement, whereas Annex A 8.9 is a broad configuration management capability covering many platforms and settings.
This control partially meets A.8.32.
ISM-1944 requires implementing a specific configuration change to AD CS (removing EDITF_ATTRIBUTESUBJECTALTNAME2) to reduce certificate issuance abuse. Annex A 8.32 requires that changes to information systems are controlled through formal change management procedures, which would govern how this CA flag change is requested, tested, approved and rolled out. ISM-1944 defines the required end-state for one security setting, while Annex A 8.32 governs the process for making and controlling such changes across all systems.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.