What are NDES security best practices?

The Network Device Enrollment Service (NDES) allows software on network devices, such as routers, firewalls, switches, etc., to obtain digital certificates without running any domain credentials. NDES is also one of the role services on Active Directory Certificate Services (AD CS). It implements the Simple Certificate Enrollment Protocol (SCEP), which defines the communication between the Registration Authority (RA) and network devices for certificate enrollment.

Functions of NDES

NDES performs the following functions:

1. Generates and provides one-time enrollment passwords to administrators
2. Submits enrollment requests to the Certificate Authority (CA)
3. Retrieves enrolled certificates from the CA and forward them to the network device

Best Practices

Enable SSL for the NDES administrator site

SSL protection ensures that the enrollment challenge password is protected against inspection attacks when the network device connects to the MSCEP_Admin Web site.

Create extended validity period device certificates

The default IPsec (Offline Request) certificate template has only a one-year validity period. If you define custom signing, encryption, or general-purpose certificate templates, consider creating a version 2 certificate template with a two-year validity period. A longer validity period reduces the management overhead for requesting device certificates.

Disable the NDES service when not in use

Stopping the NDES service ensures that unauthorized certificates will not be issued. Stopping the service also ensures that all data, such as all passwords that were not used by network devices, is cleared from the service cache.

Use the Security Configuration wizard to lock down the server

The Security Configuration Wizard will recommend locking down IIS and other services installed on the NDES server.

Implement Role Separation

Various accounts involved in installing, configuring, and operating NDES:

• Setup Account
• Device administrators
• NDES account
  • Network Service
  • Group Managed Service Account (gMSA) or
  • Domain user account

Recommendations based on the choice of NDES account

• AES encryption is required for gMSA or Domain user accounts.
• Configure login restrictions and a long password for domain user accounts
• Do not use gMSA or Domain user accounts on any other computers or for any other purposes
•  Enable the “Account is sensitive and cannot be delegated” checkbox for Domain user accounts.
• Remember to manually configure permissions on the NDES’ certificates’ private keys when using a gMSA or custom certificate template.

Ensure system hardening

Reduce the number of local admins groups to include only PKI Admins. Only members of the PKI Admins group are granted any logon user rights (interactive, remote interactive, log on as a batch job, log on as a service).

Secure the keys

The following practices should be implemented to secure the keys:

• It is strongly advised to use a Hardware Security Module (HSM) to generate, store, and manage access to NDES keys. HSMs ensure that the NDES keys never reside in the operating system’s memory, provide additional operational controls, and limit exposure to the key material.
• If the NDES is virtualized, it is recommended that HSM should be used to store NDES private keys as the keys can be found in an unencrypted version by Virtualization’s host admins who have access to VM, disk, and memory.
• Backups must be encrypted, and access should be extremely limited in case an HSM is not being used to store private keys, as Snapshots/Checkpoints and other types of backup typically contain the NDES’ private keys

Infrastructure

The following practices should be followed with respect to infrastructure for NDES:

• When allowing Internet access to NDES (for example, to enroll certificates in Intune-managed mobile devices), ensure that NDES is properly protected using a reverse proxy (such as Azure AD Application Proxy or Web Application Proxy (WAP)).
• NDES should be installed on a different computer than the one hosting the CA service. Furthermore, no other services should be running on the computer that hosts NDES.
• If NDES is deployed on a CA computer, configure the Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) firewall rule so that only the NDES (and OCSP) IP address can access the CA for enrollment.

Certificate Authority & Certificate templates

The certificate templates assigned by default during the configuration of NDES are:

• CEP encryption: A certificate based on this template is issued to the NDES computer during the configuration of the service. It is used to apply SCEP-specific encryption to the communication with the requesting client. 

• Exchange Enrollment Agent (Offline request): A certificate based on this template is issued to the NDES computer during the configuration of the service. The NDES uses it to digitally re-sign the enrollment request received from the device or MDM. After that, the re-signed enrollment request is forwarded to the issuing CA.

Note: Both of the above templates are used only during the initial installation of NDES and when renewing the certificate before it expires—Un-assign these templates from the CA during normal operating times. The Setup Account needs to have Enroll permissions on this template during the 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 automatically assigned to the CA during NDES configuration. Most of the time, you’ll decide to replace it with a certificate template that better suits your needs. The Device administrator and NDES Service Account need to have Enroll permissions on this template.

Implement Data-in-transit encryption

TLS must be used to encrypt communication between NDES and MDM/the device requesting the certificate. This includes the following:

• Enforcing TLS by disabling IIS’s HTTP listener
• TLS 1.2 Compliance

Conclusion

We should implement all the above-mentioned best practices to secure NDES. It is extremely important to protect the private keys as any malicious person who gets access to it will be able to request a valid certificate for logging into the Active directory with any subject.

Reference: NDES Security Best Practices – Microsoft Community Hub