ISE Deployment EAP-TLS Machine or User Certificates Native Supplicant

[joeharb]

We are in the process of rolling out dot1x in a monitoring phase.  We have machine and user certificate enrollment setup via gpo/active directory.  Machine Certificates seem to working fairly consistently, but I am struggling on new user logins or admin's logging into a computer for the first time troubleshooting something....The NIC will show unauthenticated (the default ACL is currently permit ip any any to not disrupt traffic) and the authentication will fall back to MAB as there is no certificate for the logging in user in the store.  Should we add something to the policy for mab/mar combination (I have read the pro's and con's of using mar) or leverage the AD probe to determine that the machine is part of the domain to give an authenticated result?  I have struggled with this chicken and the egg scenario and hoping others have some suggestions on how to proceed.

Thanks,

Joe

[Mike.Cifelli]

A few thoughts & opinions:
-What version of Windows and ISE are you running? AFAIK the latest version of Windows (May release) has built in support for eap-teap (industry standard in comparison to Cisco's eap-fast) to accomplish eap-chaining, and ISE supports eap-teap as of ISE version 2.7. Keep in mind that other releases and versions relating to your scenario cannot accomplish eap-chaining (both comp/user auth chained together) without the use of AnyConnect NAM. Not sure of your end goal, but wanted to point that out.
Should we add something to the policy for mab/mar combination (I have read the pro's and con's of using mar) or leverage the AD probe to determine that the machine is part of the domain to give an authenticated result?
-I dont see any real issues with implementing mab as a fallback mechanism. I have seen several environments that do so. Note that in your scenario of utilizing the AD probe you could profile devices, auto add them to an endpoint group in ISE, and then push policy based on that group. Only catch is if you decide to push authz policy based on profiled endpoint groups you would require additional licensing (plus).
-As far as other options, NAM is a completely separate umbrella meaning now you add into the mix software updates, NAM profiles, user education :) , etc. IMO the native supplicant is typically easier to use and deploy. However, both options have their pros/cons. May not be a bad idea to look into eap-teap support at some point down the road. Anyways, HTH & good luck!

[Greg Gibbs]

The issue you're experiencing it due to the order of operations that Windows uses for the GPO and 802.1x processes. The certificate enrolment uses the GPO process, but the user 802.1x process kicks in before the user GPO so you run into this catch-22. The diagram below was pulled from an old Cisco document on 802.1x, but is still relevant. This is a common problem with using user auth with certificates.

There's not really an easy fix for this, but there are some options. I'm not sure if MAR will help as you don't really have a user credential to tie the 'was machine authenticated' attribute to (not sure if this will work with a subsequent MAB session).

Some options include:

1. Include an AuthZ Policy that uses CWA to allow users to leverage portal-based user authentication with their AD credentials. This could be the default rule or one above the default that uses profiler conditions based on AD probe or other attributes (hostname prefix match for SOE computers, etc). Train your users on the process to connect and possibly force the GPO update for the cert enrolment.
2. Create an AuthZ Policy that uses profiler conditions based on AD probe or other attributes alone. Restrict access to only what is required for AD login and GPO. This may not be ideal as you lose user visibility and can be difficult to implement with reasonable ACLs in a large distributed AD environment.
3. Use AnyConnect NAM to leverage separate auth methods for computer (EAP-TLS) and user (PEAP-MSCHAPv2) authentication. This is not currently possible with the Windows supplicant, but will be an option when EAP-TEAP is publicly available in Windows 10. Using MSCHAPv2 with the native supplicant, however, might require disabling Credential Guard in the domain policy. See this link regarding Credential Guard.

When you move forward from Monitor Mode, you will need to consider similar issues with the computer auth for PC builds. See this post for further suggestions.

PC Imaging on NAC secured ports 

[joeharb]

I have not found any specific information related to EAP-TEAP being available in the May release, does anyone have documentation or evidence that it is now supported?

I have thought about the CWA to allow for "onboarding", we currently do have CWA for guest access, although most of our guest access is wireless, so we haven't tested much on the wired.  

Thanks,

Joe

[Mike.Cifelli · Accepted solution]

See the following:
https://www.cisco.com/c/en/us/td/docs/security/ise/2-7/release_notes/b_ise_27_RN.html
https://www.ise-support.com/2020/05/29/using-teap-for-eap-chaining/
HTH!

[joeharb]

Thanks for the link...that is very promising.  I have looked at the release notes for Windows 10 Build 2004 and don't see any information on TEAP https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-2004

I have posted this question on the www.ise-support.com site to get more clarity.

Thanks,

Joe

[Damien Miller · Accepted solution]

I have confirmed that the Windows 10 "2004 May update" includes TEAP support.

[hslai]

[MS-GPWL]: Group Policy: Wireless/Wired Protocol Extension > 8 Change Tracking shows,

EAP-TEAP method is supported on Windows 10 v2004 and later.

Section	Description	Revision class
2.2.3.2.1 EapHostConfig Element	Added Config Format 'EapTeapConnectionPropertiesV1' of  method type '55 (EAP-TEAP)' to method implementation configuration formatting table. Also updated behavior note 25 to specify 'EAP-TTLS' method product support and that 'EAP-TEAP method is supported on Windows 10 v2004 and later.	Major