...
- additional SSID for WPA2/AES:
If you deploy other SSIDs for which eduroam credentials are valid, you can add these here and they will be configured alongside the eduroam SSID. - additional SSID for WPA2/AES and WPA/TKIP
If you deploy other SSIDs for which eduroam credentials are valid, you can add these here and they will be configured alongside the eduroam SSID. This SSID will be installed for both WPA2/AES and (legacy) WPA/TKIP. - additional own Hotspot 2.0 / Passpoint Consortium OI
If you want to enable Passpoint and have a Consortium Organization Identifier, you can enter it here. The consortium OI for eduroam is 001BC50460. We do not currently enable this consortium OI by default.
On end-user device side, settings made regarding Passpoint will currently only benefit the most recent Apple devices (iOS 7+ and recent-enough hardware; recent Mac OS X). - whether or not to configure wired ethernet for IEEE 802.1X
Some eduroam participants also use IEEE 802.1X for wired ethernet ports in their premises, e.g. in dormitories. Administrators can specify that the installers should include wired ethernet eduroam configuration on the client devices. This is currently supported for the Windows installers and Apple OS X. Windows installers will provoke a UAC prompt when wired support is turned on. - disable captive portal SSIDs after setting up eduroam
Many eduroam participants deploy several SSIDs; typically, a captive portal SSID for help and/or download of configuration profiles/configuration instructions (a "bootstrap" or "onboarding" network), and the real eduroam network. If your users have connected to the bootstrap network before, their devices usually remember it, and may unfortunately prefer that network over the then-configured eduroam network. To prevent this, you can configure the name of your bootstrap SSID, and then during the installation process, CAT will either remove it from the client device, or at least mark it as "do not join automatically".
...
Profiles
In Profiles are the EAP Details section, you can upload common properties of your RADIUS installation's EAP configuration. If you specify something here, the settings will be used for all the user profiles you define (see below), unless you choose to override them in one of the profiles.
For most EAP methods, the required EAP details are
- The Certification Authority (CA) certificate(s) which signed your EAP server certificate
- always include the root CA (root CAs are indicated with a blue circled "R" besides the certificate details after upload)
- optionally include intermediate CAs (intermediate or server certificates are indicated with a blue circled ("I") besides the certficate after upload)
- The name of your server as specified in the Common Name (CN) of your EAP server certificate
Note 1 - server certificates
There is no point in uploading the server certificate itself. The server certificate is sent during the EAP exchange during login time to the client. Contrary to that, the CA certificates are needed because they are the trust anchor on the client device which it uses to verify that incoming server certificate.
Note 2 - CA requirements
Various client device operating systems have specific requirements about which CA certificates and server certificates they accept. For more information, please see EAP Server Certificate considerations.
Note 3 - CA rollover support
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 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 isolate Android users while giving everyone else multiple trust roots early, you could 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 already supports that
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.
Profiles
Profiles are the specific EAP configurations for your user group(s), and installers are always generated for specific profiles. If you only have one user group, the distinction between institution-wide and profile-wide settings does not make a difference. However, many IdPs have different user groups which share some properties, but not all. One example is where on the one hand students have username/password accounts, authenticating with PEAP and generic helpdesk contact points, and on the other hand permanent staff have TLS Client certificates with EAP-TLS and access to a better second-level helpdesk just for them.
eduroam CAT makes it easy to manage multiple user group profiles for one institution. Shared properties for e.g. server certificates and helpdesk contacts can be defined institution-wide (which makes them immediately available in all profiles) or per-profile (the property then is only defined for this specific profile). You can also define institution-wide settings and override them in specific profiles.
In the first-time wizard, the CAT automatically takes you to the profile creation page as soon as the institution-wide settings are submitted.
For a profile, you first have to set its name and description, which as usually can be done in many languages. There is also one important option: "Production-Ready". We will not publish your generated installers on the end-user download page unless you set this option and check the box. This is to prevent that people accidently download installers with incomplete information while you are still working on the final setup.
The CAT also asks for the RADIUS realm belonging to this profile; submitting the realm name is optional, but highly recommended because it enables us to do very thorough sanity checks on your RADIUS installation later. Please see the section "Verifying my RADIUS setup" for more details. You can also decide whether you want the generated installers to be configured with an anonymous outer identity, and what that identity should be. If you want users of that profile NOT to be given an installer, you can also specify that we should send your users to your own support page instead. A typical use case for that is if you, the admin, want to generate installers but only download them yourself and present them on your own eduroam support page.
The third part of profile generation is about the EAP types which you've configured in your RADIUS server for this user group. By simple drag&drop, please drag all the EAP types you support into the upper green area. The list is ordered by preference, so drag the EAP types into your preferred order. The CAT will always compare the EAP types you've configured here with the capabilities of the various devices which are to be configured. If the device supports your most preferred EAP type, installers will always be generated for that EAP type. If your preferred EAP type does not work on a given device, the preference list is worked through until a match occurs, and then installers for that device will use that not-so-preferred EAP type (which is better than not supporting eduroam configuration at all). Finally, if there is a complete mismatch between the EAP types you support and the EAP types on a device, then we can't generate installers for that device. You might be luckier if you can change your RADIUS setup to support more EAP types then.
specific EAP configurations for your user group(s), and installers are always generated for specific profiles. If you only have one user group, the distinction between institution-wide and profile-wide settings does not make a difference. However, many IdPs have different user groups which share some properties, but not all. One example is where on the one hand students have username/password accounts, authenticating with PEAP and generic helpdesk contact points, and on the other hand permanent staff have TLS Client certificates with EAP-TLS and access to a better second-level helpdesk just for them.
eduroam CAT makes it easy to manage multiple user group profiles for one institution. Shared properties for e.g. server certificates and helpdesk contacts can be defined institution-wide (which makes them immediately available in all profiles) or per-profile (the property then is only defined for this specific profile). You can also define institution-wide settings and override them in specific profiles.
In the first-time wizard, the CAT automatically takes you to the profile creation page as soon as the institution-wide settings are submitted.
For a profile, you first have to set its name and description, which as usually can be done in many languages. There is also one important option: "Production-Ready". We will not publish your generated installers on the end-user download page unless you set this option and check the box. This is to prevent that people accidently download installers with incomplete information while you are still working on the final setup.
The CAT also asks for the RADIUS realm belonging to this profile; submitting the realm name is optional, but highly recommended because it enables us to do very thorough sanity checks on your RADIUS installation later. Please see the section "Verifying my RADIUS setup" for more details. You can also decide whether you want the generated installers to be configured with an anonymous outer identity, and what that identity should be. If you want users of that profile NOT to be given an installer, you can also specify that we should send your users to your own support page instead. A typical use case for that is if you, the admin, want to generate installers but only download them yourself and present them on your own eduroam support page.
The third part of profile generation is about the EAP types which you've configured in your RADIUS server for this user group. By simple drag&drop, please drag all the EAP types you support into the upper green area. The list is ordered by preference, so drag the EAP types into your preferred order. The CAT will always compare the EAP types you've configured here with the capabilities of the various devices which are to be configured. If the device supports your most preferred EAP type, installers will always be generated for that EAP type. If your preferred EAP type does not work on a given device, the preference list is worked through until a match occurs, and then installers for that device will use that not-so-preferred EAP type (which is better than not supporting eduroam configuration at all). Finally, if there is a complete mismatch between the EAP types you support and the EAP types on a device, then we can't generate installers for that device. You might be luckier if you can change your RADIUS setup to support more EAP types then.
EAP Details
In the EAP Details section, you can upload common properties of your RADIUS installation's EAP configuration. If you specify something here, the settings will be used for all the user profiles you define (see below), unless you choose to override them in one of the profiles.
For most EAP methods, the required EAP details are
- The Certification Authority (CA) certificate(s) which signed your EAP server certificate
- always include the root CA (root CAs are indicated with a blue circled "R" besides the certificate details after upload)
- optionally include intermediate CAs (intermediate or server certificates are indicated with a blue circled ("I") besides the certficate after upload)
- The name of your server as specified in the Common Name (CN) of your EAP server certificate
Note 1 - server certificates
There is no point in uploading the server certificate itself. The server certificate is sent during the EAP exchange during login time to the client. Contrary to that, the CA certificates are needed because they are the trust anchor on the client device which it uses to verify that incoming server certificate.
Note 2 - CA requirements
Various client device operating systems have specific requirements about which CA certificates and server certificates they accept. For more information, please see EAP Server Certificate considerations.
Note 3 - CA rollover support
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 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 isolate Android users while giving everyone else multiple trust roots early, you could 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 already supports that
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
After these steps, you can enter/override helpdesk and media properties After these steps, you can enter helpdesk, media properties and certificate details 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. For certificates this means: if you upload one CA certificate on the profile level, all CAs which you may have defined on the institution-wide page already will be ignored for this profile.
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 more.
...