cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Advanced ISE tips to make your deployment easier

2016
Views
35
Helpful
2
Comments


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

 

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: Unfortunately there is no official name for this feature that can be searched via the feature navigator. When dVLAN assignment is used with multi-auth mode, it behaves differently depending on the platform

 

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:

Screen Shot 2019-05-03 at 8.36.23 PM.png

 

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:

 Screen Shot 2019-05-03 at 8.42.48 PM.png

 

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):

Screen Shot 2019-05-03 at 8.44.55 PM.png

Example authorization policy condition:

Screen Shot 2019-05-03 at 8.44.32 PM.png

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:

Screen Shot 2019-10-08 at 1.34.42 PM.png

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

Screen Shot 2019-05-03 at 8.47.11 PM.png

 

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

Screen Shot 2019-05-21 at 6.47.19 AM.png

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:

LDAP-group.png
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

  1. Apply ISE 2.4 patch 1 or higher.
  2. Go to Administration > Identity Management > External Identity Sources > Active Directory
  3. Click Advanced Tools > Advanced Tuning
  4. Select the ISE node you want to change
  5. The 'Name' field gets the specific REGISTRY string given below.
    REGISTRY.Services\lsass\Parameters\Providers\ActiveDirectory\MachinePasswordLifespan
  6. 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).
  7. Type any description. Required before next step.
  8. Click 'Update Value' button
  9. Click 'Restart Active Directory Connector'

Screen Shot 2019-05-20 at 11.13.48 PM.png

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

 

Comments
VIP Engager

For VPN it is helpful to break out your use cases, i.e. employee vs. vendor VPN.  In most cases customers will have different tunnel group setup for different VPN use cases.  We use the Cisco-VPN3000 tunnel group name (option 146) for our VPN policy sets:

 

Employee VPN  Cisco-VPN3000 tunnel group name equals Employee-VPN

Vendor VPN Cisco-VPN3000 tunnel group name equals Vendor-VPN

 

Cisco Employee

Paul, thanks for the tip. I added to the policy set table.