How to Configure RADIUS without Active Directory (AD)
In order for a RADIUS server to work, it needs a directory to verify who is allowed access to the network. Microsoft’s Active Directory (AD) has served as one of the most popular directory services in the industry since its inception.
However, the industry is now moving away from on-premises infrastructure, opting instead to use the cloud which is causing many in the industry to find alternatives to using their existing on-premise AD Server.
Why Use RADIUS Without Active Directory (AD)?
AD is the most ubiquitous IDP and is used in conjunction with most RADIUS servers. In the past, RADIUS servers were typically maintained on-premise, but the rising popularity of cloud-based services has seen an increase in managed, off-site RADIUS services.
However, organizations with AD-domain environments are having trouble migrating to the cloud because there are a lot of roadblocks if you want to migrate away from your AD while continuing to support 802.1x.
Downsides of On-Prem Hardware
Cloud computing services are rapidly gaining market share due to their inherent convenience, price, and because on-site hardware services are becoming more dated. Modern end users and IT admins value both the convenience and versatility of cloud computing services and it’s quickly overtaking on-site servers.
As mentioned earlier, on-site servers usually come with a hefty price tag just to get hardware up and running. After an installation that takes significant time and money to set up, you will need a team of experts managing the server on a daily basis. All together, the time and cost for an on-site server represent an enormous burden on the resources of an organization, and almost always costs significantly more than a cloud service in the long term.
Active Directory Requires On-Prem Hardware
Since AD requires on-site hardware to run, that leaves Microsoft environments with a difficult obstacle if they want to pursue cloud services for their network. Many organizations are annoyed at the amount of hardware and resources needed to run an on-premise Active Directory.
Both RADIUS and AD are server roles and work with each other, but are sometimes run on separate servers. That usually means more cost on the organization by maintaining multiple servers. RADIUS and AD can be programmed to run on the same server computer, ostensibly saving organizations money by not needing more than one server. However, if that server computer is compromised or goes down, the whole network is disrupted. This is something that network admins simply don’t need to worry about with the cloud. And let’s be real, if the cloud does go down, throwing your cloud provider under the bus looks a whole lot better than your own server going down.
Configuring RADIUS Authentication on Windows without AD
Today, organizations don’t necessarily need AD for a directory because of the rise in SaaS companies offering directory instances in their software. Platforms like Okta, Cisco, and even Microsoft’s Azure AD provide documentation to configure RADIUS servers.
First, you will need to pick an Identity Provider (IDP) that has good SAML Application support. The most common we see out in the field are:
An IDP will need to be configured for RADIUS to work. For Windows environments without AD, you can create local groups and start adding users for authentication. SaaS platforms like Okta and Google Apps can also replace the roles of AD.
Choosing an Authentication Protocol
There are a few types of protocols that allow RADIUS authentication, but we’ll cover three: EAP-TTLS/PAP, PEAP-MSCHAPv2, and EAP-TLS.
EAP-TTLS/PAP and MSCHAPv2 are both credential-based protocols, using passwords logins to access the network. Passwords are notorious for their inability to protect against data breaches because passwords are easy to crack. Most data breaches happen by exploiting weak passwords.
PEAP-MSCHAPv2 is a Microsoft protocol that should provide better security than PAP, but it has a major vulnerability that also leaves it susceptible to man-in-the-middle attacks. Also, it can only really be used with Active Directory, so it’s not really an option for us here, which is why we see all cloud-environments using either EAP-TTLS/PAP or EAP-TLS.
RADIUS servers can also authenticate with digital certificates. EAP-TLS is a certificate-based authentication protocol touted for its improvements in security over others. Certificates offer far more security benefits because they’re encrypted, eliminating any concerns of over-the-air credential theft.
EAP-TLS is our recommended solution because it’s the most secure authentication protocol, and it will give you the most flexibility in what network infrastructure you can use on your network. In order to use EAP-TLS, you will need to run a Public Key Infrastructure (PKI), but this is actually pretty easy to set up now as there’s a lot of turnkey Managed PKI solutions today.
Configuring RADIUS with a SAML IDP and EAP-TLS
The best practice for configuring and implementing a RADIUS is with a certificate-based network environment. Certificates-based networks cannot be compromised by over-the-air credential theft and MITM attacks because certificates are virtually impossible to unlock.
Certificates can be locked onto devices so it can serve as the device’s identity. Instead of basing identification on passwords, certificates lists can be integrated and serve as the directory for network authentication. RADIUS configuration is also much easier with certificates. The configuration process can be broken down into 4 steps:
- Add Root and Intermediate certificates to Trust List
Trusted certificates authorized by IT are distributed to all network devices and to Trust Lists to ensure which certificates are valid and which devices can access your network.
- Configure RADIUS Server Certificate Validation (SCV)
SCV basically confirms that a device is connecting to the correct RADIUS server for authentication, eliminating over-the-air credential theft.
- Configure the Certificate Revocation List (CRL)
The CRL provides a list of certificates that have been revoked from the network, whether by an employee leaving or a device is lost. The list is automatically updated everyday.
- Setup the CRL
The CRL provides yet another form of security. Whenever a RADIUS needs to authenticate a device, it can look through all revoked certificates before approving the device.
Luckily, Cloud RADIUS comes set up with all of this out of the box, and relieves you of the need to manage your own on-site RADIUS server at just a fraction of the cost. Cloud RADIUS comes with Onboarding Software and a Managed PKI, making it the most secure RADIUS on the market. It’s also one of the most cost-effective solutions on the market too. Click here to learn more.
