Setting up FreeRADIUS
| Wiki Markup |
|---|
...
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:
...
- 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.
| Code Block |
|---|
\\ {code} client descriptivename { ipaddr = 158.64.254.0 netmask = 29 secret = verysharedsecret require_message_authenticator = no shortname = eduroam-ap-v4 nastype = other virtual_server = eduroam } {code} \\ 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 in[http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip| |
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
...
.
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:
| Code Block |
|---|
\\ {code} proxy server { default_fallback = yes } {code} \\ 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). \\ h5. 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| |
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:
| Code Block |
|---|
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: \\ {code} user = radiusd group = radiusd {code} \\ If these lines remain = 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.
...
- 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:
| Code Block |
|---|
\\ {code} listen { type = auth ipaddr = * port = 1812 } listen { type = auth ipv6addr = :: port = 1812 } listen { type = acct ipaddr = * port = 1813 } listen { type = acct ipv6addr = :: port = 1813 } {code} * 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: \\ {code} |
- 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:
| Code Block |
|---|
security {
max_attributes = 200
reject_delay = 0
status_server = yes
}
proxy_requests = yes
$INCLUDE proxy.conf
$INCLUDE clients.conf
$INCLUDE sites-enabled/
{code}
* 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, |
- 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.
| Code Block |
|---|
. \\ {code} detail auth_log { detailfile = ${radacctdir}/%Y%m%d/eduroam/auth-detail detailperm = 0600 } {code} * The following module determines which part of the incoming |
- 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).
| Code Block |
|---|
\\ {code} realm suffix { format = suffix delimiter = "@" } {code} * 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 |
- 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.
| Code Block |
|---|
\\ {code} attr_filter attr_filter.pre-proxy { _attrsfile = ${confdir}/attrs.pre-proxy } {code} |
The
...
remaining
...
parts
...
in
...
the
...
virtual
...
server, like
| Code Block |
|---|
\_if (...) { update { ... request { } _ are not separate modules but a configuration language. Details about usage of this configuration language are available on its man } |
are not separate modules but a configuration language. Details about usage of this configuration language are available on its man page ("man unlang").