Configuring an 802.1x Wired Policy using PEAP-EAP-TLS

Introduction

Securing wired network access is critical in today’s enterprise environments, where unauthorized access can lead to data breaches and compromised systems. Identity Services Engine (ISE) offers a robust solution for enforcing 802.1X authentication, which adds an extra layer of security by verifying the identity of devices and users before granting network access. Configuring ISE policies for wired 802.1X can seem complex, but you can protect your network while maintaining operational efficiency with the proper steps. This post will walk us through configuring ISE policies for wired 802.1X.

Configuring the Allowed Protocols

We will start our configuration by putting the building blocks together for our policy.

Navigate to Policy>Policy Elements>Results>Authentication>Allowed Protocols.

Click Add.

This is where we can define the network protocols that ISE can use to communicate with an endpoint requesting access, such as specifying specific EAP methods.

Note: There is a pre-defined Allowed Protocol list named Default Network Access. This list has the following options enabled:

Authentication Bypass>Process Host Lookup (Necessary for MAB)
PAP/ASCII – Necessary for VPN and other types of logins
EAP-MD5
EAP-TLS
PEAP-MS-CHAPv2
PEAP-EAP-GTC
PEAP-EAP-TLS
EAP-FAST-MS-CHAPv2
EAP-FAST-EAP-GTC
EAP-FAST-EAP-TLS
EAP-TTLS (All inner methods)
TEAP-MS-CHAPv2
TEAP-EAP-TLS

You might not want to allow every one of these protocols and EAP methods since most will be unused, so we will create a custom Allowed Protocol list.

I am going to name this list as MAB_APPROVED_EAP.

I will enable the following:

Process Host Lookup
Allow EAP-TLS
Allow PEAP
- Allow EAP-MS-CHAPv2
  - Allow Password Change
- Allow EAP-TLS
Allow TEAP
- Allow EAP-MS-CHAPv2
  - Allow Password Change
- Allow EAP-TLS
  - Allow downgrade to MSK
- Accept client certificate during tunnel establishment
- Enable EAP Chaining

Configuring the Downloadable ACLs

Next, we will configure the downloadable ACLs (ACLs) for our Authorization Profiles. These ACLs only exist on the NAD for the lifetime of the session. If the user or endpoint disconnects, they will not exist on the NAD configuration after the session ends. They’re genuinely portable and dissolvable ACLs.

Navigate to Policy>Policy Elements>Results>Authorization>Downloadable ACLs.

Click Add.

We are going to create the following dACLs.

Name: COMPUTER-ONLY
ACL:
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit ip any host 198.18.133.1
deny ip any any

The above ACL will be for computers without any user logged into it.

Name: EMPLOYEE-ONLY
ACL:
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit ip any host 10.1.100.21
permit ip any host 10.1.100.40
deny ip any host 10.1.10.3
deny ip any 10.1.100.0 255.255.255.0
permit ip any any

The above ACL will be for employees.

Name: ADMIN-ONLY
ACL:
permit ip any any

This ACL is for full access.

Note: Be sure to click the Check DACL Syntax link to ensure the correct syntax.

Click the Submit button to save each dACL.

Configuring the Authorization Profiles

Next, we will create the authorization profiles that we will use in our Authorization Policy. Authorization profiles define the level of access to grant an endpoint after successfully authenticating and matching the conditions of an authorization rule. Some of the different access options that we can choose to add in an authorization policy include:

DACL Name – The name of an IPv4 DACL that we previously created.
IPv6 DACL Name – The name of an IPv6 DACL we previously created.
ACL (Filter-ID) – An IPv4 ACL already configured locally on the NAD.
ACL IPv6 (Filter-ID) – An IPv6 ACL already configured locally on the NAD.
Security Group – If you would like to assign a SGT, this you can pick on here as well.
VLAN – You can assign a VLAN by name or number. If you choose to use a name, it must match the name of the VLAN configured locally on the switch.
Voice Domain Permission – If the switchport is configured with a voice VLAN, the port will be authorized to use the voice VLAN with the endpoint.
Web Redirection (CWA, MEM, NSP, CPP) – Web redirection for use with guest portal, client provisioning, posture, MDM, BYOD onboarding, etc.
Auto SmartPort – This uses the SmartPort functionality. Auto Smartports macros dynamically configure ports based on the device type detected on the port. When the switch detects a new device on a port, it applies the appropriate macro. When there is a link-down event, the switch removes the macro. For example, when you connect a Cisco IP phone to a port, Auto Smartports applies the IP phone macro. The IP phone macro enables quality of service (QoS), security features, and a dedicated voice VLAN to treat delay-sensitive voice traffic properly. Auto Smartports uses event triggers to map devices to port macros. Enter an event name, which creates a VSA cisco-av-pair with that value as auto-smart-port=event_name.
Assess Vulnerabilities – If ISE is integrated with a vulnerability scanner such as Qualys, Rapid7, or Tenable, it can kick off a vulnerability scan if the endpoint has never been assessed or hasn’t been assessed in a specified time.
Reauthentication – This option keeps the endpoint connected during authentication. The default (RADIUS-Request (0)) disconnects the existing session, but this changes it to RADIUS-Request (1). You can also select an inactivity timer from here.
MACSec Policy – You can enable this option by using Layer 2 hop-by-hop MACSec encryption and specifying the policy. From here, you can specify the following option: must-secure, should-secure, and must-not-secure.
NEAT – The NEAT feature enables extended secure access in areas outside the wiring closet (such as conference rooms). NEAT allows you to configure a switch to act as a supplicant to another switch. Enable this option to use Network Edge Access Topology (NEAT), which extends identity recognition between networks.
Interface Template – An interface template is a container of configurations or policies that can be applied to specific ports. When an interface template is applied to an access port, it impacts all traffic exchanged. There are two types of interface templates configured on a switch: User and builtin. Builtin is created by the system. User templates are created by the user. If you choose this option in the authorization policy, you can put in the name of a locally configured interface template on the switch to apply to the interface.
Web Authentication (Local Web Auth)—This option is not used as often. You would enable it if you wanted to use local web authentication for this authorization profile.
Airespace IPv4 ACL Name – This option is to invoke an IPv4 ACL configured on the Wireless Controller
Airespace IPv6 ACL Name – This option is to invoke an IPv6 ACL configured on the Wireless Controller
ASA VPN – Enable this option to assign an ASA VPN group policy.
AVC Profile Name – You would enable this option to enable an AVC profile locally configured the on switch.
UDN Lookup – Cisco’s User Defined Network Plus solution allows users to register and manage their own private network, where only their registered devices can communicate, just as if they were on a home network. With the Cisco User Defined Network Plus solution, Cisco is simplifying and optimizing the user experience for both Meraki and Catalyst wireless-based deployments. User Defined Network Plus still requires the Catalyst 9800 Series controller, Cisco access points (Wave 2 or Catalyst 9100), and ISE, but the only other requirement is Splash Access. Splash Access integrates with Cisco ISE via APIs. With this option enabled, Upon successful authentication, ISE sends a RADIUS response to the wireless controller containing three UDN vendor-specific attributes (VSAs) used for UDN segmentation at the wireless controller and access point (cisco-av-pair = UDN:Private-group-id, cisco-av-pair = UDN:Private-group-name, and cisco-av-pair = UDN:Private-group-owner)
Unique Identifier – This option is to share a value of DUID retrieved during cert-based authentication such (i.e. EAP-TLS) from the Certificate attributes (i.e., SAN) to overcome MAC Address Randomization.
For advanced users, there are hundreds of custom attributes that can be selected from the Advanced Attributes Settings.

Navigate to Policy>Policy Elements>Results>Authorization>Authorization Profiles

Click Add.

I am going to create the following profiles:

Name: Computer-Access

Check DACL Name and choose COMPUTER-ONLY from the drop-down.
Check VLAN and choose ID/Name 100

Name: Employee-Access

Check DACL Name and choose EMPLOYEE-ONLY from the drop-down.
Check VLAN and choose ID/Name 50

Name: Admin-Access

Check DACL Name and choose ADMIN-ONLY from the drop-down.
Check VLAN and choose ID/Name 75

On the bottom of the Authorization Profile, you should see the Attributes Details pane, which gives you the raw details of the RADIUS attributes sent to the switch.

Click Submit to save the authorization profile.

When finished, you should have the following authorization profiles created.

Create a saved Library Condition

Navigate to Policy>Policy Elements>Conditions>Library Conditions

Here, you see something similar to the Conditions Studio used when creating policies in ISE.

When I deploy ISE, I don’t often create many saved conditions. I find it easier to troubleshoot or make policy changes if I can see all the attributes I use listed in my policy. The only exception is defining the EAP type and tunnel to save time later adding this to my conditions.

In this window, we will create saved conditions for various EAP types.

In the Editor pane, click on the Click to add an attribute link.

This will bring up the Select attribute for condition window.

In the Attribute field, type Eap.

Choose EapTunnel from the dropdown.

Click the value field and choose PEAP from the dropdown.

Click the Duplicate button under the attribute.

On the new attribute, click the Network Access-EapTunnel attribute. This should bring up your previous attribute filter. This time, choose EapAuthentication.

From the dropdown for the value, choose EAP-TLS.

Click Save to save this condition. Name it PEAP-EAP-TLS.

Creating the Policy Set

Now, we will create and configure the policy set.

Navigate to Policy>Policy Sets.

Click the + above the default policy set to create a new policy set.

Note: If configuring a new policy set in a live environment, you can check the green checkmark next to the rule name. This will give you a dropdown menu that allows you to set the policy set’s status to Enabled, Disabled, or Monitor. The best practice for a live environment is to disable the initial policy until you have the authentication and authorization rules inside it configured.

We will name the policy as Wired Policy.

Click the + under Conditions to configure the settings.

This brings up the Conditions Studio.

The Conditions Studio as two main parts:

Editor – The right-hand pane which allows us to add or edit conditions
Library – The left-hand pane which allows us to display all saved condition blocks and drag and drop them into the editor

Click the Click to add an attribute field in the Editor.

The Select attribute for condition window will pop up.

We will create a condition based on the Network Device Groups we previously configured so we steer all RADIUS sessions coming in from switches to this policy.

Click on the All Dictionaries field.

Choose Device from the dropdown.

Choose Device Type as the attribute.

Now, choose Switches from the attribute field.

Leaving the top-level policy set condition as-is will steer all RADIUS sessions from ALL switches to this policy set. Depending on your organization, that might be all you need. I’m a fan of the KISS principle and try not to add unnecessary conditions. However, I will add a few more conditions to demonstrate some possibilities you can use to create/divide your policies.

What if you want to create policy sets based on physical location?

Hover over your condition and click on the Duplicate button that appears below it.

Click on the DEVICE-Device Type field of the new condition and choose Location.

Click on the attribute value and choose the location from the dropdown menu.

Now, all RADIUS sessions that originate from NADs that are switches located in San Jose will use this policy set.

Click Use to use these conditions.

Note: If you wonder how ISE knows how a NAD is a switch or where it is located, please see my post on Network Device Groups.

Next, click the Allowed Protocols dropdown and choose the MAB_APPROVED_EAP Allowed Protocol list we previously created.

Click Save to save this initial policy set.

Click the arrow next to the policy set to expand the Authentication and Authorization rules.

Configuring the Authentication Policy

Expand the Authentication Policy.

Click the + above the default rule to create a new authentication rule.

I will name this rule Wired 802.1x

Then click the + under Conditions to add a condition.

From the Library in the Conditions Studio, drag the Wired_802.1X condition into the Editor field.

If you don’t plan on doing BYOD, then you can likely just use this condition only in the authentication rule. However, if you plan on using BYOD or other EAP protocols that might need to be authenticated against a different identity source, you will want to add additional conditions here to specify that only PEAP-EAP-TLS will use this identity source sequence.

Drag and drop the saved library condition PEAP-EAP-TLS that we previously created into the Editor to do so.

Click Use to use these conditions.

Under the Use field of the rule, click the pencil icon next to the identity store (Internal Endpoints) to show the dropdown. Choose the CA_AD_Cert Identity Source Sequence that we previously configured.

Configure the Authorization Policy

PEAP-EAP-TLS does not support EAP-chaining. That means that the computer and user cannot be authenticated simultaneously. In a previous post, we configured an Active Directory Group Policy Object (GPO) that auto-enrolled both users and computers with certificates and configured the supplicants for EAP authentication. Based on the setting from this GPO, if a user is logged into the computer, the computer will offer the user certificate for EAP authentication. If the user is not logged in, the computer will offer the computer certificate for EAP authentication. Why is this important? If you want a computer to still have some level of access to the computer for updates, patches, etc, during the night, you will want to ensure an authenticated computer has some level of access. Otherwise, you may have to deal with hundreds or thousands of computers simultaneously getting updates, patches, etc, in the morning when computers login, and that would not be optimal. For that reason, our first authorization rule will be for computer access.

Expand the Authorization Policy.

Click on the + above the Default rule.

We will name this rule Computer Access.

Then click the + under conditions to bring up the Conditions Studio.

We are going to create a condition based on Active Directory group membership.

Click on Click to add an attribute.

From the Select attribute for condition pop-up, type in External in the Attribute field to filter the options.

Choose ExternalGroups from the dropdown next to your Active Directory domain.

From the value dropdown, choose the Domain Computers Active Directory group.

Optionally, if you plan on configuring BYOD that might use a different EAP type and want users to have differentiated access for BYOD devices vs. corporate-owned devices, you can drag our PEAP-EAP-TLS condition from the library into the editor here.

When finished, click Use to use these attributes.