ASD ISM 2130 Disabling or hardening AD CS web enrolment interfaces
What it says
Web-based enrolment interfaces for Microsoft AD CS servers are disabled unless required, and where enabled, are configured to require HTTPS and Extended Protection for Authentication.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishTurn off the AD CS web enrolment pages unless you genuinely need them; if you keep them, force HTTPS and enable Extended Protection for Authentication so credentials cannot be relayed.
Microsoft Active Directory Certificate Services (AD CS) can expose web pages that let users and computers request certificates through a browser or an HTTP endpoint (the Certification Authority Web Enrolment and Certificate Enrolment Web Service roles). This control says those web-based enrolment interfaces should be switched off unless there is a real business need for them. Where they must stay on, they need two hardening settings: connections must use HTTPS only, and the web application must enforce Extended Protection for Authentication (EPA). Why it matters: the web enrolment endpoints authenticate users with Windows authentication (NTLM or Kerberos). If they accept plain HTTP or do not enforce EPA, an attacker who can coerce a machine into authenticating to them can relay that authentication to the enrolment page and request a certificate in the victim's name, including for a domain controller. That certificate can then be used to log on as the victim. This relay technique (often called ESC8) is one of the most common ways attackers escalate from a foothold to full domain compromise. Disabling the interface removes the target entirely; HTTPS plus EPA binds the authentication to the encrypted channel so a relayed credential is rejected.
Free. Save your status, tasks and notes.
Why it matters
If web enrolment stays enabled without HTTPS and Extended Protection for Authentication, an attacker on the internal network can relay coerced NTLM authentication from a user, server or domain controller to the enrolment page and obtain a valid certificate for that identity. That certificate gives them persistent, password-independent access as the victim, which for a domain controller account means full control of the Active Directory domain and every system that trusts it.
How to implement
The PKI or Active Directory team should inventory every AD CS server and use Server Manager or PowerShell (Get-WindowsFeature ADCS-Web-Enrolment, ADCS-Enrol-Web-Svc) to identify where the web-based enrolment interfaces are installed.
The PKI owner should confirm with application and desktop teams whether any process actually depends on the web enrolment pages; where nothing does, uninstall the Certification Authority Web Enrolment and Certificate Enrolment Web Service role services from the CA or web server rather than leaving them installed but idle.
For any interface that must remain, the Windows platform team should configure IIS on the CertSrv site and enrolment web applications to require SSL and remove or redirect the HTTP binding so that only HTTPS connections are accepted.
The Windows platform team should open IIS Manager, select the CertSrv site or enrolment application, edit Windows Authentication advanced settings and set Extended Protection to Required (or set extendedProtection tokenChecking to Require via appcmd or PowerShell) so that relayed authentication is rejected.
The PKI team should record the approved configuration in the CA build standard and add a scheduled script or configuration-management check that reports any AD CS server where the web roles are present or where SSL or Extended Protection settings differ from the standard.
Keep it running
Keep a current list of which AD CS servers have the Certification Authority Web Enrolment or Certificate Enrolment Web Service roles installed and a documented reason for each one that is enabled. Most enrolment in a Windows domain happens through auto-enrolment and RPC/DCOM rather than the web pages, so the justification for keeping a web interface is often weaker than assumed and should be revisited when the CA is rebuilt or upgraded.
For interfaces that stay enabled, the settings live in IIS: the site or application must require SSL (HTTP binding removed or redirected), and Windows Authentication must have Extended Protection set to Required, not Accept or Off. Role installs, IIS repairs and some updates can reset these values, so re-check them after change windows and include them in configuration drift monitoring. Ensure the HTTPS certificate on the web server is valid and renewed before expiry so that HTTPS enforcement does not become a reason to fall back to HTTP.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the inventory of AD CS servers showing which ones have the Certification Authority Web Enrolment or Certificate Enrolment Web Service roles installed.
Look at
Compare the inventory against actual role output from each CA (for example Get-WindowsFeature) and check that each enabled interface has a documented business justification.
Good evidence
Web enrolment roles are absent from most or all CAs, and every remaining instance has a recorded reason and an owner.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the IIS configuration of the CertSrv site and any enrolment web applications on servers where the interface is enabled.
Look at
Check the site bindings and SSL Settings to confirm that Require SSL is enabled and that no plain HTTP binding is left serving the enrolment pages.
Good evidence
Only an HTTPS binding is present (or HTTP redirects to HTTPS) and Require SSL is ticked on the enrolment site and applications.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the Windows Authentication settings for the same IIS site and applications.
Look at
Look at the Extended Protection value in the advanced settings or the applicationHost.config extendedProtection element.
Good evidence
Extended Protection is set to Required (tokenChecking Require), not Accept or Off, on every enabled enrolment interface.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the CA build standard or hardening baseline used when deploying or rebuilding AD CS servers.
Look at
Check whether it states that web enrolment is disabled by default and specifies HTTPS and Extended Protection for any exception.
Good evidence
The baseline explicitly covers all three elements of the control and is referenced in recent build or change records.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence that the configuration is re-verified over time, such as configuration-management reports or periodic review records.
Look at
Look for checks that would detect the web roles being reinstalled or the SSL and Extended Protection settings drifting after updates.
Good evidence
Recent reports show the settings were checked after the last change window and any drift was corrected and recorded.
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-2130 requires organisations to disable AD CS web enrolment interfaces unless required, and if enabled, to harden them by enforcing HTTPS and Extended Protection for Authentication. Annex A 8.9 broadly requires secure configuration management across hardware, software, services and networks, including establishing, documenting, implementing, monitoring, and reviewing configurations. ISM-2130 is a specific secure-configuration requirement for a Microsoft PKI component, while Annex A 8.9 is a broader governance and lifecycle control that includes managing and assuring that hardening state.
This control partially meets A.8.20.
ISM-2130 addresses reducing network-exposed attack surfaces on AD CS by disabling web enrolment and, where necessary, enforcing secure transport (HTTPS) and protections against credential relay (Extended Protection for Authentication). Annex A 8.20 requires networks and network devices to be secured, managed, and controlled to protect information in systems and applications. ISM-2130 is a concrete, application-facing network service hardening action within the broader network security expectations of Annex A 8.20.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.