Read through the National Policy for eduroam South Africa
Read through the info for new participants if you want to join as an eduroam service provider and/or identity provider. Once you've done some planning, submit a registration request form.
Create DNS entries for your RADIUS server(s). e.g. eduroam0.example.ac.za and eduroam1.example.ac.za. The actual name is not important provided it is properly reflected in DNS, so you can use whatever your RADIUS server is already called. However, the RADIUS server(s) do need to be reachable from the Internet.
Let the national roaming operator (NRO) know when your DNS is working so that they can add your realm to the eduroam servers and provide you with a shared secret.
eduroam's magic is in the RADIUS configuration. Spend time making sure you understand how to do this right. We give information for commonly used RADIUS software, but if you have questions, please ask.
See information about certificates for eduroam. These are key to securing your users' credentials.
If you're making use of Active Directory, you may be able to make use of the Network Policy Server (NPS) feature. For information on how to configure this, read through GÉANT's documentation on Using Windows NPS as RADIUS in eduroam (local copy).
In that document, references to ntlr1.eduroam.no and ntlr2.eduroam.no should be replaced with the South African FLR servers flr-cpt.eduroam.ac.za and flr-jnb.eduroam.ac.za (you do need both!)
Note that the priority of servers in the eduroam-proxies RADIUS server group is important (pg. 21). You should set the one that's geographically closest to you (i.e. has the lowest ping time/latency) as the highest priority (i.e. 1) so you try it first. That means that Eastern, Northern & Western Cape sites should generally have flr-cpt.eduroam.ac.za as priority 1 and flr-jnb.eduroam.ac.za as priority 2; Gauteng, Limpopo, Mpumalanga, and Kwazulu-Natal sites should generally have flr-jnb.eduroam.ac.za as priority 1 and flr-cpt.eduroam.ac.za as priority 2.
The CISCO-CAPWAP-CONTROLLER.uninett.no client is an example demonstrating how you'd add your own wireless controller to NPS — consult your wireless vendor for details on how to configure your controller. Please use a different secret to the eduroam FLR servers.
If you wish to support anonymous outer identities, you may do so by configuring a realm manipulation rule in your connection request policy that rewrites "anonymous.*@" to "Guest" in the User-Name field.
For detailed instructions for FreeRADIUS, see GÉANT's documentation for IdPs and SPs. The South African-specific bits are summarised below (they're aligned with the GÉANT documentation, so should be drop-in replacements). There is also a template configuration available that has these changes incorporated.
In clients.conf add the two FLR servers:
client flr-cpt.eduroam.ac.za {
ipaddr = 155.232.195.20
shortname = flr-cpt
secret = MySharedSecret
require_message_authenticator = yes
nastype = other
# you have to create this in sites-enabled/ - see the GEANT docs
virtual_server = eduroam
}
client flr-jnb.eduroam.ac.za {
ipaddr = 155.232.195.21
shortname = flr-jnb
secret = MySharedSecret
require_message_authenticator = yes
nastype = other
virtual_server = eduroam
}In proxy.conf you should have realm rules to keep all the requests from example.ac.za + any sub-domains local and a default realm rule that forwards all other requests to the eduroam FLR servers:
proxy server {
default_fallback = no
}
# home server definitions
home_server flr-cpt {
type = auth+acct
ipaddr = 155.232.195.20
port = 1812
secret = MySharedSecret
status_check = status-server
}
home_server flr-jnb {
type = auth+acct
ipaddr = 155.232.195.21
port = 1812
secret = MySharedSecret
status_check = status-server
}
home_server_pool EDUROAM {
type = fail-over
#
# The order of the home_server entries in the pool is important. You
# should put the one that's geographically closest to you (i.e. has the
# lowest ping time/latency) at the top of the list so you try it first.
# That means Eastern, Northern & Western Cape sites should generally
# have flr-cpt at the top of the list and Gauteng, Limpopo, Mpumalanga,
# and Kwazulu-Natal sites should generally have flr-jnb at the top.
home_server = flr-jnb
home_server = flr-cpt
}
# your local realms
# leaving them blank stops them from ever being forwarded
realm LOCAL {
}
realm NULL {
}
realm example.ac.za {
}
# this catches subdomains
realm "~.+\\.example\\.ac\\.za$" {
}
# the default destination for unknown realms
# forward to the upstream FLR servers
realm "~.+$" {
pool = EDUROAM
nostrip
}
realm DEFAULT {
pool = EDUROAM
nostrip
}In the sites-available/eduroam virtual server the unlang stanza to add Operator-Name: needs to cover both FLR servers, like this:
if ("%{client:shortname}" != "flr-jnb" && "%{client:shortname}" != "flr-cpt") {
update request {
&Operator-Name := "1example.ac.za"
}
}Please also enable Chargeable-User-Identity in the sites-available/eduroam-inner-tunnel virtual server by adding cui-inner into the post-auth section. You will need to set cui_hash_key in policy.d/cui to protect your users' privacy.
The national policy for eduroam includes technical requirements for logging and timestamping. These ensure that you've sufficient information available should there be an abuse complaint or a request from a law enforcement agency.
Please ensure you've configured your RADIUS server to retain logs for the required retention period (currently 184 days, but check the policy). For FreeRADIUS this typically involves configuring syslog's rotation; in Windows NPS, you must edit your log retention policy in the Windows event viewer.
Although most modern operating systems do this automatically, you should also check that you synchronise your time from a reliable time source such as za.pool.ntp.org. This ensures that the timestamps in your logs can be correlated against other providers logs.
Make sure your firewall will allow UDP on ports 1812 and 1813 coming in from flr-cpt.eduroam.ac.za and flr-jnb.eduroam.ac.za to your servers (CIDR ranges 155.232.195.20/31 and 2001:4200:0:f::/64).
If you put your RADIUS servers behind NAT:
You may want to enable dynamic discovery by adding the following DNS record for your realm (if you use multiple realms [e.g. staff and students on different domains], you should add a separate NAPTR record for each of your realms):
example.ac.za. IN NAPTR 100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.eduroam.ac.za.Dynamic discovery makes international roaming much more efficient, so please do this if you expect any of your users to travel abroad. If you are interested, you can read about how the NAPTR record works.
Create a test user called nren_radius_test@example.ac.za on your server to test your IdP from another site. Supply this user to the NRO so that it gets configured in the eduroam monitoring system. This allows you to check that your users are able to log in from a remote site.
A service provider should be configured with an SSID called "eduroam" with "WPA2 Enterprise" user authentication and AES+CCMP encryption. You should not use WPA or WPA+WPA2 mixed mode, nor should you use TKIP encryption. Protected management frames (802.11w/PMF) should be set to "optional" unless your own users have older devices that do not support this. You may use WPA3 Enterprise Transition Mode (i.e. WPA2+WPA3) if you wish, but should not configure a WPA3-only network. Note that capitalisation is important — the eduroam SSID is always lowercase.
Your wireless network must be configured to authenticate using your RADIUS server. That's where the real magic of eduroam happens.
Please read through the national eduroam policy documents to see what rules an SP should comply with e.g. no portals, minimum service for visitors, etc. Note also the logging requirements.
It is normal practice to separate traffic from your own users and that of eduroam visitors. This should be done by dynamic VLAN assignment from the RADIUS servers. How you do this depends on your wireless infrastructure and RADIUS software. Two examples follow:
With FreeRADIUS you can usually place users and visitors in different VLANs by adding the following section in your virtual server config file (sites-enabled/eduroam)
post-auth {
# reply_log
Post-Auth-Type REJECT {
reply_log
attr_filter.access_reject
}
switch &Realm {
# VLAN settings for your local users
case "example.ac.za" {
update reply {
&Tunnel-type := "VLAN"
&Tunnel-medium-type := "IEEE-802"
&Tunnel-Private-Group-Id = "2505"
}
}
# VLAN settings for visitors to your campus
case {
update reply {
&Tunnel-type := "VLAN"
&Tunnel-medium-type := "IEEE-802"
&Tunnel-Private-Group-Id = "2506"
}
}
} # switch realm
}You can achieve the same thing in Windows NPS by using a Network Policy to alter the RADIUS Attributes and add the above Tunnel-* attributes (cf page 41 of the "Using Windows NPS as RADIUS in eduroam document").
Wireless infrastructure and NAS devices usually send the Calling-Station-ID attribute, which typically contains the MAC address of the client device connected to your wireless infrastructure. Please ensure you do not withhold or filter this.
If you've supplied the NRO with test credentials for your IdP, you automatically have test credentials you can use to test your eduroam wireless network.
Once you're sure it is working, let us know and we'll ship you a usizo usizo device to verify your deployment.
When everything is working, sign up on our eduroam management portal and check that we've captured your site's details correctly. You will use this portal to make changes to your configuration in future.
geteduroam is a configuration app that makes it easy for your users to connect to eduroam, irrespective of device or operating system. While it isn't the only Wi-Fi configuration utility you can use, it is freely available and specifically designed for eduroam.
To make the geteduroam app work for your institution, you need to provide the correct configuration for your IdP. This is done by by creating a profile in the eduroam CAT portal. You can gain access to CAT by enrolling your institution.