Roaming Technology - FAQs
- End-user FAQs
- JRS Administrator / Technical Infrastructure / Implementation FAQs
- General Information / Business Management FAQs
|
JRS Administrator / Technical Infrastructure / Implementation FAQs
|
General Information / Business Management FAQs
|
About JANET Roaming and eduroam
When was the JANET service launched?
The JANET Roaming service was launched on 2nd May 2006. This followed the LIN Trial which ran from August 2005 until December 2005 and the Service Pilot phase from 19th January 2006 to launch. Details of the LIN trial can be found at: www.webarchive.ja.net/development/aa/lin/archive/
How popular is the service - have you got any usage figures?
Membership of the service has been steadily growing since launch and there are currently 116 registered JRS UK participating organisations. This represents 18.4% of the total of the c.630 total of JANET-connected organisations, which is a healthy percentage considering the broad mix of JANET customers from HE to small specialist colleges (for many of which JRS is not relevant).
Regarding usage, there was a threefold increase between May 2008 and March 2009 and there was a similar threefold increase over the preceeding eight months (Sept 07-May 08).
 |
Where can I use the service, how widely available is it?
You can see where the organisations that have registered to participate in the JANET Roaming service are in the UK by clicking on the link in the top menu bar - 'MAP - where you can use JRS eduroam'.
For maps and details of the overseas countries that are members of eduroam, click here -
Europe: www.eduroam.org/index.php?p=europe
Asia Pacific: www.aarnet.edu.au/Content.aspx?p=137
Canada: https://wiki.bc.net/atl-conf/display/CANEDUROAM/Canada+eduroam
For a Google-maps powered zoomable map of Europe showing SSID and wireless encryption for each site see:
Europe: http://monitor.eduroam.org/gmap.php
What is a 'Home' site / What is a 'Visited' site?
Organistation may offer eduroam as a 'Home' and/or 'Visited' service. With a Home service, users can gain authentication at other eduroam sites they might visit (ie the Home site acts as an identity provider). Visited service sites provide an eduroam guest network that supports users visiting from organisations that provide a Home service. The idea of such a flexible approach is to be as inclusive as possible and to allow organisations to implement the type of service that suits their policies and local infrastructure/technical expertise.
Common misconceptions / myths about JANET Roaming eduroam
1. JRS eduroam only provides wireless network facilities for visiting guests
Not at all - the service is based on 802.1x technology which can be implemented using ordinary Ethernet LAN switches to provide JRS eduroam guest network access JR45 outlets. In fact is it easier to implement hard-wired JRS as you do not have the complications of wireless ciphers and AP setup to contend with.
2. JRS eduroam is difficult for end-users working / configure laptops for
It is true that it is possible to implement a difficult system to setup/administer - eg if an EAP-TLS based solution is selected which requires the distribution of certificates for every machine. However the most commonly implemented systems (based on PEAP-MSCHAPv2 or EAP-TTLS/xxx) are NOT difficult to configure laptops/mobile devices for. There may be an unecessarily long series of mouse clicks involved with some wireless client software/supplicants, (eg. MS Windows) but many supplicants are in fact very straighforward to set up.
To help in this area JANET has been an active contributor to the OpenSEA Xsupplicant development project whose aim is to eliminate this problem and produce cross-platform, easy to configure 802.1x supplicant software.
The second area of potential difficulty is that since we cannot impose one standard WLAN solution on JANET customers, the various universities and colleges are free to implement their chosen WLAN wireless network authentication and data encryption methods. This is why we require all participating organisations to pubish the cipher settings on their web sites and why we will shortly be publishing this information directly on our JRS locations map pages.
3. JRS eduroam is an unreliable service
Not true at all - JRS eduroam has a rock solid infrastructure and guest network reliability at participating sites is no more unreliable than any other network or WLAN. The problems arise when insufficient attention is paid to the minor s/w tweaks that may be required when roaming from site to site.
Users should bear in mind that in the UK there are many and varied organisations and that they are independent. JRS eduroam is a federated service and relies on the trust and co-operation of the participating organisations. It aims to support all the various different guest network implementations that the members have put in place (whilst adhering to the the JRS technical specification).
This means that regarding wireless connectivity at UK sites (and the same applies in many other countries throughout eduroam), there is no one standard. In order to successfully connect to a network that is not your home WLAN you simply have to get the wireless network authentication and data encryption settings correct for the network you are visiting (and you've set your IP address and DNS server addresses to be obtained automatically using DHCP). You'll need admin rights on your machine to do this. Details of how to do this will be set out on the visited site's web pages.
4. JRS eduroam is not widely available
There are now over 100 organisations in the UK participating in the service. The locations and availability of the service can be seen on the JRS map pages
Travelling Abroad - eduroam
I am travelling to an eduroam-participating country, how do I find out the status of the service provided by their NREN (local JRS equivalent)?
The status of the NREN eduroam infrastructure is monitored here:
The status of individual national RADIUS proxy servers is available here:
http://monitor.eduroam.org/eduroam/mon_server.php
How do I find out whether the organisation I plan to visit offers eduroam and details about it?
You should check out the web site of the organisation you intend to visit to determine availability of wired/wireless network and encryption/SSID settings - just as you would before visiting a UK site.
To find the web site of the organisation overseas, you will be able to navigate to the country NREN eduroam site and from thence to their maps and links to the places you plan to visit, click here -
Europe: www.eduroam.org/index.php?p=europe
Asia Pacific: www.aarnet.edu.au/Content.aspx?p=137
Canada: https://wiki.bc.net/atl-conf/display/CANEDUROAM/Canada+eduroam
For a Google-maps powered zoomable map of Europe showing SSID and wireless encryption for each site see:
Europe: http://monitor.eduroam.org/eduroam_map.php
Joining JANET Roaming / Realms
Can individuals join JANET Roaming? Is there a way for an individual to obtain a JRS/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).
Workstation/Laptop/Palmtop Setup
My smart phone/handheld device was working perfectly well with eduroam before 6th Nov '08 but now it doesn't - what's happened and how can I get it working again?
We have recently tightened up the NRPS realm handling behaviour so that now realm checking is more rigorous. Incorrectly formatted realms with spurious extensions are now not forwarded, which means that some devices that previously worked with eduroam now no longer do so.
Check your realm settings on the device - it is likely that you have incorrectly configured EAP settings and the device may be trying to use the certificate as the realm. It is possible that you may have put your userid@myorg.ac.uk as your user in use id (it shoud be simply 'userid') and not configured the realm as specified, (it may read 'From certificate', which is wrong). Consult your IT dept for details about how to configure the settings correctly.
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.
To make life easier I want to uncheck the 'Validate Server Certificate' in my XP client - what's wrong with doing that?
You should *ALWAYS* validate the server certificate - the option in the supplicant (be it Windows native, SecureW2, OpenSEA et al) should always be enabled. Certification is one of the main
securing blocks of EAP, which underpins the JRS eduroam service.
If you don't verify that the RADIUS server (which is handling your sensitive authentication credentials) is legitimate and not being spoofed by an unscrupulous person, you are leaving yourself open to having your credentials stolen. Maintaining the security of your credentials is one of the requirements of the JRS usage policy that you subscribe to as part of using the service - ie. it is mandatory.
How can I clear the username that the XP supplicant appears to cache?
The issue is that when using the XP built-in supplicant, after successful authentication
the credentials are cached and you are not prompted again for a username and password. If a different user wishes to use that machine, the problem arises that the username and password are wrong and can't be changed.
What you need to do is to clear out the EAPOL key so that you are prompted for username/password again. This can be done by using regedit.
I visit organisations that use different WLAN encryption methods (WPA/TKIP and WPA2/AES). How can I configure Vista to make it easy to connect to SSID 'eduroam' for both - without having to manually change the protocol settings each time?
Using the netsh command, which allows us to manage wireless connection profiles as editable .xml files, it is possible to create two working Vista profiles - one for WPA/TKIP, the other for WPA2/AES.
The same result can also be achieved by simply using the standard Vista wireless manager - you just create two profiles, one for each method. However since Vista automatically attempts to name the profile using the SSID - which in this context will be 'eduroam' - you will not be able to add the second different profile with the same name.
So firstly set up a WLAN profile for eduroam using WPA/TKIP. The trick now is to rename this first eduroam profile, as say eduroam-tkip, so that the second profile can be added (and then renamed to say eduraom-aes). To rename a profile go to "managing wireless networks", choose eduroam, press F2 and rename the profile to eduroam-tkip. This changes the name of the profile, but not the SSID. Next you manually add the second eduroam profile, configuring it for WPA2/AES and then rename the profile to say eduroam-aes.
If you have two profiles, Vista will display both SSIDs when it sees an eduroam WLAN, but if the particular eduroam network only supports one cipher, one of the networks will be shown as unavailable. Of course both profiles can be marked as automatic and then one of them will be used, depending on the particular situation.
[If you do this for either TLS or TTLS/SecureW2, then connection to the second profile is automatic. However with PEAP you will be asked for credentials for the second time (only once, of course)].
The above applies to Vista only - not 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 software at Home organisations.
Updated versions the most popular RADIUS servers have been released which fix this problem:
FreeRADIUS 1.1.4* - tested (1.1.7 was the last 1.1.x release. Latest version is now 2.1.3)
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.
*Vista will work with 1.1.4 but 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). A 1.1.6 system would be far better than 1.1.4 and the final release of 1.1.x was 1.1.7 and is the one to use IF you must use 1.1.x. We see no reason not to go for a later 2.1.x version though. 2.1.3 is the latest release and fixes many 1.1.x issues and includes amongst other features a much enchanced stats monitoring system.
How can I get my Palm TX handheld to work with JANET Roaming?
Palmtops need 802.1x supplicant software to work at the vast majority of JANET Roaming sites (excepting those providing web redirect authentication JRS1) - the supplicant software must support the authentication protocols in use on your home network (EAP-TLS, EAP-TTLS, EAP-PEAP(v0 or v1)). The Palm TX uses Palm OS Garnet 5.4 which supports wireless connection, but unlike XP and Vista does not include an 802.1x supplicant. This software is however available in the Wi-Fi Enterprise Security Update (ESU) package which costs $5.99 from www.palm.com/us/software/esu.
User Authentication
I've heard of pGina, can it be used to enable authentication for a Windows machine into a non-Windows network?
As standard, the Microsoft Windows NT/2000/XP client operating system only provides for a single method of user authentication - via a Microsoft Windows Server. Should you wish to use a user database on a non-Windows server to authenticate access for Windows machines, eg. an existing Unix server and its existing base of users, there are a few non-ideal options - eg. use a Windows server for authentication and maintain identical lists of usernames/passwords on each server or use Samba to emulate a Windows NT 4 Server.
The pGina project however has developed a replacement for the authentication portion of the Windows 2000/XP OS. This has created a wide choice of many different methods for the authentication and login of a user. It has been achieved through the creation of a substitute for Microsoft's replaceable GINA (Graphical Identification aNd Authentication) dynamic link library DLL component that is loaded by the Winlogon executable. The pGINA can dynamically load “plugins', where a plugin can be created to use ANY method of authentication. For further information see: What is pGina?
Top of page
Web Redirect
'Web redirect' or 'captive portal' is the system currently used in many Internet cafes and commercial wireless hotspots. However it has serious security weaknesses and JANET advises against its use. Captive portal works as follows; when a user starts their web browser, the request is intercepted and forwarded to a redirect server which usually presents the user with either a login page for authentication/payment or to an information page for the user to read/agree to conditions of use. This is simple and straightforward to use, but there are serious security flaws and the user is vulnerable to a number of attacks as detailed below.
In the academic community many early adopters of distributed authentication for network access chose to present a web-based authentication interface, typically on a guest wireless LAN. The approach has been to intercept web traffic from the client, either by policy-based routing, DNS or HTTP manipulation, and redirect it to a web proxy. This then presents a login screen in place of the requested web pages until such time as a successful authentication has been accomplished, after which it acts as a transparent pass-through for the length of the session. Some organisations have elected to offer a web-only guest service; others used dynamic firewall rules on the proxy device to open up a wider range of protocols to the authenticated visitor. Many commercial wireless ISPs follow this strategy for user authentication, since it is intuitive and effectively self-documenting.
A number of manufacturers have introduced products implementing this model, among which Bluesocket and Vernier have attained significant market share in the higher and further education arena.
The JANET Roaming Service in the UK accommodated legacy web-redirection network access services within tier JRS1 for an initial period following launch of the service. WRD is now not permitted and JRS1 has been withdrawn as of 1st May 2009 for a number of reasons as follows:
- entered credentials are visible at the NAS (Network Access Server) and any intervening RADIUS servers
- subsequent data communications are not secured in any way unless additional measures are taken, such as VPN
- IP/MAC spoofing may allow trivial session hijack
- they are potentially vulnerable to the so-called ‘evil twin’ attack, whereby an attacker creates a ‘clone’ of an authorised login screen on a rogue access server in order to harvest credentials
- proxying may break some web applications.
Historical note: where web redirect systems were used in a JANET Roaming Service context, for
example as an adaptation of an existing standalone guest service, a number of
conditions had to be met - in particular, it was required that the interface had to support SSL
or TLS security based on a certificate acquired from ‘a well-known’ certificate provider. This improved security by ensuring that all WRD NASs used a certificate to identify themselves to the visitors' web browsers. These provisions did not entirely eliminate the concerns set out above
(which focus on credential protection), and tier JRS1 services were considered to provide only
low security contexts in which it was recommended that additional data privacy measures, such as VPN, were
adopted.
The JRS1 web redirect option has always been deprecated has now been withdrawn. Organisations wishing to provide a guest infrastructure are strongly encouraged to develop an 802.1x infrastructure and to adopt JRS tier 2 or higher service.
For futher information please see:
http://www.terena.nl/activities/tf-mobility/deliverables/delF/DelF-f.pdf
What are the security issues with web redirect?
WRD is widely deployed within many organisations, and is also supported by all visitor clients possessing a web browser. However, WRD has some significant limitations.
Firstly, because the visitor provides a user name and password to the WRD NAS, these credentials are visible to the NAS and any intervening RADIUS servers involved in forwarding the credentials.
Secondly, it does not provide data privacy for subsequent communications over the wireless LAN.
Thirdly, it is relatively trivial for an unauthenticated attacker to abuse the network in a non-traceable fashion. For example, an unauthenticated attacker can easily spoof the IP and MAC addresses of an authenticated user, and masquerade as that user.
Finally, WRD is vulnerable to the so-called ‘evil twin’ attack, whereby an attacker creates a ‘clone’ of an authorised WRD NAS. Users are easily tricked into entering their credentials into the ‘clone’ because it looks identical to the authorised NAS. This vulnerability is the reason that the JRS tier 1 requires all WRD NASs to use a certificate from a well-known certificate authority to identify themselves to visitors' web browsers.
In the light of these limitations, we have always strongly recommend against its deployment for JRS and WRD is now not permitted. (Organisations may still offer their own WRD systems for use by their own users and visitors, but they are not permitted to advertise them with 'eduroam', use the 'eduroam' SSID nor connect them to the JRS service).
802.1x and EAP Technical Sheets
What is 802.1x and EAP and how do they work?
- IEEE 802.1x - three page JANET technical sheet on 802.1x outlining its benefits and describing how it works and listing currently available supplicants together with their main features and applicability.
- Extensible Authentication Protocol (EAP) - three page JANET technical sheet on EAP, describing how it works, EAP types and implementation considerations.
Top of page
Joining JANET Roaming / Realms
Is JANET Roaming eduroam available to all members of an organisation - academic staff, administrative staff and students? Do JANET Roaming users have to be registered network logon account users at a participating organisation?
Yes, JANET Roaming eduroam is available to all members of the academic community. 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 we have an additional top level realm for our organisation?
Yes, provided your organisation is entitled to use that realm and has registered it in the DNS zone file. If you need to apply for a new domain name see:
www.ja.net/services/domain-name-registration/register.ac.uk
To use the realm name within JRS, it must first be added into the JRS Support database. For security reasons JRS site administrators are NOT able to add new tld realms to the JRS Support database directly from the JRS Support web site config pages. Instead requests must be registered through the JSD support desk in the usual way.
Can we have a sub-realm for our organisation?
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?
b) If so, will the NRPS strip off 'department' and forward RADIUS requests to the example-org ORPS?
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'.
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.
Top of page
How do we get the site information on JRS map pages/Site Finder spreadsheet updated?
The data presented on the JRS map pages is derived from information provided by the participating organisations themselves.
The mechanism for getting your site data/data updates onto the JRS map pages and into the 'site finder' spreadsheet updated is for the JRS administrator at your organisation to update the JRS configuration data on the JRS Support server. Changes will automatically be passed through to JRS administration and the JANET website pages will be updated.
The 'Site-Finder' spreadsheet is presented as Excel file. Whilst it is appreciated that Excel is not available to everyone, the information contained is alternatively available to all in the pop-up tables on the map pages. The Excel spreadsheet is published in case people want bespoke lists of participating organisations since it is easily to sort and filter the data it contains.
I've forgotten my account credentials for the JRS Support server / the JRS administrator has left the institution.
If you look on the login page of the JRS Support site at the bottom left of the screen you'll see a link to 'Request new password'. This will take you to a page from which you can request a replacement password.
If the JRS administrator has left your organisation and you do not know the e-mail address they were using, please see the open access JRS Technical Support General page, which shows the status, realm, compliance and service details together with tech user details.
How can we change our account settings/username on the JRS Support server? And how can we add a secondary technical contact?
Having logged in to the JRS Support server, click on 'my account' from the left hand menu. Click on the 'edit' tab and make the appropriate changes to your account settings or contact information as required. You can also add a secondary technical contact there.
RADIUS server configuration
In this section you will find specific information on Radiator, FreeRADIUS and MS Internet Authentication Service / Network Policy Server as well as information relevant to all RADIUS software.
Do you have links to the various RADIUS server platform websites?
Microsoft IAS (Internet Authentication Service) (Windows Server 2003) website
Microsoft Network Policy Server (NPS) (Windows Server 2008)website1 website2
Cisco ACS (Secure Access Control Server for Windows) website
Juniper Funk Steel-Belted Radius website
How many RADIUS client devices can my ORPS support?
Please note that this answer relates to RADIUS clients (eg NAS devices - such as wireless access points and switches) NOT actual users using the ORPS.
Windows Server 2003, Standard Edition or Enterprise Edition (for IAS and Certification Authority (CA) installation). Standard edition supports maximum of 50 wireless APs (RADIUS clients) per server.
FreeRADIUS - as many as your server can logically handle
RADIATOR - as many as your server can logically handle
CiscoACS - Number of Access Points. To determine the number of access points that a Cisco Secure ACS can manage, start with the assumption that each access point manages about ten WLAN users. Then divide the total number of users that can be supported by a Cisco Secure ACS - 21,000 by this number. With this formula we have 21,000 divided by 10 or 2,100 access points that can be supported by one Cisco Secure ACS. This is the minimum number of access points that can be supported because not all access points will be supporting the maximum number of users at any one time.
Number of Network Access Servers - a Cisco Secure ACS can support up 5,000 discrete network access servers (NASs). This number can be increased by the use of the multi-NAS capability of an ACS. Multi-NAS is a concept that allows one or more addresses to be configured for a given NAS entry. Using multi-NAS, the Cisco Secure ACS can support a theoretical maximum of 255 multiplied by 5,000 discrete NAS equaling 1.275 million devices. However, a configuration of 1.275 million devices per Cisco Secure ACS is clearly not realistic.
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 | July 2008 | April 2009 |
|
FreeRADIUS |
27 |
51 |
59 | 64 | 74 | 74 |
Microsoft IAS |
12 |
15 |
16 | 21 | 24 | 31 |
Radiator |
13 |
13 |
13 | 15 | 14 | 16 |
Cisco Secure ACS |
2 |
3 |
4 | 4 | 10 | 15 |
Cisco IOS |
0 |
1 |
1 | 1 | 1 | 0 |
Typo/not stated |
14 |
9 |
5 | 6 | 4 | 5 |
Funk/Juniper Steel-Belted |
- |
- |
- | - | - | - |
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.
Versions 1.1.3 - 1.1.7 are vulnerable to being crashed by an attacker sending a Tunnel-Password attribute in an Access-Request packet.
If you are sticking with 1.1.x code, 1.1.8 was the final version of the 1.1.x product.
However we see no reason not to upgrade to the 2.1.x version of FreeRADIUS. 2.1.7 is at the time of writing the latest release and fixes many 1.1.x issues.
Further details regarding security vlunerabilities of FreeRADIUS versions can be found here: http://freeradius.org/security.html
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.4 is the latest version, last modified 11 March 2009).
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.
A full history of Radiator software revisions can be found here: Radiator Revision History
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, OSC (the publisher of Radiator) has produced a number of example configuration file snippets and templates which can be found in the goodies directory on a Radiator server. Eg. ntlm_eap_multi.cfg 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).
Resources:
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 web site 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 JANET Roaming Technical Specification using FreeRADIUS in an AD environment: A Case Study in Complying with the JANET Roaming Service Technical Specification (pdf)
Resources:
Also appendix A.2 of the Geant2 Roaming Infrastructure Service and Support Cookbook provides Roaming Technology - FAQsuseful information on configuring the ORPS server software.
What's the Difference between MS IAS and NPS?
Here's what msdn says - Internet Authentication Service vs Network Policy Server
- Microsoft IAS website documentation
- Deployment of IEEE 802.1x for Wired Networks Using Microsoft Windows
- Deploying MS IAS with VLANs
- MS IAS Operations Guide
- Techrepublic article - Installing MS IAS
Troubleshooting Microsoft IAS as a RADIUS server and as a RADIUS proxy
This link to the MS TechNet site should be useful:
Microsoft TechNet IAS Troubleshooting
We have configured the relevant databases for our ACS servers and ports on the ASA firewalls, now we need some help in configuring ACS 4.0 for PEAP.
The following Cisco links give various bits of help regarding ACS and PEAP:
PEAP under Unified Wireless Networks with ACS 4.0 and Windows 2003
System Configuration: Authentication and Certificates
When initially setting this up it is a good idea to maximise the logging as follows.
How to Set the Logging Level to Full in the ACS GUI:
You will need to set ACS to log all messages. To do this, follow the steps listed below:
1. From the ACS home page, go to Systems Configuration > Service Control.
2. Under the Service Log File Configuration heading, set the level of detail to Full.
You can also use the command line tools to further debug - there's a whole suite of them.
ACS Internal Architecture - CSTacacs and CSRadius
CSRadius appears to be the most useful - for an example of it in action see:
Obtaining vs and AAA debug info for Cisco Secure ACS - RADIUS success authentication
I've set up Attribute filtering - what Attributes should I NOT filter out?
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 JANET Roaming Support.
For more information on this topic see:
Attribute Screening for Access Requests on Cisco Network Access Server
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.
What is the recommendation regarding shared secrets for ORPS - internal RADIUS servers? (We have multiple internal RADIUS servers at departments and colleges, should be use separate shared secrets for each pairing or would a common one be acceptable?)
It is best practice to use one shared secret for each ORPS-internal RADIUS server. This is to limit the effect of one RADIUS server being compromised or having the credentials leaked giving further access to the rest of the RADIUS infrastructure. In some cases it is not feasible to have seperate shared secrets, for example in a system where the RADIUS servers have a shared/synchronised database.
Top of page
Server Certificates for ORPS
Can I use a self-signed certificate for my RADIUS server?
Yes. The RADIUS server certificates required by certain EAP methods may be derived from a self-signed certificate authority (CA) / private certificate authority or they can be purchased from a commercial public CA.
EAP methods that use transport layer security (TLS), such as EAP-TLS, EAP-PEAP and EAP-TTLS, 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.
The advantages and drawbacks of both using private and public CAs are listed below.
Using a certificate from a self-signed private CA
Benefits:
- No need to purchase a certificate from a commercial vendor - saving cost.
- 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).
Drawback:
- you will generally have to install or get the laptop user to install the server ‘root certificate’ from your self-signed Certificate Authority on each client before it will recognise a private server certificate - but this is not a difficult procedure.
Using a certificate from a commercial CA
Benefit:
- No need to distribute the CA's root certificate to each client since public CA certificate will generally be recognised by any client, since such certs are distributed with operating systems.
- The correct extension attributes will be present (if requested or needed) - eliminating necessity of configuring openssl etc.
Drawback:
- Cost - you usually have to pay an annual fee for each certificate.
- Slight vulnerability to illegal spoofing
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:
TechRepublic paper - Self-sign a RADIUS server for secure PEAP or EAP-TTLS authentication
Microsoft technical article - Certificate requirements when Using EAP-TLS or PEAP with EAP-TLS
Private certificate authority software eg. CATool from Open System Consultants http://www.open.com.au/catool
Can I use the JANET Server Certificate Service to provide certificates for my RADIUS servers? / Do you have any technical documentation on using MS IAS and JANET SCS?
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 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. Choose a vendor that will supply a certificate 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 JANET SCS certificates should read the JANET guide - Using Certificates Issued by the JANET SCS with MS IAS (Word) pdf version 
]
3. Manage your own private CA.
How do I get and install a commercial server certificate for use with MS IAS?
MS IAS - obtaining and installing a VeriSign WLAN Server Certificate for EAP-PEAP (MSCHAPv2)
Top of page
Integration of RADIUS Server with Back-end User Database
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:
http://www.novell.com/documentation/edir_radius/index.html
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 Complying with the JANET Roaming Service Technical Specification (pdf)
Radiator integration with Active Directory
The first thing to note is that different handlers in the radius.cfg should be used dependent on the OS platform of your Radiator server. AD is also problematic as it will not permit access to plaintext password by the RADIUS server.
There are a large number of sample configuration files and templates in the 'goodies' directory on Radiator servers which should prove helpful. These can be modified to suit your environment with options configured such as domain name, IP addess, password etc.
Top of page
Dealing with a virus infection incident/Implementation of JRS Policy/RADIUS server log keeping and interpretation
Can you clarify the JANET Roaming Policy/Tech Spec on vistor logging?
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)
In cases of major abuse by visiting guest JRS eduroam users, who should we contact?
(By major abuse we mean those about which we receive a complaint from an outside organisation).
Fortunately such cases are few and far between, however if you receive a complaint from an outside organisation about a guest user on your network (eg. illegal copyright download notice), the user's Home organisation should be contacted immediately.
In the first instance you should try to contact the JRS technical administrator at the Home site AND also please copy in JANET Service Desk quoting 'eduroam' in the subject line. Contacts are listed on the JRS Support Server General Information page. If you have difficulties in tracking down the administrator at the Home site (eg. in cases of visitors from outside the UK where searching on the eduroam.org site has been unfruitful), please contact JANET Service Desk and we will pursue the matter with eduroam.
Say we receive notification from JANET CSIRT about suspected virus activity giving an IP address which turns out to be used by an eduroam visitor at our site, what do we do about it?
So CSIRT detects virus-related activity coming from your visited site and notifies you giving the IP address of the offender (who may be an eduroam user) and the date/time of the incident. You need to determine the MAC addess and probable home organisation of the offender using your detailed DHCP and RADIUS logs and you should then contact the home organisation to report the incident.
Obtaining MAC address and probable home organisation details:
Given the IP address CSIRT provides, your DHCP log should reveal the MAC address of the offender. The RADIUS log includes user-name, acct-session-id and calling-station-id attributes. Again, by using the IP address, the MAC address should be evident from the calling-station-id attribute and this should match the address revealed from the DHCP log.
You will be able to provide the probable realm name of the offender (from the user-name record, which can only be used to determine realm since the visited site RADIUS log only shows details of the outer ID/stage 1 authentication of an EAP authentication - which will be null@usersiterealmname.ac.uk or anonymous@usersiterealmname.ac.uk or realfred@usersiterealmname.ac.uk in case of WindowsXP and Vista supplicants. Only the inner ID/stage 2 authentication utilises the real user ID). Nb. we cannot be certain that the indicated realm name is a definitive pointer to the realm of the real user ID since due to erroneous set up of proxying by some sites, the inner ID may be proxied off to another organisation for final authentication (we run a scan once a month to expose such errors).
Action:
The probable home site should now be contacted for details about who that user was (using date and time stamp details from the visited site logs, the home site should be able to track down the user and deal with the incident). The JRS technical contacts/site JRS administrators are listed here: https://support.roaming.ja.net/?q=general
What should we do if we identify a virus infection on a visiting user’s laptop if they are still on our eduroam guest network - do we have the right to block their access (based for example on MAC address of the Calling-Station-ID) or do we report this to JRS Support (which will then escalate to the Home institution to deny authentication)?
If a visitor has a device with a proven virus infection or they breach yours or JANET’s AUP then you should indeed block their access to your guest network. As service provider, you are certainly have the right to block access. You should however have a mechanism by which they know that they have been blocked for that reason - eg some captive page or network walled garden that gives them that information.
The case must also be escalated to the Home institution AND JANET Roaming Support. Note that the visitor could be from a non-UK organisation so by notifying JRS Support the issue will be pursued with eduroam.
Also note that whilst blocking MAC address is a simple method of denying access it could be circumvented if the visiting host is intent on more malicious activity (likewise, blocking on outerid won’t be effective either).
JRS Support Test System and Testing
We want to peer an ORPS with the NRPS and carry out tests without it becoming part of the production infrastructure and being sent production traffic, can this be accomplished?
Yes - see ORPS-role-designation-features-JRS-Support-Server In fact in order to facilitate testing, we have configured NRPS realm handling such that only traffic with your realm name prefixed with 'test' will be sent to your test/development server (see document).
Are there any test systems available to verify our system works/help with problem investigation? Where would I find these tests and are there any instructions on their use?
Yes - see Test Facilities on JRS Support Server
Using the remote authentication test facility on JANET Roaming 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 JANET Roaming Test. Why is this and what's the solution?
The log error is due to the JANET Roaming 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 JANET Roaming test used to use anonymous@realm, however feedback from several organisations lead 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 command to the sql.conf which will remove this from logging etc. The inner ID should still be accounted and logged.
The simulated visitor test is failing but the remote authentication test works for our site (indicating that shared secrets are fine). Why is this?
Our logs show 'remote server did not process authentication request'; packet sniffing shows that the ORPS keeps repeating the request and the JRS test system repeats the challenge. Our firewall settings seem fine.
NRPS logs show 'incorrect login' authentication results, so the problem could be:
i) the wrong password is being used for the simulated visitor test; you must use the password you configured for the test user account on the JRS Support server (not eg. the password you use for login to your JRS Support account)
ii) one of the shared secrets configured on your ORPS is incorrect - remember these are employed in both client and proxy areas of the ORPS configuration and are utilised independently; an error could mean that remote authentications are successful whilst visitor authentications fail.
Remote authentication tests from the JRS Support web site fails but the simulated visitor test works. Why is this?
See above answer (ii)!
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 JANET Roaming Support server.
In your RADIUS logs you are seeing a single NRPS using the JANET Roaming 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 JANET Roaming 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.
Having just made changes to our config on the JRS Support web site, errors are being recorded in our logs every five minutes - why?
Any changes to the test username/password and realm made on the JRS Support web site are instantly put into the JRS database. The on-demand tests on your test page on the JRS web site are therefore instantly accessible.
There is however a background service availability monitor test powered by NAGIOS that is run from the JRS Support server via one of the NRPS (usually roaming1). This runs a test authentication using the test account you have created in your user database and configured on the JRS Support site. The NAGIOS probe configuration is however NOT updated/generated instantly and therefore there may a short period when test proble authentications fail and errors are logged on your ORPS. Once any config. changes have filtered through to the NAGIOS system, the test will run successfully and log error entires will cease.
Top of page
Upgrading FreeRADIUS from v 1.1.x to v2.0.x
Do you have any guidance for upgrading our system to FreeRADIUS v 2.0.x?
Whilst the upgrade to FreeRADIUS may at first seem daunting due to the change of structure and the new features, it is actually a very short task to migrate a live 1.1.x systems across to 2.0.x.
FreeRADIUS 2.0.x is a great improvement over 1.1.x and it is well worth making the effort to upgrade. 2.0.4 and upwards featured an 'inner-tunnel' method which means that eg EAP only hits your LDAP or SQL once...not the 3 or 4 times experienced previously. The current release is now 2.0.5
which has a lot of stats available via a simple query to the server and there will be new features going into 2.0.6 that will make it even more desirable, not least of which will be working SNMP and highly configurable logging capabilities.
Recommended approach to upgrading:
1) Examine the 1.x config to see what you have configured
2) Take the vanilla 2.0.x configuration and then edit it to add in the bits you did in 1.x this should be involve just the following:
a) edit sites-enabled/DEFAULT to match your authen/author/account fromt he old radiusd.conf
b) edit clients.conf and proxy.conf - exactly like 1.x initially
c) check out the other sites-available/* file to see what new functionality you want and then enable those modules (eg inner-tunnel) by copying or softlinking them like the DEFAULT file entry (rename DEFAULT to 'university_of_foo' or whatever if you want)
- if you want to enable inner-tunnel, then edit eap.conf to use the inner-tunnel virtual server (highly recommended!)
d) after some local rad_check stuff, use the JRS support server to ensure remote and home access is working.
We would then recommend setting up a proper proxy JRS pool using the unlang (contact us for more advice etc on this aspect..some of it is covered on the support site FAQ)
Firewall Configuration
Why do I get only "Re-sending Access-Request" when testing authentication?
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.
Why do we appear to not be getting any response from the JRS NRPSs when visitors try to authenticate? Authentication requests are being sent from our ORPS but we get no response from the NRPSs. We have also tried authenticating with our JANET Roaming test id ([our realm]@eduroam.ac.uk and [our_realm]@roaming.ja.net) and again get no response. This looks like a routing issue.
Troubleshooting - from the JRS Support site tests:
a) the ping test shows that routing from the NRPS to your ORPS works and your ORPS responds
b) remote authetication tests PAP and the relevant EAP test results in success so your essential authentication system is correctly set up
c) since the problem is with outgoing authentication, this points towards a firewall configuration problem.
Problem resolution - whilst the firewall had been configured to allow incoming UDP 1812/13 from the NRPS to the ORPS and subsequent responses (ie outside authenication worked), there was no permission set to allow outgoing UDP to the NRPSs originating from the ORPS.
Top of page
Shibboleth
What's the difference between JANET Roaming and Shibboleth?
Shibboleth and JANET Roaming are complementary technologies that provide solutions to two different objectives.
The JANET Roaming/eduroam infrastructure provides the network access technology to make it easier for users with valid accounts at JANET connected organisations to log on to networks (both at home and) when visiting participating organisation sites. Before authentication, a user will typically have no access to the network or Internet. Once logged in using the JANET Roaming infrastructure, a user will have access to the network and the Internet.
After having logged on to the network Shibboleth then facilitates admission to online resources that are subject to access control. The Shibboleth architecture defines a streamlined way of exchanging information between an individual and providers of digital data resources to authorise the user's access to the resources. It has been designed to protect both the security of access to the data and the privacy of the individual viewing it (since authentication and authorisation is controlled by the home organisation).
Therefore, once a user has logged in using the JANET Roaming infrastructure and gained access to the Internet, Shibboleth could then be used to provide authentication and authorisation to access controlled online resources, such as journals and media content. http://www.ja.net/development/middleware/uk-federation.html
There has been a JISC-funded project, LICHEN, aimed at extending the usage of JANET Roaming in the Shibbolith arena. The main goal of LICHEN was to demonstrate that the JANET Roaming architecture can be extended to embrace supporting access control and authentication for virtual organisations of collaborating users on a variety of applications that may themselves authenticate through RADIUS. The secondary aim was to investigate methods to have such authentication interoperate with Shibboleth.
Currently there is work being done at a European level to further explore the possibilities. See: Geant2 unified Single Sign-On (uSSO)
Top of page
Wired Networks
How do you configure a Cisco Catalyst switch to operate with 802.1x?
Information on Cisco configuration can be found within the technical paper:
Configuring 802.1X Port-Based Authentication
Top of page
Wireless Networks
How do you configure a Cisco 1200 Series Wireless Access Point for eduroam SSID?
Details of the precise (largely web-based) steps used to configure the eduroam SSID on a Cisco® 1200 series WAP can be found in Appendix 2 of the case study -
Complying with the JANET Roaming Service Technical Specification (pdf)
Is it imperative that an institution broadcasts the eduroam SSID, as opposed to having it hidden? And would failure to broadcast eduroam exclude an institution from joining JANET Roaming?
Yes to both questions. Broadcasting the eduroam SSID is required by eduroam confederation policy and is a JANET Roaming technical requirement. This is because firstly, it's a way of advertising the presence of the service. Secondly, the native WinXP SP2 supplicant cannot do 802.1x against a hidden SSID (see below).
Can Cisco fat WAPs be used with multiple broadcast SSIDs and dynamic VLANs?
There is a known problem with Cisco 'fat' WAPs with regard to multiple BSSIDs and dynamic VLAN assignment (RADIUS-assigned VLANs) which unfortunately affects a lot of institutions. The problem was that Cisco 'fat' IOS driven APs until recently only supported a single primary (guest) SSID broadcast in the beacons (the BSSID). Furthermore, it was not possible to achieve assignment of VLANs via RADIUS. This limitation does not apply to Cisco's 'thin' architecture, so the problem could hitherto only be circumvented by adopting this technology.
This issue only affected the autonomous Cisco APs. There never was any difficulty with lightweight APs (including upgraded autonomous ones) in supporting RADIUS-assigned VLANs and multiple broadcast SSIDs. (Certainly 1131 and 1232 APs in non-autonomous LWAPP thin client mode with WiSM controllers have always worked fine).
With release 12.3.8-JEC(GD) of the Cisco IOS firmware, this issue has been resolved - certainly multiple BSSIDs with RADIUS assigned VLANs have been successfully setup with AP1231 and other 1200 series access points.
Although the issue has been resolved in the IOS, you may find that some AP radios do not support multiple BSSIDs. To find out if a particular radio will support multiple BSSIDs:
Run a 'show controllers' radio_interface command to check how many BSSIDs an AP will support.
Look for the line which states - "Number of supported simultaneous BSSID on Dot11Radio0: 8"
or something similar.
To setup multiple BSSIDs on the AP you can log into the web interface and select Security > SSID Manager.
The page displayed will show the current VLANs configured and indicate which are being broadcast.
Alternatively from the IOS command line, enter SSID configuration interface and use the command mbssid. You'll also have to use mbssid from the
configuration terminal interface
to enable
multiple basic SSIDs on an access point radio interface. This command was introduced in IOS release 12.3(4)JA.
[NB. The validity of following advice with regard to latest release of IOS is unknown - it certainly applied to pre-12.3.8 releases]. The Cisco WAP beacon can by default advertise only one broadcast SSID, nevertheless it is possible to alert client devices of additional SSIDs although this did not remove the limitation that RADIUS-assignment of VLAN was not possible. You can achieve client alerting of multiple SSIDs as follows; use the SSID list information elements (SSIDL IEs) in the access point beacon to alert client devices of additional SSIDs on the access point. When you designate an SSID to be included in an SSIDL IE, client devices detect that the SSID is available, and they also detect the security settings required to associate using that SSID.
See: Cisco AP Configuration Guide - Configuring Multiple SSIDs.
The AP configuration needs to use the command: information-element ssidl [advertisement] [wps] (Microsoft Wireless Provisioning Services) in the radio interface configuration / specific SSID configuration section.
For WinXP users the following download must be installed. This update enhances Windows XP support for Wi-Fi Protected Access 2 (WPA2) options in Wireless Group Policy (WGP), and helps prevent the Windows wireless client from advertising the wireless networks in its preferred networks list.
WinXP Update:
http://support.microsoft.com/kb/917021
Using this update, the 'hidden' SSIDs become visible in a Cisco 'fat' AP environment - the subsequent SSIDs use the extension made available through 802.11i.
Can you expand on what is necessary to convert 'fat' Cisco WAPs into 'thin' ones? (Is it just an IOS upgrade and does it cost anything? What device(s) do you use to control them? Do you lose any functionality in converting to thin?)
Changing to thin is a straighforward job. Either use the IOS command line (archive download-sw tftp://.........), the windows-based upgrade tool or a WLSE (Wireless LAN Solution Engine). The upgrade tool and software image can be downloaded free from Cisco, and the tool pushes the image to the APs you tell it to, which converts them to lightweight. They then get their configuration from the controller rather than it being stored locally.
To control these thin APs you need a central controller, which incurs a cost. Lightweight wireless means all the clever stuff (authentication, key management, channel and power management) is done by a central box. This could be the Wireless Services Module (WiSM) for the Cisco Catalyst 6500 switch (controls upto 300 APs), the standalone Wireless Control System (WCS) or the Catalyst 3750G Integrated Wireless LAN Controller (can only control about 32 APs). There's a fair amount of configuration to do so the controller knows about your VLANs, SSIDs, RADIUS servers etc.
You gain a great deal of functionality and management facilities - such as reporting, accounting, configuring WLANs, mobility etc. You manage the APs bia a web interface on either the controller or a PC running Cisco's WCS software, which co-ordinates multiple controllers and does RF planning etc. Adding a new access point is a straightfoward task of connecting it to a switch and then using the software to put the switch port in the right VLAN.
Summary:
- WAPs must have IOS 12.3(7)JA or higher
- Thin IOS must then be loaded via WinXP program (available on Cisco web) or via CLI
- The WAPs must be 1240AG/1130AG/1200 series [1210,1220,1230,1235]
- (1200 series radios must be one of following models only: MP21G/MP31G/RM21A/RM22A)
- Wireless controller module (WiSM) of some description necessary [WiSM for Catalyst 6500 (will need a free slot), WCS or Catalyst 3750G IWLC]
- Catalyst 6500 requirements: free slot for WiSM, Supervisor Engine 720 WS-SUP720 needed and to run a SUP720 you need the higher rated PSU
- For large deployments of three or more WiSM, a WCS is recommended
There is a guide to the process on the Cisco web site: Upgrading Autonomous Cisco Aironet Access Points to Lightweight Mode
To get the upgrade tool and Cisco IOS release:
- Browse to the wireless downloads page:http://tools.cisco.com/support/downloads/pub/MDFTree.x?butype=wireless
- Click Access Points.
- Click the type of access point that you want to upgrade. When you click the access point type, the access point folder expands.
- Click the access point that you want to upgrade in the expanded list. The Select a Software Type list appears.
- For the upgrade tool, click the Autonomous to Lightweight Mode Upgrade Tool link.
- For the software image, click the Autonomous to Lightweight Mode Upgrade Image link.
Will a client configured for WPA2 fallback to WPA in a WPA-only environment?
Will an AP configured for WPA2 fallback to WPA if a WPA-only client tries to associate?
The native Windows XP supplicant software requires the user to make an explicit choice between WPA and WPA2 when performing the configuration. If a user with a device configured for WPA2 visits a site where the guest WLAN has been configured to utilise WPA, will they be denied service, or does the client fall back to WPA? Similarly if the guest WLAN has been configured for WPA2 and a visitor arrives with a device configured for WPA will the APs fall back to support WAP or will the user experience problems?
It will probably be the case that a client set up to use WPA2 will not work at a WPA location - this depends on the supplicant and the configuration. Generally a client needs to have the correct specific cipher methods configured. Likewise a client configured to use WPA will not work in a WPA2-only location.
Some clients can handle both WPA and WPA2 versions of the same SSID... and some clients (eg Vista) can even have different profiles pointing to the same SSID. See Workstation/Laptop Setup above.
However, since the vast majority of clients only support WPA at present, we advise that JRS3 WPA2 sites should still provide WPA connectivity and JRS2 sites must provide WPA (and they may also provide WPA2). This advice will stand until we see a wholesale migration to WPA2 (which is expected in a few years time).
Our Cisco 1200 autonomous-mode APs have been configured using the 'cipher' option of 'AES CCMP + TKIP'. Does this mean that our WLAN is effectively supporting both?
Yes, it should support both - you can determine this by using a wireless card or probe that tells you what ciphers it can detect, eg. the 'airport' utility in MacOSX.
We recommend that the cipher mix is kept to the standards - eg WPA/TKIP and WPA2/AES.- Whilst WPA/AES exists it is very exotic and WPA2/TKIP is just wrong.
Another reason to implement WPA2/AES (alongside WPA/TKIP) is that only with AES can true 802.11n speeds be obtained (apart from in a wide open wi-fi scenario) - so anyone looking at 802.11n kit needs to keep this in mind.
Top of page
Useful links:
Wireless assistance\\Tech Guide: Wi-Fi: Security For The Masses
802.1X Port Access Control for WLANs
Deploying 802.1X for WLANs: EAP Types
Wireless on Linux, Part 1 and Part 2
Open1x.org - Selecting An Appropriate EAP Method For Your Wireless LAN Evolution of WLAN Security
Promoting eduroam at your organisation
Can the JANET Roaming and eduroam graphics be included in our own JRS web page and JRS eduroam promotional / advertising material? Can the images be downloaded?
Yes. See Promotional Material for JRS Participating Organisations.
Any problems, comments or suggestions regarding this page,
please e-mail the JANET Roaming service manager.