...
Setting
...
up
...
FreeRADIUS
...
This
...
section
...
describes
...
how
...
to
...
set
...
up
...
FreeRADIUS
...
for
...
an
...
IdP.
...
It
...
assumes
...
that
...
you
...
have
...
already
...
executed
...
the
...
configuration
...
steps
...
for
...
the
...
...
...
...
...
...
.
...
We
...
will
...
expand
...
that
...
configuration
...
to
...
turn
...
FreeRADIUS
...
into
...
a
...
simple
...
IdP.
...
N.B.:
...
even
...
if
...
you
...
are
...
going
...
to
...
have
...
an
...
IdP-only
...
installation,
...
the
...
eduroam
...
SP
...
configuration
...
for
...
FreeRADIUS
...
is
...
still
...
the
...
exact
...
same.
...
You
...
just
...
don't
...
define
...
any
...
own
...
Access
...
Point
...
clients
...
in
...
clients.conf.
...
Adding
...
IdP
...
support
...
in
...
FreeRADIUS
...
needs
...
several
...
steps
...
to
...
be
...
executed:
...
- a
...
- TLS
...
- server
...
- certificate
...
- needs
...
- to
...
- be
...
- created
...
- for
...
- EAP
...
- methods
...
- to
...
- work
...
- the
...
- desired
...
- EAP
...
- types
...
- need
...
- to
...
- be
...
- configured.
...
- the
...
- virtual
...
- server
...
- eduroam
...
- needs
...
- to
...
- be
...
- instructed
...
- to
...
- do
...
- tunneled
...
- EAP
...
- authentication
...
- a
...
- user
...
- database
...
- needs
...
- to
...
- be
...
- linked
...
- to
...
- the
...
- FreeRADIUS
...
- instance
...
- to
...
- authenticate
...
- the
...
- users
...
- a
...
- realm
...
- needs
...
- to
...
- be
...
- marked
...
- as
...
- to-be-authenticated-locally
...
- in
...
- the
...
- configuration
...
- the
...
- server
...
- needs
...
- to
...
- be
...
- prepared
...
- to
...
- process
...
- incoming
...
- requests
...
- *from
...
- *
...
- the
...
- upstream
...
- FLR
...
- server
...
These
...
steps
...
are
...
explained
...
in
...
detail
...
below.
...
For
...
the
...
user
...
database,
...
this
...
example
...
will
...
use
...
a
...
"flat
...
file"
...
with
...
usernames
...
and
...
passwords.
...
The
...
Goodies
...
section
...
contains
...
examples
...
for
...
MySQL
...
and
...
other
...
types
...
of
...
backend
...
databases.
TLS server certificate
While it is possible to buy and install a commercial TLS certificate, this is neither necessary (the trust settings of web-browser stores don't apply for EAP, so there are no "recognised" CAs) nor prudent (a commercial CA issues many certificates, and uncautious users might be tempted to accept other certificates from that same CA).
We suggest to create an own certificate. FreeRADIUS makes this very easy by providing an automatic script for that purpose. Execute the
| Code Block |
|---|
h6. TLS server certificate While it is possible to buy and install a commercial TLS certificate, this is neither necessary (the trust settings of web-browser stores don't apply for EAP, so there are no "recognised" CAs) nor prudent (a commercial CA issues many certificates, and uncautious users might be tempted to accept other certificates from that same CA). We suggest to create an own certificate. FreeRADIUS makes this very easy by providing an automatic script for that purpose. Execute the {code} /etc/raddb/certs/bootstrap {code} |
script.
...
It
...
will
...
generate
...
certificates
...
which
...
are
...
suited
...
for
...
EAP
...
authentication,
...
and
...
name
...
them
...
so
...
that
...
the
...
server
...
can
...
find
...
them
...
immediately
...
without
...
further
...
configuration.
...
Later,
...
for
...
the
...
supplicant
...
configuration,
...
you
...
will
...
need
...
to
...
include
...
the
...
generated
...
CA
...
certificate
...
into
...
your
...
supplicant
...
configurations.
...
EAP
...
type
...
configuration
...
The
...
file
...
/etc/raddb/eap.conf
...
defines
...
how
...
EAP
...
authentication
...
is
...
to
...
be
...
executed.
...
The
...
shipped
...
configuration
...
file
...
is
...
not
...
adequate
...
for
...
eduroam
...
use;
...
it
...
enabled
...
EAP-MD5
...
and
...
LEAP,
...
for
...
example;
...
which
...
are
...
not
...
suitable
...
as
...
eduroam
...
EAP
...
types.
...
Use
...
the
...
following
...
content
...
for
...
eap.conf
...
instead.
...
It
...
enables
...
PEAP
...
and
...
TTLS:
| Code Block |
|---|
{code} eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = whatever private_key_file = ${certdir}/server.key certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" } ttls { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } peap { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } mschapv2 { } } {code} |
A
...
common
...
question
...
regarding
...
this
...
definition
...
is:
...
"why
...
is
...
TLS
...
also
...
configured?
...
I
...
don't
...
want
...
it,
...
can
...
I
...
disable
...
it?"
...
The
...
answer
...
is:
...
the
...
TTLS
...
and
...
PEAP
...
sections
...
depend
...
on
...
the
...
tls
...
stanza
...
for
...
the
...
definition
...
of
...
which
...
server
...
certificates
...
to
...
use.
...
You
...
cannot
...
delete
...
the
...
stanza,
...
but
...
that
...
doesn't
...
mean
...
you
...
can't
...
effectively
...
disable
...
TLS:
...
the
...
tls
...
stanza
...
contains
...
the
...
ca_file
...
parameter.
...
Only
...
clients
...
with
...
a
...
TLS
...
client
...
certificate
...
from
...
this
...
CA
...
will
...
be
...
accepted.
...
We
...
have
...
just
...
created
...
a
...
brand-new
...
CA
...
with
...
the
...
"bootstrap"
...
script.
...
Simply
...
don't
...
issue
...
nor
...
distribute
...
any
...
client
...
certificates
...
from
...
this
...
CA,
...
then
...
nobody
...
will
...
be
...
able
...
to
...
log
...
in
...
with
...
EAP-TLS.
...
Note that in newer versions of FreeRADIUS (>3.0.14) there is a new tls-config section that allows you to configure the common TLS configuration without configuring the TLS EAP type. The config above is backwards compatable, but if you want to take advantage of the new section you can replace the name of the "tls" block above with "tls-config tls-common" and then reference it from each EAP type with "tls = tls-common" (the example eap config shows you how to do this).
Another question is regarding the mschapv2 section. For all practical purposes, the easy answer is that it is a piece of magic and needs to be there for PEAP to work. If you are curious regarding the gory details, please let us know.
Note that one parameter for both the ttls and peap stanza is "virtual_server = eduroam-inner-tunnel".
...
This
...
means
...
that
...
the
...
inner
...
EAP
...
authentication
...
will
...
be
...
carried
...
out
...
in
...
this
...
other
...
virtual
...
server,
...
which
...
we
...
will
...
define
...
later.
...
Virtual
...
server
...
eduroam:
...
enable EAP, make Operator-Name conditional
Compared to the eduroam SP config, you need to additionally mention the "eap" module in both the authorize and authenticate stanza of the file /etc/raddb/sites-enabled/eduroam so that your server can process EAP requests from your own userbase.
You should also make sure to only tag those incoming requests with the Operator-Name attribute which actually originate from your own WiFi gear - as an IdP, your own users roaming elsewhere will also be processed, but they should not carry your own Operator-Name. For the purposes of this wiki, let's assume that you are connected to one FLR server, and it is defined in your clients.conf with the shortname "antarctica-flr-1" (see below for the exact definition).
It will then look like the following:
| Code Block |
|---|
authorize { if ("%{client:shortname}" != "antarctica-flr-1") { update request { Operator-Name := "1yourdomain.tld" # the literal number "1" above is an important prefix! Do not change it! } } auth_log suffix eap EAP Compared to the eduroam SP config, you simply need to additionally mention the "eap" module in both the authorize and authenticate stanza. It will then look like the following: {code} authorize { auth_log suffix eap } authenticate { eap } {code} h6. Virtual server eduroam-inner-tunnel When the eap module has started with an authentication, it will first establish a TLS tunnel; this is done by enabling the module in the previous "eduroam" virtual server. After the TLS tunnel is established, the content (i.e. the tunneled authentication) is processed separately in this new virtual server. Create the file in /etc/raddb/sites-enabled/eduroam-inner-tunnel and give it the following content: {code} server eduroam-inner-tunnel { authorize { auth_log eap files mschap pap } authenticate { Auth-Type PAP { pap } Auth-Type MS-CHAP { mschap } eap } post-auth { reply_log Post-Auth-Type REJECT { reply_log } } } {code} Let's revisit the modules which this virtual server executes one after another: * auth_log: logs the incoming packet to the file system. This is needed to fulfill the eduroam SP logging requirements. Note that this log \*may\* contain the user's cleartext password if TTLS-PAP is used. You can log the packet with omitted User-Password attribute if you prefer; see the "Goodies" section for more details). * eap: if the EAP authentication contains another EAP instance inside, the module will decode it. This is the case for PEAP. * files: this module tries to find out the authoritative password for the user by looking up the username in the file * mschap: this module is in effect only if PEAP-MSCHAPv2 or TTLS-MSCHAPv2 is used. It will mark the packet as to be authenticated with MS-CHAP algorithms later. * pap: this module is in effect only if TTLS-PAP is used. It will mark the packet as to be authenticated with PAP alogrithms later. * reply_log: logs the reply packet to the file system h6. User database: flat file By default, the "files" module will use information in the file {code} / |
Virtual server eduroam-inner-tunnel
When the eap module has started with an authentication, it will first establish a TLS tunnel; this is done by enabling the module in the previous "eduroam" virtual server. After the TLS tunnel is established, the content (i.e. the tunneled authentication) is processed separately in this new virtual server. Create the file in /etc/raddb/sites-enabled/eduroam-inner-tunnel and give it the following content:
| Code Block |
|---|
server eduroam-inner-tunnel {
authorize {
auth_log
eap
files
mschap
pap
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type MS-CHAP {
mschap
}
eap
}
post-auth {
reply_log
Post-Auth-Type REJECT {
reply_log
}
}
}
|
Let's revisit the modules which this virtual server executes one after another:
- auth_log: logs the incoming packet to the file system. This is needed to fulfill the eduroam SP logging requirements. Note that this log *may* contain the user's cleartext password if TTLS-PAP is used. You can log the packet with omitted User-Password attribute if you prefer; see the "Goodies" section for more details).
- eap: if the EAP authentication contains another EAP instance inside, the module will decode it. This is the case for PEAP.
- files: this module tries to find out the authoritative password for the user by looking up the username in the file
- mschap: this module is in effect only if PEAP-MSCHAPv2 or TTLS-MSCHAPv2 is used. It will mark the packet as to be authenticated with MS-CHAP algorithms later.
- pap: this module is in effect only if TTLS-PAP is used. It will mark the packet as to be authenticated with PAP alogrithms later.
- reply_log: logs the reply packet to the file system
User database: flat file
By default, the "files" module will use information in the file
| Code Block |
|---|
/etc/raddb/users
|
for authenticating users. This file has a straightforward format
| Code Block |
|---|
etc/raddb/users {code} for authenticating users. This file has a straightforward format {code} icecold@group1.aq Cleartext-Password := "snowwhite" otheruser@group1.aq Cleartext-Password := "swordfish" {code} h6. Local authentication for your realm In the SP configuration, all requests were unconditionally forwarded to upstream. We will need to revisit the file |
Local authentication for your realm
In the SP configuration, all requests were unconditionally forwarded to upstream. We will need to revisit the file "proxy.conf"
...
and
...
mark
...
one
...
realm
...
to
...
NOT
...
proxy.
...
In
...
this
...
example,
...
we
...
will
...
use
...
"@group1.aq"
...
as
...
the
...
local
...
authentication
...
realm.
...
Simply
...
add
...
the
...
following
...
stanza
...
immediately
...
preceeding
...
the
...
"DEFAULT"
...
realm:
| Code Block |
|---|
{code} realm group1.aq { nostrip } {code} |
Since
...
the
...
stanza
...
doesn't
...
contain
...
a
...
server
...
pool
...
to
...
proxy
...
to,
...
this
...
realm
...
won't
...
be
...
proxied
...
and
...
instead
...
authenticated
...
locally.
...
This
...
stanza
...
works
...
only
...
for
...
users
...
who
...
correctly
...
use
...
the
...
full
...
username
...
format
...
"user123@group1.aq"
...
for
...
their
...
eduroam
...
login.
...
If
...
the
...
IdP
...
and
...
SP
...
are
...
colocated,
...
it
...
is
...
possible
...
to
...
*locally
...
*
...
also
...
accept
...
users
...
who
...
erronuously
...
omitted
...
their
...
realm
...
(just
...
"user123").
...
This is NOT permitted by the eduroam policy (read 6.3.2 bullet 6 under AAA Servers of the current service definition document: "The outer EAP identities (and with it, RADIUS User-Name attributes) for the IdP MUST be in the format of arbitrary@realm"). Allowing this also requires further configuration and it is strongly discouraged, because it will give such users a "halfways-working"
...
experience:
...
they
...
will
...
be
...
able
...
to
...
use
...
eduroam
...
when
...
on
...
their
...
own
...
IdP's
...
campus,
...
because
...
no
...
routing
...
information
...
needs
...
to
...
be
...
evaluated,
...
but
...
their
...
account
...
will
...
fail
...
at
...
all
...
other
...
locations.
...
Therefore,
...
this
...
guide
...
does
...
not
...
include
...
instructions
...
for
...
that
...
kind
...
of
...
setup.
Processing incoming requests
As an eduroam IdP, your users can go to other eduroam hotspots around the globe. They will still be authenticated at your server. In these roaming cases, your upstream FLR servers will send Access-Requests to your server. Surprisingly, it is very simple to configure that: these upstream servers are simply clients - just like an Access Point. So, simply add client stanzas for your FLR servers into clients.conf:
| Code Block |
|---|
h6. Processing incoming requests As an eduroam IdP, your users can go to other eduroam hotspots around the globe. They will still be authenticated at your server. In these roaming cases, your upstream FLR servers will send Access-Requests to your server. Surprisingly, it is very simple to configure that: these upstream servers are simply clients - just like an Access Point. So, simply add client stanzas for your FLR servers into clients.conf: {code} client antarctica-flr-1 { ipaddr = 172.20.1.2 netmask = 32 secret = secretstuff require_message_authenticator = noyes shortname = antarctica-flr-1 nastype = other virtual_server = eduroam } {code} That's it\! Now your server is prepared for eduroam IdP operation\! You can add users to your "database" by amending the "users" file; if you do, you will unfortunately have to restart FreeRADIUS so that it picks up the change. h6. Goodies *Omitting User-Password in inner authentication logs* *adding VLAN assignment attributes* *Using MySQL as user database backend* 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. \\ h5. 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|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} 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|http://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|http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip]. \\ \\ \\ h5. 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|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} 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|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.). \\ h5. 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} user = radiusd group = radiusd {code} \\ 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} 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} 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, pre_proxy_detail, post_proxy_detail, reply_detail. \\ {code} detail auth_log { detailfile = ${radacctdir}/%Y%m%d/eduroam/auth-detail detailperm = 0600 } {code} * 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} 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 2.0.4, the server will ship with standard defaults that are compatible with eduroam operation without the need for modifications. \\ {code} attr_filter attr_filter.pre-proxy { _attrsfile = ${confdir}/attrs.pre-proxy } {code} The remaining parts in the virtual server, like {code} if (...) { update request { } } {code} are not separate modules but a configuration language. Details about usage of this configuration language are available on its man page ("man unlang"). h5. User authentication: configuring an eduroam IdP Configuring an IdP involves: * Configuring the server as EAP endpoint. * Configuring the local database backend. EAP configuration happens in the file eap.conf (downloadable from [http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip|http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip]). This example, eap.conf file is configured to accept both TTLS and PEAP requests and process them with the same backend. For a discussion of when to use TTLS and when PEAP, please refer to section 3.2.3.5 of this document. The following notes refer to different modules within the file: * In the tls section, the server certificate that is presented to the users while they authenticate is defined. certdir, private_key_... have to point to the appropriate files on the server. It appears confusing for most new administrators that tls needs to be defined even though EAP-TLS is not a desired authentication method. This is because the ttls and peap sections share the certificate parameters and rely on the existence of the tls stanza. Unwanted EAP-TLS authentication can be prevented by pointing cadir to a dummy Certification Authority (like the one that is created on first server startup) which never issues proper client certificates. * The ttls and peap sections denominate a dedicated virtual server to handle the inner tunnel request (which happens after the TLS handshake with the supplicant has completed). Note that there needs to be an empty mschapv2 stanza in eap.conf to make PEAP work -- this is due to internal server workings only. * To include EAP into the virtual server eduroam (see section A.2.4 "Virtual server definition for eduroam: sites-enabled/eduroam"), only two lines need to be added; the new virtual server "eduroam-innertunnel" (which we defined in eap.conf before) needs be set up to do the actual user authentication, and the module eap must be listed at the end of the _authorise_ and _authenticate_ sections.: server eduroam-inner-tunnel { authorize { auth_log files ldap mschap pap } authenticate { Auth-Type LDAP Unknown macro: { ldap } Auth-Type PAP Unknown macro: { pap } Auth-Type MS-CHAP Unknown macro: { mschap } } preacct { } accounting { detail sql } session { } post-auth { reply_log Post-Auth-Type REJECT Unknown macro: { reply_log } } pre-proxy { } post-proxy { } } The most notable difference between the inner server and the outer is that the inner tunnel does not do EAP. Instead, it uses the ldap module in the authorize and authenticate sections to authenticate users against the ldap backend. Note that the ldap module is configured in radiusd.conf. You have to enter the appropriate connection details to your LDAP server there and open firewall ports from the RADIUS server to the LDAP server if need be. Also note that this virtual server does not call the suffix module. This means the inner request does not get proxied elsewhere. This is a standard security measure in eduroam. The virtual server definition also includes the files module. When doing LDAP authentication, this is optional. In the example file, we use this module to have test users in the flat file "users" in order to have a possibility of debugging authentication. Once the authentication against the file works and the LDAP connection is set up properly, the files module is only needed for advanced topics like VLAN assignment. • For an initial setup of the users file, administrators should delete all existing entries and add only the following line in the file: test@domain.tld _Cleartext-Password := "<test password>"_ This creates a test user with the name "test@domain.tld" and a password. It can be used to test authentication. * In case a VLAN assignment should be done, the users file needs to contain the corresponding RADIUS attributes, like in the following example for VLAN 313: DEFAULT <assignment conditions here> _Tunnel-Type =VLAN,_ _Tunnel-Medium-Type =IEEE-802,_ _Tunnel-Private-Group-Id =313_ * The configuration of the ldap module itself happens in radiusd.conf. This config stanza is extensively documented in the file, so below just a simple example of a sample configuration (based on an eduPerson LDAP schema). _modules {_ _ ldap {_ _ server = "localhost"_ _ identity = "cn=RADIUS,dc=domain,dc=tld"_ _ password = "<secret for identity dn>"_ _ basedn = "ou=student,dc=domain,dc=tld"_ \_ filter = "(eduPersonPrincipalName=% Unknown macro: {User-Name} )"\_ _ start_tls = no_ _}_ _\# Mind the Linewrap\!_ * If logging of accounting requests to a database is desired (see below), it is also wise to extend the accounting key in the acct_unique module to make accounting more robust. _acct_unique {_ \_ key = "User-Name, Acct-Session-Id, Calling-Station-Id,\_ _ Called-Station-Id, NAS-IP-Address, NAS-Port"_ _}_ h5. Setting up accounting in the SQL database All accounting information is logged into the MySQL database. The configuration is in the file /etc/raddb/sql.conf. The content of this file should be replaced with that found in [http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip|http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip]. h5. Logging the client IP address as Service Provider (Optional) The client IP address is logged in the DHCP log file. However this information can also be stored in the ACCOUNTING table with other accounting data and thus provide easy access to that data. A Sysadmin needs to set-up a script to update the SQL database information with the assigned IP address. The client IP address is determined by tailing the DHCP log file and monitoring all IP assignments. The script also monitors active connections and cleans up accounting (closes accounting) for stale connections. SNMP access to Access Points is required. The script is available from here: [http://www.eduroam.si/uploads/CN/eC/CNeCC3Uc7XI9Tw_dLtwYZg/eduroam_monitor-20060809.tar.bz2|http://www.eduroam.si/uploads/CN/eC/CNeCC3Uc7XI9Tw_dLtwYZg/eduroam_monitor-20060809.tar.bz2] The access points need to be registered with the script. This is done by entering the needed access point data into the database: _USE radius;_ _create table access_points (_ _ `IP address` varchar(100) PRIMARY KEY NOT NULL,_ _ `snmp secret` varchar(100) NOT NULL default '',_ _ `radius secret` varchar(100) NOT NULL default '',_ _ `root username` varchar(100) NOT NULL default '',_ _ `root password` varchar(100) NOT NULL default ''_ _) TYPE=MyISAM;_ h5. More information The original Slovenian Eduroam technical specifications and sample configuration site:[http://www.eduroam.si|http://www.eduroam.si/] ARNES AAI technical support e-mail address: aaa-podpora@arnes.si FreeRADIUS files:[http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip|http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip] Eduroam-in-a-box web configuration tool:[http://eduroam.sourceforge.net|http://eduroam.sourceforge.net/] |
CUI for eduroam IdP
To use the Chargeable-User-Identity (CUI) you must already use the Operator-Name attribute. This documentation is only for FreeRADIUS 3.0.X release.
Modify the log module
Edit "eduroam_cui_log" file in the mods-available/ subdirectory and add the following lines to your virtual inner server :
| Code Block |
|---|
...
linelog cui_inner_log {
# filename = syslog
filename = ${logdir}/radius.log
format = ""
reference = "inner_auth_log.%{%{reply:Packet-Type}:-format}"
inner_auth_log {
Access-Accept = "%t : eduroam-inner-auth#VISINST=%{request:Operator-Name}#USER=%{User-Name}#CSI=%{%{Calling-Station-Id}:-Unknown Caller Id}#NAS=%{%{Called-Station-Id}:-Unknown Access Point}#CUI=%{%{%{reply:Chargeable-User-Identity}:-%{outer.reply:Chargeable-User-Identity}}:-Local User}#RESULT=OK#"
Access-Reject = "%t : eduroam-inner-auth#VISINST=%{request:Operator-Name}#USER=%{User-Name}#CSI=%{%{Calling-Station-Id}:-Unknown Caller Id}#NAS=%{%{Called-Station-Id}:-Unknown Access Point}#CUI=%{%{%{reply:Chargeable-User-Identity}:-%{outer.reply:Chargeable-User-Identity}}:-Local User}#RESULT=FAIL#"
}
} |
Use policy and module in your eduroam-inner-tunnel virtual server
Add 'cui-inner' (policy already defined, you don't need to change it) and 'cui_inner_log' in post-auth section :
| Code Block |
|---|
server eduroam-inner-tunnel {
...
post-auth {
reply_log
cui_inner_log
cui-inner
Post-Auth-Type REJECT {
reply_log
cui_inner_log
}
}
...
} |
That's it! Now your server is prepared for eduroam IdP operation! You can add users to your "database" by amending the "users" file; if you do, you will unfortunately have to restart FreeRADIUS so that it picks up the change.
Goodies
Omitting User-Password in inner authentication logs
By default, the "detail" modules log every attribute as it was received. For inner authentications with TTLS-PAP, this means that the attribute "User-Password" with the user's perceived password will be logged. This is often considered harmful. You can deactivate it by blacklisting the attribute in the auth_log module in /etc/raddb/modules/auth_log:
| Code Block |
|---|
detail auth_detail {
...
suppress {
User-Password
}}
|
adding VLAN assignment attributes
You can mark every user with a VLAN where he should be put into. This is done by assigning "reply items" to the user in the authentication database. In our flat file example, reply attributes are in a separate line, indented by a tab. To put our two example users into VLANs 17 and 42, respectively, the entries would look like the following:
| Code Block |
|---|
icecold@group1.aq Cleartext-Password := "snowwhite"
Tunnel-Type := VLAN,
Tunnel-Medium-Type := IEEE-802,
Tunnel-Private-Group-ID := 17
otheruser@group1.aq Cleartext-Password := "swordfish"
Tunnel-Type := VLAN,
Tunnel-Medium-Type := IEEE-802,
Tunnel-Private-Group-ID := 42
|
Using SQL as user database backend
Using a flat file as in our example scales very poorly. You can use arbitrary database backends instead; the FreeRADIUS documentation can give you an overview. If you wish to use SQL, changing our example configuration is very easy: simply replace the "files" line in eduroam-inner-tunnel:authorize with "sql". You'll need to specify the connection details for your SQL backend in the corresponding module ( /etc/raddb/modules/sql ).
The schema which FreeRADIUS uses to store user information is similarly structured to the "users" file: a table radcheck holds the check items (i.e. the username and password), and the radreply table contains the reply items (for example VLAN memberships, as explained above).
Mandating or forbidding use of anonymous outer identity
eduroam at large supports anonymous outer identities for user logins. It is at the discretion of eduroam IdPs whether they want to
- mandate that their users use an anonymous outer identity
- forbid their users to use an anonymous outer identity
- be agnostic in that respect
Configuring any one of the three choices is done with only a few lines of configuration. The easiest choice is being agnostic: no configuration is necessary, since there is no link between the inner and outer User-Name attribute in FreeRADIUS.
If you want to mandate the use of anonymous outer identities, the recommended way is using the identity "@realm" (i.e. the part left of the @ sign should be empty). You can enforce that only this outer User-Name is allowed to proceed to EAP authentication by adding the following to the authenticate section:
| Code Block |
|---|
if ( User-Name != "@realm" ) {
fail
}
|
If you want to forbid usage of anonymous outer identities, you can do this by comparing the two presented User-Name attributes of the outer and inner authentication. You can only do this in the eduroam-inner-tunnel virtual server obviously, since only that server has access to the inner identity. Put the following into the "authenticate" section of eduroam-inner-tunnel:
| Code Block |
|---|
if ( User-Name != outer.User-Name ) {
fail
}
|
More information
Eduroam-in-a-box web configuration tool:http://eduroam.sourceforge.net