Configuring Certificate Templates with Active Directory Certificate Services

Certificates are essential for network services because they enable secure communication, authenticate identities, and protect data integrity across the network. In an increasingly interconnected and security-conscious environment, certificates provide the foundation for encrypting data transmissions, ensuring that sensitive information is protected from unauthorized access. They also play a critical role in verifying the identity of users, devices, and services, preventing impersonation, and ensuring that only trusted entities can access network resources. Additionally, certificates support the implementation of secure protocols, such as HTTPS and SSL/TLS, which are fundamental for maintaining the confidentiality and trustworthiness of network communications. By integrating certificates into network services, organizations can enhance their security posture, reduce the risk of cyber threats, and ensure the reliability and integrity of their network infrastructure.

Likewise, certificates are crucial for Cisco Identity Services Engine (ISE) because they provide a foundation for secure communication and trusted identity verification within the network. In a security-driven network environment, certificates ensure that all devices, users, and network elements can authenticate themselves reliably and securely. Certificates also support various security protocols, such as EAP-TLS, ensuring that only authenticated devices and users can connect to the network, thus enhancing the organization’s overall security posture. By leveraging certificates, Cisco ISE can maintain a high level of trust and integrity, which is vital for effective identity management and network access control.

In this blog post, like the other Windows Server blog posts, we are just laying the foundation on what we will later configure on other tools and products.

Although ISE could act as its own Certificate Authority since version 1.3, this feature is typically used for BYOD scenarios rather than corporate devices in most production environments. In future blog posts, I’ll cover many of these steps using the ISE CA, but for now, I want to focus on what’s most commonly implemented for corporate-owned machines.

So why are certificates so important? The first thing that comes to mind is to use them for client authentication with dot1x. User certificates, computer certificates, or both can authenticate a device to the network. You can also use your Windows PKI or ISE’s built-in Certificate Authority to issue certificates to mobile devices and other BYOD devices not part of your Active Directory domain. During their initial enrollment, the supplicant (the software on the endpoint that performs the EAP authentication) is configured, and a certificate is issued to the endpoint.  After the initial enrollment, the user no longer needs to authenticate the device via a splash page since the endpoint will now authenticate using 802.1x – which should be transparent to the user at that point.

pxGrid certificates can also authenticate and establish secure communication between your ISE nodes and pxGrid clients (third-party systems and endpoints that may provide or retrieve contact from/to ISE). If you’re unfamiliar with pxGrid, It’s a pretty cool concept. pxGrid (Platform Exchange Grid) is a technology developed by Cisco that enables dynamic sharing of contextual information between different security and network devices within an enterprise environment. It acts as a communication framework, allowing various systems, such as firewalls, security information and event management (SIEM) tools, and other network devices, to exchange data in real time. This integration enhances the overall security posture by enabling coordinated responses to threats and improving the visibility of network activities.

When integrated, pxGrid allows ISE to share its rich contextual information—such as user identity, device type, security posture, and location—with other network and security solutions. Likewise, other solutions may also share attributes they learned about the endpoints with ISE via the pxGrid integration, which can help ISE profile the endpoints or even take action to restrict access. This enables a more comprehensive security strategy where different systems can make informed decisions based on shared data, automate responses to threats, and maintain a consistent security policy across the entire network. The combination of pxGrid and ISE thus enhances the ability to detect, respond to, and mitigate security risks in a coordinated and efficient manner.

A good example of how ISE may take information learned via pxGrid and take action: Imagine if an endpoint downloaded malware. At the time of download, the firewall may not have been able to issue a disposition on that file; instead, it allowed the endpoint to complete the download. After some time, the firewall might discover that the file’s disposition should change from “unknown” to “malware.” While the firewall can block future downloads of that file, that initial endpoint still downloaded the file, and now there is potentially a “patient zero” somewhere on your network. With pxGrid integration with the firewall, that firewall could send a message to ISE to deny that device access to the network until the  Security team can wipe the device. That would allow you to create dynamic and automated security based on a condition or vulnerability.

For more information on pxGrid:

• Cisco Platform Exchange Grid (pxGrid) Devnet—This site has extensive information on creating a custom integration with pxGrid, free labs, and community support.
• ISE BERG – Cisco ISE’s Big Encyclopedic Resources Guide (BERG) – Tons of guides on integrating various products with ISE. This is maintained by the amazing Thomas Howard – who is a national treasure

I’m going to walk you through the configuration of the certificate templates. I’ll use a different Active Directory environment for the screenshots in this post, so the domain name will be different, but the configurations are still the same as what we walked through in the previous blog posts.

Go to your Start menu and open Certification Authority.

In the Certificate Authority window, expand your CA server in the left-hand pane.

Highlight the Certificate Templates folder and right-click.

Choose Manage from the list.

The Certificate Template Console window will open.

First, we will configure the client certificate that we will use to authenticate the users who log into an endpoint.

Highlight the existing User certificate template first and right-click on it.

Choose Duplicate Template.

In the Properties of New Template window, click the General tab and create a logical name for this template.

In the example below, I will push this user certificate down through my group policy, so I named it EAP-USER.

On the Request Handling tab, uncheck the Allow private key to be exported box. 

There is no reason for this certificate that we need to be allowing the private key to be exported.

On the Extensions tab, highlight the Application Policies and click Edit. 

The Edit Application Policies Extension window will pop up. Click the Add button.

Then, add the Server Authentication policy to the Application Policies. Then click OK to close the Edit Application Policies Extension window.

On the Security tab, highlight Domain Users and check the Allow boxes for Read, Enroll, and Autoenroll under the Permissions pane. This will be important when configuring our Group Policy to auto-enroll users with a user certificate for EAP authentication when they log into their computers. Without allowing these permissions on the certificate template to allow auto-enrollment, the certificates won’t be issued to users regardless of how we configure the Group Policy Object (GPO) later.

Next, navigate to the Subject Name tab. If this is a lab environment, you may want to exclude email addresses from the Certificate template as your environment may not have an Exchange server or SMTP server integrated with Active Directory to pre-populate that information in the AD. If that information is not in the Active Directory record and this box is checked in the template, your certificate will not be issued to the user.

Click Ok to close this window and save the template.

Next, we will create our computer certificate template.

Highlight the Workstation Authentication template and duplicate it as you did for the User certificate template.

On the General tab, choose a name for this template.

For the example below, I chose EAP-Computer since this will be the Computer certificate template for EAP authentication.

This template does not allow the private key to be exported by default, so we don’t need to uncheck that box as we did for the User certificate.

Under the Extensions tab for this template, highlight Application Policies and click Edit.

As we did for the User certificate template, we will click Add and choose Server Authentication.

On the Security tab, highlight Domain Computers and check the Allow boxes for Read, Enroll, and Autoenroll under the Permissions pane.

This will be important when configuring our Group Policy to auto-enroll computers with a computer certificate for EAP authentication. Without allowing these permissions on the certificate template to allow auto-enrollment, the certificates won’t be issued to computers regardless of how we configure the Group Policy Object (GPO) later.

Next, we will configure our pxGrid certificate template.

Highlight the existing Web Server template and duplicate this template.

On the General tab, give this template a name. In the below example, I gave my template the name ISE-pxGrid

If you would like to configure your Windows Server PKI to issue certificates to BYOD devices instead of utilizing ISE’s internal CA, we will walk through the configuration of the certificate template in this section.

Highlight the default User template and duplicate it again.

On the General tab, give the certificate a name. In the below screenshot, I named my template EAP-BYOD.

Note: Issuing BYOD certificates through ISE’s internal CA is much easier, and most production ISE installs are deployed that way.