FreeRADIUS Beginner's Guide: Master authentication, authorization, and accessing your network resources using FreeRADIUS

Free Trial

4.4 (10 Ratings)

Paperback Sep 2011 344 pages 1st Edition

Paperback Sep 2011 344 pages 1st Edition

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!

Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!

50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

Thousands of reference materials covering every tech concept you need to stay up to date.

Subscribe now

View plans & pricing

View table of contents

Preview Book

FreeRADIUS Beginner's Guide

Chapter 1. Introduction to AAA and RADIUS

It is my pleasure to present you a beginner's guide to FreeRADIUS. This book will help you to deploy a solid, stable, and scalable RADIUS server in your environment.
This chapter is used as an introduction to RADIUS and FreeRADIUS. We will be covering a fair amount of theory and recommend you pay special attention to it. This will supply you with a good foundation on the workings of the RADIUS protocol and will be of much help in subsequent chapters.

In this chapter we shall:

See what AAA is, and why we need it
Learn where RADIUS started and why it is so relevant today
See why FreeRADIUS really shines as a RADIUS server
Understand the relationship between AAA, RADIUS, and FreeRADIUS

Let's get started.

RADIUS

RADIUS is an acronym for Remote Access Dial In User Service. RADIUS was part of an AAA solution delivered by Livingston Enterprises to Merit Network in 1991. Merit Network is a non-profit Internet provider, which required a creative way to manage dial-in access to various Points-Of-Presence (POPs) across it's network.

The solution supplied by Livingston Enterprises had a central user store used for authentication. This could be used by numerous RAS (dial-in) servers. Authorization and accounting could also be done whereby AAA was satisfied. Another key aspect of the Livingston solution included proxying to allow scaling.

The RADIUS protocol was then subsequently published in 1997 as RFCs, some changes applied, and today we have RFC2865 , which covers the RADIUS protocol, and RFC2866 , which covers RADIUS accounting. There are also additional RFCs which cover enhancements on certain RADIUS aspects. Having RFCs to work from allows any person or vendor to implement the RADIUS protocol on their equipment or software. This resulted in widespread adoption of the RADIUS protocol to handle AAA on TCP/IP networks. You will find the word RADIUS is used loosely to either mean the RADIUS protocol or the entire RADIUS client/server system. The meaning should be clear from the context in which it is used.

Supporting the RADIUS protocol and standards became the de facto requirement for NAS vendors. RADIUS is used in a wide variety of places, from cellular network providers having millions of users to a small WISP start-up providing the local neighborhood with Internet connectivity to enterprise networks that implement Network Access Control (NAC) using 802.1x to ring fence their network. RADIUS is found in all these places and more!

ISPs and network administrators should be familiar with RADIUS since it is used by various devices that control access to TCP/IP networks. Here are a couple of examples:

A firewall with VPN service can use RADIUS.
Wi-Fi access points with WPA-2-Enterprise encryption involve RADIUS.
When Alice connects through an existing Telco's infrastructure using DSL; the Telco's equipment will use RADIUS to contact Isaac's RADIUS servers in order to determine if she can gain Internet access through DSL (proxying).

The next section will summarize the RADIUS protocol as specified in RFC2865.

RADIUS protocol (RFC2865)

This section explores the RADIUS protocol on a technical level as published in RFC2865. RADIUS accounting is excluded. This is published as RFC2866 and explored in its own section.

The RADIUS protocol is a client/server protocol, which makes use of UDP to communicate. Using UDP instead of TCP indicates that communication is not strict on state. A typical flow of data between the client and server consists of a single request from the client followed by a single reply from the server. This makes RADIUS a very lightweight protocol and helps with its efficiency across slow network links.

Before successful communication between the client and server can be established, each has to define a shared secret . This is used to authenticate clients.

Note

An NAS acts as a RADIUS client. So when you read about a RADIUS client it means an NAS.

RADIUS packets have a specified format defined in the RFC. Two key components inside a RADIUS packet are:

The code, which indicates the packet type
Attributes, which carry the essential data used by RADIUS

Let's investigate the composition of a RADIUS datagram.

The data packet

Knowing the format of a RADIUS packet will greatly assist in understanding the RADIUS protocol. Let us look more closely at the RADIUS packet. We will look at a simple authentication request. A client sends an Access-Request packet to the server. The server answers with an Access-Accept packet to indicate success.

The RADIUS packets shown here are only the payload of a UDP packet. A discussion of the UDP and IP protocols is beyond the scope of this book.

Note

The screenshots were obtained by capturing the network traffic between the RADIUS client and RADIUS server.

We used a program called Wireshark to capture and look at the content of the data packets. Wireshark is an open source tool that should be part of any serious network guru's arsenal. It can be found here:

http://www.wireshark.org

The screenshots here are the result of a simple Authentication request send to a RADIUS server. The obtaining of this data is commonly known as packet sniffing among IT geeks.

The following screenshot shows the Access-Request packet send from the RADIUS client:

The following screenshot shows the RADIUS server responding to this request with an Access-Accept packet:

Let's discuss the packets.

Code

Each packet is identified by a code. This field is one octet in size. The value of this code determines certain characteristics and requirements of the packet. The following table can be used as a reference to list some of the current defined codes for RADIUS packets:

RADIUS code (decimal)	Packet type	Sent by
1	Access-Request	NAS
2	Access-Accept	RADIUS server
3	Access-Reject	RADIUS server
4	Accounting-Request	NAS
5	Accounting-Response	RADIUS server
11	Access-Challenge	RADIUS server
12	Status-Server (Experimental)
13	Status-Client (Experimental)
255	Reserved

Knowing these codes is beneficial when working with RADIUS.

Identifier

The second octet of each packet contains a unique identifier. It is generated by the client and used as an aid to match requests and replies. RADIUS packets are transported using connectionless UDP. This requires RADIUS to implement its own algorithm to submit retry requests from the client. When a client resends a request to the server the packet's identifier will remain unchanged. The server will respond to requests by matching the identifier in the response packet.

Length

This is the third and fourth octets in the datagram. It indicates up to where the useful data inside the packet is located. Octets outside the boundary indicated by this field are considered to be padding and silently ignored.

Authenticator

The manner in which this field, which consists of 16 octets, is formed differs depending on whether the packet is a request from the client or a response from the server. It also depends on the packet type, for example Access-Request or Accounting-Request. If it is a request, the field is referred to as a Request Authenticator. If it is a response, the field is referred to as a Response Authenticator.

The value of a Request Authenticator is a random number not to be repeated again. The value of a Response Authenticator is the MD5 hash of various fields in the reply packet along with the shared secret between the client and server.

If the request includes the User-Password attribute, then the value of this attribute will be encrypted. This encrypted value is typically generated by creating an MD5 hash from the shared secret combined with the authenticator and then XOR-ing the result with the user's password. This is why the shared secret has to be the same on the client and the server in order to decrypt the user's password.

Attributes

The rest of the RADIUS packet will contain zero or more attributes, which are referred to as Attribute Value Pairs (AVP). The end of these AVPs is indicated by the packet's length field, as mentioned before.

Conclusion

RADIUS packets are transported through UDP. The code field identifies the type of RADIUS packet. Attributes are used to supply specific information used for authentication, authorization, and accounting. To authenticate a user for instance, the User-Name and User-Password AVPs will be included along with some other attributes inside the Access-Request packet.

AVPs

AVPs are the workhorse of the RADIUS protocol. AVPs can be categorized as either check or reply attributes. Check attributes are sent from the client to the server. Reply attributes are sent from the server to the client.

Attributes serve as carriers of information between the client and server. They are used by the client to supply information about itself as well as the user connecting through it. They are also used when the server responds to the client. The client can then use this response to control the user's connection based on the AVPs received in the server's response.

The following sections will describe the format of an AVP.

Type

The first octet of the AVP is the type field. The numeric value of this octet is associated with an attribute name so that we humans can also understand. Assignment of these attribute names to numbers is controlled by IANA (http://www.iana.org/). The attribute names are usually descriptive enough to deduce their function, for example User-Name(1), User-Password(2), or NAS-IP-Address(4).

RADIUS also allows extending the protocol; attribute Type 26 (called Vendor-Specific) allows for this. The value of the Vendor-Specific attribute can in turn contain Vendor Specific Attributes (VSAs) which are managed by a vendor.

Length

The length field consists of the second octet in the AVP. This is used in the same manner as in the RADIUS packet itself to indicate the length of the AVP. This method allows one to have AVPs with different size values since the length field will mark the AVP's end.

Value

The value of an AVP can differ in size. The value field can be zero or more octets. The value field can contain one of the following data types: text, string, address, integer, or time.

Text and string can be up to 253 octets in size. Address, integer, and time are four octets long.

If we take the 'NAS-IP-Address' AVP in the Request packet we see the length is six. That is one octet for the type, one octet for the length, and four octets for the IP address, six octets in total.

The next section will discuss Vendor-Specific Attributes, which are an extension to the standard AVPs.

Vendor-Specific Attributes (VSAs)

VSAs allows vendors to define their own attributes. The format of the attribute definitions is basically the same as for normal AVPs with the addition of a vendor field. VSAs are sent as the value of AVP Type 26. This means that VSAs are an extension of AVPs and carried inside AVPs.

This makes RADIUS very flexible and allows a vendor to create extensions to customize their RADIUS implementation. CoovaChilli for instance has a VSA attribute called 'ChilliSpot-Max-Total-Octets '. When the CoovaChilli client receives this attribute in a reply from the RADIUS server it uses this value to restrict data through the captive portal.

The NAS will silently ignore any VSAs that are not meant for it. Some vendors publish their VSAs, but this is not required. Others simply list them on a website or document. This can then be consulted to determine the capabilities of the RADIUS implementation of their equipment.

Proxying and realms

The RADIUS protocol allows for scaling. Proxying allows one RADIUS server to act as a client to another RADIUS server. This can eventually form a chain.

A discussion on proxying also includes realms . Realms are names used to group users and form part of the username. A username is separated from the realm name with a specified delimiter character. The realm name can be prefixed or postfixed to the username. Today's popular standard uses domain names as a postfix and delimits it with the @ character, for example <alice@freeradius.org>. This is, however, just a convention. The realm can be any name and the delimiter can be any character. Windows users typically use a prefix notation specifying the domain first with a \ character as delimiter, for example my_domain\alice.

When the RADIUS server receives a request with a username containing a realm it can decide whether to process the request or to forward the request to another RADIUS server designated to handle requests for the specified realm. This would require that the second RADIUS server should have the forwarding RADIUS server defined as a client and that they also have a shared secret in common.

RADIUS server

The RADIUS protocol is client/server based. The RADIUS server will listen on UDP port 1812 and 1813. Port 1812 is used for authentication. This will involve Access-Request, Access-Accept, Access-Reject, and Access-Challenge packets. Port 1813 is used for accounting. This will involve Accounting-Request and Accounting-Response packets.

A client and the server require a shared secret in order to encrypt and decrypt certain fields in the RADIUS packet.

RADIUS client

RADIUS clients are usually equipment which supplies access to a TCP/IP data network. The client acts as a broker between the RADIUS server and a user or device that wants to gain network access.

The proxying functionality of RADIUS also allows one RADIUS server to be the client of another RADIUS sever, which eventually can form a chain.

The feedback from the RADIUS server not only determines if a user is allowed on the network (authentication), but can also direct the client to impose certain restrictions on the user (authorization). Examples of restrictions are a time limit on the session or limiting the connection speed.

The responsibility to impose the recommended adjustments to the user's session lies with the client though. Due to the stateless nature of the RADIUS protocol there is no way for the RADIUS server to know if the client is imposing the recommended restrictions. In order for the client to communicate successfully with the RADIUS server there should be a shared secret between the two. This is used to encrypt certain attributes.

Accounting is defined in a separate RFC. The next section will summarize RADIUS accounting as specified in RFC2866.

RADIUS accounting (RFC2866)

This section explores the accounting functionality of the RADIUS protocol. Accounting is a means of tracking usage of resources and typically used for billing.

Operation

The RADIUS accounting server runs on port 1813. When a user's session begins the NAS sends an Accounting-Request packet to the RADIUS server. This packet must contain certain AVPs. It is the first packet sent after successful authentication. The server will confirm reception by sending a matching Accounting-Response packet.

Throughout the session the NAS can send optional update reports on the time and data usage of a particular user. When the user's session ends the NAS informs the server about it. This puts closure to the accounting details recorded during the user's session.

The RADIUS client's functionality makes provision for instances when the server is down. The NAS will then, depending how it is configured, retry or contact another RADIUS server.

When a RADIUS server functions as a forwarding proxy to another RADIUS server, it will serve as a relay for the accounting data. It may also record the accounting data locally before forwarding it.

Packet format

Accounting involves RADIUS code 4 (Accounting-Request) and code 5 (Accounting-Response) packets. Accounting packets like authentication packets use the same RADIUS protocol. One unique feature of accounting packets is that the User-Password attribute is not sent in the request.

See the following output from Wireshark that shows a typical accounting transaction. It starts with an Accounting-Request from the client:

The server then replies to the client with an Accounting-Response:

Accounting-Request packets are also required to include certain AVPs. Let us take a look at important AVPs used in accounting.

Acct-Status-Type (Type40)

This packet indicates the status of the user or the NAS. An NAS may send interim updates on the usage of a certain session. in order to do this the NAS sets the type to Interim-Update. This allows us to follow usage trends in approximately real time.

The RADIUS server does not check up on an NAS. If an NAS has informed the RADIUS server about a newly connected user (status type Start) and thereafter the NAS breaks down completely, the records on the RADIUS server will still indicate that the user is connected to the NAS when in fact the user is not. These records are referred to as rogue entries. To reduce rogue entries, it is good practice for an NAS to send an Accounting-Off followed by an Accounting-On packet just after boot-up and also an Accounting-Off packet before shutting down. This action will cause RADIUS to close all open records for any user connected to the particular NAS allowing a clean start.

Rogue entries are particularly problematic when you limit the number of sessions a user can have. If the component limiting the sessions of a user makes use of data containing rogue entries the calculations will not be accurate.

The following decimal to type table can be used as reference for the possible status values:

Decimal value	Status type
1	Start
2	Stop
3	Interim-Update
7	Accounting-On
8	Accounting-Off
9-14	Reserved for tunnel accounting
15	Reserved for failed

Although the Acct-Status-Type AVP is not compulsory it is almost always included.

Acct-Input-Octets (Type42)

This indicates the octets received during the session and is used with Acct-Status-Type having a value of Interim-Update or Stop.

Take note of the value's limitation. Four octets limit it to 4,29,49,67,296. Most modern RADIUS implementations already cater for this.

Acct-Output-Octets (Type43)

This indicates the octets sent during the session and is used with Acct-Status-Type having a value of Interim-Update or Stop.

Take note of the value's limitation. Four octets limit it to 4,29,49,67,296. Most modern RADIUS implementations already cater for this.

Acct-Session-Id (Type44)

Compulsory for all Accounting-Request packets, this is a unique value that is used to match Start, Interim, and Stop records. All Start, Interim, and Stop records of a session should have the same value for Acct-Session-Id.

Acct-Session-Time (Type46)

The name is self explanatory. The time in seconds indicating the session's duration and is used with Acct-Status-Type having a value of Interim-Update or Stop.

Acct-Terminate-Cause (Type49)

This is accompanied by an Acct-Status-Type AVP with its value set to Stop. The value of this AVP is decimal. It is used in the same manner as Acct-Status-Type where a specific decimal value resolves to a termination cause.

Conclusion

This brings us to the end of RADIUS accounting. The next session will look at certain RFCs that add functionality and enhancements to the RADIUS definitions of RFC2865 and RFC2866.

RADIUS extensions

After the initial RFCs defining RADIUS in general and RADIUS accounting, various extensions were proposed to expand RADIUS usage or improve some weaknesses.

There is also an improved RADIUS protocol called Diameter (A word play—twice as good as RADIUS). The uptake of Diameter has been very slow though, and RADIUS still remains the de facto standard for the foreseeable future. A major reason for this is probably the fact that the many enhancements that Diameter was supposed to bring are already covered by the various RADIUS extensions. There is, for instance, the RadSec protocol that transports RADIUS over TCP and TLS. This makes RADIUS scale better in roaming environments.

Although there are more, we will only look at two important extensions likely to be used.

Dynamic Authorization extension (RFC5176)

This extension helps to create a feedback loop from the RADIUS server to the NAS. This in effect swaps the roles of the client and server. The RADIUS server becomes a client to the NAS.

Dynamic authorization allows for the RADIUS server to inform the NAS about changes that have to be made to a user's existing session on the NAS. There are two popular applications of this extension.

Disconnect-Message (DM)

Also known as a Packet of Disconnect (POD), this is used to disconnect an existing user's session. The RADIUS server sends the disconnect request and the NAS has to reply whether the disconnection was successful or not.

Change-of-Authorization Message (CoA)

This message supplies data to change the authorization of an existing user's session. We can now dynamically change the bandwidth limit per session for instance. This allows us to increase the per session bandwidth when load on our Internet link decreases. When load on our Internet link increases we can again decrease the per session bandwidth.

MikroTik RouterOS includes this functionality on some of the services that use RADIUS.

The following table lists the codes and names of the RADIUS packets involved:

Radius code (decimal)	Packet type	Send by
40	Disconnect-Request	RADIUS server
41	Disconnect-ACK	NAS
42	Disconnect-NAK	NAS
43	CoA-Request	RADIUS server
44	CoA-ACK	NAS
45	CoA-NAK	NAS

RADIUS support for EAP (RFC3579)

EAP stands for Extensible Authentication Protocol. It is mostly used for security on Ethernet switches and Wi-Fi access points.

EAP supports the use of an external authorization server. RADIUS can be such a server. EAP will then use the RADIUS protocol to wrap the EAP data inside AVPs in order to authenticate a connection.

This book has a dedicated chapter on EAP since it is such an important part of enterprise Wi-Fi security.

In the next section will look at the FreeRADIUS project. FreeRADIUS is an implementation of the RADIUS protocol and its various extensions including the two mentioned here.

Summary

This chapter is the introduction and foundation on which we will build that. As a rehash on important points discussed, be sure to know the following facts:

Name	Stands for	Short description
AAA	Authentication, Authorization, and Accounting	The three components required for proper control of access and usage.
NAS	Network Access Server	A device controlling access to the network for example, a VPN server. Acts as the RADIUS client.
AVP	Attribute Value Pair	A three-field component inside a RADIUS packet used to contain a specified field and its data.
VSA	Vendor-Specific Attributes	An extension of the AVP managed by a specific vendor.

AAA is a security architecture model.
RADIUS is a specific implementation of AAA.
FreeRADIUS is a practical application of RADIUS.
Thus we have AAA → RADIUS → FreeRADIUS.
RADIUS is all about central control and is the de facto standard supported by NAS vendors.
RADIUS is a client/server protocol. It uses UDP and listens on port 1812 for authentication and port 1813 for accounting requests.
RADIUS data packets have a code field, which specifies the type of RADIUS packet.
RADIUS data packets have zero or more AVPs, which contain the data used in RADIUS.
FreeRADIUS implements the RADIUS protocol along with its various extensions as specified in RFCs.
FreeRADIUS is a very popular, widely used, and very flexible RADIUS server.

This chapter was a FreeRADIUS starter. The main course begins with the next chapter where we'll be installing FreeRADIUS and starting to use it.

Pop quiz – RADIUS knowledge

Explain the term NAS device.
What are the start and end points of a session?
Which protocol and ports does RADIUS use?
What do the RADIUS client and server require for successful communication?
What packet does the RADIUS client send when authenticating a user?
Who initiates a Disconnect Request packet and who receives it?
Name three components of an Attribute Value Pair (AVP).
Alice connects with username alice@freeradius.org to a network. What is the name of the realm to which Alice belongs?

Key benefits

Step-by-Step instructions for all the main Linux distributions: CentOS, SUSE, and Ubuntu
Know the FreeRADIUS components and understand how they interact
Integrate FreeRADIUS into an existing environment or blend it into a larger infrastructure
Control and track the usage of network resources by using the most popular RADIUS server today

Description

The Open Source pioneers have proved during the past few decades that their code and projects can indeed be more solid and popular than commercial alternatives. With data networks always expanding in size and complexity FreeRADIUS is at the forefront of controlling access to and tracking network usage. Although many vendors have tried to produce better products, FreeRADIUS has proved over time why it is the champion RADIUS server. This book will reveal everything you need to know to get started with using FreeRADIUS. FreeRADIUS has always been a back-room boy. It's not easy to measure the size or number of deployments world-wide but all indications show that it can outnumber any commercial alternatives available. This essential server is part of ISPs, universities, and many corporate networks, helping to control access and measure usage. It is a solid, flexible, and powerful piece of software, but can be a mystery to a newcomer. FreeRADIUS Beginner's Guide is a friend of newcomers to RADIUS and FreeRADIUS. It covers the most popular Linux distributions of today, CentOS, SUSE, and Ubuntu, and discusses all the important aspects of FreeRADIUS deployment: Installing, configuring and testing; security concerns and limitations; LDAP and Active Directory integration. It contains plenty of practical exercises that will help you with everything from installation to the more advanced configurations like LDAP and Active Directory integration. It will help you understand authentication, authorization and accounting in FreeRADIUS. It uses many practical step-by-step examples, which are discussed in detail to lead you to a thorough understanding of the FreeRADIUS server as well as the RADIUS protocol. A quiz at the end of each chapter validates your understanding.Not only can FreeRADIUS be used to monitor and limit the network usage of individual users; but large deployments are possible with realms and fail-over functionality. FreeRADIUS can work alone or be part of a chain where the server is a proxy for other institution's users forwarding requests to their servers. FreeRADIUS features one of the most versatile and comprehensive Extensible Authentication Protocol (EAP) implementations. EAP is an essential requirement to implement enterprise WiFi security. FreeRADIUS Beginner's Guide covers all of these aspects.

Who is this book for?

If you are an Internet Service Provider (ISPs) or a network manager who needs to track and control network usage, then this is the book for you. You need to be familiar with Linux and have a solid understanding of TCP/IP. No previous knowledge of RADIUS or FreeRADIUS is required.

What you will learn

Get a solid foundation on the RADIUS protocol and how it works
Build the latest FreeRADIUS packages for your Linux distribution using the distribution s package management system
Integrate FreeRADIUS into an existing environment by making use of alternative user stores
Utilize the powerful unlang language included with FreeRADIUS to control the flow of authorization
Manage, track, and limit network usage
Discover the available FreeRADIUS help resources and use them to your advantage
Implementing EAP especially for enterprise WiFi security
Use FreeRADIUS to forward requests to other RADIUS servers (Proxying)
Answer requests for other RADIUS servers using FreeRADIUS

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!

Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!

50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

Thousands of reference materials covering every tech concept you need to stay up to date.

Subscribe now

View plans & pricing

Product Details

Publication date : Sep 08, 2011

Length: 344 pages

Edition : 1st

Language : English

ISBN-13 : 9781849514088

Category :

Cloud & Networking

Concepts :

Cloud Computing

Tools :

FreeRADIUS

Filter reviews by

All

Amazon verified reviews

Diego Oct 15, 2012

This book covers how to configure the freeradius server in a really easy way, in the ubuntu authentification there are some little changes that must be done for it to work but nothing a regular ubuntu user can't solve.

Amazon Verified review

Jessica Campbell Nov 12, 2018

Great general overview of the Ins and Outs of FreeRADIUS - this book has been very helpful in my FreeRADIUS setup

ArtFan Mar 11, 2016

Although this book deals with Freeradius-2.x, the vast majority of it is also applicable to 3.0 and even for those pieces that have changed you will be able to figure it out with the knowledge you get from the book. Which means that if you need to learn how to administer recent versions, this book works. It explains how the radius protocol works, how freeradius implements it, and the various pieces and moving parts, what they do, how to make use of them. It explains this in a practical manner, as a tutorial with exercises, that starts from the ground and builds piece-by-piece so that you acquire a solid understanding. The author explains things in clear, effective language. You learn without being distracted by unnecessary jargon or irrelevant topics. The reason I got the book was because I needed such a tutorial and was unable to find something similar online. And I'm glad I did, it gave me what I needed.

Stefan Winter Nov 03, 2011

The book "'FreeRADIUS Beginner's Guide -' Manage your network resources with FreeRADIUS"' by Dirk van der Walt has set itself a bold goal: to transform an ordinary Unix/Linux system administrator from a 'Zero' to a 'Hero' in the topic of Authentication, Authorisation and Accounting with FreeRADIUS. The book is in a very modest price range and available in traditional printed and also an eBook version.From my own experience, getting in first contact with the RADIUS protocol in general and FreeRADIUS in particular can be a dreadful exercise: there are many complex concepts to grasp and huge configuration files to master; and plenty of opportunity to break things if you touch the configuration without knowing the do's and don'ts. The FreeRADIUS software package has ample documentation in the form of man pages and comments in configuration files. What was sorely missing ' up until now ' was documentation that would take an innocent reader by the hand and show him the wonders of RADIUS without too much confusion.Dirk's book certainly achieves this goal, and more. It dives straight into the matter, touches the RADIUS specification only as much as is needed to understand the software that delivers it. The reader learns how easy it is to get to the 'Hello, world!' equivalent of RADIUS ' the first successful authentication, an Access-Accept packet. From then on, the book builds on the milestones achieved by the reader and adds more and more features and complexity. Near the end of the book, the reader has all the required knowledge to run his own little hotspot, a federated 'single-sign-on domain' based on RADIUS or even be part of a large roaming consortium.Being heavily involved in RADIUS myself, as the lead R&D engineer for the 'eduroam' roaming consortium in Europe, and as lecturer on the topic of Secure Network Admission at the University of Luxembourg, I was amazed how often I found myself thinking 'Right, couldn't have said it better' when the author explained some of the particularly hairy concepts ' EAP with outer identity just being one example.Of course, there are always those few little things everyone likes to do a bit differently; I'm very much a compile-from-source person and was slightly disappointed to read that the author rather encourages his readers to use distribution packages or build their own RPMs/DEBs. Then again, the target audience is starting from zero, and adding "'compile your own"' to the stack of things to learn is probably asked a bit much. Another question of taste is the client to use for testing the more complex authentication mechanisms ' the book uses a GUI client, JRadiusSimulator, while I very much prefer 'eapol_test' from the wpa_supplicant software suite. It can be so nicely scripted and is as flexible as a Swiss army knife ' perfect for Nagios monitoring. In my humble opinion, it would have deserved a significant mention. Lastly, there is a nagging little oversight when it comes to the description of proxying on page 250: Proxying, when done in combination with mutually authenticating EAP methods and with anonymous outer identities doesn't expose usernames nor credentials to the roaming partner. The book doesn't make that aspect overly clear. Then again, peeking at the title, this topic is way advanced and few people will get to a point in their RADIUS life where they would need it.Summarising, I can highly recommend this book as a starter to get into FreeRADIUS. I'm sure the FreeRADIUS users' mailing list would see much less traffic on basic operational and conceptual questions if everyone were to read this book. If you need to get acquainted with FreeRADIUS, do yourself a favour and grab a copy.

Daniel Jun 05, 2013

This is a great book for starting off with Free Radius with very little understanding of how it functions to begin with.