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
TEAP properties window
TEAP properties 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. Hopefully it will be fixed in 2.7 patch 3.

Update 2 (2021/02/04)

I installed patch 3 for 2.7 and can verify that the TEAP/AD group bug is fixed. TEAP EAP-Chaining authorization rules that contain AD groups are now processed properly.

Share this post:

29 comments

  1. Is Primary method belongs to ‘Machine’ auth and secondary refers to User authentication.

    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).

    2. Very good article, thanks for sharing… just a quick note on CSCvt18613, we are not positive it will be fixed in patch 3. The workaround for now is to use TLS instead of MSCHAPv2.

  2. 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.

  3. 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.

  4. Can you use mschapv2 domain computer and user checking using AD instead of with certs? How would the authentication and authorization rules look for this to work?

    1. Absolutely. You don’t really need to change anything in the authorization policy itself. You would need to make sure your authentication policy is configured for either just dot1x or you can set an authentication policy with a condition of “Network Access·EapAuthentication EQUALS EAP-MSCHAPv2” and then your identity store.

      If you to have separate authorization rules based on the authentication type, add “Network Access·EapAuthentication EQUALS EAP-MSCHAPv2” as one of the conditions in the authorization policy rule(s). Just be sure your authentication rules also support multiple auth types as well.

    2. Very good article, thanks for sharing… just a quick note on CSCvt18613, we are not positive it will be fixed in patch 3. The workaround for now is to use TLS instead of MSCHAPv2.

    3. It’s hopeful that it is fixed in P3 after it wasn’t in P2.

      As for MSCHAPv2, the problem (no AD group lookup when using TEAP and EAP chaining) happens even with EAP-TLS. I’ve tried different combinations and then found that bug ID. If I disable the rules that don’t require AD groups, I hit the default rule which is Deny Access in my set up. I can see in the steps (auth details) where it queries for AD groups but it doesn’t match up with any.

  5. Nice.
    Will password change work when using certificates on both authentication modes?
    we use EAP-TLS today, and with that setup, password change does not work.

  6. Anyone else having problems with identity privacy?
    Any setting i put in there, is always ignored, and identity (radius user name) is always anonymous.
    Seems like a bug.
    But in windows or in ISE, that is the question

    1. Try using SElf-signed certificate, for me it doesn’t work with CA signed certificate… I have a CAS open with Cisco and they are investigating. Also I got that problem if you use the option ‘Preferred protocol TEAP’. Leave it ubchecked. I’m using ISE 3.0 PATCH 2.

  7. i wonder if by using EAP chaining can i do the followings?
    match domain_user_A group and domain_machine_A group, assign to vlan10
    match domain_user_B group and domain_machine_B group, assign to vlan20?

    1. That should work, depending on Eap-Chaining results.
      Add additional condition to the Auth policy

  8. How does this change if you aren’t using user certs and are just using AD creds? I can’t get it to work, it seems like the PC is sending my microsoft org cert instead of my AD creds when I configure it as you did. Any help would be greatly appreciated.

    1. For the record, I had to do 2 things, MS-CHAPv2 first and EAP-TLS second. And I had to follow the instructions here to change the ambiguity settings: https://community.cisco.com/t5/network-access-control/cisco-ise-user-certificate-ambiguity-error/td-p/4052761

      My Certificate Authentication Profile needed to have “Only to resolve identity ambiguity” selected under “Match Client Certificate Against Certificate In Identity Store” and at the time I had “Always perform binary comparison”. That caused it to resolve it all as invalid.

  9. Getting an error when implementing this. We always get the “anonymous” username but the host part is correct, We’ve unchecked the enable identity privacy already. I’ve an open case with TAC.

    1. Did some testing today on ISE 3.0 p4 and funny thing. No matter if EAP-TLS or MS-CHAPv2 is used for the inner method the computer always rejects the user authentication but the machine auth always works. I can see in the ISE logs that the client rejected the method but only for user even though both primary and secondary method match identically. We tried on a windows 10 and windows 11 machine with the same results. I have not had this issue on ISE 2.7 releases.

  10. I am trying to implement TEAP with ISE 3.1 patch 3
    So far I am not able to authenticate user with certificate, TLS handshake failed.
    Both machine and user use same EAP root CA , only machine authenticate successfully.
    Anyone had same problem?

    1. That is odd if the user cert and machine cert are from the same CA. Are you limiting what root CAs (under the settings for each authentication) are allowed? What if you change the user auth to MSCHAPv2 while leaving the machine auth EAP-TLS?

  11. What to do if the machine is authenticated in vlan1 and the user has vlan2. After reauthentication the computer falls into vlan 2 network and Dns cannot find it. What to do to always know the computer

  12. We’re experincing the issue that some of you have mentioned, where the user cert is not being authorized but the machine cert work fine. When changing to MSCHAP the user auth works fine. Not sure what we’re doing wrong. As “Danijel” mentioned, we’re also seeing the TLS Hanshake fail but as far as I can see in the logs, it is the correct certificate being used/sent.

    Anyone has some ideas or knows that this is a bug?
    Tried it with and without NAM, same issue with both setups. We preferably want it to work without NAM.

    ISE version 2.7 Patch 10

  13. We recently configured authentication via TEAP, validated it on some machines, but for some reason, we are receiving the error “Received malformed EAP Payload TLV”. We do not have a specific GPO, but we follow a supplicant configuration step, without sending a certificate. Authentication has two checks, one for the user and the other for the machine. However, I wanted to know if I can get around this error.

Leave a Reply to Mark Cancel reply

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