Tunneled EAP (TEAP)

  13 minute read  

TEAP – Tunneled EAP

EAP (Extensible Authentication Protocol) is the standard used in 802.1x framework to authenticate users against a centralized authentication server. EAP is quite effective due to the flexibility it provides to use different authentication methods within the EAP protocol. The most commonly used EAP authentication methods today are PEAP-MSCHAPv2 (credential-based authentication) and EAP-TLS (certificate-based authentication). Typically, EAP framework allows one authentication method but when used with tunneled authentication methods, EAP also allows chaining multiple authentication methods within the secure tunnel. This means that multiple factors can be validated within a single authentication request. There have been different variants of EAP chaining however the lack of client support has been an obstacle for wider adoption. Tunneled EAP (TEAP) is a chained EAP authentication method (as defined in https://tools.ietf.org/html/rfc7170) which is now natively supported on Windows 10 / 11 platforms since Windows 10 build 2004 (May 2020). There is no support yet for TEAP on Mac or Linux platforms.

TEAP Protocol

TEAP authentication uses EAP framework with RADIUS as carrier protocol between network devices and AAA server. TEAP uses TLS to establish secure tunnel with the inner EAP methods being used inside the TLS tunnel. It does not support insecure TLS versions like 1.0 or 1.1

TEAP authentication has two distinct phases where the first phase establishes the protected tunnel through TLS handshake. Anonymous identity, TEAP version, EAP method type and information needed for TLS connection are exchanged during phase one outside the secure tunnel.

If session resumption is enabled, only phase one is executed and inner authentication methods are not used. If session resumption is disabled or if the duration has elapsed, server and client fall back to full authentication.

The second phase of TEAP exchanges happen within the TLS tunnel. Depending upon the status of different inner EAP methods, the AAA server can choose to return either an Access-Accept or Reject.

On Windows devices, TEAP is used to combine machine auth and user auth within a single RADIUS request. Depending upon the status of each authentication, policy can be defined to return either Access-Accept, specific user role / VLAN or Reject. TEAP currently supports EAP-MSCHAPv2 or EAP-TLS as inner authentication methods and it is possible use any combination of the two. For example, it is possible to use PEAP-MSCHAPv2 for machine auth and EAP-TLS for user auth or vice versa. Note that it is recommended to use certificate-based authentication wherever possible due to inherent security risks with credential-based authentication.

TEAP Use Cases

The ability to combine User and Computer authentication helps solve many issues with windows domain authentication today. With windows 10 / 11 22H2 release, Microsoft enabled credential guard which disabled credential-based authentication on Enterprise and Education versions. This has been part of a broader effort from Microsoft to move towards certificate-based authentication. While improving security, this does pose some operational challenges in terms of user certificate enrollment and authentication.

One common scenario is for laptops handed over to new employees. As part of the imaging process, it is possible to join the laptop to AD domain and to install machine certificate. However, user certificate can only be installed after the laptop has been assigned to a user. With traditional EAP-TLS authentication, when the new user logs in with their domain credential, user authentication would fail since there is no user certificate. This causes the device to lose network connectivity and means that user certificate enrollment has to be done over an open network or outside the corporate network.

With TEAP, there is now flexibility to do either machine auth or user auth within the same request. When the user certificate is not present, instead of failing authentication and losing network connection, the laptop can stay connected using machine auth to provide basic network access. Once the certificate enrollment process is complete and the user certificate is available for authentication, the device can be provided full network access.

It is common for organizations to have windows machines which are shared by multiple users. There needs to be a way where each logged in user can authenticate securely using separate user certificates. Traditional EAP-TLS can use machine certificate to stay connected when there is no user logged in. However, EAP-TLS fails when a new user logs in and there is no certificate for the user. TEAP also helps solve this challenge of using certificates for user and machine authentication on shared devices. As with the previous scenario, the device stays connected to the network using machine certificate with limited access. When the first user logs in, the device still stays connected through machine authentication allowing the user to go through the certificate enrollment process. Once the certificate enrollment process is complete, the device does both user and machine authentication at which point the device can be granted full access. Once this user logs out, the device does machine authentication alone and reverts to the limited network access state until the next user logs in and goes through the same steps to get full access.

TEAP can also be useful in scenarios where machine auth happens outside network coverage. In this case, when the device comes within range of the network, it does a user auth only. However, with TEAP, the supplicant will attempt to do both machine auth and user auth every time the device connects to the network. TEAP has also been used in eduroam deployments to do machine authentication. As the adoption increases, TEAP has the promise to solve even more problems with domain authentication.

ClearPass Configuration

There is some configuration that needs to be implemented on ClearPass to work with TEAP. TEAP is not included as a default auth method in ClearPass, so we need to create a new authentication method and then configure appropriate auth source filter queries, role mappings, enforcement policies and enforcement profiles.

Create new authentication method

First, we need to create the new authentication method from Configuration > Authentication > Methods > Add by selecting the type as “TEAP”.

With EAP-TEAP, the credentials for both machine and user are sent at the same time if available. The two inner authentication methods are broken down into Method-1 and Method-2 where Method-1 is typically machine authentication and Method-2 typically is user authentication. So, a single authentication request would have two separate usernames associated with each inner method. “User-Name in Access-Tracker” field shown in the screenshot below determines which username is displayed in the access tracker.

The inner authentication method types supported are EAP-MSCHAPv2 and EAP-TLS. Note that in ClearPass you can define different authentication methods of the type “EAP-TLS” with additional authorization and OCSP settings. All methods of type “EAP-TLS” would be available for selection.

After selecting the inner authentication methods, it is also possible to select one of them as default to optimize authentication flows.

Custom Active Directory Authorization Filters

Default active directory authorization filter uses Authentication:Username attribute to fetch user attributes from AD. This works with TEAP for user authentication. If you are only concerned about fetching authorization attributes for user authentication, no further customization is required, and you can skip ahead to the next section.

(&(sAMAccountName=%{Authentication:Username})(objectClass=user))

If there is a need to fetch attributes for machine, an additional filter needs to be added to the AD authentication source.

To add custom filter, navigate to active directory authentication source under Configuration > Authentication > Sources > Click on the active directory auth source where the custom filter needs to be added. Navigate to “Attributes” tab and click on “Add More Filters”

Add the following filter query to fetch machine attributes like group membership

(&(sAMAccountName=%{Authentication:TEAP-Method-1-Username})(objectClass=computer))

Between the default filter and the custom filter, ClearPass can now fetch both machine and user group memberships and other attributes from active directory as shown below:

Create Roles and Role Mappings

To provide different levels of access for machine vs user authentication, create new roles “TEAP Machine Authenticated” and “TEAP User Authenticated” from Configuration > Identity > Roles > Add

Create a role mapping as shown in the screenshot below to assign different roles in ClearPass for user vs machine authentication.

Create Enforcement Profiles and Policies

In scenarios where the device only does machine authentication, the Method-2 username is empty and if “User-Name in Access-Tracker” attribute in authentication method is set to Method-2 the entries in access tracker will be missing the username as shown below.

It is possible to work around this by using enforcement profiles to send the appropriate username after authentication. First, we have to create an enforcement profile to send username as part of RADIUS Access-Accept.

Next, we have to create an enforcement profile to send the machine name as part of RADIUS Access-Accept.

Finally combine both the enforcements profiles into an enforcement policy as shown below:

Here when user auth is successful we return the username. If only machine auth is successful, we return the machine name so that either the user or the machine name shows up in access tracker instead of having blank entries in username field.

Create a Service

TEAP can be incorporated into existing windows authentication services by adding the role mapping and enforcement policy conditions discussed earlier. The policy conditions must be crafted by keeping in mind devices running operating systems that do not support TEAP. TEAP also contains additional computed attributes like TEAP-Method-1-Status and TEAP-Method-2-Status which can be used as part of policy conditions. Computed attributes list also contains attributes of the client certificate used for authentication. Note that machine certificate attributes are available if the device does machine authentication only. When a device uses certificates for both machine and user authentication, the computed attributes will contain only the user certificate attributes.

Sample TEAP authentication request:

Deploying TEAP

Windows 10 build 2004 released on May 2020 and later supports TEAP natively. While the supplicant can be configured manually for TEAP authentication, enterprises need a way to be able to deploy the network profile to a large number of devices. Active directory group policy is a common method used to push TEAP profile to domain joined devices. Another option is to use MDM solutions like Microsoft Intune to push the profile. Here we will briefly discuss these deployment options.

Configuring Windows Supplicant

EAP-TEAP is one of authentication methods that can be selected in the supplicant as shown below:

Under EAP-TEAP settings, it is possible to select primary and secondary authentication methods. Note that it is recommended to enable identity privacy so that real username is not exposed in cleartext outside the TLS tunnel.

Each authentication method has additional configuration options to select the trusted root certification authorities and server names.

Configuring AD Group Policies

Create a new GPO and apply it to the appropriate OUs. Since the GPO covers both user and machine authentication, both the user and computer OUs have been selected in this example.

Within the GPO, TEAP can be enabled for either wired, wireless or both. Here a network policy called TME-Secure has been created for wireless.

Within TEAP properties, there is an option to select primary and secondary authentication methods. If the drop down is not working, you might have to toggle the up/down arrow keys on the keyboard to switch between different auth methods.

Using XML backup import method to configure TEAP SSID

In windows servers older than 2022, TEAP authentication method is not available yet. So first we have to configure TEAP on a standard windows machine manually and export the WLAN profile using netsh command in XML format. Next, we have to replace the EAP Config XML within the GPO.

1. Within GPO, configure a standard EAP-TLS SSID

2. Right click and backup group policy object

This will create a folder containing the group policy

The folder would contain backup.xml which has the WLAN configuration

3. Configure TEAP on windows supplicant manually. Choose the appropriate primary and secondary EAP methods to be used and configure the advanced settings for the EAP method like Trusted Root Certification Authorities.

4. Export the TEAP Wi-Fi profile created using netsh command given below:

netsh wlan export profile “TEAP-Test-SSID” folder=C:\WiFi-Profile interface=WiFi

5. Open the TEAP Wi-Fi profile and copy the EAPConfig XML section

6. Open backup.xml from group policy backup and replace the EAPConfig with the section copied in step 5

7. Restore the group policy object from backup location

Certificate auto enrollment using GPO

Auto enrollment over group policy helps users fetch a certificate upon logging into the machine. Steps to configure auto-enrollment can be found here:

https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-autoenrollment

Care must be taken to ensure that the machine has network connectivity to the domain controller for GPO update and user certificate enrollment.

The first step is to enable auto enrollment in the “Public Key Policy” under the group policy object.

Enable auto enrollment, certificate renewal and certificate updates

Under certificate authority, create templates for both user and machine certificate

The security permissions on the CA should also allow “Request Certificates” permission for appropriate user groups

Post Enrollment Reconnect

Note that with auto enrollment, there could be situations where TEAP authentication happens before the certificate enrollment is complete. This means that only machine authentication goes through, and hence the device is still stuck in Machine role. The experience varies depending upon how fast the certificate enrollment is completed and how soon the network profile is pushed. To get more consistent user experience, it is possible to use different methods like logon scripts that run only at first login, scheduled tasks, session timeouts etc. to deterministically bounce the network and force a re-authentication at which point the device should be able to complete both user and machine authentication.

Following articles provide details about how to setup a logon script that runs upon first logon:

https://woshub.com/run-gpo-logon-script-once/

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789190(v=ws.11)

Here is a sample logon batch script that executes upon first logon only based on the articles referenced above:

@echo off

IF EXIST C:\Users\UserName%\AppData\app_init.txt GOTO END

date /t >> C:\Users\UserName%\AppData\app_init.txt

time /t >> C:\Users\UserName%\AppData\app_init.txt

REM Put your code here, which will be executed once

REM Wait for 60 seconds for the certificate enrollment to complete before triggering auto reconnect

Start-Sleep -Seconds 60

netsh wlan disconnect interface=“Wi-Fi”

Start-Sleep -Seconds 5

netsh wlan connect interface=“Wi-Fi” ssid=“TME-Secure” name=“TME-Secure”

:END

Microsoft Intune TEAP Configuration

Microsoft Intune is a powerful cloud-based endpoint management system that can be used to manage apps and devices. Intune can be used to push network profile and certificates to managed devices and now supports provisioning a TEAP network profile along with using SCEP protocol to enroll user and machine certificates.

To configure a wired TEAP profile, navigate to Intune > Devices > Windows > Configuration Profiles > Create Profile

Set the platform to “Windows 10 and later” and profile type to “Templates” and select “Wired network” template and click Create

Give a name for the TEAP profile

Review and set scope and applicability rules appropriately. Under configuration settings, select EAP Type as Tunneled EAP (TEAP) and provide the name of AAA server under “Certificate server names”. Here for primary and secondary authentication we are using certificates with ClearPass Onboard as the SCEP server. There is a separate tech note on using Onboard CA with Intune managed devices.

https://www.arubanetworks.com/techdocs/ClearPass/TechNotes/Extensions-Intune-Onboard/Default.htm

For wireless devices, there are a few extra configuration steps. At the time of writing this document, Intune does not support EAP-TEAP within wireless network profile. However, Intune does support using custom XML to configure network profiles. To configure a wireless TEAP profile, navigate to Intune > Devices > Windows > Configuration Profiles > Create Profile

Set the platform to “Windows 8.1 and later” and profile type to “WIFI” and click Create.

Give a name for the TEAP profile

Under configuration settings, give a name for the connection and upload the TEAP network profile XML file exported from the windows device discussed earlier under section “Using XML backup import method to configure TEAP SSID”

Assign profile to appropriate groups as needed and finish creating the profile.