NDES (Network Device Enrollment Service)

NDES (Network Device Enrollment Service) deployment stills very simple to perform in simple architecture.

NDES is clearly a certificate broker, based on Microsoft technology. Since Microsoft Windows Server 2008 R2 operating versions, it is a part of a security feature.

It is also a function of Microsoft PKI, (ADCS) Active Directory Certificate Services based on the SCEP (Simple Certificate Enrollment Protocol) designed to enroll devices without other Active Directory domain credential to use certificates from Enterprise CAs.

Your NDES node or farm, portion of your Enterprise PKI, should be usually located between the ADCS node and components such as Intune or JAMF, through a Proxy equipment of course (see Proxy-App Gateway).

With this definition that I have just written, there can be several contradictions if we refer to some Microsoft recommendations.

Microsoft recommends that NDES (Network Device Enrollment Service) servers must be placed in T1 environment. But my experience leads to believe that my NDES nodes should be classified as a part of T0 components.

Keep in mind that prerequisites to perform NDES deployment are:

1. The NDES machine should be joined to the Active Directory domain,
2. NDES node should be a dedicates machine,
3. You must have at least one Enterprise CA in your global environment,
4. Your NDES service account should be part temporarily of Enterprise Admin during the NDES deployment. As a reminder, this group is a privileged group located at the root domain level and it has full Active Directory permissions to every domain in the entire Active Directory forest. When configuring your NDES, you must specify your preferred issuing Enterprise CA to set information for the RA (Registration Authority),
5. The NDES account should never be used interactively,
6. Referring to the Enterprise CA, separated role must be deactivated. This can be checked via the registry keys by executing the following command line: certutil.exe -getreg CA\RoleSeparationEnabled. As a reminder, the certificate manager setting for certificates service will change if role separation id enabled.
7. Required flows must be opened because of your NDES component should communicate with the Active Directory, PKI machine and Proxy
8. The same service account:
   • • Must be a part of the local Administrators grope referring to your NDES node,
     • Should be added to the local IIS_IUSRS group of NDES node,
     • Must be allowed to log on your NDES node as a service,
     • Have a SPN (Service Principal Name) attribute,
     • Must be allowed issuing certificate templates on which are based the RA
     • Must be granted to restart remotely the certificate service hosted on your Enterprise CAs which you target during the NDES configuration stage, especially during the step completing the NDES configuration (this last step seems not publicly documented by Microsoft). So, if your NDES is classified as a part of your T1 environment, this situation looks like a privilege escalation. Are we talking about design flaw to gain elevated access to resources that should normally be unavailable to them?

From my perspective, I would classify the NDES node as a part of T0 to simplify the implementation, the maintenance, monitoring and alerting.

Active Directory Certificate Services is part of T0 and the OCSP also. So, why do not classify the NDES (Network Device Enrollment Service) as part of T0?

If you prefer placing your NDES as part of your T1, as Microsoft seems to recommend, you must document the exception procedure to allow the NDES service account obtaining the required elevated privilege if it is needed.

Whatever is your implementation strategy, to increase the security level and integrity of your NDES enrollment process, additional steps should be performed to secure the NDES private keys. These keys are used for signing certificate requests sent to your Enterprise CA and used to encrypt the communication between NDES and your Enterprise CA. It’s clear, a compromise of these keys will have significant impact to not just NDES (Network Device Enrollment Service), but your CA Enterprise as well. If your Enterprise CA is vulnerable in this way, then your Active Directory is also vulnerable in the same way.

NDES in real life, Thierry Adrian