Tech Corner

• 1: Tunneled EAP (TEAP)
• 2: RadSec
• 3: Okta MFA Workflows
• 4: Okta Secure LDAP

1 - Tunneled EAP (TEAP)

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.

2 - RadSec

RADIUS and Untrusted Networks

RADIUS is the most widely used protocol for exchanging authentication information between network devices and AAA servers. It has been around for decades and being very simple has been adopted very widely in the industry. Now with the increased adoption of remote work and increased mobility of networks, there is an expectation that networks can be setup or accessed from anywhere as long there is some form of internet connection. This means that traffic flows through untrusted networks before reaching perimeter firewalls or cloud based firewalls. While RADIUS has been great for exchanging authentication data within trusted networks, it becomes very insecure when used in untrusted networks.

RADIUS uses MD5 and shared secret to encrypt sensitive attributes like password. However MD5 is old and weak leading to potential vulerabilities similar to the Blast RADIUS vulnerability discovered in early 2024. Apart from weak encryption, RADIUS also exposes other metadata about the autentication request like username, location, wireless SSID name, MAC address of the device etc. These attribute in the RADIUS exchanges are not encrypted and can be read in cleartext by anyone who can capture the RADIUS packets.

Hence there is a need for a more secure way to exchange authentication information.

RadSec: RADIUS in a TLS wrapper

This is where RadSec comes into play. RadSec first establishes a TCP connection between the network access device (NAD) and AAA server over TCP port 2083. This TCP connection uses mutual TLS authentication where both the RadSec client and server present their certificates to each other. Once the certificates have been verified and trust validated, the TLS tunnel is established.

Now with a secure tunnel between the network device and AAA server, all the RADIUS authentication and accounting messages are sent inside the tunnel. This way it is now safe from eavesdropping.

RadSec in ClearPass

For a network device to be able to send authentication requests to ClearPass, it first has to be added to the Network Devices list with the correct shared secret. If you want the device to use RadSec instead of RADIUS, there is a checkbox to enable RadSec. Once RadSec is enabled the shared secret field is greyed out and a RadSec settings tab appears.

The IP or Subnet Address here should be the NAS-IP-Address in RADIUS request. Now within internal networks, the NAS-IP-Address and actual IP address of the network device could be the same. However with RadSec use cases, authentication requests are often NATed and hence there would be the source IP address which would be the NATed IP address of the request and the NAS-IP-Address which is the actual address of the device. By default ClearPass validates both. Hence if there is NAT involved, ensure that the source IP address is entered in the “Source Override IP Address” field as shown below:

By default mutual TLS authentication of the certificates involve both OCSP and CRL checks. There are also additional validations available where you can validate the CN or SAN of the certificate or can check serial number of the issuer certificate.

RadSec Allow All

Typically, it is a good idea to validate both the NAS-IP Address and the source IP of the request so that you know exactly where the request is coming from. However there are scenarios where devices use public internet connections provided by ISPs. The public IP of these devices would keep changing from time to time and as and when these devices move between locations. Hence it becomes difficult to nail down a source IP address. For these situations it is now possible to add 0.0.0.0/0 as source override IP address with ClearPass version > 6.11.7 or 6.12.0.

When using this RadSec Allow All feature, ensure to use additional certificate validations to ensure that only devices with valid trusted RadSec certificates are allowed to connect.

Load Balancing RadSec

RadSec being TCP, it uses long lived TCP connections with both authentication and accounting messages sent within the trusted tunnel. Any standard load balancer can be used to balance the TCP connections. One thing to note is that some RadSec connection could have high rate of authentication requests while others do very less authentication. For example, RadSec connection from a wireless gateway in the corporate building with 1000 employees will have very high volume of authentications compared to a few small branch location with 10 employees each. Load balancers might give equal weightage to these RadSec connections, resulting in skewed load balancing. Another options is to terminate the TLS session at the load balancer and to send the raw RADIUS packets to the AAA servers. Very few commercial load balancers if any support this. RadSec proxy is one open source solution which can be used for terminating RadSec connections.

3 - Okta MFA Workflows

Okta is a cloud-based identity and access management service that helps secure user access with an extra layer of protection beyond just passwords.

Okta supports many MFA methods like:

• Okta Verify (push notifications, TOTP)

• SMS or voice call verification

• Email OTP

• Security questions

• WebAuthn (biometric/FIDO2 keys like YubiKey)

• Google Authenticator and others

While MFA does provide more security than just password, it can also lead to poor user experience if not implemented correctly. Certain workflows are more tolerant of the delays when the user has to access a registered device to respond to the MFA prompt. With respect to ClearPass implementation, the following workflows are MFA friendly and commonly deployed:

1. Management login to ClearPass using SAML SSO
2. TACACS+/RADIUS authentication for management login to network devices
3. Guest login using SAML SSO / Cloud Identity
4. Operator login to ClearPass guest
5. VPN authentication

Using Okta for SAML SSO

SAML is a web based authentication mechanism used to authenticate and authorize users attempting to login to the network or access applications. Once authenticated, the SAML token is cached by the browser and enables the user to access other SSO enabled webpages without having to re-login. MFA can also be part of the SAML SSO web authentication workflow and the type of MFA method depends on the IDP. Okta supports a wide range of MFA options from push notifications, entering OTP from authenticator apps or even FIDO2 biometrics through Okta verify app.

From a ClearPass perspective, this provides a secure and easy way for users to log into ClearPass and also for users to connect to captive portal based networks. The section below captures the configuration steps to use Okta as IDP for management or operator login to ClearPass.

Okta SAML Setup

On Okta a SAML Application has to be created with ClearPass as the service provider as described below:

1. Login to Okta Admin console and navigate to Applications > Create App Integration

2. Select Sign-in method as SAML 2.0 and give a name for the Application

3. Under SAML Configuration settings, configure the Assertion Consumer Service (ACS) URL and the service provider URL as shown below:

The “Single sign-on URL” would be in the format https://<ClearPass FQDN>/networkservices/saml2/sp/acs

Example:

https://cxcii.arubasecurity.net/networkservices/saml2/sp/acs

The Audience URI (SP Entity ID) would be in the format https://<ClearPass FQDN>/networkservices/saml2/sp

Example:

https://cxcii.arubasecurity.net/networkservices/saml2/sp

4. Note that if you want to enable SSO for multiple nodes in a cluster, ensure that separate “Single sign-on” URLs with the FQDN of each ClearPass cluster nodes are added to “Other Requestable SSO URLs” field in Okta under SAML App > Configure SAML > Advanced Settings

In this example, there is a two node ClearPass cluster with the following roles:

Publisher: cxcii.arubasecurity.net
Subscriber: cxciii.arubasecurity.net
VIP: cxci.arubasecurity.net

Hence, the other requestable SSO URLs are as follows:

https://cxciii.arubasecurity.net/networkservices/saml2/sp/acs

https://cxci.arubasecurity.net/networkservices/saml2/sp/acs

5. Use attribute statement to return specific user attributes as part of SAML response

6. Use Group attribute statement to return names of the groups that the user is member of. To return all the group names, use a regex “.*” as shown below. If you want to filter and return only specific groups, apply the appropriate filter in group statement

The attributes returned from Okta would show up in the “Computed Attributes” and can be used as part of the NAC policy

7. Once the app is created, navigate to Sign On page for the app and ensure that a user authentication policy is selected and appropriate MFA factors are selected as needed.

8. Next navigate to the Assignments tab and add groups and users who can be authenticated using SAML SSO

Configuring ClearPass for Okta SSO

In ClearPass, Okta needs to be configured as the IDP and a SAML SSO service must be created for management or operator login as described below:

1. Once the SAML SSO app has been created on Okta, navigate to the Sign On page, expand the “More Details” section to get the “Sign on URL” and download the Signing Certificate

2. Navigate to ClearPass, Administration > Certificates > Trust List > Add the signing certificate downloaded from Okta with the usage as SAML

3. Navigate to ClearPass, Configuration > Identity > Single Sign-On (SSO) > SAML SP and add the Sign On URL copied from Okta as the Identity Provider (IdP) URL

4. Use the “Enable SSO for” section to select for which application you want to enable SAML SSO for. Note that this is a global configuration and would enable SSO for all the nodes in the cluster. Enabling SSO for “Guest” requires additional configuraton to create a SAML SP weblogin page as described in step #6

5. Select the Okta signing certificate as the Identity Provider (IdP) Signing certificate as shown below.

6. If enabling SSO for Guest login, navigate to ClearPass Guest > Configuration > Pages > Web Logins and create a new web login page as shown below with the Pre-Auth check set to “Single Sign-On - SAML Service Provider”

7. Configure a service to handle SAML SSO authentication by navigating to ClearPass, Configuration > Service Templates & Wizards and select the template “ClearPass Admin SSO Login (SAML SP Service) and configure the service as follows

8. Now that the service has been configured, we need to create role mapping and enforcement policy to assign the approriate enforcement action. A sample enforcement profile is shown below that assigns read only access to users belonging to “HQ Employees” group in Okta while providing admin access to users belonging to “Tech Marketing” group and help desk access to users belonging to “Help Desk” group in Okta.

The enforcement profiles used in this example are:

Okta SSO in action

Example of Okta SSO for guest operator login using push notification

Example of Okta SSO for login to ClearPass Insight using Okta FastPass

Using Okta for Device Logins

Logging into devices and applications can also be secured by using MFA workflows. Typically the authentication protocols used are either RADIUS or TACACS+. ClearPass enables MFA for device logins by forwarding the auth request to Okta RADIUS agent. Okta RADIUS agent then uses API calls to Okta to authenticate the user and evaluate MFA; whether it is by triggering a push notification or evaluating the MFA token within the password attribute. Below is the flow diagram of how the integration works:

Installing and configuring Okta RADIUS Agent

Okta RADIUS agent is a lightweight application that runs as a system service that tunnels communication between on premise system and Okta. It delegates authentication to Okta using single-factor authentication (SFA) or multifactor authentication (MFA). The agent can be installed on windows or linux platforms and supports PAP, EAP-GTC and EAP-TTLS (with PAP as inner method) authentication methods.

These steps describe how to install the Okta RADIUS agent on a windows server:

1. Login to Okta and download the agent from Settings > Downloads

2. Run the exe file on the windows server to install the agent.

3. Enter proxy details if there is a proxy to reach Okta

4. Enter organization URL which would be Okta URL and sign in using a service account

5. Allow Access when prompted

6. The next step is to configure a RADIUS App on Okta. Login to Okta admin console and navigate to Application > Browse App Catalog > Search for RADIUS and add the RADIUS Integration

7. Configure the RADIUS UDP port as 1812 and enter a shared secret for RADIUS communication between ClearPass and Okta RADIUS Agent

8. Once the RADIUS App has been installed, navigate to the Sign On page of the app set up the following authentication settings.

9. For MFA workflows, ensure that a Sign On Policy is applied and multifactor is required for every session

10. Next navigate to the Assignments tab and add groups and users who can be authenticated using RADIUS Agent

Configuring ClearPass for TACACS+ MFA with Okta

On ClearPass, Okta needs to be configured as a token server so that any incoming TACACS+ request will be sent to Okta as RADIUS.

1. Add Okta RADIUS Agent as Token server with appropriate authorization source like Active Directory or Okta (over LDAPS). Steps to configure Okta as an LDAPS authentication source is documented here: https://arubanetworking.hpe.com/techdocs/NAC/tech-corner/okta-ldap/

2. Create a TACACS+ service that uses the token server as authentication source and define the role mapping and enforcement profiles to return appropriate level of access

Device login with Okta MFA

On the network device, ClearPass should be configured as the TACACS+ server. The video below captures how the push notification based MFA user experience looks like.

To trigger a push notification the password has to be entered as password,push

Example: aruba123,push

To use one time token the password has to be entered as password,token

Example: aruba123,635710

4 - Okta Secure LDAP

ClearPass can work with any open LDAP based directory as an authentication and authorization source. Here are the steps to integrate ClearPass with Okta for LDAP authentication. This integration can be used with TACACS+ / Captive Portal / Onboard workflows amongst others

1. Create an authentication source of type Generic LDAP

2. Configure Okta LDAP host details

3. Configure auth filter to lookup using uid

4. Configure filter to lookup group membership

Once the auth source is configured, we can now use it as part of authZ policies. Note that the username is the full email address since uid attribute in okta is usually email. Sample attributes from access tracker: