This document is to provide any changes made to endpoint OS that impacts BYOD flow for end users.   Prior to troubleshooting endpoint issues, please follow these steps first: Update OS finger printing DB on ISE: This is done by going to Administration > System > Settings, Posture > Updates, then click ‘Update Now’ button. It may take ~ 10 minutes to complete. Although this update is for posture, BYOD flow leverages the same update to identify browser user agent string to get OS information from the client. This menu is available to setup even if the deployment does not have any Apex license. For Android, make sure to download latest version of SPW app from the Google play store For Windows and macOS, make sure to download latest SPW from Cisco to ISE and update Client Provisioning Policy to reflect the newer version of SPW   Android devices Android 9 (Pie) If BYOD profile includes web proxy settings, SPW requires user to establish Android work profile if not already present on the endpoint With single-SSID flow, user has to delete the SSID setting (That was used to connect with PEAP-MSCHAPv2) for EAP-TLS will function. User will be guided via overlay instructions   Android 6 (Marshmallow) and above Uses EST instead of SCEP between the endpoint and ISE. Requires additional policies on ISE and also change to redirect ACL to allow EST server access from endpoint. Due to this change end users are required to enter network credential for EST authentication in addition to regular WebAuth/802.1X authentication   iOS devices 12.2 Now iOS device requires user to manually go to profile settings whereas before user was able to open profiles within the browser Profile popup for root CA certificate and SCEP/WiFi profile popup happens back to back without user acknowledging In a single-SSID flow, the iOS device is still connected with PEAP instead of EAP-TLS after CoA. User has to disable Wireless and re-enable it to connect with EAP-TLS   10.3 When non well known certificate is used for BYOD portal, iOS device requires the root CA certificate to be trusted prior to accepting rest of the profile   macOS 10.12 (High Sierra) When CNA BYOD (mini browser) flow is used, and when user clicks on the hyperlink in the CNA browser, instead of opening up full browser, it opens up within the CNA browser which breaks the BYOD flow.       ... View more

For common mis-configurations on IOS, please go to: https://community.cisco.com/t5/security-documents/top-ten-mis-configured-cisco-ios-switch-settings-for-ise/ta-p/3643912 For best practices configuration for AireOS wireless controller, please go to: https://community.cisco.com/t5/security-documents/top-six-important-cisco-wlc-settings-for-ise-integration/ta-p/3643795   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:     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   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.   How to use policy set effectively Not really advanced in terms of feature, but often get asked about what is the best way to utilize policy set. Best way is to use it to make policy easy to read from the admin stand point. When policy is easy to read, mistakes are minimized. One way to make policy easier to read on ISE is to create policy set per access type. This way, similar use cases are contained within each policy set. Policy Set Name Description Condition Identity Store WLAN_Employee Employee SSID, match with SSID Name RADIUS:Called-Station-ID(31) ENDS_WITH Employee & Wireless_802.1X All_User_ID_Store WLAN_Guest Guest SSID, match with SSID Name RADIUS:Called-Station-ID(31) ENDS_WITH Guest Internal Endpoints WLAN_PSK PSK SSID, match with SSID Name Called-Station-ID(32) ENDS_WITH PSK Internal Endpoints Wired_MAB Wired MAB Wired_MAB Internal Endpoints Wired_DOT1X Wired 802.1X Wired_802.1X All_User_ID_Store VPN_Employee Remote Access VPN for Employee RADIUS:NAS-Port-Type(61) EQUALS Virtual & Cisco-VPN3000:CVPN/ASA/PIX7x-Tunnel-Group-Name(146) EQUALS Employee All_User_ID_Store VPN_Vendor Remote Access VPN for Vendor RADIUS:NAS-Port-Type(61) EQUALS Virtual & Cisco-VPN3000:CVPN/ASA/PIX7x-Tunnel-Group-Name(146) EQUALS Vendor All_User_ID_Store EST Enrollment over Secure Transport authentication for Android BYOD flow Network Access: Device IP address EQUALS 127.0.0.1 All_User_ID_Store Note: I am listing wireless access first as wireless endpoints tend to be chatty in terms of authentication compared to wired access   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 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   ... View more

Adds RADIUS CoA support on AP and modifies MAB parameters. Tested with Aerohive AP330 running HiveOS 6.5r8b.179369. On ISE, Auth VLAN feature was used for URL redirect and advanced flows (CWA, BYOD, Compliance). Few notable settings on Aerohive AP: Enable Captive Web Portal: Unchecked Enable MAC Authentication: Checked Authentication Protocol: PAP User Profile Application Sequence: SSID-MAC Authentication - Captive Web portal Note: To reduce number of ISE policies, ISE can return VLAN ID sent from the AP RADIUS attribute ‘Aerohive:Aerohive-User-Profile’ for access VLAN ID for authorization.   ... View more