RADIUS for Universities

University environments present challenges for RADIUS system design. Every hour, on the hour, thousands of students close their laptops, move to a different location, and open them again. This unique environment requires a unique infrastructure to support it.

Every hour, on the hour, thousands of university students need to be authenticated, and their thousands of laptops need to be assigned IP addresses. All of these students must get on the network quickly and efficiently, otherwise the help desk will be flooded with complaints. This process becomes even more challenging when, as is commonly the case, a university has multiple campuses in different locations, but authentication servers are only provisioned at a central location.

At Network RADIUS, we have created a standard RADIUS infrastructure for universities and colleges. This infrastructure has been deployed at multiple sites, where it has proven to be both fast, and stable.

In general, we see university networks having the following unique characteristics:

• Large numbers of authentication requests in very short time frame. i.e. At the start of each new class period.

• The same people reauthenticating several times a day as they move from class to class throughout the campus.

• Generally Active Directory or LDAP are used as the identity store rather than in an SQL database

• Authentication is done via EAP (Extensible Authentication Protocol) rather than simple passwords, as with ISPs.

• There are often multiple satellite locations, but with only a single identity store at the main campus

• There is no need to transmit ongoing session information after authentication, such as accounting data for billing. Once a user has been authenticated, there is usually no additional RADIUS traffic for the user’s session.

University environments tend to have intermittent spikes of authentication requests, with most of the authentication requests coming from the same students authenticating multiple times throughout the day.

In this article, we outline a “best practices” design blueprint for universities. This design has been used successfully world-wide, at multiple universities. The following steps outline our approach.

1. Use “fast reconnect” to speed up repeat authentication requests

The use of TLS session tickets for “fast re-authentication” or “fast reconnect” will yield the most significant performance improvements.

In most cases, an initial authentication attempt will result in a call to Active Directory. While Active Directory is widely used due to its capabilities and user interface, it is not the fastest database around. Our tests indicate that most Active Directory systems top out at a few hundred requests per second, for the kind of queries needed by RADIUS.

When students move around campus throughout the day, their laptops reauthenticate many, many times each day. A straightforward approach would be to just query Active Directory for each reauthentication. However, that approach results in tens of thousands of queries to Active Directory each hour. Even worse, those queries are performed in a five to ten-minute time window. A normal Active Directory installation just cannot keep up with the load.

Also, because universities tend to use EAP (Extensible Authentication Protocol) for authentication, there is a handshake process to establish a TLS connection, share and check certificates etc. This is just another step that makes the authentication process take a longer period of time.

We can come up with a better solution by realizing that the student’s status is not likely to change over the course of a day. Therefore, it is not necessary to verify the students credentials each time they reauthenticate. This knowledge helps us to create a much more efficient solution.

We can minimize the load on Active Directory by *enabling the TLS “fast reconnect” feature. At a high level, this feature works as follows.

The first time a student logs into the network, their credentials are authenticated through Active Directory and a TLS certificate check is performed. Once they have been authenticated, the server sends a session ticket to the user’s device which it caches. When the student reconnects a short time later with the same device, it sends the session ticket as proof of identity. This session ticket can be used to authenticate the user, and means that we no longer need to query Active Directory. Only students signing in for the first time in a day need to be checked against Active Directory.

After the student authenticates for the first time, the RADIUS server sends a small session ticket which serves as proof of identity. This session ticket is cached on the student’s laptop for a few hours.

Session tickets bypass repeat requests by the same student. This feature dramatically improves performance by reducing the volume of authentication requests to Active Directory.

The end result is faster network access for everyone. In one client location, Active Directory, which had previously been struggling with authenticating tens of thousands of users every hour, was now freed up to handle only the newly arriving students. This change dropped the load on Active Directory by over 100 times!

2. Improve performance at satellite campuses with multiple FreeRADIUS servers

Students at satellite campuses should be able to get onto the network just as quickly as anyone at the central campus. However, this performance can be hard to achieve when each authentication request has to travel to and from servers at the main campus, and when there aren’t enough servers to efficiently manage the load every time users move on to their next class.

Many commercial RADIUS products have pricing models which make multiple RADIUS servers prohibitively expensive. This financial burden often results in organizations deploying fewer servers than they actually need in an effort to save costs.

However, because FreeRADIUS is well… free, we are able to deploy RADIUS servers at each campus location without the need to pay licensing fees for each additional server. With more servers sharing the traffic load, and with minimized travel time for requests, we are able to provide equal service for students, regardless of their location that day.

3. Build resilience in the network through centralized data store

Multiple FreeRADIUS servers at various satellite locations will solve key performance issues, but such a distributed system can also introduce other potential complexities.

For universities, we recommend having a FreeRADIUS server at the central campus. This system can be the canonical repository of information for all the other servers.The satellite servers then do not store any unique information. They are instead created via templates or VM clones. Any site-local data such as log files are sent back to the central site for processing and storage.

This centralized configuration makes the network more resilient to technical failures. If a satellite server develops a problem or goes down completely, it can be quickly discarded and a new one spun up from the central system in a matter of minutes. It also makes it trivial to create additional servers on short notice in the case of special events, when a campus is hosting more users than usual.

RADIUS servers at satellite locations are clones of the server at the main campus. A RADIUS server at each location improves performance by reducing roundtrip time for authentication requests. By storing all the data in the main location, the satellite servers can be easily replaced on short notice, without worrying about preserving data

These design principles are based on best practices developed over the last twenty years at NetworkRADIUS. We have seen pretty much every variation of FreeRADIUS deployments out there. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.

Contact us today at sales@networkradius.com, or via our toll-free number, +1 (844) 588-1812.