Two features on the eduroam Support Server enable participating organisations to utilise their RADIUS infrastructure in more flexible ways.

Designation of RADIUS Server Function

Many organisations participating in eduroam have deployed multiple ORPS and in many cases wish to dedicate these to particular functions (eg. authentication, accounting, testing).

The first new feature on the eduroam(UK) Support Server is the option for administrators to select from a list of four different types what function their ORPS performs:

• Authentication - ORPS can authenticate home users
• Accounting - ORPS can receive accounting packets
• Authentication & Accounting - ORPS can receive both (default)
• Client only – ORPS initiates exchange with NRPS, but NRPS will not send packets to ORPS

The selection can be made on the RADIUS proxy servers page under eduroam Configuration where a new ‘Function’ field will be found. To change the OPRS designation, click on the drop down menu and select the required function. Then click on [Update RPS] at the bottom of the section.

The NRPS are set to receive packets from any ORPS configured in the eduroam Support system so in all the above cases the ORPS is able to send packets to the NRPS, but by setting the function of the ORPS, the type of traffic that the NRPS sends to it can be controlled. This will allow the eduroam Administrator to dedicate ORPS to particular roles.

Nb an organisation providing a Home (Identity Provider) service must always have at least one ORPS that can deal with authentication (otherwise the NRPS won’t be able to proxy the Access Requests from the remote site to yours!)

All existing systems have, by default, been set to Authentication & Accounting as this was their previous behaviour and when creating new ORPS this is the default option.

RADIUS Server Test/Development Designation and Test Realm Handling

The second facility is the ability for eduroam administrators to designate a RADIUS ORPS server as a 'Test/Development' unit ('testdev') and put it into protected test-mode as far as the NRPSs are concerned. The server remains peered with the NRPS, but the effect of designating the unit as ‘testdev’ is to shelter it from being deluged with RADIUS traffic in order to enable you to carry out specific EAP tests yourselves.

By designating a server as ‘testdev’, the server will be set in the eduroam NRPSs realm handling logic to protected test-mode with the result that the following packets will NOT be forwarded to it from the NRPS:

• production service RADIUS packets
• NAGIOS EAP monitor test probe RADIUS packets
• eduroam Support on demand EAP test RADIUS packets

(Prior to the introduction of this testdev designation feature, RADIUS packets, for example resulting from a remote user attempting to authenticate at a Visited site, destined for ‘youruniversity.ac.uk’ would have been forwarded to any one of the ORPS you had configured – including any test/development pre-production servers).

This facility allows eduroam administrators to bring up a new server, integrate it into the system, configure shared secrets, sort out firewalling etc., without fear that the NRPS will bombard it with production requests. This condition is also ideal for testing new server settings.

Only RADIUS traffic with the ‘test’ prefix to the realm will be sent to the ‘testdev’ ORPS. If you have more than one registered realm, then traffic prefixed with ‘test’ on any of your realms will be sent to the ‘testdev’ server. In other words, if you select an ORPS to be a 'testdev' system then only traffic targeted to your registered realms with a 'test' prefix will be sent to it.

For example if you have two realms registered, youruniversity.ac.uk and learning.ac.uk;

Both testuser@test.youruniversity.ac.uk and testing_123@test.learning.ac.uk will be sent to your testdev box.

Whilst testuser@youruniversity.ac.uk will be sent to your normal ORPS

Setting an ORPS to testdev allows organisations to bring up a test box and for it to only be sent specific test traffic during logic/rules checking etc. eduroam administrators will need to generate such test traffic themselves. There are several ways to do this. You can use any EAP command line tool, e.g. rad_eap_test, radeapclient and eapol_test. Newer versions of wpa-supplicant include eapol_test. If you use RHEL7/CentOS7 you'll find eapol_test once wpa-supplicant has been installed. Use 'testuser@test.youruniversity.ac.uk' as the username to do a 'loopback test' to the new systems. This can be done by using your live RADIUS systems:

'testuser@test.youruniversity.ac.uk' -> Production ORPS -> NRPS -> Testdev ORPS

Nb. you do NOT have to specifically configure a ‘test’ sub-realm (eg.‘test.youruniversity.ac.uk’) in the Realms section of eduroam Support in order for this test realm handling facility to work. 

Nb. The manually initiated ICMP test from the eduroam Support test page remains operational even when the test ORPS is set to ‘testdev’ – the test server can still be pinged.

Nb. The manually initiated EAP test from the eduroam Support test page is designed to send test RADIUS traffic to the normal production realms, so by setting the ORPS to ‘testdev’ the test is effectively disabled. The same is true of the NAGIOS automatic EAP probe monitor test. These tests are designed to check / troubleshoot production servers.

The designation of the RADIUS server as test or full service can be made on the RADIUS proxy servers page under eduroam Configuration where a new ‘Test/Development’ field will be found.

The default setting is ‘No – Full Service’. To change the OPRP designation to test/dev, click on the drop down menu and select ‘Yes – Only send test realm traffic’. Then click on [Update RPS] at the bottom of the section.