Hi, I am Dagmar, working for the Microsoft Compromise Recovery Security Practice team. As NDES (Network Device Enrollment Server) – if misconfigured or not secured and hardened properly – can be a door opener for the compromise of an Active Directory, I decided to collect and write down security best practices.
A brief History of SCEP and NDES
The Network Device Enrollment Service (NDES) is one of the role services of the Active Directory Certificate Services (AD CS) role in Windows server. It implements the Simple Certificate Enrollment Protocol (SCEP). SCEP was originally designed to semi-automatically enroll certificates to Cisco network devices in a closed network where all endpoints are trusted, like routers or VPN concentrators. In absence of success, it has been languishing for many years and it has even been abandoned by its creator Cisco until Mobile Device Management (MDM) systems appeared on the scene and SCEP was revived to enroll certificates to mobile devices.
SCEP dates to the year 2000 but was re-published as only in September 2020. As it was originally designed by Verisign and Cisco, you will still find the most detailed documentation on their webpage: Simple Certificate Enrollment Protocol Overview - Cisco.
SCEP does not include any mechanisms of verifying the certificate requestor’s identity, instead it relies on a Registration Authority (RA) to handle this sensitive task. The warnings from CERT in the article SCEP does not strongly authenticate certificate requests should be considered when implementing the NDES service. It is not surprising that a protocol developed more than 20 years ago cannot keep up with today's understanding of security and you can call it a “crutch”, but there is no doubt that SCEP is heavily used in MDMs and we have to find a secure way to deal with it.
Why do we need to implement Security Measures for NDES?
To put it in very clear words: Getting access to the NDES Enrollment Agent certificate’s private key allows a malicious person to request a certificate valid for logon to Active Directory with ANY subject. E.g., someone could log on as an organization’s CEO or Domain Administrator using the mechanisms of PKINIT (aka smart card-based) authentication defined in RFC 4556 (which funnily even does not require a smart card.).
A little bit more detailed: The most common misunderstanding in the PKI-world is that certificates are secure just because they are certificates. It is not that easy, unfortunately. For a certificate to be secure the following rules must apply at a minimum:
- the corresponding key pair must be created and stored in hardware (e.g., in an HSM - Hardware Security Module),
- the certificate requestor’s identity and the request must be verified thoroughly and
- the issuing CA (and the PKI as a whole) must be operated in a secure way.
NDES gets involved in verifying the certificate request, as it is acting as a Registration Authority (RA) and an endpoint for SCEP-based communication. A RA, generally, is responsible for validating the requestor’s identity and pre-checking the incoming certificate request. If both has been verified successfully, the RA puts another digital signature on the certificate request and forwards it to the CA. The CA verifies the RA's signature and general policy compliance like e.g., minimum key length. When it comes to the certificate's subject, the CA must rely on the RA's verification capabilities.
Having some basic knowledge about the NDES/SCEP enrollment process is a key factor to understanding our security recommendations as well as potential points of attacks. Please note that the following is a shortened, generalized, and simplified description of the enrollment process in an ADCS, NDES & MDM world:
- Typically, an Active Directory user account (aka "Device Admin") is created which is granted Enroll permission to the end-entity certificate template configured for NDES (by default IPSec (Offline request)).
- The MDM uses the Device Admin's credentials to access http(s)://ndesservername.domain.com/certsrv/mscep_admin and retrieve a One-Time-Password for submitting a request to NDES.
- A key pair and a certificate request are created and forwarded to NDES (either by the device requesting the certificate or by the MDM, depending on the MDM product).
- NDES verifies the incoming certificate request according to its capabilities.
- In case the request is ok from NDES's perspective, it puts a counter signature on the certificate request using its Enrollment Agent certificate, thereby confirming that it has verified the request and forwards the re-signed request to the CA.
- All the CA can do now is to verify whether the incoming request is compliant to the template settings and the NDES' counter signature is valid, but it cannot verify the most essential part – the certificate subject. Verification of the certificate request must have happened previously (MDM, NDES Policy Module) or it will not happen at all.
You may ask yourself: Why is this enrollment process so complex? Why are “Device Admin” and a One-Time-Password involved? Keep in mind what this protocol was originally designed to semi-automatically enroll certificates to Cisco network devices like routers or VPN concentrators. This type of devices does not have user accounts in Active Directory, but they have “Device Admins” (the guys who administrate these devices), and they can transfer One-Time-Passwords to the network device to authenticate against NDES.
In case your MDM is Intune, you should also read this article explaining enrollment options for end-entity certificates in Intune: Intune - Enrollment Options for End-Entity Certificates - Microsoft Tech Community
The most complete technical documentation on NDES can be found at Active Directory Certificate Services (AD CS): Network Device Enrollment Service (NDES) - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com).
Decisions and Steps to take before installing NDES
The crucial point for securely operating NDES is - as with most security solutions - you are not done when enrolling certificates works as expected. That's only when the fun starts going. Instead, you are done when this enrollment process is secure and - if required - highly available. Further on you find things to consider before even thinking about installing NDES.
NDES is a Tier 0 System
Microsoft’s AD Tier model has enhanced to the “Enterprise Access Model” (See Securing privileged access Enterprise access model | Microsoft Docs for details). What remains the same is the fact that a PKI-related system which is fully trustworthy for Active Directory (meaning that the CA certificate has been published to NTAuth) and allows to enroll certificates usable for PKINIT-based smart card authentication with ANY subject, must be assigned to Tier 0 and secured and treated accordingly. This is not only true for computers hosting Certification Authorities, but also for computers acting as Registration Authorities (like NDES) or computers which have enroll permissions for user certificates allowing for custom subjects (like Microsoft Intune Certificate Connector”). In case your are not familiar with the concept of NTAuth, please find more details in the When not needed, un-publish the CA certificate from the NTAuth store in Active Directory section later in this article.
PAW (Privileged Access Workstation)
As any other Tier 0 system, a Certification Authority or NDES computer must be administered using a PAW. See https://aka.ms/cyberpaw for more details.
System Hardening
A system hardening policy should include at least the following tasks:
- Reduce the members of the local Administrators group to include only PKI Admins.
- Only members of the PKI Admins group are granted any type of logon user right (interactive, remote interactive, log on as a batch job, log on as a service).
- Apply Microsoft Security Baselines provided at Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center.
HSM
Using a Hardware Security Module (HSM) is strongly recommended to generate, store, and manage access to NDES keys. An HSM is a third party hardware device that provides security controls for cryptographic keys. The use of these devices ensures that the NDES keys are never resident in memory on the operating system, offer additional operational controls, and limit exposure to the key material itself.
Note: NDES does not support CAPI Next Generation (CNG) based Key Service Providers (KSP) for its keys. A legacy CSP (Cryptographic Service Provider) must be installed instead.
Virtualization
Your NDES is virtualized and running on a general-purpose Virtualization Environment? Not the best idea… Keep in mind that the Virtualization Host's Administrators in most cases have access to the VM itself, the disk and the computer's memory (where you can find an unencrypted version of the NDES private keys if HSM is not in use).
Backup
If using software-based NDES certificates (no HSM in place) Snapshots/Checkpoints and other types of backup typically contain the NDES' private keys. Consequently, backups must be encrypted, and access should be extremely limited.
Use a reverse Proxy
When allowing access to NDES from the Internet (e.g., for enrolling certificates to mobile devices managed by Intune), ensure that NDES is properly protected using a reverse proxy (like Azure AD Application Proxy or Web Application Proxy (WAP)). See Configure infrastructure to support SCEP certificate profiles with Microsoft Intune - Azure | Microsoft Docs
Preparing the Certification Authority
Using a separate CA for enrolling certificates via NDES is highly recommended, this allows additional hardening of the CA.
PKI Constraints
The goal of stating constraints in a CA certificate is to restrict the scope of a CA in terms of certificates which can be issued by the CA. RFC 5280 defines multiple ways to express constraints: basic constraints, name constraints, policy constraints, and EKU (Enhanced Key Usage). E.g., constraints can limit a CA to issue only end-entity certificates with an EKU of “Client Authentication” and with a subject limited to a defined name space. Irrespective of permissions or templates assigned to the CA, constraints will ensure that certificates can be issued only within these limits. However, PKI constraints are a complex topic and covered in more detail in the following article: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786428(v=ws.11)#ca-certificate-constraints
When not needed, un-publish the CA certificate from the NTAuth store in Active Directory
The NTAuth entry is used to store certificates for CAs that are trustworthy to issue certificates usable for authentication against Active Directory (like smartcard logon or authentication against Network Policy Server or IIS) and perform client private key archival in CA database. All certificates from this container are propagated to each member of the Forest as a part of Autoenrollment processing to client’s Intermediate Certification Authorities container.
The NTAuth store is an Active Directory directory service object that is located in the Configuration container of the forest. Certificates that are published to the NTAuth store are written to the cACertificate multiple-valued attribute. From there, the certificates are replicated to the Enterprise store of all members of the Forest. You can verify the locally cached contents using the following command: certutil -verifystore -enterprise
When installing an AD-integrated Certification Authority, the CA certificate is published to NTAuth by default. Consequently, the CA enjoys the highest level of confidence in Active Directory and makes the corresponding CA an attractive target for attackers. A CA certificate which cannot be considered “Tier 0 secure” should be removed from NTAuth. Whether you can un-publish the CA certificate from NTAuth store without breaking existing applications depends on the applications using and verifying the certificate. Non-Microsoft systems typically do not care about the NTAuth store.
Some scenarios referring to the NTAuth store are listed below. Please note that this list is not complete!
- PKINIT smart card authentication
- NPS (Network Policy Server)
- ADFS (Active Directory Federation Service)
- Windows Hello for Business Certificate Trust
- Enrollment Agent, using the “Enroll on behalf” feature
To remove a certificate from NTAuth follow the instructions provided in step 7 of the following article: How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)
Do not install NDES on the CA Computer
It is recommended to reduce the attack surface of the computer hosting the CA by not enabling additional services. Therefore, the recommended setting is to install NDES on a different computer than the one hosting the CA service. Furthermore, the computer hosting NDES should not run any additional services.
Windows Firewall
On the CA computer, configure the Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) firewall rule to allow only the NDES (and OCSP) IP address to access the CA for enrollment.
Certificate Revocation
Configure your MDM to automatically revoke certificates in case a device is wiped or reset. To do so, the MDM’s account needs the “Issue and Manage certificates” permission on the CA. To follow the “principle of least privilege” even more carefully, consider configuring a Restricted Certificate Manager. See AD CS Security Guidance - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com) for more details. In case your MDM does not provide this capability, ensure that a proper certificate revocation process is set up.
Certification Authority and Certificate Templates
The NDES installation process does not have any mechanism to customize the protection of the private key materials. The install code is also hard-coded to two specific templates – CEP Encryption and Exchange Enrollment Agent (Offline request). Both templates are V1 templates and therefore cannot be modified. However, as they may not meet your requirements (e.g. in terms of key length or private key protection (HSM)), you can enroll new certificates based on customized templates and clean out the certificates installed during installation.
The certificate templates assigned by default during configuration of NDES are:
CEP Encryption
A certificate based on this template is issued to the NDES computer during configuration of the service. It is used to apply SCEP-specific encryption to the communication with the requesting client.
This template is used only during initial installation of NDES and when renewing the certificate before it expires. Un-assign the template from the CA during normal operation times.
The Setup Account needs to have Enroll permissions on this template during configuration of NDES.
Exchange Enrollment Agent (Offline request)
A certificate based on this certificate template is issued during configuration of the service. It is used by the NDES to digitally re-sign the enrollment request it receives from the device or the MDM. The re-signed enrollment request is then forwarded to the issuing CA.
This template is used only during initial installation of NDES and when renewing the certificate before it expires. Un-assign the template from the CA during normal operation times.
The Setup Account needs to have Enroll permissions on this template during configuration of NDES.
IPSec (Offline Request) aka "Device Template" aka "SCEP Certificate Template"
This certificate template is used for enrolling device- or user-certificates and is assigned to the CA automatically during NDES configuration. In most cases you will decide to replace it with a certificate template which better meets your needs.
Ensure that your end-entity certificates only contain the EKUs/Application policies they really need. To put it in other words: do you want that your user's smartphones can present themselves as a trusted web servers on the network? Client Authentication is sufficient in most cases.
The following accounts need Enroll permission on the template:
- Device Administrator
- NDES Service Account
Enforce proper Verification of the NDES Enrollment Agent Signature on the Certificate Request
This can be configured in the properties of the Device Template > Issuance Requirements tab > enable the This number of authorized signatures checkbox. Select Application Policy under Policy type required in signature and Certificate Request Agent under Application policy like configured in the screenshot below:
Installing and configuring NDES
Understanding Accounts involved in NDES Installation, Configuration and Operation
Applying the famous “principle of least privilege” requires understanding the accounts involved in installing, configuring, and operating NDES:
Setup Account
The account running the configuration part of NDES installation needs to be member of the Local Administrators and Enterprise Administrators group. After NDES has been configured successfully, Enterprise Administrator group membership is not required anymore.
In addition to that, the Setup Account needs the Manage CA permission on the CA as well Enroll permissions on the Exchange Enrollment Agent (Offline request) and CEP Encryption templates only for the time of installation and configuration.
Please note that the CA service will be restarted automatically during the NDES configuration process.
Device Administrators
In “normal” NDES operations, this account is an Active Directory account owned by the device’s (e.g. a router) administrator. When using NDES together with a MDM solution, this is the account which is used by the MDM to request an OTP for submitting a certificate request to the NDES.
The Device Administrator needs Request certificates permission on the CA, Enroll permission on the Device template and Access this computer from the network (logon type 3) permission to the NDES computer. In no case the Device Administrator accounts needs to be member of any Administrators group or requires interactive logon permissions to the computer hosting NDES.
NDES Account (Application Pool Identity)
During configuration of NDES, two virtual applications (mscep_admin and mscep) are created. The corresponding IIS application pool (SCEP application pool) runs in the context of the NDES account. This account can be either a
- Network Service or
- a Group Managed Service Account (gMSA) or
- a Domain user account.
For obvious reasons, a group Managed Service Account is always the preferred option. For whichever option you decide, there are different recommendations for different types of accounts:
- gMSA or Domain user accounts: enforce AES encryption
- Domain user accounts: configure logon restrictions and a looooong password (for Domain user accounts)
- gMSA or Domain user accounts don’t reuse the account on other computers/for other purposes (for gMSA or Domain user accounts)
- Domain user account: Enable the Account is sensitive and cannot be delegated checkbox
- When using a gMSA or custom certificate templates, don’t forget to manually configure permissions on the NDES’ certificates private keys.
Permissions required for the NDES service account:
- Must be member of the local IS_IUSRS group on the server hosting NDES.
- Must have Request Certificate permissions on the CA. Consider restricting Request Certificate permissions as much as possible.
- Must have Enroll permission on the Device certificate template.
Note: If using a custom A record as a hostname, or load balancing with a Virtual IP, an SPN needs to be registered against the NDES service account.
Apply Mitigations against NTLM Relay Attacks
To prevent NTLM Relay Attacks on networks with NTLM enabled, domain administrators must ensure that services that permit NTLM authentication make use of protections such as Extended Protection for Authentication (EPA) or signing features such as SMB signing. PetitPotam takes advantage of servers where Active Directory Certificate Services (AD CS) is not configured with protections for NTLM Relay Attacks. See Mitigations against NTLM Relay Attacks on AD CS for more details.
Avoid insecure NDES Configuration
Configuration of NDES is defined in the NDES computer registry at HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP.
Be extremely cautious with setting the EnforcePassword=0 and UseSinglePassword=1 registry keys. By setting the EnforcePassword registry key to 0, you simply remove the requirement of authentication for retrieving a NDES OTP, thereby allowing everyone with network access to the NDES to request a certificate with a subject of his choice.
Also, never ever set certutil -setreg Policy\EditFlags +EDITF_ATTRIBUTEENDDATE. This is a global setting and will configure your CA to stop enforcing certificate validity periods set in all templates assigned.
Enforce TLS (1.2)
Communication between NDES and MDM/the device requesting the certificate must be encrypted via TLS. This includes:
- Enforcing TLS by disabling the HTTP listener on IIS
- Enforcing TLS 1.2
See Enforcing TLS 1.2 via registry settings
Posted at https://sl.advdat.com/3BAezkr
