Configuring Cisco ISE
Cisco's own general configuration documentation at https://www.ise-support.com/2019/07/01/configuring-ise-for-eduroam-authentication/ can be used as a starting point and contains eduroam-specific instructions however these contain errors! Jisc's advice in the past has been to read their Implementing eduroam roadmap pages as it contains relevant configuration guidance for Cisco ISE in each logical section.
After applying any ISE update or patch or after editing remote RADIUS servers in Network Resources > External RADIUS Servers or a RADIUS server sequence in Network Resources > RADIUS Server Sequences, you MUST check that ISE is still forwarding auth requests for your visitors to the FLR. You should probably use active eduroam monitoring to monitor your connection. Restart your ISE instance (usually takes ~30 minutes) completely to return ISE to status.
Nb. Upgrade matrix - https://community.cisco.com/t5/security-knowledge-base/ise-version-upgrade-matrix/ta-p/3653501
ISE 3.1 - 3.2: We've had reports of problems with the remote RADIUS configuration / RADIUS authenticators on various versions of ISE over time and issues have been reported with version 3.2 too.
Known good versions of ISE are:
- ISE 3.1 patch 8 - as of 21/12/2023 this is the recommended version of ISE to be running.
- ISE 3.2 patch 3.
These versions probably should (and can be) updated as information changes.
ISE 3.0 - 3.1: Version 3.0 was released ~ Sept 2021. Nothing very much changed between 2.7 and 3.0 other than the addition of some new features. The GUI screens may have altered, but the above guide can still be used as a starting point. Note the warnings documented in the configuration notes.
ISE 2.3 - 2.7: A new Policy Engine was introduced in version 2.3 and with that came changes to how RADIUS Proxy Sequences are used for authentication. Because of this change in behaviour https://community.cisco.com/t5/security-documents/configuring-eduroam-on-cisco-identity-services-engine-ise/ta-p/3655672 (note this guide can be used for versions 2.2 and lower since it breaks the Policy Sets section into sections detailing the configurations necessary for both strands). (*) 2.7 entered end-of-life and the last date of software maintenance releases were on 22 Sept 2023. See https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/bulletin-c25-2943876.html
ISE 2.0 - 2.2: See https://community.cisco.com/t5/security-knowledge-base/configuring-eduroam-on-cisco-identity-services-engine-ise-2-1/ta-p/3655770 for instructions.
ISE 1.2 - 1.4: Retired; you really should upgrade to ISE 2.7 (stable) or 3.0
Configuration Notes:
The section in the Cisco guide headed Create another condition 'Eduroam_User_Traveling' which is intended to relate to your roaming users, i.e. authentication requests received from the FLRs, contains some conditions which have erroneously been included; these MUST NOT be applied:
Radius:Service-Type = Framed
AND
Radius:NAS-Port-Type = Wireless 802.1X (type 19)
AND
Airespace:Airspace-WLAN-ID = 6 <This would be relevant to the Policy condition for auths from your visitors to campus>
Those attributes have no relevance to users roaming to other venues and are often filtered out (Service-Type and NAS-Port-Type attributes are not among the minimum required eduroam attributes). These conditions have place in Policy for Roaming Users. The condition you need to apply is that the RADIUS client belongs to your 'Eduroam network Device Group' (i.e. the FLR).
The section headed Create a new condition 'Eduroam_User_External' which will be used to identify RADIUS requests that need to be handed off to the eduroam RADIUS Servers, contains errors. It is not clear why the below conditions are included:
Radius:Service-Type EQUALS Framed
AND
Radius:NAS-Port-Type EQUALS Wireless – IEEE 802.11
Furthermore it is possible that these conditions will result in unwanted attributes being included in the RADIUS request sent to the FLRs.
So, in your policy conditions for selecting authentication requests for visitors which will be forwarded to the FLR, set the following conditions only:
Radius:User-Name NOT ENDS WITH @<your_domain>
AND
Radius:User-Name CONTAINS @ <This is the bare minimum as all it checks is that there is an @ in the username..>
You may also add a condition for matching the VLAN/WLAN-ID/network service from which the auth request has come. This will be highly dependent on your local Wi-Fi kit and network configuration.
The Cisco guide - relating to Cisco WLAN kit provides (in the wrong section) the following:
AND
Airespace:Airspace-WLAN-ID = 6 <Alternatively you could match Radius:Called_Station-ID ENDS WITH eduroam>
See also: https://www.ise-support.com/2019/07/01/configuring-ise-for-eduroam-authentication/
ISE Distributed Deployments:
Understanding the roles of different nodes—specifically the Admin Node and the Policy Node—is crucial for both setting up networks and maintaining security protocols efficiently.
ISE has 3 components/personas:
- Administration (PAN) – Administration Node is a single point of ISE deployment configuration. This persona provides full access to administration GUI
- Policy Service (PSN) – Policy Service Node is a node that handles traffic between network devices and ISE (its IP is used as Radius for devices). To achieve radius traffic sharing you can scale the PSNs up.
- Monitoring (MnT) – monitoring node is responsible for logs aggregation across deployment.
Which nodes are the ones you peer with the eduroam FLR? The Policy Service Nodes are the ones that handle authentication traffic and these need to be peered with the eduroam FLR and your WLCs.
Sending operator name (with ISE 2.0):
Cisco ISE servers do not have the correct attribute set up for insertion of the Operator-Name attribute. However, the steps to achieve this are straight forward in the GUI.
The following article at Jisc describes how:
https://support.eduroam.uk/files/Configuring%20Operator%20name%20in%20CISCO%20ISE%202.docx