- Downloadable URL-Redirect ACL
- Control endpoints with random MAC address
- Prevent disconnection during reauthentication on wired connection
- Inaccessible Authentication Bypass (AKA Critical Authentication) with newer Catalyst platform
- Differentiating specific interface
- VLAN ID in NAS-ID attribute (MAB only)
- VLAN ID & VLAN Name in Tunnel-Private-Group-ID attribute (With IBNS 2.0 syntax)
- MAB request as EAP-MD5
- Differentiating specific network device
- ACL for Active Directory services
- VLAN change for guest
- Per-user/per-endpoint enforcement using dynamic attribute matching
- VLAN Alias
- Use CN instead of DN for LDAP group name
- ISE node AD machine account password renewal
For the Basic Tips for new ISE administrators including sample policy set, please review Basic Tips for new ISE Administrators document
For common mis-configurations on IOS, please review Top Ten mis-configured Cisco IOS Switch settings for ISE integration document
For best practices configuration for AireOS wireless controller, please review Top Six Important Cisco WLC settings for ISE integration document
Downloadable URL-Redirect ACL
Some newer IOS-XE based devices now support downloadable URL-Redirect ACL. Although there is no native support available on ISE yet, one can try the experimental policy described in the Downloadable URL-Redirect ACL with ISE document to try it out.
Control endpoints with random MAC address
If you want to find out whether random MAC is used, apply regular expression condition for RADIUS:Calling-Station-ID attribute to match ^.[26AEae].*. Initially you can assign same permission as real MAC address, but can decided to further employ additional controls if needed. For more information, please read Random MAC address - How to deal with it using ISE.
Prevent disconnection during reauthentication on wired connection
On the wired interface, one can configure ordering of 802.1X and MAB. When reauthentication occurs, as a default flow, the endpoint will go through the ordering setup on the interface again. For instance if ordering was set as 802.1X > MAB, and an endpoint was authenticated via MAB. When reauthentcation occurs, the endpoint will be disconnected during when the reauthentication timer expires as the interface times out the 802.1X for the endpoint. This can yield in bad experience for the endpoint or the enduser as the traffic will be disconnected during that time. In order to maintain the session, one can configure the session to reauthenticate using the last successful method instead of the order the interface is set as. So with this, the MAB endpoint will reauthenticate via MAB without having to go through 802.1X even though the interface ordering is set to 802.1X > MAB. To configure this, one will need to add Cisco VSA in the authorization profile in addition to the reauthentication attributes. The Cisco VSA is “termination-action-modifier=1”. So applied along with regular session time out, it would look like following:
Inaccessible Authentication Bypass (AKA Critical Authentication) with newer Catalyst platform
| SWITCH(config-if)#authentication host-mode multi-auth SWITCH(config-if)#authentication event server dead action authorize {Optional VLAN ID if different from interface access VLAN} |
In the past there was no point of multi-auth mode with server dead action authorize combination as a single interface will not allow more than one data VLAN. So assigning a server dead VLAN that is different from interface VLAN or AAA assigned VLAN would result in odd behavior. However, that is no longer the case with certain Catalyst platforms. Relatively newer platforms allow different endpoints to be assigned different VLAN on a single interface and even the server dead VLAN may be assigned along with other endpoints on the same interface. This option provides best end user experience as pre-connected endpoints are not impacted during the server dead transition, only newly connecting endpoint during server dead event is moved to specified VLAN. Following platforms supports multi-auth mode with multi-dVLAN as well as Inaccessible Authentication Bypass (Critical Authentication) with authorize option:
- Catalyst 2960X, 2960XR, 3560CX running 15.2(2)E+
- Catalyst 3850, 3650 running 03.03.00SE
- All Catalyst 9K with any IOS XE version
Note: More information on the "Multi-auth Per User VLAN assignment":
Differentiating specific interface
There are certain use cases where admins would like to differentiate policy based on the physical interface that endpoints are connected to. For instance, specific ports are mapped to conference rooms and the admin wants to designate the ports for guest only access, but currently there is no easy way to let ISE know that certain ports are for conference rooms. In the case of wireless access, the SSID name is included in the Called-Station-ID field as a default, however, no such information can be sent for wired authentication for RADIUS access request. There is an open enhancement request (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp20205) for IOS-XE to allow customizable information such as interface description or template name as part of RADIUS access request, but in the mean while, following work arounds can be used:
VLAN ID in NAS-ID attribute (MAB only)
12.2(43)SE2 and above
| SWITCH(config)#mab request format attribute 32 vlan access-vlan SWITCH(config)#interface GigabitEthernet x/y/z SWITCH(config-if)#switchport access vlan 10 |
Example authorization policy condition on ISE:
VLAN ID & VLAN Name in Tunnel-Private-Group-ID attribute (With IBNS 2.0 syntax)
15.2(2)E/3.6.0E/15.2(1)SY and above (Currently not supported with 16.x. Tracked with https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvo05751)
| SWITCH(config)#vlan 10 SWITCH(config-vlan)#name USER SWITCH(config-vlan)#exit SWITCH(config)#access-session attributes filter-list list VLAN SWITCH(config-com-filter-list)#vlan-id SWITCH(config-com-filter-list)#exit SWITCH(config)#access-session authentication attributes filter-spec include list VLAN SWITCH(config)#interface GigabitEthernet x/y/z SWITCH(config-if)#switchport access vlan 10 |
Example authorization policy condition:
If IdentityGroup·Name EQUALS User Identity Groups:Employees
AND Radius:Tunnel-Private-Group-ID EQUALS (tag=2) Demo-Wired
MAB request as EAP-MD5
Another way to differentiate specific interface is to send MAB request in a different authentication protocol. As default Cisco Catalyst devices sends MAB request via PAP, following command will force the device to send MAB request as EAP-MD5 request, which ISE can use as condition to differentiate policy decision.
| SWITCH(config)#interface GigabitEthernet x/y/z SWITCH(config-if)#mab eap |
When making this change, ISE will match MAB request from this interface to 802.1X policy as it is using EAP. In order to force ISE to process it as MAB request create MAB policy set as following and list it before 802.1X policy set
Example policy set condition for MAB (Make sure MAB policy set is above 802.1X policy set):
Example authorization policy condition:
Note: Side effect of using ‘map eap’ is that ISE processes the MAC address as if it is a username within the system so the identity format of ‘mab eap’ and regular mab will look different in places like live log
In addition to above, you may need to create a separate NAD profile to use EAP-MD5 for MAB:
Note: Once NAD profile has been created, it needs to be applied to the NAD as well as Authorization profile to take affect.
Differentiating specific network device
In general when different policy is to be used for specific device, it is best to utilize Network Device Groups within ISE and allocate network devices in different groups and use it for policy condition. However, there may be cases where admin would like to send custom string from the network device to influence policy decision. In the following example “Stack-“ will be prepended to the host name for NAS-ID attribute.
| SWITCH(config)#radius-server attribute 32 include-in-access-req format ? LINE A string where %i = IP address and %h = hostname, %d = domain name SWITCH(config)#radius-server attribute 32 include-in-access-req format Stack-%h |
Example policy condition
ACL for Active Directory services
As ISE admin you made sure to include all AD servers in the ACL for Windows machines. Yet, when 802.1X with ACL is used, the users complain that their login takes few minutes or in some cases that their shutdown takes forever. However, when user unplugs the PC from the network, the PC is able to shutdown immediately. You also notice that when ‘permit ip any any’ ACL is used there are no login delays. You recheck the ACL but you have accounted for all AD servers on the network with specific TCP/UDP ports (FYI, required ports listed here: https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/ise_active_directory_integration/b_ISE_AD_integration_2x.html#reference_94BE6ABB85BC47C8AEC29EF8D286E6E4).
Potential fix, permit ip fragments to AD servers in the ACL. If using dACL add ‘permit ip any host x.x.x.x fragments’ for each AD servers.
Note: ISE dACL syntax check will fail but can be ignored.
VLAN change for guest
Admins generally want to segment off guest traffic. For wireless, admins can use auto-anchoring to tunnel guest traffic to DMZ, however, it is not easy for wired guest traffic to leverage the similar design. So typical alternative is to assign a different VLAN for guest users, which could be mapped to a different vrf. In order to achieve this, they opt to assign guest VLAN upon successful guest web authentication. Since CWA utilizes MAB, the endpoint will not be able to change VLAN upon web login automatically, rather they will be forced to download java applet to renew IP address which isn’t user friendly nor always applicable. One alternative way to achieve segmentation of guest traffic is to assign VLAN pre & post guest authentication. Consider when creating CWA policy on ISE, one would create two authorization profile; one for Web redirect (Default authorization on ISE for this is called Cisco_WebAuth) and another to provide access once authenticated. The trick is to send same VLAN ID as part of authorization for both authorization profile. The VLAN ID sent in both authorization profile is the one the guest users should eventually be assigned to. This way, guest users are not forced to change VLAN upon authentication and guest traffic is segmented from employee traffic.
Note: This will only work when closed mode is used (as opposed to monitor mode or low-impact mode)
Per-user/per-endpoint enforcement using dynamic attribute matching
Per user VLAN, SGT, and IPSK
Per user MAC address enforcement
VLAN Alias
It is rare to see VLAN ID/Name to be standardized across all access layer switches. It is common for it to be standardized in a single campus, but not across the entire network footprint. This poses issues when trying to create policy using dynamic VLAN assignment as the VLAN ID/Name that ISE is pushing via RADIUS may not exist on all the network device. Standardizing VLAN ID/Name is probably not any network team would want to consider. Also, creating ISE policies to accommodate all variances of VLAN ID/Names would be hard to manage. Now, one option is to use the dynamic attribute feature above where VLAN ID/Name is hard coded per endpoint. Dynamic attribute works as long as the endpoint isn’t nomadic. If endpoint tends to move from one access switch to the other, there is possibility that specific VLAN ID/Name for that endpoint may not be present on the network device.
There is another option where an alias can be created for each VLANs on the network device. The feature on IOS is called ‘VLAN group’. The original intent of the VLAN group feature was for multiple VLANs to be assigned in round robin for load distribution, but one can create single VLAN to single VLAN group mapping to create alias for each of the VLANs. This will allow switches to accept standardized VLAN names from ISE while leaving original VLAN names intact. Here I have two switches where on one switch the VLAN ID for user is 110 and name is USER110 while the other one has 320 and name of USER320 for VLAN information. On ISE policy, only single rule is needed with VLAN name ‘USER’ in the permissions for both switches.
//First switch with original VLAN ID 110 for user VLAN
| SWITCH1(config)#vlan 110 SWITCH1(config-vlan)#name USER110 SWITCH1(config-vlan)#exit SWITCH1(config)#vlan group USER vlan-list 110 |
//Second switch with original VLAN ID 320 for user VLAN
| SWITCH2(config)#vlan 320 SWITCH2(config-vlan)#name USER320 SWITCH2(config-vlan)#exit SWITCH2(config)#vlan group USER vlan-list 320 |
Use CN instead of DN for LDAP group name
When using default LDAP schema for AD within ISE, it will use DN (Distinguished Name) for the group names, which is not easy to read within ISE GUI. This is especially true when trying to use LDAP group in other parts of the ISE such as policies. AD stores group mappings both ways (As in user objects are stored in group as well as group attributes are in user objects) so referencing users from group works as well. If you want to use CN (Common Name) for the group name, create custom LDAP identity store with following settings:
Note: One caveat with doing LDAP lookup of AD is that ISE will not be able to lookup membership of primary group. For instance, all domain users are part of 'Domain Users' primary group, but even though you can map 'Domain Users' to sponsor group, ISE will not be able to match using LDAP. This is due to how AD treats primary groups differently and can be avoided by using other groups or native AD integration.
ISE node AD machine account password renewal
When ISE integrates with AD, each ISE node becomes a member server of AD domain. Due to this ISE doesn't require service account credentials to be saved to ISE, as it uses trust between the machine and AD for domain user/machine authentication. However, since ISE is not a Windows server, it doesn't follow all of the domain level GPO settings that AD admin may require for Windows servers. One of the setting that doesn’t follow domain settings is password renewal interval for the machine account. Although ISE doesn't honor the GPO setting, it can be configured manually using AD Advanced Tuning option. Here is instruction on how to configure the machine account password renewal period, for other settings that can be configured via AD Advanced Tuning, please refer to: https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_01110.html#reference_D81D04FDE46C4FF1A396641074E8836C
- Apply ISE 2.4 patch 1 or higher.
- Go to Administration > Identity Management > External Identity Sources > Active Directory
- Click Advanced Tools > Advanced Tuning
- Select the ISE node you want to change
- The 'Name' field gets the specific REGISTRY string given below.
REGISTRY.Services\lsass\Parameters\Providers\ActiveDirectory\MachinePasswordLifespan - The 'Value' field is where you specify the option. Specify value in seconds. Valid range is 30 minutes ~ 60 days; default is 30 days (2592000).
- Type any description. Required before next step.
- Click 'Update Value' button
- Click 'Restart Active Directory Connector'
Note: ISE Machine change password should trigger every (configured-time) / 2 seconds. However, the ISE machine Kerberos TGT refreshes every 30 minutes regardless of machine password settings so as to keep the TGT fresh
