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 eduroam SP configuration of FreeRADIUS. 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.
...
We suggest to create an own certificate. FreeRADIUS makes this very easy by providing an automatic script for that purpose. Execute the
| Code Block |
|---|
/etc/raddb/certs/bootstrap
|
...
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 |
|---|
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 {
}
}
|
...
Compared to the eduroam SP config, you simply need to additionally mention the "eap" module in both the authorize and authenticate stanza of the file /etc/raddb/sites-enabled/default. It will then look like the following:
| Code Block |
|---|
authorize {
auth_log
suffix
eap
}
authenticate {
eap
}
|
...
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
}
}
}
|
...
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 |
|---|
icecold@group1.aq Cleartext-Password := "snowwhite"
otheruser@group1.aq Cleartext-Password := "swordfish"
|
...
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 |
|---|
realm group1.aq {
nostrip
}
|
...
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 |
|---|
client antarctica-flr-1 {
ipaddr = 172.20.1.2
netmask = 32
secret = secretstuff
require_message_authenticator = no
shortname = antarctica-flr-1
nastype = other
virtual_server = eduroam
}
|
...
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
}}
|
...
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
|
...
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
}
|
...