News and articles

While MS-CHAP has been used since 1998, it uses DES encryption which was deprecated in 2002. Attacks on MS-CHAP itself have been known since 2006, and those attacks have only gotten better over time. New attacks show that it is possible to crack most user-generated passwords in milliseconds, using only commodity hardware such as a laptop or desktop PC.

As we’ve previously discussed, there are several insecure elements in RADIUS. We are currently working in the IETF (Internet Engineering Task Force) to close those gaps and improve security for everyone. This article outlines some of the current shortcomings of RADIUS, best practices for mitigating against them, and a roadmap for how these vulnerabilities will be addressed within the RADIUS standard.

As the most popular RADIUS server in the world, FreeRADIUS is used by many hardware vendors. They ship their products with FreeRADIUS embedded as an embedded or “OEM” product. It is common for them to need some additional features or some customizations which are not part of the core FreeRADIUS functionality.

There is a lot of advice out there that email addresses are not identifiers. Even Internet2 has a document explaining why email is not an appropriate user identifier.

What does this mean for RADIUS, especially since RFC 7542 allows using email addresses as identifiers? Speaking as the author of RFC 7542, I think I can help you.

We have been involved in the Internet Engineering Task Force (IETF) for a few decades now. During that time, we have written many of the RADIUS standards. We are still involved in the standards process, and this post explains how the new standards will affect you.

RADIUS has a problem. The name of the problem is MD5. The MD5 hash algorithm was defined in 1991, and was used in RADIUS in 1993. However, MD5 is no longer secure. It is a bit of a miracle that RADIUS is still safe to use, even though it is using 30 year-old cryptographic primitives!

It’s time for us to fix RADIUS.

An essential part of good network design is to plan for failures. In a RADIUS ecosystem, one major requirement is that clients can always connect to a RADIUS server, and that the system can continue to operate even after the loss of one or more RADIUS servers. This article walks through some good and bad fail-over network designs.

The promise of cloud hosted infrastructure sounds tempting. Someone else manages your database, you pay only for what you need, and the database can scale up with your business as it grows. However, the pricing for cloud hosted databases is optimized for non-RADIUS use cases which can result in surprisingly high operational costs when used as part of a RADIUS ecosystem.

Database design is often overlooked as a critical element of a RADIUS ecosystem. In practice, when we work with our clients, we usually spend the bulk of our time optimizing the database architecture. Our time spent on FreeRADIUS is small in comparison. Why? Because the difference between a fast, reliable RADIUS server and a slow, unstable one, is almost always the database.

Not all RADIUS systems are the same, and the system architecture can vary wildly. For example, a network design which works well for 10,000 users will likely not work well for 10,000,000 users. It can be difficult to just “scale up” a RADIUS system. In most situations, the entire system architecture has to change.

In many environments, the same group of users will authenticate to the wifi network multiple times a day. TLS session tickets help to streamline this process by doing a full authentication only once a day, rather than every single time users reconnect to the network.

A common question for people installing the server is “what are the hardware requirements for FreeRADIUS?” The answer is both simpler, and more complex than you would think.

While Active Directory is widely used, it has still uses insecure protocols such as NTLM. The important question many people ask is “Does turning off NTLM increase security”?

RADIUS has used MD5 for security for almost thirty years. It is time to use a modern alternative: SRADIUS!

RADIUS is almost thirty years old, and uses cryptography based on MD5. Given that MD5 has been broken for over a decade, what are the implications for RADIUS? Why is RADIUS still using MD5?

ISPs and telecoms are often legally required to keep user accounting data for long periods of time. However, keeping these records can result in enormous databases which then affect the performance of your RADIUS system. There are ways of optimizing the database so that you can keep high performance while maintaining years of accounting data.

A common misconception is that PAP is less secure than other authentication protocols such as CHAP, MS-CHAP, or EAP-MSCHAP(v2). This perception arises because of a misunderstanding of how PAP is actually used.. In fact, PAP is often the most secure authentication protocol option available, and it’s what we usually recommend people use.

One of the most common questions about RADIUS security asks “Is PAP secure?” The usual answer is “no”, which is (in our opinion) seriously misleading. A better answer is “Here’s a comparison of PAP and CHAP, so that you can make an informed decision for yourself”. The end result? It may not be what you think!

One-time passwords (OTP) and multi-factor authentication (MFA) are important mechanisms used to improve security. Both these strategies can combine the username and password credentials with a one-time token as part of the sign-in process. The one-time token is usually supplied through an authentication app, or a small separate piece of hardware. In network security, using a one-time token is common practice for activites such as signing into private networks through VPN.

While one-time passwords are useful, the authentication method that is used to transmit the user’s credentials may not be compatible with the use of OTP.

Choosing an authentication protocol is one of the most important decisions when designing a RADIUS ecosystem.

There are a variety of authentication protocols to choose from, each with their own set of advantages, disadvantages, and constraints. In general, we recommend using PAP whenever possible. It is compatible with all known back-end databases, and it has no known security issues.

This article outlines the most common authentication protocols, how they work, and the implications of using them.

If you’re just getting started with FreeRADIUS, it can sometimes seem overwhelming when you run into problems. To the beginner, FreeRADIUS looks complex, but the debug troubleshooting information help to manage that complexity. In fact, your FreeRADIUS system is surprisingly straightforward if you know how to interpret the debug information.

This article will cover the most common error messages you are likely to encounter, and what to do about them.

If you are encountering performance issues with FreeRADIUS, the first thought is usually to blame FreeRADIUS. In fact, it’s always the database which is the source of a system slowdown. Well, maybe not always, but 99 times out of a 100, it’s the database.

The final step to configuring EAP for FreeRADIUS is to add the CA (Certificate Authority) to every client machine that performs EAP authentication.

As part of the process of configuring EAP for FreeRADIUS, you will need to test whether or not it works. If you prefer to use a command line tool rather than clicking through windows, this article walks through the steps for testing your EAP configuration.

Once the initial EAP testing has been performed, it is time to create the real certificates to use in your production network. These certificates will be configured on the end hosts that will be doing PEAP, TTLS, or EAP-TLS authentication.

If you have followed the steps for configuring EAP and are encountering problems, there are only a few things that go wrong. This article goes through the most common issues and how to fix them.

Once FreeRADIUS has been configured to use PAP, it is straightforward to configure the server to use EAP for authentication. This article will walk through all the necessary steps.

The FreeRADIUS Auth-Type attribute is often misunderstood and misused. There are actually very few situations where this attribute should be manipulated at all.

In many network configurations, there will be some transactions for which the RADIUS server will not perform the authentication itself, but simply pass credentials to a third party system and rely on the pass/fail response it gets from that system. Unfortunately, not all of these authentication systems work with all password storage formats. In these scenarios, it is important to realize that the incompatibility is between the authentication system and the password format, not the RADIUS system.

The first step to getting any authentication working in FreeRADIUS is to configure PAP (Password Authentication Protocol), or clear-text passwords. Even though most deployments will end up using additional authentication protocols, PAP is the simplest and easiest to configure, which makes it the perfect place to start. And as we will see, once PAP is configured, many other authentication protocols become simple, too.

Active Directory is widely used in the Enterprise and University systems. This article describes how to connect FreeRADIUS with Active Directory.

Virtual servers provide a powerful way to define unique policies for different traffic sources. When policy rules for each traffic source are defined in their own separate configuration file, it’s a lot simpler to define them, understand them, and debug them.

After an administrator installs FreeRADIUS for the first time, the big question is “Now what?”. Most sites need complex policies, interactions with databases, and logging. Yet the documentation for the server doesn’t give detailed instructions for how to configure the server for your particular location. As a result, many administrators are left wandering around the configuration files and documentation, wondering what to do next.

In order for RADIUS authentication to work, user passwords need to be stored in a format that is understood by the authentication protocol used by the client. Unfortunately, not all protocols work with all password storage formats. This can be especially problematic with platforms that use proprietary formats or protocols.

You can spend as much time as you want securing your RADIUS infrastructure and the rest of your network. But are you really secure?

In this article, we show just how easy it is to convince supplicants to send user credentials such as names and passwords to pretty much anyone. Ouch!

The root cause for both messages is the same, and is unambiguous: The shared secret on the RADIUS server and the NAS are not the same.

However, there can be some confusion because, depending on what information RADIUS receives in the packet header, you will see either the error message or the warning.

Your network can go down for really simple reasons.

A junior system admin might inadvertently type the wrong thing into a command line, or a minor upgrade can break some obscure dependency between libraries resulting in a cascading set of errors that bring the network down. When your infrastructure stops working, (and it will, you just don’t know when), it is critical to fix it quickly.

If you live in an earthquake zone, it’s important to engineer buildings to survive an earthquake. You don’t know when an earthquake will happen, or where exactly, or how big it’s going to be, but you know that it will happen at some point during the lifetime of the building. And the consequences of not earthquake proofing can be deadly.

The same goes for your critical network infrastructure. At some point, some part of your network will go down. The consequences are not usually deadly, but it can feel that way when it’s happening to you.

We see a lot of questions on the FreeRADIUS mailing list and from our clients that boil down to “RADIUS isn’t working. Can you tell me why?”. Most of the time, the problem isn’t with RADIUS itself, it is with the supporting infrastructure, or with less than ideal network administration practices. Many of these issues aren’t necessarily self-evident so we wanted to outline the most common mistakes and tell you how to avoid them.

We are happy to announce that FreeRADIUS 3 is now fully compliant with the base DHCP standards. Previous versions supported the base DORA exchange, but lacked some features such as Decline packets.

With greater flexibility and performance that is as fast or faster than the ISC DHCP server, FreeRADIUS is now a compelling option if you find yourself limited by your current implementation.

As part of our contributions to the FreeRADIUS community, Network RADIUS took on the task of overhauling its DHCP support. The result is the same highly flexible and configurable DHCP server, but now easier to configure and outperforms both ISC and Kea DHCP in most common scenarios. And it’s available now, in FreeRADIUS 3.0.22

The acronym AAA stands for “Authentication, Authorization, and Accounting”. It defines an architecture which authenticates and grants authorization to users and, and afterwards accounts for their activity. When AAA is not used, the architecture is described as “open”, where anyone can gain access and do anything, without any tracking.

Like any system, FreeRADIUS provides error messages to inform administrators of problems within the FreeRADIUS server itself. Sometimes however, error messages that are logged by FreeRADIUS are actually reporting an indication that something is wrong with one of the connected systems. A common cause of some of these errors is an unexpectedly slow database.

Many ISP networks have Authentication and Accounting handled by the same databases. This configuration works for many situations, especially small and low-load systems. There are times, however, when it is beneficial to separate the functions of Authentication and Accounting. Doing so can increase performance, and scalability.

When an ISP has RADIUS servers across multiple sites, new attacks are possible. Users can share account information with their friends, who can then log in separately to each site. If the RADIUS system design does not take this problem into account, users can defraud the ISP of significant revenue.

Some organizations and ISPs can use a central RADIUS service for all of their RADIUS needs. This configuration is possible when there are a small number of users, or system load is low. However, when there are a large number of users spread across a wide geographic region, it may be beneficial to use a multi-site approach. As with all solutions, this approach has benefits and costs.

More than almost any other business, Internet Service Providers (ISPs) need to provide their customers with fast, reliable access to their network. Any downtime can be catastrophic to their business. Slow connection speeds will drive customers away to other providers. This means that ISPs need to ensure that their network has several levels of redundancy in order to provide stable service at all times.

The short answer is Yes, Active Directory is compatible with FreeRADIUS. However, there are some constraints and implications for the rest of the system.

Like any technology choice, Active Directory has advantages and disadvantages, as well as consequences for how other network components need to be set up. This article provides an overview of these considerations at a high level and provides pointers to more detailed how-to guides.

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.

In order to create more secure systems, standards such as FIPS-140 2 are being more widely used. The FIPS standard provides for limits on which cryptographic protocols can be used, along with limits on the way that those protocols can be used. The standard also provides a process for validating and certifying software implementations.

The current Covid-19 crisis has created an unprecedented situation for businesses. More people are working remotely than ever before, in order to maintain corporate productivity in the face of this crisis. This remote access applies to Enterprises, Government agencies, Universities, and every other type of business.

Even though clients may prefer to configure their own system, some clients are unsure of how to configure a RADIUS server. Although the process can be complex, clients can learn how to setup a RADIUS server themselves. Alternatively, our team of experts is happy to set up a RADIUS configuration for any business.

We were called in to help our client who had database performance issues with their custom schema and queries. We made updates to the database tables and indices and reconfigured the RADIUS server appropriately. The output meant a 300 times increase in the performance of the original system with no customer application updates required.

RADIUS server installation is more involved than just setting up a few software packages. The default RADIUS products are intended to be the basis for a customized local configuration.

RADIUS accounting collects data for statistical purposes and network monitoring and is also employed to enable accurate billing of users.

During the process where the user requests access to the RADIUS server, RADIUS authorization and authentication happen simultaneously. An “authentication request” occurs when the Network Access Server (NAS) sends a request to the RADIUS server.

RADIUS authentication starts when the user requests access to a network resource through the Remote Access Server (RAS). The user submits a username and a password, which are encrypted by the RADIUS server before being sent through the authentication process. The request may also include additional user information, such as location or network address.

Release packages are available for Debian, Ubuntu and CentOS 7.

These packages are from the official “3.0.19” release, and will track all new versions of FreeRADIUS. The release packages are also integrated into our new Jenkins driven, dockerised, workflow. Packages should be available as soon as a new version has been released.

The benefits of a RADIUS server on the efficiency of an entire network are wide-reaching. Although some businesses are unaware of the advantages of a RADIUS server as opposed to a pre-shared key, others have long benefited from the increased speed of RADIUS servers, as well as their ability to heighten security, to enhance reporting and tracking capabilities, and to personalize restrictions based on the user.

One of our clients with a support contract had performance issues. We tracked this down to inefficient usage of AAA policies. Having tuned the policies the load on our client’s database dropped by a factor of 400 which saved them from an expensive hardware upgrade.

One of our clients had customer-visible issues in their 802.1X deployment. We tracked the problem down to firmware issues and worked with multiple vendors to fix the issues and more. This meant that our client was satisfied that their setup met all requirements.

We believe that standards compliance is critical for customer satisfaction and vendor interoperability. Systems that follow standards have known, documented behavior, so there are few surprises.

We have extensive experience in the WiFi roaming arena, and we are actively involved in vendor forums. Proxying is a key part of most RADIUS infrastructures. We foster relationships with numerous companies that provide roaming and proxying RADIUS help.

Building a RADIUS system that can handle 10 million users takes time. Our experienced team can work with you to design a customized solution using your desired hardware and Operating System to achieve that goal.

A RADIUS server utilizes a central database to authenticate remote users. RADIUS functions as a client-server protocol, authenticating each user with a unique encryption key when access is granted. How a RADIUS server works depends upon the exact nature of the RADIUS ecosystem. Below is an overview of how RADIUS servers work.

A case study on how we redesigned our client’s system to improve the RADIUS server’s database, which had lost performance over time. The database performance was restored, even with ten times the amount of data, and our client did not need to replace any systems.

LDAP databases are typically used by enterprises, though some ISPs also use them. The common implementations are Active Directory and OpenLDAP. We have extensive experience with both.

Undertaking 802.1X setup is a daunting experience for many organizations. There are detailed requirements on end-user PCs, switches, servers, certificates, and more. If any of these requirements are not met, your 802.1X setup will not work.

Most telecommunications companies and internet service providers (ISPs) use SQL databases to store the bulk of their user information. Whether the database is MySQL, Oracle, or PostgreSQL, we can help. We can optimize both the database and its interaction with the RADIUS server.

A case study on how Network RADIUS were able to assist a client to increase the stability of their RADIUS proxy system. We were able to reuse common configuration, maintain existing capabilities and make proxying more robust. A faster failover and more reliable system helped lower ongoing costs and increase revenue.

A case study on how Network RADIUS were able vastly improve the performance of a client’s RADIUS server, enabling them to move the system into production.

RADIUS is the core of our business. We have world-leading experience with the protocol. We can help you with all aspects of Authentication, Authorization, and Accounting.

So you decided that whatever you were using for network security wasn’t getting the job done… either it didn’t scale with the growth in your user base, devices, or network design, or it was hindering your organization’s productivity. Or maybe you suffered a security breach. Whatever the case, you decided to make the jump to RADIUS authentication, and you’ve implemented a RADIUS server.

We have already looked at authentication and authorization. In this third article, we’ll take a look at the accounting process, the process of monitoring and recording a client’s use of the network, and we’ll describe why it’s essential that the RADIUS server monitors user activity on the network.

The first article in our series described the authentication process, whereby the RADIUS server prevents unauthorized users from accessing the system.

In today’s article, we’ll examine the second link in the RADIUS security chain: authorization.

RADIUS security is composed of three components: authentication, authorization, and accounting. These three links in the RADIUS security chain are often referred to by their acronym, “AAA”. The first of these, authentication, is the process that determines whether a client (a person, a device, or a software process) is a legitimate user of the system.

When setting up a WiFi network at home, you typically set up an SSID and password, accept the defaults for any other options, and be done with it. (In some cases, these are done for you by your service provider — you don’t even have to think.) You share the password with family and visitors, and everyone is happy.