Implementing eduroam Roadmap - Part 3

Download as PDFDownload as PDF

Contents

Network and technology service docs

Last updated: 30/05/2023

On this page sections (11),12 - 16:

  1. RADIUS Server configuration to support Home user authentication when on-campus and roaming; and attributes filtering
  2. Wi-Fi service and establishment of a VLAN/network service for eduroam
  3. Firewall configuration to support eduroam network service
  4. RADIUS server software configuration and interoperation with user database
  5. DNS Name Server Configuration
  6. Test facilities on eduroam Support Server / Visitor Test / Testing a new ORPS

See Part 1 for sections 1 - 7:

  1. Concepts and terminology
  2. Deciding your service type and planning your eduroam implementation
  3. Choose RADIUS server platform and plan network connectivity for ORPS
  4. Joining eduroam(UK) and selecting your realm
  5. The eduroam Support Server website; input organisation/site details, realm name, test account
  6. Install your RADIUS Server (ORPS)
  7. Acquire server certificate for ORPS/NAS

See Part 2 for sections 8 - 11:

  1. Firewall configuration to permit RADIUS servers to work with NRPS
  2. Add your ORPS to the eduroam(UK) RADIUS Infrastructure via support website and acquire your shared secrets
  3. RADIUS server proxying to support a Visited service and attributes filtering

See Part 4 for sections 17 - 23:

  1. RADIUS server log keeping and interpretation of logs
  2. Monitoring your own service
  3. Setting up user devices - 'onboarding users'
  4. Q.A. test of your eduroam implementation
  5. Promote eduroam at your organisation - your eduroam web site
  6. Keep your configuration details data on the eduroam Support server up to date
  7. Planning Ahead and Developing your eduroam Implementation

Part 3

For more information on this topic see:

10.4 Configure Rejection of Malformed Usernames

Sending Access-Request packets to the national proxy infrastructure with malformed 'bad' usernames, more particularly those with errors in the realm component, is bad practice; definitely not good-neighbourly. Due to the prevalence of misentered usernames in laptops and mobile phones and in the case of the latter, the 'auto-correct' feature of the phone software compounds this problem, the NRPS are bombarded with Access-Requests that will never result in successful authentications. Instead, the finite resources of the NRPS become tied up waiting for responses from the Home ORPS or from the eduroam.org ETLRs in the case of non-existent non-UK realms. To avoid the above situation you should configure your ORPS to drop authentication attempts by clients with bad usernames. Bad usernames are essentially those that do not conform to 'username@FQDN' - the formal description can be found in RFC 4282, which is largely correct.

To avoid the above, FreeRADIUS depoyments should utilise the Policy engine. There are now numerous examples included in the FreeRADIUS config. It is also possible to avoid the above situation is described at:www.wireless.bris.ac.uk/netcomms/eduroam-realm-checks.conf.

For Microsoft NPS and IAS this is described at: Microsoft NPS 2008R2 config to avoid bad usernames flooding NRPS.

NB. There is nothing that can be done at present to avoid the RADIUS infrastructure from being hit by Access-Requests from users who have left their organisation but still have eduroam credentials configured in their devices. User education to remove eduroam configuration from devices when they leave is the best current solution.

10.5 Configure Injection of Operator-Name Attribute (FreeRADIUS, Radiator, ClearPass and Cisco ISE)

If you are deploying a FreeRADIUS, Radiator, Aruba ClearPass or Cisco ISE/ACS v5.4, you should configure your system to inject the Operator-Name attribute, correctly formed for your organisation, into Access-Request packets forwarded to the NRPS. The background, rationale and one method of achieving this are documented in Advisory: Injection of Operator-Name attribute (Aug 2011).

11. RADIUS Server configuration to support Home User Authentication when Roaming and on Campus; and Attributes Filtering

In this step you will a) add your ORPS to the NRPS config as Authenticators and b) add the NRPSs to your ORPS RADIUS configuration as Clients. This enables the NRPS to send authentication requests to your ORPS and readies your ORPS to support a Home service. You will also need to take steps to ensure that your authentication service is not vulnerable to harmful attributes being sent by sites your users roam to and that you do not send harmful attributes that may 'poison' your roaming users' authentication attempts. 

The first step involves you updating your ORPS settings on the eduroam Support server. 

Step b involves configuration of your ORPSs - although the GUIs/config files for various RADIUS platforms are different, there are broadly similar steps that need to be taken for all RADIUS server platforms:

  1. Defining client RADIUS servers (the NRPSs) and pooling them into an eduroam RADIUS clients group
  2. Setting up processing logic with dependency conditions that will identify authentication request types arising from various sources and configure how these request types are to be handled (setting Network Policies/Services/Authentication conditions) for the three types i) your roaming users ii) your own users on campus iii) visitors on campus
  3. Configuring authentication of your own users against your user directory 

In this section, (i) and (ii) are addressed. Authentication is covered in section 14.

Contents:

  • Addition of your ORPS as RADIUS authenticators in the NRPS configuration
  • Addition of NRPS as RADIUS clients in your ORPS configuration
  • Authentication request handling for your own users a) when roaming and b) when on-campus
  • FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang
  • Special note for Microsoft NPS Configuration - setting the Framed-MTU attribute in Roaming User Network Policy
  • Special note for Microsoft NPS Configuration - ensure that support TLS1.2 is enabled
  • Testing your Configuration - shared secrets check; authentication against local database; remote authentication
  • If applicable, configure peering with other RADIUS servers on your network
  • Configure Attributes Filtering
  • FAQs/Resources

Home service - Configuring peering of your ORPS with the NRPS to support authentication requests from for your own roaming users: You now need to peer your ORPS(s) with the NRPSs so that RADIUS messages can be exchanged to authenticate your users when they roam to eduroam campuses operated by other member organisations. (Nb. This is not applicable to Visited-only deployments).

With respect to setting up a Home service, since a there are two ends of a RADIUS conversation there are two operations:

Addition of the NRPS to the RADIUS clients configuration of your ORPSs - so your ORPS are able to receive RADIUS packets from the NRPS.

Addition of your ORPS to the remote RADIUS servers/authenticators configuration of the NRPSs - so the NRPS send RADIUS packets to your ORPS

(After you have completed the peering operation you will need to configure authentication of requests received from the NRPSs against your user directory (AD/LDAP) - see section 14).

Home service - Configuring your ORPS to support authentication requests from your own users on your campus: You will need to configure realm handling and local authentication of auth requests from your wireless LAN from the eduroam SSID against your user directory (AD/LDAP). (Nb. this is not applicable to any Home-only deployments that do not have a local Wi-Fi service).  

11.1 ​Home service - Add your ORPS as remote RADIUS servers/authenticators on the NRPSs

This step configures the NRPS to send authentication requests from your roaming users to your ORPS, necessary for your ORPS to support a Home service: This will configure the NRPS to send RADIUS authentication request packets to your ORPS.

  • If not already logged in, log in to Support Server: via https://support.eduroam.uk/login
  • Click on the 'Configure' tab.
  • In the green 'RADIUS servers' click on the relevant ORPS line. The server details popup box will appear.
  • Scroll down to the RADIUS settings box and click on the 'Authenticate requests' tickbox.
  • Scroll down and click [Save]. The new setting will be added to the ORPS config file on Support and at the next hourly NRPS config update, will be propagated to all three NRPS.

11.2 Home service - Add the NRPSs as RADIUS clients on your ORPS

This step configures your ORPS to accept RADIUS authentication request packets from the NRPS. The addition of the NRPS to the RADIUS clients configuration of your ORPSs allows your ORPS to receive RADIUS packets from the NRPS thereby supporting your roaming users.

  • If not already logged in, log in to Support Server: via https://support.eduroam.uk/login
  • Click on the 'Configure' tab.
  • In the green 'RADIUS servers' click on the relevant ORPS line. The server details popup box will appear. In the RADIUS settings box  you will see the unique shared secrets that were generated when your registered your RADIUS server. You will need to copy each key and paste it into the relevant RADIUS clients configuration files/fields on your ORPS servers. Accuracy is essential when transcribing shared secrets. Ensure that there are no extra characters (white space at beginning or end of the shared secret) and ensure that you are copying and pasting with a correct UTF-8 or ASCII buffer so that characters do not get adjusted when pasting from your web browser.

There are three NRPSs and any one may try to communicate with your ORPS systems, so you must allow all NRPS to talk to your ORPSs. 

IP Addresses or FQDNs?:

We recommend that the NRPS are added to your systems using explicit IP addresses and not the roaming1/2/3.ja.net FQDNs. Using IP addresses keeps things simple and means that you are not dependent on DNS lookups when you reboot your servers. 

(The NRPSs support IPv6 and the addresses are resolvable through DNS. Windows 2012R2 and above NPS users note - NPS is IPv6-aware so if FQDNs are used the ORPS will do a DNS lookup and may select the v6 address and if your site is not fully IPv6 enabled, the ORPS will attempt to tunnel v6 via v4 resulting in communications failure with the NRPS).

RADIUS Accounting: In the past you needed to configure your ORPS for roaming0.ja.net, roaming1.ja.net and roaming2.ja.net clients to have Accounting passes as well as being set as RADIUS clients and servers for authentication handling, hence in the past the need to support port 1813 as well as 1813 on UDP, but Accounting is now not handled by the NRPS and you will not be forwarded Accounting packet from the NRPS. 

Hints

FreeRADIUS: edit clients.conf file

Microsoft NPS: in Templates Management create RADIUS Shared Secret Template and in RADIUS Client and Servers, create RADIUS Clients

Aruba Clearpass: i) Configuration > Network > Devices > Add. Enter the NRPS names, IP addresses, shared secrets. Use 'IETF' as Vendor Name. No not enable RADIUS CoA for the NRPS (only for your WLCs).  ii) Configuration > Network > Device Groups > Add. Create a group for the eduroam NRPSs (e.g. 'eduroam NRPSs') and add the NRPSs to the list of servers in the group. 

iii) For authentication (see step 14 below): Configuration>Services>Add. Create a Service for your roaming users (e.g. Requests From NRPS). Click on Service tab and define the Conditions to be matched: a) Connection, ‘Src-IP-Address’ belongs to server group 'eduroam NRPSs' b) Authentication, 'Full-username' matches regex - see Clearpass guide . You will also need to specify the authentication method you are supporting and the authentication source e.g. servername of your domain controller/LDAP database). 

Conditions: For roaming user authentications do NOT define Conditions based on RADIUS attributes that are not guaranteed to be in the Access-Request from your roaming users at a Visited sites you have no control over! e.g. Do NOT specify NAS-Port-Type=wireless-802.11 (19). The only attributes that are guaranteed to be present are listed in section 2.1 of the Technical Specification.

Cisco ISE: Configuration for eduroam

i) Administration > Network Resources > Network Devices > +Add.

Configure all three NRPS roaming0, roaming1 and roaming2. Set device type to 'eduroam'. Enter the shared secret with the NRPS in the RADIUS Authentication Settings panel.

ii) Administration > Network Resources > Network Device Groups +Add e.g. 'eduroam NRPS'

Add all three NRPS to the Network Device Group

Radiator: edit the <client> clause to include the three NRPS, complete with shared secret and directive, 'RequireMessageAuthenticator'

The following applies to Microsoft NPS and IAS implementations only - it is essential for these systems. When setting up the NRPS as clients in Win2008 NPS it is essential to check that the Vendor Name for the three NRPS is set to ‘RADIUS Standard’ and not ‘Ascend Communications’ in the NPS/RADIUS clients and servers/RADIUS clients configuration tree in the Server Manager. Open Server Manager, navigate down Roles/Network Policy and Access Services/NPS/RADIUS Clients and Servers/RADIUS Clients. The RADIUS clients pane will display the IP Address and Vendor Name (Device Manufacturer) that has been set. Device Manufacturer should be ‘RADIUS Standard’.

In the case of IAS, even if the Client-Vendor name is correctly set in the NRPS client properties to RADIUS Standard, Access-Requests containing Operator-Name will still be dropped. The solution is a little more involved and it is necessary to modify an IAS database file as below. It is however essential that MS IAS sites carry out this fix at the earliest opportunity.

  1. Stop the IAS Service
  2. Make a backup copy of c:\windows\system32\ias\dnary.mdb
  3. Open c:\windows\system32\ias\dnary.mdb in MS Access
  4. Open the 'Attributes' table
  5. Scroll down to attribute number 126
  6. Change the Name to Operator-Name
  7. Change the Syntax to String
  8. Close Access, and start IAS

The dnary.mdb file can be copied to another machine for editing if you do not have Access on your IAS server.

These instructions and the background to this requirement are described in the following Janet Advisory:

Janet Advisory: MS IAS and NPS Operator-Name RADIUS attribute issue (Nov 2010) - notification of critical issue affecting participants that have implemented Microsoft IAS and NPS ORPS - urgent action required.

Resources:

11.3 Authentication request handling for your own users a) when on-campus and b) when roaming

The next step is to configure authentication of your own users: 

  • You will need to configure your ORPS to handle requests received from the local campus network for your own users to be authenticated against your user directory (AD/LDAP).
  • And you will need to configure your ORPS to handle requests received from the NRPSs to be authenticated against your user directory (AD/LDAP).

Configuration for your users on-campus - The logic for how to process authentication requests arising from your own users on campus is dependent on the following conditions being met a) the device is attempting to connect via the eduroam SSID b) the network access server belongs to the group of your WLC/network switches and c) the realm component of the username matches your organisation's realm(s). If these conditions are met, the authentication request should be handled 'locally' by your RADIUS service. 

The simplest connection solution for supplicant devices where the username realm is your organisation's realm and the authentication request is received from your eduroam SSID (Home users on home campus) -  is to just to connect all your own users onto a Home-users' eduroam network service. This is okay for initial trial implementation, however it does not provide any segmentation of your network. A more sophisticated solution is recommended.

A key benefit of implementation of 802.1X is the support of dynamic VLAN assignment. This technique allows you to connect users belonging to particular user groups to specific VLANs or network access profiles - in our literature we refer this user access control as 'dynamic VLAN assignment'. Segregation of user devices on the home campus is, we would argue, an essential element of network security - however, it is outside the scope of the eduroam service to define exactly what member organisations should implement. This is a matter to be decided by the organisation itself. Nevertheless we recommend that the separation of own students, own staff, eduroam visitors and non-eduroam visitors should be the minimum level of segregation. During the user authentication process against your user directory, the group that the user belongs to can be determined and by setting group membership conditions to be matched for a specific VLAN identification attribute to be included in the Access-Accept, the RADIUS server can be configured to dynamically assign the required VLAN for the user to be connected to.  

The particular attributes to be included in Access-Accepts sent from your RADIUS server to your nework kit/WLC necessary to achieve this depend on the vendor of the network/WLAN equipment, but the following are in common use:

  • Tunnel-Type (attribute 64) ​
  • Tunnel-Private-Group-ID (attribute 81)​
  • Tunnel-Medium-Type (attribute 65)
  • Aruba-User-Vlan
  • Trapeze-VLAN-Name

Since there are so many RADIUS servers to choose from, it is beyond the scope of this guide to provide detailed instructions for all the possible solutions. Nevertheless we have produced a configuration guide for Microsoft NPS and there are links to other guidance in the resouces section. You will also find links to these in the green Library panel on the Troubleshoot page of the Support server portal. 

Configuration for your users when roaming - In the eduroam environment, unless a mutual agreement is in place with a Visited organisation, a Home organisation’s Access-Accept reply should not contain dynamic VLAN assignment attributes.

The logic for how to process authentication requests arising from your own users when roaming is dependent solely on the following conditions being met a) the authentication request for the device attempting to connect has been received from the eduroam(UK) NRPSs and b) the realm component of the username matches your organisation's realm(s). If these conditions are met, the authentication request should be handled  by your RADIUS service and a simple Access-Accept or Reject should be returned without any inclusion of VLAN assignment attributes.

Authentication of your users - the actual authentication of users against your user directory is covered in section 14 below.

Points to consider:

a) It is a requirement that ALL users (home users and visitors) authenticating via eduroam MUST have a realm component in their username (ie must be of the form 'userID@camford.ac.uk') and that the Visited site realm handling logic drops any authentication request without a realm name in the outer id. This is to avoid a situation where your users have used a simple username eg. 'fred' to authenticate whilst connecting to eduroam at your organisation and then find that they cannot gain authentication when visiting another eduroam site. The problem would be that the Visted site ORPS will not recognise the user name and should drop it, but even if it did forward the Access-Request to the NRPS, the NRPS will not know where to forward the request to and so will drop it, returning an Access-Reject including explantory text. Do NOT permit authentication based on a simple username - insist that the username contains @realm.

b) Consideration should be given as to how both "outer" stage 1 identities and "inner" stage 2 identites are handled. You should not permit proxying of inner ID off to other organisations in cases where the inner ID realm is not your organisation - such authentication attempts should be allowed to fail. (E.g. Your RADIUS server handles an authentication request for outerID user@myorganisation.ac.uk, but during the auth process encounters an innerID of user@camford.ac.uk - your ORPS must drop this auth request).

c) It is essential that your ORPS must not forward an authentication for a user from your own realm or a sub-realm to the NRPS. That would create a potential authentication loop as the NRPS would rightly return the request to your ORPS. Because such authentication loops are highly resource-hungry this situation would create a threat to the eduroam service. The NRPS have anti-auth-loop logic which drops such loop-forming requests, which protects against this threat - but please note that sending auth-loop triggers are explicitly prohibited by the Technical Specification.

d) When forming your handling conditions for handling authentication requests in policies and service rules, be careful to avoid setting conditions that can cause unexpected behaviour or failures. For instance, do not set a condition for your roaming users based on an attribute that may not be forwarded from a remote visited organisation's AP/WLC. You must not make NAS-Port-Type = Wireless-802.11 a condition in the roaming user policy/service rule!

11.4 FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang

We have put together an example configuration of a FreeRADIUS ORPS (both v 1.1.x and 2.x) here: example FreeRADIUS ORPS configuration on eduroam Support server

The first section covers configuration of the NRPS servers as proxy authenticatprs and clients.

About a third of the way down there is script for the authorize stanza in your proxy.conf file for your default virtual server to:

a) enforce use of full userID@realm username format

b) reject bad usernames against a sequence of common error criteria, returning reason for rejection in the reply-message

c) check for properly formed usernames in auth requests and only for valid forms, detect your local realm and hand off to local realm processing

d) hand off auths for non-local realms to eduroam realm processing

11.5 Microsoft NPS Configuration - Setting the Framed-MTU Attribute in Roaming User Network Policy

By default NPS uses a maximum size of 1500 (was 2000) bytes for its datagrams. If it is sending a certificate (whose size may exceed this), the Ethernet packet created will probably be fragmented and this may result in the datagram to be lost in transit where packet fragmentation is rejected (this is why we specify you must NOT configure reject fragments at your firewall). If this happens, the EAP interaction will never complete. This causes NPS to log a discard for your roaming user authentication, for some reason claiming that the incoming packet was incorrectly formatted. Even if the client sends a Framed-MTU attribute itself, NPS will ignore it. However, if you set the Framed-MTU attribute in the Network Policy involved, NPS will use the value you specify for its own packets.

[The author of this tip notes: 'We were seeing this problem initially with responses to the test authentication requests that the NRPSs send every few minutes. I got the details from a Cisco article (http://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/118634-technote-eap-00.html). Since implementing the change, I've noticed that authentication attempts from a number of clients which were failing previously are now working.']

How to set the Framed-MTU attribute size in Microsoft NPS:

From the NPS console, double-click Policies, click Network Policies, and then in the details pane double-click the policy that you want to configure - refer to our NPS config guide for the policy that forwards Visitor authentication requests to the NRPSs.

In the policy Properties dialog box, click the Settings tab.

In Settings, in RADIUS Attributes, click Standard. In the details pane, click Add. The Add Standard RADIUS Attribute dialog box opens.

In Attributes, scroll down to and click Framed-MTU, and then click Add. The Attribute Information dialog box opens.

In Attribute Value, type a value equal to or less than 1344. Click OK, click Close, and then click OK.

11.6 Microsoft NPS Configuration - Ensure Support for TLS 1.2

Microsoft blog about supporting TLS 1.2 - TLS 1.2 support at Microsoft | Microsoft Security Blog

How to enable TLS 1.2 video - see instructions at 3:55 - 5:50 mins - https://www.youtube.com/watch?v=NR-N65cDzi0&list=PLbKeiLya4JyA_6A10XKhnCzEY4eyApG4M&index=3

How to enable TLS documentation - https://community.jisc.ac.uk/library/network-and-technology-service-docs/tls-12-and-updated-radius-requirements for Windows Server 2012, support for TLS 1.2 was introduced via update Security Update for Windows Server 2012 (KB2977292). But to enable TLS after you install the security update, you must add a DWORD value that is named TlsVersion to the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13

The value of this registry key can be 0xC0, 0x300, 0xC00, or any OR'ed combination of these values - you should support TLS 1.0, 1.1 and importantly 1.2

11.7 Special Note for NPS Configuration - Tuning NPS for authentication with eduroam

This article is quite old now but may be useful https://community.jisc.ac.uk/library/network-and-technology-service-docs...

See Part 3 of this guide for section 11.6 Testing your Configuration

11.8 Configure Peering with other RADIUS servers on your network

If you choose to implement multiple organisation RADIUS proxy servers for resilience or performance/load sharing, you may have to configure peering/clustering between them.

11.9 Testing your Configuration

Once the ORPS(s) have been configured, authentication can be tested using the test tools on the eduroam Support web site as described in section 12.

Shared secrets check. In scenarios involving multiple ORPSs, it is advisable to test each ORPS independently for correct configuration. Shared secrets can be checked by simply running a command line test on each of the ORPS. Note that whilst FreeRADIUS, Radiator and MS IAS/NPS include utilities for cleartext password based authentication methods such as PAP, this is no longer supported by the eduroam(UK) infrastructure, so please do not attempt to use radtest, radpwtst or NTRadPing.

a) If you have not hooked your Wi-Fi service in to your RADIUS server, the simplest test involves using a command line tool to try to send Access-Request packets to the NRPS for forwarding to the eduroam Support ORPS for a test user belonging to the eduroam(UK) realm. (This is a command line variation of the standard visitor authentication simulation test - see section 12 below). Nb As specified in section 5 above, you must register a test user account complete with password for your site on the Support server. You should also create a test user account with the registered credentials as a local account on your RADIUS server or an account in your user database). Remember, any changes your make to your config on eduroam Support can take up to an hour to take effect.

Test tools (linux and Windows): http://techgenix.com/testing-monitoring-tools-radius-servers/

NTRadPing (PAP/CHAP test only - do not attempt to use this!): https://support.secureauth.com/hc/en-us/articles/360019651812-How-To-Tes.... Support server no longer supports plain PAP authentication.

Radius Test: https://radiustest.software.informer.com/download/

eapol_test is included in wpa_supplicant which is an opensource supplicant that can be acquired from http://w1.fi/wpa_supplicant/

The eapol_test commands would be:

eapol_test -c<test.conf> -aroaming0.ja.net -p1812 -s<shared secret for roaming0>

eapol_test -c<test.conf> -aroaming0.ja.net -p1812 -s<shared secret for roaming1>

eapol_test -c<test.conf> -aroaming0.ja.net -p1812 -s<shared secret for roaming2>

See https://www.systutorials.com/docs/linux/man/8-eapol_test/

For hints on how to build the test.conf file see https://www.systutorials.com/docs/linux/man/5-wpa_supplicant.conf/

(Radpwtst for Radiator may include PEAP/EAP alternatives to PAP for the more advanced user.)

b) If you have peered your Wi-Fi controller/AP to the RADIUS server you can simply use the test account credentials to try to send authentication requests for the user <your realm>@eduroam.ac.uk to the NRPS

Authentication tests against your local realm user database / test auth requests from remote sites In order to carry out this test you must have a test user account on your site with a valid password (eg. a local account on the RADIUS server or an account in your user database) and registered it on the eduroam Support server as specified in section 5. You then have a variety of options for testing authentication at your realm - using the remote eduroam Support server or locally from (one of) your ORPS. The tests described below involve interaction with the NPRS, you can however use radtest locally against a specific host.

The eduroam Support server has a remote user test feature for ORPS in normal 'production' mode - see section 12.

If you wish to run authentication tests involving the NRPS from (one of) your ORPS you must first set the target ORPS as a 'test-development' server in the eduroam infrastructure. This can be done via the relevant RADIUS proxy servers page on the eduroam Support server. With this setting, ONLY packets with 'test' prefixing your realm name will be sent to your ORPS. This facility is detailed in section 12; Testing a new ORPS within eduroam Infrastructure before bringing it into production use. CAUTION - there is a danger that auth-loops can be created, so it is essential that the local test user account is valid and that you use credentials accurately. At the end of your test session, you must check your logs to ensure that no auth-loop has been initiated.

If you (temporarily) configure the test ORPS forwarding policy to send all access-requests with realm ('@xxx') suffixes to the NRPS, then when you use 'testuser@test.yourrealm' with radtest, the NRPS will process the request and send the access-request back to your ORPS. (Nb. if you have a group of ORPSs then this request could be sent to ANY one of the individual servers since the NRPS sends to the first ORPS in its list that it finds is not busy). Nevertheless the three lines of radtest commands are useful to verify that the ORPS can talk to all three NRPS - ie that there are no bad secrets and no firewall problems! If you do have multiple ORPSs you could always turn off the other ORPSs while doing each test - which would guarantee that only the ORPS being tested would be sent the return access-request. This would verify that the ORPS under test could be reached from each NRPS in turn).

Assuming that the test account can be authenticated using PAP, the FreeRADIUS command would be:

Radtest testuser@test.your_realm <password> roaming0.ja.net 1812 <shared secret for roaming0>

Radtest testuser@test.your_realm <password> roaming1.ja.net 1812 <shared secret for roaming1>

Radtest testuser@test.your_realm <password> roaming2.ja.net 1812 <shared secret for roaming2>

11.10 Resources/FAQs

Troubleshooting Microsoft IAS as a RADIUS server and as a RADIUS proxy

This link to the MS TechNet site should be useful:

Is it possible to authenticate EAP-PEAP against Novell Directory Services?

While it is not possible to authenticate EAP-PEAP against the default non-reversible hash used in NDS, it is now possible to configure a "Universal Password" in NDS which stores users' passwords in a reversibly encrypted format. This will permit the authentication of EAP-PEAP against NDS through RADIUS servers such as FreeRADIUS and Radiator.

How do you configure FreeRADIUS against Novell eDirectory?

Novell has produced documentation on configuring FreeRADIUS against eDirectory:

Are there any example configurations for Radiator available?

We currently don't have any direct cut'n'paste for Radiator that is clearly available for any site due to the uniqueness of each site requirement (backend authentication and such).

However, Radiator supplies many example configuration file snippets and templates.

eg ntlm_eap_multi.cfg which is a simple config which handles Radius PAP, CHAP, MSCHAP and MSCHAPV2 and also handles the outer and inner requests for TTLS and PEAP. In this case, the <AuthBy NTLM> sub-handler is doing the work. Of course this is only suitable for Active Directory. If sites are using passwords or eDirectory etc then the requirements will be different.

Also appendix A.2 of the Geant2 Roaming Infrastructure Service and Support Cookbook provides useful information on configuring the ORPS server software.

Are there any example configurations for FreeRADIUS available?

We don't have any direct cut'n'paste configurations for FreeRADIUS that would be suitable for all sites due to the uniqueness of each site requirement (backend authentication etc).

However there are some hints and tips on the eduroam Support website and there is some useful information in the following case study, which is a practical description of how University of Bristol implemented and complies with the Technical Specification using FreeRADIUS in an AD environment: A Case Study in Complying with the Technical Specification.

Also appendix A.2 of the Geant2 Roaming Infrastructure Service and Support Cookbook provides useful information on configuring the ORPS server software.

FreeRADIUS integration with Active Directory

The received way of setting up FreeRADIUS to authenticate users against Active Directory is to use Samba/winbind/ntlm_auth:

FreeRADIUS Active Directory Integration Howto - from FreeRADIUS Wiki

University of Bristol implemented FreeRADIUS in an AD environment, the following case study contains useful information: A Case Study in Comlying with the Technical Specification.

How do I change the IP address of our ORPS? (Is there a procedure we need to go through?)

You need simply to use the https://support.roaming.ja.net eduroam support site. Go to your ORPS configuration page and select your ORPS, change the name of the RADIUS server and press [Update RPS]. Check that the passphrase does not change (it should not). The final step is to remove the old ORPS entry and add the new one. The passphrase will be different then. The changes are propagated to the NRPS on the hour.

 

12. Wi-Fi Service and Establishment of a VLAN/Network Service for eduroam

eduroam Wi-Fi service

The steps involved in establishing an eduroam Wi-Fi service are:

  • Enabling 802.1X on your Access Points or Wireless LAN Controllers
  • Peering APs/WLC with your ORPS (ORPS are RADIUS servers to APs and APs are RADIUS clients of ORPS)
  • Set up radios and wireless LAN  - RF bands to be used for each standard, define WLANs, enable WPA2/AES cipher
  • Setup eduroam SSID
  • eduroam VLAN setup
  • Configure authenticated user connection policy - VLAN connection/dynamic VLAN assignment
  • Tune EAP timers, RADIUS server timeout and other WLAN parameters

Most organisations provide eduroam over a Wi-Fi service although eduroam may alternatively or in addition be provided over wired infrastructure. Wi-Fi is typically the 'front-end' by which most users would prefer to connect, since this supports the laptop, tablet and  smartphone devices that are most popular with users.

Many organisations have used the deployment of eduroam to simplify their wireless network offering. This can result in reduced management overhead and improved overall Wi-Fi performance and can be achieved by combining eduroam as the primary ESSID with multiple dynamically assigned VLANs as described below, together with a further small number of ESSIDs e.g. for an open captive portal network for first time users to provide access to device setup utilities or for a guest network for non-eduroam visitors.

To establish an eduroam Wi-Fi service, you need to configure the organisation's APs to broadcast the eduroam SSID, the APs need to be set to use 802.1X/AAA-RADIUS-authentication and be defined as clients of the RADIUS server. Then the APs need to be configured to forward authentication requests from the Wi-Fi devices associating to the eduroam SSID to your RADIUS server(s). Upon receipt of an validated authenticated request (an Access-Accept) the APs must connect the device to your eduroam network, described below.

If you want to use dynamic VLAN assignment as described below (assigning users to specific VLANs based on information received from the RADIUS server) then the APs must be configured to do this. (Other activities performed by the APs include exchange keying material (initialisation vectors, public and session keys, etc.) with client systems to prevent session hijacking).

Resources:

 

eduroam network

Visited organisations must implement one (or more) dedicated network/VLAN(s) to provide eduroam network services. All eduroam networks must comply with the eduroam(UK) Tech Spec (access to the Internet permitting use of (at least) the defined key ports and protocols - see Firewall section). Any eduroam network/VLAN must not be shared with any other network service. Authenticated Visitors must be connected to such an eduroam network service.

Most participating organisations permit their own users to connect via the organisation's eduroam Wi-Fi service. If this is not permitted, this must be clearly stated on the organisation's eduroam Service Information web page. Organisations may connect local users to the mandatory Visitors' eduroam network service, but alternatively may connect them to a more appropriate local network. This can be achieved through 'dynamic VLAN assignment' (which is the more efficient alternative to the fixed SSID-VLAN mapped solution). Such local networks may be used to for example satisfy the following requirements:

  • provide access to local resources that the organisation wishes to be accessed only by its own users/specific groups of users
  • provide a security environment required for local users/specific groups of users
  • enable local users connecting their own personal devices to be connected onto an 'untrusted network'
  • provide a remedial network environment for devices requiring AV updates, OS-patches etc.

Detailed information about how to set up dynamic VLAN assignment is beyond the scope of this guide, but essentially involves configuring your RADIUS server to return a value in the relevant attribute in the Access-Accept based on the policy you define for the particular user or user-group. The AP needs to be configured to act upon the attribute value and to connec the device to the appropriate VLAN. There are many guides available on the Internet, one of which is Allied Telesyn's How To user 802.1X VLAN Assignment.

Nb. The minimum set of open ports and protocols for eduroam network services defined in the eduroam(UK) Tech Spec does NOT apply to non-eduroam network services that a participating organisation may choose to connect local users to.

Requirements for eduroam network/VLANs:

  • The Wi-Fi service that connects to the eduroam network service must use a broadcast SSID of 'eduroam' (which must be lowercase)
  • DHCP must be employed to allocate IP addresses
  • Only IEEE 802.1X is permitted for the eduroam network; no form of WRD/captive portal is permitted, although you may implement this on other networks such as device setup and remediation networks
  • IEEE 802.1X NASs must support symmetric keying using keys provided by the Home organisation within the RADIUS Access-Accept packet
  • Only a single user is permitted per NAS port except where 'thin client'/controller-based systems are employed
  • IPv4 addresses must be allocated to visitors using DHCP
  • The IPv4 addresses allocated to visitors and the corresponding MAC addresses must be logged
  • NAT address mappings, if used must be logged
  • Routing of IPv6 on the eduroam visitor VLAN ideally should be supported
  • NAT is permitted
  • WEP must not be implemented on the eduroam Wi-Fi service that connects to the eduroam network service
  • TLS interception proxies/filters must not be employed on the eduroam network service for visitors

Visited organisations may implement IPv4 and IPv6 filtering between the visitor VLAN and other external networks, providing that this permits the forwarding protocols detailed in the Firewall Configuration section.

Resources:

13. Firewall Configuration to Support eduroam Network Service

If not done already, your organisational firewall must now be made ready for the eduroam Visitors network service.

An important aim of eduroam is to provide visitors with unimpeded access to the Internet, not least because this maximises the probability of a visitor’s applications working as expected. The Tech Spec therefore requires that at least the core list of protocols listed in the talble below must be permitted. You may of course open additional ports and protocols if your local policy is more liberal.

Note, if member organisations wish to absolutely ensure that their own users, when roaming, have or a wider range of ports/specific additional ports available than the minimum listed, they could provide their users with a (supported) VPN service through which the home site could control the availability of required ports and protocols.

Similarly, the Visited service providing organisation need only comply with the list for their eduroam visitor network. If you connect your own users (through your eduroam Wi-Fi service) to an alternative network service more appropriate for local users, you are not required to adhere to the minimum list (and you may be more restrictive or more open).

One approach worth considering is to offer a fairly open Visitied service network with just the ports and protocols suggested in the following document blocked and also SMTP/port 25 blocked https://community.jisc.ac.uk/library/janet-services-documentation/blocking-lan-service-ports. Your own users when at home could be connected to a network service compying with your policy for local users.

Mandated Ports and Protocols that must not be blocked:

Passive (S)FTP: TCP/21 egress and established
SSH: TCP/22 egress and established
IPv6 Tunnel Broker Service: IP protocol 41 egress and established
PPTP:

IP protocol 47 (GRE) and TCP/1723

 egress and established
ESP: IP protocol 50 egress and established;
AH: IP protocol 51 egress and established
HTTP: TCP/80 egress and established
POP: TCP/110 egress and established
NTP: UDP/123 egress and established
IMAP4: TCP/143 egress and established
IMAP3: TCP/220 egress and established
IMSP: TCP/406 egress and established
HTTPS: TCP/443 egress and established
ISAKMP: and IKE: UDP/500 egress
LDAPS: TCP/636 egress and established
SMTPS: TCP/465 egress and established
Message submission: TCP/587 egress and established
IMAPS: TCP/993 egress and established
POP3S: TCP/995 egress and established
OpenVPN: UDP 1194 and TCP 1194 egress and established
Citrix: TCP/1494 egress and established
SQUID Proxy TCP/3128 egress and established
RDP:  (deprecated) TCP/3389 egress and established
IPv6 Tunnel Broker NAT traversal: UDP/3653 and TCP/3653 egress and established
IPSec NAT traversal: UDP/4500 egress and established
VNC:  (deprecated) TCP/5900 egress and established
AFS: UDP/7000 through UDP/7007 inclusive egress and established
HTTP Proxy: TCP/8080 egress and established
Cisco IPSec NAT traversal: UDP/10000 and TCP/10000 egress and established

You may have additional ports and protocols open as permitted by your local policies.

The above list is subject to change, so you should refer to the current published eduroam(UK) Technical Specification, which provides the definitive listing.

 

14. RADIUS server configuration for Home service - interoperation with user database

The next step is to configure the authentication of your preferred EAP types. (With Microsoft NPS this is the creation of a Network Policy, although some configuration is also needed in the Connection Policies for your own users).

It is assumed that you have:

a) completed configuration of your RADIUS server to set the NRPSs as clients of your RADIUS server as described in section 8.2

b) completed configuration of your firewall to permit inbound traffic from the NRPSs as described in section 9

Configure Authentication of Preferred EAP Types

Home organisations must configure their RADIUS server (eg.edit the eap.conf file) to authenticate one or more EAP (Extensible Authentication Protocol) types as specified in the Technical Specification.

Interoperation with User Database

For each home realm authentication request handled by the ORPS, the RADIUS server generally has to interrogate the user database (LDAP, NDS, AD). The interoperation of the RADIUS server with the backend user database is often the most problematic part of implementing 802.1X. Whilst there are a number of well known techniques and software combinations, since each institution's environment is unique, detailed guidance about this is beyond the scope of this overview.

Hints

FreeRADIUS: if you are using Active Directory as your user database you will need to install and configure Winbind and Samba.

Microsoft NPS: if you are using Active Directory as your user database, user authentication is configured within a Network Policy and the server simply has to be registered in your AD and be 'authorised to read users' dial-in properties from the domain'.

A note on the use of anonymous outer identities: the majority of the most often deployed EAP methods (PEAP/MSCHAPv2, EAP-TTLS/*, EAP-FAST) use a two-stage authentication process (EAP-TLS is certificate based and is not a two-stage process):

  • the first stage uses the realm component only of the 'outer identity' username to enable the client to be connected to the appropriate authenticator (identity username = userID@realm)
  • the second stage uses the cryptographically protected 'inner identity' username for the actual authentication of the user (and the authentication server actually uses the userID and is not normally concerned with the realm component of the username that is presented)

Note that RFC 4282 permits the use of anonymous outer identities the aim of which is the better preservation of privacy for your users. Therefore the RADIUS server configuration of a Home service should permit the use of anonymous/blank userID in the outer identity, ie the value the user inputs when enabling 'Enable Identity Privacy'/ 'Anonymous identity' and the RADIUS server configuration of a Visited service MUST permit the use of anonymous/blank userID.

A note for Microsoft NPS server deployments: see p51 on https://community.jisc.ac.uk/system/files/257/eduroam%28UK%29%20Microsof... - when configuring the Connection Request Policy for your roaming users be sure to tick 'Override network policy authentication settings’ and Add the EAP Type of 'Microsoft: Protected EAP (PEAP)'.

More in depth advice on configuring RADIUS-database interaction is available in various documents:

A note on FreeRADIUS with LDAP based systems: the authentication handling flow is as follows - after the prefix module has run, the 'Stripped-User-Name' attribute gets populated with the userID part of the username (e.g. 'a123467'/'fred.smith') - you then use that in your LDAP configuration (ie %{Stripped-User-Name}) with the relevant CN/DN/ON that you require in LDAP.

Tip: when setting up a FreeRADIUS server we'd recommend you run the server in full debug mode (freeradiusd -X  or radiusd -X depending on whether it was installed by APT or from source) to enable you to see exactly what is going on for each packet and the decisions/checks the server is making as you develop the configuration.

A word on the format of user names: when migrating to an 802.1X authenticated network, it is often tempting to permit simple usernames to continue to be authenticated for users on the home campus rather than requiring a full username including a realm element to be used. Since an eduroam username must include a realm component, the Tech Spec now requires that the username should always include the realm component, even for eduroam networks for local users only and for users who might be thought to not roam to other eduroam sites.

It is particularly important to not permit simple userID-only usernames to be used in single-SSID eduroam networks where 'eduroam' is used for both guest users and local users.

By requiring that the full 'userID@organisation.ac.uk' type credentials are used, you can ensure that the same credentials are used by users both on the home network and when roaming. Thus problems associated with use of incorrect creadentials can be avoided. For the user, there is no confusion and after the first time that the credentials are entered into the supplicant, there is no additional work involved resulting from the adoption of this policy.

Configure RADIUS server to reject PAP requests from the NRPS

Historical note (PAP tests are no longer generated from the NRPS): PAP is useful to have configured against a local test account during the early stages of service implementation. However, once you have used it to test port 1812 transit and NAT/PAT if applicable, since there will be no production PAP traffic, you should confgure your RADIUS server to reject any PAP requests coming from the NRPSs.

Configure load balancing if deploying multiple RADIUS servers servicing your WLAN

If you are deploying multiple RADIUS servers to service your WLAN, think about how you are going to share the load evenly between these and your failover mechanisms.

A note on working with usernames in Microsoft NPS Windows 2008R2

Many organisations implement eduroam in an existing MS Windows network environment where usernames are stored in AD in a simple userID form without a realm component (or in some cases the realm component doesn't match the eduroam realm, e.g. eduroam realm = @camford.ac.uk but AD realm = @ad.camford.ac.uk). For eduroam authentication, usernames must be in the form userID@realm, therefore a means must be found of presenting the username in a form that can be successfully authenticated. (In the mismatching realms case, the eduroam realm needs to be made authenticatable). In IAS and earlier NPS versions, a perfectly workable solution has hitherto been to simply strip the realm component by using for example the find-replace rule in the Connection Request policy which is the standard Find “(.*)@(.*)”  Replace “$1”. This however is no longer possible in later versions of NPS.

In NPS Windows2008R2 and later, whilst you can implement the above, the results is authentication fails even though the actual realm stripping seems to work - the stripped username is found in the AD, but still the authentication fails, (almost as if the password is wrong). Interestingly you could even strip the original .ac.uk type realm component (e.g. @camford.ac.uk) and replace it with a local one (e.g. @ad.camford.ac.uk or @camford.local) that matches a valid username in AD, but the result would be the same.

This is because in Windows 2008R2 Microsoft decided to change the way that NPS deals with realms. In 2008R2 a stripped realm no longer passes EAP security requirements and thus the stripping of a User-Name always results in an authentication failure.

The fix for this is to do one of the following:

1) Configure the realm stripping rules on the front-end NPS server to modify the identity in the Access-Request and then forward the request to a second NPS server for authentication OR just send the Access-Request to a second (earlier release) Microsoft RADIUS server (older NPS or even ancient IAS box) to do the stripping and authentication.

2) The recommended solution is to add your eduroam realm as another global UPN to your AD so you don't need to strip the realm in the first place. (What is UPN? https://apttech.wordpress.com/2012/02/29/what-is-upn-and-why-to-use-it/)

3) Use a different RADIUS server platform!

Set up logging

Logging on the ORPS must be set up in accordance with the Technical Specification. All transactions with the NRPS, including some mandatory attributes, must be logged and records held for at least 3 months, with a recommended maximum of 6 months (subject to your own policies).

RADIUS Accounting

RADIUS Accounting is not required by eduroam(UK) but some overseas countries do use Accounting information inside their own borders for various reasons. Since eduroam Europe Operations does not interfere with forwarded Accounting packets, ORPS at Home service organisations may receive accounting records from their own users when they roam to a non-UK hotspot for which RADIUS Accounting has been turned on. Note that the number and content of attributes in the Accounting packets varies greatly due to the underspecification in RFC2866; you can not rely on any single Accounting attribute being present. The best option is for your to simply discard Accounting packets which cannot be correctly understood by your RADIUS server.

Visited sites must turn off/not enable RADIUS Accounting forwarding to the NRPS.

Resources:

15. DNS Name Server Configuration - NAPTR record

All(*) participants providing a Home (IdP) eduroam service should ensure that the DNS zone relating to their realm contains a NAPTR record (Name Authority Pointer) enabling the NRPS to be indirectly defined as hosts for radsec services via SRVs. (*)With the exception of .ac.uk participants using Windows Server 2003 as their DNS server (since this does not support NAPTR records - Windows 2008 R2 is fine). This ensures improved authentication performance for your users when using eduroam outside of the UK.

It should be noted that it is mandatory for organisations using non-.uk realm names (e.g. camford.edu and camford.org to configure NAPTR records in their DNS zones and so such organisations must ensure that their DNS name server supports NAPTR records. This is because top-level international RADIUS routing for 'special' top level domain names is now achieved using RadSec DD.

The background, rationale and method of achieving insertion of NAPTR records are documented in Advisory: Improving Efficiency of International Authentication through utilisation of RadSec at National Level 

16. Test facilities on eduroam(UK) Support Server / Visitor Test / Testing a New ORPS

eduroam administrators at participating organisations are able to carry out a number of tests themselves to verify the correct configuration of their ORPS/user database for authentication of their roaming eduroam users. These on-demand tests can be found on your 'Troubleshoot' page on Support server. Support server also carries out regular active tests (which in the first generation of Support server used Nagios) and passive NRPS log checks to continually check all ORPS. Alerts that need to be drawn to the attention of sys admins are displayed on your organisation Status overview (monitor) page.

16.1 eduroam Support Server ORPS/Authentication Tests

Tests available to eduroam administrators at participating organisations from the eduroam Support server enable testing on demand of :

a) basic network connectivity and dead or alive status of your ORPS

b) authentication of one of your users visiting another organisation, using authentication protocols: EAP-PEAP, EAP-TTLS.(*) (Basic PAP authentication is no longer supported).

c) authentication of a user visiting your site from another organisation (ie that your ORPS is forwarding RADIUS packets correctly and handling attributes within RADIUS-challenge/response etc. packets ok).(*)

(*) EAP-TLS - test function is not available at present due to the complexities presented by the need to use client certificates. However the eduroam CAT system does support such tests within the 'realm reachability' checks - in your EAP profile you need to add EAP-TLS to the list of methods you support. 

How to use the tests:

1) The ICMP ping test is available on the Troubleshoot page for your organisation - simply click on the [ICMP] button in the blue 'Tests' panel. 

2) A test user account must first be registered on the eduroam Support Server web site with details including the test user name, password, the realm that the organisation wishes to test and the EAP method required (basic PAP is no longer supported as an authentication method - it is supported as an inner EAP-TTLS method). If you have multiple realms registered on the Support server you can select which of these you wish to be appended to the test account name.

2) The test user account should be created in the organisation's user database that is authenticated against by eduroam. This should allow at least five failed authentication attempts without being locked. Nb The test account credentials will only ever be known to Technical Support.

3) Log in to the eduroam Support server, click on the 'Troubleshoot' tab on the menu bar. The tests are displayed in the blue Tests panel. 

The available test functions are:

  • ORPS Status Check - ICMP ping status test. This is to ensure an ORPS is up and running at the participant's site.
  • Remote User Authentication Tests. To check that one of your users at a remote site can be authenticated by your systems. Click on the relevant [Test] button.

EAP-PEAP authentication test - PEAP is commonly used for 802.1X authentication. This option will work for most RADIUS servers. Some servers, e.g., Radiator, may require peaplabel=1 configuration to interoperate with PEAPv1. In this case the following test should be tried:

EAP-PEAP (peaplabel=1) authentication test

EAP-TTLS has various inner types, choose the appropriate one for your site:

EAP-TTLS (inner PAP)

EAP-TTLS (inner MD5)

EAP-TTLS (inner MSCHAPv2)

Remember that when testing a user from your own organisation authenticating using your 802.1X network, if the user can be authenticated on your network, then provided that proxying works, the user will be able to successfully authenticate at any compliant visited organisation.

(PAP authentication is no longer supported by Support server - PAP is a clear-text authentication method which was common with web redirect systems (Support server v1 originally included support for PAP for the test user account to test basic RADIUS connectivity).

eduroam
eduroam implementation
how to set up
  • Twitter logo
  • LinkedIn logo
  • Google+ logo
  • Reddit logo
  • StumbleUpon logo