Cisco ISE Wired 802.1X with EAP-TEAP (EAP-Chaining)

In this blog post, we'll be exploring a practical example of how to configure wired 802.1X with Cisco Identity Services Engine (ISE) and EAP-TEAP. We're breaking down a typical network scenario and explaining it in a way that's easy to understand.

The process we'll detail involves a domain-joined PC connecting to a switch port. We'll walk you through configuring the ISE, the PC, and the switch to enable this sequence of events. By the end of this post, you'll understand this specific network access control scenario and be better equipped to manage it in your own network environment.

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-TEAP to work, the users and machines should have their own certificates (you can also use MSCHAPv2 which doesn't require any certificates) issued by a trusted CA. In this example, I'm using Active Directory Certificates Services to issue the 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, please check out my other blog post 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.

What is EAP-Chaining?

EAP-Chaining, a feature that facilitates machine and user authentication within a single EAP/RADIUS session. To explain this, let's picture a scenario, A user comes in, connects their laptop to the network, powers it up, and then leaves to grab a cup of coffee. In their absence, the laptop boots up, awaiting user login.

In environments that only use user authentication, the laptop would remain unauthenticated from the network until the user logs in. However, with EAP-Chaining, the situation changes drastically. It enables machine authentication, which kicks in before the user login. In other words, even when a user hasn't logged into the computer yet, machine authentication can provide a basic level of network connectivity such as DHCP, GPO updates etc. In this stage, machine authentication has been successfully completed.

When the user returns and logs in, EAP-Chaining helps to chain the user authentication alongside the pre-existing machine authentication. As a result, the user can have full network access.

EAP-Chaining ensures that only authenticated users on authenticated devices can access the network. In other words, not only must the device itself be authenticated (machine authentication), but the user on that device must also be authenticated (user authentication).

Member Plans

Why do I need TEAP for EAP-Chaining?

There's a good reason why TEAP is necessary for EAP-Chaining and why EAP-TLS or EAP-PEAP alone wouldn't suffice. EAP-TLS or EAP-PEAP are designed to handle either user or machine authentication within a single session, but not both at the same time.

However, EAP-Chaining with TEAP solves this problem by providing a mechanism to authenticate both entities in a single session. It establishes an initial secure tunnel wherein multiple EAP methods can be 'chained' together, thus allowing machine and user authentication to be performed in the same network session.

💡

While TEAP is one method to achieve EAP-Chaining, it's not the only one. You could also use EAP-FAST to achieve the same goal. However, it Cisco AnyConnect NAM client, adding an extra layer of complexity to your setup.

Certificates

As we mentioned before, 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. Here are both the user and machine certificates.

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: EAP-TEAP is selected within these settings.

Primary and Secondary EAP Authentication settings are identical as shown below.

💡

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 and 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 pointing the Identity Store to Active Directory.

Please note that I'm using Subject Alternative Name as the Certificate Attirubute but it can also be Common Name depending on how your certificates are provisioned.

Step 3 - Trusted Certificates

Next, we need to import the Root CA certificate that signs the user certificates into ISE. The same Root CA has also singed ISE's System Certificate.

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-TEAP 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-TEAP which is already allowed (by the check box). Please ensure that you check 'Enable EAP Chaining' too.

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 certificates against the certificate profile we created in step-2. When a user/machine 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

For the Authorization Policy, we are providing access levels based on whether we are dealing with machine-only or both machine and user authentications. The goal is to provide minimum access for machine-only situations, while full access is provided when both the machine and the user are authenticated.

Firstly, let's create a Downloadable ACL (dACL). This dACL permits only the most basic of access such as DHCP, DNS and LDAP. This is the "bare minimum" access we allow for machine-only authentication.

Following that, we need to create an Authorization Profile. This is essentially the 'result' of your authorization process. I created one named 'machine_only_auth' and associate the previously created dACL with it. In an event where only the machine is authenticated, ISE sends this dACL to the network switch. The switch then applies this dACL to the specific port that the machine is connected to, ensuring restricted access.

However, when a user logs in, it's not just the machine being authenticated, but the user as well. In response, ISE sends the default 'PermitAccess' Authorization Profile to the switch. Unlike 'machine_only_auth', this profile doesn't have a restrictive dACL associated with it. Hence, it allows for full network access.

In a nutshell, if the user connects the laptop and walks off before signing in, the request will hit the 'Machine Only' authorization policy. When the user comes back and logs in, the request will hit the 'Machine and User' Policy.

Verification

Now that we have our setup configured, it's time to put it to the test. To test machine-only, I'm going to connect the laptop to the switch port and power it on.

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:  host/DESKTOP-JLGSL24.packet.lan
               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: 172712s
       Session Uptime:  112s
    Common Session ID:  0A0A141F0000001B03534673
      Acct Session ID:  0x0000000F
               Handle:  0x5D00000C
       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:
              ACS ACL:  xACSACLx-IP-machine_only-64c7a6c5	<<<<< dACL here
Method status list: 
      Method            State 
      dot1x              Authc Success

Now that we have tested the first part of the puzzle, I'm going to login with the user called 'max' and see the results.

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@packet.lan
               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: 172394s
       Session Uptime:  472s
    Common Session ID:  0A0A141F0000001B03534673
      Acct Session ID:  0x00000010
               Handle:  0x5D00000C
       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

This confirms that our configuration of 802.1X with Cisco ISE using EAP-TEAP is working as intended.

Closing Thoughts

I hope this blog post has provided you with a clearer understanding of the 802.1X process using Cisco ISE and EAP-TEAP. 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.