Cisco ISE Wired 802.1X with EAP-TLS Example

In this blog post, we will look at a practical example of how to configure wired 802.1X with Cisco ISE and EAP-TLS. We will break down a typical network scenario and explain it in a way that's easy to understand.

The process we'll detail involves a PC (domain-joined) connecting to an 802.1x protected switch port. We'll walk you through configuring Cisco ISE, the PC, and the switch to enable this sequence of events.

Assumptions and Prerequisites

Before we proceed, let's establish the assumptions and prerequisites for this guide. This blog post assumes that you have a foundational understanding of Cisco ISE and the 802.1X protocol.

Additionally, it is assumed that the PC we're focusing on is already joined to the domain and operating correctly. Active Directory' (AD) has also been integrated with the ISE. For EAP-TLS to work, the users (or machines if you are using machine authentication) should have a user certificate issued by a trusted CA. In this example, I'm using Active Directory Certificates Services to issue user certificates.

It's also important to note that this example operates in a 'Closed Mode'. In this mode, the switch will not permit any traffic other than EAPoL until successful authentication. If this is a potential issue, consider using 'Low Impact' mode where a Pre-Auth ACL (that allows DHCP, DNS for example) on the switch port allows network access until successful authentication. Upon successful authentication, a specific level of access is granted via a downloadable ACL (dACL) from ISE. I will try to cover this in another post.

If you want to learn more about 802.1X or NAC in general or Wireless 802.1X, please check out my other blog posts below.

What is 802.1X?

802.1X is an IEEE standard for port-based network access control that provides secure network access to corporate networks. You cannot secure if you don't know what's on your network. The 802.1X framework functions as a gatekeeper for entry to enterprise networks (wired and wireless).

When a user or device wants to gain access to a network, 802.1X acts as a framework that verifies the person/device connecting is who they say they are. When we enable 802.1X on a port, the switch drops all traffic received on that port except EAPoL packets (more on this later). Only after the 802.1X authentication has successfully completed will the switch allow any other traffic on that port.

The Components of 802.1X

802.1X consists of three components:

The Supplicant (laptop) is the device attempting to gain access to the network. The supplicant communicates with the authenticator via 802.1X-encapsulated EAP packets
The Authenticator (Switch) is the gatekeeper to the network and permits or denies access to the supplicants. The authenticator acts as an intermediary (proxy) between the supplicant and the authentication server. The authenticator requests identity information (credentials/certificates) from the supplicant via EAP packets, verifies that information with the authentication server and then relays a response to the supplicant (access permit or deny)
The Authentication Server (Cisco ISE) performs the actual authentication of the supplicant. By examining the information in the encapsulated EAP messages relayed from the authenticator, the authentication server validates the identity of the supplicant and responds back to the authenticator whether or not the supplicant is authorized to access the network.

💡

While the IEEE 802.1X specification does not dictate which protocol should be used for communication between the authenticator and the authentication server, the industry has converged on Radius as the go-to protocol.

Choosing an EAP Method

When deploying 802.1X, it is important to choose an EAP method that meets your organization’s security standards. Choosing which EAP method to use is one of the most important decisions because different EAP methods offer differing levels of security and complexity. This example solely focuses on EAP-TLS.

Which EAP type to implement solely depends on the level of security that the organization requires and the administrative overhead. If you are looking for a higher level of security, EAP-TLS is the best choice, providing the strongest authentication method using client and server-side certificates.

💡

Not all supplicants/clients support all EAP methods. Please make sure to verify that the supplicants support the EAP method you are planning to deploy.

Even though there are many EAP types available, I've listed the most popular ones.

EAP-TLS relies on client-side and server-side certificates to perform mutual authentication. This is considered one of the strongest EAP types however, it requires each and every client to have a certificate pre-installed.
EAP-PEAP requires only server-side certificates for the client to authenticate the authentication server. PEAP is known as a tunnelled EAP type because it first establishes an outer tunnel using TLS and then sends the credentials via an inner tunnel. The inner tunnel can be virtually any EAP type but the widely used inner method is MSCHAPV2.
EAP-FAST is very similar to PEAP, it first establishes an outer TLS tunnel. Inside this encrypted tunnel, a secondary inner EAP method (such as MSCHAPv2) is used to authenticate the user.

Certificates

For EAP-TLS to work, we need certificates so, let's get to it. The first step is to configure a Certificate Template that AD Certification Services (AD CS) uses as the starting point for device certificates that are automatically enrolled and deployed to machines or users in the domain.

The below procedure shows how to create a copy of a template, and then configure the newly created template to enable auto-enrollment.

Navigate to Certificate Authority > Certificate Templates > Manage
For machine certificates, duplicate the 'Workstation Authentication' template and give a suitable name ('machine auth' in this example)
Under the Security tab, Allow Read, Enroll and Autoenroll for 'Domain Computers'
For user certificates, duplicate the 'User' template and give a suitable name ('user auth' in this example)
Under Security tab, Allow Read, Enroll and Autoenroll for 'Domain Users'

The next step is to Publish the newly created certificate templates as shown below. Once you added the certificates, they are available for enrollment.

You can use Group Policy to automatically enrol both computer and user certificates and deploy them to the workstations.

Open the Group Policy Management console.
Edit the GPO that you want to modify (using the Default Domain Policy in this example)
Navigate to User | Computer Configuration, Policies, Windows Settings, Security Settings, and Public Key Policies.
Double-click Certificate Services Client - Auto-Enrollment.
Change Configuration Model to Enabled.
Select both Renew expired certificates and Update certificates that use certificate templates.
Click OK to save your changes. Workstations apply the GPO and download the certificate the next time Group Policy is refreshed.

Once all the configurations are completed, you can either reboot your computer or force the GPO update by running gpupdate /force on the command line to receive the certificates. You can view the certificates on the MMC console.

Windows 10 / Supplicant Configurations

In a production environment, typically, group policies would be used to configure the network settings across the organization. However, for the purpose of this tutorial, we'll simplify the process by directly configuring these settings on the PC.

To begin, navigate to the Network adapter settings. You can access this via Control Panel > Network and Sharing Center > Change Adapter Settings. Once here, right-click on the desired network connection, and select 'Properties'. Look for the 'Authentication' tab and ensure that the 802.1X authentication is enabled and Microsoft: Smart Card or other certificate is selected within these settings.

💡

In case you do not see the 'Authentication' tab in the properties window, it's possible that the 'Wired AutoConfig' service is not running. You can start this service by opening the 'Services' app, locating 'Wired AutoConfig' in the list and starting it.

Switch / Authenticator Configuration

In configuring the switch for our use case, it's important to note that there are a lot of settings that could be adjusted to tweak and tune the behaviour of 802.1X. For the sake of simplicity, our example will only focus on the most essential configurations.

aaa new-model
!
radius server ise-01
 address ipv4 10.10.0.100 auth-port 1812 acct-port 1813
 key cisco123
!
aaa group server radius ISE-GROUP
 server name ise-01
 ip radius source-interface Vlan5
!
aaa server radius dynamic-author
 client 10.10.0.100 server-key cisco123
!
aaa authentication dot1x default group ISE-GROUP
aaa authorization network default group ISE-GROUP 
aaa accounting dot1x default start-stop group ISE-GROUP
aaa accounting update newinfo periodic 2880

interface Ethernet0/2
 description WINDOWS-10
 switchport access vlan 5
 switchport mode access
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate server
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 15
 spanning-tree portfast edge

Cisco ISE / Authentication Server Configuration

Step 1: Add the Switch as a Network Device in ISE

The very first step is to add the switch as a network device in ISE. To do this, navigate to the ISE management interface and select 'Network Resources' followed by 'Network Devices'.

Here you can add a new device (our switch) by specifying the IP address and shared secret, which should match the configurations set in the switch.

Step 2 - Certificate Authentication Profile

The purpose of the Certificate Authentication Profile is to inform ISE which certificate field the identity (machine or user) can be found on the client certificate presented to ISE during EAP-TLS. These settings are bound to the Authentication Policy to authenticate the identity.

From ISE GUI, navigate to Administration > Identity Management > External Identity Sources > Certificate Authentication Profile and select or add a profile. I'm using the default profile for this example and points the Identity Store to Active Directory.

Step 3 - Trusted Certificates

Next, we need to import the Root CA certificate that signs the user certificates into ISE.

Step 4 - Create a Policy Set

At a high level, a Policy Set in ISE is a bundle of rules, each of which contains conditions and results. When a device tries to access the network, ISE applies these policy sets to determine whether the device meets certain conditions (like being in a specific IP range or having a specific identity group) and assigns results (like allowing or denying access) based on that.

Imagine you have a list of policy sets created for different types of network users, such as VPN users, guest users, and wired/wireless clients. Each of these policy sets has specific conditions tailored to the type of network access they manage.

Now, when a request comes from a device through the switch to access the network, ISE starts to evaluate these policy sets, going from top to bottom. It checks each policy set to see if the conditions of that policy match the incoming request.

In our case, we're dealing with a wired 802.1X request from a domain-joined PC. So, ISE will scan through the policy sets until it finds the one that's specifically designed for wired 802.1X requests. Once it finds a match, it applies the corresponding authentication and authorization policies to this request. Here I'm creating a new policy set called EAP-TLS with the pre-built smart condition Wired_802.1x

The Radius:NAS-Port-Type = Ethernet and Radius:Service-Type = Framed are specific attributes included in the Wired_802.1X smart condition.

Radius:NAS-Port-Type = Ethernet: This attribute tells the RADIUS server (in this case, Cisco ISE) that the access request is coming from a device connected to an Ethernet port. This helps ISE understand the type of network access being attempted.
Radius:Service-Type = Framed: This attribute indicates that the user data is framed, meaning that it's encapsulated in a protocol.

Here you must have noticed that the 'Allowed Protocols' is set to 'Default Network Access'. This is the default list that comes with ISE. Here you can specify which EAP protocols the clients can use. In our case, we are using EAP-TLS which is already allowed (by the check box)

within a policy set, we need to define two key types of police that are Authentication and Authorization.

Step 5 - Authentication Policy

An Authentication Policy is essentially a set of rules that the ISE uses to verify the identity of a device or user trying to access the network. This is the "who are you" part of the process, checking the credentials provided by the device or user against AD or Internal User Group.

For our configuration, we are using the default authentication policy. This policy checks the certificate against the certificate profile we created in step-2. When a user attempts to authenticate, ISE takes the provided certificate and cross-checks them with the AD. If the authentication is successful the process proceeds to the next step, which is authorization.

Step 6 - Authorization Policy

On the other hand, an Authorization Policy determines what a successfully authenticated user or device can do within the network. It dictates the level of access, the resources that can be used, and any restrictions that need to be applied. This is the "what you can do" part of the process, defining the permissions for each authenticated device or user.

Our Authorization Policy in this setup is quite straightforward. It has a single condition, if a user is part of the 'desktop-users' group in Active Directory (AD), the policy 'permitAccess' is applied.

By defining these policies within a policy set, we create a rulebook for how the ISE should handle devices trying to access the network, from verifying their identity to deciding what they can do once they're in.

Verification

Now that we have our setup configured, it's time to put it to the test. To do this, I'm going to log in to a domain-joined PC with a user named 'max'. This user, being a part of the 'desktop-users' group in Active Directory, meets our defined authorization policy condition.

Given this, upon successful authentication, ISE should authorize the access request. This would confirm that our configuration of 802.1X with Cisco ISE using EAP-TLS is working as intended.

switch_01#show authentication sessions interface e0/2 details 
            Interface:  Ethernet0/2
          MAC Address:  5000.0001.0000
         IPv6 Address:  Unknown
         IPv4 Address:  10.10.20.10
            User-Name:  max		 <<<<<<
               Status:  Authorized		<<<<<<
               Domain:  DATA
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
      Restart timeout:  N/A
Periodic Acct timeout:  172800s (local), Remaining: 172796s
       Session Uptime:  5s
    Common Session ID:  0A0A141F0000001F02FC39D8
      Acct Session ID:  0x0000000F
               Handle:  0x4F00000D
       Current Policy:  POLICY_Et0/2

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecure

          
Server Policies:

Method status list: 
      Method            State 

      dot1x              Authc Success		<<<<<<

Closing Thoughts

I hope this blog post has provided you with a clearer understanding of the 802.1X process using Cisco ISE and EAP-TLS. Remember, network configurations are rarely a one-size-fits-all scenario. The settings and processes we've explored here offer a solid starting point, but you'll likely need to adjust and refine them to perfectly suit your specific environment and needs.