Self-Managed RADIUS vs Cloud RADIUS Architecture
RADIUS servers, also known as AAA servers, have been a critical part of network authentication since they were first introduced in the 90’s. They increase the security of your Wi-Fi and VPN by allowing each user to authenticate with their own sets of credentials as opposed to sharing one set.
In the past, organizations mostly had to build and manage their own RADIUS servers – a practice that some have continued to this day. However, building and maintaining your own RADIUS in-house is often more complex and resource-consuming than organizations anticipate. It would be like your business constructing its own power plant just to provide power to itself. Why not leverage the energy provided by an existing power plant and focus on your own business instead?
We’ll compare the architecture of self-managed RADIUS to that of Cloud RADIUS so you can see for yourself the advantages of both options.
What is a Self-Managed RADIUS?
If you’re familiar with network infrastructure, you’ve probably already heard the term “on-premise” in regard to servers. How is an on-prem RADIUS server different from a self-managed one?
Self-managed and on-premise RADIUS servers aren’t necessarily synonymous terms, although there can be some overlap between them. A self-managed RADIUS is exactly what it sounds like: a RADIUS server that is built and managed internally instead of using a third-party RADIUS service.
On-premise RADIUS servers are those which are established physically on-site at your location. As you can imagine, these RADIUS servers are generally self-managed. Self-managed RADIUS servers don’t have to be on-premise, though.
Building a Self-Managed RADIUS Server
If your organization is planning to build its own RADIUS infrastructure, there are generally two ways you can go about it: building a cloud-facing architecture with on-premise components or a hub and spoke architecture in which you have a centralized location with surrounding locations pointing their infrastructure towards it.
The architecture varies slightly between these two different styles, so we’ll look at both and list the components you’ll need to make either one.
RADIUS Server Hub and Spoke Architecture
A hub and spoke architecture is shaped like its name. For the “hub,” you establish a central data center composed of your RADIUS servers and everything else you need for authentication and authorization purposes. If you’re doing certificate-based authentication (CBA), this central data center is where you’ll also establish the necessary components for a Public Key Infrastructure (PKI). In that scenario, you’d also build a Certificate Authority (CA) and, for added security, a Hardware Security Module (HSM). This data center syncs up with your Identity Provider (IDP) – in the above example, the IDP is Azure AD.
Additional regional locations will need to have infrastructure built facing towards the central data center – much like spokes on a wheel. For each of these “spokes,” you’ll need to build another RADIUS server and LDAP/identity server that point towards the “hub.”
It’s important to understand that there’s a difference between authentication and authorization, and that these steps can be completed at different locations based on how you establish your infrastructure. In authentication, a user is confirmed to be a legitimate user, and in authorization, the level of access that user needs is established. With the hub and spoke structure having both RADIUS and LDAP/Identity servers in each “spoke,” authentication and authorization can be performed at each location. If you were missing some part of the infrastructure at a regional location, such as the identity servers, you may do part of the process and then send the data to your “hub” for the authorization step.
Of course, this can cause latency issues, especially if you’re spread across distant geographical locations. If there are internet outages, parts of your organization may find themselves unable to access the network at all. Practically, both the authentication and authorization processes need to be completed in the same area, which is why you end up duplicating RADIUS servers and identity servers at each regional location.
On-Premise with Cloud-Facing Components RADIUS Architecture
Of the two types of self-managed RADIUS architectures, this one is arguably the more complicated because it involves taking components designed for the on-prem world and making them cloud-facing. The key issue to be concerned about is the security aspect, including constant security updates that need to be performed on cloud-facing systems. In this setup, you host the infrastructure on local data centers or cloud providers and leverage security tools like Intrusion Prevention Systems (IPS) to protect against external threats.
Often, this will require you to build what’s called a demilitarized zone, also known as a DMZ. It establishes an intermediate network and provides defense-in-depth capabilities that protect more sensitive servers such as PKI, HSMs, and Identity Infrastructure.
Inside the DMZ, you’ll have your load balancers, IPS, and your self-managed RADIUS servers. It’s imperative to ensure RADIUS authentication is done passwordless/certificate-based, so you’ll need to construct PKI/CAs and use HSMs. You’ll also build one other component: your AD/LDAP identity servers which sync with your cloud IDP since most RADIUS servers designed for on-prem do not natively converse with cloud IDPs.
Unlike the hub and spoke architecture, this may not need to be replicated at every single location your organization has; however, this approach is still best used on a regional basis to deal with latency concerns. If you need to have your RADIUS span multiple time zones, countries, or continents, this may not be a scalable architecture.
It’s easy to see how this can quickly get tedious, time-consuming, and expensive, especially if your company has numerous offices located multi-regionally and internationally. However, both types of architecture can be excessively difficult to construct, especially if you don’t have any staff with significant RADIUS experience.
Fortunately, there is an alternative: a managed Cloud RADIUS.
Why Use a Managed Cloud RADIUS?
The alternative to building and managing your own RADIUS is to use a RADIUS-as-a-service (RaaS) or managed RADIUS option. Like the terms “self-managed RADIUS” and “on-premise RADIUS,” RaaS and managed RADIUS are similar but not exactly the same.
RaaS generally means you’ll have a pre-built RADIUS server to use, but the amount of support and configuration done for you may vary. On the other hand, a managed RADIUS provides more comprehensive support before and after deployment than a RaaS might. An example of a managed RADIUS is our Cloud RADIUS, which is a powerful cloud-native RADIUS server with a knowledgeable team of engineers to back it up.
Managed RADIUS servers are significantly more straightforward than setting up your own self-managed one. While you’ll still need to configure some infrastructural elements on your own, such as your IDP, you’re saved the time that would otherwise be spent building and maintaining your own RADIUS. Furthermore, with a service like Cloud RADIUS, which is hosted in the cloud, you don’t need to replicate the infrastructure at every single one of your locations. You can use one single RADIUS server to authenticate all your offices.
Another thing you won’t need to worry about is constantly updating your RADIUS architecture to support new technological advances, such as Change of Authorization or RadSec. RADIUS services take it upon themselves to provide servers that are in keeping with modern standards. Cloud RADIUS, for example, regularly adds new features to protect organizations from cyber threats.
If you decide to utilize certificate-based authentication (CBA) within your organization, Cloud RADIUS can integrate with either an existing CA or you can use our managed PKI service, JoinNow Connector PKI.
Cloud RADIUS Architecture
Your network’s architecture looks a bit different when you opt for Cloud RADIUS and other SecureW2 solutions. Of course, the source of truth will still be your IDP.
Cloud RADIUS exists outside of your own infrastructure but integrates with it. With Identity Lookup, Cloud RADIUS will communicate with your IDP at the time of authentication to ensure the most current network policies are applied to each user and device.
If you use JoinNow Connector PKI, a bit more goes into the architecture. You’ll have our PKI services to create certificates, which are presented to Cloud RADIUS for authentication instead of passwords. If your organization uses an MDM such as Intune or Jamf, certificates will be issued to your managed devices through a gateway API such as SCEP or WSTEP. With unmanaged devices/BYODs, certificates are instead issued through a dissolvable, self-service client called JoinNow MultiOS.
Deploying Cloud RADIUS
Deployment of a self-managed RADIUS can take a lot of time. The exact amount can vary based on the availability of the components you need, the knowledge of your IT staff, and the possibility of needing to hire personnel with RADIUS experience.
You can cut out this deployment time entirely with Cloud RADIUS. In fact, with the right preparation, Cloud RADIUS can even be deployed in a single click.
Cloud RADIUS: the Security of RADIUS Authentication without the Complicated Self-Managed Architecture
RADIUS security is integral to those looking to build 802.1X networks or those simply looking to take the next step in improving their network security. Building it yourself, however, is a massive undertaking that is costly in terms of time, effort, and money.
A managed service like Cloud RADIUS can save you that time and effort – and even money, as well. You won’t need to hire personnel specifically for maintaining the RADIUS server, and its built-in vendor-neutrality means it will integrate with your existing infrastructure. Since it’s an already-established RADIUS, Cloud RADIUS can also be deployed much more quickly. Many of our customers can deploy it within hours.
See how easy Cloud RADIUS can be deployed yourself. Schedule a demo with us and our team will be happy to show you how it works.
