Using TEAP for EAP Chaining

Cisco ISE 2.7 and Windows 10 build 2004 (May 2020) added support for TEAP. This is a huge step forward because it will allow us to perform user and machine authentication at the same time. Previously, doing this required the AnyConnect NAM module and configuring EAP-Chaining (Windows only). Now, we can utilize the Windows native supplicant to perform the same action.

The setup for this configuration is as follows:

Cisco ISE Configuration

I’m using the Default Network Access allowed protocols but you can easily set it to just the protocols you require (recommended). In the default protocols, I’m enabling TEAP and EAP Chaining.

Default network access protocols. Enabling TEAP and EAP Chaining.
Modifying the Default Network Access policy under Allowed Protocols

I then modify my wired (since that’s what I’m testing) 802.1x policy set.

Policy sets overview.
Modifying the existing SecDemo Wired Dot1x policy set

I already have my authentication policy configured for EAP-TLS with an identity source sequence using a Certificate Authentication Profile that is found under Administration > Identity Management.

Authentication policy for EAP-TLS

The authorization policy is going to be updated to include two new rules. The first rule will be the machine authentication. The condition will check if the machine is authenticated but the user is not. The second rule will be the user and machine authentication. The condition for this rule will check if the user and the machine has successfully authenticated. Both rules use the Network Access ยท EapChainingResult attribute.

TEAP EAP Chaining authorization rules for user and computer authorization.
Authorization policy rules for EAP chaining

That completes the configuration on the ISE node.

Windows TEAP configuration

I’ll be configuring the wired authentication settings for this example. Go to the Authentication tab under the properties of the LAN connection (Control Panel > Network and Sharing Center > Change adapter settings > right-click LAN connection > Properties).

  1. Set the Choose a network authentication drop down to Microsoft EAP-TEAP.
  2. Click the Settings button next to the drop down.
    • Leave Enable identity privacy enabled with anonymous as the identity.
    • The Connect to these servers field is optional but can be used to ensure endpoints only authenticate to specific RADIUS (ISE PSN) nodes.
    • Place a checkmark next to the root CA server(s) under Trusted Root Certification Authorities that are used to sign the certificate for EAP authentication on the ISE PSN.
    • Under Client Authentication, I’m setting both the primary and secondary EAP method for authentication to Microsoft: Smart Card or other certificate.*
    • Under each EAP method drop down, click the Configure button.
      • Use a certificate on this computer is the default setting.
      • Leave Verify the server’s identity by validating the certificate enabled.
      • Connect to these servers is optional (just like above).
      • Place a checkmark next to the root CA server(s) under Trusted Root Certification Authorities that are used to sign the certificate for EAP authentication on the ISE PSN.
      • Click OK.
      • Repeat for secondary method.
    • Click the Additional Settings button.
      • Enable Specify authentication mode
      • Set the drop down to the appropriate setting. I am using User or computer authentication so that both are authenticated (computer on boot to login screen, computer and user when user logs in).
      • Click OK.
    • Click OK to exit the LAN connection properties.
Authentication tab of the LAN properties
Authentication tab of the LAN properties
EAP-TEAP settings window
EAP-TEAP settings window
EAP method configuration window (primary and secondary are the same)
EAP method configuration window (primary and secondary are the same)
LAN properties additional settings window
LAN properties additional settings window

Testing the configuration

Now that the Windows 10 configuration is complete, it is time to test. I rebooted the computer to get a clean Live Logs entry. The initial connection was successful! The Live Logs showed anonymous,host/WIN10-ADMIN.securitydemo.net for the identity. This was expected as we set the identity privacy to use anonymous as the username. Because this was only a machine authentication, there is no user identity to send so anonymous is basically a place holder.

Logging in to the machine with an AD account was also successful. Checking the Live Logs again showed neo@securitydemo.net,host/WIN10-ADMIN.securitydemo.net for the identity. Notice anonymous has been changed to the user account now that a user account is actually present. Both entries showed that the SecDemo-EAPTLS authentication policy was used to authenticate the sessions.

Live Logs entries for machine and user/machine successful authentication
Live Logs entries for machine and user/machine successful authentication
Session details overview section for the machine authentication
Session details overview section for the machine authentication
Session details overview section for the machine and user authentication
Session details overview section for the machine and user authentication

Looking at the session details we now have a few new fields in the session details. Most notably is NACRadiusUserName and EapChainingResult under Other Attributes. Machine authentications will only show a single NACRadiusUsername entry but the chained user and machine authentication will show two entries (one for user, one for machine). You can also verify in the session details, under the Authentication Details section, that TEAP (EAP-TLS) was used for the Authentication Protocol.

Authentication details sample for machine authentication
Authentication details sample for machine authentication
Authentication details sample for machine and user authentication
Authentication details sample for machine and user authentication
A section of Other Attributes showing NACRadiusUserName and EapChainingResult for machine authentication
A section of Other Attributes showing NACRadiusUserName and EapChainingResult for machine authentication
A section of Other Attributes showing NACRadiusUserName and EapChainingResult for machine and user authentication
A section from the Other Attributes showing NACRadiusUserName and EapChainingResult for machine and user authentication

* If your deployment is currently using MSCHAPv2 for machine and user authentication, set the secondary EAP method for authentication to Microsoft: Secured password (EAP-MSCHAP v2).

Update

So I found out there is a bug in release 2.7 (Patch 1 and unpatched) preventing you from utilizing AD groups in the authorization rule. ISE is not pulling AD group information properly when using EAP chaining so the authorization rule containing an AD group condition will not match. The bug ID is CSCvt18613. The good news is that it should be fixed in 2.7 patch 2.

I was also able to test with an instance of ISE 3.0 beta. Happy to report it worked properly. The authorization rule using EAP chaining plus an AD group condition was processed correctly.

Share this post:

8 comments

    1. I’m not 100% sure. If I change the primary method to MSCHAP v2, my username goes back to DOMAIN\username, instead of showing username@domain like it does with EAP-TLS, so it appears that the primary method is for the username. I’m still trying to find documentation to verify.

      I did notice the Authentication Protocol changed based on which method was set to MSCHAPv2. So primary EAP-TLS and secondary MSCHAP v2 would show TEAP (EAP-TLS,EAP-MSCHAPv2). Switching the methods around around would show up as TEAP (EAP-MSCHAPv2,EAP-TLS). Of course, with both set to EAP-TLS, it only showed TEAP (EAP-TLS).

  1. Can you confirm that support for TEAP is available with this update, I have checked the release notes and don’t see anything referencing TEAP.

    Thanks,

    Joe

    1. Included in the Windows update? It definitely is because that’s what my Windows 10 VM is running (build 2004). I downloaded the Windows 10 update directly instead of waiting for it to hit the automatic updates. I noticed the absence of an entry for TEAP support as well but heard about it from others. That’s why I was waiting anxiously for it.

  2. So what about RDP? Is native supplicant still can`t authorize users over RDP?
    Since it was the only reason why we install anyconnect company-wide

    1. Unfortunately, being able to force dot1x auth for RDP still requires NAM. That’s a limitation of the OS.

    1. There’s not reason to use MAR cache if you are using TEAP. MAR cache is only to check if the computer account was previously authenticated when a user is authenticating. TEAP allows you to chain both user and computer authentication at the same time. That’s why the user rule example above is checking if machine and user authentication was successful.

Leave a Reply

Your email address will not be published. Required fields are marked *