Implementing eduroam - Roadmap

  1. Concepts and terminology
  2. Decide on which JRS Tier, EAP method and Service Level to implement
  3. Choose an appropriate RADIUS server platform
  4. Decide Realm(s) and Join eduroam
  5. The JRS Support Server website; input organisation/site details, realm name, test account
  6. Install your RADIUS Server (ORPS)
  7. Acquire Server Certificate for ORPS/NAS
  8. RADIUS server software configuration and interoperation with user database
  9. Firewall configuration
  10. Configure JRS Support Website with your ORPS details and get shared secrets
  11. RADIUS server proxying configuration and attributes filtering
  12. Test facilities on JRS Support Server / Testing a new ORPS
  13. RADIUS server log keeping and interpretation of logs
  14. Monitoring your own service
  15. Setup VLAN for Visitors network
  16. Workstation/Laptop Setup/MS Vista issue
  17. Q.A. test of your eduroam implementation
  18. Promote eduroam at your organisation - your eduroam web site
  19. Keep your configuration details data on the JRS Support server up to date
  20. Planning Ahead and Developing your eduroam Implementation

 

1. Concepts and Terminology

It is recommended that organisations planning to implement eduroam familiarise themselves with the concepts and terminology described in the depolyment guide:

www.ja.net/documents/services/janet-roaming/jrs-deployment-guide.pdf
Nb. This guide is now showing its age is due for an update.

For an introduction to 802.1X, chapters 1 and 2 of 802.1X Implementation at JANET-Connected Organisations are recommended reading. Hard copies of this booklet are available to order.

 

2. Deciding your eduroam Implementation

In the UK, JANET-community organisations are independent and so there is a wide range of ways in which organisations have implemented network services. To enable disparate networks to interoperate for the purpose of user authentication and to provide a reliable and predicable service for the user, JANET has produced the Technical Specification to which all participating organisations must adhere. This describes the technical standards and definition of service types.

The first step in planning your eduroam implementation is to decide the type(s) of service you wish to offer for visitors and for your own users and that will best suit your organisation. Choose from:

a) Home only organisation so your members can benefit from eduroam at other sites,

b) Visited only organisation so you provide eduroam facilities for visitors to your site or

c) Home and Visited whereby you enable your members to roam at other sites and you reciprocate by setting up facilites to support visitors to your site.

Next, consider the technological aspects of the network you wish to offer eduroam over. To provide a reasonably standard experience for users and to try reduce the amount of changes to supplicant and application settings required from site to site, the Tech Spec currently defines two sets of network parameters, JRS Ties 2 and JRS Tier 3. The tier of service that the organisation offers can be widely publicised and so the user is able prepare for use of the service at the organisation.

The tier system is much simpler now than it used to be when the web redirect method was permitted (in the withdrawn Tier 1). The only authentication method permitted now is 802.1X. The differences between JRS2 and 3 are IP versions (IPv4, IPv6), NAT (employed or not) and wireless security technology (WPA, WPA2). see JRS 2,3 matrix. Nb. Web redirect methods are no longer permitted on 'eduroam' SSID networks, on the grounds of its security weaknesses. (It was included in the initial Tech Spec in order to make the service as inclusive as possible). All JRS tiers use the same national JANET RADIUS infrastructure and users can gain authentication irrespective of the tier of the Home and Visited organisation involved. The differences to the user are simply the wireless cipher options, IPv6 availability and NATing.

If you decide to offer a Home service, you need to decide what EAP authentication mechanism(s) you want to provide for your users. This is an important decision since it will affect how your users must configure their laptops and the driver/supplicant software and certificates you will have to install / instruct your users in how to install. The decision on EAP mechanism will also probably involve a review your wireless LAN setup - if you have one (nb. you don't need to have a WLAN on your home network site in order to provide an authentication service for your users when they are visiting other organisations and using the remote site guest WLANs).

Your choice of EAP mechanism will be determined by i) the type of credentials on your authentication backend, ii) the client PC/laptop operating systems you wish to support and iii) the supplicant software you have or plan to install on your clients and may also be influenced by your wireless LAN (if any) setup/vendor support.

Help is available from eduroam Technical Support

(The selection of supplicant issue may be made easier when the cross-platform version of the OpenSEA 802.1X Xsupplicant is released - due soon. Currently versions for XP and linux are available).

If you decide to offer a Visited site service, a further set of issues must be addressed, particularly the encryption system you choose to deploy on your wireless network and the implementation of 'guest' VLAN assignment on your wireless access points and wired switches. Also your firewall from the guest VLAN must permit certain traffic types as detailed below.

You don't need to decide all the details of the implementation at the start of the process - Technical Support can provide advice and guidance. The project should also be divided into manageable step by step stages.

Resources:

(produced and published by GEANT2)

back to top of page

3. Choose an appropriate RADIUS server platform

The RADIUS server platform selected will be influenced by the type of credentials employed at your organisation (AD, DNS, LDAP and how certificates are utilised) and consequently the EAP types that you could use. This in turn will affect the choice of supplicant and that may also affect the decision. Other factors will be vendor preference, budget and technical expertise. Most RADIUS platforms however support a wide range of EAP types and authentication back-ends. (Having said that, if considering MS IAS, since this does not at present support EAP-TTLS, the choice falls to EAP-PEAP(MSChapv2) or EAP-TLS (with client certificates).

Options:

Help:

FAQs:

Are there any known issues with certain versions of RADIUS server software?

Yes! We of course make the general recommendation that you keep your RADIUS server software updated to the latest releases. There are particular known issues with versions of the popular choices of RADIUS sofware, including the following:

FreeRADIUS - versions prior to 1.1.4 do not support Vista clients due to the change in PEAP handling with Vista compared to XP. 1.1.5 and 1.1.6 had further SSL fixes to improve/fix SSL behaviour and stability in general...as well as more than 30 other bug fixes. If you are sticking to 1.1.x code, 1.1.7 was the final version of the 1.1.x product.

However we see no reason not to upgrade to the 2.0.x version of FreeRADIUS. 2.0.5 is at the time of writing the latest release and fixes many 1.1.x issues.

Radiator - in June 2007 the JANET NRPS had to be upgraded to the current version due to several EAP-TLS broken parts. This was leading to failed authentication attempts from visited sites for users from a participating organisation using EAP- TLS with MS IAS.

The problem, which was traced to the RADIUS exchange not completing, was resolved by upgrading our NRPS Radiator software from v 3.13 to 3.17.1. It is likely that if you are running older versions of Radiator on your ORPS and you get a visitor from a site that utilises EAP-TLS then similar problems will be encountered.

We specifically recommend that if you are still running older versions of Radiator, you should upgrade as soon as possible to the latest version. (Radiator 4.3.1 is the latest version, last modified 29 July 2008).

In addition to the above, a compounding problem was that the ipf firewall software configurations on our NRPS were set to discard UDP fragments. The script was therefore changed to pass fragments using the keep frag keyword. If you employ the ipf filewall on your ORPS, you should check this.

What RADIUS server software are eduroam participants using?

Number of ORPS installations by RADIUS software type:

  Dec 2006 July 2007 Dec 2007 Apl 2008

FreeRADIUS 

 27 51 59 64

Radiator 

 16 16 16 15

Microsoft IAS

 12 15 16 21

Cisco ACS 

 2 3 4 4

Cisco IOS

 0 1 1 1

Typo/not stated

14 9 5 6

Funk/Juniper

Steel-Belted

 - - - -

 

back to top of page

4. Joining eduroam / Realms

Joining eduroam is very straighforward. The first thing to do is to choose your organisational realm name. This is the second part of the username credential which will be used by individuals when logging in using eduroam. ie the '@myorganisation.ac.uk' part of the user name.

Your organisation must be entitled to use the requested realm name ie it must be (or be derived from) a DNS name from the organisation's registered DNS namespace. It is expected that most organisations will request their domain name (eg.'myorganisation.ac.uk') although it is perfectly acceptable to request a sub-domain name (eg.'computer-science.myorganisation.ac.uk')

The next step is to complete the eduroam application form - which can be found at the bottom of this section.

After your registration has been accepted, an account will be created on the Support server to enable you to manage your configuration details within eduroam. This will provide you with the capability to create sub-realms under the primary realm. Additional primary realms may be requested via JANET Service Desk.

FAQs:

Can individuals join the eduroam om JANET? Is there a way for an individual to obtain an eduroam ID without the user's home institution having to join eduroam?

No. Users must have registered network logon accounts at their home organisations and in order for individuals to use their credentials for authentication at eduroam participating sites, their home organisation has to join eduroam and install a RADIUS server which is peered with the national JRS proxy servers.

The aim of eduroam is to reduce the amount of administration required both by organisations offering guest access to their networks and for visiting users. This is achieved by users being enabled to use their own usernames and passwords when roaming. JANET(UK) has set up the NRPS network and the support service to facilitate this through the eduroam mechanism. There is no facility for users to be issued with independent IDs since this would involve another tier of administration (and defeat the aim of the service).

Do eduroam users have to be registered network logon account users at participating organisations?

Yes. Users must have a network account at their participating home organisation in order for their authentication requests to be validated when they attempt to log on at a visited organisation. They must be registered on their home organisation's AD, LDAP, NetWare etc user database. This is because JANET connected organisations are not permitted to just let anyone onto their guest networks and to access JANET/the Internet via JANET. Furthermore, there is a logging requirement for organisations to record the date and time and user name of eduroam enabled authentications. We have to be able to track down a visiting user if ever there is any security or anti-social usage incident - hence the need to limit the service to registered users.

Can I have a sub-realm for my organisation?

Question a) Does the eduroam spec allow us to configure ORPS to forward user@department.myorganisation.ac.uk RADIUS requests to the department in question's RADIUS server?

Question b) If so, will the NRPS strip off 'department' and forward RADIUS requests to the example-org ORPS?

Answer a) Yes - you can submit any number of sub-realms (such as 'department.myorganisation.ac.uk' as you like. To create a new sub-realm, browse to your organisation in the eduroam Configuration menu on the support web server, and select 'Realms'. Enter the sub-realm name into the Realm name field and press 'Create realm'.

Answer b) No - the NRPS will forward requests bearing these realms to your ORPS unchanged. Because the realm is left unchanged by the NRPS, you can perform additional proxying within your organisation if you wish (for example, to route the request to a departmental RADIUS server). This permits delegation of authentication to other units within your organisation.

Can I request a wild-card realm?

No - however, you are able to define as many "sub-realms" as you require. For example, if your realm is example.ac.uk, you can additionally define bar.example.ac.uk and foo.bar.example.ac.uk.

Application to join the eduroam service on JANET

Your application will be acknowledged and a after validity check, a eduroam technical consultant will contact you to discuss your requirement in detail and to provide you with user credentials for the JRS Support website. Following acceptance onto the scheme a welcome information pack will be sent to you.

To underpin the service and to support organisations joining and participating in the service, a comprehensive, fully resourced support structure has been put in place which provides:

  • Pre-deployment support – planning and selection of RADIUS server hardware and software and supplicant systems
  • Technical support during implementation
  • Post-implementation support on technical issues
  • Dedicated JRS Support server with web front end for eduroam site administrators only
  • Participanting organisations RADIUS service monitoring system
  • Dedicated e-mailing list for technical and service announcements
  • A chargeable consultancy service
  • Comprehensive technical and promotional documentation
  • eduroam service type and operational status table
  • Locations map showing where eduroam is available and the service details at each site

back to top of page

5. The JRS Support Server website; input organisation/site details, realm name, test account

Assertion of service type and service level

> Log in to the eduroam Support web site https://support.roaming.ja.net using the credentials supplied during joining/induction.

The left hand menu presents the following options:

  • General
  • JRS configuration
  • my account
  • log out

> Click on 'JRS Configuration' and select your organisation folder on the left hand menu pane. Your organisation folder will now expand and the left hand menu will show the following options under your organisation name:

  • Nagios LG
  • RADIUS proxy servers
  • Realms
  • Site Locations
  • Support
  • Test

The right hand pane will now display eduroam configuration details for your organisation and shows your asserted compliance and offered service level. Select the relevant 'Compliance level' (Home, Visited, working towards etc.) and 'Service level' (no service, JRS 2, JRS 3 etc.) from the drop down menus. Click the [Update compliance] or [Update service level] buttons. You must keep these assertions up to date as your implementation of JANET Roaming progresses. If, over time, any issues are detected with your organisation's compliance with the Tech Spec, these will be indicated in the compliance box. (Please resolve these!)

Also displayed are fields for:

a) your organisation's name

b) your organisation address postcode

c) your eduroam test account name (this will appear once you have asserted a compliance level), realm and password (which will only ever be seen by eduroam support staff) and EAP method to be used by the eduroam monitor test

d) the URL of the web page on which you publish key information about your eduroam service provision; AUP, locations where eduroam is available, how to use the service/user guide to configure laptops etc. See:Content for eduroam info web page guide

Please keep this information updated if you make any changes.

Once you are in a position to provide details of your test account and the URL of your eduroam info web page, please insert these into the relevant fields.

Update 'default location'/enter new site details

> Click on 'Site Locations' from the JRS Configuration left hand menu:

  • Nagios LG
  • RADIUS proxy servers
  • Realms
  • Site Locations
  • Support
  • Test

Having completed/updated details of your organisation name and post code in the step above, a default site record will have been created. Under 'Site Locations' on the left hand menu, you will see that 'default site' appears and in the right hand pane a blank 'Create a new site location' panel is displayed.

> Click on 'default site' in the left hand menu. The right hand pane now displays the default details for your main site (limited to postcode and default name, note this Site Location name is 'default location', which will stick out like a sore thumb in the internationally published data unless you update it). Please input the details about the service provided in the various fields. These include; site name and post code, site address (optional), the number of APs, number of RJ45 sockets providing eduroam (eduroam is about 802.1X on wired too), wireless ciphers, NAT if implemented, network traffic proxy if implemented, traffic port filtering if implemented, site support contact details (optional).

The information provided on this site details page will be used to populate the JANET eduroam locations maps and data tables and is also used by the eduroam organisation to produce their international site locations map. The information enables organisations to give a far better picture of their service to visitors and the rest of the eduroam world. Note, *everything* on this page will be published including the site location description and contact details (hence the contact details are optional).

> Finish site information update by clicking on the [Update Location] button.

Details about further sites

> If you have multiple sites at which you provide eduroam, you can create records for these by selecting 'Site Locations' on the left hand menu and then complete the necessary details on the blank 'Create a new site location' panel that appears in the right hand pane. By 'site' we mean a contiguous area of eduroam coverage, so if a campus comprises a number of adjacent buildings in which eduroam service is available, we define this as a singular location. (Otherwise the number of records will become unmanageable).

> Finish site location creation by clicking on the [Create Location] button. If successful, the new site name will appear in the left hand menu under 'Site Locations.'

Your Realm(s)

Click on 'realms' from the JRS Configuration left hand menu under your organisation name:

  • Nagios LG
  • RADIUS proxy servers
  • Realms
  • Site Locations
  • Support
  • Test

> The realm name(s) that you requested on your application to join will be displayed. You can create and delete additional (sub-)realms for your organisation if you require to. Do not delete your top level domain name (if you do, a request must be made to service@ja.net to have this reinstated).

Create and configure your eduroam Test account

Your eduroam Test User account is an important part of your eduroam implementation and is mandated by the Technical Specification. It is utilised by the eduroam Support Nagios service status monitoring system and can be used by eduroam site administrators to a) verify the function of 802.1X authentication (remote user test) through the JRS Support server on-demand Test utility and b) to verify auth-request forwarding for visitors by your ORPS (simulated visitor test).

Your test account must be created on your local network in the database that authenticatation will be made to from eduroam. It is important that this account is NOT subject to any account locking policies that you may have for general users. (We recommend against account locking measures in general since there are now alternative measures available but it is particularly important that the eduroam test account is not lockable since it is used by the service status Nagios monitor).

To make use of your test account through the JRS Support server, details of it must first be configured on the server.

> Click on 'JRS Configuration' and select your organisation folder on the left hand menu pane.

  • General
  • JRS configuration
  • my account
  • log out

Your organisation folder will now expand showing the eduroam configuration screen and you can now enter your eduroam Test Account username and password in the 'Test account details' panel on the right hand pane. This will enable the JRS Support system to act as a remote user for the test account you previously created in your user database.

>Click on [Update test account] button.

If you have requested multiple organisational-level realms you can select which realm the test account belongs to. You can also select the EAP method that the Nagios service status monitor test uses - PAP is the default, but you should choose the EAP method most generally used by your users.

The left hand menu of the eduroam configuration screen shows the following options under your organisation name:

  • Nagios LG
  • RADIUS proxy servers
  • Realms
  • Site Locations
  • Support
  • Test

To use the Test facility, click on 'Test' from the JRS Configuration left hand menu:

Clicking on 'Test' results in the right hand pane displaying the test functions that are available; ping, EAP - see section 12 below. The simulated visitor test can also now be run - see section 12).

To facilitate testing of ORPSs before bringing them into operational use, the JRS Support website also provides a proxy control and RADIUS traffic routing function. This also supports set up of dedicated role proxying between ORPS and NRPS if required. (This feature can be found under 'RADIUS proxy servers'). Configuration of ORPS in the JRS Support server is described below in the relevant section 10.

Your organisational firewall must be made ready for the eduroam service at some point. This involves configuring it to permit the passage of required protocols. This can be done now or after your 802.1X system has been set up and authentication tested on your home network.

See: Firewall configuration

back to top of page

6. Install Your RADIUS Server (ORPS)

If you have not already implemented RADIUS on your network, a RADIUS server of your choice must now be deployed. We recommend that software is installed on dedicated hardware or on a virtual platform. The first step is to give your server a DNS name - not forgetting to create an entry in your DNS zonefile. Next you carry out basic installation of your selected software.

It is strongly recommended that your ORPS is highly fault tolerant and preferrably a resilient dual-ORPS system is put in place. This will require configuration of fail-over or load balancing between the two ORPS. Different systems have differing requirements, but normal practice is for each of your ORPS to have a unique set of shared secrets with the NRPS (the shared secret between roaming0 and ORPS1 will be different from the secret between roaming0 and ORPS2). If your configuration requires both ORPS to have the same shared secret for each NRPS, please open a service request ticket with JANET Service Desk and we will configure the NRPS accordingly. Acquiring shared secrets for ORPS is detailed below in section 10.

The reason we strongly recommend you depoly a resilient dual-ORPS system is two-fold. a)For your own service provision b)Most importantly from a JRS operational viewpoint, to ensure that your realm always has an ORPS available to service incoming authentication requests from the NRPS. If your realm for some reason stops responding to auth-requests and these continue to arrive from your users at remote eduroam sites, a huge amount of NRPS resources will rapidly become tied up and the performance of the NRPS will be drastically reduced. This is because since RADIUS uses UDP, each auth-request results in a UDP socket being held open in the NRPS UDP buffer awaiting a reply. If your realm continues to fail to reply, the load on NRPS resources will increase to the point that effectively service will be denied to other operational eduroam sites - which are handling auth-requests properly. To prevent this situation from affecting the performance of the national service, JRS will have no option but to suspend service to your ORPS.

Resources:

 

7. Acquire Server Certificate for ORPS/NAS

Depending upon the EAP method you choose to implement, mutual authentication between client and RADIUS server is generally required. The first stage of this is that the client machines need to be able to trust the authenticity of the RADIUS servers and network access servers/APs that they communicate with during the logon process. The most popular EAP methods require that the authenticating RADIUS server must have a digital certificate. This can be from a legitimate certification authority (CA) or can be self-signed. For information about producing self-signed certificates or for a link to the JANET Certificate Service (for provision of Comodo certs foc.) see resources section below.

JRS2 and JRS3 networks (802.1x) are generally implemented using EAP methods that use transport layer security (TLS), such as EAP-TLS, EAP-PEAP and EAP-TTLS, which require the use of a server certificate to authenticate the RADIUS server to the supplicants. In addition EAP-TLS requires client certificates too in order for the clients to be validated by the RADIUS servers. These client certificates can be can also be self-signed, ie. generated by your private CA software.

Most RADIUS servers work without difficulty with certificates supplied from both root certification authorities and intermediate certification authorities such as the JANET Certificate Service (certificates provided free of charge). If you implement MS Internet Authentication Server however, particular care will be needed in configuring the server because by default it is assumed that the certificate is issued directly from a root certification authority known by the supplicant.

If organisations have multiple ORPS servers, since technically they do not need to have different certificates for each server, it is recommended that they do not acquire separate different certificates for the servers due to issues of support and client configuration/certification.

Resources:

FAQs:

Can I use the JANET Server Certificate Service to provide certificates for my RADIUS servers?

Yes - the JANET Certificate Service. (JANET CS) works fine with the most popular RADIUS servers; FreeRADIUS, Radiator and Cisco ACS and will provide you with server certificates free of charge - suitable for use with EAP-PEAP and EAP-TTLS methods. The service provides 'intermediate CA' certificates issued through TERENA SSL CA and thence chained to Comodo. The use of intermediate CA certificates is considered to be more secure than root CA type. The result of this however is that if you intend to use Microsoft Internet Authentication Service (IAS/NPS) with JANET Certificate Service, a degree of skilful configuration will be required. A technical guidance sheet which details this is available: Using Certificates Issued by the JANET Server Certificate Service with Microsoft Internet Authentication Service.

The difficulties with MS Internet Authentication Service stem from the fact that it does not send the full certificate chain during EAP-PEAP negotiation. Consequently, in order to use MS IAS with JANET CS certificates (or any other certificate not issued directly from a certification authority (CA) known by the supplicant), it is essential to:

1. Ensure that you include the correct extensions in the certificate

2. Configure IAS to include the certificate in its list of known certificates.

This issue came to light through problems experienced in attempting to use certificates issued by the JANET SCS with the Windows XP supplicant. All certificates issued by the JANET SCS are signed as from an intermediate CA; but any 802.1x supplicant, including the one native to XP, will not be able to validate certificate chains derived from intermediate CAs from Microsoft IAS because IAS does not send the full chain in the ServerHello during the TLS handshake in Phase 1 of EAP-PEAP.

So if you intend to use Microsoft IAS, your options are:

1. Use a commercially-supplied certificate that will 'chain directly' to a root CA 'known' by your supplicants.

2. Use a certificate that uses an intermediate CA, but be very careful and thorough in your configuration of IAS. Refer to the technical guide.

3. Manage your own private CA.

How do I get and install a commercial server certificate for use with MS IAS?

Can I use a self-signed certificate for my RADIUS server?

Yes. EAP methods that use TLS, such as EAP-PEAP and EAP-TTLS, require the use of a server certificate to authenticate the RADIUS server to the supplicans.

This certificate may be derived from a local self-signed certificate authority (CA), or purchased from a commercial CA. The advantages and drawbacks of both of these are listed below.

Benefits of a certificate from a self-signed CA:

  • No need to purchase a certificate from a commercial vendor.
  • Provides a slight security benefit by making it harder for a user to misconfigure their supplicant in an insecure way. (The use of a certificate from a commercial CA combined with a failure by the supplicant to validate the CN of the certificate makes a MITM attack feasible, where the attacker simply acquires a certificate from the same CA).

Benefits of a certificate from a commercial CA:

  • No need to distribute the CA's root certificate to each client.

Note: some RADIUS implementations, such as Radiator and FreeRADIUS, provide a certificate from a self-signed CA for testing purposes. Under no circumstanances should this certificate be used in a production environment. 

Resources:

  • See links in Resources section above

back to top of page

8. RADIUS server configuration and interoperation with user database

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

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 rather than requiring a full username including a realm element to be used. Since an eduroam username must include a realm component, we recommend that the username should always include the realm component, even for 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 usernames to be used in single-SSID networks where 'eduroam' is used for both local and guest users.

By requiring that the full 'user@organisation.ac.uk' type crediticals 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.

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, but no longer than 6 months.

Resources:

 

9. Firewall Configuration

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

a) The organisational firewall must be configured to permit the following protocols and port numbers from the three JANET NRPSs - 194.82.174.185 ; 194.83.56.233 ; 194.83.56.249 to the ORPS(s):

  • UDP/1812 inbound and outbound (used for authentication)
  • UDP/1645 inbound, only if your ORPS requires this (deprecated)
  • UDP/1813 inbound and outbound (used for accounting)
  • UDP/1646 inbound, only if your ORPS requires this (deprecated)
  • UDP/1814 inbound and outbound (used by FreeRADIUS when acting as a proxy, ie forwarding packets)
  • ICMP
  • ICMP must also be permitted for JRS Support server 193.60.199.62

b) The organisational and/or ORPS firewall must be configured to allow UDP fragments to pass. This is because certain EAP methods generate very large packets which get fragmented in transit. It is vital to the RADIUS exchange that these fragments are not discarded. [If you are using Solaris ipf firewall the config script can be written to pass fragments using the keep frag keyword].

c) An important aim of eduroam is to provide visitors with unimpeded access to JANET, not least because this maximises the probability of a visitor’s applications working as expected. The Tech Spec therefore requires that as a minimum the forwarding of the following protocols is permitted (sites may of course be more liberal and permit a wider range of protocols and a greater number of ports to be open, but this is at their discretion):

  • Passive (S)FTP: TCP/21 egress and established
  • SSH: TCP/22 egress and established
  • PPTP: IP protocol 47 (GRE) egress and established; TCP/1723 egress and established
  • ESP: TCP/50 egress and established
  • AH: TCP/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
  • LDAP: TCP/389 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, TCP 1194 and UDP/5000-5110 egress and established
  • Citrix: TCP/1494 egress and established
  • RDP: 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: TCP/5900 egress and established
  • AFS: UDP/7000 through UDP/7007 inclusive egress and established
  • Cisco IPSec NAT traversal: UDP/10000 and TCP/10000 egress and established
  • VNC: TCP/5900 egress and established

back to top of page

10. Configure JRS Support Website with your ORPSs details - shared secrets

The next stage is to get your ORPS(s) to peer with the NRPSs so that they can exchange RADIUS communications across JANET. This involves two operations:

  • configuration of the NRPSs to proxy with your ORPS
  • configuration of your ORPS to proxy with the NRPS

Operation 1 is detailed here and is accomplished through the JRS Support website. For operation 2 see next section.

By selecting "JRS Configuration", once logged into the Technical Support web site, choosing your organisation from the left hand menu and then selecting "RADIUS proxy servers", a screen enabling the creation of ORPS on the support database and thence the NRPSs will be displayed.

You must enter the following details for your ORPS:

  • Fully qualified domain name: (The fully qualified domain name of the RADIUS proxy server; do not use the IP address). This field is mandatory.
  • Authentication port: (The port that the RADIUS server is listening on for authentication requests). This field is mandatory.
  • Accounting port: (The port that the RADIUS server is listening on for accounting requests). This field is mandatory.
  • Function: The function of the OPRS - authentication only, accounting only, client (no auth or acct packets to be sent to it, but NRPS will accept packets from it - which would be applicable if you provide a Visited-only service), authentication and accounting (the default. These setting enable you to set up the most efficient RADIUS deployment to suit your organisation.
  • Test/Development: For test purposes you may wish to peer the OPRS with eduroam, but not receive production or eduroam test/monitor traffic; only anyuser@test.youruniversity.ac.uk traffic will be sent to the ORPS to facilitate your own testing.
  • Operating system name: (The name of the operating system running on the RADIUS proxy server (for example, "Redhat Enterprise Linux" or "Microsoft Windows")).
  • Operating system version: (The version of the operating system running on the RADIUS proxy server (for example, "Advanced Server 3" or "2003")).
  • RADIUS software name: ( The name of the RADIUS implementation running on the RADIUS proxy server (for example, "FreeRADIUS" or "IAS")).
  • RADIUS software version: (The version of the RADIUS implementation running on the RADIUS proxy server (for example, "1.1.0" or "2003")).

When complete, click on [create RPS].

The new ORPS will appear under "RADIUS proxy servers" on the left hand menu.

Selecting the new ORPS will result in the ORPS details screen being displayed. These details can be ammended and the ORPS can be updated.

At the bottom of the screen, the shared secrets with the three NRPS will be displayed. These must be entered into the relevant configuration files on your ORPS servers.

Once the JRS Support server has refreshed the configurations of the NRPSs, your ORPS(s) will be able to proxy to the NRPSs. Note that changes may take up to an hour to be propagated to the eduroam NRPS infrastructure.

To enable full RADIUS communications you must allow all NRPS to talk to your ORPS systems (eg. edit clients and proxy.conf files). You must configure your ORPS for roaming0.ja.net, roaming1.ja.net and roaming2.ja.net to have full auth and accounting passes - 1812/1813 on UDP and be allowed as clients on your ORPS.

Normally every ORPS has a unique set of shared secrets for peering with the three NRPS. This is best practice and the most secure way of employing shared secrets. This remains true even in scenarios in which peered realms contain multiple RADIUS servers. It is now quite common practice for organisations to deploy multiple ORPSs, which they may do for resilience or load sharing. When an organisation registers a second ORPS, by default a further unique set of shared secrets is generated, different from those for the first ORPS. eduroam administrators must be aware that in deployments where the ORPS form fail-over clusters you cannot simply use the original three shared secrets on both ORPSs.

We recognise however that there are particular solutions which use and require a common shared database for all clients and so require the same shared secret for each NRPS to be used by all ORPSs. Where two ORPS are deployed in fail-over systems that use the same set of secrets for each ORPS-NRPS proxy/client config. (ie ‘secret0’ for roaming0 for both ORPSs, ‘secret1’ for roaming1 for both ORPSs, ‘secret2’ for roaming2 for both ORPSs) we can, on request, adjust the details stored on the JRS Support server, (ie we will duplicate the settings for one of your ORPS). This has had to be done for a number of sites that have chosen a cluster solution that doesn’t allow different keys for remote agents.

If this is required, please choose the ORPS that will be the nominal shared secret seed and which ORPS you want to have adjusted to be the same as that seed and let us know.

Where multiple ORPS are configured, the order in which these are queried by the NRPS is by default based on the order that the ORPS were added to the Support server. One ORPS can be set as top priority and will be the first ORPS contacted. This can be done by selecting the Priority setting on the ORPS config page to High or Normal. Setting an ORPS to High priority will overwrite any previously configured High settings. If you have multiple ORPS and wish to create a prioritised list, you must ensure that you add the ORPS/set them as High priority in your preferred order. Nb. The NRPS do NOT load balance between your ORPS, they only use fail-over to the next server(s) in the system - which is triggered if the higher listed ORPS is busy or offline.

back to top of page

11. RADIUS server proxying configuration and attributes filtering

In this section:

  • Configure Peering with NRPSs
  • Configure Realm Handling, Proxying and Load Balancing
  • FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang
  • Testing your Configuration - shared secrets check; authentication against local database; remote authentication
  • Configure Peering with orther RADIUS servers on your network
  • Configure Attribute Filtering
  • Configure Injection of Operator-Name Attribute (FreeRADIUS and Radiator only)
  • Configure Rejection of Malformed Usernames
  • FAQs/Resources

11.1 Configure Peering with NRPSs

You must allow all three NRPS to talk to your ORPS systems (hint - edit clients.conf and proxy.conf files). Roaming0.ja.net, roaming1.ja.net and roaming2.ja.net must have full authentication and accounting passes - allowed as clients on your ORPS through UDP ports 1812/1813 (authentication and accounting). The NRPS will not listen on anything other than the proper RADIUS ports 1812 and 1813. If your ORPS needs to use ports 1645/46 (inbound), these should also be configured - the NRPS will send on these if you have set the configuration so, as detailed in section 10 above.

The shared secrets with the NRPS are generated through the Technical Support web site, as described above.

Accuracy is essential when transcribing the shared secrets to the configuration files. It should be remembered that these are used independently to validate and encrypt client (NRPS remote authentication) and proxying (visitor authentication forwarding from ORPS) connections. An error in one of the shared secrets can lead to confusing problems such as i) remote authentication working whilst visitor authentication fails ii) unreliable performance due to authentication failure occuring when one NRPS is utilised whilst successful authentication is achieved through the others.

The following applies to Microsoft NPS and IAS implementations only. 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.

11.2 Configure Realm Handling, Proxying and Load Balancing

The next stage is to configure your ORPS so that RADIUS access-request packets from your users are handled locally while requests from visiting users are forwarded to the NRPS servers. (Do this by for example editing the authorize section and the proxying logic in radiusd.conf).

Nb. We recommend a policy that ALL users (home users and visitors) who try to authenticate via eduroam MUST have a realm component in their username (ie must be of the form 'user@myorganisation.ac.uk') and that your realm handling logic drops any user without a realm name in their outer id. This is avoid the 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. This is because the Visted site ORPS will not recognise the user name and should drop it, but even if it forwards the access-request to the NRPS, the NRPS will not know where to forward the request and so will drop it, returning an access-deny including explantory text. Do NOT permit authentication based on a simple username - insist that the username contains @realm.

How requests are handled and how different RADIUS server modules should authenticate and authorise the users must be configured. 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.

Nb. (Advisory applicable only to FreeRADIUS and Radiator) - it is possible to set up your ORPS to be too "open" with regard to forwarding authentication requests, which can make interpretation of logs very difficult. A unsatisfactory situation can arise if your ORPS is configured to forward requests based on inner identities in addition to forwarding based on the mandatory outer ids. The default on FreeRADIUS is too open and should be closed down. By default Radiator is fine, but it is possible to set up undesirable forwarding based on inner id.

The order in which your ORPS communicates with the three NRPS should be considered. Most participants order the three NRPS in the order: roaming0, roaming1, roaming2. The effect of this is that roaming0 is the most heavily loaded of the three national proxies. In order to ensure the best responsiveness for your ORPS and to help avoid overloading roaming0, it is recommended that you order the NRPS in the proxy configuration differently.

Load balancing of communications with the NRPSs should be set up. However the method used must be such that all RADIUS conversation in relation to any one particular authentication event is directed through only one NRPS for the duration of the conversation. Problems arise if proxy state and conversation sequence do not tally at the NRPS.

Radiator 3.1 and up, MS IAS, NPS, Cisco Secure ACS and FreeRADIUS 2.x all have good EAP load balancing capability, but older software, such as FreeRADIUS 1.x, must only be used in 'fail over' mode rather than 'load balance' (ie. use fail_over in proxy.conf, not round_robin).

It is essential that your ORPS does not mark any NRPS as 'dead' if no reply is received while attempting to hand off authentication of visitors to your site to the visitors' Home organisation via the NRPSs. Remember it is not the NRPS that are authenticating the visitor, it is the Home site. The NRPS simply acts as proxy and waits for a response from the Home site. This can take some time, especially if the visitor is from outside the UK. Furthermore, the NRPS does not detect whether the remote Home realm is responsive or not and so will not reply to your ORPS with any error message. It will only forward error messages returned in RADIUS packets from the remote Home site.

11.3 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 JRS Support server

11.4 Testing your Configuration

Once the ORPS(s) have been configured, authentication can be tested using the test tools on the JRS 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. FreeRADIUS, Radiator and MS IAS/NPS include suitable utilities. The simplest test involves trying to send access-request packets to the NRPS for forwarding to the JRS Support ORPS for a test user - the test user belonging to the JRS ORPS realm. (This is a command line variation of the standard simulated visitor test - see section 12 below). Nb 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) that your have registered on the JRS Support server as specified above in section 5. Remember, any changes your make to your config on JRS Support can take up to an hour to take effect.

The FreeRADIUS commands would be:

Radtest your_realm@eduroam.ac.uk <password> roaming0.ja.net 1812 <shared secret for roaming0>

Radtest your_realm@eduroam.ac.uk <password> roaming1.ja.net 1812 <shared secret for roaming1>

Radtest your_realm@eduroam.ac.uk <password> roaming2.ja.net 1812 <shared secret for roaming2>

For Radiator use radpwtst, which provides a similar function. For Microsoft IAS/NPS use ntradping. Radtest and radpwtst include PEAP/EAP alternatives for the more advanced user.

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 JRS Support server as specified in section 5. You then have a variety of options for testing authentication at your realm - using the remote JRS 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 JRS 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 JRS infrastructure. This can be done via the relevant RADIUS proxy servers page on the JRS 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.5 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 will have to configure peering between them.

11.6 Configure Attribute Filtering

Frequently organisations make use of attributes within RADIUS packet during the Access-Request / Challenge and Accounting exchanges to check user/machine parameters or to control how users are given access to the network. Such exchanges are frequently of local relevance only and can cause problems during remote authentication attempts. Filtering of all but the most essential RADIUS attributes from the return packets should therefore be implemented to avoid the local access point at the Visited site receiving attributes it doesn't know how to handle.

The following is the minimum set of attributes required to support eduroam. These must not be filtered out:

RADIUS Access-Request or Access-Challenge message attributes:

1.    User-Name
18.  Reply-Message
24.  State
25.  Class
80.  Message-Authenticator
31.  Calling-Station-ID
33.  Proxy-State
79.  EAP-Message
       MS-MPPE-Send-Key
       MS-MPPE-Recv-Key
126. Operator-Name

RADIUS Accounting messages:

1.    User-Name

40.  Acct-Status-Type

44.  Acct-Session-ID

25.  Class

33.  Proxy-State

This list has been determined following a small number of incidents involving roaming eduroam users being unable to connect at certain institutions (both here in the UK and elsewhere) owing to over-restrictive attribute filtering. Please note that implementation of the list is likely to become a mandatory feature of eduroam.

For more information on this topic see:

11.7 Configure Injection of Operator-Name Attribute (FreeRADIUS and Radiator only)


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

The FreeRADIUS configuration 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.

11.9 Resources/FAQs

   (produced and published by GEANT2)

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 JRS 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 (pdf)

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 (pdf)

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.

back to top of page

 

12. Test facilities on JRS Support Server / 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 to permit authentication of their roaming users via eduroam. The Support server also supports a background monitoring test using NAGIOS which continually tests the status of all ORPSs.

JRS Support Server ORPS/Authentication Tests

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

a) basic dead or alive status of your ORPS

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

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 facilities are not available at present due to the complexities relating to the digital certificate requirements (clients require unique server and client certificates).

How to use the tests:

1) A test user account must first be registered on the JRS Support Server web site with details including the test user name, password, the realm that the organisation wishes to test and the EAP method or PAP required. 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 JRS Support server, go to the eduroam configuration page and select 'Test' from the drop down list under your organisation name in the left hand menu.

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.

Click on the [Test ICMP] button

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.

PAP authentication - this tests a clear-text authentication attempt, such as those generated by web redirect systems (although not necessary for 802.1x implementation it is nevertheless required that all sites enable PAP for the test user account).

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 (innerMD5)

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.

 

Simulated Visitor Authentication Test

You can test vistor authentication without needing to request a set of credentials from JANET or a mentor/buddy organisation. The JRS Support Server will return Access-Accepts for authentication requests for a test user with a name of 'your_realm' at the realm 'eduroam.ac.uk'. The password is the same password you registered on JRS Support for your local test user account.

If you have already set up 802.1X authentication on your network, you can use a network-connected laptop or workstation to test authentication of a visitor. Alternatively you can run authentication tests directly from your ORPS using radtest, radpwtst or NTRadPing (for FreeRADIUS, Radiator and IAS/NPS respectively).

Points to note:

  • use your realm as the actual user identity rather than your test account user name (this is to ensure a unique test user name for each participant - several sites have chosen the same name for their test accounts)
  • use one of the following as the realm: roaming.ja.net, janetroaming.net, eduroam.ac.uk, eduroam.org.uk
  • use your test account password for this test (not your JRS Support server password)
  • disable certificate validation as this is not currently supported for this test

For example, if your realm is "foo.ac.uk" and your JRS Support server test account user name is: "jrstest" and the password is "password1", then for a visitor user test at your site simply use the following in the supplicant for the user credentials:

foo.ac.uk@eduroam.ac.uk
password1

The alternative way to perform a visitor test is to run test commands from your ORPS. For FreeRADIUS this would be as follows:

Radtest your_realm@eduroam.ac.uk <password> roaming2.ja.net 1812 <shared secret for roaming2>

The service supports PAP, PEAP, EAP-TTLS/PAP and EAP-TTLS/MSCHAPv2.

Participants are permitted to use the simulated visitor authentication test for their own monitoring solutions but should configure any such solutions to not query this service more often than once every 5 minutes.

Monitoring of eduroam Participants' ORPS

eduroam operates a remote monitoring system service for participating organisations that assert an operational service. This is powered by Nagios and runs from the JRS Support server. There are two components of this monitor:

  • ICMP 'are you alive' ping (or TCP 2002 for Cisco ACS CSA sites)
  • EAP authentication of test account from remote site (applicable to operational 'Home' and 'Home & Visited' service sites only and only for 'full service' ORPS)

ICMP probes run from the JRS Support server and from all three NRPS every 5 minutes to check basic connectivity and server status. For RADIUS servers that cannot accept ICMP, ie Cisco ACS RADIUS servers running CSA, an alternative solution using telnet on TCP port 2002 has been implemented.

RADIUS authentication probes using your preferred EAP method (originally this test used PAP) are made to participants' realms from all three NRPSs every 5 minutes using the test accounts. This tests that the participating organisation has an operational remote user authentication service for the realm. Since we can control from which NRPS the access-request is sent from, we can test that your realm accepts such traffic from all three NRPS. However we cannot direct RADIUS traffic to a particular ORPS at your realm. Therefore in cases where an organisation has multiple ORPS, it is essential that you check that the shared secrets are correct. Reminder about shared secrets with the NRPS

The authentication method used by the probe test was extended from the original PAP-only method and now supports PEAPv0/MSCHAPv2, PEAPv1/MSCHAPv2, EAP-TTLS/PAP, EAP-TTLS/MD5 and EAP-TTLS/MSCHAPv2. The EAP method that organisations actually use for their users can be selected on the site's eduroam configuration page on the JRS Support web site.

For technical reasons we do not send out automated notifications of failures, however eduroam site administrators now have access to the Nagios system for their particular site (feature added March 2010). After logging on to the JRS Support server, under the 'JRS configuration' menu on the left hand pane, select 'Nagios LG'. This looking glass view gives eduroam admins access to the results of the relevant Nagios monitoring processes for their site/realm. Access to this tool should help participants to see more readily underlying issues.

Testing a new ORPS within eduroam Infrastructure before bringing it into production use

We have introduced the facility for you to set up peering of a (new) ORPS with the NRPS in a protected test-mode. This allows you to carry out your own tests without the ORPS becoming part of the production infrastructure and without it being sent live production or Nagios test traffic. Nb, the JRS Support on demand EAP tests are also effectively disabled in this mode.

Setting an ORPS to protected test-mode can be achieved by designatating the ORPS as 'test/development' via the JRS Support server eduroam configuration/Radius Proxy Server menu. Once an ORPS has been set to protected test-mode, only traffic with 'test' prefixed to your realm name will be sent to your test/development server. This enables you to carry out 'loopback' tests using eg: testuser@test.yourorganisation.ac.uk.

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.

For full details see: ORPS-role-designation-features-JRS-Support-Server

FAQs:

Why do I get only "Re-sending Access-Request" when testing authentication via the support server?

Ensure that your firewall is configured to permit UDP ports 1812, 1813 and 1814. RADIUS does not use TCP!

You should also check that your firewall is not discarding UDP fragments. If it is then the configuration should be changed to allow UDP fragments to pass. [Specifically for ipf firewall users, (to be found on Solaris systems) the config script can be changed to PASS fragments using the keep frag keyword].

Rationale - with certain EAP communications, eg EAP-TLS, the RADIUS packet sizes can get much bigger than the usual MTU of 1500. This means that the RADIUS packets get fragmented in transit. Many firewalls are configured to drop UDP fragments (as security against DoS attacks), however this will, of course, break such RADIUS communications. If your firewall is doing such dropping then it will need to be configured to ALLOW such traffic from NRPS<->ORPS. This will affect more sites as people migrate to full 802.1x implementations and use eg EAP-TLS or other EAP methods which use larger packets.

Resources:

back to top of page

13. RADIUS server log keeping and interpretation of logs

It is a mandatory requirement of the JRS Techncial Specification that participating organisations keep RADIUS logs of authentication traffic.

It is strongly recommended that JRS System Administrators make it routine practice to inpsect their RADIUS logs in order to detect any abnormalities and hidden problems.

Clarification of Policy and Tech Spec Wording - Visitor Activity Logging (Word)

Clarification of Policy and Tech Spec Wording - Visitor Activity Logging (pdf)

 

FAQs:

Can you clarify the Policy/Tech Spec on vistor logging?

Using the Test facility on JRS Support web site for EAP-TTLS with PAP inner authentication results in errors in our FreeRadius log due to use of null value outer user name by the JRS Test. Why is this and what's the solution?

The log error is due to the JRS Support server using an outer user name comprising just the realm name for the Test. This conforms to the correct RFC format for anonymous outer identity, in accordance with RFC 4282:

"Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user."

The JRS test used to use anonymous@realm, however feedback from several organisations led us to adopt the correct RFC format.

ORPS shouldn't be acting on the outer identity unless you really need to - this value is easily set to be whatever value you want and therefore must not be used to authorise. The solution is to add a simple addition to the sql.conf which remove this from logging etc. the inner ID should still be accounted and logged.

The NRPS are only testing one of our ORPSs using the test account configured on the Support server, why is this?

JANET has set up a system to monitor the RADIUS request handling status of Home organisations, ie. that an ORPS is operational. This is done using the test user account that participating organisations set up on the JRS Support server.

In your RADIUS logs you are seeing a single NRPS using the JRS Support test account to check the service status on just one of your ORPS. The reason for this is that the RADIUS check is being launched from the support site and goes via the NRPS. So a NRPS that can handle the request will only pass the request through to the first working ORPS at your site. This validates that your site is currently able to handle JRS RADIUS requests but does not check that ALL of your ORPS are alive.

The servers can be checked for network connectivity by PING but the only way to check RADIUS would be to allow a direct Support Server to ORPS RADIUS link. This is deemed unacceptable and would invalidate the JRS check - as we really need to monitor how the NRPS see the ORPS. Monitoring of the status of the ORPS system (be they load balanced, failover or round-robin constructed) is down to the individual organisations.

back to top of page

14. Monitoring your own service

A monitoring system should be set up to ensure that you are aware that your eduroam system is operating satisfactorily and that your OPRS is communicating with the NRPS. Nagios is often used for this purpose (and this is what JRS uses to monitor the availability of participants' authentication systems).

As indicated above in section 12, participants are permitted to use the JRS simulated visitor authentication test for their own monitoring solutions, but if you do so you must configure any such solution to only query the simulated visitor test service at intervals exceeding 5 minutes.

If your RADIUS solution supports server-status (FreeRADIUS and Radiator 4.7), you should employ this method to check that your ORPS can successfully communicate with the NRPS (and that the NRPS are responsive).

back to top of page

15. Setup VLAN for Visitors network

Visited organisations must implement a separate network/VLAN for each JRS tier that they choose to implement. A tier's VLAN must not be shared with any other tier or network service.

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 following section.

VLAN requirements:

JRS2 VLANs:

  • wireless networks must use a broadcast SSID of 'eduroam' (which must be lowercase)
  • all SSIDs must be broadcast
  • DHCP must be employed to allocate IP addresses
  • The JRS2 and JRS3 tiers must only implement IEEE 802.1x; no form of WRD is permitted
  • 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
  • The JRS2 tier must not implement WEP; it must implement WPA/WPA2
  • 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

Specific requirements for JRS3:

  • Routing of IPv6 on the visitor VLAN must be supported
  • Use of NAT is not permitted
  • WEP must not be implemented

Resources:

back to top of page

16. Workstation/Laptop Setup

One of the potential hurdles to be overcome in a successful 802.1X institutional deployment is the roll out of 802.1X supplicant and its configuration, including configuration of the client for checking of the ORPS certificate! (Without this check, users are susceptible to credentials harvesting attacks.) Once you have decided on the supplicant of choice and the necessary EAP settings there remain potentially two major operations:

  • Distribution of third party supplicant software - if you have decided not to rely on built in operating system supplicant. (With the introduction of Windows 7 the imperative to use a more satisfactory supplicant than the built in Microsoft Windows software has receded somewhat - unless your system cannot support PEAP/MSCHAPv2 in which case you will still require your users to use a third party supplicant.)
  • Configuration of this supplicant software - a large proportion of users are either relucatant / not up to the job of correct configuration of the software. Expecting users to correctly configure supplicants, whether native or third party, is optimistic in the extreme. Automating this process serves to help both the end user and IT Services, since the burden of fixing misconfigured machines can be eliminated.

There are now at least two tools which make the whole undertaking much more manageable:

FAQs:

How do I configure Windows to work with 802.1x?

Details of all aspects of setting up the client and using eduroam are included in the User Guide however the following extract details setup of the client in Windows XP.

Why am I having a problem using eduroam with MS Vista?

Windows Vista has a slightly different PEAP authentication to that of WinXP. This difference means that Vista 802.1x authentication will not work with older versions of Cisco ACS, RADIATOR or FreeRADIUS ORPS sotware at Home organisations.

Latest versions of these AAA RADIUS servers have been released which fix this problem:

FreeRADIUS 1.1.4 - tested
RADIATOR 3.16 - tested
Cisco ACS 4.1 - not tested (would like feedback from sites using this)

As this issue is only at the authentication end, visitors with Vista should happily be able to use eduroam at a Visited site if their Home site has upgraded their ORPS.

back to top of page

17. Q.A. Test of your eduroam implementation

eduroam is a federated service and as such relies on all participants to offer high quality operational services - the Technical Specification is in place to try to ensure this, but by its federated nature there is a degree of trust that participants will implement it faithfully. There is at present no national accreditation process, so we rely on participating organisations to test their implementations thoroughly themselves. An unreliable or badly configured service reflects badly on the rest of the eduroam world and brings the service into disrepute.

Your network should not broadcast the eduroam SSID until you have an operational Home or Visited service and the following tests can be passed.

We are at present developing a rigorous test list. In the meanwhile, the following checks are recommended:

ORPS - NRPS Communication Test ICMP check - the reachability of each ORPS must be verified individually. All ORPS must be reachable by UDP and ICMP/TCP (and so your firewall must be configured accordingly) and must be peered with the NRPS and handle RADIUS traffic correctly to support authentication.

From your access to the JRS Support server, the Nagios LG program can be viewed or the on-demand ping tests can be run to verify ICMP to each ORPS.

  • ICMP Check                                          - PING OK

Authentication Test - Authentication check from each NRPS to your realm. From your access to the JRS Support server, the Nagios LG menu option under your JRS Configuration can be viewed. This tests authentication via the first available ORPS at your realm. This verifies proper configuration of NRPS 'clients' and realm handling on your ORPS

  • EAP Authentication Check                       - access-accept for NRPS0
  • EAP Authentication Check                       - access-accept for NRPS1
  • EAP Authentication Check                       - access-accept for NRPS2

Visited Organisation - Simulated Visitor Test Authentication - to verify that authentication attempts by visitors to your service will be forwarded to the NRPS, the simulated visitor test, as detailed in section 12 Simulated Visitor Test should be run where applicable.

  • Simulated Visitor Test                            - success

Peering Configuration check (verify ALL shared secrets) - The basic authentication check above only tests authentication via the first available ORPS at your realm. In cases where there are multiple ORPS, the client peering of each ORPS for each NRPS must be also be checked individually. Similarly the simulated visitor test only checks authentication via one of the NRPS to the 'eduroam.ac.uk' realm. Run utilities such as radcheck to verify shared secrets for all ORPS-NRPS combinations, client and proxy.

  • to verify proper configuration of all 3 NRPS 'proxy' settings on your ORPS and in multiple ORPS deployments to verify NRPS 'client' configs: radcheck / radpwtest / ntradping tests - ok for each ORPS/NRPS combination

Correct Realm Handling by ORPS (anti-auth-loop) - to reduce user authentication/misconfiguration problems and eliminate the danger of your ORPS marking the NRPS as dead due to our ORPS-NRPS authentication loop prevention logic. The test usernames listed below should be applied to a client on your network and you should check that your ORPS handles realm names correctly and does NOT proxy the authentication attempts up to the NRPS. Such misbehaviour could potentially initiate an 'authentication loop' since logically the NRPS should send the auth-request back to your ORPS and the ORPS would then erroneously send the request back to the NRPS again - causing a never-ending authentication loop as access-requests have no time-to-live limit. This would be a serious situation leading to a loss of service.

To prevent this, the NRPS have anti-authentication loop logic which will drop the misdirected access-requests if your OPRS does forward such usernames. However, since your ORPS will get no reply from the NRPS there is the danger that your ORPS will mark the NRPS as dead - leading to it not forwarding valid access-request packets for a period of time and causing authentication problems. It is therefore important that your ORPS handles username variations correctly.

ORPS username handling tests ('realm' stands for your full realm name eg. 'myorganisationname.ac.uk'):

  • testuser@realm@other(egCAauthrealm)     - handled locally and NOT forwarded to NRPS
  • testuser@UPPERCASErealm                   - handled locally and NOT forwarded to NRPS
  • testuser@validsubrealm.realm                   - handled locally and NOT forwarded to NRPS
  • testuser@realm                                       - handled locally and NOT forwarded to NRPS
  • invalidtestuser@realm                              - rejected locally and NOT forwarded to NRPS

The following section focusses on expands on invalid User-Name (ie those that do not conform to the Network Access Identifier standard).

Username Handling Conformance Check - of particular importance in deployments where a single SSID 'eduroam' is implemented at an orgnisation, usernames MUST be in the form user@myorganisationname.ac.uk (.net and .org.uk are also acceptable as is .subrealm.ac.uk etc.) This ensures that users are able to utilise eduroam in a seamless manner when they travel.

The following test usernames should be applied to a client on your network and you should check that your ORPS drops them without authentication against your user database or forwarding to the NRPS:

  • testuser (no realm name component)                        - authentication should be dropped (User-Name MUST contain '@')
  • testuser@@anyrealm (contains two '@')                   - authentication should be dropped (User-Name MUST NOT contain '@@')
  • test user@any realm (contains spaces)                   - authentication should be dropped (User-Name MUST NOT contain '  ')
  • testuser@.anyrealm (starts with a dot)                        - authentication should be dropped (User-Name realm MUST NOT start with '.')
  • testuser@anyrealm. (ends with a dot)                        - authentication should be dropped (User-Name realm MUST NOT end with '.')
  • testuser@myorganisationname..ac.uk (contains double dot)                        - authentication should be dropped (User-Name realm MUST NOT contain double '..')

eduroam Information Web Site - you must have an information web site as detailed in the Tech Spec and described in section 18 below promoting eduroam at your organisation

  • eduroam information page on organisation web site        - yes

JRS Support Server Organisation Congifuration Details Up to Date - the information you have entered into the web page for your organisation must be up to date, particularly the following:

  • Conformance status
  • Service level
  • 'Test EAP method' should be the EAP method most used by your users
  • Individual site details

back to top of page

18. Promoting eduroam at your organisation

There are three key elements to promoting eduroam at your organisation:

  1. An eduroam information page or section on your organisation web site advising eduroam users of the key points to enable them to use the eduroam service at your site. This is mandatory requirement of the Tech Specification. A content guide (pdf) is available [Word version].
  1. Advertising the locations at which eduroam is available and raising general awareness of eduroam in your organisation.
  1. Providing information and training if necessary to your own users on the service.

It is a mandatory requirement of the Technical Specification that Visited organisations publish information on their web site page for visitors about how to use eduroam at their site. You must update the URL of your eduroam information page on the JRS Configuration page on the JRS Support web site. (This enables this information to be published on our eduroam locations map pages).

Although it is not mandatory for Home only organisations to publish a 'how to use eduroam' web page, it is highly recommended that you publish such a page to provide information for your own users to help them to use the service when they roam to other sites.

For Visited organisations, the Tech Spec requires that their eduroam web page is accessible from both the Internet and from within the organisation in order to allow visitors easy access to information they may wish to refer to.

As a minimum the Visited organisation's web site must include the following:

  • The participant’s acceptable use policy (AUP)
  • Sufficient information to enable visitors to identify and access the service; the locations where eduroam is available, the JRS Tier(s), and the SSID(s)
  • Information regarding any application or interception proxies that may be deployed and if this is not transparent, how to configure applications to work with the proxy

There is further guidance in the content guide (pdf) (Word version).

Resources:

back to top of page

19. Keeping your configuration details data on the JRS Support website up to date

The details you enter on the JRS Support site are the source used to populate the information maps on the www.ja.net/roaming web site and the eduroam database for the benefit of eduroam users. It is therefore important that you keep your organisation's eduroam configuration and guest network details up to date. Any issues with the data you supply on the main config page will be highlighted in the "Detected issues" box. Reminder of how to update details.

The most important data entry is done on your main eduroam configuration page on the JRS Support site, but it is also important to keep the RADIUS proxy servers page and individual sites network information current. After making any changes please hit the relevant [Update] button for the changes to take effect.

In June 2008 we significantly expanded the amount of data we wished to collect prompted by the requirements of the eduroam organisiation.

Original information requested:

- your level of compliance with the Tech Spec

- the service tier you provide

- organisation details

- test account details

- your eduroam service information web page

- main technical contact user

and on the RADIUS proxy server page:

- RADIUS proxy server FQDN

- authentication port

- accounting port

- operating system

- version

- RADIUS software

- version

and on the Realms page:

- realms

Additional information about your guest network if relevant now requested:

- is the guest network NATed

- any proxying transparent or not

- any IP port restrictions (inbound/outbound) applied to the network connection

- whether wired Ethernet eduroam access is available
- number of eduroam-enabled 802.1X sockets*

- number of wireless access points for eduroam network

- wireless ciphers in use at the location

* you will only be able to see the wired socket request if you state you provide sockets

Nb. Only sites stating 'working towards' or 'achieved' Visited compliance will be able to see the guest network fields. Either category of participant can enter values, but only fully compliant sites will have their numbers passed through to eduroam and the eduroam web site.

There will be some extra logic/checks and removals of options for those sites to which this does not apply - eg Tier 3 sites cannot NAT so the option will be gone (and hardset to 'no')

For those sites which run multiple tiers, please give the answer that is suitable for your BEST network - eg those sites with tier2/tier2, please supply the information for tier2 (eduroam themselves only care about the network given the SSID 'eduroam' so therefore in such mixed cases, this would be the best tier on your site)

This information will be made available to the rest of the eduroam community on the main JRS Support site general page as well as supplied to the eduroam information pages on ja.net and such data may also be in a future RSS/XML feed.

back to top of page

20. Planning ahead and developing your eduroam implementation

We plan to add to the documentation available on the Documentation page with features on best practices and ideas to enhance and develop eduroam implementations. We also plan to introduce a 'UK eduroam Technical Development Roadmap' to indicate plans for the progression of the eduroam service and changes to the Technical Specification that will take effect in the UK in the future.



Any problems, comments or suggestions regarding this page, please e-mail the eduroam service manager.

 

 

 

Privacy Policy | Web Admin
© The JNT Association,
JANET(UK), Lumen House, Library Avenue
Harwell Science and Innovation Campus, Didcot, Oxfordshire
OX11 0SG