FreeRADIUS is a very versatile and freely available RADIUS server under the GPL license. Setting up FreeRADIUS as an SP is a rather straightforward task, since it merely needs to forward requests from NASes to other RADIUS servers. In particular, it does not need to authenticate users. The following configuration enables your FreeRADIUS server to be an eduroam SP. At the same time, it is the baseline from which to establish an eduroam IdP configuration, if that is envisaged for a later stage.
Version information
This documentation is current as of FreeRADIUS 2.1.10.
Installation
FreeRADIUS is written in C and can be compiled with the usual UNIX compilation sequence. After unpacking the source into a directory of your choice, do
./configure --prefix=<your preferred install dir> --sysconfdir=<your preferred configuration base dir> make make install
In the examples below, we assume the installation is done for --prefix=/usr/local/freeradius/ and the configuration dir is --sysconfdir=/etc
Sample config directory
Base configuration / logging / F-Ticks
The main configuration file is /etc/radiusd.conf; it does not require many changes from the shipped default. That's because the logic in the server is done by activating certain modules in a certain order. These modules are separately defined and configured in the /etc/modules/ subdirectory. The order of activation of these modules is defined in so-called virtual servers, which are defined in the /etc/sites-enabled/ directory. For our eduroam SP purposes, we only need one virtual server "eduroam". It needs to contain as a minimum:
server eduroam {
authorize {
auth_log
suffix
}
authenticate {
}
preacct {
suffix
}
accounting {
}
post-auth {
reply_log
Post-Auth-Type REJECT {
reply_log
}
}
pre-proxy {
pre_proxy_log
if (Packet-Type != Accounting-Request) {
attr_filter.pre-proxy
}
}
post-proxy {
post_proxy_log
attr_filter.post-proxy
}
}
The multitude of sections in this above configuration is often confusing to new-comers. The order of execution when proxying a request are:
authorize → authenticate → pre-proxy
Then, the packet is proxied to an upstream server. When the reply comes back, the execution continues:
post-proxy → post-auth
Every stanza contains names of modules to be executed. Let's revisit them one after another:
- auth_log: logs the incoming packet to the file system. This is needed to fulfull the eduroam SP logging requirements.
- suffix: inspects the packet to look for an eduroam style realm (separated by the @ sign)
- pre_proxy_log: logs the packet to the file system again. Attributes that were added during the inspection process before are then visible to the administrator - great for debugging
- attr_filter.pre-proxy: strips unwanted attributes off of the request before sending the request to upstream
- post_proxy_log: logs the reply packet to the file system - as received by upstream
- attr_filter.post-proxy: strips unwanted attributes off of the reply, prior to sending it back to the Access Points (VLAN attributes in particular!)
- reply_log: logs the reply packet after attribute filtering to the file system
The paths where the logs are written to, and the files with the list of permitted attributes for filtering, are defined in the corresponding module definitions in /etc/modules/<name-of-module>.
Client definition
FreeRADIUS defines the connected RADIUS clients in the file /etc/raddb/clients.conf. This file needs to hold all your connected Access Points and/or wired eduroam-enabled switches. You set a shared secret for each client and define these in the config file as follows:
client antarctica-access-point-1 {
ipaddr = 172.25.1.55
netmask = 32
secret = yoursecret12345
shortname = southpole-11g
virtual_server = eduroam
}
There are more (optional) settings for clients; please consult the comments in clients.conf for more detail. One option, the "virtual_server" one, enables your RADIUS server to serve more purposes than only eduroam: you can define several other virtual servers for other RADIUS purposes, and link clients to these. That is beyond the scope of this documentation, though.
If you want to connect your clients over IPv6, the syntax is only slightly different:
client antarctica-access-point-2 {
ipv6addr = 2001:db8:1:789::56
netmask = 128
secret = yoursecretABCDE
shortname = southpole-11n
virtual_server = eduroam
}
Request forwarding
FreeRADIUS contains a wealth of options to define how requests are forwarded. These options are defined in the file /etc/proxy.conf. For a single eduroam SP, these may seem overkill, but the required definitions for that purpose are rather static. Assuming you have two upstream servers to forward requests to, the following configuration will set these up - you only need to change the IP addresses and shared secrets in home_server stanzas.
proxy server {
default_fallback = yes
}
home_server antarctica-flr-1 {
type = auth+acct
ipaddr = 172.20.1.2
port = 1812
secret = secretstuff
status_check = status-server
}
home_server antarctica-flr-2 {
type = auth+acct
ipv6addr = 172.25.9.3
port = 1812
secret = secretstuff
status_check = status-server
}
home_server_pool EDUROAM {
type = fail-over
home_server = antarctica-flr-1
home_server = antarctica-flr-2
}
realm DEFAULT {
pool = EDUROAM
nostrip
}
Goodies
Running FreeRADIUS as non-root user
The RADIUS protocol runs on ports >1023, which means it can be started entirely in unprivileged mode on UNIX-like systems. You can easily achieve that by
- creating a user "radiusd" and group "radiusd"
- giving all configuration files in /etc/raddb ownerships for that user radiusd + group radiusd
- changing these two parameters in /etc/raddb/radiusd.conf:
user = radiusd group = radiusd