You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Setting up FreeRADIUS

FreeRADIUS (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:

  • clients.conf – Definition of the client devices which connect to the server (see A.2.2)
  • proxy.conf – Definition of other servers and realms for proxying (see A.2.3)
  • sites-enabled/eduroam - virtual server definition (see A.2.4)
  • radiusd.conf – main configuration file (see A.2.5)

For eduroam Identity Providers, additionally the following file is important:

  • eap.conf – define EAP authentication (see A.2.6)

In this section, an example server is configured as follows:

  • Acting as a Service Provider:
    Accept requests from Access Points.
    Proxy requests to IdPs in the eduroam infrastructure.
  • Acting as a Identity Provider:
    Usage of both EAP-TTLS/PAP and PEAP/MSCHAPv2 simultaneously for authenticating the clients.
    Optionally: forcing outer identity to anonymous@domain.tld.
  • A few test user accounts are statically entered in a file.
  • Regular users are authenticated from an LDAP directory, using the eduPerson schema. Usernames are
    stored in eduPersonPrincipalName attribute and the plaintext password in userPassword attribute.
  • Accounting is stored in a MySQL database.
  • Optionally a script can be set-up to update accounting SQL table with information of assigned IP
    addresses.
Defining clients - Access Points and RADIUS servers in clients.conf

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 FLRS uplinks (Luxembourg
FLRS 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.


Configure realm handling and proxying: proxy.conf

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:

  • Replace domain.tld for your own assigned realm as an IdP. For SPs, only the DEFAULT realm is
    important.
  • proxy.conf contains a small configuration stanza; proxy server for system-wide options:

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.

  • The configuration file also needs to have defined home_server entries. They are the counterpart to the
    client stanzas from above: other RADIUS servers with their IP addresses and shared secrets. Two such
    example stanzas (for FLRS proxying of unknown realms) are included in the example file.
  • The parameters response_window, zombie_period and revive_interval are tuning parameters and should initially remain untouched. Using status_check = status-server is recommended, but only if the
    server on the other end is configured to handle such Status-Server requests. This behaviour is
    configured in radiusd.conf.
  • Home servers are aggregated in pools (i.e.: all servers that have the same function, like: all FLRS
    servers, are grouped together). This happens very straightforward in a home_server_pool definition:
  • All realms known to the server are listed in realm sections.
  • The nostrip command specifies that no domain stripping is performed (usernames always remain
    Network Access Identifier in the form short_username@domain.tld, for both local and roaming users).
Virtual server definition for eduroam: sites-enabled/eduroam

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:

  • authorize: Collect information about the user from the RADIUS client.
  • pre-proxy: Prepare proxy to other server.
  • post-proxy: Evaluate response from other server.
  • post-auth: Final packed inspection before sending the answer to the RADIUS client.

Accounting requests are processed as follows:

  • preacct: Collect information about the session which is being accounted.
  • pre-proxy: Prepare proxy to other server.
  • post-proxy: Evaluate response from other server.

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:

  • authorize/auth_log: The request packet is dumped into a log file.
  • authorize/suffix: The username is examined to determine the realm.
  • authorize/if: Loop prevention of bogus subdomain routing.
  • pre-proxy/attr_filter.pre-proxy: Filter out attributes which are not supposed to be sent out (VLAN etc.).
  • pre-proxy/pre_proxy_log: Log the request to disk before it is proxied.
  • post-proxy/post_proxy_log: Log the request to disk after receiving the answer from the proxy.
  • post-proxy/attr_filter.post-proxy: Filter out unsolicited attributes from the proxy (VLAN etc.).
  • post-auth/reply_log: The final reply to the client is logged to file.

For accounting requests, the following steps are performed:

  • preacct/detail: The request packet is dumped into a log file.
  • preacct/suffix: The username is examined to determine the realm.
  • preacct/if: Loop prevention of bogus subdomain routing.
  • pre-proxy/attr_filter.pre-proxy: Filter out attributes which are not supposed to be sent out (VLAN etc.).
  • pre-proxy/pre_proxy_log: Log the request to disk before it is proxied.
  • post-proxy/post_proxy_log: Log the request to disk after receiving the answer from the proxy.
  • post-proxy/attr_filter.post-proxy: Filter out unsolicited attributes from the proxy (VLAN etc.).
Main configuration file: radiusd.conf

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.

  • The following lines are commented-out by default:

           user = radiusd
           group = radiusd

           If the 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.

  • As of version 2, FreeRADIUS is capable of both IPv4 and IPv6. The following four sections enable both
    authentication and accounting processing with IPv4 and IPv6:

listen {
          type = auth
          ipaddr = *
          port = 1812
}

listen {
          type = auth
          ipv6addr = ::
          port = 1812
}

listen {
          type = acct
          ipaddr = *
          port = 1813
}

listen {
          type = acct
          ipv6addr = ::
          port = 1813
}

  • The following lines are important for eduroam operation: the aforementioned possibility to use Status-
    Server requests is enabled in the security section, and all the defined client definitions, proxy server
    definitions and the virtual servers are read in. The small subset of modules used in the virtual server
    eduroam are also defined here:

security {
           max_attributes = 200
           reject_delay = 0
           status_server = yes
}

proxy_requests      = yes
$INCLUDE proxy.conf
$INCLUDE clients.conf
$INCLUDE sites-enabled/

  • detail modules take a filename as an option to determine where to log packet content. The choice of file
    name is arbitrary. The %Y%m%d name above gets expanded to a date, and thus creates a new subdirectory every day. This makes debugging and deleting old records very easy. This module shows
    up in the sample server configuration in several variations (different filenames): auth_detail, detail,
    pre_proxy_detail, post_proxy_detail, reply_detail.

detail auth_log {
_detailfile = $

Unknown macro: {radacctdir}

/%Y%m%d/eduroam/auth-detail_
detailperm = 0600
}

  • The following module determines which part of the incoming User-Name is the name, and which one is
    the realm. Using @ as delimiter and treating the part behind the @ as realm is the eduroam definition of
    user names (and is the suggested naming scheme in RFC4282).

realm suffix {
format = suffix
delimiter = "@"
}

  • The following module gives the potential for filtering out unwanted attributes. One example for this is
    VLAN assignments. These assignments are of local significance only, and therefore it does not make
    sense for a remote server to dictate VLAN membership. In fact, this may even be harmful, and so,
    VLAN attributes should be not be sent out by IdPs and also be filtered by SPs. The module refers to
    files in the main configuration directory. Please refer to these files themselves for additional
    documentation on how to specify which attributes are allowed and which not. As of FreeRADIUS 2.0.4,
    the server will ship with standard defaults that are compatible with eduroam operation without the need
    for modifications.

attr_filter attr_filter.pre-proxy {
_attrsfile = $

Unknown macro: {confdir}

/attrs.pre-proxy_
}

The remaining parts in the virtual server, _if (...) update

Unknown macro: { ... }

_ are not separate modules but a
configuration language. Details about usage of this configuration language are available on its man

  • No labels