FreeRADIUS ([http://www.freeradius.org|http://www.freeradius.org/]) is a very powerful, configurable, fast and freely available open-source RADIUS server. The sample configurations are based on FreeRADIUS 2.0.3. RPM installation packages exist for numerous distributions under the name of either freeradius or freeradius-server. The use of version 1.x is discouraged. If the personal skills allow, it is suggested to download the most recent version from the FreeRADIUS web site \[link: www.freeradius.org\] and compile it fresh from these sources. \\ |
All the configuration files for FreeRADIUS are stored in a /etc/raddb directory. Configuration is broken down into several files by default.
The most important ones for an eduroam Service Provider are:
For eduroam Identity Providers, additionally the following file is important:
In this section, an example server is configured as follows:
Access points, RADIUS servers and other RADIUS clients (NAS devices, RADIUS test scripts, ...) are defined in the file /etc/raddb/clients.conf. This file lists devices that may send requests to the server. An example is given below, and can be downloaded from http://www.eduroam.org/downloads/docs/eduroam-cookbookscripts.zip.
This example defines a group of access points with a common shared secret: 158.64.254.0 – 158.64.254.7 (due to netmask = 29) are defined as clients and are assigned the shared secret verysharedsecret. These clients will show up in log files with their shortname eduroam-ap-v4. All incoming requests by these clients will be handled by the virtual server eduroam.
client descriptivename {
ipaddr = 158.64.254.0
netmask = 29
secret = verysharedsecret
require_message_authenticator = no
shortname = eduroam-ap-v4
nastype = other
virtual_server = eduroam
}
|
To edit the file for your own configuration, comment out or delete the existing entries and add the access points:
An arbitrary number of client stanzas can be added to the file. Individual IP addresses with their own shared secret can be defined by assigning netmask = 32.
For Cisco APs the nastype is set to cisco, for other NAS devices the value should be set differently. If the AP has no corresponding nastype, the nastype needs to be set to „other". It is recommended to use a different shared secret for every access point. The secret has to be entered in the Access Point as well. You can use mkpasswd to randomly generate shared secrets. Shared secrets in RADIUS are rather weak; for cryptographic reasons, the recommend length for shared secrets is 16 bytes.
Since a linked RADIUS server is viewed as a RADIUS client device, they also have to be added here. Hence it is necessary to determine all servers DNS names or their IP addresses. For an institutional server, at least its uplink RADIUS servers from the federation have to be added (in most cases, these are the Federation-Level RADIUS servers (FLRS)). client stanzas can also define IPv6 clients. The example files found inhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip show two FLR uplinks (Luxembourg FLR servers), one for IPv6 and one for IPv4 clients.
A loopback client is useful for running testing scripts and even mandatory for tunnelled authentication methods like TTLS and PEAP, so we make sure it is set correctly. The localhost's secret does not need to be shared with anyone, it is just there proforma and can even be left at the default „testing123" An example can be downloaded from http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip.
RADIUS requests from local users must be handled locally, while requests from roaming users must be proxied to the national FLRS RADIUS server. If an organisation has a domain domain.tld all requests for *.domain.tld are forwarded from the national RADIUS server to their organisational RADIUS server and it is their responsibility to filter out invalid domains via the blackhole rule to prevent looping of invalid authentication requests. Proxying is configured in the file /etc/raddb/proxy.conf, the first rule with a match is used. The configuration file contains lots of sample definitions. These are not necessary and can be deleted.
An example file can be downloaded as an example and for edit (http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip). Points of importance are:
proxy server {
default_fallback = yes
}
|
This setting means that if an authentication request contains a realm that is not explicitly listed in latersections of this file, it is proxied to the DEFAULT realm.
For a Service Provider, the definition of the actual server (the part that processes incoming packets from the defined clients and sends them off to the defined proxy servers) is very simple, since the server doesn't have to perform any authentication by itself.
Configuration of a server section happens in its own file within the subdirectory sites-available. The file can be downloaded from http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. A symlink in the directory sites-enabled points to the definition in sites-available.
The file contains a single server section with several subsections. Authentication requests are processed through the following sections, in order:
Accounting requests are processed as follows:
These sections contain the names of modules that are configured in radiusd.conf and are explained in a later section. The complete server configuration for an SP is below (note the empty authenticate section since the server is not actually performing any authentication itself as an SP): As the script is processed, the following actions are performed:
For accounting requests, the following steps are performed:
This file contains many generic RADIUS configuration items. However, the defaults to these items are usually appropriate for eduroam, and therefore will not be discussed here. Only configuration items that need alteration are discussed.
user = radiusd
group = radiusd
|
If these lines remain commented-out, FreeRADIUS will run as root. This is generally considered inadvisable. Therefore, it is strongly recommended that you create a radiusd user and a radiusd group, and then run the server as this radiusd user. However, if you do this you must ensure that that all files the server accesses during operation can be written to and read by this user and group.
listen {
type = auth
ipaddr = *
port = 1812
}
listen {
type = auth
ipv6addr = ::
port = 1812
}
listen {
type = acct
ipaddr = *
port = 1813
}
listen {
type = acct
ipv6addr = ::
port = 1813
}
|
security {
max_attributes = 200
reject_delay = 0
status_server = yes
}
proxy_requests = yes
$INCLUDE proxy.conf
$INCLUDE clients.conf
$INCLUDE sites-enabled/
|
detail auth_log {
detailfile = ${radacctdir}/%Y%m%d/eduroam/auth-detail
detailperm = 0600
}
|
realm suffix {
format = suffix
delimiter = "@"
}
|
attr_filter attr_filter.pre-proxy {
_attrsfile = ${confdir}/attrs.pre-proxy
}
|
The remaining parts in the virtual server, like
if (...) {
update request {
}
}
|
are not separate modules but a configuration language. Details about usage of this configuration language are available on its man page ("man unlang").