The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the steps that are used in order to successfully configure the Microsoft Network Device Enrollment Service (NDES) and Simple Certificate Enrollment Protocol (SCEP) for Bring Your Own Device (BYOD) on the Cisco Identify Services Engine (ISE).
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
The information related to Microsoft certificate services is provided as a guide specifically for Cisco BYOD. Refer to the Microsoft TechNet as the definitive source of truth for Microsoft certification authority, Network Device Enrollment Service (NDES), and SCEP-related server configurations.
One of the benefits of the Cisco ISE-enabled BYOD implementation is the ability of the end users to perform self-service device registration. This eliminates the administrative burden on IT in order to distribute authentication credentials and enable devices on the network. At the heart of the BYOD solution is the network supplicant provisioning process, which seeks to distribute the requisite certificates to employee-owned devices. In order to satisfy this requirement, a Microsoft Certificate Authority (CA) can be configured in order to automate the certificate enrollment process with the SCEP.
SCEP has been used for years in Virtual Private Network (VPN) environments in order to facilitate certificate enrollment and distribution to remote access clients and routers. The enablement of SCEP functionality on a Windows 2008 R2 server requires the installation of the NDES. During the NDES role installation, the Microsoft Internet Information Services (IIS) web server is also installed. IIS is used in order to terminate HTTP or HTTPS SCEP registration requests and responses between the CA and ISE policy node.
The NDES role can be installed on a current CA, or it can be installed on a member server. In a standalone deployment, the NDES service is installed on an existing CA that includes the Certification Authority service and, optionally, the Certification Authority Web Enrollment service. In a distributed deployment, the NDES service is installed on a member server. The distributed NDES server is then configured in order to communicate with an upstream root or sub-root CA. In this scenario, the registry modifications outlined in this document are made on the NDES server with the custom template, where certificates reside on the upstream CA.
This section provides a brief overview of the CA/NDES deployment scenarios that have been tested in the Cisco lab. Refer to the Microsoft TechNet as the definitive source of truth for Microsoft CA, NDES, and SCEP-related server configurations.
When ISE is used in a Proof of Concept (PoC) scenario, it is common to deploy a self-contained Windows 2008 or 2012 machine that acts as an Active Directory (AD) domain controller, root CA, and NDES server:
When the ISE is integrated into a current Microsoft AD/PKI production environment, it is more common to see services distributed accross multiple, distinct Windows 2008 or 2012 servers. Cisco has tested two scenarios for distributed deployments.
This image illustrates the first tested scenario for distributed deployments:
This image illustrates the second tested scenario for distributed deployments:
Before you configure SCEP support for BYOD, ensure that the Windows 2008 R2 NDES server has these Microsoft hotfixes installed:
Warning: When you configure the Microsoft CA, it is important to understand that the ISE does not support the RSASSA-PSS signature algorithm. Cisco recommends that you configure the CA policy so that it uses sha1WithRSAEncryption or sha256WithRSAEncryption instead.
Here is a list of important BYOD ports and protocols:
Note: For the lastest list of required ports and protocols, refer to the ISE 1.2 Hardware Installation Guide.
Use this section in order to configure NDES and SCEP support for BYOD on the ISE.
By default, the Microsoft SCEP (MSCEP) implementation uses a dynamic challenge password in order to authenticate clients and endpoints throughout the certificate enrollment process. With this configuration requirement in place, you must browse to the MSCEP admin web GUI on the NDES server in order to generate a password on-demand. You must include this password as part of the registration request.
In a BYOD deployment, the requirement of a challenge password defeats the purpose of a user self-service solution. In order to remove this requirement, you must modify this registry key on the NDES server:
In some deployment scenarios, it might be preferred to restrict SCEP communications to a select list of known ISE nodes. This can be accomplished with the IPv4 Address and Domain Restrictions feature in IIS:
It is possible for ISE to generate URLs that are too long for the IIS web server. In order to avoid this problem, the default IIS configuration can be modified to allow for longer URLs. Enter this command from the NDES server CLI:
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/
security/requestFiltering /requestLimits.maxQueryString:"8192" /commit:apphost
Note: The query string size might vary dependent upon the ISE and endpoint configuration. Enter this command from the NDES server CLI with administrative privileges.
Administrators of a Microsoft CA can configure one or more templates that are used in order to apply application policies to a common set of certificates. These policies help to identify for which function the certificate and associated keys are used. The application policy values are contained in the Extended Key Usage (EKU) field of the certificate. The authenticator parses the values in the EKU field in order to ensure that the certificate presented by the client can be used for the intended function. Some of the more common uses include server authentication, client authentication, IPSec VPN, and email. In terms of ISE, the more commonly used EKU values include server and/or client authentication.
When you browse to a secure bank website, for example, the web server that processes the request is configured with a certificate that has an application policy of server authentication. When the server receives an HTTPS request, it sends a server authentication certificate to the connecting web browser for authentication. The important point here is that this is a unidirectional exchange from the server to the client. As it relates to ISE, a common use for a server authentication certificate is admin GUI access. ISE sends the configured certificate to the connected browser and does not expect to receive a certificate back from the client.
When it comes to services such as BYOD that use EAP-TLS, mutual authentication is preferred. In order to enable this bidirectional certificate exchange, the template used in order to generate the ISE identity certificate must possess a minimum application policy of server authentication. The Web Server certificate template satisfies this requirement. The certificate template that generates the endpoint certificates must contain a minimum application policy of client authentication. The User certificate template satisfies this requirement. If you configure ISE for services such as Inline Policy Enforcement Point (iPEP), the template used in order to generate the ISE server identity certificate should contain both client and server authentication attributes if you use ISE Version 1.1.x or earlier. This allows the admin and inline nodes to mutually authenticate each other. The EKU validation for iPEP was removed in ISE Version 1.2, which makes this requirement less relevant.
You can reuse the default Microsoft CA Web Server and User templates, or you can clone and create a new template with the process that is outlined in this document. Based upon these certificate requirements, the CA configuration and resultant ISE and endpoint certificates should be carefully planned in order to minimize any unwanted configuration changes when installed in a production environment.
As noted in the introduction, SCEP is widely used in IPSec VPN environments. As a result, installation of the NDES role automatically configures the server to utilize the IPSec (Offline Request) template for SCEP. Because of this, one of the first steps in the preparation of a Microsoft CA for BYOD is to build a new template with the correct application policy. In a standalone deployment, the Certification Authority and NDES services are collocated on the same server, and the templates and the required registry modifications are contained to the same server. In a distributed NDES deployment, the registry modifications are made on the NDES server; however, the actual templates are defined on the root or sub-root CA server specified in the NDES service installation.
Complete these steps in order to configure the Certificate Template:
Note: The template validity period must be less than or equal to the validity period of the CA root and intermediate certificates.
Note: Alternatively, you can enable the template via the CLI with the certutil -SetCAtemplates +ISE-BYOD command.
Complete these steps in order to configure the Certificate Template Registry keys:
In a BYOD deployment, the endpoint does not communicate directly with the backend NDES server. Instead, the ISE policy node is configured as a SCEP proxy and communicates with the NDES server on behalf of the endpoints. The endpoints communicate directly with the ISE. The IIS instance on the NDES server can be configured in order to support HTTP and/or HTTPS bindings for the SCEP virtual directories.
Complete these steps in order to configure ISE as a SCEP Proxy:
There is currently no verification procedure available for this configuration.
Use this section in order to troubleshoot your configuration.
Here is a list of important notes that you can use in order to troubleshoot your configuration:
Note: Some supplicants do not initialize a client certificate exchange if the wrong EKU is present, such as a client certificate with EKU of server authentication. Therefore, authentication failures might not always be present in the ISE logs.
Here is a list of useful techniques that are used in order to troubleshoot client-side logging issues:
Note: WinHTTP is used for the connection between the Microsoft Windows endpoint and ISE. Reference the Microsoft Windows Error Messages article for a list of error codes.
Complete these steps in order to view the ISE log:
For more information, refer to the AD CS: Troubleshooting Network Device Enrollment Service Windows Server article.