Authenticate with Azure AD (Entra): 802.1X Setup

Step-by-Step Guide: Setting Up 802.1X with Azure AD

Sync your Azure AD (Microsoft Entra ID) with an LDAP Server

Some organizations have adapted by performing an LDAP sync, duplicating their Azure AD on-premises so LDAP applications can continue on. For organizations with existing credential-based 802.1x, this can be a good temporary solution that allows them to move to Cloud Azure AD while they continue to use their legacy servers.

However, configuration guides are hard to find. And whatever guides you can find are difficult to configure. At a high level, you need to build an OpenLDAP server, install Azure AD Connect and manually configure an Azure AD federation. An easier method is desirable.

There are third-party solutions that handle the LDAP sync by providing cloud-based LDAP servers. While you are able to migrate away from your on-prem infrastructures, it still seems like a step back because you’re authenticating with passwords and using vulnerable authentication protocols like Protected Extensible Authentication Protocol Microsoft-Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2), which industry titans have recommended moving away from.

In essence, an LDAP sync can be a good temporary solution for organizations that want to move their AD to the cloud, but it’s difficult to set up. Also, it’s not a long-term solution due to security concerns.

Leverage Azure AD to Enroll x.509 Certificates

The second option is adopting a passwordless solution by using Azure AD to issue and manage X.509 Digital Certificates, which can be used for a number of applications like Desktop Login, a virtual private network (VPN) and 802.1X Wi-Fi. Authenticating via certificates is similar to passwords; you present identification to your Access Point (AP), it forwards it to the RADIUS server, and then the RADIUS tells your AP whether you are allowed access or not.

However, there are a few key differences:

• Certificates are significantly more secure than passwords.
• Certificates provide much more usable context for security decisions. They offer a ton of device information: who owns it, the type of user attached to it, the make and model, and conditional access in your organization.
• Certificates simultaneously improve user experience and They eliminate password-related disconnects and threats of evil-twin attacks that steal credentials over-the-air.
• For organizations that use Azure AD as their Identity Provider: certificates eliminate the need for on-premises servers. Windows servers are among the most targeted vulnerabilities in organizations.

These are just a few of the reasons why the NSA and CISA have both recommended certificates.

Historically, organizations shied away from using certificates. They required public key infrastructures (PKI) which were difficult to setup, and certificates were impossible to manage. Today, PKIs can be configured as an extension of identity providers (IdPs) and mobile device management (MDM) tools, making certificate enrollment and management a mostly automated process.

With the right software, bring your own device (BYOD) devices can self-onboard using their Azure AD credentials to receive a certificate and 802.1X settings. For environments that use Intune or other MDM platforms, you can push out configuration profiles that instruct devices to auto-enroll themselves for certificates using an API.

Want to learn how to set up certificate-based 802.1X authentication (EAP-TLS) with Azure AD? We laid out a basic overview below. For the full documentation, check out our page on how to configure WPA2-Enterprise with Azure.

EAP-TLS vs. PEAP-MSCHAPv2 for Azure AD Authentication

With Azure AD and 802.1X, the deciding factor for security is the Extensible Authentication Protocol (EAP) method you choose.

Protected Extensible Authentication Protocol Microsoft-Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) requires users manually enter their domain credentials. From a security standpoint, this is problematic for several reasons. It is naturally vulnerable to credential theft and man-in-the-middle (MITM) attacks. Password expiration also makes for a poor user experience.

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is ideal for secure Wi-Fi. Rather than credentials, EAP-TLS utilizes digital certificates. Mutual authentication proves the identities of the client device and the server. Its cryptographically strong connection is far more secure than any password-based method.

Why Azure AD Has No Native RADIUS Server

802.1X authentication always needs a RADIUS server to sit between the network access point and the identity source, but Microsoft Azure AD (Entra ID) does not include one. Azure AD is a cloud identity provider, not a network authentication server, so it cannot directly answer the access request an access point sends during an 802.1X handshake.

This is also why on-premises Microsoft Network Policy Server (NPS) is not a clean fit for cloud-managed devices: NPS was built to authenticate against on-prem Active Directory and does not natively support device-based authentication for Azure AD-joined devices. Bridging the gap means deploying a RADIUS service that can talk to Entra ID directly. A cloud RADIUS server removes the on-prem NPS dependency entirely by communicating with your Azure AD at the time of authentication, which is the approach the next sections describe.

How to Use Certificates to Tie Network Security with Azure AD

The process is broken down into two phases: one-time enrollment and runtime authentication. We’ve provided a high-level overview of how you can set up certificate auto-enrollment for your Intune or other MDM devices.

• One-Time/Renewal: Configure your MDM platform with JoinNow Dynamic PKI services to send out configuration profiles directing managed devices to auto-enroll and auto-renew for a certificate and self-service for 802.1X.
• Ongoing Authentication: JoinNow Cloud RADIUS will authenticate the device for Wi-Fi access by directly communicating with your Azure AD.

Once the device requests Wi-Fi or VPN access, Cloud RADIUS will directly communicate with your Azure AD (or whatever cloud identity you have) to verify the user and authorize network access at the time of authentication. Now, a passwordless 802.1X system is tied directly with Azure AD.

A Quick Guide to Using Azure AD for 802.1X

We’ve constructed a quick guide on how to set up Azure AD as a single sign-on (SSO) for Certificate Enrollment and 802.1X Onboarding. Your end users can easily self-service for certificate-hardened 802.1X with their Azure credentials.

• Creating a SAML Application in Azure Portal
  • End-users can enter their credentials into the SAML app, which are then sent to and verified by Azure AD. Once Azure AD sends back attributes, the SAML app will share them with SecureW2 PKI to issue certificates.
• Testing the SAML Application
  • Add yourself as a user to test the SAML app for any If you go through the onboarding process with no issue, Azure AD and SecureW2 have successfully connected.
• Mapping Azure AD Attributes
  • This is where you can map out the attributes sent by Azure AD and encode them onto

Passwordless RADIUS Authentication with Azure AD

RADIUS is a standard protocol to accept authentication requests and to process those requests. If you use certificate-based Wi-Fi authentication (EAP-TLS) with Azure AD, you can set up Azure AD with any RADIUS server. While you may think that it’s not worth it to set up a PKI just for Wi-Fi, the growing risk of credential theft combined with the improvements in PKI technology have resulted in EAP-TLS becoming the industry standard form of Wi-Fi authentication.

SecureW2 provides the easy-to-use Dynamic PKI and Cloud RADIUS, giving organizations everything they need to set up certificate-backed EAP-TLS on their network and ditch passwords for good.

SecureW2 also grants access to industry-first technology that allows Cloud RADIUS to talk to any IDP to dynamically update your users and policies. It’s so easy to set up, and the average deployment time is often under an hour.

Using Cloud RADIUS also requires significantly less time and money for maintenance and upkeep than a traditional on-premises RADIUS server.

SecureW2 onboarding clients use Azure as a Wi-Fi SSO, except the credentials won’t be used for Wi-Fi authentication. Instead, they will be used to enroll for a Wi-Fi certificate, which will then be used for authentication. This provides a high level of flexibility with stronger overall cybersecurity. Certificates work with any RADIUS server and AA and protect your Azure AD credentials from over-the-air theft.

SecureW2 Can Make Azure Integration Easy

Legacy RADIUS deployments were built for a different era of networking. They weren’t designed for cloud identity, BYOD, MDMs or the kind of continuous identity validation modern networks require.

JoinNow Cloud RADIUS validates identities against your existing IdPs, such as Azure AD (Entra ID), and pairs with JoinNow Dynamic PKI so certificates reflect the current device posture for every authentication request.

SecureW2 Cloud RADIUS also lets you customize the policies assigned to users via our policy engine. So, no more expired certs.

Eliminate unauthorized access with industry-leading reliability and deployment options that support up to 99.999% availability.

If you’d like to learn more about how flexible Cloud RADIUS can be, reach out to us today for a free demo.

---

Frequently Asked Questions

Does Azure AD support 802.1X authentication?

Yes. Microsoft Entra ID (formerly Azure AD) supports 802.1X authentication, but not on its own. Because Azure AD is a cloud identity provider, it needs a RADIUS server to handle the 802.1X handshake. Once that RADIUS service is connected to Entra ID, you can authenticate either with synced credentials or, more securely, with digital certificates over EAP-TLS.

Does Azure AD have a built-in RADIUS server?

No. Azure AD does not include a native RADIUS server. To run 802.1X, you pair Entra ID with a separate RADIUS service. Organizations either stand up on-premises Microsoft Network Policy Server (NPS), which authenticates against on-prem Active Directory, or use a cloud RADIUS that talks directly to Azure AD and removes the on-prem dependency.

Can I use on-premises Windows NPS for 802.1X with Azure AD joined devices?

Only with limitations. NPS was designed to authenticate against on-premises Active Directory, and it does not natively support device-based authentication for Azure AD-joined devices. For cloud-managed and Azure AD joined fleets, a cloud RADIUS service that integrates directly with Entra ID is a cleaner fit than retrofitting NPS.

How do you deploy certificates to devices for 802.1X with Azure AD?

Certificates are pushed through your mobile device management (MDM) platform. For managed devices, you configure Intune or another MDM to send a configuration profile that auto-enrolls the device for a certificate using an enrollment protocol, then deploys the matching 802.1X Wi-Fi profile. For unmanaged or bring your own device (BYOD) endpoints, users self-enroll with their Azure AD credentials through an onboarding client.

What happens to 802.1X authentication if the revocation endpoint is unreachable?

Certificate-based 802.1X relies on the RADIUS server checking revocation status through a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). If the RADIUS server cannot reach the revocation endpoint, authentication can fail, so those endpoints need to be highly available and reachable from the RADIUS infrastructure. A managed cloud RADIUS handles revocation checking as part of the service.

Can I Use Azure AD Multi-Factor Authentication (MFA) With 802.1X?

It’s possible that your infrastructure may not support certificate-backed VPN authentication. Luckily, you can still use Azure AD MFA with certificates.

Many end-users complain that MFA is annoying to use when connecting to Wi-FI, especially if they’re students or faculty walking around campus. Certificates prevent end-users from having to enter their credentials every time they near a new Access Point. No matter where they are, their certificate will automatically connect them to Wi-Fi with no interruptions.

So the answer is yes, you use Azure AD credentials to enroll for certificates for 802.1X authentication. You can configure any form of Multi-Factor Authentication (MFA) to be used during the 802.1X certificate enrollment phase.