Last updated: 
1 day 9 hours ago
Group Manager
A place to share information on all aspects of eduroam in the UK. Follow us on Twitter @eduroamuk - for news, interest, information, photos and fun. Contents Click on item and scroll down to the selected content at the bottom of the page. eduroam Visitor Access Administrator Manual - Configuration and Management eduroam Visitor Access Portal User Manual - Creating Guest Accounts eduroam Visitor Access User Manual - Creating Guest Accounts for Groups and SMS Events eduroam Visitor Access Guide - UKAMF IdP Configuration Requirements Advisory: Injection of Operator-Name at the NRPSs Walled Garden for Onboarding User Devices to eduroam Using eduroam Support site; Connecting to the NRPS; User on-boarding – CAT Guidance document - eduroam and Safeguarding Guidance document - Cost of Implementing eduroam eduroam(UK) Technical Specification Summary of Recommendations Checklist eduroam(UK) Technical Specification Summary of Requirements Checklist eduroam(UK) Technical Specification NHS and eduroam/shared use of wireless/govroam ORPS in Azure - alternatives to the use of ICMP Sending Operator Name with Cisco ISE 2.0 eduroam in Public Buildings and Spaces in City Centres TLS 1.2 and updated RADIUS requirements FreeRADIUS Packet Handling - examining the flow FreeRADIUS Best Current Practice Configuration for eduroam  Performance tweaks for RADIUS and backend authentication systems eduroam(UK) Microsoft NPS Configuration Guide eduroam(UK) Service Provider Assurance Tool User Guide eduroam(UK) Service Provider Assurance Tool Phase2 Field Trial Feedback Improving the Reliability of NPS as an Authenticator in eduroam Advisory: Using Status Server Advisory: Use of MD5 Certificates Deprecated in Favour of SHA-1 for RADIUS servers Advisory: Windows Mobile 8 and Certificate Verification NWS41 eduroam Forum presentations - TKIP, CUI, NAPTR, QoS Probe NWS40 FreeRADIUS Demystified seminar presentation Geant Funding available Janet Lumen House eduroam Service Information UK eduroam Usage Feb 2013 EAP-pwd Moving Towards a Deployable Standard Site Finder and Service Information Directory eduroam(UK) Technical Specification 1.3 (archived) - superseded by 1.4 eduroam User Troubleshooting Flowchart for IT Support Staff eduroam Administrators Troubleshooting Flowchart NAPTR Record Creation Using Microsoft Windows 2008 R2 DNS Server eduroam Best Practice Pointers FreeRADIUS 2 eduroam Deployment at University of Sussex

Group administrators:

eduroam Best Practice

17 April 2014 at 4:38pm

eduroam Best Practice

A.L.M. Buxey
A few pointers to provide a better service for end users

Firstly - try to solve the problem at the root by helping users understand that they need to use usernames in the form of userID@realm   e.g. fredB@camford.ac.uk

  • On your organisation's web site make it easy for users (including visitors) to navigate to your eduroam information web page
  • Make the requirement to use userID@realm stand out from what may be a large block of information on that info page
  • If eduroam is not your primary campus Wi-Fi network, give it equal weight to your 'other network'
  • Consider making eduroam your primary campus network (this will reduce the burden of managing multiple SSID networks)
  • Ensure that there is an eduroam logo on your organisation's main web site 'Visiting Us' page, with a link to your eduroam info

To ensure that the base configuration of your users' devices is correct you are strongly recommended to use auto configuration tools such as SU1X, Cloudpath XpressConnect or eduroam CAT.

Then, ensure you have a policy in place on the RADIUS server to ensure that all local authentications MUST have a realm defined.

ie 'if SSID = eduroam , then User-Name must include @'

(This can be done in FreeRADIUS using unlang; in RADIATOR using a Handler or PERL hook;and ACS/NPS in the policy section.)

What does this achieve/fix? Read on...

Well, if you allow local user authentication to eduroam without a realm being defined, then your local users can authenticate to eduroam locally without their client being properly configured...so it appears to them that .eduroam is working fine....it's only when they go to other sites that they discover that they cannot connect (at which point they blame eduroam or the site that they are visiting).

So, enforcing this policy ensures that your users ARE properly configured for eduroam....and will enjoy their roaming when they do travel.

Next, configure dropping of junk realms

You will need to check your logs for this (or check the NRPS problem log files for your organisation - accessible from your main config page on the SUpport server) since each organisation will have its own local typo issues (due to smartphone/tablet etc autocorrect on the realm name).

You only need to send requests to the NRPS when there is a valid realm - otherwise the request should be dropped at the local RADIUS servers. A valid realm is of the form  @[string] where there is at least one dot with a string on each side of it and the string may contain only the legal characters as per the NAI specification. Basically, this means you can get rid of all the requests in which the username is malformed as follows:

1) no realm eg (userID@)

2) no dot in the realm (eg @organisation-name)

3) dots in succession (eg realm..com)

4) ends in a dot (eg realm.)

5) illegal characters (eg @test\realm)

6) realm that ends, contains or begins with whitespace (eg @realm .com, or @ realm.com)

In addition to the above, you can reject any typos of your own realm (eg @realm.ax.uk, @realm.uk.ac, @realm.a.uk).

(As previously mentioned, you will need to look at the fail logs for your RADIUS server to see your best typos of the month.)

Sending only valid traffic to the NRPS will ensure that they are dealing only with valid traffic...and not being loaded with invalid requests to be rejected/dropped (which causes back-pressure on outstanding requests in the proxy heirarchy).