Securing and Hardening Network Device Enrollment Service for Microsoft Intune and System Center Configuration ManagerMicrosoft Corporation

Published: March 2015

Version: 1.0

Author: Mark B. Cooper, President & Founder – PKI Solutions Inc.

AbstractThis white paper discusses the architectural and configuration practices to secure a deployment of the Network Device Enrollment Service (NDES). It describes the best practices for designing network security, operating system configuration and service modifications to increase the integrity of issued certificates and minimize security risks. The paper also addresses the new Windows Server 2012 R2 NDES policy module feature and its configuration for Microsoft Intune and System Center Configuration Manager deployments.

Copyright InformationThis document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2015 Microsoft Corporation. All rights reserved.

Active Directory, Hyper-V, Internet Explorer, Microsoft, Windows, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

ContentsAbout this guide........................................................................................................4

Target audience......................................................................................................4

Overview of NDES........................................................................................................5The Enrollment Process.............................................................................................6

Network Topology.........................................................................................................7Firewall Recommendations Checklist........................................................................8

NDES Configuration...................................................................................................10Dedicated Server Roles...........................................................................................10Enterprise Subordinate CAs....................................................................................11Device Certificate Cryptography.............................................................................11Role Separation.......................................................................................................12Policy Modules........................................................................................................14

Policy Module Process Flow..................................................................................15Microsoft Intune...................................................................................................16

Internet Information Server Configuration.........................................................17Private Key Protection.............................................................................................18

Securing NDES Keys with an HSM........................................................................19NDES Configuration Recommendations Checklist...................................................22

Server Hardening.......................................................................................................23OS Hardening..........................................................................................................23

Security Configuration Wizard..............................................................................23Remote Administration Consideration..................................................................23

Internet Information Server Hardening....................................................................24IIS Components....................................................................................................24SSL Enrollment Encryption...................................................................................24

Server Hardening Recommendations Checklist.......................................................25

About the Author........................................................................................................26

See also.....................................................................................................................27

3

Securing and Hardening Network Device Enrollment Service for Microsoft Intune and System Center Configuration Manager

About this guideThis document provides guidance for architectural and configuration practices to secure Windows Server 2012 R2 running Network Device Enrollment Service (NDES). It is also applicable to environments using NDES to support the deployment and use of Microsoft Intune and System Center Configuration Manager.

Target audience Administrators or IT operations engineers responsible for planning and managing

certificate issuance with NDES.

Administrators or IT operations engineers responsible for the day-to-day management and troubleshooting of networks, servers, client computers, operating systems, or applications.

IT operations managers accountable for network and server management.

IT architects responsible for computer management and security throughout an organization.

Microsoft Intune architects and administrators responsible for the design and operation of a certificate deployment solution.

4

Overview of NDESThe Network Device Enrollment Service (NDES) is one of the role services of the Active Directory Certificate Services (AD CS) Windows Server role. It implements the Simple Certificate Enrollment Protocol (SCEP). SCEP defines the communication between network devices and a Registration Authority (RA) for certificate enrollment and is defined in detail in http://tools.ietf.org/html/draft-nourse-scep-18.

The need to secure networks has grown substantially over the last few years. The integration of Bring Your Own Device (BYOD) and the proliferation of intelligent devices such as VoIP phones has created challenges for many organizations. While these devices can use x509 version 3 certificates as a means to identify themselves in a secure session, the difficulty for many organizations is how to issue and manage certificates for these devices. This is because many devices do not support certificate enrollment using domain-based credentials. SCEP enables these network devices to enroll for x509 version 3 certificates from a Certification Authority (CA).

SCEP was designed to be used in a closed network where all end-points are trusted. The warnings from CERT in the article Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests should be considered when implementing the NDES service. This is one of the many reasons why it is recommended to use a policy module with NDES to improve security and integrity of issued certificates

Beginning with Windows Server 2012 R2, NDES can be augmented with the use of a policy module. The policy module provides additional control over the challenge and enrollment process of NDES. These controls improve the security and integrity of the PKI and enable organizations to provide flexible enrollment for a diverse set of devices. Policy modules can be used to integrate Mobile Device Management (MDM) solutions such as Microsoft Intune and System Center Configuration Manager into a PKI.

5

The Enrollment ProcessFigure 1 illustrates the various steps for enrolling certificates through the Network Device Enrollment Service. The enrollment and interaction process may differ from this diagram if a NDES policy module has been installed – such as Microsoft Intune’s custom module. For more information, refer to the Policy Module section.

Figure 1

The enrollment process includes the following steps.

1) The device generates an RSA public-private key pair on the device.2) The administrator obtains a password from the Network Device Enrollment

Service.a. The administrator browses to the administration Web page.b. The service verifies that the administrator holds the required

permissions for the configured certificate templates.3) The administrator sets the device with the password and sets it to trust the

enterprise PKI.4) The administrator configures the device to send the enrollment request to the

Network Device Enrollment Service.

6

5) The Network Device Enrollment Service signs the enrollment request with its Enrollment Agent certificate and sends it to the CA.

6) The CA issues the certificate and returns to the service.7) The device retrieves the issued certificate from the service.

Network TopologyA key part of securing NDES properly is to ensure that only trusted entities can enroll for certificates. This presents a challenge when devices that need to enroll are outside of domain authentication structures or need to enroll via the cloud. Deployments using Microsoft Intune are a prime example as both Microsoft Intune and BYOD devices prior to enrollment are cloud devices.

To ensure the NDES service is accessible to these components and to minimize access and associated security risks, NDES must be deployed in a secure architecture. In addition, NDES must have full domain membership and ability to communicate over a number of protocol ports to participate in the Active Directory forest and perform certificate enrollments with a Certificate Authority (CA).

To achieve these security goals, NDES should be deployed on the internal corporate network. In addition, a Web Application Proxy (WAP) server should be used in a DMZ to publish a reverse proxy to the NDES enrollment interface. DMZ firewall controls should be carefully defined to allow only desired traffic to reach the NDES server. All network traffic will be on port 443 using an HTTP SSL connection.

The recommended architecture to protect NDES is shown below in Figure 2.

7

Figure 2

Firewall Recommendations ChecklistThe following recommendations should be followed with respect to network architecture, communications and firewalls when deploying NDES.

Exterior DMZ Firewall - An exterior firewall should be used to manage traffic accessing the WAP server from the Internet. In addition, this firewall should be configured to allow only HTTPS traffic to access the URL for NDES.

Port 443 - https://<NDESServerName>/certsrv/mscep

Port 443 - https://<NDESServerName>/certsrv/mscep_adminNOTE: Access to the /certsrv/mscep_admin URL will vary based on the NDES deployment. For environments using Microsoft Intune, this interface is not used. As a result, the exterior firewall rule does not need to be defined to allow access. Other MDM solutions may choose to use the interface to call operation=NDESGenerateChallenge call. Refer to the documentation for any applicable 3rd party solutions for required URLs.

If the exterior DMZ firewall will be performing protocol inspections or terminating the SSL session, it must be able to support large HTTP GET requests up to 40kb in length.

Proxy Server – A proxy server such as Windows Server 2012 R2 Web Application Proxy (WAP) should be used to provide a secure connection between external devices, Microsoft Intune, and the NDES server. WAP is available as both an on-premises Windows Server 2012 R2 Role and as Azure AD Application Proxy, part of Azure Active Directory. For more information on Azure AD Application Proxy, refer to https://msdn.microsoft.com/en-us/library/azure/dn768219.aspx.

WAP should be configured for pass-through authentication as the NDES server will authenticate all enrolling devices.

The on-premises WAP service is dependent on Active Directory Federation Services (AD FS) and as such, requires an AD FS server to communicate with. For more information on AD FS, refer to https://technet.microsoft.com/en-us/library/dd807092.aspx.

8

The on-premises is an Internet Information Server (IIS) web service and as a result it must be properly configured to support the long HTTP GET requests that will be transmitted through the proxy service. Refer to the Internet Information Server Configuration section for the required changes.

Hotfix 523052 is required for the on-premises WAP service to handle the longer HTTP GET URLs. Refer to http://support.microsoft.com/kb/523052 for more details.

Interior Firewall – An interior firewall should be used to manage traffic between the WAP server and the NDES server. The WAP server requires the ability to communicate with the NDES server and the AD FS server.

Port 443 - https://<NDESServerName>/certsrv/mscep

Port 443 - https://<NDESServerName>/certsrv/mscep_adminNOTE: Access to the /certsrv/mscep_admin URL will vary based on the NDES deployment. For environments using Microsoft Intune, this interface is not used. As a result, the exterior firewall rule does not need to be defined to allow access. Other MDM solutions may choose to use the interface to call operation=NDESGenerateChallenge call. Refer to the documentation for any applicable 3rd party solutions for required URLs.

Port 443 - https://<ADFS Server>NOTE: Access to an ADFS server is only required if using Windows Application Proxy server. This firewall rule is not required when using Azure AD Application Proxy or 3rd party proxy solutions.

If the exterior DMZ firewall will be performing protocol inspections or terminating the SSL session, it must be able to support large HTTP GET requests up to 40kb in length.

9

NDES ConfigurationThe default security posture of SCEP (and subsequently NDES) assumes that its use is in an environment of trusted devices and identities. The original purpose of SCEP was to provide the enrollment of devices that lacked higher level authentication mechanisms. One-time use passwords afforded the means to identify authorized administrators and provide the mechanism to carry that identity into the enrollment process. As a result, there was not a great emphasis on securing and controlling the enrollment process for these administrators. As the use of NDES has expanded, the requirement to secure and protect the integrity of the PKI became an important design consideration.

The default installation of NDES provides a basic level of protection for enrollments. Passwords are one-time use and have a short validity period. However, there are several additional mechanisms available to increase the security posture of NDES.

The NDES role by default can be deployed in a number of different configurations to suit organizational needs. However, to meet security and integrity requirements, several key aspects of the design should be carefully followed.

Dedicated Server RolesSince the Issuing CA computer has access to the CA signing keys, 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.

When using the Microsoft Intune NDES policy module, the NDES server cannot be the same as the issuing CA. Even though that configuration is not blocked by setup, the policy module will not work as expected in those conditions.

Figure 3 illustrates a network diagram of this deployment model.

10

Figure 3

Enterprise Subordinate CAsWhile NDES supports both stand-alone and enterprise CA configurations, an enterprise subordinate CA affords great versatility and allows for improved cryptographic strength of issued certificates as well as improving the security of the NDES keys. An Enterprise CA enables organizations to define custom templates for use by NDES as well as for devices enrolled through NDES. This ability is not available with standalone CAs. Additionally, the use of a standalone CA would require NDES to be installed on the same server as the CA which would be counter to the previous recommendation on dedicated server roles. For environments using Microsoft Intune or System Center Configuration Manager, standalone CAs can’t be used to provide certificate issuance to managed devices.

Device Certificate CryptographyWhen NDES is installed, the service is configured to use a default template for all certificates issued to devices. The templates are defined in the NDES computer registry at HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP using the values:

EncryptionTemplate GeneralPurposeTemplate SignatureTemplate

The default template is listed in the registry as IPSECIntermediateOffline which is the template name for the AD based template named IPSec (Offline request). This template issues certificates with a two-year validity period and RSA key sizes as small as 1024 bits. Based on current cryptographic industry standards, these default values should be carefully evaluated and improved if possible.

11

The ability to improve the cryptographic strength of the certificates issued to the devices by NDES is heavily dependent on the devices themselves. The encryption and hashing algorithms available from device to device vary greatly. Thus it will be important to fully understand the supported cryptographic abilities of your devices prior to creating a custom template.

By duplicating the default template you can modify a few properties of the certificates issued to devices. As mentioned above, these settings need to be carefully reviewed to ensure compatibility with enrolling devices. Once the custom template is created, ensure it is added to the issuing CA for the NDES server, modify the registry values noted above, and restart the SCEP application pool to read the new values.

12

Validity Period – The default validity period is two-years. For many devices outside the corporate boundary, this length of validity is too long. The validity period should be short enough to discourage brute force attacks against it, while at the same time provide adequate usefulness without undue burden to renew the certificate excessively. Shorter validity periods are recommended for high value certificates or weaker keys. Stronger keys can support longer lifetimes. In general, a device should have a certificate that is valid for no more than 1 year.

Minimum Key Size – The default minimum key size for NDES requests is RSA 1024 bits which is no longer considered commercially viable. As a result, key sizes should be at least RSA 2048 bits or stronger.

Role SeparationFor all deployments, it is recommended that you create a separate not-interactive account for the NDES service credentials. Based on existing PKI policies, CA administrators should also use a separate account for the service administrators and an additional account for the device administrator (This account should have the permissions to request a NDES enrollment password). Different accounts for managing enterprise PKI, running the services, setting up the service, and requesting a password increase the security of an Enterprise PKI deployment.

There are four roles related to setting up and running the service.

NDES Installer - The user who logs on the service machine and installs the Network Device Enrollment Service:

Must be part of the local administrators group. Must have Enroll permission on the “Exchange Enrollment Agent (Offline

request)” and “CEP Encryption” templates. Must have permissions to add templates to the selected CA. Must be a member of the Enterprise Admins group

NDES Administrator - The user who manages the Network Device Enrollment Service and its configuration after installation:

Must be part of the local administrators group.

13

Service Account - The credentials that will be used to run the NDES service:

Must be a member of the local IIS_IUSRS group. Must have request permission on the configured CA. Must be a domain user account and have Read and Enroll permissions on the

configured templates. Must have SPN set in Active Directory. To do so, use the Setspn command.

For example: Setspn -s HTTP/NDES1.fabrikam.com fabrikam\NdesSvc1

o Domain: Fabrikam.como NDES computer name: NDES1o NDES service account name: NdesSvc1

Device Administrator - The user who manages the devices and should request a one-time password from the service to enable security enrollment.

The account must have Enroll permissions on all templates configured in the NDES template registry settings - HKLM\Software\Microsoft\Cryptography\MSCEP.

o GeneralPurposeTemplateo EncryptionTemplateo SignatureTemplate

NOTE: The use of a Device Administrator account will vary based on the NDES deployment. For environments using Microsoft Intune, this role is not used by the policy module. Other MDM solutions that use the administrative interface to generate an NDES challenge may require the use of an enrollment account. Refer to the documentation for any applicable 3rd party solutions for account requirements.

14

Policy ModulesIn Windows Server 2012 R2, NDES supports a policy module that provides additional security. Without this policy module, when a user or a device requests a certificate, the SCEP implementation might require a unique or shared password. Then, to obtain a certificate without the policy module, only the password is required. In addition, the certificate subject name value is provided by the user at request time. Using a legitimately obtained password, a rogue user could request a certificate that has the following security problems:

The subject name value is for another user and therefore the security risk is impersonation.

The certificate purpose is changed and therefore the security risk is an elevation of privileges.

When you use a policy module with the Network Device Enrollment Service, the module addresses these security risks by implementing additional authentication and controls. For example, the module can verify that the requested certificate is for a specific user, a specific purpose, whether to deploy a user certificate or computer certificate, and ensure that it meets cryptographic requirements.

Windows Server 2012 R2 AD CS Network Device Enrollment Service does not ship with a policy module. However, Microsoft Intune provides two different policy modules that enable it to interact with an Enterprise Issuing CA and deploy certificates to managed devices. One policy module is available for cloud-only deployments (http://www.microsoft.com/en-us/server-cloud/products/microsoft-intune/Overview.aspx) and the other ships with System Center Configuration Manager for use with Microsoft Intune in hybrid deployments (deployments of Intune with System Center 2012 Configuration Manager).

The most typical scenario for using a policy module is to support the enrollment of user and computer certificates for mobile devices that use a cloud service. This is sometimes referred to as over-the-air enrollment. Figure 4 shows the process flow after a mobile device administrator configures policy for certificate enrollment for a mobile device that is being used by an information worker.

For more information on using policy modules with NDES, refer to http://technet.microsoft.com/en-us/library/dn473016.aspx.

15

Figure 4

Policy Module Process Flow 1. The mobile device management (MDM) software requests a challenge password

from NDES.2. NDES delegates the challenge password request to the policy module.3. The policy module creates a challenge password that requires that the certificate

request includes the following items and then sends this instruction to NDES: Specific user Specific purpose Type of certificate (user or computer)

4. When the MDM software receives the challenge password, this software sends the uniform resource indicator (URI) for contacting NDES and the challenge password to the mobile device.

5. The mobile device contacts NDES to enroll a certificate. 6. NDES delegates the request to the policy module.7. The policy module verifies the challenge password and certificate request. Then,

the policy module returns the result of the verification to NDES.8. If the challenge password and certificate request is not successfully verified by

the policy module, NDES returns an error to the mobile device. If the verification is successful, NDES forwards the request to the CA.

9. When the request is approved by the CA, the certificate is returned to NDES.10. NDES notifies the policy module of the certificate issuance request enrollment

success & state.

16

11. NDES sends the certificate to the mobile device.

17

Microsoft IntuneMicrosoft Intune is a cloud-based solution that provides mobile device and application management across platforms, such as Windows, Windows Phone, Android, and iOS.. It is also available in a hybrid solution that leverages System Center Configuration Manager on premises. Both solutions can use a NDES policy module that enables provisioning and enrollment for device certificates. The implementation of the policy module for Microsoft Intune uses a modified process flow for enrollment. This process leverages Intune to create the challenge password as well as the other details for enrollment and eliminates the requirement to interact with the NDES administrative interface. It also eliminates an extra transmission of the challenge password to reduce exposure of the password.

1. Microsoft Intune creates a challenge password that requires that the certificate request includes the following items and then sends this instruction to NDES:

Specific user Specific purpose Type of certificate (user or computer)

2. Microsoft Intune sends the uniform resource indicator (URI) for contacting NDES and the challenge password to the mobile device.

3. The mobile device contacts NDES to enroll a certificate. 4. NDES delegates the request to the policy module.5. The policy module verifies the challenge password and certificate request. Then,

the policy module returns the result of the verification to NDES.6. If the challenge password and certificate request is not successfully verified by

the policy module, NDES returns an error to the mobile device. If the verification is successful, NDES forwards the request to the CA.

7. When the request is approved by the CA, the certificate is returned to NDES.8. NDES notifies the policy module to indicate success and state, or failure and error,

of the certificate issuance request.9. NDES sends the certificate to the mobile device.

18

Internet Information Server ConfigurationTo accommodate the additional information that will be part of the NDES enrollment requests and interaction with the policy module, two registry settings must be made on the NDES server. These two settings enable IIS to properly set the maximum size for incoming requests. These settings must be configured and then the server needs to be rebooted (restarting IIS is not sufficient), refer to http://support.microsoft.com/KB/136393 for details on how to modify the registry.

Location: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\ParametersValue: MaxFieldLength Type DWORDData: 65534 (decimal)

Location: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\ParametersValue: MaxRequestBytesType DWORDData: 65534 (decimal)

Additionally, you need to add the Request Filtering feature to IIS and configure it to support these new maximum values. Follow these steps:

1. Use Server Manager on the NDES server and select Dashboard and then Add roles and features.

2. Expand Web Server (IIS)/Web Server/Security and then enable Request Filtering. Complete the installation process.

3. Open IIS Manager, navigate to the default website and select Request Filtering.4. In the Actions pane on the right, select Edit Feature Setting and change the

Maximum URL length and Maximum query string to 65534

19

Private Key ProtectionTo increase the security and integrity of the NDES enrollment process, additional steps should be taken to secure the NDES private keys. These keys are used for signing certificate requests sent to the CA and used to encrypt the communication between NDES and the CA. A compromise of these keys will have significant impact to not just NDES, but the PKI as well.

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 of these templates are V1 templates which cannot be modified. As a result, follow the standard NDES installation process and then use the following steps to increase the security of the NDES keys.

The use of a Hardware Security Module (HSM) is strongly recommended to generate, store and manage access to NDES keys. A HSM is a 3rd 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.The use of operator/user identification cards or identification to load and use NDES keys in an HSM is not supported. The NDES service interface and underlying cryptographic engine have no mechanism available to interact with an administrative user logged into the server. As a result, prompts for card inserts and pins cannot be accomplished. The use of module protection or other similar technology should be used instead.

NOTE: While Microsoft has tested and supports the use of a Hardware Security Module to protect NDES keys, the support for the HSM, its CSPs and associated components are the responsibility of the device manufacturer. Microsoft will only provide direct support for software CSPs as provided in the Windows Server product.

20

Securing NDES Keys with an HSM1) Complete the standard NDES installation process by using the Add Roles/Features

component of Server Manager, refer to https://technet.microsoft.com/en-us/library/hh831498.aspx for details.

2) Connect the HSM to the NDES server as directed by the manufacturer.3) Install the Cryptographic Service Provider (CSP) software as provided by the HSM

manufacturer. Note: A legacy CSP must be used. NDES does not support CAPI Next Generation (CNG) based Key Service Providers (KSP) for its keys.

4) On the issuing CA, duplicate the CEP Encryption template to create a new template:

On the Compatibility Tab select Server 2012 R2 for both the CA and Recipient.

On the Cryptography Tab select Requests can use any provider available on the subject’s computer. Alternatively you if the CSP for the HSM that is also installed on the CA, you can choose Requests must use one of the following providers and select the appropriate HSM CSP to use.

On the Cryptography Tab, specify a Minimum key size of 2048 (or higher). On the Subject Name Tab, select Build from this Active Directory

Information and specify a Subject Name of Common name. No alternate subject name is required.

On the Request Handling Tab, Enable Authorize additional service accounts to access the private key. Click Key Permissions and add the service account defined during the NDES installation process.

On the Security Tab, add the computer account that is hosting NDES and grant it Enroll permissions.

5) Add the new template to the CA.6) Repeat the process to duplicate and configure the Enrollment Agent

(Computer) template. NOTE: This template is different from the default template used for NDES installation. This is to accommodate the enrollment of a new certificate using the machine context.

21

22

7) On the server hosting NDES, run CERTLM.MSC to open and view the Personal Certificate store for the computer.

8) Delete the two certificates that were enrolled as part of the NDES installation – based on the CEP Encryption and Exchange Enrollment Agent (Offline request) templates.

9) Right-click the Certificates folder (under Personal), select All Tasks, and then select Request New Certificate.

10)On the Request Certificates page, click Details for one of the new templates, and then click Properties to modify the request properties. NOTE: This step can be skipped if the new templates were configured with a specific HSM CSP in Step 4.

On the Private Key tab, click Cryptographic Service Provider to expand the section. Uncheck the default CSP (Microsoft Strong Cryptographic Provider (Encryption) and select the appropriate CSP for your HSM.

Click OK to return to the Request Certificates page. Repeat the process for the other certificate request.

11)Select both templates and then click Enroll.12)Restart the SCEP Application Pool in IIS to cause the NDES service to empty the

certificates already loaded in memory and to begin using the new certificates.13)Use the Certificate Authority to revoke the default certificates originally issued to

NDES during installation.

23

NDES Configuration Recommendations ChecklistThe following recommendations should be followed when implementing and configuring NDES.

Dedicated Server Roles – The NDES service should be installed on a dedicated server. The Issuing CA should also be on its own dedicated server.

Enterprise Subordinate CAs – An Enterprise CA should be used to issue certificates as requested by the NDES service.

Device Certificate Cryptography – A custom template should be used to improve the validity period and key sizes used for device certificates.

Role Separation – Separate accounts should be used for the three distinct roles in installing, managing, and requesting certificates in NDES.

Policy Modules – A policy module should be used to enhance the security and validity of enrollment requests submitted to NDES.

Private Key Protection – The private keys for the two NDES certificates (Key Exchange and Key Signature) should be protected with a HSM device to protect these keys against unauthorized use. Operator Card Sets or other administrative authorization for use of NDES keys is unsupported – module protection should be used instead.

24

Server HardeningIn addition to designing and implementing a secure architecture and implementing security controls for NDES, the underlying support components need to be properly secured. In the case of NDES the two most prominent areas for review are IIS and the operating system itself. This section reviews these two areas and provides recommendations on how to harden each to provide a secure deployment of NDES.

OS HardeningA key part to securing NDES is protecting the server from unauthorized access prior to reaching the operating system. This has been addressed elsewhere in this paper by allowing only authorized traffic to reach the server. But additional controls should be put into place to secure the server and the operating system as a whole.

Security Configuration WizardOnce the NDES server is properly patched and the required services installed, the Security Configuration Wizard (SCW) should be run on the server. The SCW evaluates the current services and network ports that are in use. In addition it asks several questions about the other computers and infrastructure the server will interact with. Once the process completes, it creates a security policy that will lockdown the operating system to only the required services, and elevate security controls where possible.

Remote Administration ConsiderationSpecial emphasis should be placed on reducing remote administrative access to the server. This includes disabling Remote Desktop services and any other component that could be used to elevate access to the operating system. Other potential sources include in-band and out-of-band remote bios level management boards, remote KVM (keyboard, video and mouse) connections, and network administration tools. When possible, all administration should take place at the physical console for the NDES server.

25

Internet Information Server HardeningNDES is implemented as an ISAPI extension and installs to the %windir%\system32\certsrv\mscep folder as mscep.dll. During installation, the local IIS server is configured with an ISAPI execution path for NDES. The Internet Server API (ISAPI) extension runs in its own application pool named SCEP. This application pool is created during setup and is configured to run with the credentials that were provided during setup.

IIS ComponentsWhen NDES is installed, it has a number of feature dependencies defined for IIS. It is recommended to install only the required components as defined by NDES. If IIS is installed prior to NDES, there may be additional components and features that are unneeded which could pose unknown security risks. As a result, IIS should not be installed independently of NDES.

SSL Enrollment EncryptionThe SCEP specification does not require devices to support Secure Socket Layer (SSL). However, to improve the security and integrity of the enrollment process, all NDES interfaces should be protected with SSL encryption. Using NDES without SSL could allow an un-authenticated user to hijack the password as it is returned to the administrator. The NDES install process creates two virtual applications — one for the administrative interface and one for the device enrollment interface.

http://localhost/certsrv/mscep_admin - Used to retrieve enrollment passwords or interact with NDES policy modules.

http://localhost/certsrv/mscep - Devices use this location for all enrollment communications.

It is recommended to use SSL encryption for all interactions with NDES. Because most devices that enroll for certificates with NDES will not already trust an internal PKI environment, a certificate from a publically trusted commercial provider should be used. Use a standard webserver/SSL certificate with a key usage for Server Authentication. In addition, the subject name and/or subject alternate names should match the URL name that is used to reach the NDES server.

If you will use Microsoft Intune or System Center Configuration Manager, you have the added flexibility to use an enterprise issued web server certificate from your own PKI. This reduces the complexity and cost associated with securing IIS.

26

Server Hardening Recommendations ChecklistThe following recommendations should be followed to secure the underlying components that support NDES.

Minimal IIS Install – IIS should be installed only as a dependency of NDES to ensure that only required features and components are installed and available.

SSL Encryption – The server should be configured with an SSL certificate and it should be used to create an SSL binding in IIS to protect all traffic with NDES.

HTTP Access – The default port 80 binding for HTTP access should be explicitly removed from the website configuration. This will ensure that all incoming connections use SSL on port 443.

Security Configuration Wizard – The operating system should be fully patched and all server roles installed and configured, and then SCW should be used to evaluated and harden the server.

Remote Administration Considerations – The use and availability of remote administration tools, remote desktop and other elevated/privileged access methods should be disabled or removed to reduce the security threat to the NDES server when possible.

27

See also Active Directory and Active Directory Domain Services Port Requirements

Creating Tunnel Mode IPsec Rules

System Center Configuration Manager 2012 R2 and Intune Integration

Network Device Enrollment Service (NDES) in Active Directory Certificate Services (AD CS)

Using a Policy Module with the Network Device Enrollment Service

28