Implementing eduroam Roadmap - Part 3

Download as PDFDownload as PDF

On this page sections 16 - 22:

  1. RADIUS server log keeping and interpretation of logs
  2. Monitoring your own service
  3. Workstation/Laptop Setup/MS Vista issue
  4. Q.A. test of your eduroam implementation
  5. Promote eduroam at your organisation - your eduroam web site
  6. Keep your configuration details data on the eduroam Support server up to date
  7. Planning Ahead and Developing your eduroam Implementation

See Part 1 for sections 1 - 9:

  1. Concepts and terminology
  2. Deciding your service type and planning your eduroam implementation
  3. Choose RADIUS server platform and plan network connectivity for ORPS
  4. Joining eduroam(UK) and selecting your realm
  5. The eduroam Support Server website; input organisation/site details, realm name, test account
  6. Install your RADIUS Server (ORPS)
  7. Acquire server certificate for ORPS/NAS
  8. Add your ORPS to the eduroam(UK) RADIUS Infrastructure via support website and acquire your shared secrets
  9. Firewall configuration to permit RADIUS servers to work with NRPS

See Part 2 for sections 10 - 15:

  1. RADIUS server proxying configuration and attributes filtering
  2. Wi-Fi service and establishment of a VLAN/network service for eduroam
  3. Firewall configuration to support eduroam network service
  4. RADIUS server software configuration and interoperation with user database
  5. DNS Name Server Configuration
  6. Test facilities on eduroam Support Server / Visitor Test / Testing a new ORPS

Part 3

16. RADIUS server log keeping and interpretation of logs

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

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

Clarification of Policy and Tech Spec Wording - Visitor Activity Logging

Hint for FreeRADIUS ORPS: the default main logfile (radiusd.log), which is configured in the main radiusd.conf file and which logs OK messages etc., is rather basic.

It is recommended to use linelog module for logging - this will enable you to log any of the attributes present in packets. And if you also call linelog in the inner-tunnel authentication phase, attributes relevant to local authentication of your own users can be logged such as EAP type. Rather than fill up your ORPS with log files you can also push logging off to a remote syslog server. And FR 3 includes more funky NOSQL/Logstash stuff.

FAQs:

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

See - community.ja.net/library/janet-services-documentation/clarification-eduroamuk-policy-and-tech-spec-wording-visitor Clarification of Policy and Tech Spec Wording - Visitor Activity Logging

Using the Test facility on eduroam 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 eduroam Test. Why is this and what's the solution?

The log error is due to the eduroam 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 eduroam test used to use anonymous@realm, however feedback from several organisations led us to adopt the correct RFC format.

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

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

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

In your RADIUS logs you are seeing a single NRPS using the eduroam 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 eduroam 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 eduroam 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.

17. Monitoring your own service

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

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

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

18. Setting up User's Devices/'Onboarding'

One of the hurdles to be overcome in a successful 802.1X institutional deployment is getting the devices of your users setup to work with eduroam. You may have chosen to utilise a third party 802.1X supplicant or to reply on the built in OS supplicant or you may want to support both and/or a variety of EAP methods. Whichever policy you adopt, you are faced with three challenges:

1. Not all devices, operating systems and supplicants are equal with regard to their 802.1X capability

2. Getting requisite third party supplicants and certificates to devices and installed

3. Getting devices properly set up and optimised, including possibly removing legacy configurations and setup SSIDs

Devices and operating system supplicants that are compatible with eduroam

See the geant wiki table: Devices that are compatible with eduroam  To a large extent we are at the mercy of product developers to properly implement 802.1X supplicants for thier products and OSs.

Distribution of third party supplicant software and certificates (where applicable)

Once you have decided on the supplicant of choice and the necessary EAP settings there remain potentially two major operations:

  • Distribution of third party supplicant software - if you have decided not to rely on built in operating system supplicant. (With the introduction of Windows 7 the imperative to use a more satisfactory supplicant than the built in Microsoft Windows software has been reduced - unless your system cannot support PEAP/MSCHAPv2. In this case you will still require your users to use a third party supplicant that does support your chosen EAP method.)

Getting the user's device Properly set up - auto-configuration tools

  • Configuration of this supplicant software - a large proportion of users are either relucatant / not up to the job of correct configuration of the software. Expecting users to correctly configure supplicants, whether native or third party, is being somewhat optimistic. It is essential that the setup should include configuration of the client for checking of the ORPS certificate! (Without this check, users are susceptible to credentials harvesting attacks.) Automating this process serves to help both the end user and IT Services, since the burden of fixing misconfigured machines can be eliminated.

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

FAQs:

How do I configure Windows to work with 802.1X?

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

Why is it important for the supplicant to be set to check RADIUS server certificate?

For answers to this and to understand server certificate validataion see Kevin Koster's presentation at NWS38 Nb. The Janet Certificate Service CA chain is now USER Trust - UTN-USERFirst-Hardware - TERENA SSL CA.

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

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

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

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

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

19. Q.A. Test of your eduroam implementation

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

Your network should not broadcast the eduroam SSID until you have an operational service, ie you can tick off compliance to the requirement of the Technical Specification and the following tests can be passed. You can then say with configence that you have a working service.

eduroam(UK) Technical Specification Summary of Requirements Checklist - tick box list to enable you to verify compliance of your service

eduroam(UK) Tech Spec Summary of Recommendations Checklist - tick box to help you assess your implementaton of recommendations

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

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

  • ICMP Check                                          - PING OK

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

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

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

  • Visitor Authentication Simulation Test                            - success

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

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

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

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

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

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

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

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

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

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

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

  • eduroam information page on organisation web site        - yes

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

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

20. Promoting eduroam at your organisation

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

  1. A dedicated 'eduroam service information' page or eduroam section on the Wi-Fi service page on your organisation's web site. This must provide eduroam users with the key information to enable them to use the eduroam service at your site. This is mandatory requirement of the Tech Specification. A content guide is available.
  2. Advertising the locations at which eduroam is available and raising general awareness of eduroam in your organisation.
  3. Providing information to freshers and training if necessary to your own users about the service.

eduroam service information web page

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

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

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

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

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

There is further guidance in the content guide.

Advertising the locations at which eduroam is available and raising general awareness of eduroam

There is a range of ready-made material published on the eduroam.org web site which you may find useful. This includes a poster, leaflet, information card (business card size),  beer mat, sticker, banner. All you need to do is enter the country, NREN and your organisation-specific details in the pdf fields and print on a suitable medium. If you need the Janet logo, please apply for this via Janet service desk.

See: https://www.eduroam.org/index.php?p=media

Providing information and training if necessary to your own users on the service

We would suggest that information on how to get started with campus network services includes information about eduroam. You might want to provide an open access captive portal network service for first time users that simply provides information about eduroam, links to your preferred eduroam setup tools and guidance on how to get IT support.

21. Keeping your configuration, ORPS, sites location and contact details data on the eduroam Support website up to date

The information you enter on the eduroam(UK) Support site is the source used to populate the www.eduroam.org UK service availability map and the European eduroam database and worldwide map for the benefit of eduroam users. It is therefore important that you keep your organisation's eduroam configuration and eduroam network details up to date.

It is also beneficial to you to regularly check the main config page for your organisation, since issues with the data you supply through the Support portal and your organisation's eduroam service/compliance to tech spec that we detect will be highlighted in the "Detected issues" and "Problem logs" areas on that page. (You should also check the Nagios LG page periodically too). Reminder of how to update details on organisation config page.

The most important data entry is done on your main eduroam UK Configuration page, but it is also important to keep the RADIUS proxy servers page and individual sites network information current. After making any changes please hit the relevant [Update] button (located towards the bottom of the pages) for the changes to take effect.

The data requested is detailed below.

eduroam UK configuration page:

  • your service type as defined in the Tech Spec
  • assertion of the the status of the service you provide
  • organisation trading name and legal name details
  • test account details
  • EAP method to be used in the roaming user monitor test
  • requirement in respect of inclusion of troublesome attributes for visitor simlutation test responses
  • URL of your eduroam service information web page
  • FQDN of your syslog server if you operate one
  • requirement in respect of permitting security audits of your RADIUS server by eduroam(UK)/eduroam.OT
  • Primary user for receipt of advisories and notices from eduroam(UK)

RADIUS proxy server page:

  • RADIUS proxy server FQDN
  • authentication port
  • accounting port
  • priority of ORPS in NRPS servers list (enabling preferred ORPS to be identified)
  • function of ORPS - authentication (for Home and Visited) or client (for Visited-only service)
  • requirement in respect of Status-Server utilisation
  • marking of ORPS as production or test/development server
  • operating system
  • version
  • RADIUS software
  • version

Realms page:

  • realms

Site Locations page:

  • description of location, address, post code and preferrably co-ordinates (*) [particularly if multiple sites at one postcode]
  • Number of wireless APs at location
  • Wi-Fi ciphers supported (legacy option, since WPA2/AES is the mandatory and only permitted cipher)
  • whether wired Ethernet eduroam access is available
  • number of eduroam-enabled 802.1X sockets (you will only be able to see the wired socket request if you state you provide sockets)
  • is the eduroam visitor network NATed
  • does the network traffic on your eduroam visitor network pass through any (transparent) proxy
  • are any IP port restrictions (inbound/outbound) applied to the network connection
  • is IPv6 supported on your eduroam visitor networkork
  • optional details for support contacts at the particular location

(*) Use of co-ordinates allows you to get your site much more accurately positioned on the eduroam sites location map and on eduroam Companion. It is therefore recommended that if possible you use co-ordinates (easily determined from web tools such as Streetmap). If you have multiple sites at one post code, to enable the eduroam map to render the locations and for the info you are providing to be of any use in Companion, you must use co-ordinates.

If you have a large list of sites which will result in maintaining up to date information becoming an unmanagable administrative burden using the Support portal, you can ask us to update your sites information by sending us a csv file. If you wish to do this, please contact Service Desk to request the required format of the data.

Nb. Only sites stating 'working towards Visited' or 'achieved Visited' compliance will be able to see the fields for the eduroam visitor network (since these are not relevant to Home only organisations). Whilst both 'compliant' and 'no service' organisations can enter values, only organisations asserting that they provide a 'Compliant service' (ie are operational) will have their numbers passed through to eduroam and the eduroam web site.

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

'Primary user' and additional tech contacts for your organisation can be updated through the Support server. You can add additional contacts, which you may wish to do if your role with the organisation is changing or you are moving on. How to do this is described in Responsibilities of the eduroam System Administrator.  Please let us know through service@ja.net if the sys admin for your organisation changes - we can arrange a fresh joiner's induction call for the new person.

22. Planning ahead and developing your eduroam implementation

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