We do not provide a PDF of this document. For an offline copy of this document, simply create your own PDF using File > Print then Save as PDF on your local computer. Introduction Cisco Catalyst 9800 (C9800) series wireless controller running 16.10.1 has feature parity with AireOS 8.8, which means that all the feature that works between AireOS & ISE also works between C9800 & ISE. However, the configuration of C9800 is different from AireOS and this document shows how to configure C9800 to work with ISE. For more information on Cisco Catalyst 9800 series, please go to: https://www.cisco.com/c/en/us/products/wireless/catalyst-9800-series-wireless-controllers/index.html Setup Components used: WLC: Catalyst 9800-CL running 16.10.1 AP: Cisco 1815i ISE: 2.4p3 (Previous versions of ISE should work with C9800 as well)   The document does not cover details on how to bootstrap the ISE, C9800, and AP. The document assumes the C9800 is accessible from the management PC and AP is associated to the C9800. The document also assumes underlying network elements are already configured, which includes, VLANs, SVIs, Subnets, DHCP, routing, and DNS. The following diagram and table shows settings for the components. C9800 IP 192.168.201.61 ISE IP 192.168.201.93 DNS IP 192.168.201.71 OPEN SSID OPEN SECURE SSID SECURE Guest VLAN 30 Guest Subnet 192.168.30.0/24 User VLAN 10 User Subnet 192.168.10.0/24   Notes: If static ACL needs to be applied to a session, use AireSpace-ACL-Name (6) attribute to send down a ACL name. The ACL needs to be pre-created on C9800 C9800 supports dACL for central switching If dVLAN needs to be applied to a session, use AireSpace-VLAN-Name (5) attribute to send down a VLAN name/ID. The VLAN needs to be pre-created on C9800. Alternatively standard RADIUS 3 tuple attributes can be used for VLAN assignment using VLAN name/ID Redirect ACL follows Catalyst IOS syntax instead of AireOS syntax. So permit statement means the matching traffic is redirected, while deny means it will be allowed without redirect With local mode, unlike AireOS, DNS ACL entries are not tied to the redirect ACL. URL entries needs to be defined in the URL Filters and called upon via separate RADIUS attribute during the authentication. More information on this at the end of the document on ISE section. With FlexConnect mode, URL filter is tied to the redirect ACL within the flex profile, so URL filter does not need to be called upon via separate RADIUS attribute   Catalyst 9800 Configuration Following diagram shows the C9800 configuration at a high level. Each box represents individual configuration profile with relevant options shown and how each profile feeds into other profiles to make a working configuration. The bullet points within the profile that are in bold represents sub profile being fed into the profile. It also includes the suggested order to create the profiles that maps to the main section of the document.   Steps 1 - 3: Define AAA   Go to Configuration > Security > AAA > Servers / Groups > Servers, Click Add Enter following information (Any configuration not defined in the table assumes default settings): Name ISE01 IP 192.168.201.93 Key ***** (Match with ISE) Support for CoA Checked Click Server Groups, Click Add Enter following information: Name ISE Available Servers ISE01 Go to Configuration > Security > AAA > AAA Method List > Authentication, Click Add Create Authentication list using following information that will be used for both OPEN SSID and SECURE SSID: Name default Type dot1x Group-Type Group Available Server Groups ISE Note: If clients are failing to associate and authentication request does not show up on ISE Live Log, try setting the authentication list name to 'default' as shown above. Go to Configuration > Security > AAA > AAA Method List > Authorization, Click Add Enter following information for AAA Authorization list that will be shared for both SSIDs: Name default Type Network Group-Type Group Available Server Groups ISE Note: The Authorization name 'default' is significant here since there is no Authorization list that can be defined within the 802.1X WLAN. By using 'default' as name, C9800 can use the ISE to get additional authorization details such as for dACL operation. If default authorization list cannot be used or desired, then named authorization can be created and can be referenced via RADIUS server as a Cisco VSA. The Cisco VSA to use is 'Method-List={authorization-method-list}', which can be configured in ISE advanced Attribute Settings. Please see examples at the end of the document. Go to Configuration > Security > AAA > AAA Method List > Accounting, Click Add Enter following information for AAA Authorization list that will be shared for both SSIDs: Name default Type Identity Available Server Groups ISE   Step 4: Create Webauth Parameter Map (Required for BYOD) This will only be used in the SECURE SSID to suppress Apple CNA (AKA mini browser) from popping up upon association to the WLAN. This is required as the Apple CNA is unable to fulfill the BYOD onboarding flow. Go to Configuration > Security > Webauth > Webauth Parameter Map, Click Add Enter Name ‘Captive-Bypass-Portal, Click Apply to Device Click ‘Captive-Bypass-Portal’ parameter map from the list Check Captive Bypass Portal, Click Update & Apply   Step 5: Create VLANs Go to Configuration > Layer 2 > VLAN > VLAN, Click Add Add two VLANs using following table for User VLAN and Guest VLAN. These VLANs will be mapped to SECURE SSID and OPEN SSID respectively using policy profiles and tags: VLAN ID 10 30 Name User Guest State Activated Activated Port Members Gi2 Gi2 Click Save & Apply to Device   Step 6: Create WLANs Go to Configuration > Tags & Profiles > WLANs, Click Add Add WLANs using following table for OPEN WLAN and SECURE WLAN. These WLANs will be mapped to the AP using tags (Any configuration not defined in the table assumes default settings): General Profile Name OPEN SECURE   SSID OPEN SECURE   Status Enabled Enabled Security > Layer 2 Layer 2 Security Mode None WPA + WPA2   MAC Filtering Enabled     Authorization List default   Security > Layer 3 Webauth Parameter Map   Captive-Bypass-Portal Security > AAA Authentication List default default Note: There is no reference to Authorization List for 'SECURE' SSID. This is not an issue for AAA override operation that applies authorization directly from RADIUS ACCESS-ACCEPT response. However, this is an issue for applying dACL as it requires additional RADIUS communication which requires authorization list. To address this issue, either use special name 'default' as authorization list as configured above or configure ISE to send Cisco VSA 'Method-List={authorization-method-list}' with ACCESS-ACCEPT when dACL is used. See ISE section below for more information. Click Save & Apply to Device Step 7: Create Policy Profiles Go to Configuration > Tags & Profiles > Policy, Click Add Add Policy Profiles for both WLANs using following table. Policy profile covers device sensor, default VLAN, CoA, and RADIUS Accounting. Since VLANs are different, two profiles are created one for each WLAN. These profiles will be mapped to the WLANs using tags (Any configuration not defined in the table assumes default settings): General Name Guest User   Status Enabled Enabled Access Policies HTTP TLV Caching Checked Checked   RADIUS Profiling Checked Checked   DHCP TLV Caching Checked Checked   VLAN/VLAN Group Guest User   URL Filters (Pre Auth)   BYOD-URL-Filter Advanced Allow AAA Override Checked Checked   NAC State Checked Checked   Accounting List default default Click Save & Apply to Device   Step 8: Create Policy Tag Go to Configuration > Tags & Profiles > Tags, under Policy Click Add Enter Name: ISE Enabled Within the 'ISE Enabled' Tag window, click Add to map following WLANs to matching policy profiles. This ties the WLAN to the respective Policy Profile. WLAN Profile Policy Profile OPEN Guest SECURE User Click Save & Apply to Device   Step 9: Assign Policy Tag to AP Finally, apply the tag to the AP. This section shows instructions on tying it to a single AP. Using Advanced Wireless Setup Wizard on C9800, same tag can be applied to multiple APs at the same time. Go to Configuration > Wireless > Access Points Click on the AP Name or MAC address Under General > Tags, Select 'ISE Enabled' Click Update & Apply to Device   Step 10a: Create Redirect ACL for Guest flow Go to Configuration > Security > ACL, Click Add Use ACL Name: ACL_WEBAUTH_REDIRECT For ACL Type, select IPv4 Extended Enter following rules in the ACL for Guest only access redirect ACL Sequence Action Source IP Destination IP Protocol Source Port Destination Port 10 deny any 192.168.201.93 tcp   eq 8443 20 deny any 192.168.201.71 udp   eq domain (53) 30 permit any any tcp   eq www (80) Click Save & Apply to Device   Step 10b: Create Redirect ACL for BYOD flow Enter following rules in the ACL for Guest and BYOD (Sequence 20 is needed for any endpoints using Network Setup Assistant for BYOD) Sequence Action Source IP Destination IP Protocol Source Port Destination Port 10 deny any 192.168.201.93 tcp   eq 8443 20 deny any 192.168.201.93 tcp   eq 8905 30 deny any 192.168.201.71 udp   eq domain (53) 40 permit any any tcp   eq www (80) Click Save & Apply to Device   Step 11a: Create URL Filter for BYOD flow Unlike AireOS which allows DNS entries to be part of redirect ACL, separate URL filter have to be created and be called upon via RADIUS attribute from ISE to permit access to Internet hosts using FQDNs. Go to Configuration > Security > URL Filters, Click Add Add URL Filter using following table (Example here is to allow access to Google Play store for BYOD): Name BYOD-URL-Filter Type PRE-AUTH Action Permit URLs *.google.com accounts.youtube.com gstatic.com *.googleapis.com *.appspot.com ggpht.com gvt1.com market.android.com android.pool.ntp.org *.googleusercontent.com *.google-analytics.com Note: The PRE-AUTH URL filter always works as if the 'Action' is Permit regardless of whether it is setup as Permit or Deny. Click Save & Apply to Device   Step 11b: Create URL Filter for Social Network Guest access - Facebook Go to Configuration > Security > URL Filters, Click Add Add URL Filter using following table (Example here is to allow access to Facebook OAUTH2 login for Guest access): Name Guest-URL-Filter Type PRE-AUTH Action Permit URLs *.facebook.com *.akamai.com *.fbcdn.net *.akamaihd.net Click Save & Apply to Device   ISE Configuration Authorization Profile with URL Filter Policy Setup on ISE is identical to the one for AireOS controller aside from the URL ACL that needs to be defined as separate RADIUS attribute. This is done by sending Cisco VSA "url-filter-preauth={URL_Filter_Name}". Here is an example of ISE Authorization profile for BYOD that allows Android devices to access the Google play store using the pre-auth URL filter defined above. Note the Cisco AV pair defined in the 'Advanced Attribute Settings' section.   Authorization Profile with dACL using AAA 'Method-List' Cisco VSA As noted above in AAA section, to support dACL, authorization method list name should be set as 'default'. Alternatively, you can choose to use other names for authorization method list, however, doing so requires specifying authorization method list using RADIUS attribute. Here is an example of applying dACL by sending down authorization method list 'ISE-AUTHZ' within the ISE authorization profile. Note that the Cisco VSA 'Method-List' is case sensitive.     For rest of the ISE configuration, please use following guide for rest of the ISE configurations: Guest: https://community.cisco.com/t5/security-documents/ise-guest-access-prescriptive-deployment-guide/ta-p/3640475 BYOD: https://community.cisco.com/t5/security-documents/cisco-ise-byod-prescriptive-deployment-guide/ta-p/3641867 Posture: https://community.cisco.com/t5/security-documents/ise-posture-prescriptive-deployment-guide/ta-p/3680273   Catalyst 9800 Configuration for FlexConnect Local switching This section describes additional configuration needed to configure the WLAN as FlexConnect Local switching and integrate it with ISE. This section will utilize existing configurations made above.   Modify Policy Profile Go to Configuration > Tags & Profiles > Policy, Click profile name that maps to the WLAN to change to local switching Under WLAN Switching Policy section, uncheck Central Switching Click Update & Apply to Device Repeat above steps for other policy profiles that maps to the WLANs to be converted to local switching   Create Flex Profile Go to Configuration > Tags & Profiles > Flex, Click Add Add Flex Profile using following table General Name Flex   Policy ACL ACL Name ACL_WEBAUTH_REDIRECT     Central WebAuth Checked     Pre Auth URL Filter (If this is for BYOD, select BYOD-URL-Filter, else blank)   VLAN VLAN Name User Guest   VLAN Id 10 30 Note: When 'Central WebAuth' is checked, the C9800 automatically creates a Flex ACL that is in reverse of selected redirect  ACL. The permit statements are changed to deny and deny statements are changed to permit. This is due to differences between the two redirect ACL types and slight modification is needed on the ACL to make it work with FlexConnect mode. This option should only be checked for ACL that is going to be used for redirect purpose and for post-authentication ACL, this option should not be checked. See ACL section below for more information. Click Save & Apply to Device   Create Site Tag Go to Configuration > Tags & Profiles > Tags, Click Site, Click Add Add Site Tag using following table Name Branch Flex Profile Flex Enable Local Site Unchecked Note: Unchecking 'Enable Local Site' will reveal Flex Profile option Click Save & Apply to Device   Assign Site Tag to AP Go to Configuration > Wireless > Access Points Click on the AP Name or MAC address Under General > Tags > Site, Select 'Branch' Click Update & Apply to Device Note: The AP will disconnect for few minutes and when reconnected to the controller, it will be in FlexConnect mode   Modify Redirect ACL When ACL is translated to the FlexConnect ACL, it requires return traffic to be allowed for it to work. If deny is missing for return traffic the endpoint in Central_WebAuth state will not be able to finish the redirect flow. Following changes to the existing ACL will make ACL wotk for both local mode and FlexConnect mode. Go to Configuration > Security > ACL, Click ACL name ACL_WEBAUTH_REDIRECT For any deny statement ensure that deny ACE entry is added for return traffic. See sequence 11 & 12 for example: Sequence Action Source IP Destination IP Protocol Source Port Destination Port 10 deny any 192.168.201.93 tcp   eq 8443 11 deny 192.168.201.93 any tcp eq 8443   20 deny any 192.168.201.71 udp   eq domain (53) 21 deny 192.168.201.71 any udp eq domain (53)   20 permit any any tcp   eq www (80) Click Update & Apply to Device   Troubleshooting For more information on the C9800/ISE integration and troubleshooting, please go to: https://www.cisco.com/c/en/us/support/wireless/catalyst-9800-series-wireless-controllers/products-configuration-examples-list.html       ... View more

Working HPE-ArubaOS switch 2920 running 16.02 with matching ISE configuration. This leverages dynamic URL redirect feature on the NAD. This requires matching NAD profile. See the ISE Third-Party NAD Profiles document for additional NAD configurations and profiles. ... View more

Profile is for HPE_ArubaOS switch that supports dynamic URL redirect, tested with 2920 running16.02. Matching configuration can be found here. Also, see the ISE Third-Party NAD Profiles and Configs document for additional NAD profiles. ... View more

This is list of resources related to using Chromebook on ISE enabled network. Single-Sign-On using 802.1X: Using ChromeOS v66 and above, Chromebook can be configured to reuse login credential for 802.1X authentication. This document describes the steps to configure G-Suite for 802.1X SSO Single-Sign-On using SAML: Using ISE Guest feature with SAML, ISE can map Google user account information to the session on network device even using OPEN or PSK WLAN. This is useful to gain visibility of Google users on the network. ISE BYOD for Chromebook: Using the Native Supplicant Provisioning Wizard Chrome Extension, ISE can issue signed digital certificate to the Chromebook for network authentication. ... View more

  Deploying ISE for Bring Your Own Device (BYOD)   This deployment guide is intended to provide all the relevant design, deployment and operations related guidance to run Cisco Identity Services Engine (ISE) for Bring Your Own Device (BYOD), specifically on the Cisco Unified Wireless Network (CUWN) Controllers.   Hosuk Won  Note June 2018 First version February 2019 Convert pdf to native community document     Table of Contents   Introduction About Cisco Identity Services Engine (ISE) Cisco Identity Services Engine (ISE) is a market leading, identity-based network access control and policy enforcement system. It’s a common policy engine for controlling, endpoint access and network device administration for your enterprise. ISE allows an administrator to centrally control access policies for wired wireless and VPN endpoints in the network.   ISE builds context about the endpoints that include users and groups (Who), device-type (What), access-time (When), access-location (Where), access-type (Wired/Wireless/VPN) (how), threats and vulnerabilities. Through the sharing of vital contextual data with technology partner integrations and the implementation of Cisco TrustSec® policy for software-defined segmentation, Cisco ISE transforms the network from simply a conduit for data into a security enforcer that accelerates the time to detection and time to resolution of network threats.   About this guide This guide is intended to provide technical guidance to design, deploy and operate Cisco Identity Services Engine (ISE) for Bring Your Own Device (BYOD). Special focus will be on the Cisco Unified Wireless Networks controller configurations to handle two BYOD deployment flow; Single-SSID BYOD and Dual-SSID BYOD. The document provides best practice configurations for a typical environment for BYOD use case.   Even though Cisco ISE BYOD supports wired access use cases, this guide does not cover BYOD flow via wired connection.   The first half of the document focusses on the planning and design activities, the other half goes in to the specifics of configurations and operations.     There are four major sections in this document. The initial, define part talks about defining the problem area, planning for deployment, and other considerations. Next, in the design section, we will see how to design for BYOD. Third, in the deploy part, the various configuration and best practice guidance will be provided. Lastly, in the operate section, we will learn how to manage BYOD controlled by Cisco ISE   Define Define your BYOD requirements If you are reading this document, you have already decided to allow users to bring in personal devices or possibly looking into allowing personal devices. The consensus is that BYOD increases productivity of the users as they do not need to be provisioned with additional devices for internal network access. Before we dive into the details of ISE BYOD, let’s discuss what BYOD is. BYOD as the term states is about bringing in and connecting personal devices to the managed network. Now, this is simple enough concept, but the ‘connecting’ part can have many different meanings for many different customers. For some it could simply mean connecting to the guest network to access the Internet, for others it could mean providing access to internal resources as well as the Internet, and yet for others it could mean provisioning digital certificates and MDM agent and provide network admin some control over the devices and also providing access to the internal resources not available to guest users. So as you can see, there may be different goals of BYOD based on the customer. However, before allowing personal devices on the network, it is important to define what the requirements are for BYOD access. Requirements may include, who will be allowed to bring in personal devices and how technically savvy the users are, which level of access will be given to BYOD, what types of devices will be allowed to be connected, how are you going to onboard the endpoint devices on to the network to ensure the endpoints are securely configured? The following provides guidance on the requirements:   Users   Who should be able to bring in personal devices and gain network access? For a user access network, generally there will be employee users, contractors, and guest users. For a typical BYOD use cases, BYOD is allowed for employee users and potentially for contractor users. Further control is possible by allowing BYOD for certain set of users based on user groups if necessary. When users are bringing in personal devices, what is the role of the admin users?   Devices   What types of devices are allowed to the network as part of BYOD? Are these user devices, where user can interactively configure the devices such as PC or mobile devices? Or are the devices headless devices, where there are no user interface (UI) such as IoT devices? Does the device support 802.1X or only PSK? Are the devices personal devices or are you going to consider corporate owned devices as BYOD? How many devices will be allowed to be tied to a single user needs to be considered as well.   Access Control   Compared to managed devices, generally organizations lack control for BYOD endpoints. Due to lack of control, BYOD endpoints cannot be confirmed to be compliant before granting access whereas managed devices can be trusted to have certain elements such as anti-malware, MDM, hotfix, etc. Due to lack of control, administrators may limit BYOD endpoints to Internet only access or to certain set of web based applications. The access control can be achieved by assigning different permissions in the form of ACL, VLAN, or SGT.   Onboarding   Depending on the customer requirement, BYOD may simple as allowing personal endpoints connect to the network without automated onboarding process. Which assumes the end user is responsible for configuration of the endpoint to connect and gain network access. For many organizations, this level of BYOD may meet their requirement. However, the benefit of ISE BYOD flow is that ISE can assist the end user to onboard their endpoints by provisioning CA signed endpoint certificate as well as configure the network interface and OS native supplicant to utilize the provisioned certificate for network access. The other benefit of ISE BYOD is the ‘My Devices Porta’, which allows end users to Create/Read/Update/Delete (CRUD) on endpoints that they own.   Solution deployment considerations   As mentioned earlier, there are different ways to onboard endpoints to the network. One way is to simply let users connect their personal devices to the existing guest or internal network, where endpoint simply gets Internet only access or in the case of internal network, the endpoint will gain same level access as managed devices. The other end of the spectrum is where endpoint is onboarded via ISE BYOD flow. When ISE BYOD onboards the endpoint, ISE can issue Certificate Authority (CA) signed certificate as well as automatically configure endpoint network settings to use the endpoint certificate that has been signed to gain network access. At the same time, ISE can mark the device as BYOD endpoint and also tie the endpoint with the user. Furthermore, the end user can logon to the ISE my devices portal to manage the endpoint that he/she owns without the need of involvement from IT team.   When it comes to ISE BYOD, there are two distinct ways to design the user experience flows; Single SSID BYOD and Dual SSID BYOD flow. If the goal is to minimize number of SSIDs, there are no separate guest WLAN, or if the guest access is using hotspot access (rather than named guest account access) then single-SSID BYOD is recommended as the open SSID using hotspot portal cannot be used for initial BYOD portal at the same time. With Single-SSID BYOD, the endpoint associates to a secure WLAN gets onboarded then after the endpoint automatically reconnects the endpoint is granted full network access via same WLAN.   If guest access is utilizing one of the named guest account, then same guest portal can be used for employee BYOD portal. This flow is called Dual-SSID BYOD, where the endpoint is associated to a provisioning WLAN which is typically shared with guest access. When the ISE confirms that the user is an employee user, then ISE will direct the user to the BYOD flow where the endpoint gets onboarded. Once provisioned with the WLAN settings and possibly CA signed certificate, then the endpoint is reconnected to the secured WLAN for full network access.   Endpoint Onboarding When leveraging ISE for BYOD, there are few actions that the endpoint needs to perform, which includes starting the communication with proper ISE node via the BYOD portal, creating digital certificate pairs, submitting certificate signing request, and configuring network profile. Some O/S has provisions for such functions natively while others require downloading and running an application temporarily to assist with the flow. Aside from Apple mobile devices (iOS), ISE leverages Network Setup Assistant (NSA or AKA Supplicant Provisioning Wizard (SPW)) to ease the BYOD flow for the users. NSA is an application that is downloaded to the endpoint either from the ISE itself or from app store for each of the endpoint types. NSA assists the user to generate certificate pair, install signed certificate, and configure network and proxy settings on the endpoint.   Windows OS & macOS   For Windows and macOS, the NSA is located on the ISE PSN itself. When the endpoint goes through onboarding flow, ISE instructs the user to download and install NSA, which in turn guides the user through the BYOD process. Since there are newer version of Windows and macOS that are introduced to the market, admin user will need to update the NSA on the ISE periodically to assure support for newer OS.   Apple mobile devices (iOS)   The way Apple iOS work is different from other OS in that it doesn’t require ISE NSA application for BYOD flow. Rather ISE will leverage iOS’ existing capabilities (Apple Over-the-air (OTA)) to generate key pair, install signed certificate, and configure WiFi settings. Even though ISE is leveraging OTA, iOS gets instructions from ISE in the form of profiles which gets installed on the iOS. As there are no applications to download, iOS can be onboarded without access to the Apple App store.   Android devices   For Android devices, ISE will force installation of NSA during the onboarding flow if it is not installed already. NSA assists the user to generate key pair, install signed certificate, and configure WiFi settings. Since Android devices download applications from Google Play store, the temporary ACL assigned during onboarding flow needs to be modified to allow such access. Since it is not practical to use IP address based ACL to allow access to play store, it is recommended to utilize DNS ACL on the NAD to allow access. This ensures that access to play store is allowed even when there are IP changes for services related to play store access. Aside from allowing access to the play store, it is also recommended to guide users to pre-download the NSA via other means such as cellular network or different WLAN to simplify the onboarding process when the endpoint is connected to the network.     Chromebooks BYOD flow on Chromebook devices is different from other OS. Unlike other OS where there is no requirement for the endpoints to be pre-registered, the Chromebook devices needs to be enrolled to the Google-Suite before it can go through the ISE BYOD flow. The G-Suite admin needs to configure Chromebook policy on the G-Suite to force installation of NSA Chrome extension. Also, G-Suite admin needs to configure WiFi settings on the Google admin console. This is different from other OS where they get network settings pushed from the ISE directly. Just like Android devices, Chromebook requires the endpoint to have access to the Google resources for BYOD flow to work. The temporary ACL assigned during onboarding flow needs to be modified to allow such access. Since it is not practical to use IP address based ACL to allow access to play store, it is recommended to utilize DNS ACL on the NAD to allow access. This ensures that access to the G-Suite resources is allowed even when there are IP changes for services related to play store access   Unsupported endpoints As noted above, ISE supports Windows, macOS, iOS, Android, and Chromebooks for BYOD flow. For other OSes, ISE global settings can be toggled to determine what access will be given to unsupported devices. You can dictate what level of access will be given in the case of unsupported devices using policy or unconditionally provide network access. Another option is to manually onboard devices by issuing certificates from certificate portal and enabling network settings to connect to the network. You can further secure the network by forcing endpoints to be registered to the ISE by using my devices portal. Lastly, if dual SSID BYOD flow is used, you can provide option to allow Internet only access if user chooses not to go through the BYOD flow.   Following summarizes characteristics of different endpoints going through ISE BYOD flow: Endpoint Characteristics MS Windows NSA located on ISE PSN node Latest NSA can be downloaded to ISE from ISE GUI Can use ECC certificate (Windows 8+) As part of onboarding flow following settings can be configured: - Both wireless and wired interface - Web proxy settings Can configure user, machine, or both for identity Apple macOS NSA located on ISE PSN node Latest NSA can be downloaded to ISE from ISE GUI Also supports EAP-FAST As part of onboarding flow following settings can be configured: - Both wireless and wired interface - Web proxy settings Apple iOS Use iOS native capability (Over-the-Air (OTA)) instead of NSA With iOS 11+, and self-signed identity certificate is used for ISE admin GUI, then ISE identity certificate must be explicitly trusted before BYOD flow can complete Also supports EAP-FAST Web proxy settings can be configured along with wireless profile Newer iOS may not work if the Top Level Domain (TLD) of the FQDN is not a valid one such as .local. Google Android NSA located in the Google Play Store The NSA needs to be pre-downloaded or the Play Store needs to be accessible during the BYOD flow Can use ECC certificate (Android 4.4+) Google Chromebook NSA located in the G-Suite Chrome extension Chromebook needs to be managed devices G-Suite app policy needs to be configured to force NSA extension to be pre-installed Other OS In the case of dual-SSID flow, BYOD portal can be configured to allow guest access if employee does not want to go through the BYOD flow ISE Policy can be used to allow devices based on profiling Global setting can be configured to allow network access unconditionally My Devices Portal can be used to allow endpoints without 802.1X capability to connect Certificate provisioning portal can be used to issue certificates for added security, however configuration of endpoint network settings to use certificate is manual process   Password vs. Digital certificate While ISE supports various EAP types for 802.1X authentication, with ISE BYOD, there are three EAP Types that can be used; EAP-TLS, EAP-PEAP-MSCHAPv2, and EAP-FAST. With EAP-TLS ISE identifies itself by providing EAP Identity certificate to the endpoint, once the ISE identity certificate is validated by the endpoint, the endpoint will provide its own endpoint identity certificate that was previously signed by ISE. Once ISE confirms its validity, then the endpoint is authorized on to the network. With EAP-PEAP-MSCHAPv2, ISE identifies itself by providing EAP Identity certificate to the endpoint, once the ISE identity certificate is validated by the endpoint, the endpoint provides a combination of username and password that ISE can authenticate. Once ISE validates the user, then the endpoint is authorized to the network. In both EAP types, first ISE provides its own certificate to the endpoint and the main difference is whether the endpoint provides a digital certificate or username/password. ISE supports both endpoint identity, but it is recommended to use endpoint certificates for better security and manageability.   Password (EAP-PEAP-MSCHAPv2 & EAP-FAST) Digital Certificate (EAP-TLS) Pros Simple to use Certificates are generally valid for longer period than passwords Added security as the certificate is purpose built for BYOD only ISE BYOD certificates are tied to the endpoint MAC address Cons Generally, passwords are required to be changed every X number of days. When the password has been changed, user has to manually change it on all endpoints in short periods of time to avoid connectivity issues. May need to consider integration with enterprise PKI for better BYOD user experience     Network Access Device   ISE BYOD is supported on wireless and wired networks regardless of network device vendor. However, depending on the feature set available on the NAD, deployment may be easier for devices that supports standards based features. For instance, Cisco WLC supports standards based CoA and RADIUS based URL-redirect as well as DNS ACLs, all of which makes it easy to deploy ISE BYOD. Furthermore, Cisco WLC is supported by ISE Secure Access Wizard, where ISE can configure the WLC and ISE policies for BYOD user cases. In the case of other network devices that lacks certain features, ISE can still support BYOD flow by leveraging 3 rd party NAD support. ISE can be configured to leverage WebAuth capabilities built into the 3 rd party NAD for BYOD. And for switches that lacks CoA and WebAuth, ISE can be configured to provide redirection using DNS Sink-holing. Please note that while ISE supports Cisco switches and 3 rd party NAD for BYOD, this document will focus on BYOD deployment on Cisco WLC platform only. Following table describes required NAD feature and in case of 3 rd party devices which lacks the feature, how ISE 3 rd party NAD feature can still support the network devices.   NAD Feature Description ISE 3 rd party NAD feature URL-Redirect This allows endpoints to be redirected to a web portal when the user opens up a browser on the endpoint. This is essential to the ISE BYOD as ISE needs to interact with the end user to guide through the process. There are two main components of URL-Redirect. First is the ACL which dictates what traffic will be allowed without being redirected or not and the second is the URL destination to direct the web traffic to when the traffic is denied. Also, there are two distinct ways to perform URL-Redirect: - Dynamic URL-Redirect: When an endpoint is authenticated via RADIUS, ISE can send back a name of ACL and Destination URL as part of RADIUS response. Most of Cisco devices and limited number of 3 rd party NAD supports this method - Static URL-Redirect: The URL destination and the ACL is predefined on the NAD as static configuration. This is common method of URL-Redirect in most of 3 rd party NAD In the case of NAD without URL-Redirect feature, ISE can be configured to provide URL-Redirect using DNS-Sinkholing. With DNS-Sinkholing, any web request destinations are re-written with ISE IP address, where ISE can provide web portal CoA Change of Authorization is essential to BYOD as it provides ways to transition from limited access during pre-onboarding to full access once onboarding is complete. ISE has two different ways to provide CoA: - RADIUS Based CoA: This is using RADIUS to communicate between ISE and the NAD - SNMP Based CoA: For some 3 rd party NAD that does not support RADIUS based CoA, ISE can use SNMP to change the access. This is done by ISE issuing SNMP Write command to the NAD for the interface to shut down the interface and immediately bring it back up. As the interface is brought back up, ISE can assign different permissions to the interface ISE SNMP CoA still requires MAB configured and functional on the interface. DNS based ACLs Google Android and Chromebook requires access to NSA which is located in the cloud. NSA can be preinstalled, but if required to download NSA during the onboarding flow, then the ACL need to be modified to allow access to cloud resources. Cisco WLC running 7.6 (8.2 and above supports up to 20 DNS entries per ACL, while older versions supports 10 entries) and up has feature to craft ACL based on FQDN Some 3 rd party NDA supports DNS based ACLs, for others without the feature, ISE DNS-Sinkholing can be used to provide the feature.     Digital Certificates ISE relies on digital certificates for various aspects of the solution. As noted above, ISE utilizes certificates to identify itself to the endpoints for EAP, but it also uses certificates to identity itself for web portals. In some cases, the EAP identity certificate and web portal certificate could be different, but in many cases, it could be using the same certificate for both to save on management cost. This is especially true when the certificate is signed by well-known Certificate Authority (CA). One of the main benefit of ISE BYOD is that ISE can provide signed certificate for the endpoints as part of the BYOD flow. For endpoint certificates, ISE can utilize internal CA to issue signed certificates. ISE is already enabled with internal PKI which can be integrated with customer’s existing PKI infrastructure and also provide web portal to manage endpoint certificates. Here are characteristics of ISE Internal CA: - Generally used for BYOD - Can also be used for other purposes such as to secure pxGrid communication - Full certificate lifecycle management including multiple templates, expiry, revocation (OCSP) - Supports validity dates up to 10 years for endpoint certificates - Supports up to 1 million certificates   Integration with MDM/EMM ISE can leverage MDM/EMM to check posture of the mobile endpoints prior to providing full network access. ISE itself doesn’t provide native MDM/EMM capabilities such as checking for pin lock, encryption, jail broken status, but as endpoints connect to the network ISE can reference the MDM/EMM system to see if the endpoint is compliant. If compliant ISE can provide full network access, however, if the endpoint is not registered with MDM/EMM or is not compliant, ISE can guide the end user to address the issue without having to involve IT. When My Devices Portal is used in conjunction with MSM/EMM, the portal allows end user to issue MDM/EMM commands such as remote lock, remote wipe, corporate wipe, etc. Also, if endpoints are managed via MDM/EMM, some of the MDM/EMM vendors can issue certificates as well as configure network settings without the need of ISE BYOD. If using MDM/EMM for certificate provisioning and network configuration, ISE can be configured to trust MDM/EMM signed endpoint certificate for better user experience. Following is sample of MDM attributes ISE can look up for an endpoint during authorization: MDM Attribute Description DaysSinceLastCheckin How many days elapsed from last MDM check for particular endpoint DeviceCompliantStatus Attribute validate that complaint status been confirmed by MDM server for particular endpoint DeviceRegisterStatus Endpoint is known to MDM server and been previously registered DiskEncryptionStatus Disk encryption is not enabled on the endpoint IMEI IMEI value. Match based on endpoint IMEI value from MDM server response JailBrokenStatus Match endpoint status JailBroken based on MDM server response Manufacturer Manufacturer name. Match based on mobile device manufacturer name from MDM server response MDMFailureReason FailureReason value MDMServerName Match based on MDMServerName from endpoint attributes MDMServerReachable Match reachable status of MDM server MEID MEID Value. Match based on endpoint mobile equipment identifier(MEID) value from MDM server response Model Model Value. Match based on mobile device model from MDM server response OsVersion OsVersion Value. Match based on mobile device OS version from MDM server response PhoneNumber PhoneNumber Value. Match based on phone number of mobile device PinLockStatus Pinlock disabled on endpoint SerialNumber SerialNumber Value. Match based on mobile device serial number from MDM server response ServerType Server on which endpoint registered belongs to Desktop Device Manager type (ex: Microsoft System Center) or Mobile Device Manager type (regular MDM server) UDID UDID Value. Match based on Unique Device Identifier (Apple specific) UserNotified User has not been notified previously about requirement to register device (Desktop Device Manager specific check)   Please note that this document will not cover the integration of ISE with MDM/EMM.       Design Single vs. Dual SSID Flow As noted earlier there are two BYOD flows. Here we will compare the two BYOD flows. First let’s look at the flow of Single SSID flow: As its name signifies there is only one SSID used for the onboarding, which is secured by 802.1X. User initially connects using username/password and is registered then optionally can get a signed endpoint certificate issued to the endpoint which is used to reconnect to the same SSID and gets elevated access.   Now let’s look at the dual SSID flow: In the case of dual-SSID flow, user initially starts on one SSID which may be shared with guest access. But once onboarded, the endpoint is reconnected to the secured SSID to gain elevated access. The initial SSID may be secured via WPA-PSK if the WLC supports WPA-PSK and ISE-NAC (RADIUS-NAC on the same WLAN).   Note that when guest portal is used for BYOD flow, all employee users will go through the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal can be used based on authorization condition. This flow allows, for instance, different user groups to have different BYOD portal and also allows each groups to register the devices into different endpoint groups.   Note that in either flow, once the devices have been onboarded, there is no difference in terms of the access to the secured network. Here are pros and cons of the different BYOD flows:   Single SSID Dual SSID Dual SSID w/ differentiated BYOD portal Pros User experience is better for iOS users as SSID switching from OPEN to SECURED does not require user intervention This is a unique capability of ISE where competitor solution forces user to login twice while ISE can take user information from 802.1X session without asking for the user to login again to the web portal Can provide different BYOD portal based on authorization condition. BYOD portal can be tied to different endpoint group for registration. Some organizations prefer having a dedicated SSID for on-boarding devices. Can provide visible guidance to the user on the BYOD process before logging in Better security: User can confirm that the BYOD server is legitimate as the user does not get prompted to manually trust the EAP certificate ID Store is LDAP and cannot start with PEAP with MSCHAPv2 currently to LDAP store Wired deployment where cannot assume client already has 802.1X enabled on wired interface Can be configured to use secured SSID that is not broadcasting In the case of dual-SSID flow, BYOD portal can be configured to allow guest access if employee does not want to go through the BYOD flow Some organizations prefer having a dedicated SSID for on-boarding devices. Can provide visible guidance to the user on the BYOD process before logging in Better security: User can confirm that the BYOD server is legitimate as the user does not get prompted to manually trust the EAP certificate ID Store is LDAP and cannot start with PEAP with MSCHAPv2 currently to LDAP store Wired deployment where cannot assume client already has 802.1X enabled on wired interface Can be configured to use secured SSID that is not broadcasting Can provide different BYOD portal based on authorization condition. BYOD portal can be tied to different endpoint groups for registration. Cons Fast-SSID change setting needs to be enabled on the WLC to accommodate iOS devices When end users connect to the SSID for the first time there is no easy way to validate whether server provided certificate is from the trusted source Others see dual SSID as an extra management burden. A second SSID adds channel overhead and may degrade wireless performance Requires iOS users to manually switch SSID Pre-authentication ACL is shared between guest and employee users Others see dual SSID as an extra management burden. A second SSID adds channel overhead and may degrade wireless performance Requires iOS users to manually switch SSID Some client OS may have issues with multiple redirects     PKI and ISE Internal CA Although issuing signed certificates to the endpoints for BYOD is optional, many customers will consider issuing certificates to the endpoints as it provides better security and user experience for subsequent connections. When ISE is installed the internal CA is installed and enabled by default. Here are the characteristics of ISE internal CA. - Primary Admin node is the root CA - Both primary and Secondary admin node is also Sub-CA of the root called Node_CA. This added layer of hierarchy allows single root hierarchy which simplifies the deployment when new PSNs are added while the primary node is not the active admin node - PSN runs both CA, RA, and OCSP responder   When ISE is installed, the first node will become a Root_CA. Then each of the Admin node including the first node will become a sub CA of the hierarchy called Node_CA. This added layer of CA hierarchy was done to ensure the ISE BYOD certificate authority is setup with single root. This makes the deployment much simpler as it allows PSNs to be added at a later time regardless of which admin node is up during the addition of PSN. In the below diagram, even though PSN3 was added while S-PAN (Secondary PAN) was active, the certificate hierarchy is still maintained up to the Root-CA. This allows certificates generated by PSN3 to be trusted by the other PSNs without additional work. Also, note that all the nodes run both RA and CA services along with OCSP. Both Registration Authority (RA) and Certificate Authority (CA) is required for ISE to validate requests and issue certificates to the endpoints. Having both services on each node ensures that certificates can be issued autonomously by each PSN. Also, the Online Certificate Status Protocol (OCSP) service confirms whether the certificate is still valid or not and having the OCSP service locally on PSN node ensures all aspects of BYOD operation can be covered by each PSN. Note that ISE Internal CA does not support CRL as OCSP is available for CRL checking.   When it comes to PKI, ISE can be deployed in 3 options. First two leverages the internal CA feature and are mutually exclusive, while the last option simply proxies the signing requests to 3 rd party CA server and can also be enabled along with first or second option.   Self-Signed CA This is the initial state of the ISE BYOD setting. The Internal CA is enabled by default and ready to issue certificates for BYOD endpoints. There are no additional actions to take in terms of setting up the CA. This mode of deployment will be ideal for PoC, pilot, or if the customer intends to separate PKI for BYOD as opposed to having unified PKI for enterprise use and BYOD. With separate PKI, it is easier to assign different permissions for BYOD endpoints vs. enterprise endpoints. Subordinate CA ISE internal CA can be integrated with customer’s existing PKI such as MS CA services. In this mode ISE will be able to sign BYOD certificates that is recognized by other entities that already trusts the existing CA. If this is mode of operations that is desired, then recommendation is to add the initial ISE node as sub-CA of the existing PKI prior to adding secondary ISE nodes to the deployment. SCEP Proxy This is legacy mode of operation, where ISE does not leverage its internal CA, rather ISE forwards the certificate signing request to external CA. Once signed ISE relays the certificate to the endpoint which uses to identify itself. In this mode the management of certificates can only be done with the CA itself. For more information on this mode, please refer to the following guide: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-software/116068-configure-product-00.html   The following table summarizes the 3 ways ISE can issue signed certificates to the endpoint:   SCEP to enterprise CA Sub CA of enterprise PKI ISE Self-Signed CA Pros Provide single point of management for all endpoint certificates; 3 rd party CA console as ISE simply proxies all certificate signing request to 3 rd party CA ISE Internal Certificates need to be re-issued if already deployed as distributed deployment Easiest deployment method. No configuration is necessary. ISE is already enabled with Self-signed CA to use with BYOD endpoints If there is existing PKI, ISE internal CA provides distinction between enterprise CA issued certificates for managed devices, vs. BYOD Cons Most complex deployment mode Only been validated with MS CA (Requires MS enterprise license for SCEP feature) There may be licensing cost with 3 rd party CA for each signed endpoint certificate There may be licensing cost with 3 rd party CA for each signed endpoint certificate Additional effort may be needed to ensure the self-signed CA is trusted on the network.     Captive Network Assistant Apple CNA (Captive Network Assistant, AKA Apple mini browser) is an Apple iOS feature that allows a browser like window to pop-up whenever network access is needed and the CNA determines that the network requires user interaction to gain full network access. This typically happens when the user associates to an open wireless LAN and even though an IP address is provided to the device, the network still restricts the user to take further actions, such as accepting an Acceptable Use Page (AUP), providing a shared password, or logging in as a guest user. This enhances user experience as it saves the user from manually opening up a Safari browser window. It also provides assistance even during non-initial association to the WLAN. For instance, if the endpoint device goes into sleep mode and the session is torn down on the WLC and subsequently the user tries to use a non-web browser application that requires network connectivity, the iOS device can sense that the device is in captive portal state and pop-up the mini browser for user to take further action to gain network access. As one can see having the iOS CNA feature operate on a guest network is a good idea, however, when BYOD is enabled on the same WLAN, as is the case with ISE dual-SSID flow, the CNA breaks the ISE BYOD process. One of the reason for that is due to ISE BYOD process forcing the CNA mini browser to go into the background as it asks the end user to accept the iOS profiles, which includes CA certificate and enrollment package, and when the CNA mini browser is moved to the background it immediately disconnects the device from the WLAN, which in turn breaks the BYOD process.   Prior to ISE 2.2, the ISE was setup to warn the user that the browser is not supported and user had no easy way aside from reporting it to the network administrator and subsequently the administrator had to enable captive bypass on the WLC which disabled the pop-up of the CNA mini browser on the controller level. Unfortunately, the captive bypass feature on WLC 8.3 and below required to be ran controller wide, which meant that all of the WLANs that the controller was servicing disabled the apple CNA. Cisco ISE version 2.2 is the first version to support Dual-SSID BYOD flow through Apple CNA. Here is link to the document that explains how to configure the ISE and Cisco WLC to provide Dual-SSID BYOD even when the captive portal bypass feature is disabled on the WLC https://communities.cisco.com/docs/DOC-71398 For other options on how to deal with Apple CNA, please go to following document: Dealing with Apple CNA (AKA Mini browser) for ISE BYOD https://communities.cisco.com/docs/DOC-71469   DNS ACL For Android device and Chromebook, endpoint OS requires endpoint access to the Google play store and Chrome extensions while going through the ISE BYOD process. This is different from Apple iOS, macOS, and Windows BYOD process. For Apple iOS ISE leverages native OTA capabilities to provision certificates and network settings, and for macOS and Windows ISE provides Network Setup Assistant that is pushed to the endpoint locally from the ISE node which does not require endpoint access beyond the ISE node itself.   To allow the Android devices and Chromebook to download the Network Setup Assistant, the easiest way to get the NSA downloaded to the endpoint is to do it prior to going through the BYOD flow. This can be done out-of-band by notifying users to download it from the play store while connected to the Internet by other means. However, if the endpoint going through the BYOD does not have NSA pre-downloaded, the way to control access to the Google play store and Chrome extension is via DNS ACL feature available on Cisco WLC 7.6 and above. This feature works by snooping the endpoint DNS request from the AP and dynamically inserting IP ACL for the DNS response that endpoint gets from the DNS server. Aside from the WLC version, here are additional notes around this feature: The ACL prepends and appends wildcard which means a string value of .google.co will match play.google.com and also www.google.co.ca Not supported on auto-anchored WLAN WLC AireOS version 8.2 and above can support up to 20 DNS ACE while previous versions can support up to 10 DNS ACE WLC AireOS version 8.7 and above supports DNS-ACL with FlexConnect ACL Not supported on Auto-Anchored WLAN     Deploy To understand configuration needed to make ISE BYOD work, this section is broken down into smaller parts.   First is the Setup part which describes steps needed to configure the WLC and general global BYOD settings on ISE. The major part of the configuration will be in Policy section. ISE utilizes multiple policy to control how authentication and authorization flows, but also for controlling how endpoints are onboarded for BYOD. As such there are two main policies to modify, one is the policy set, which includes both authentication and authorization and the other policy is the Client Provisioning policy which controls which OS is supported for BYOD and how the endpoints will get onboarded as well as how the certificates will be signed. Following table shows the difference between the two policies: Policy Type Description Client Provisioning Policy This is policy to control which BYOD profile will be pushed based on endpoint type or user group. BYOD profile includes certificate template, SSID name, proxy settings, etc. Authentication & Authorization  Policy This is the policy to control which portal will be presented to the user going through the BYOD flow. It also dictates how user will be authenticated and which network or SSID will be forced to go through BYOD. It can also control what to do in the event of expired certificates.   Aside from policies, there are elements that comprises the policy such as Certificate template and Native Supplicant Profile. Certificate template controls how the endpoint certificate will be signed including subject name, key size, and duration. The NSP controls which certificate template to use and how the network setting will be configured on the endpoint, including SSID name, EAP-Type, proxy settings and more.   Lastly, there are two portals that end user can use as part of the ISE BYOD. My devices portal and the certificate provisioning portal. This document will describe where the settings are located for these two portals and show to control access to the portals.   Following diagram shows the relationship between various elements and the two policies.   Configure Network Device This section assumes the Cisco WLC and the network is already setup with basic settings, including management IP, interfaces, and DHCP. This section will go through setting up WLC/ISE communication using RADIUS, relative WLANs, and ACLs. For complete Cisco WLC configuration for ISE please use: https://communities.cisco.com/docs/DOC-68172   Enable fast-ssid-change feature (Optional) This is needed for Dual-SSID flow for better user experience. Enabling this feature allows wireless clients to transition from Open SSID to Secured SSID without delay. In dual SSID flow, if the transition from Open to Secured SSID keeps on failing on the endpoint, then check the following on the WLC settings: Access the WLC GUI and navigate to Controller > General Enable Fast SSID Change Click Apply and Save Configuration   Configure ISE as RADIUS Authentication and Accounting server 1. Go to Security > RADIUS Authentication 2. Click New... on the top-right corner to add a new RADIUS authentication server 3. RADIUS authentication server settings are listed in the table below (Use default value if not specified) Attribute Value or description Server Index (Priority) {Available Index Value} Server IP Address {ISE PSN IP} Shared Secret Format ASCII Shared Secret {Shared RADIUS Key} Port Number 1812 Server Status Enabled Support for RFC 3576 Enabled (This option enabled CoA) Server Timeout 5 (Recommended to use 5 seconds or higher) Network User Disabled (As the RADIUS server is defined in the AAA section of WLAN, this can be disabled globally) Management Disabled   4. Click Apply and Save Configuration. 5. Click Accounting and New... to add RADIUS accounting servers 6. RADIUS accounting server settings are listed in table below (Use default value if not specified) Attribute Value or description Server Index (Priority) {Available Index Value} Server IP Address {ISE PSN IP} Shared Secret Format ASCII Shared Secret {Shared RADIUS Key} Port Number 1813 Server Status Enabled Server Timeout 5 Network User Disabled   7. Click Apply and Save Configuration (If there are multiple ISE PSN nodes, add both RADIUS authentication and accounting for each PSNs)   Create Redirect ACL Single ACL will be created for redirect that applies to both single-SSID flow and dual-SSID flow 1. Go to Security > Access Control Lists > Access Control Lists 2. Click on ‘New’ and create ‘ACL_WEBAUTH_REDIRECT’ ACL with following parameters. The ACL name ‘ACL_WEBAUTH_REDIRECT’ is the default ACL name referenced by ISE, so if using different ACL name on the WLC, make sure to change it on the ISE Authorization profile as well. Note that the WLC ACL is stateless so reverse of the allowed ACE needs to be created. Action Source IP / Mask Dest. IP / Mask Protocol Source Port Dest Port Direction Permit {DNS}/255.255.255.255 0.0.0.0 / 0.0.0.0 UDP DNS Any Outbound Permit 0.0.0.0 / 0.0.0.0 {DNS}/255.255.255.255 UDP Any DNS Inbound Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8443 Any Outbound Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8443 Inbound Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8905 Any Outbound Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8905 Inbound                         Note that this ACL works with ISE 2.4, however older version of ISE may require additional TCP ports to be open. 3. Click ‘Back’ on the top right corner 4. Click down arrow next to the ACL and select ‘Add-Remove ACL’ 5. Here enter following entries one by one .google.co accounts.youtube.com gstatic.com .googleapis.com .appspot.com ggpht.com gvt1.com market.android.com android.pool.ntp.org .googleusercontent.com .google-analytics.com 6. Click Back 7. Click Apply   Create Blacklist ACL Single ACL will be created for Blacklist portal 1. Go to Security > Access Control Lists > Access Control Lists 2. Click on ‘New’ and create ‘BLACKHOLE’ ACL with following parameters. The ACL name ‘BLACKHOLE’ is the default ACL name referenced by ISE, so if using different ACL name on the WLC, make sure to change it on the ISE Authorization profile as well. Note that the WLC ACL is stateless so reverse of the allowed ACE needs to be created. Action Source IP / Mask Dest. IP / Mask Protocol Source Port Dest Port Direction Permit {DNS}/255.255.255.255 0.0.0.0 / 0.0.0.0 UDP DNS Any Outbound Permit 0.0.0.0 / 0.0.0.0 {DNS}/255.255.255.255 UDP Any DNS Inbound Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8444 Any Outbound Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8444 Inbound                         Note that this ACL allows full IP access to the ISE node but can be changed to limit ISE exposure from end users. 3. Click ‘Back’ on the top right corner 4. Click Apply   Secured SSID Go to WLAN Click on Add New and create WLAN with following parameters Tab Attribute Value or description General WLAN ID Available WLAN ID Profile Name / SSID Secured Status Enabled Security Layer 2 Security WPA+WPA2 WPA+WPA2 Parameters WPA2 Policy WPA2 Encryption AES Authentication Key Management 802.1X Layer 3 Captive Network Assistant Bypass Enabled AAA Servers Authentication & Accounting Enabled and ISE PSN nodes selected (If multiple PSNs defined, list them here for both Authentication & Accounting in order) RADIUS Server Accounting Interim Update Enabled, Interim Interval 0 Advanced Allow AAA Override Enabled NAC State ISE NAC (Or RADIUS NAC) RADIUS Client Profiling HTTP & DHCP Enabled     Open SSID (Optional)   If there is an existing guest WLAN, same portal can be used for employee BYOD as well. As employee user logs in to the guest portal ISE recognizes the guest users and employee users and apply different flows. For guest users, ISE automatically applies guest related access. Only named guest access portal such as self-service or sponsored guest portal can be used as employee BYOD portal at the same time. If hotspot guest access is used, then the same portal cannot be used for both hotspot and employee BYOD portal. To create the open WLAN: Go to WLAN Click on Add New and create WLAN with following parameters Tab Attribute Value or description General WLAN ID Available WLAN ID Profile Name / SSID Open Status Enabled Security Layer 2 Security None, MAC Filtering Layer 3 Captive Network Assistant Bypass Enabled AAA Servers Authentication & Accounting Enabled and ISE PSN nodes selected (If multiple PSNs defined, list them here for both Authentication & Accounting in order) RADIUS Server Accounting Interim Update Enabled, Interim Interval 0 Advanced Allow AAA Override Enabled NAC State ISE NAC (Or RADIUS NAC) RADIUS Client Profiling HTTP & DHCP Enabled     Define Network Device Starting with his section, the configurations are for the ISE itself. This document assumes the Cisco ISE is installed and the management IP address is accessible via GUI.   Go to Administration > Network Resources > Network Devices Click on Add Provide Name, IP Check RADIUS Authentication Settings and the section will expand for more options Provide Shared Secret Click Save   Attribute Value Name Name of the NAD IP IP address of the NAD RADIUS Shared Secret Shared secret between ISE and NAD     Define Global settings To Control how many devices that can be registered by each user, go to Work Centers > BYOD > Employee Registered Devices and change the value in the box. The default is 5 devices, but can be set between 1 to 999 devices. Note that this applies to all BYOD users globally.   The Retry URL allows administrator to configure URL that ISE will try to force a new URL-Redirect when the initial onboarding flow failed for any reasons. For instance, if the user abandoned the onboarding flow in the middle and came back, the existing session may have been torn down and the user will need to re-initiate the flow. ISE re-initiates this by forcing the browser to try the retry URL specified in the setting. By default, if the Retry URL is not specified, ISE will try 1.1.1.1 to force a redirect.   By default, devices without NSA support follows the main authorization policy for network access, but to allow network access unconditionally for unsupported devices, select ‘Allow Network Access’ for the ‘Native Supplicant Provisioning Policy Unavailable’ option.   Managing and Defining Certificate Template This is an optional step if EAP-PEAP-MSCHAPv2 or EAP-FAST will be used instead of EAP-TLS. Fresh ISE installation comes with default certificate template called ‘EAP_Authentication_Certificate_Template’, which is used when signing certificates during BYOD flow. Subject content can be populated to reflect the customer’s environment but also note that the content within the subject can be used during authorization to assign different permissions. For instance, two separate certificate template can be created for two different Organization Unit and used to provision certificates to two different OU. When the BYOD devices connect back after being onboarded, ISE can use the OU to differentiate and assign different ACLs or VLANs.   Existing certificate template should work for most environment, but it is recommended to change the subject attributes to reflect the site that ISE is being deployed at. Additionally, the certificate properties such as key type, key size, and valid period can be changed with the template as well. To change the CN (organization, organization unit, city, state, and country) and other certificate properties, follow the steps below.   Go to Administration > System > Certificates > Certificate Authority > Certificate Templates Click on Add (Or Edit to edit default ‘EAP_Authentication_Certificate_Template’) Enter Site specific information in the Subject fields. CN field is auto populated by ISE with the user ID of the user going through the BYOD process ISE also auto populates endpoint MAC address in to the certificate SAN field. The endpoint MAC address is collected during initial authentication of the endpoint either via MAB or 802.1X and embedded in to the certificate for security purpose. By doing so, ISE policy can be crafted to match the actual endpoint MAC address and the certificate MAC address to prevent BYOD issued certificates from being used for other endpoint other than the one that was issued for. The template also allows settings to change Key Types (RSA & ECC), Key Size, and Valid Period. Valid period for the certificates can be changed from default of 2 years to maximum of 10 years. Note that newer client OS requires key size of 2048 or bigger   Attribute Value Name Name of the Certificate Template. Provide descriptive name as this field can be used as AuthC/Z condition Subject CN is auto populated with the username that is going through the BYOD flow. Other attributes can be entered here to reflect the site. If differentiating different endpoint or users based on certificate is needed, then any of the attributes here can be changed and can be used during AuthZ to provide differentiated access. For instance if OU=HR, the endpoint can have access to HR resources, while other endpoints cannot access HR resources Subject Alternative Name (SAN) Currently, only value available is the MAC Address. The MAC Address is pulled from the RADIUS session from the endpoint that initiated the BYOD flow. This is one way ISE allows admin user to tie the certificate to the actual endpoint that it was signed for. Key Type RSA or ECC. ECC is currently supported by Windows and Android devices only. Key Size 1024, 2048, 4096. For compatibility, recommended minimum value is 2048. SCEP RA Profile ISE Internal CA. If using SCEP to 3 rd party CA, then this setting can be changed to send certificate signing request to 3 rd party CA Valid Period 1 days to 10 years. Classic case of security vs. convenience. Extended Key Usage For the BYOD use, only Client Authentication option needs to be checked   Defining BYOD Profiles and Resources Here you can manage Windows and macOS Network Setup Assistant (NSA) and also compile Native Supplicant Profile (NSP). There are two predefined NSP; one for Chromebook and another shared among all other supported OS. With Chromebook much of the network settings are pushed via G-Suite, so only setting to change within the NSP is which certificate template is to be used. For other OS, multiple wireless profiles can be automatically defined and created for any WLANs. Within the Wireless setting, proxy settings, WPA settings, EAP type, and certificate template.   Native Supplicant Profile (NSP) controls certificate signing template, Wireless settings, proxy settings, EAP type, and Wired network settings. At minimum, existing Native Supplicant Profile (NSP) needs to be modified to reflect the SSID name of the secured WLAN that is used. Follow the steps below to make changes to the existing NSP or create a new NSP. If creating new NSP, then the Client provisioning policy needs to be modified to use the newly created NSP. Go to Policy > Policy Elements > Results > Client Provisioning > Resources Edit Cisco-ISE-NSP (Or Add > Native Supplicant Profile) If editing default NSP, there is existing SSID ‘ISE’, which can be edited for the secure SSID used on site. Edit the default SSID by checking it and clicking on Edit Change SSID Name (Optional) Configure proxy related settings Recommended to leave Security to WPA2 Enterprise For Allowed Protocol, select among TLS (For digital certificate), PEAP (For username & Password), or EAP-FAST (For macOS and iOS). Note that if TLS is used, certificate template needs to be selected as well. Expand Optional Settings can be used to configure additional settings: For Windows endpoints, use of machine or user store for certificate settings SSID broadcast settings can be set here For iOS devices, SSID broadcast settings can be set here Click Save If Wired interface is to be used, then ‘Wired Profile’ check box can be enabled for Windows and macOS   Within the same page, updated version of NSA for Windows and macOS can be downloaded. To download latest NSA, follow the directions here: Click on Add > Agent Resources from Cisco site After screen refreshes there will be list of available agents that can be downloaded from Cisco site. This includes NSA as well as posture agents (If the ISE node does not have access to the Internet, this page will not be able to download the NSA, in that case, download the NSA manually from cisco.com and add them manually by using Add > Agent Resources from local disk). Select latest version of MaxOsXSPWizard x.x.x.x and WinSPWizard x.x.x.x. Click Save Once downloaded, the newly downloaded NSA can be used in Client Provisioning Policy   Manage Client Provisioning policy Client Provisioning policy dictates what OS will be supported and which NSP will be used. Designation of NSP also controls which certificate template will be used to sign endpoint certificates. Also, if new NSA has been downloaded, Client Provisioning policy can be updated to reflect which NSA will be used to assist user to onboard the device. This may be necessary when new version of endpoint OS have been introduced to the market. Lastly, note that this same policy also affects posture client provisioning as well, which controls which type of posture agent and compliance module will be enforced. Although two different client settings are present in a single rule, ISE can enforce different client settings based on the flow. The top portion titled ‘Agent Configuration’ controls posture agent for the rule, while the bottom portion titled ‘Native Supplicant Configuration’ controls settings for the BYOD provisioning. Following shows default Client Provisioning policy on newly installed ISE 2.4 system which includes policy rule for ISE supported OS.     In general, the existing client provisioning policy should work for most environments, however, if new NSA for Windows or macOS has been downloaded, then the client provisioning policy will need to be updated to reflect the change. Also, if different native supplicant profile other than the system provided one is used, then the client provisioning policy needs to be updated to reflect the change. Lastly, if separate NSP is required for certain set of users, ‘Other Conditions’ can be modified to match certain user groups to specific NSP. To create new Client Provisioning rule: 1. Go to Policy > Client Provisioning 2. All of the OS policies are already predefined, however, if new policy is needed click on the down arrow on the right of any rule and select ‘Insert new policy …’ (Note that the policy works top down, so if there are more specific rule that needs to be matched, ensure that the new rule is on top of other rules) 3. Provide Rule name 4. If specific rule should match on certain internal user or endpoint group, it can be specified here 5. Select Operating Systems. If specific version of Windows or macOS needs to specified, then it can be specified here 6. Use Other Conditions to further qualify policy rule. AD groups/attributes, location, EAP-Types, etc. can be used here. 7. Result section dictates version of NSA and NSP. Note that version is only available if Windows and macOS is selected for the Operating Systems as these two OS downloads NSP directly from PSN, while other OS relies on native capability or from cloud resources.   Creating policy for Single-SSID BYOD flow When ISE is installed, there are set of AuthZ policy rules that are pre-created for BYOD flow. Although the policy rules are in place, the rules are deactivated. Admin user can simply enable the two rules to activate BYOD policy. The two rules are ‘Employee_EAP-TLS’ and ‘Employee_Onboarding’.   When the user connects to the secured SSID using username and password, the user’s endpoint does not have digital certificate, so the session will match ‘Employee_Onboarding’ policy rule which forces the endpoint to be onboarded. As the endpoint goes through onboarding flow, the endpoint MAC address is registered to ISE and the signed certificate is provisioned to the endpoint, at that point the endpoint will be forced to reauthenticate to the same SSID where the session will match ‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess permission.       Although pre-configured policy rules work for simple deployments, when setting up ISE Authentication and Authorization policies, it is recommended to create separate policy set for each SSIDs. By doing so the policies are much easier to view and predictable. Here we are going to create a policy set for Secured SSID used for single-SSID BYOD flow. Initially the endpoints associate to the SSID using username & password using PEAP-MSCHAPv2. When user opens up a web browser, instead of getting to the user’s browser destination or home page, the user will get redirected to BYOD portal where the user is guided to follow steps to get the endpoint onboarded.   Go to Policy > Policy Sets Click on ‘+’ Change the new policy set name to ‘Secured SSID’ In the conditions use ‘Normalized RADIUS : SSID ends with SECURED’ Click on Use Select Default Network Access for Allowed Protocols Click Save Click on ‘>’ Click on ‘>’ on Authorization policy Click ‘x’ on Deny Access on Results:Profiles Column Select NSP_Onboard Click ‘+’ above default rule Change name to ‘TLS’ Click on ‘+’ In the conditions use ‘Network Access:EAPAUthentication equals EAP-TLS’ (Other conditions such as matching on certificate SAN with the MAC address learned from RADIUS session as well as BYOD registered status can be used here as well) For Results:Profiles Column select PermitAccess Click Save   Creating policy for Dual-SSID BYOD flow  As with the Single SSID flow, also for dual SSID, when ISE is installed, there are set of AuthZ policy rules that are pre-created for BYOD flow. Although the policy rules are in place, the rules are deactivated. Admin user can simply enable the two rules to activate BYOD policy. The two rules are ‘Employee_EAP-TLS’ and ‘WiFi_Redirected_to_Guest_Login’. The ‘WiFi_Redirected_to_Guest_Login’ rule is also used for general self-service named guest access.   If self-service guest service is not needed, then it can be disabled from the guest portal settings. This can be done by going to the guest portal in use for BYOD purpose and unchecking the ‘Allow guest to create accounts’ option.   To make guest portal also support employee BYOD, the BYOD setting on the portal needs to be modified. Go to the guest portal and expand ‘BYOD Settings’, then check ‘Allow employees to use personal devices on the network’ option. Notice that as soon as this option is checked the contextual guest flow diagram on the right reflects the change. The ‘Allow employees to choose to guest access only’ option allows the employees to bypass the BYOD process and opt to get guest access only.   Note that when guest portal is used for BYOD flow, all employee users will go through the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal can be used based on authorization condition. Instructions on how to configure the flow is shown in the appendix.   In the case of dual SSID BYOD, when the user connects to the open SSID, the endpoint is unconditionally authorized to limited network access which provide enough access to get to ISE guest portal. This is done by using advanced authentication options for MAB to ‘CONTINUE’ even when user is not found. The ‘CONTINUE’ option in the Authentication policy allows unknown MAC addresses to bypass authentication and get conditionally authorized to limited access where the endpoint can reach the ISE portal page for web login. This allows the user to open up the web browser, and the user is redirected to the guest portal. When the user logs in using username and password, ISE identifies the user as employee as the account used to login to the portal is not in the guest user database, which forces the user to BYOD portal instead of guest access.   As the endpoint goes through onboarding flow, the endpoint MAC address is registered to ISE and the signed certificate is provisioned to the endpoint, at that point the endpoint will be forced to reconnect to the secured SSID where the session will match ‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess permission.   If not using default policy set, then following instructions can be used. Here we are going to create a policy set for Open SSID used for dual-SSID BYOD flow. Initially the endpoints associate to the Open SSID. When user opens up a web browser, instead of getting to the user’s browser destination, the user will get redirected to guest portal. When user enters credential for employees to the guest portal the user is guided to follow steps to get the endpoint onboarded. The ISE can differentiate between the employees and guests by identifying the identity store that is being used at the time of authentication. Since the endpoint will connect to the secured SSID after the onboarding is complete, the steps for single-SSID flow needs to be completed. Also note that the BYOD portal has no bearing when using dual-SSID flow as the BYOD flow is subset of the main guest portal.   Go to the Guest portal that is currently referenced by ‘Cisco WebAuth’ Authorization profile (If this is fresh install of ISE, then it should be ‘Self-Registered Guest Portal (Default)’) Go to Work Centers > Guest Access > Portals & Components > Guest Portals Click on Self-Registered Guest Portal (default) Scroll down to BYOD Settings and click > to expand Click ‘Allow employees to use personal devices on the network’ Scroll up and click ‘Save’ Go to Policy > Policy Sets Click on ‘+’ Change the new policy set name to ‘Open SSID’ In the conditions use ‘Normalized RADIUS : SSID ends with OPEN’ Click on Use Select Default Network Access for Allowed Protocols Click Save Click on ‘>’ Click on ‘>’ on Authentication policy On the ‘Use’ column, select Internal Endpoints instead of All_User_ID_Stores Click on ‘> Options’ Change If User Not found from REJECT to CONTINUE (Setting this as CONTINUE allows ISE to unconditionally authenticate the unknown MAC addresses so the session can continue through the Authorization instead of getting instant REJECT. This is essential to make the flow work as most of the endpoints connecting to the Open SSID will be initially unknown to ISE and yet, ISE needs to be able to assign limited network access so user can be directed to the ISE portal page) Click on ‘>’ on Authorization policy Click ‘x’ on Deny Access on Results:Profiles Column Select Cisco WebAuth Click Save (In real deployment if the same portal is used for guest users then we would be creating the guest access rule as above the default rule)   Note about different ISE portals So far the document provided instructions on how to use Guest portal and BYOD portal, however, there are other portals that can be used to provide more control for the end users: Portal Type Config Location Used for Guest Portal Work Center > Guest Access > Portals & Components > Guest Portals User portal that end user goes through for onboarding. This is only used for dual-SSID flow. Existing guest portal can be used for guest and BYOD at the same time, provided that the customer is using named guest access as opposed to hotspot guest access. BYOD Portal Work Center > BYOD > Portals & Components > BYOD Portals Or Administration > Device Portal Management > BYOD User portal that end user goes through for onboarding. This is only used for sing-SSID flow Blacklist Portal Administration > Device Portal Management > Blacklist User portal for users with endpoints in blacklist group. Instead of denying network access for blacklisted devices, it may be useful to provide visual guidance on how to proceed to get the device back on the network when their device is blacklisted. My Devices Portal (MDP) Work Center > BYOD > Portals & Components > My Devices Portals Or Administration > Device Portal Management > My Devices Used for end users to manage their own devices. Here users can view onboarded devices as well as add devices manually. User can also mark devices as stolen or lost which can impact network access. If ISE is integrated with MDM/EMM, user can also issue lock, full wipe, and corporate wipe from the portal. Certificate Provisioning Portal Administration > Device Portal Management > Certificate Provisioning Portal Used for signing and generating certificates manually. Certificates can be signed by importing CSR or certificate pair can be generated from the portal. Access to the portal can be controlled via ID store and groups.   Setting up Blacklist Portal (Optional) The blacklist portal is already setup but note that it runs on different TCP port 8444 compared to the guest or BYOD portal which runs on 8443. Also, the blacklist portal utilizes different ACL on the WLC. The policy for Blacklisted devices is already created and active, but following steps can be used to change the content that users are presented when their devices are blacklisted: Go to Administration > Device Portal Management > Blacklist Click on Blackist Portal (default) Click on Portal Page Customization Page title and the message can be modified Click Save   Note that the policy for blacklist is already setup and enabled on ISE, It still requires the ‘BLACKHOLE’ ACL to be present on the NAD to work.   Setting up My Devices Portal (Optional) The My Devices Portal is hosted on the PSNs and already enabled by default. MDP is typically used for non-guest end users to manage their personal devices. Follow the below steps to reconfigure the behavior of My Devices Portal Go to Work Centers > BYOD > Portals & Components > My Devices Portals Click on My Devices Portal (default) Expand Portal Settings Certificate group tag Fully qualified domain (FQDN) and host names (If FQDN is configured here, the DNS server needs to be updated to point to PSNs as well in order to direct users to the MDP using FQDN. Also, if the portal certificate used is not a wildcard certificate, it should also contain the FQDN as SAN to avoid security popup on the web browser trying to access the portal) Endpoint identity group Authentication method (Currently, there is no way to control access to the MDP based on end user groups from internal ID or AD. In other words, if an ID store is enabled to login to MDP, any user with valid user credential can access the MDP) Scroll up and click on Portal Page Customization Under Pages, click on Manage Device Click on Settings on the right hand preview pane You can select which options are available to end users   Setting up Certificate provisioning portal (Optional)   The Certificate Provisioning Portal is hosted on the PSNs but authorization groups need to be assigned before user can login to the portal. Follow the below steps to reconfigure the behavior of Certificate Provisioning Portal Go to Administration > Device Portal Management > Certificate Provisioning Click on Certificate Provisioning Portal (default) Expand Portal Settings Certificate group tag Authentication method Configure authorized groups Fully qualified domain (FQDN) and host names (If FQDN is configured here, the DNS server needs to be updated to point to PSNs as well in order to direct users to the Certificate Provisioning Portal using FQDN. Also, if the portal certificate used is not a wildcard certificate, it should also contain the FQDN as SAN to avoid security popup on the web browser trying to access the portal)       Operate Review Single-SSID BYOD Flow User experience on iOS Step User Experience Note 1 User connects to the secure SSID and provide valid employee credential to gain network access. Since the RADIUS server is unknown to the endpoint, user is asked to trust the server prior to sending credentials. Although user is associated to the WLAN, user is limited to ISE portal and associated services to get BYOD onboarding flow work. This includes DHCP, DNS, and access G-suite or Google Play store. 2 Once associated to the secure SSID, user opens up the browser and the browser automatically redirects user to the BYOD Portal.   Note: If the pseudo (Apple CNA) browser automatically opens up that means the captive portal bypass feature was not enabled on the WLC or the WLAN. 3 2 nd page of the BYOD portal allows end user to provide device name and description so devices can be identified when multiple devices have been registered by same user. 4 3 rd page of the portal brokers creation of certificate pair and signing. It also automatically configures the network interface or WLAN profile per the settings specified on the ISE NSP as admin user. On iOS, ISE leverages iOS native capability to achieve this and makes user go through series of installing iOS profiles. Depending on the iOS security settings, user may be prompted to enter iOS PIN to trust the downloaded settings and profiles. Note: If self-signed certificate is used, due to XXX, iOS 10.3 and above requires extra steps to trust the ISE certificate. Please see appendix for more information. 5 Once the onboarding is successful, user is sent back to Safari browser. The last page of portal notifies the user that the user has full access now. User can open app or browse to other destination.   ISE Live log 1. Starting from the bottom, the user associates to the SSID 2. The lines with only Endpoint ID represents CoA that was successful. Multiple CoA may be sent depending on the CoA settings to ensure proper endpoint session is assigned 3. Shows the endpoint Authorization Profile transitioned from NSP_Onboard to PermitAccess 4. Top most line indicates the session which combines the RADIUS authentication to the information learned from RADIUS accounting which includes the endpoint IP Address     Review Dual-SSID BYOD Flow User experience on iOS Step User Experience Note 1 User connects to the open SSID and opens up the Safari browser. User is automatically redirected to the guest portal. If the guest portal certificate is not signed by known CA, user may get prompted before proceeding to the guest login page. User provide valid employee credential to the guest portal login. 2 ISE sees that the user is non-guest user and is directed to BYOD flow.       Note that this page shows ‘Guest Portal’ in the title as user is using guest portal for BYOD. This can be changed to another title in the guest portal settings if needed. 3 2 nd page of the BYOD portal allows end user to provide device name and description so devices can be identified when multiple devices have been registered by same user. 4 3 rd page of the portal brokers creation of certificate pair and signing. It also automatically configures the network interface or WLAN profile per the settings specified on the ISE NSP as admin user. On iOS, ISE leverages iOS native capability to achieve this and makes user go through series of installing iOS profiles. Depending on the iOS security settings, user may be prompted to enter iOS PIN to trust the downloaded settings and profiles.   Note: If self-signed certificate is used, due to XXX, iOS 10.3 and above requires extra steps to trust the ISE certificate. Please see appendix for more information. 5 Once the onboarding is successful, user is sent back to Safari browser. The last page of portal notifies the user that the user has to manually change over to the secure SSID by going to settings. This is due to iOS restriction as it does not allow change of SSID automatically. Once connected to the secure SSID, user can open app or browse to other destination.   Note that the manual switchover to secure SSID is only required for iOS devices. Other OS can be switched over automatically.   ISE Live log 1. Starting from the bottom, the user associates to the open SSID, the user is unknown and is identified as the MAC address as the user has not logged in 2. User logs into the guest portal as Employee user 3. The lines with only Endpoint ID represents CoA that was successful. Multiple CoA may be sent depending on the CoA settings to ensure proper endpoint session is assigned 4. Shows the endpoint Authorization Profile transitioned from Cisco_WebAuth to PermitAccess 5. Top most line indicates the session which combines the RADIUS authentication to the information learned from RADIUS accounting which includes the endpoint IP Address    Using self-signed certificate on ISE If the ISE is not using 3 rd party signed certificate, Apple iOS 11 and above does not allow the user to accept the enrollment profile without first trusting the ISE certificate as trusted CA. It is recommended to use ISE certificate that is already signed by well-known CA to avoid getting errors during the BYOD flow. In case the ISE is using the self-signed certificate, user will need to manually trust the certificate in to the trusted root CA within iOS. This is done by going to iOS settings after step 4.   Step User Experience Note 4a During the last step of the flow in either single or dual SSID flow described in the previous steps, instead of succeeding in the provisioning flow, user will get following error page: Profile installation Failed 4b On the iOS click home button, go to Settings > General > About > Certificate Trust Settings. Enable the trust for the certificate as root CA by sliding the option bar to the right and select Continue to accept the changes     4c Click Home button and open Safari and go through the BYOD flow again. This time the flow should be able to complete without the error.       Note: If Retry button does not work, enter an external URL in the address bar to initiate redirect.   If the ISE certificate is signed by well-known 3 rd party CA, and the iOS10+ users are still getting errors, it may be due to CSCvk05778 ‘sISE BYOD with apple devices sends misordered certificate chain’. To address the issue replace the existing ‘USERTrust RSA Certificate Authority’ on the ISE with the one from the following link: https://www.tbs-certificates.co.uk/FAQ/en/racine-USERTrustRSACertificationAuthority.html   Managing devices via My Devices Portal   My Devices Portal (MDP) can be used to manage onboarded devices as well as manually add devices that cannot be onboarded through the NSP flow. Note that there is no policy associated with the MDP, and anyone with account in the valid identity store can log in to the MDP. For instance, if AD is enabled with MDP then anyone with AD credential can login to the MDP to manage endpoints. There are 5 states a device can be set to in the my devices portal   State Status Registered EP has been through BYOD flow(either NSP or MDP) and is currently registered(HAS been seen on the network,  20 minute delay from PENDING  to registered because it is done by MnT) Pending EP has been through BYOD flow(either NSP or MDP) and is currently registered BUT has NOT been seen on the network yet. Not Registered EP hasn't been through BYOD flow(this is the default for every end point in the system) Stolen EP status changed to Stolen by owner or admin. When you identify a device as stolen, the system prevents the device from connecting to the network. Once reinstated, the status will revert to Not Registered status and has to be provisioned before it can connect to the network. For My Devices, device will need to be deleted and re-added. Devices reported as Stolen are assigned to the Blacklist Identity Group. Lost EP status changed to Lost by owner or admin. When you identify a device as lost, when you identify a device as stolen, the system prevents the device from connecting to the network. Once reinstated, the status will revert to previous state prior to reporting as Lost. Devices reported as Lost are assigned to the Blacklist Identity Group.   Manage issued certificates from ISE Admin UI   As noted in the previous section, BYOD issued certificates can be revoked by end user via MDP when the endpoint is marked as stolen. However, as ISE admin user, one can login to the Admin GUI and also manage the endpoint certificates as well as monitor the status of the certificates. To revoke certificates from the admin console, go to Administration > System > Certificates > Certificate Authority > Issued Certificates, select the certificate to be revoked and click Revoke. The revoked certificate cannot be undone and if the endpoint needs to get certificate re-issued, the user has to go through the BYOD flow again. Note that revoked certificates takes 30 days to be removed from ISE GUI.   Managing Expired certificates One of the benefits of using endpoint certificates for BYOD is that it is no longer linked to the username & password which generally has shorter refresh cycle for the passwords. However, certificates are also created with validity dates which may impact endpoint access to the network. In general, it is recommended to provide enough time for life of the endpoint. For instance, for higher educational customers, admin could set validity period of the endpoint certificates to be 4 years to cover the student endpoint for the duration of student enrollment at the school or enterprise may require certificates to be valid for 2 years to match general lifecycle of the mobile device purchase in the market. Too frequent requirement to refresh the BYOD certificate may increase calls to the helpdesk and add to the user frustration. When dealing with expired or near expiry of certificates, ISE provides several options to address the renewal of certificates. 1. Policy condition: As part of authentication ISE can validate how many days are left on the certificate that the endpoint is using. Based on the remaining days, ISE can force end users to renew certificates prior to expiry. There are two conditions that can be used; CERTIFICATE: Days to Expiry & CERTIFICATE: Is Expired. If allowing endpoints with expired certificates to authenticate, it is recommended to always use CERTIFICATE: Is Expired in the authorization rule to limit network access for devices with expired certificates.   2. Authorization profile: Checking ‘Display Certificates Renewal Message’ allows the portal to be used for renewing certificates that the endpoint is using   3. Allowed Protocol: By default, Cisco ISE rejects a request that comes from a device whose certificate has expired. However, you can change this default behavior and configure ISE to process such requests and prompt the user to renew the certificate. EAP-TLS Section in the Allowed Protocols includes option to allow authentication for expired certificate. This option is disabled by default as it is not secure to allow expired certificate, but if there is a need to allow expired certificate to authenticate then this option can be enabled. However, if using this option, be sure to use AuthZ condition in conjunction with this option to limit access for users with expired certificate. Note: Some devices allow you to renew the certificates before and after their expiry. But on Windows devices, you can renew the certificates only before it expires. Apple iOS, Mac OSX, and Android devices allow you to renew the certificates before or after their expiry.   Managing ISE Internal CA You must back up the Cisco ISE CA certificates and keys securely to be able to restore them back on a Secondary Administration Node in case of a PAN failure and you want to promote the Secondary Administration Node to function as the root CA or intermediate CA of an external PKI. The Cisco ISE configuration backup does not include the CA certificates and keys. Instead, you should use the Command Line Interface (CLI) to export the CA certificates and keys to a repository and to import them. The ‘application configure ise’ command includes export and import options to backup and restore CA certificates and keys.   For more information on managing ISE Internal CA, please review following document: 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_0111.html#concept_435C4E3FF56949B1B4D5A0C73671AB22   ISE Reports Although not part of the reports, ISE Live log shows live status of all the authentication requests including the BYOD endpoints. Here one can confirm which policy the endpoint is matching.     You can also control which columns are shown as well. Here different attributes can be enabled or disabled to show or could be dragged in different order as well.   ISE also includes several BYOD related reports that can assist with trouble shooting and to understand statistics on BYOD endpoints. Here is list of BYOD related reports available ISE 2.4.   Report Note External Mobile Device Management Shows the integration between ISE and external MDM. Also shows endpoint status from the ISE without having to login to the external MDM portal. Manual Certificate Provisioning Combined report that tracks: Login activity Manual certificate requests performed via Certificate provisioning portal Registered Endpoints Displays personal devices registered by employee users. Supplicant Provisioning Provides details on the supplicant and certificates provisioned by onboarding for employees. My Devices Login and Audit Combined report that tracks: Login activity Device related operations performed by users in the MDP           Appendix Dual-SSID flow with differentiated portal This flow is similar to dual-SSID flow, but instead of utilizing the BYOD setting within the guest portal, the BYOD portal is used for employees. Once employee user logs in to the guest portal, the user is presented with BYOD portal based on the authorization condition. In the example below, the user group will be used to provide different BYOD portal. This example utilizes the NAD settings and NSP settings in the main section of the document.   Create endpoint groups Go to Administration > Identity Management > Groups Click on ‘Endpoint Identity Groups’ on the left and click ‘Add’ Provide name ‘EP_Group_A’ for the group and click Submit Repeat above for ‘EP_Group_B’   Create user groups Go to Administration > Identity Management > Groups Click on ‘User Identity Groups’ on the left and click ‘Add’ Provide name ‘User_Group_A’ for the group and click Submit Repeat above for ‘User_Group_B’   Create end users Go to Administration > Identity Management > Identities Click on ‘Users’ on the left and click ‘Add’ Provide name ‘User_A’ for the Name Provide Login Password Select ‘User_Group_A’ for the User Groups and click Submit Repeat above for ‘User_B’ while selecting ‘User_Group_B’ for the User Groups instead   Create BYOD portal Go to Work Center > BYOD > Portals & Components > BYOD Portals Click on Add Use Portal_A as Portal Name Expand ‘Portal Settings’ tab and Select ‘EP_Group_A’ as Endpoint identity group Click Save Repeat above for ‘Portal_B’ while selecting ‘EP_Group_B’ for the as Endpoint identity group   Configure Guest portal Go to the Guest portal that is currently referenced by ‘Cisco WebAuth’ Authorization profile (If this is fresh install of ISE, then it should be ‘Self-Registered Guest Portal (Default)’) Go to Work Centers > Guest Access > Portals & Components > Guest Portals Click on Self-Registered Guest Portal (default) Scroll down to BYOD Settings and click > to expand Make sure ‘Allow employees to use personal devices on the network’ is unchecked Scroll down to ‘Authentication Success Settings’ and click > to expand Select URL and enter www.cisco.com (Or any site that is resolvable by DNS and on the trusted side of the network) Scroll up and click ‘Save’   Create Authorization Profiles Go to Policy > Policy Elements > Results Click on Authorization > Authorization Profiles Click Add Enter ‘BYOD_A’ as Name Scroll down under Common tasks and check ‘Web Redirection (CWA, MDM, NSP, CPP) Select Native Supplicant Provisioning Enter ACL_WEBAUTH_REDIRECT as ACL Select Portal_A for Value Click Submit Repeat above for BYOD_B while selecting Portal_B for Value   Create policy Go to Policy > Policy Sets Click on ‘>’ for the Default Policy Set Name Click on ‘>’ for the Authorization Policy to expand Click on the cog for the Wi-Fi_Guest_Access and select ‘Duplicate Above’ Change the name of the duplicate rule to Group_A Hover mouse on the conditions for Group_A rule and click ‘+’ Once in the conditions studio, click on ‘New’ in the editor box on the right Select gray ‘Select to add an attribute’ Select ‘InternalUser’ > IdentityGroup Select ‘User Identity Groups:User_Group_A’ Click ‘Use’ Under Results:Profiles column for the Group_A rule click on ‘x’ on the ‘PermitAccess’ when asked to select new profile, select ‘BYOD_A’ Repeat steps 4 – 12 for rule named ‘Group_B’ while using User_Group_B and BYOD_B instead for selections Click on the status column for ‘Employee_EAP-TLS’, ‘Group_A’, ‘Group_B’, and ‘Wi-Fi_Redirect_to_Guest_Login’ to enable the rules Policy set should resemble the following       ... View more