...
- Microsoft products:http://windows.microsoft.com/en-us/windows/lifecycle
- Apple products: https://support.apple.com/en-gb/HT201624
- ChromeOS products: https://support.google.com/chrome/a/answer/6220366
- Android products: there is no clear support strategy that could be linked against. Status as of Oct 2021 is that apparently Android 8.1 AOSP is the oldest that still receives security updates.
Scope
eduroam CAT is not replacing your helpdesk! While we hope to do you a good service by taking the technical task of generating secure installers for many platforms into our hands, we can not take your users' phone calls or tell them how to fix problems on their computers. The CAT's installers work on the target platforms if these have not been modified beyond reason by the end-user, and we hope the installation process with them is intuitive enough; but we can not give you guarantees that you will not ever hear from failing users again.
...
Step 2: How to log into eduroam CAT?
When clicking on the Administration interface linkUnder the Manage Tab, go into eduroam admin access, you will be automatically sent to the eduroam Support Services' federated login service. This login service does not work with site-specific usernames and passwords; , instead you are presented with a list of sources of identity. Choose any organization that you have an account with:
* eduGAIN: many universities across Europe have already joined the educational Global Authorisation INfrastructure - if your organization is among them, click on that institution and authenticate with your home organization's usual web login credentials
* Experimental: some institutions are in the process of joining eduGAIN, but are not production-level members; if that is the case for your institution, you might find your institution's authentication service in this Experimental list
* Social Networks: if you cannot log in with your institution's credentials (for example, because your institution is not participating in eduGAIN), you can also log in using the federated login function of several popular social networks, including, but not limited to, Google and Facebook.
Some users have noted that none of the above options suits them: e.g. their institution is not participating in eduGAIN, and they have an aversion against using social networks. We understand that if a user finds all the numerous authentication options unacceptable, then he will have a hard time logging in. However, at this moment we do not have a good solution to that problem. It might be worth considering creating a social network account just for the purpose of logging in here; even if the service portfolio offered by e.g. Google is not interesting for the user, their authentication service in itself is useful on its own.
Configuring my institution's properties
Overview
.
- Attributes needed for an R&E federated sign in to eduroam CAT may be one of the following:
- eduPersonTargetedID, Subject-id, Pairwise-id.
- All three are accepted, with no one attribute preferred over another at this time.
- The attributes are checked for presence (and used when a value is found) in this order: eduPersonTargetedID, pairwise-id, subject-id.
- For guidance on enabling these attribute(s) released or transitioning from one unique identifier to another should consult with your National Roaming Operator and/or IdP software provider.
* Experimental: some institutions are in the process of joining eduGAIN, but are not production-level members; if that is the case for your institution, you might find your institution's authentication service in this Experimental list
* Social Networks: if you cannot log in with your institution's credentials (for example, because your institution is not participating in eduGAIN), you can also log in using the federated login function of several popular social networks, including, but not limited to, Google and Facebook.
Some users have noted that none of the above options suits them: e.g. their institution is not participating in eduGAIN, and they have an aversion against using social networks. We understand that if a user finds all the numerous authentication options unacceptable, then he will have a hard time logging in. However, at this moment we do not have a good solution to that problem. It might be worth considering creating a social network account just for the purpose of logging in here; even if the service portfolio offered by e.g. Google is not interesting for the user, their authentication service in itself is useful on its own.
Configuring my institution's properties
Overview
There are basically four groups of information which we need to ask of There are basically four groups of information which we need to ask of you before we can create good-looking installers for you:
* general information about your institution (e.g. logo, approximate location, name)
...
You can upload multiple root CA certificates simultaneously to CAT. On all supported client OSes, all of them will be installed and all will be marked trusted. This enables CA vertificate rollow This enables CA certificate rollover without a flag day: User devices which were configured with an upcoming new root CA ahead of time will then not even notice the change of server cert from old to new trust root (so long as the Common Name of the server certificate remains unchanged during the rollover).
Almost all CAT-support client operating systems support mutliple trust roots. There is only one fraction of CAT-supported client OSes which does not support multiple root CAs: Android versions < 7.1. For those, due to an API limitation we are not able to do anything about, only one root CA will be installed; the API also cannot install any intermediate CAs at all. To On the client OSes, all root CAs will be installed and all will be marked trusted. The eduroam CAT Android App, however, will only install one certificate and can thus not be used to support CA rollover. Please use the geteduroam App instead. Or you can isolate Android users while giving everyone else multiple trust roots early, in this case you could can create a different profile (see next section) just for Android and only load the desired root CA into that profile). Android 7.1 finally got its support for multiple trust roots; the eduroamCAT app will support that in a future update.
Given the update situation on the Android platform, it is naive to think that the unsupported root CA rollover problem will wither out in anything less than five years. There is unfortunately nothing we can do about it.
Overriding IdP-wide Settings
.
Overriding IdP-wide Settings
After After these steps, you can enter/override helpdesk and media properties if you haven't done so on the institution-wide settings already (see above). If you have entered one specific option institution-wide already, and you enter something else here, then the settings on profile level supersede the institution-level ones.
...
That's all - the CAT then proceeds to a sanity check of the things you have configured and will tell you about any things which need fixing, it any. You are then transported to the Institution dashboard - from where you can continue to download your installers, change institution or profile details, perform sanity checks and morecontinue to download your installers, change institution or profile details, perform sanity checks and more.
Optional: OpenRoaming support
OpenRoaming is a Wi-Fi roaming consortium independent from eduroam, but using similar underlying technologies. You can find more details about this consortium and eduroam's interaction, and information for eduroam end users.
eduroam has created infrastructure that allows eduroam IdPs to enable their end-users for joining OpenRoaming hotspots. This
- has to be enabled by your NRO for your country or region
- is entirely optional for you as an IdP
- requires actual work in your own domain's DNS setup to function correctly
- is currently in its early days and functionality varies between EAP types and operating systems
General information and details about the technical setup can be found at Roaming on Passpoint-based network infrastructure (incl. OpenRoaming) (notably the "eduroam IdP" section there). Only the CAT-specific steps are described below:
Enabling OpenRoaming with CAT 2.1+
Starting with version 2.1, the eduroam onboarding toolset (eduroam CAT and eduroam Managed IdP) integrates Passpoint network definitions in general, and OpenRoaming settings in particular, in its standard workflow. You can enable OpenRoaming by setting the option of that name in the "Media Properties" section:
If you do not see this option, then your National Roaming Operator (NRO) did not enable the functionality in their country or region yet. Please speak to your NRO in that case.
This option can have one out of four states. This is due to two choices you have to make about OpenRoaming inclusion into installers:
1) Do you want to give every end user the choice to decide whether they want to join OpenRoaming networks?
2) Do you inform your end users about the OpenRoaming Terms and Conditions yourself out-of-band, or should this be done by CAT?
Unsurprisingly, this maps to the four choices and end-user download interface:
Option Value | Meaning | End-User download interface |
---|---|---|
Ask User | User is asked to make a choice; OpenRoaming Terms and Conditions have to be acknowledged during the download process | two buttons and a "Accept T&C" checkbox |
Ask User; T&C Pre-Agreed | User is asked to make a choice; no need to acknowledge OpenRoaming Terms and Conditions explicitly because this has been done by the IdP | two buttons ("eduroam" and "eduroam and OpenRoaming") |
Always | All users always gets an eduroam + OpenRoaming installer, but have to acknowledge the OpenRoaming Terms and Conditions during the download process | one button and a "Accept T&C" checkbox |
Always; T&C Pre-Agreed | All users always get an eduroam + OpenRoaming installer, no need to acknowledge OpenRoaming Terms and Conditions because this has been done by the IdP | one button ("eduroam and OpenRoaming") |
(not set) | no OpenRoaming, just eduroam | one button ("eduroam") |
DNS setup verification
After enabling OpenRoaming, CAT will execute checks that verify whether your RADIUS realm is correctly configured in DNS. You see the results of this check in the Submission Summary page in your enabled profiles. Please attend to all warnings and errors thoroughly to make sure OpenRoaming will actually work for your users in the field.
These checks can be repeated any time using the "Check Realm Reachability" button (see "Verifying my RADIUS Setup" below). The check page has a new tab for the OpenRoaming checks:
Unfortunately, currently IPv6 connectivity tests are not implemented, so you will receive a warning about those. This will be fixed soon (2.1.1 or a hotfix release).
Technical ability to support OpenRoaming in installers
Support is currently limited to the following operating systems:
OS family | Notes |
---|---|
Windows 10+ | Depends on chipset and driver capabilities. If not supported, OpenRoaming will be silently ignored during installation. |
Apple | CAT native installer (mobileconfig): only works for PEAP and EAP-TLS. The password prompt for OpenRoaming during install is "ugly": geteduroam installer, TTLS support is possible (see extra explanation about geteduroam limits below) |
Android 8+ | OpenRoaming availability depends on vendor build and chipset support. |
Android 11+ | supported |
Note on geteduroam and user choice: the in-app workflow only installs OpenRoaming if one the "Always" variants has been selected. If "Ask user" has been selected, geteduroam in-app workflow will only install eduroam, not OpenRoaming. "Ask user" will soon work (2.1.1 or as a hotifx) by downloading the Android installer from the end-user download interface of CAT and an "Open with ... geteduroam" (known as 'side-loading' in geteduroam).
Generating installers for my users
...
CAT 1.1 Windows installers can be run silently with the /S flag, which is useful for institutions which want to build the installers into their own, larger ones.
Replacing the RADIUS server root CA certificate
When your RADIUS server's root CA certificate is about to expire and you need to replace it with a new one, the new server CA certificate needs to be communicated to all your users' devices. The procedure to achieve this is as follows:
...
1. Create a new “migration” eduroam profile in eduroam CAT, containing both the current and new root CA certificates. All previous eduroam CAT profiles should be deleted to avoid them being used. (Caveat: this new profile will not work as intended for Android < 7.1 devices).
2. Require all new and existing end-users to download the “migration” profile. Their devices, except for Android < 7.1, will then be capable of trusting both the current and the new CA, and will accept server certificates from either CA.
3. Once you are confident that all end-user devices have the “migration” profile installed, apply the new server certificate on the Radius server(s). Ideally, the host name in the certificate CN/subjectAltNames should be identical to the old server certificate. (Caveat: Android < 7.1 devices configured with the old root CA will now no longer be able to authenticate, they will need to install a new profile containing just the new root CA).
4. Create a new “permanent” eduroam profile in eduroam CAT, containing only the new root CA certificate. Delete the “migration” eduroam profile.
5. Require all existing Android < 7.1 users, and all new users, to download the new profile.
...