Want to learn the best practice for configuring Chromebooks with 802.1X authentication?

Sign up for a Webinar!

802.1x Without Active Directory

802.1X is the de facto gold standard that organizations should strive for when it comes to authentication; it’s safe, secure, and efficient, especially when combined with certificates. However, setting up 802.1X without the right tools can be a challenge depending on your network infrastructure.

Microsoft AD brings a difficult situation to the table because admins have a hard time transitioning to an all-cloud environment. Admins try to move to Microsoft Azure, Microsoft’s cloud service, but Azure AD does not work with the historical AD 802.1x environment (NPS, PEAP-MSCHAPv2, and AD CS). Due to this reason, when organizations try to move to Azure, their 802.1x authentication breaks.

Since Windows 802.1x environments only work with on-premise servers, it begs the question; how do you move away from Active Directory and migrate to an all-cloud 802.1x solution?

What Components Do You Need for 802.1X?

There are just a few components that are needed to make 802.1X work. Realistically, if you already have access points and some spare server space, you possess all the hardware needed to make secure wireless happen. In general, you’ll need:

  • Client / Supplicant
  • Switch / Access Point / Controller
  • RADIUS Server

Check out our solutions page for more information on 802.1X architecture.

Drawbacks of 802.1x With Active Directory

It’s no secret that Active Directory has some drawbacks. One such drawback is if your organization is not completely reliant on Microsoft products, you might run into some issues that can put your productivity on hold while trying to use Mac products with Microsoft AD. This forces you to stay in a Windows environment and limits your choices. These issues can turn costly in terms of time spent troubleshooting these problems.

In terms of flexibility, due to Active Directory’s Windows environment requirement, there is little to no support for other managed devices on the network, such as Jamf-supported devices. Being forced to stay in a Windows environment creates limitations for managed devices to connect to the network and can be a troublesome affair for admins to configure.

As previously mentioned, Active Directory needs to have an on-premise server. On-premise servers are expensive with high upfront costs and need an experienced IT team to manage and maintain the server. Not to mention the physical security needed to protect the server room access and protection against power outages. Along with these costs, Microsoft AD can be cumbersome to manage and lacks important management tools.

How to Do 802.1x Without Active Directory

The first step to using 802.1x without Active Directory is to move away from credential-based authentication to certificates. By moving to certificates, your RADIUS server will no longer need to directly talk to the IDP and will only need to host a Certificate Authority (CA) to validate users. Certificates give you the flexibility to use any IDP. Here is a list of alternatives to AD:

  • Google
  • Okta
  • Azure AD

Along with the flexibility of being compatible with any IDP, certificates offer more network security than credentials as credentials are highly susceptible to hacking attacks.

Does a RADIUS Server Require Active Directory?

In order for a RADIUS server to work, it needs a directory to verify who is allowed access to the network. Traditionally, AD was used as that directory, which has led many to believe you need AD to use a RADIUS server.

This is simply not the case anymore, as there are providers, like SecureW2 that can run a RADIUS server from the Cloud.

Why Use RADIUS without Active Directory?

While RADIUS servers were typically maintained on-premise, there is now rising popularity of cloud-based services is managed, off-site RADIUS services. This is because RADIUS in the cloud is much easier to manage, is cheaper, and simpler to use.

If you want to use AD with RADIUS, you’re essentially tethering yourself into an on-premise environment, which leaves you stuck with all the extra headaches of on-premise server management.

How to Do 802.1x with MDMs

Implementing a WPA2-Enterprise 802.1x network with certificate-based authentication (EAP-TLS) is the best way to achieve maximum security and the best ease of use for managed devices. By removing credentials and relying on certificates for authentication, you avoid the repercussions of passwords:

  • Easily hacked passwords.
  • Password reset rules.
  • Terrible authentication experience.

Certificates also identify who is on the network by assigning a name to each network connection. Investing in a PKI also enables SSL decryption, allowing you to guarantee that all users adhere to your organization’s restrictions and that no SSL-encrypted malware enters your network.

Let’s describe the flow for Jamf 802.1X EAP-TLS authentication without AD as an example. To efficiently enroll your managed devices for a certificate, the best option is to utilize a SCEP Gateway. Once a SCEP payload is sent out, devices do not need to be manually configured for certificates; they have enrolled automatically through the SCEP Gateway without requiring end-user interaction. Using SecureW2’s Managed Device Gateway APIs, you can easily enroll every Jamf-managed device with certificates.

For Microsoft Intune, the primary thing to keep in mind while configuring an Intune SCEP profile is that you must create a Trusted Certificate Profile for the devices you intend to use for the SCEP configuration. This trusted certificate profile helps in the deployment of the root CA or intermediate CA on the device. Furthermore, it also helps in establishing trust between the device and the issuing CA.

The API Token SCEP Integration is relatively vulnerable because it works on a shared secret and a SCEP URL. The shared secret is essentially a preshared key visible within the URL, making this method riskier than necessary. To combat this, we recommend using the Intune Third-party CA method because it checks the device’s authorization in Intune before distributing certificates, while the API token method does not.

SecureW2 Allows You to Move Away From AD and Perform 802.1x in the Cloud

SecureW2 provides everything and anything you need to issue and validate certificates. We can simplify integration because our PKI works with any IDP and allows you to use existing credentials to issue certificates. Our PKI and RADIUS can even integrate with your AD environment if need be.

Our #1 rated JoinNow onboarding software enrolls certs on devices, and API gateways distribute certificates to managed devices with no end-user interaction.

Conveniently, SecureW2 comes with certificate management software so that you can create, issue, and manage all your certificates in one place. Our Cloud RADIUS comes built-in at no additional cost to you and is pre-built for EAP-TLS, making the user experience seamless and simple.

You can check out our pricing here to see why organizations are making the switch today.

Learn about this author

Kainoa Lee

Kainoa is digital marketing specialist and a graduate of Central Washington University with a major in Marketing. As part of the marketing team his is focused on content, analytics and design . He is an accomplished athlete and won state championships in soccer.

802.1x Without Active Directory