06-20-2016 11:19 AM - edited 03-23-2023 08:46 AM
Cisco Identity Services Engine (ISE) 2.0 introduces support for some non-Cisco Network Access Devices (NADs). ISE uses Network Access Device Profiles to express a NAD’s capabilities and requirements which ISE uses to enable flows such as MAB, Guest, BYOD and Posture.
ISE versions 2.0 and later ship with a number of built-in NAD profiles which are located under Administration > Network Resources > Network Device Profiles:
This guide describes how to create a custom NAD profile when the built-in profiles do not suffice. The number of ISE flows that will be enabled by your NAD profile depends on the NAD’s capabilities.
|Note: For complex flows such as Guest, BYOD and Posture, the device needs to support RFC 5176, “Change Of Authorization” (CoA), and a URL Redirection mechanism capable of redirecting to ISE portals and passing in the client identity (MAC or IP address) as a URL parameter. If your NAD does not support these features, those flows will not work.|
Some information about your device needs to be determined before new NAD profiles can be defined. It is usually necessary to import a new RADIUS dictionary for your device before you can create a NAD profile. You may have to upgrade the device firmware to a more recent version to get CoA/URL Redirect support. It is also usually necessary to make configuration changes on the devices to configure or enable certain features, especially for URL Redirect. Once done, create the new NAD Profile in ISE and assign it to the appropriate devices. Finally, configure new authorization profile(s) and ISE policy to leverage the new profile.
These steps will be explained in more detail in subsequent sections.
Consult the documentation for your NAD to determine what RADIUS dictionary the NAD uses. Most NADs have a vendor-specific RADIUS dictionary that provides a number of vendor-specific attributes in addition to the standard IETF RADIUS attributes. Features such as MAB, CoA, URL Redirect, ACLs, VLAN, SSID, all potentially use RADIUS attributes and sometimes they are vendor-specific (VSAs) rather than IETF.
If your device uses VSAs, you will usually need to install its RADIUS dictionary into ISE before you can assign it to the NAD profile. ISE has the ability to import RADIUS dictionary files in the freeradius format, which can be found at Policy Elements > Dictionaries > System > Radius > RADIUS Vendors then select Import
Once imported successfully, the new dictionary should appear in the list of RADIUS dictionary vendors.
Once you have the required information and RADIUS dictionary installed, go to Administration > Network Resources > Network Device Profiles then click on
For a given Vendor, if you are creating NAD profile for a device similar to one of the built-in profiles, i.e. same vendor but different model with some differences, it is best to clone the existing NAD profile and customize it. The cloned profile will have a copy of the original profile’s settings so you only have to tweak it rather than define it from scratch. You may not have to define a new RADIUS dictionary either, if the current one is sufficient.
However, if your NAD vendor does not match any of the existing ones, you should set the Vendor field to ‘Other’ and enter all of its characteristics.
Check each box if your device supports RADIUS, TACACS+ and/or TrustSec. It is only necessary to check the protocols you want to actually use.
Assign the RADIUS dictionary the device supports – typically one you imported in a step beforehand. Note: You can assign more than one dictionary as some devices do support multiple vendor dictionaries.
Enter the attributes and values that your device uses for the various flows like Wired MAB, 802.1x, in the Flow Type Conditions section (under Authentication/Authorization). This is necessary for ISE to detect the right flow type for your device according to the attributes it uses. There is no IETF standard for MAB and different vendors use different values for Service-Type. It may be necessary to use a sniffer trace to determine the values here if they are not documented in your device’s Admin Guide.
This section allows you to map device specific attribute names to common names to simplify policy rules. Currently, only “SSID” is defined. If your device has the concept of wireless SSID then set this to the attribute it uses.
Attribute Aliasing allows a NAD Profile to map vendor-specific attributes to a common attribute so that policy rules can use the friendly name. It simplifies attribute selection, reduces the number of authentication/authorization policy rules required for different vendor devices, and is potentially less error prone. For example, the Wireless SSID involved in a flow could be included in the Airespace-Wlan-ID, Aruba-ESSID-Name, or Called-Station-ID depending on the type of NAD involved. You can map this to the “SSID” attribute available in the “Normalised Radius” dictionary (Policy > Policy Elements > Dictionaries > Normalised Radius > SSID).
This section allows you to define which attributes and protocols your device uses for MAB. Prior to 2.0, this was accomplished with various obscure combinations of checkboxes in Allowed Protocols page and it potentially required multiple Allowed Protocol entries. Host Lookup is now encapsulated in NAD Profiles and simplifies configuration.
When the Process Host Lookup option is enabled in the Allowed protocols page, the Host Lookup request is processed based on the NAD profile configuration (specifically the Host Lookup (MAB) settings).
Different (non-Cisco) vendors populate the RADIUS Calling-Station-ID and password attributes differently while doing a MAB authentication. For Cisco NADs doing MAB, enabling the Process Host Lookup option is sufficient. However, for other vendor devices, you must enable appropriate options in the Host Lookup (MAB) section, while creating the NAD profile.
As stated above, there is no standard for MAB, so the attributes and protocol it uses varies from vendor to vendor. Refer to your device Admin Guide or a sniffer trace of a MAB authentication to determine the correct settings for this section.
This section defines which attributes your device uses for setting a VLAN or ACL. They may be IETF standard attributes or vendor specific. These are usually published in your device’s Admin Guide.
For the VLAN permission, you can specify multiple RADIUS attribute-value pairs, or a single RADIUS attribute (e.g. Aruba-User-VLAN).
For the ACL permission, you can specify a single RADIUS attribute, to be used for setting a named ACL on NADs relevant to the current NAD profile.
|Note: The options displayed in the Common Tasks section in the Authorization Profile page vary based on the attributes that you configure in the NAD Profile Permission section.|
This section allows you to define what CoA capabilities your device has. Refer to your device documentation for information – look for references to terms like “RFC 5176”, “Change of Authorization” or “CoA”. Most non-Cisco devices with RFC 5176 support will support “Push” and “Disconnect”, but not Re-authenticate, so if unsure try enabling the two checkboxes marked “RFC 5176”.
While RFC 5176 defines the types of CoA requests, the required attributes in the requests vary from device to device. Some devices are very particular about attributes sent in the CoA request.
If your CoA requests are getting a CoA ‘NAK’ back from the device, check some of the following tips:
Some require the RADIUS User-Name attribute from the access-request to be included in CoA requests
Some do not accept both Calling-Station-ID and Acct-Session-ID sent in the same request (send one)
Some do not accept other vendors VSAs in a request
Some devices can be configured to expect (or not) Event-Timestamp and the CoA configuration above must match
While some Admin Guides do publish the attributes, some do not and it requires some trial and error to determine the right set of attributes.
|Note: Ensure that the RADIUS option is selected in the Supported Protocols section, before you configure the RADIUS CoA.|
This section defines the device’s URL Redirect capabilities. URL redirection is necessary for complex flows like Guest, BYOD and Posture. It needs to be capable of redirecting to an ISE portal, i.e. local web auth is not sufficient.
There are two general types of URL redirect found on devices; static and dynamic. Static means a URL has to be configured into the device (manually). It does not support being told where to redirect dynamically via a RADIUS attribute. Typically, you copy and paste the ISE portal URL into the device’s configuration.
The other type is dynamic URL – this is where ISE can use a RADIUS attribute to tell the device where to redirect to dynamically. It is not necessary to manually configure the device. If your device supports dynamic URLs, you should use it as it simplifies configuration.
The Parameter Names are arguments passed by the device in the redirect URL. ISE needs to be told the names of these parameters so it can extract them correctly from the URL. It uses them to identify the client and session, as well as the original URL the client was trying to get to so that it can redirect it.
|Note: Admin Guides do not usually publish these parameter names. Some do, but most do not. A few are actually programmable. What matters is the URL parameter names must match what the device sends (it may be necessary to use a browser to determine what they are if it is not published).|
|Note: Wired devices usually do not have a capable URL redirect.|
Normally, it is unnecessary to create additional or modify the built-in Authentication and Authorization conditions (such as Wired/Wireless MAB or Wired/Wireless 802.1X) as these will automatically use the right NAD profile at runtime. Similarly, the built-in Allowed Protocols will use the correct attributes from existing NAD profiles to detect MAB.
However, should it become necessary to create a custom condition, protocol or profile, you can use the Policy Element Generation wizard to assist you. It can create various editable elements based on the NAD profile which you can further customize or use in policy.
The Summary section shows what flows and services will be enabled by your NAD profile configuration.
Once your NAD profile is created, you may assign it to your network devices in Administration > Network Resources > Network Devices:
ISE has a number of built-in authentication and authorization conditions (Wired/Wireless MAB, 802.1x) that smartly select the right underlying conditions to evaluate. It does this by determining the NAD profile assigned to the NAD at runtime then referring to information in its NAD profile. This allows you to have significantly less authentication/authorization conditions. Often you can define a new NAD profile and it is not necessary to customize the built-in smart conditions.
If you examine one of the existing conditions you can see which NAD profiles will be taken into consideration by it and which are not:
Occasionally, you may wish to define a custom condition for your new device. You can use the Generate Policy
Elements feature from the NAD profile to help you create them with the correct attribute/values in the conditions.
You will usually need to create one or more authorization profiles for your new device. Set the Network Device Profile box to the name of your new NAD profile when creating the profile. This allows the ‘smart’ authorization to automatically select the right profile based on the device’s assigned NAD profile.
When you configure your policy rules, the authorization profile should be explicitly set to the NAD profile that you assigned to that device or “Any” if you are just using VLAN or ACL.
Once you have created your new NAD profile and configured ISE’s policy to use it, you should verify whether the relevant flows work as expected. It is also advisable to verify devices using other NAD profiles still work as expected. The ‘STEPS’ detail in ISE’s monitoring/reports has additional information in ISE 2.0 to help you understand which NAD profile is being used and what flow type is detected which can aid troubleshooting.
I try to send to customers Brocade switch an Acces List.
Brocade requires ACL in format: Filter-ID = ip.ACL_number.in, but ISE define this as: Filter-ID = ACL_number(when network device profile is set to BrocadeWired) and Filter-ID = ACL_number.in(when network profile is set to Cisco) - Policy->Policy Element->Results->Authorization->Authorization Profiles->Add.
How to setup a custom network device profile with Filter-ID = ip.ACL_number.in required by Brocade?(I can create new network device profile, but I can't change Filter-ID to ip.ACL_number.in format).
I can't find where cisco and bracade Filter-ID definitions exist (why cisco has format Filter-ID = ACL_number.in vs Brocade Filter-ID = ACL_number).
Maybe someone can help?
In the future I recommend posting questions to the general ISE Community Support page so that more engineers can view and respond. Otherwise there is a chance your question may be missed or response delayed.
ISE 2.0: By default, ISE appends ".in" to Filter-Id if enabled under Common Tasks for both Cisco and non-Cisco NADs. If do not wish to have this appended, do not define the Filter-Id using the Default Permissions under the NAD Profile, but instead use Advanced Attributes in the Authorization Profile to assign RADIUS:Filter-Id. This option will not append “.in” to ACL name by default.
ISE 2.1: ISE no longer appends ".in" to Filter-Id by default since some vendors wish to use this as a role definition without the ACL direction indicator. This new behavior was resolved by CSCux40136 [Suffix of ACL(Filter-ID)]. In ISE 2.1, the inclusion of ".in" is configurable for non-Cisco NADs under the Common Tasks for ACL (Filter-Id) in the Authorization Profile.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: