Implementing JANET Roaming - 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 JANET Roaming
  5. The JRS Support Server website; input organisation details and realm name
  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
  14. Setup VLAN for Visitors network
  15. Workstation/Laptop Setup/MS Vista issue
  16. Promote JRS at your organisation - your JRS/eduroam web site
  17. Keep your configuration details data on the JRS Support up to date

 

1. Concepts and Terminology

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

www.ja.net/documents/services/janet-roaming/jrs-deployment-guide.pdf

 

2. Deciding your JANET Roaming Implementation

The first step is to decide what form of implementation of JANET Roaming would best suit your organisation. Choose from:

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

b) Visited only organisation so you provide JANET Roaming 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 you.

Next, decide what system or combination of services you wish to deploy - JANET Roaming is stratified into three tiers depending upon technology, network and authentication protocols employed, JRS 1, 2, 3. Essentially these tiers are based on combinations of authentication method (web redirect or 802.1x), IP versions (IPv4, IPv6), NAT (employed or not) and wireless security technology (WEP, WPA, WPA2). JRS 1,2,3 matrix. Nb. we strongly advise against the adoption of JRS 1, web redirection method, on the grounds of its security weaknesses. (It was included in the original JRS Tech Spec in order to make the service as inclusive as possible). Despite these variations, all JRS tiers use the same national JANET RADIUS infrastructure and between the tiers, a high level of inter-operability is generally achievable.

If you decide to offer a Home service using 802.1x, 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 JANET Roaming Technical Support

(The selection of supplicant issue will soon be made easier to resolve when the OpenSEA 802.1x supplicant is released - due soon).

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 - JANET Roaming 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 JANET Roaming 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 JANET Roaming / Realms

Joining JANET Roaming 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 JANET Roaming. ie the @exampleuniversity.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."exampleuniversity.ac.uk") although it is perfectly acceptable to request a sub-domain name (eg."staff.exampleuniversity.ac.uk")

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

FAQs:

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

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

The aim of JANET Roaming 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 JANET Roaming 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 JANET Roaming 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 JANET Roaming 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 JANET Roaming spec allow us to configure ORPS to forward user@department.example-org.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.example.ac.uk") as you like. To create a new sub-realm, browse to your organisation in the JRS 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 JANET Roaming

Your application will be acknowledged and a after validity check, a JANET Roaming 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 scheme, 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 JANET Roaming-support web site for participants only
  • Dedicated e-mailing list for technical and service announcements
  • A chargeable consultancy service
  • Comprehensive technical and promotional documentation
  • JANET Roaming availability map showing where and how JANET Roaming can be used

back to top of page

5. The JRS Support Server website; input organisation details and realm name etc.

> Log in to the JANET Roaming 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 administrivia
  • JRS configuration
  • JRS stats
  • 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:

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

The right hand pane will now display JRS 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 JRS 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 JRS test account name (this will appear once you have asserted a compliance level), realm and password (which will only ever be seen by JANET Roaming support staff) and EAP method to be used by the JRS monitor test

d) the URL of the web page on which you publish key information about your JANET Roaming/eduroam service provision; AUP, locations where eduroam is available, how to use the service/user guide to configure laptops etc. See:Content for JRS 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 JRS info web page, please insert these into the relevant fields.

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

  • 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 (JANET Roaming 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 JRS 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 JRS and 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.

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

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

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

Click on 'Test' from the JRS Configuration left hand menu:

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

If you have not entered the details of your JANET Roaming test account you will be prompted to configure details of your test account. Your test account must be created on your local network in the database that authenticatation will be made to from JANET Roaming. Enter details of your test account on the top level JRS configuration page for your organisation as detailed above. Once the test account has been configured, the right hand pane will display the test functions that are available. (For details of the simulated visitor test see section 12 below).

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 JANET Roaming 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. The first stage is to carry out a basic installation of your selected software. We recommend that software is installed on dedicated hardware.

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 JANET Roaming Technical Specification.

Interoperation with User Database

For each home realm authentication request handled by the ORPS, the user database (LDAP, NDS, AD) generally has to be interrogated by the RADIUS server.

Set up logging

Logging on the ORPS must be set up in accordance with the JANET Roaming 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 JANET Roaming 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
  • UDP/1645 inbound, only if your ORPS requires this (deprecated)
  • UDP/1813 inbound and outbound
  • UDP/1646 inbound, only if your ORPS requires this (deprecated)
  • UDP/1814 inbound and outbound
  • 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 JANET Roaming 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 JRS Tech Spec therefore requires that the forwarding of the following protocols is permitted:

  • IPv6 Tunnel Broker NAT traversal: UDP/3653 and TCP/3653 egress and established
  • IPSec NAT traversal: UDP/4500 egress and established
  • Cisco IPSec NAT traversal: TCP/10000 egress and established
  • PPTP: IP protocol 47 (GRE) egress and established; TCP/1723 egress and established
  • OpenVPN: TCP/5000 egress and established
  • SSH: TCP/22 egress and established
  • HTTP: TCP/80 egress and established
  • HTTPS: TCP/443 egress and established
  • LDAP: TCP/389 egress and established
  • LDAPS: TCP/636 egress and established
  • IMSP: TCP/406 egress and established
  • IMAP4: TCP/143 egress and established
  • IMAP3: TCP/220 egress and established
  • IMAPS: TCP/993 egress and established
  • POP: TCP/110 egress and established
  • POP3S: TCP/995 egress and established
  • Passive (S)FTP: TCP/21 egress and established
  • SMTPS: TCP/465 egress and established
  • Message submission: TCP/587 egress and established
  • RDP: TCP/3389 egress and established
  • VNC: TCP/5900 egress and established
  • Citrix: TCP/1494 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 JANET Roaming 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 JRS, but not receive production traffic, only anyuser@test.youruniversity.ac.uk will be sent to it 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 JRS NRPS infrastructure.

To enable full RADIUS communications you must allow all NRPS to talk to your ORPS systems (eg. edit proxy.conf file). 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.

back to top of page

11. RADIUS server proxying configuration and attributes filtering

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 JANET Roaming 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.

Configure Realm Handling, Proxying and Load Balancing

The next stage is to configure your ORPS so that RADIUS requests from your users are handled locally while requests from visiting users are proxied to the NRPS servers. (eg. edit the authorize section and the proxying logic in radiusd.conf). 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.

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

Testing your Configuration

Once the ORPS(s) have been configured, authentication can be tested using the facilities on the JRS Support web site as described below.

In scenarios involving multiple ORPSs, it is advisable to test each ORPS independently for correct configuration. It is possible to check secrets by simply running a command line check on each of the ORPS. Freeradius and RADIATOR include suitable utilities. You will need to have or create a test user account on your site with a valid password (eg. a local account on the RADIUS server).

The Freeradius command would be:

Radcheck testuser@yourrealm <password> roaming0.ja.net 1812 <shared secret for roaming0>

Radcheck testuser@yourrealm <password> roaming1.ja.net 1812 <shared secret for roaming1>

Radcheck testuser@yourrealm <password> roaming2.ja.net 1812 <shared secret for roaming2>

By using 'testuser@yourrealm' rather than simply 'testuser', the NRPS will interpret the request and send an authentication 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 whichever one is free). However the above three lines WOULD verify that the ORPS could talk to each NRPS - ie no bad secrets and no firewall problems! If you have multiple ORPSs you could always turn off the other ORPSs while doing each test, which would guarantee that only the ORPS that was up would get used. This is a way of verifying that that single ORPS is valid from each NRPS.

RADIATOR comes with radpwtst which provides a similar function.

Both of the above utilities include PEAP/EAP alternatives for the more advanced user..though everyone's test account can hopefully still be authenticated using PAP.


For Microsoft IAS you can use ntradping to test against the NRPS.

Configure Peering with other site ORPS

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

Configure Attribute Filtering

Frequently organisations make use of attributes within RADIUS packet during the Access-Challenge / Request 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 receiving attributes it doesn't know how to handle.

The following is the minimum set of attributes required to support JANET Roaming. 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

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 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 JANET Roaming.

If you are aware of any other attributes then please contact JRS Support.

For more information on this topic see:

Resources:

   (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 JRS Technical Specification using FreeRADIUS in an AD environment: A Case Study in Complying with the JANET Roaming Service 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 JANET Roaming Service Technial 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 JRS 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

JRS 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 JANET Roaming. The Support server also supports a background monitoring test which continually tests the status of all ORPSs.

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

The facility to peer a (new) ORPS with the NRPS so allowing you to carry out tests without the ORPS becoming part of the production infrastructure and being sent live production traffic has been set up. This can be achieved by designatating an ORPS as test/development via the JRS Support server. In order to facilitate testing, NRPS realm handling has been configured such that only traffic with your realm name prefixed with 'test' will be sent to your test/development server. This enables you to carry out 'loopback' tests using eg: testuser@test.youruniversity.ac.uk.

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

JRS Support Server ORPS/Authentication Tests

The tests available to JRS participant administrators via the JRS Support server enable:

a) checking of the status of the ORPS

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

c) simulation of a user visiting from another organisation to your site. (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 JANET Roaming. This should allow at least five failed authentication attempts without being locked. Nb The test account credentials will only ever be known to JRS Technical Support.

3) Log in to the JRS Support server, go to the JRS 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

From a laptop or workstation connected to your network, simply make use of your JRS Support server test account to attempt to log on as follows:

i) use your realm as the actual user identity rather than the test account user name (this is to ensure a unique user name for the test - several sites have chosen the same name for the test account)

ii) use one of the following as the realm: roaming.ja.net, janetroaming.net, eduroam.ac.uk, eduroam.org.uk

iii) use your test account password for this test (not your JRS Support server password)

iv) 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 simply use the following for a visitor user test at your site:

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

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

Monitoring of participants' ORPS

JANET Roaming 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. ICMP probes run from the JRS Support server every 5 minutes to check basic connectivity and server status. RADIUS probes (which originally used PAP) are made of the participants' realms from all three of the NRPSs every 5 minutes using the test accounts to test authentication function. For technical reasons we do not send out automated notifications of failures nor give access to the NAGIOS system to participants, but in event of an ORPS failure we will be able to rapid diagnose the problem using the logs.

The authentication method used by the probe test has now been extended from the original PAP-only method to include 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 JRS configuration page on the JRS Support web site.

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.

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 and 1813. 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 interpretation of logs

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

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

 

FAQs:

Can you clarify the JANET Roaming 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 Roaming 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. Setup VLAN for Visitors network

Visited organisations must implement a separate network/VLAN for each 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:a broadcast SSID of 'eduroam' must be used on wireless visitor networks; all SSIDs must be broadcast; DHCP must be employed to allocate IP addresses.

For JRS2 VLANs:

  • 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

15. Workstation/Laptop Setup

FAQs:

How do I configure Windows to work with 802.1x?

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

Why am I having a problem using JANET Roaming 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 JANET Roaming at a Visited site if their Home site has upgraded their ORPS.

back to top of page

16. Promoting JANET Roaming at your organisation

There are three key elements to promoting JANET Roaming at your organisation:

  1. A JANET Roaming information page or section on your organisation web site advising JANET Roaming/eduroam users of the key points to enable them to use the JANET Roaming service at your site. This is mandatory requirement of the JRS Tech Specification. A content guide (pdf) is available [Word version].
  1. Advertising the locations at which JANET Roaming eduroam is available and raising general awareness of JANET Roaming 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 JRS Technical Specification that Visited organisations publish information on their web site page for visitors about how to use JRS eduroam at their site. You must update the URL of your JANET Roaming information page on the JRS Configuration page on the JRS Support web site. (This enables this information to be published on our JANET Roaming locations map pages).

Although it is not mandatory for Home only organisations to publish a 'how to use JRS 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 JRS Tech Spec requires that their JANET Roaming 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 JRS 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

17. 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 JRS/eduroam users. It is therefore important that you keep your organisation's JRS 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.

The most important data entry is done on your main JRS 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 JRS Tech Spec

- the service tier you provide

- organisation details

- test account details

- your JRS/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 JRS-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 JANET Roaming 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 tier1/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 JRS community on the main JRS Support site general page as well as supplied to the JRS information pages on ja.net and such data will also be in the RSS/XML feed available soon.

back to top of page

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

 

 

 

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