Configure EAP-TLS Authentication for Cloud Networks

Key Takeaways

• EAP-TLS authentication relies on certificates to provide secure, password-free wired and wireless network access, eliminating challenges with stolen or shared passwords.
• It requires a Public Key Infrastructure (PKI) to manage certificates, as well as a RADIUS server like Cloud RADIUS to authenticate the certificates.
• The certificates can be encoded with information from your Identity Provider, such as Azure AD/Entra ID, allowing for more granular network access policies such as VLAN segmentation.
• SecureW2 provides both a PKI and Cloud RADIUS server designed with vendor-neutrality in mind to integrate with all major IDPs and MDMs.

Network infrastructure is becoming increasingly complex, especially with employees logging in remotely using their personal devices like cell phones or other Bring Your Own Device (BYOD). This makes it a complex system that on-prem servers can no longer manage.

There is also the additional challenge of identifying a user or device with absolute certainty in a password-based environment. Passwords do not provide a good identity context, as they can be stolen or shared. Issues such as a locked account for using the wrong password can increase the burden on IT teams.

Azure AD, by Microsoft, helps organizations move to the cloud. But it uses an LDAP server that relies on PEAP-MSCHAPv2 and, therefore, does not solve the challenges of password-based authentication.

Certificate-based authentication method EAP-TLS can help improve the security of your cloud network by helping you create an environment for identity context-based authentication.

In this article, we will explain:

• How we can configure EAP-TLS authentication for cloud networks
• The benefits of using UniFi EAP-TLS to protect your network
• What EAP-TLS is and how it compares to other authentication methods

What Is EAP-TLS?

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is an authentication protocol that allows the use of X.509 digital certificates for authentication. It uses Public Key Infrastructure (PKI) to enroll and manage certificates and is considered the gold standard of authentication.

The following diagram illustrates the EAP-TLS authentication flow.

Its use across the board as an authentication method for an enterprise network, however, is less popular. EAP-TLS as an authentication protocol was developed long ago when there was no onboarding solution available that could automate the certificate management process. The challenge of setting up the PKI causes most organizations to shy away from using this protocol.

SecureW2 has developed the industry’s best cloud PKI and Cloud RADIUS with EAP-TLS. They integrate with Azure AD seamlessly to provide excellent certificate-based authentication for Wi-Fi.

Info: Read our customer success stories to find out more about how we helped organizations to move their networks to the cloud and go passwordless.

How Does Ubiquiti Unifi Authentication Work With EAP-TLS?

EAP-TLS adds a layer of security to your Unifi network. Here’s what the workflow looks like with a WPA2 or WPA3-Enterprise network.

When a client seeks to connect to your network, the UniFi access point initiates an EAP-TLS handshake by requesting the client’s digital certificate via 802.1X. The UniFi access point forwards the EAP exchange to your RADIUS server.

Once the RADIUS server verifies the client certificate, it sends a message to the access point, which grants network access.

Why Should You Use EAP-TLS With Your UniFi Network?

EAP-TLS protects your UniFi network by replacing shared passwords with digital certificates and mutual authentication. If you’re using WPA3-Enterprise, EAP-TLS provides the high level of security required for compliance.

Legacy security methods, like shared passwords, can be cracked, phished, or stolen, creating risk for the whole network. EAP-TLS bypasses shared secrets and assigns users digital certificates instead.

EAP-TLS uses mutual authentication, requiring the client and the RADIUS server to present digital certificates. This protects you from spoofed access points and “Evil Twin” attacks.

The User Experience With EAP-TLS

EAP-TLS with a RADIUS server, used in an enterprise network, improves network security and performance and, overall, provides a better user experience for unmanaged and managed devices.

EAP-TLS Eliminates Password-Related Disconnects

Certificates eliminate all issues related to password management that create a terrible user experience in a credential-based environment.

When a certificate is created for a user or a device, the certificate templates will be recorded with certain information unique to the user or the device. This information, which provides a better identity context, is used to verify the identity at the time of authentication, thus eliminating the need for submitting credentials.

EAP-TLS Is More Secure

EAP-TLS authentication, when deployed with a RADIUS server, makes your network more secure. It mitigates the risks of over-the-air threats such as Man-in-the-Middle (MITM) attacks since there is no data to intercept.

Certificate-based authentication does not require transferring of passwords over the air. Authentication is complete with a successful private-public key handshake and an authentication server like RADIUS verifying the certificate is valid.

Authentication With EAP-TLS and RADIUS Is Faster

EAP-TLS has fewer steps than other credential-based authentication protocols, making it more efficient.

Cloud RADIUS, which is designed for EAP-TLS, does real-time look-up with IDPs at the time of authentication, and it does so very quickly by integrating natively with all major IDPs.

EAP-TLS vs. Other WPA2 & WPA3-Enterprise Authentication Protocols

The following table illustrates the key differences between the most common WPA2 and WPA3 Enterprise authentication protocols.

WPA2 & WPA3-Enterprise Common Protocols	Level of Encryption	Authentication Speed	Directory Support	Credentials
EAP-TLS	Public-Private Key Cryptography	Fast – 12 Steps	Universal	Passwordless
PEAP-MSCHAPv2	Bad Encryption (MD4, Compromised since 1995)	Slow – 22 Steps	Active Directory	Passwords
EAP-TTLS/PAP	No Credential Encryption	Slowest – 25 Steps	Non-AD LDAP Servers	Passwords

EAP-TLS is considered the most secure of the three authentication protocols because of certificates. X.509 certificates cannot be stolen because of the public and private key combinations that are almost impossible to crack. Also, with certificate authentication, there is no need for human input, thus reducing the risks due to human error.

In a work environment with multiple locations for login, identity context-based authentication is considered the most effective. That’s because it helps implement a zero-trust network that demands always verifying the client, not just at the time of authentication but continuously monitoring user behavior to detect any suspicious activity.

A certificate-based EAP-TLS protocol creates the foundation for a network security infrastructure that can dynamically monitor user behavior and, with the help of machine learning, identify and stop any behavior that is not on par with the usual user activity.

Native Integration With Azure AD for Deploying Enterprise Networks

With SecureW2’s onboarding solutions, configuring a certificate is completely automated, making it a great user experience. We can help you configure EAP-TLS authentication by easily integrating your existing infrastructure with our turnkey solutions.

Let’s look at an example of how Azure AD is integrated with SecureW2 PKI and RADIUS for a WPA2-Enterprise network.

Here’s how it’s done:

1. First, tie the PKI Infrastructure to Azure AD for certificate enrollment and management.
2. Then tie the RADIUS Infrastructure to Azure AD for authentication.
3. Lastly, link the Device Management platform — in this case, Microsoft Intune — to SecureW2’s cloud PKI.

Configuring Managed Devices for 802.1X With Intune (Microsoft Endpoint Manager)

Configuring managed devices for 802.1X certificates and certificate-based authentication is seamless.

You just have to complete these steps:

• Configure your MDM platform with SecureW2’s PKI services. Once set up, any device requesting access to your network will be sent configuration profiles for self-service of 802.1X and auto-enrollment of certificates.
• Once your managed devices are enrolled with a certificate, Cloud RADIUS will directly communicate with your Cloud IDP for real-time look-up to authenticate Wi-Fi access.

This does not require a Lightweight directory access protocol (LDAP) server. Your devices, configured for certificate-based authentication, will be authenticated by Cloud RADIUS in any major Cloud IDP to authorize access per their assigned roles defined in the IDP.

The diagram below illustrates how SecureW2 Cloud RADIUS protects networks using certificate-based authentication.

 

For a detailed configuration guide for MDM certificate enrollment for your Intune devices, click here.

How to Use Other MDMs for WPA2-Enterprise/802.1X

Configuring Intune for certificate deployment with Azure AD is simple because they are compatible since both are Microsoft products.

However, some MDMs are not designed to include an email address in the certificate template RFC. This causes a break in the look-up process, making it impossible for admins to identify the user without the email address.

Info: The SecureW2 JoinNow suite with certificate enrollment Gateway APIs enables auto-enrollment of devices for certificates.

This solution can easily integrate with all major MDMs, such as Jamf and Kandji, to enable identity look-up integration for matching the certificates with the devices they are attached to.

Here’s a guide to integrating Azure and AD with SecureW2 for deploying certificates to enable EAP-TLS auth protocol for managing an 802.1X network in the cloud. Click here for a more detailed guide.

Unmanaged Devices/BYOD and WPA2-Enterprise/802.1X

Configuring EAP-TLS manually requires expertise that an average end-user does not have.

Warning: Misconfiguring can have an adverse impact on your business. Missing server certificate validation can lead to evil twin attacks and misconfiguring EAP, to name a few, leaving your network vulnerable.

Configuring unmanaged or BYOD devices for EAP-TLS is simple and hassle-free with our JoinNow MultiOS self-service configuration solution.

• When a user requests access for the first time from an unmanaged device, they run our onboarding software on the device that is customizable to change style, instructions, or which operating system to support.
• This is a quick process that doesn’t take more than 60 seconds.
• Once the device is enrolled, the authentication with a certificate to connect to the network is automatic.
• Our solutions can be customized to best suit your needs, such as multiple landing pages for different types of access.

Configuring EAP-TLS Authentication for a Cloud Network

The next part of the article is a guide to configuring EAP-TLS.

We will be using an Azure AD environment as an example to explain the configuration process steps that include:

• Creating an SAML application in WPA2-Enterprise
• Active Directory Integration with the Azure SAML Application
• Attribute Mapping and Policies Configuration for 802.1X Certificates

Note: Contact us to learn more about how SecureW2 can help you set up EAP-TLS authentication. If you’d like to know how to configure EAP-TLS authentication for cloud networks, continue reading below.

Creating SAML Application in Azure for WPA2-Enterprise

The Security Assertion Markup Language (SAML) application is a crucial component for connecting the IDP and the JoinNow MultiOS Management Portal. This is where the end users feed their credentials that are looked up in the IDP to verify the user.

The following image illustrates how SAML-based certificate enrollment works.

Once the IDP verifies the credentials, they return attributes that the SAML app shares with SecureW2’s PKI for issuing certificates.

How to Set Up SAML Application for Azure With SecureW2

1. Log in to the Azure Portal.
2. From the Login page, go to Enterprise Application (Type Enterprise applications in the search box) to create a new application.
3. Click New application in the main pane.
4. Type SecureW2 JoinNow Connector on the Browse Azure AD Gallery page.
5. Select SecureW2 JoinNow Connector and type a name for the application in the pop-up window. Click Create.

Create an IdP in SecureW2

1. Log into the JoinNow MultiOS Management Portal.
2. Go to Identity Management > Identity Providers and click Add Identity Provider.
3. Type a name for the provider in the Name field.
4. Select SAML from the Type drop-down list.
5. Select Azure from the SAML Vendor drop-down list.
6. Click Save. An additional tab, Configuration, gets created once you click Save.
7. Click the Configuration tab. Copy the Entity ID and ACS URL to the clipboard and save it in a word/text file. You will need this at the time of connecting with your SAML application.

The SecureW2 Cloud Connector is now ready and available to exchange information with your Azure directory.

To Configure Single Sign-On in Azure

1. In the left pane, go to Manage > Single Sign-on.
2. Select SAML-based Sign-on from the Single Sign-on page.
3. Click the Edit button in the Basic SAML Configuration section.
4. Enter the Entity ID and ACS URL values obtained earlier. (See Creating a SAML IDP, Step 7) in the Identifier fields.
5. Enter the same value as the Reply URL obtained from the ACS URL in the Sign-on URL field.
6. Click Save.
7. Click the DOWNLOAD button under the SAML Signing Certificates section to get the Federation Metadata XML file from Azure.

To Configure the IDP Using Azure Metadata

You will have to upload the Azure metadata to SecureW2. The steps for this process are:

1. Go to Identity Management > Identity Providers in the JoinNow MultiOS Management Portal.
2. Click the Edit link of the SAML IDP you created.
3. Click the Configuration tab.
4. Click Choose File in the Identity Provider (IDP) Info section to select the Metadata XML file downloaded from Azure.
5. Click Upload.

Active Directory Integration With the Azure SAML Application

Now that your SAML Application is configured in Azure and SecureW2, you can start assigning users.

You can assign the users directly, or you can integrate with your Active Directory to refer to the database from there. Let’s take a look at the steps in this process.

Adding Users to the SAML Application

1. Go to the JoinNow Connector Application or the newly created SAML application in the Create an SAML Application in Azure section from Microsoft Azure Portal.
2. Next, go to Manage > Users and groups.
3. Click Add User.
4. Use the Select field from the Users and groups pane to search for the user by name or email.
5. Click Assign in the Add Assignment pane.
6. Go to Manage > Users and groups to create groups.
7. In the search box, type “Groups” and click Groups.
8. Click + New group to add a new group.
9. Select Security from the Group type drop-down list.
10. Type a suitable name for the group in the Group name field.
11. Type a description for the group in the Group description field.
12. Select Assigned from the Membership type drop-down.
13. Click No members selected in the Members field.
14. Search for one or more members in the Add members window. Choose the member(s) from the list and click Select. The selected members are now added to the group.
15. Click Create.
16. To create additional groups and add members, repeat steps 4-9.
17. Search for the group(s) created on the screen and copy the Object ID(s) of the group/groups to the clipboard and save it in a Word/text file.

Granting Your SAML Application Access to Active Directory

1. Use the search feature from the Microsoft Azure Portal to go to App registrations.
2. Click the dropdown next to the search field and select All apps to display the list of all available applications.
3. Click the application you want.
4. Scroll under Manage and click API Permissions from the pane of your application.
5. Click Add a Permission under Configured Permission.
6. Select Microsoft Graph and Delegated Permission from the Request API permissions pane.
7. Select the following permissions:
   • Directory.Read.All
   • Group.Read.All
   • User.Read.All
8. Click Add Permissions.
9. Click Settings in the pane for your application.
10. Click Manifest > Edit.
11. In the Edit manifest pane, in the source code:
    • Change the value to ‘All’ for the ‘groupMembershipClaims‘ variable.
12. Click Save.

Attribute Mapping and Policies Configuration for 802.1X Certificates

This is one of the most crucial stages for network segmentation and for designing the foundation for identity context. The screenshot below shows the basic certificate template settings page.

Each certificate can be assigned attributes that contain information about the user’s identity, such as their role and level of access. Let’s look at how these attributes are sent to SecureW2 to be included in the certificate template and how to configure policies in the management portal.

Attribute Mapping Configuration in SecureW2

1. Go to Identity Management > Identity Providers from the SecureW2 Management Portal.
2. In the IDP you created in the section “Create an Identity Provider in SecureW2”, click Edit.
3. Select the Attribute Mapping tab.
4. Click Add.
5. Enter ‘upn‘ for Local Attribute.
6. Select USER_DEFINED from the Remote Attribute dropdown.
7. In the field that appears, enter ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name‘.
8. Click Next.
9. Click Add.
10. Enter ‘email‘ for Local Attribute.
11. Select USER_DEFINED from the Remote Attribute dropdown.
12. In the field that appears, enter ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress‘
13. Click Next.
14. Click Add.
15. Enter ‘displayName‘ for Local Attribute.
16. Select USER_DEFINED from the Remote Attribute dropdown.
17. In the field that appears, enter ‘http://schemas.microsoft.com/identity/claims/displayname‘
18. Click Next.
19. Select the Basic tab.
20. For Group Map Attribute, enter ‘http://schemas.microsoft.com/ws/2008/06/identity/claims/groups‘.
21. Select the Groups tab.
22. Click Add.
23. Enter a name for the Local Group.
24. Log into your Microsoft Azure Portal in a new browser tab/window, and go to Azure Active Directory > Groups > All groups.
25. To search for the group, use the Name field
26. Click the group, and then go to Properties.
27. Copy the value for Object ID.
28. Return to your SecureW2 Management Portal.
29. For Remote Group, paste the Object ID value.
30. Click Create.
31. Click Update.

Updating Profile Policy in SecureW2

1. Go to Policy Management > Profile from your SecureW2 Management Portal.
2. Click Edit profile policy.
3. Select the Settings tab.
4. Select the IDP you created from the Identity Provider dropdown.
5. Click Update.

Updating User Role Policy in SecureW2

1. Go to Policy Management > User Roles from the SecureW2 Management Portal.
2. Click Edit DEFAULT ROLE POLICY 1.
3. Select the Conditions tab.
4. Select the IDP you created from the Identity Provider dropdown.
5. Click Update.

Adding a User Role Policy in SecureW2

1. Go to Policy Management > User Roles, and click Add Role.
2. In the Name field, enter a name.
3. Click Save. You will be directed to the Conditions tab.
4. Select the Identity provider created in section 1.2 from the Identity Provider drop-down.
5. Click Update.

Adding an Enrollment Policy in SecureW2

1. Go to Enrollment and click Add Enrollment Policy.
2. Enter a name in the Name field, and click Save.
3. For the User Role list in the Conditions tab, select the user role you created in the previous section.
4. Select the DEFAULT DEVICE ROLE policy or a policy you created in the Device Role list.
5. Click Update.

Republishing Your Network Profile

1. Go to Device Onboarding > Network Profiles, and click Publish or Republish if it is already published. This may take about 60 to 90 seconds.
2. Click View once published.
3. Click the JoinNow button to download a Wi-Fi wrapper package.
4. Open the downloaded file to enter your Azure credentials once the system prompts.
5. Check if enrollment is successful when the system tries to enroll and connect.

Note: If you encounter any issues with your setup, please contact us at support@securew2.com.

Improve Security Without Adding On-Premises Infrastructure

EAP-TLS is the authentication standard that neutralizes most credential-based attacks. 

But traditional deployments often come with costly on-premises PKI and RADIUS infrastructure, along with the ongoing challenge of managing certificate issuance, renewal, and revocation at scale. 

SecureW2 was built specifically to make EAP-TLS practical for IT teams without a dedicated PKI team. 

Our JoinNow platform delivers secure certificate enrollment for both managed and unmanaged devices through modern methods such as ACME Device Attestation (ACME DA), Dynamic SCEP, and SAML-based authentication.

Combined with Cloud RADIUS and real-time policy enforcement, it enables scalable EAP-TLS deployments across major operating systems and device environments. 

Schedule a demo to see EAP-TLS deployment in action.

Frequently Asked Questions

Does UniFi support EAP-TLS?

Yes. UniFi supports EAP-TLS to deliver secure authentication on 802.1X networks. UniFi acts as the access point for EAP-TLS, passing messages from client devices to the RADIUS server. Your PKI and RADIUS issue digital certificates for mutual authentication.

What do I need to set up EAP-TLS on my UniFi network?

As prerequisites for setting up EAP-TLS on your UniFi network, you need a RADIUS server and a PKI to issue digital certificates. You also need to configure your UniFi console and WPA-Enterprise SSID for EAP-TLS.

What are the core requirements for running EAP-TLS?

There are a few core infrastructure components necessary to run EAP-TLS. You need a PKI to issue and manage digital certificates; you also need a RADIUS server to handle the TLS handshake, and wireless access points to support 802.1X authentication. Besides this, you need a directory (like Active Directory or Entra ID) and, ideally, a Mobile Device Management system.