JANET Roaming Logo

 JRS Home | About JRS/how JRS works | Map - where you can use JRS eduroam

Using JRS | Documentation | Technology/FAQs | Technical Support | How to Join

Implementing JANET Roaming - Roadmap

 

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

 

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.

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). Nb. we strongly advise against the adoption of JRS 1, web redirection method, on the grounds of its security weaknesses. All tiers however use the same national JANET infrastructure and within 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 (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).

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

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 3.17.1 is the latest version, last modified April 12 2007).

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

 - - - -

 

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

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

Go to https://support.roaming.ja.net.

Once logged in to the JANET Roaming Technical Support web site using the credentials supplied, select "JRS Configuration" and choose your organisation from the left hand menu list. A screen showing your asserted compliance and offered service level is displayed. You must keep these assertions up to date as your implementation of JANET Roaming progresses.

Also displayed are fields for:

a) your postcode

b) the URL of your web site on which you publish details about JANET Roaming and how to use the JANET Roaming service you provide.

c) the test account name, realm and password (which will only ever be seen by JANET Roaming support staff) - if you have set up a test account (see below)

d) any detected issues with your compliance with the JRS Technical Specification (please resolve these!)

Please keep this information updated if you make any changes.

By selecting "realms" on the lefthand menu under your organisation name, the realm name(s) that you requested on your application to join will be displayed. You will be able to create and delete additional (sub-)realms for your organisation. Do not delete your top level domain name (if you do, a request must be made to service@ja.net to have this reinstated).

By selecting "test" on the lefthand menu, 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. Once the test account has been configured, the screen will display the test facilities that are available.

The JRS Support website also provides a proxying control function (under "RADIUS proxy servers") to facilitate set up of proxying between ORPS and NRPS. This will be utilised in the appropriate step below.

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

 

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:

 

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.

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

Microsoft technical article; Certificate Requirements when using EAP-TLS or PEAP with EAP-TLS

FAQs:

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

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?

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:

back to top of page

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:

(produced and published by GEANT2)

 

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
  • UDP/1813
  • ICMP

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

 

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:

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

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

RADIUS server proxying configuration and attributes filtering

Configure Peering with NRPSs

You must allow all NRPS to talk to your ORPS systems (eg. edit clients.conf and proxy.conf files). Roaming0.ja.net, roaming1.ja.net and roaming2.ja.net must have full auth and accounting passes - allowed as clients on your ORPS through UDP ports 1812/1813 (authentication and accounting).

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

Configure Realm Handling and Proxying

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.

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.

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

Test facilities on JRS Support Server

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

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.

The tests available 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 digital certificate requirements (clients require unique server and client certificates).

The available test functions 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)

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 - but use your realm as the actual user identity rather than the test account user name and one of the following as the realm: roaming.ja.net, janetroaming.net, eduroam.ac.uk, eduroam.org.uk

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 compliant participating organisations. This is powered by NAGIOS and runs from the JRS Support server. ICMP and RADIUS probes (which originally used PAP) are made of the participants' realms from the roaming1 NRPS every 5 minutes using the test accounts. 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 PAP-only 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:

 

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.

 

Setup VLAN for Visitors network

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

  • The JRS1 tier must only implement WRD NASs
  • WRD NASs must support RADIUS PAP authentication
  • WRD NASs must support Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protection of the authentication transaction with the visitor’s client, and be configured to present visitors with a server certificate from a well-known certificate authority

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 may implement WEP; if it does not, it must implement WPA/WPA2
  • Visited organisations that choose to deploy WEP must configure their WAPs to require the use of 128-bit keys, and to rotate these keys every five minutes
  • 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:

 

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.

 

Promoting JANET Roaming at your organisation

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

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

Resources:

 

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.

Most of the 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 information current.

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

* 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