Everything You Need to Know About RADIUS Server Authentication

A RADIUS server could be the missing piece of the puzzle for your organization’s network authentication. Here’s everything you need to know about RADIUS servers.

Every time a user or device attempts to access a protected resource, they need to prove they have the right to access that resource through the process of authentication. Wired and wireless networks are the same; they’re more secure when authentication is used to verify exactly who’s accessing them. For that purpose, new authentication protocols are being introduced and old ones are improved constantly, such as the RADIUS protocol.

A RADIUS (Remote Authentication Dial-In User Service) Server is a type of authentication server that functions like a virtual guard. This type of network access server is seeing an increasing amount of use in industries and organizations internationally due its triple function of authentication, authorization, and accounting.

In this article, we’ll explain everything you need to understand about what a RADIUS server is, what it does, how it works, and how it can benefit your wired and wireless security.

What is a RADIUS Server?

RADIUS is an acronym that stands for Remote Authentication Dial-In User Service. Sometimes, a RADIUS server is also referred to as an AAA server, which stands for Authentication, Authorization, and Accounting.

In a nutshell, a RADIUS server is a network access server. It grants or denies users and devices access to wired or wireless networks and VPNs. If you’re unfamiliar with the concept entirely, the easiest way to imagine where a RADIUS server fits into your network is to picture a bouncer at the door to a club. When someone tries to access the network, it confirms they should have access first by checking their credentials or certificate through the RADIUS authentication process.

Brief History of the RADIUS Protocol

The concept of RADIUS networking was born in the early 90’s, during the internet’s early days. Merit Network, a nonprofit organization that provides quality networking services to various entities, requested a solution that condensed their authentication, authorization, and accounting systems.

In response, another company called Livingston Enterprises drafted the first version of the RADIUS protocol or Remote Authentication Dial-In User Service. Initially, the RADIUS protocol only supported credential-based authentication, but it has changed over time to support authentication methods such as digital certificates. This keeps it relevant within the scope of the ever-changing cybersecurity industry. Today, it is part of IEEE 802 and Internet Engineering Task Force (IETF) standards.

Components of RADIUS Authentication

RADIUS authentication requires a few things in order to occur:

  • A RADIUS server
  • A directory of user/device information (also called an Identity Provider or IDP) for the RADIUS to reference
  • A RADIUS Client (a network access server that sends access requests to the RADIUS)

RADIUS servers are so efficient at controlling network access because they don’t perform too many tasks at once. Their focus is on authentication, authorization, and accounting – not storing user information in advance. This is why it needs a directory to reference once it receives an access request. Commonly, an Identity Provider such as Active Directory, Azure AD/Entra ID, Google, or Okta is used to verify the information behind each access request.

What is the Difference Between RADIUS Clients and RADIUS Servers?

A RADIUS client is the device transmitting access request messages to the RADIUS server. It’s important to note that the RADIUS client is not the end-user’s individual device. The term RADIUS client specifically refers to a network access server, which can mean wireless access points, VPNs, or an 802.1X switch.

One way to imagine a RADIUS client and RADIUS server is to picture the way mail is sent. You, as the writer of a letter, are a user. The mail truck is the RADIUS client, delivering your letter to the post office. The post office is the RADIUS server, verifying the letter is formatted appropriately (authenticated).

Authentication, Authorization, & Accounting in RADIUS Servers

A RADIUS is often called an AAA server, which stands for authentication, authorization, and accounting. Each of these functions is different from each other and has its own security uses.

Authentication

We’ve established that RADIUS servers can take user credentials or certificates and process access request messages. This is called authentication. During the authentication process, the RADIUS server will reply to an access request message with either an access accept message or access reject message.

Authorization

Authorization is a bit different from authentication. Authentication determines simply whether or not someone should be allowed access to the remote network. The level of authorization someone has determines exactly how much access they have and to which specific resources on the network.

For example, someone working in an HR department for an organization may have access to different resources from someone working in the Finance department. This means that they have differing levels of authorization.

We often see our customers use the RADIUS networking protocol to segment categories of users into their own unique VLANs. By doing so, they can ensure various types of users have their own strict requirements, such as limiting bandwidth for particular users or preventing access to certain resources.

Accounting

The job isn’t complete after the RADIUS server authenticates a device or user. This is where accounting comes into play.

Although it will vary by the RADIUS provider in question and what the RADIUS server supports, RADIUS servers generally produce records of each authentication. These records can be used for a variety of purposes, but typically are used for monitoring access and for audits.

As an example, consider a Cloud RADIUS event log. Cloud RADIUS event logs contain extremely detailed information tied to the device’s certificate, such as the region the device authenticated from, the time of authentication, the MAC address of the device, and more. Administrators can also use this information to troubleshoot when there are connectivity issues.

Image Alt

How does RADIUS Server authentication Work? 

Imagining a RADIUS server as a guard at a door gives you a high-level overview of how RADIUS authentication works. But it’s a bit more complicated than that, and there are steps involved in the process depending on the authentication protocol your network supports.

Image Alt

In our experience, three common wireless authentication protocols we see are the following:

  • Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2)
  • Extensible Authentication Protocol-Tunneled Transport Layer Security-Password Authentication Protocol (EAP-TTLS/PAP)
  • Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)

Each one dictates a different set of standards for the authentication process, including what the user/device provides to verify their identity. You can break down authentication with these protocols into two different categories: authentication via credentials (username/password) and authentication via digital certificates (passwordless).

Credential-Based RADIUS Authentication

A RADIUS server doesn’t store login information. It needs a directory of some kind of check the credentials and policies related to those credentials at the time of authentication. Generally, it follows these steps:

  1. The end-user/device submits an authentication request to the NAS including their username and password.
  2. The NAS transmits this request to the RADIUS server.
  3. The RADIUS server verifies that the user’s username and password exist in the directory – commonly an Identity Provider.
  4. The RADIUS returns an ACCESS_ACCEPT or ACCESS_REJECT message to the NAS based on the results of that verification.

Certificate-Based RADIUS Authentication

Image Alt

RADIUS authentication with certificates (EAP-TLS) looks different. Digital certificates contain quite a bit more information in their templates than a typical username/password does, giving the RADIUS server and any administrator reviewing records like RADIUS event logs a lot more context.

The process looks like this:

  1. The device presents its certificate to the NAS, which forwards the request to the RADIUS server.
  2. The RADIUS server starts by checking that the certificate isn’t expired.
  3. Next, the RADIUS server checks the Certificate Revocation List (CRL) to determine that the certificate hasn’t been revoked.
  4. If the certificate hasn’t been revoked, the RADIUS can confirm the user’s status in your directory.

Cloud RADIUS was designed to integrate with all major SAML Identity Providers. At the time of authentication, it can actively communicate with Azure AD/Entra ID, Google, Okta, or OneLogin to determine that a user still exists in the directory and which network access policies should be applied to them. With Real-Time Intelligence, Cloud RADIUS can even apply policy updates immediately. This means that, even if someone is removed from the organization in the middle of the day, their network access can be revoked once you update the information in your directory.

How Does RADIUS work in Wi-Fi Authentication?

Image Alt

A RADIUS server can be used to authenticate users and devices to networking resources. We see them most often used for wired and wireless authentication, but some organizations also use RADIUS server authentication to secure access to Virtual Private Networks (VPNs).

In Wi-Fi authentication, the process varies depending on the protocol you’re using. We generally recommend EAP-TLS, as it is more secure than alternatives like PEAP-MSCHAPv2, which rely on credentials that can be easily stolen or shared. In EAP-TLS, the user authenticates to the RADIUS server with a certificate containing a detailed template with their information.

However, the RADIUS server also verifies itself through a process called server certificate validation, in which it proves it is the correct authentication server by furnishing its own certificate to the device. This mutual authentication is an integral part of EAP-TLS and what makes it so ironclad.

How Does a RADIUS Server Work for VPN Authentication?

Organizations with a remote workforce often look to VPNs to allow employees to securely access company resources from outside of the office. RADIUS authentication tends to be used for wired and wireless network authentication, but it can easily be used for VPN authentication, as well. The process is similar to what happens for Wi-Fi authentication with some caveats.

If you’re looking to do certificate-based RADIUS authentication with your VPN, you’ll need to verify that your VPN supports both certificate-based authentication and RADIUS authentication.

Even if your VPN doesn’t technically support EAP-TLS, however, Cloud RADIUS can still often integrate with for more secure VPN authentication. In that case, we can use an Azure MFA license with Cloud RADIUS to perform a lookup with a SAML Identity Provider such as Azure AD/Entra ID. This will trigger the Microsoft Authenticator App to authenticate the session.

Alternatively, many VPNs support certificate-based authentication but not necessarily with the addition of RADIUS. In that case, you can leverage SecureW2’s managed PKI and integrate it with your firewalls instead.

On-Premise RADIUS Server or Cloud-Based RADIUS Server?

Some organizations want to add a RADIUS server to their security, but are uncertain whether they should build and manager their own on-premise or use a cloud-based, managed RADIUS server like Cloud RADIUS. There are advantages to either method, and it’s important to consider these before making your decision.

On-Premise RADIUS Server 

Image Alt

The main benefit offered by an on-premise RADIUS server is that your organization has total control over everything that goes into it. For some organizations with IT teams that have experience with RADIUS servers, this is an enticing benefit.

However, there are many drawbacks to consider, as well, when building and managing your own RADIUS architecture.

To start with, consider the cost. Although you could theoretically put the RADIUS on any any server where you have sufficient space, many organizations look at building a specific physical server for this purpose. Aside from hardware, that means it needs sufficient, secure space in your office somewhere.

This cost increases exponentially if you have multiple office locations. Suddenly, you’re not just establishing one RADIUS – you’re setting up one for each individual location.

There’s also the cost of maintaining a server. Regular patches and maintenance need to be performed, which requires time and effort from your IT team. This time and effort grows if they have little experience with RADIUS servers. Misconfiguration, which is possible with less experienced teams, can cause major security issues and setbacks.

Setting aside staffing and hardware requirements, there’s also the possibility of localized disasters temporarily taking your RADIUS down. Fires, earthquakes, and other types of inclement weather can potentially damage your RADIUS server or take it offline temporarily. This can prevent employees from connecting to your network, dropping productivity and increasing frustrations.

Cloud-Based Managed RADIUS Service

A cloud-based and managed RADIUS server counters all the points we addressed in the previous section.

The same cost considerations no longer apply. You don’t need to build the RADIUS yourself or manage maintenance and patching. All of those things are done for you, allowing you to deploy the security of RADIUS authentication quickly.

Furthermore, since it’s native to the cloud, you don’t need to duplicate the RADIUS at every single office location. This makes solutions like Cloud RADIUS infinitely scalable. With server locations globally available, Cloud RADIUS also enjoys low latency – faster authentication leads to faster connections.

You also no longer need to address physical security. Your IT team doesn’t need to add another server and the space for it. While this might be a small consideration, it’s still an important point, especially when you factor in the redundancy of a Cloud RADIUS service that isn’t taken down by local conditions.

Integrating Cloud RADIUS with Your Identity Infrastructure

Image Alt

Cloud RADIUS was designed to integrate with your current infrastructure so you don’t have to make any major changes or upgrades. It can integrate with all major SAML Identity Providers and even Microsoft’s Active Directory.

The configuration process for this varies depending on which IDP you want to integrate with. If you’re doing EAP-TLS, however, the general infrastructure you need to set up with as follows:

  • Tie your PKI to your IDP.
  • Tie the Cloud RADIUS infrastructure to your IDP.
  • Tie your Device Management platform to the the SecureW2 PKI if you’re leveraging our PKI services.

We have more detailed configuration guides that provide the configuration steps. If you’d like to learn more about integrating Cloud RADIUS with Azure AD/Entra ID, Okta, or Google Workspace, you can click on any of the links provided here.

Deploy RADIUS Security in Minutes with Cloud RADIUS 

RADIUS security doesn’t need to be difficult to deploy, costly, and a headache to maintain. With Cloud RADIUS, you can leverage the strength of RADIUS server authentication quickly at all of your locations.

Plus, because it’s a managed service, you can rely on the expertise of our knowledgeable engineers. We have experience integrating with all kinds of infrastructure and deploying as quickly as you need us to. We’re an award-winning platform for a reason.

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

Check PricingFree Demo
Hero Background
Free DemoCheck Pricing
CTA Background