JRS Home | About JRS - How JRS Works | Participating Organisations Map |
Documentation | Technology/FAQs | Technical Support | How to Join
This page is constantly being added to.
Choose from:
a) Home only organisation so your members can benefit from JRS at other sites,
b) Visited only organisation so you provide JRS 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.
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 and wireless security technology (WEP, WPA, WPA2). It should be noted that all tiers use the same national JANET infrastructure and a high level of inter-operability is generally achievable.
If you decide to offer a Home service, 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 (it is not necessary to have a WLAN in place on your home network to provide a service to enable authentication for your users when they are at remote sites on the visitors WLAN).
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).
To set up as a Visited site, a different set of issues must be addressed, particularly the encryption system you choose to deploy on your WLAN, the set up of VLAN assignment onto a 'guest' VLAN on your Access Points and switches. Also your firewall from the guest VLAN must permit certain traffic types as detailed below. If you decide to offer a Visited site service, the above facilities will have to be implemented.
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:
(pdf) (pdf) (pdf) (pdf)(produced and published by GEANT2)
FAQs:
What RADIUS server software are JRS participants using?
Number of ORPS installations by RADIUS software type:
| December 2006 | July 2007 | |
| FreeRADIUS | 27 | 51 |
| RADIATOR | 16 | 16 |
| Microsoft IAS | 12 | 15 |
| Cisco ACS | 2 | 3 |
| Cisco IOS | 0 | 1 |
| Error/typo | 8 | - |
| not stated | 6 | 9 |
| Steel-belted | - | - |
| Funk | - | - |
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 JRS. 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 JRS? Is there a way for an individual to obtain a JRS/eduroam ID without the user's home institution having to join JRS?
No. Users must have registered network logon accounts at their home organisations and in order for individuals to use their credentials for authentication at JRS participating sites, their home organisation has to join JRS and install a RADIUS server which is peered with the national JRS proxy servers.
The aim of JRS 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 JRS 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 JRS 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 JRS 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.
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.
Your application will be acknowledged and a after validity check, a JRS technical consultant will contact you to discuss your requirement in detail. 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:
Go to https://support.roaming.ja.net. By selecting "JRS Configuration", once logged into the JANET Roaming Technical Support web site, and choosing your organisation from the left hand menu, a screen asserting your compliance and service offered level is displayed. You must keep these assertions up to date as your implementation of JANET Roaming progresses.
Also displayed are fields for the test account user name (which you must create on your local network), the realm name(s) that you requested on your application to join, the test account password (which will only ever be seen by JRS support staff) and the URL of your web site on which you publish details about and how to use the JANET Roaming service you provide.
By selecting "realms" on the lefthand menu under your organisation name, you will be able to create and delete additional (sub-)realms for your organisation.
If you have not already implemented RADIUS on your network, a RADIUS server of your choice must now be deployed.
Resources:
The next stage is to get your ORPS(s) to peer with the NRPSs so that they can exchange RADIUS communications across the network.
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:
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.
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.
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):
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 JRS 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:
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:
(pdf)
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.
If you implement JRS 1 (web redirect), the network access servers (APs) on your Visitor VLAN must use a certificate from a "well known" certification authority.
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 Server 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:
Factsheet; Using Digital Server Certifiates
FAQs:
Yes - the JANET Server Certificate Service (JANET SCS) 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. However if you intend to use Microsoft Internet Authentication Service (IAS) with JANET SCS, skilful configuration will be required. A draft guidance tech guide sheet is available on request.
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 SCS 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. The certificate you acquire from a vendor must be one that will 'chain directly' to a root CA 'known' by your supplicants.
2. Be very careful and thorough in your configuration of IAS. Anyone considering use of SCS certificates should contact JRS Support, pending a suitable write-up. The write-up is likely to take some time, as it's rather complex.
3. Manage your own private CA.
How do I get and install a commercial server certificate for use with MS IAS?
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:
Benefits of a certificate from a commercial CA:
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:
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 reach home realm authentication request handled by the ORPS, the user database (LDAP, NDS, AD) generally has to be interrogated by the RADIUS server.
Configure Peering with NRPSs
You must allow all NRPS to talk to your ORPS systems (eg. edit proxy.conf file). Roaming0.ja.net, roaming1.ja.net and roaming2.ja.net must have full auth and accounting passes - 1812/1813 on UDP and be allowed as clients on your ORPS.
The shared secrets with the NRPS are generated through the JANET Roaming Technical Support web site, as described above.
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 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 come with suitable utilities. The Freeradius command would be:
Radcheck testuser@realm <password> roaming0.ja.net 1812 <shared secret for roaming0>
Radcheck testuser@realm <password> roaming1.ja.net 1812 <shared secret for roaming1>
Radcheck testuser@realm <password> roaming2.ja.net 1812 <shared secret for roaming2>
By using testuser@realm rather than testuser the NRPS will understand the request and send authentication request back to the ORPS (though it could be to any of the individual servers in an ORPS group!) However those three lines WOULD verify that the ORPS could talk to each NRPS - ie no bad secrets and no firewall problems! You could always turn off the other ORPS 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 was valid from each NRPS.
Radcheck is part of the Freeradius package.
RADIATOR comes with radpwtst which can do a similar function. both have PEAP/EAP alternatives for the more advanced user..though everyones test account can hopefully do PAP still.
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.
Set up logging
Logging on the ORPS must be set up in accordance with the JANET Roaming Technical Specification.
Resources:
(produced and published by GEANT2)
FAQs:
What Attribute filtering should I allow?
The following is the minimum set of attributes required to support the JRS. 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 the JRS.
If you are aware of any other attributes then please contact JRS Support.
For more information on this topic see:
Troubleshooting Microsoft IAS as a RADIUS server and as a RADIUS proxy
This link to the MS TechNet site should be useful:
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.
Novell has produced documentation on configuring FreeRADIUS against eDirectory:
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 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.
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.
Participating organisations, once they have registered a test user account with password on the JRS Support Server web site, are able to carry out a number of tests to verify the correct configuration of their ORPS/user database to permit authentication of remote users via JANET Roaming. The test account should be created in the organisation's user database that is authenticated against by JRS. This should allow at least five failed authentication attempts without being locked. Nb The test account credentials will only ever be know to JRS Technical Support.
The tests available enable checking of the status of the ORPS and the following authentication protocols: PAP, EAP-PEAP, EAP-TTLS.
PAP is used for web redirect authentication (JRS1). EAP-PEAP and EAP-TTLS authentication are both commonly used for 802.1x authentication. It is likely that your organisation will want to support one of the EAP protocols below.
Available test facilities are:
ICMP ping status test - to ensure an ORPS is up and running at the participant's site.
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)
EAP-TLS - test facility not available at present due to the complexities relating to digital certificate requirements (clients require unique server and client certificates).
FAQs:
Can you clarify the JRS 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?
The JRS 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.
Visited organisations must implement a separate 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 (but 'eduroam-web' may be used where an organisation offers a web redirect service alongside another JRS service and
'eduroam-wep' may be used where an access point provides both WEP and WPA/WPA2 security); all SSIDs must be broadcast; DHCP must be employed to allocate IP addresses.
JRS1 VLANs:
For JRS2 VLANs:
Specific requirements for JRS3:
Resources:
FAQs:
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 JRS 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 JRS at a Visited site if their Home site has upgraded their ORPS.
There are two key elements to promoting JRS at your organisation:
Resources:
Any problems, comments or suggestions regarding this page, please e-mail the JRS service manager jrs@ja.net
