...
FreeRADIUS is written in C and can be compiled with the usual UNIX compilation sequence. After unpacking the source into a directory of your choice, do
| Code Block |
|---|
./configure --prefix=<your preferred install dir> --sysconfdir=<your preferred configuration base dir>
make
make install
|
...
The following lines are important for eduroam operation: a server status probing mechanism called Status-Server is enabled in the security section. Make sure the config file contains the following security stanza
| Code Block |
|---|
security {
max_attributes = 200
reject_delay = 0
status_server = yes
}
proxy_requests = yes
|
FreeRADIUS is capable of both IPv4 and IPv6. The following four sections enable both authentication and accounting processing with IPv4 and IPv6 (you can leave out the IPv6 part if your server shouldn't do IPv6):
| Code Block |
|---|
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 logic in the server is defined by activating certain modules in a certain order. These modules are separately defined and configured in the /etc/raddb/modules/ subdirectory. The order of activation of these modules is defined in so-called virtual servers, which are defined in the /etc/raddb/sites-enabled/ directory. For our eduroam SP purposes, we only need one virtual server "eduroam". It needs to contain as a minimum:
| Code Block |
|---|
server eduroam {
authorize {
auth_log
suffix
}
authenticate {
}
preacct {
suffix
}
accounting {
}
post-auth {
reply_log
Post-Auth-Type REJECT {
reply_log
}
}
pre-proxy {
pre_proxy_log
if (Packet-Type != Accounting-Request) {
attr_filter.pre-proxy
}
}
post-proxy {
post_proxy_log
attr_filter.post-proxy
}
}
|
The multitude of sections in this above configuration is often confusing to new-comers. The order of execution when proxying a request are:
| No Format |
|---|
authorize → authenticate → pre-proxy
|
Then, the packet is proxied to an upstream server. When the reply comes back, the execution continues:
| No Format |
|---|
post-proxy → post-auth
|
Every stanza contains names of modules to be executed. Let's revisit them one after another:
...
FreeRADIUS defines the connected RADIUS clients in the file /etc/raddb/clients.conf. This file needs to hold all your connected Access Points and/or wired eduroam-enabled switches. You set a shared secret for each client and define these in the config file as follows:
| Code Block |
|---|
client antarctica-access-point-1 {
ipaddr = 172.25.1.55
netmask = 32
secret = yoursecret12345
shortname = southpole-11g
virtual_server = eduroam
}
|
...
If you want to connect your clients over IPv6, the syntax is only slightly different:
| Code Block |
|---|
client antarctica-access-point-2 {
ipv6addr = 2001:db8:1:789::56
netmask = 128
secret = yoursecretABCDE
shortname = southpole-11n
virtual_server = eduroam
}
|
...
FreeRADIUS contains a wealth of options to define how requests are forwarded. These options are defined in the file /etc/raddb/proxy.conf. For a single eduroam SP, these may seem overkill, but the required definitions for that purpose are rather static. Assuming you have two upstream servers to forward requests to, the following configuration will set these up - you only need to change the IP addresses and shared secrets in home_server stanzas.
| Code Block |
|---|
proxy server {
default_fallback = yes
}
home_server antarctica-flr-1 {
type = auth+acct
ipaddr = 172.20.1.2
port = 1812
secret = secretstuff
status_check = status-server
}
home_server antarctica-flr-2 {
type = auth+acct
ipv6addr = 172.25.9.3
port = 1812
secret = secretstuff
status_check = status-server
}
home_server_pool EDUROAM {
type = fail-over
home_server = antarctica-flr-1
home_server = antarctica-flr-2
}
realm DEFAULT {
pool = EDUROAM
nostrip
}
|
...
- creating a user "radiusd" and group "radiusd"
- giving all configuration files in /etc/raddb ownerships for that user radiusd + group radiusd
- changing these two parameters in /etc/raddb/radiusd.conf:
| Code Block |
|---|
user = radiusd
group = radiusd
|
...
F-Ticks is using syslog to deliver user login statistics. You can enable syslog logging for login events by defining a linelog module. In the /etc/raddb/modules/ subdirectory, create a new file "f_ticks":
| Code Block |
|---|
linelog f_ticks {
filename = syslog
format = ""
reference = "f_ticks.%{%{reply:Packet-Type}:-format}"
f_ticks {
Access-Accept = "F-TICKS/eduroam/1.0#REALM=%{Realm}#VISCOUNTRY=LU#VISINST=YOUR-ID#CSI=%{Calling-Station-Id}#RESULT=OK#"
Access-Reject = "F-TICKS/eduroam/1.0#REALM=%{Realm}#VISCOUNTRY=LU#VISINST=YOUR-ID#CSI=%{Calling-Station-Id}#RESULT=FAIL#"
}
}
|
...
You need to enable this new module in the post-auth section of your virtual server eduroam:
| Code Block |
|---|
post-auth {
reply_log
f_ticks
Post-Auth-Type REJECT {
reply_log
f_ticks
}
}
|
...
You would need to delete the DEFAULT realm and replace it with the following regular expression realm statement *at the end of your proxy.conf*:
| Code Block |
|---|
realm /.*/"~.+$" { ... } |