ISE Certificate Authentication

  • Post author:
  • Post category:Cisco / ISE

When deploying Cisco ISE for Network Access Control using 802.1X, the most common authentication protocols used are PEAP/MSCHAPv2 or EAP-TLS, and to a lesser extent EAP-FAST and TEAP. PEAP/MSCHAPv2 is vulnerable as user credentials can be stolen or obtained by Man in The Middle (MiTM) attacks. EAP-TLS is considered more secure as the certificates cannot be duplicated or stolen off the device, eliminating some risks. However, EAP-TLS is generally considered more complex to initially setup and maintain, in comparison to PEAP/MSCHAPv2.

EAP-FAST is a Cisco proprietary protocol and requires the use of Cisco AnyConnect Network Access Module and licensing. TEAP (Tunnel Extensible Authentication Protocol) is relatively new and only supported since Windows 10 build 2004 and Cisco ISE version 2.7. Both are out of scope for guide.

ISE Configuration

This post will cover setting up Cisco ISE for EAP-TLS certificate authentication, it is assumed that basic ISE has been configured and integrated with Active Directory (AD) for authentication.

Root Certificate

Upload the Trusted Root Certificate used to sign the certificates issued to the computers

  • Navigate to Administration > System > Certificates > Trusted Certificates
  • Click Import
  • Click Browse

  • Enter a Friendly Name
  • Ensure that Trust for client authentication and Syslog is selected (without this selected certificate authentication will fail).

EAP Certificate

ISE has multiple certificates, each for specific purposes, including a dedicated certificate for EAP Authentication – this certificate must be trusted by the computers authenticating.

This section covers generating a Certificate Signing Certificate request on ISE.

  • Navigate to Administration > System > Certificates > Certificate Signing Requests
  • Click Generate Certificate Signing Requests (CSR)
  • From the Usage drop-down list, select EAP Authentication
  • Select the Node(s) to generate the CSR for

  • Complete the Subject section, entering the specific information such as Common Name, State, Country, City etc.

  • Click Generate
  • Click Export

In this scenario the Certificate Authority is a Windows Server, which will sign the EAP certificate. The following steps will vary depending on the CA used to sign the certificate.

  • Navigate to the Web UI and sign in
  • Click Request a certificate

  • Click advanced certificate request
  • In the Saved Request box paste the CSR request.
  • From the Certificate Template drop-down list, select Web Server

  • Click Submit
  • Select the format as Base 64 encoded, click Download certificate

Download the signed certificate to the local computer (this certificate will be uploaded in the following steps to ISE).

  • Return to the ISE Web GUI.
  • Navigate to Administration > System > Certificates > Certificate Signing Requests
  • Click the pending CSR and click Bind Certificate

  • Click Browse
  • Select the signed certificate saved in the previous step.

  • Enter a Friendly Name
  • Ensure EAP Authentication is selected (it already should be as default)
  • Click Submit
  • Navigate to Administration > System > Certificates > System Certificates

Certificate Authentication Profile

ISE uses Certificate Authentication Profile (CAP) to determine which certificate attribute is used to identify the user/device during authentication. Usable certificate attributes include:

  • Subject – Common Name
  • Subject Alternative Name
  • Subject – Serial Number
  • Subject
  • Subject Alternative Name – Other Name
  • Subject Alternative Name – Email
  • Subject Alternative Name – DNS

Optionally ISE can lookup the certificate subject name against the External Identity Source, such as Active Directory to determine User and Group information. ISE has a built-in CAP called “Preloaded_Certificate_Profile”, this does not as default lookup against an Identity Store.

In this scenario a custom CAP will be created, the user identity will be learnt from the Subject – Common Name field of the certificate AND Identity Source will lookup against the Active Directory External Identity Source.

  • Navigate to Administration > Identity Management > External Identity Sources > Certificate Authentication
  • Click Add
  • Define an appropriate Name
  • From the Identity Source drop-down list, select the Active Directory External Identity Source, in this example LAB_AD – this post assumed AD integration has already been configured.

  • Click Submit

Policy Sets

This section covers editing or creating a new policy set for authentication/authorisation.

  • Navigate to Policy > Policy Sets
  • Edit an existing Policy Set or create new, in this example we shall modify an existing Policy Set.
  • Click the Authentication Policy
  • Click the Edit cog button and select Insert new row above OR Insert new row below
  • Name the Authentication Rule appropriately name, i.e., TLS
  • Select the condition as EAP-TLS
  • From the Use drop-down list, select the CAP created in the previous step – LAB_CAP

During authorisation we can distinguish between different users or devices using attributes within the certificate, such as the Certificate Template. We can also lookup the subject name (AD computer name or AD username) against Active Directory, from there we can determine the AD Group Membership and authorise based on this AD group membership.

  • Click the Authorisation Policy
  • Create a new Authorisation rule, name for authenticating computers with a “Machine” certificate and member of the “Domain Computers” AD group
  • Select CERTIFICATE Template Name EQUALS Machine
  • Add another condition for <ID SOURCE>ExternalGroups EQUALS Domain Computers

  • Click Use
  • Create another Authorisation rule for Users with a “User” certificate and a member of ”Domain Users” AD group
  • Select CERTIFICATE Template Name EQUALS User
  • Add another condition for <ID SOURCE>ExternalGroups EQUALS Domain Users

  • Click Use

If using custom certificate (not the built-in default AD Machine or User certificates) it appears ISE determines the template using the UID rather than the actual friendly name. The example below is a custom certificate template called Customer1, it has UID ending 161.11180824.1498295

From the ISE Live Logs, ISE determines the Template Name using the UID, you can confirm the UID ending 161.11180824.1498295.

Therefore, to match on the custom certificate template in an Authorisation Rule, use must use the UID.

  • Create another Authorisation rule for users with a “Customer1” certificate, member of ”Customer1” AD group and with a certificate issued by the Internal CA.
  • Select CERTIFICATE Template Name ENDS_WITH 161.11180824.1498295
  • Add another condition for <ID SOURCE>ExternalGroups EQUALS <GROUP NAME>
  • Optionally we shall match on the Issuer of the certificate, select the condition CERTIFICATE Issuer EQUALS CN=lab-PKI-CA,DC=lab,DC=local
  • Click Use

The screenshot below confirms the 3 unique authorisation rules, with different conditions that a user could match against.

Supplicant

It is assumed that both the machine and user certificates are pre-deployed to the device using Microsoft Group Policy Objects (GPO) or other means.

  • Edit the adapter Authentication settings, configure to use Microsoft: Smart Card or other certificate

  • Click Settings
  • Ensure the correct root certificate is selected under Trusted Root Certification Authorities

  • Click Ok
  • Click Additional Settings
  • From the Specify authentication mode drop-down list, select User or computer authentication

  • Click Ok

Testing/Verification

  • From a test computer, power on the device whilst connected to the network (wired or wireless).

If working correctly, the computer will authenticate and match the correct ISE authorisation rule (certificate template = Machine AND AD group membership = Domain Computers).

  • Login to the computer as a user with a “User” certificate pre-deployed.

If working correctly, the user will authentication and match the correct ISE authorisation rule (certificate ”User” AND AD group membership = “Domain Users”).

  • Logoff and login with a user with a custom certificate (not the default “User” certificate.

If working correctly, the user will authenticate and match the correct ISE authorisation rule (certificate “Customer1” AND AD group membership = “Customer1” AND Issuer = Internal CA).

Summary

Create a Certificate Authentication Profile (CAP) to perform AD lookups to determine User/Group membership and determine which attribute should be used for authentication.

When using certificate authentication, the ISE Authorisation rules can match on any of the following certificate attributes.

  • Days to expiry
  • Extended Key Usage – Name
  • Extended Key Usage – OID
  • Is Expired
  • Issuer – Common Name, Country, Domain Component, Email, Fingerprint SHA-256, Location, Organisation, Organisation Unit, State or Province, Street Address or User ID
  • Key Usage
  • Serial Number
  • Subject – Common Name, Country, Domain Component, Email, Location, Organisation, Organisation Unit, Serial Number, State or Province, Street Address or User ID
  • Subject Alternative Name – DNS, Email, Other Name or URI
  • Certificate Template

As observed, if using a custom Certificate Template, you appear to need to use the UID rather than the actual name.

If performing Machine and User authentication and the User is logging in for the first time, generally the user will not receive the certificate in time for authentication and will fail. Most organisations pre-provision user certificates or use another authentication method such as PEAP/MSCHAPv2.

Tags: , , ,