on 08-25-2020 05:29 PM
With Windows 10 build 2004 and ISE 2.7 Patch 2 TEAP (EAP Chaining) is now supported. It seems currently TEAP can only be configured manually for non-domain joined workstations. This is due to the TEAP option not available under the group policy configuration, for domain managed workstations. However I was able to push a group policy that enables TEAP, by exporting a group policy, changing some XML content related to the Windows Supplicant TEAP configuration, then importing again.
The process below outlines how to configure a TEAP group policy and push out to domain joined machines. The following is required:
1. Login to domain joined machine that will be used to generated the XML and ensure the defined options above have been enabled/imported
2. Under the Authentication tab on the Network Adapter properties set the Choose a network authentication drop down to Microsoft EAP-TEAP.
3.Click the Settings button next to the drop down
• Leave Enable identity privacy enabled with anonymous as the identity.
• Select the check mark 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, set both the primary and secondary EAP method for authentication to Microsoft: Smart Card or other certificate
4.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).
• Select the check mark 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.
5. Return to Authentication tab and 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.
6. Open a command prompt as administrator and execute the following commands:
netsh lan show profiles - Note down the interface name
netsh lan export profile folder=PATH_TO_FOLDER interface="INTERFACE_NAME"
An XML file will be generated with the required TEAP configuration. The interface name will be the name of the file in the location path set.
7. Open up the XML file and copy everything within <EAPConfig> ..... </EAPConfig> Store in a text file to be made available later
***To note the group policy is applied to all machines, you can configure this policy to only apply to certain groups.
1.Login to Domain Controller and open up Group Policy Management
2. Right click on the domain and select Create a GPO in this domain, and link it here
Name the new GPO
3. Right click on the newly created Policy and click Edit, navigate to:
4. Navigate to:
5. Name the Policy and move to Security tab and select the following (This is dummy configuration)
6. Right click on the Group Policy created and select Back Up...
Select the location to save the backup and click Backup
7. Navigate to the folder where the backup was saved and open up the Backup.xml file in notepad.
8. Replace the <EAPConfig> ... </EAPConfig> section with the generated EAPConfig created and saved previously:
Existing
Replaced
Ensure you save the notepad file
9. Right click on the Group Policy again and select Import Settings
10. Navigate back to the Wired Network (IEEE 802.3) Policies and edit the Policy that was created. You will see that it will not display the TEAP configuration because it is unsupported but will display some similar to this:
1. Login to test workstation that has a user & machine certificate and has been enabled to receive the group policy. Open up a cmd and execute the following command:
gpupdate /force - This will force a group policy update
gpupdate /scope /computer /v - This confirms the group policy has been applied, look under Applied Group Policy Objects:
2. Navigate to the wired network adapter under Authentication and you will see Microsoft: EAP-TEAP is selected as the authentication method. If you navigate around the rest of the Authentication settings will match what was created via the XML.
1. Navigate to Policy -> Policy Elements -> Results -> Authentication -> Allowed Protocols, Select the Allowed Protocols service that is used in your existing Policy.
2. Navigate to your wired dot1x policy and ensure their is an EAP-TLS authentication Policy
3. Create two authorization policies. 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.
I have yet to try this in production, because I would like to know how to get User Certificates onto a Domain Joined PC for every user account on a Win10/11 workstation. I know that Cert auto-enrol is a feature to automatically request and generate a machine cert for the workstation. But how the user certificate is created (especially for freshly built machines, and prior to the user's first login on that workstation) is not clear to me.
Does anyone know the mechanics of that?
@Arne Bier The way we are doing it is making a user certificate policy with Microsoft group policy to push a user cert to each computer that gets logged into by a user. This is so before you require user certification the computers in the enterprise can get the user policy deployed. We let it cook in the environment for like 1-2 months so the majority of PCs get the user certificate. Then we follow up with cisco ise and create a policy set that allows both user and machine cert auth (eap chaining) and if that fails it falls back to just machine cert authentication so their isnt any issues at the beginning of the deployment. Hope this helps. Honestly not sure if thats the "proper" way to introduce user certificates with wireless auth.
Hello @Arne Bier,
The 'chicken-egg problem' of EAP-TLS still exists on EAP-TEAP, aka. the user-certificate is generated after user first login and it took some time for it to be available. The only difference between EAP-TEAP and EAP-TLS is that, if user certificate still do not exist on EAP-TLS, the authentication fails, but on EAP-TEAP the same authentication would succeed for Machine Authentication and only the User Authentication fails. It allows you to identify machines that do not have the user certificate yet and you can trow them on a "Provisioning VLAN" with AD access and a Session-Timeout of 15 min. to force it to reauthenticate after this timeout, time which should be enough on most environments to generate the user certificate after the login, and the reauthentication would include the Machine and User Certificates and both authentications would be successfully. The Aruba ClearPass EAP-TEAP User Guide has some guidance about Intune Integration and restarting the Wired/WLAN Auto Config Service instead of relying on Session-Timeout to force a new authentication.
A similar workaround for EAP-TLS would be setting up the MAC authentication fallback with the "Provision VLAN" and Session-Timeout, which on the second authentication of 802.1X (User-Authentication) it should succeed.
ClearPass also allows to fallback to ClearPass OnGuard authentication for User Authentication that can be used if a User Certificate isn't available, not sure if Cisco AnyConnect or any other Cisco/3rd party tool may help into this case.
The safier approach is using Machine Authentication only if you do not use User Authentication data or use EAP-PEAP for User Authentication, which doesn't seems to be deprecated when used with EAP-TEAP.
Note: There's multiple users relating issues with EAP-TEAP authentication into the latest Windows 10 May 13th 2025 update, but it seems starting even after that because uninstalling it does not restore EAP-TEAP functionality, so we started to use GPO WMI filters to use EAP-TLS with Windows 10 and EAP-TEAP with Windows 11 machines.
@giovanni.augusto , everyone. I realised this problem is some years old but I want to ask you, if any one is still reading it, why did you use MSCHAPv2 first and then EAP-TLS in the configuration of the client laptop?
I am going through similar experience and after trying with EAP-TLS auhentication for both user and machine, my problem is in the authorisation rule, not the authentication.
The authentication passes because in the case of MSCHAPv2 the user exists in AD and the machine has a valid certificate. When I do EAP-TLS to aithenticate both user and machine it also passes the authentication because I have valid certificates for both.
In the authorisation rule, the account I am using is NOT in the AD Security group the rule if referenced to and hence, it should be rejected but it is not. I have tried with various AD groups that I know the account is not there and still permits full access.
What am I missing? Any help will be much appreciated.
Thank you!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: