eduroam Best Practice

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).