Cisco ISE BYOD Prescriptive Deployment Guide

[howon]

For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page. You may then Print, Print to PDF or copy and paste to any other document format you like.

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.

Author: Hosuk Won

Table of Contents

• Introduction
• About Cisco Identity Services Engine (ISE)
• About this guide
• Define
• Define your BYOD requirements
• Solution Deployment Considerations
• Endpoint Onboarding
• Unsupported Endpoints
• Password vs. Digital certificate
• Network Access Device
• Digital Certificates
• Integration with MDM/EMM
• Design
• Single vs. Dual SSID Flow
• PKI and ISE Internal CA
• Captive Network Assistant
• DNS ACL
• Deploy
• Configure Network Device
• Define Network Device
• Define Global settings
• Managing and Defining Certificate Template
• Defining BYOD Profiles and Resources
• Manage Client Provisioning policy
• Creating policy for Single-SSID BYOD flow
• Creating policy for Dual-SSID BYOD flow
• Note about different ISE portals
• Setting up Blacklist Portal (Optional)
• Setting up My Devices Portal (Optional)
• Setting up Certificate provisioning portal (Optional)
• Operate
• Review Single-SSID BYOD Flow
• User experience on iOS
• Review Dual-SSID BYOD Flow
• User experience on iOS
• Using self-signed certificate on ISE
• Managing devices via My Devices Portal
• Manage issued certificates from ISE Admin UI
• Managing Expired certificates
• Managing ISE Internal CA
• ISE Reports
• Appendix
• Dual-SSID flow with differentiated portal
• Create endpoint groups
• Create user groups
• Create end users
• Create BYOD portal
• Configure Guest portal
• Create Authorization Profiles
• Create policy
• Dual-SSID flow with separate Android device portal
• Create Android logical profile
• Create BYOD portal
• Configure Guest portal
• Create Authorization Profiles
• Create policy

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 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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; 3rd party CA console as ISE simply proxies all certificate signing request to 3rd 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 3rd party CA for each signed endpoint certificate	There may be licensing cost with 3rd 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:

1. Access the WLC GUI and navigate to Controller > General
2. Enable Fast SSID Change
3. 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	{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
   Permit	{ISE}/255.255.255.255	0.0.0.0 / 0.0.0.0	TCP	8084	Any	Outbound
   Permit	0.0.0.0 / 0.0.0.0	{ISE}/255.255.255.255	TCP	Any	8084	Inbound

   Note: Even when explicitly not stated, DHCP and DNS is permitted pre-web-authentcation on the WLC. If you would like to deny access to Internet DNS servers, ACL can be added to limit DNS to certain servers. Also 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 URL’
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.Note that this ACL allows full IP access to the ISE node but can be changed to limit ISE exposure from end users.
   

   Action	Source IP / Mask	Dest. IP / Mask	Protocol	Source Port	Dest Port	Direction
   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: Even when explicitly not stated, DHCP and DNS is permitted pre-web-authentcation on the WLC. If you would like to deny access to Internet DNS servers, ACL can be added to limit DNS to certain servers

3. Click ‘Back’ on the top right corner
4. Click Apply

Secured SSID

1. Go to WLAN
2. 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:

1. Go to WLAN
2. 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.

1. Go to Administration > Network Resources > Network Devices
2. Click on Add
3. Provide Name, IP
4. Check RADIUS Authentication Settings and the section will expand for more options
5. Provide Shared Secret
6. 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 > Settings > 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.

1. Go to Administration > System > Certificates > Certificate Authority > Certificate Templates
2. Click on Add (Or Edit to edit default ‘EAP_Authentication_Certificate_Template’)
3. 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
4. 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.
5. 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 3rd party CA, then this setting can be changed to send certificate signing request to 3rd 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.

1. Go to Policy > Policy Elements > Results > Client Provisioning > Resources
2. Edit Cisco-ISE-NSP (Or Add > Native Supplicant Profile)
3. 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
4. Change SSID Name
5. (Optional) Configure proxy related settings
6. Recommended to leave Security to WPA2 Enterprise
7. 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.
8. Expand Optional Settings can be used to configure additional settings:
   1. For Windows endpoints, use of machine or user store for certificate settings SSID broadcast settings can be set here
   2. For iOS devices, SSID broadcast settings can be set here
9. Click Submit
10. If Wired interface is to be used, then ‘Wired Profile’ check box can be enabled for Windows and macOS

Within the the Client Provisioning Resources page, updated version of NSA for Windows and macOS can be downloaded. To download latest NSA, follow the directions here:

1. Click on Add > Agent Resources from Cisco site
2. 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 MacOsXSPWizard x.x.x.x and WinSPWizard x.x.x.x.
3. Click Save
4. 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.

1. Go to Policy > Policy Sets
2. Click on ‘+’
3. Change the new policy set name to ‘Secured SSID’
4. In the conditions use ‘Normalized RADIUS : SSID ends with SECURED’
5. Click on Use
6. Select Default Network Access for Allowed Protocols
7. Click Save
8. Click on ‘>’
9. Click on ‘>’ on Authorization policy
10. Click ‘x’ on Deny Access on Results:Profiles Column
11. Select NSP_Onboard
12. Click ‘+’ above default rule
13. Change name to ‘TLS’
14. Click on ‘+’
15. 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)
16. For Results:Profiles Column select PermitAccess
17. 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.

1. 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)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Click ‘Allow employees to use personal devices on the network’
6. Scroll up and click ‘Save’
7. Go to Policy > Policy Sets
8. Click on ‘+’
9. Change the new policy set name to ‘Open SSID’
10. In the conditions use ‘Normalized RADIUS : SSID ends with OPEN’
11. Click on Use
12. Select Default Network Access for Allowed Protocols
13. Click Save
14. Click on ‘>’
15. Click on ‘>’ on Authentication policy
16. On the ‘Use’ column, select Internal Endpoints instead of All_User_ID_Stores
17. Click on ‘> Options’
18. 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)
19. Click on ‘>’ on Authorization policy
20. Click ‘x’ on Deny Access on Results:Profiles Column
21. Select Cisco WebAuth
22. 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:

1. Go to Administration > Device Portal Management > Blacklist
2. Click on Blackist Portal (default)
3. Click on Portal Page Customization
4. Page title and the message can be modified
5. 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

1. Go to Work Centers > BYOD > Portals & Components > My Devices Portals
2. Click on My Devices Portal (default)
3. Expand Portal Settings
4. Certificate group tag
5. 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)
6. Endpoint identity group
7. 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)
8. Scroll up and click on Portal Page Customization
9. Under Pages, click on Manage Device
10. Click on Settings on the right hand preview pane
11. 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

1. Go to Administration > Device Portal Management > Certificate Provisioning
2. Click on Certificate Provisioning Portal (default)
3. Expand Portal Settings
4. Certificate group tag
5. Authentication method
6. Configure authorized groups
7. 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		2nd 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		3rd 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		2nd 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		3rd 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 The ISE Administrator Guide for Certificate Management in Cisco ISE .

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

1. Go to Administration > Identity Management > Groups
2. Click on ‘Endpoint Identity Groups’ on the left and click ‘Add’
3. Provide name ‘EP_Group_A’ for the group and click Submit
4. Repeat above for ‘EP_Group_B’

Create user groups

1. Go to Administration > Identity Management > Groups
2. Click on ‘User Identity Groups’ on the left and click ‘Add’
3. Provide name ‘User_Group_A’ for the group and click Submit
4. Repeat above for ‘User_Group_B’

Create end users

1. Go to Administration > Identity Management > Identities
2. Click on ‘Users’ on the left and click ‘Add’
3. Provide name ‘User_A’ for the Name
4. Provide Login Password
5. Select ‘User_Group_A’ for the User Groups and click Submit
6. Repeat above for ‘User_B’ while selecting ‘User_Group_B’ for the User Groups instead

Create BYOD portal

1. Go to Work Center > BYOD > Portals & Components > BYOD Portals
2. Click on Add
3. Use Portal_A as Portal Name
4. Expand ‘Portal Settings’ tab and Select ‘EP_Group_A’ as Endpoint identity group
5. Click Save
6. Repeat above for ‘Portal_B’ while selecting ‘EP_Group_B’ for the as Endpoint identity group

Configure Guest portal

1. 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)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Make sure ‘Allow employees to use personal devices on the network’ is unchecked
6. Scroll down to ‘Authentication Success Settings’ and click > to expand
7. Select URL and enter www.cisco.com (Or any site that is resolvable by DNS and on the trusted side of the network)
8. Scroll up and click ‘Save’

Create Authorization Profiles

1. Go to Policy > Policy Elements > Results
2. Click on Authorization > Authorization Profiles
3. Click Add
4. Enter ‘BYOD_A’ as Name
5. Scroll down under Common tasks and check ‘Web Redirection (CWA, MDM, NSP, CPP)
6. Select Native Supplicant Provisioning
7. Enter ACL_WEBAUTH_REDIRECT as ACL
8. Select Portal_A for Value
9. Click Submit
10. Repeat above for BYOD_B while selecting Portal_B for Value

Create policy

1. Go to Policy > Policy Sets
2. Click on ‘>’ for the Default Policy Set Name
3. Click on ‘>’ for the Authorization Policy to expand
4. Click on the cog for the Wi-Fi_Guest_Access and select ‘Duplicate Above’
5. Change the name of the duplicate rule to Group_A
6. Hover mouse on the conditions for Group_A rule and click ‘+’
7. Once in the conditions studio, click on ‘New’ in the editor box on the right
8. Select gray ‘Select to add an attribute’
9. Select ‘InternalUser’ > IdentityGroup
10. Select ‘User Identity Groups:User_Group_A’
11. Click ‘Use’
12. Under Results:Profiles column for the Group_A rule click on ‘x’ on the ‘PermitAccess’ when asked to select new profile, select ‘BYOD_A’
13. Repeat steps 4 – 12 for rule named ‘Group_B’ while using User_Group_B and BYOD_B instead for selections
14. Click on the status column for ‘Employee_EAP-TLS’, ‘Group_A’, ‘Group_B’, and ‘Wi-Fi_Redirect_to_Guest_Login’ to enable the rules
15. Policy set should resemble the following
    
    

Dual-SSID flow with separate Android device portal

Another use case of using differentiated portal is for Android devices. For Android BYOD, you need to permit access to the google resources so the user can download Android NSP. When same portal is used for both guest users and the employee BYOD onboarding, the guest users will also have access to the google resources without having to login. To avoid this, a separate portal can be created for Android so only employee users with Android devices going through BYOD will have access to the google resources.

Create Android logical profile

Use of logical profile is required so the Android devices can be presented with proper page for both initial guest portal and the Android specific BYOD portal. Make sure to add every Android devices in the profiling policies in to the newly created logical profile.

1. Go to Work Centers > Profiler > Profiling Policies
2. Click on ‘Logical Profiles’ on the left and click ‘Add’
3. Provide name ‘Android-Logical-Profile’ for the name and select all of the Android devices from the Available policies and add them in to the Assigned Policies
4. Click Submit

Note: Only single logical profile for all Android devices should be created instead of creating multiple logical profiles for individual vendor devices

Create BYOD portal

This is the Android specific BYOD portal and only employee users with Android devices will get access to this.

1. Go to Work Center > BYOD > Portals & Components > BYOD Portals
2. Click on Add
3. Use Android_BYOD as Portal Name
4. Click Save

Configure Guest portal

1. 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)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Make sure ‘Allow employees to use personal devices on the network’ is unchecked
6. Scroll down to ‘Authentication Success Settings’ and click > to expand
7. Select URL and enter www.cisco.com (Or any site that is resolvable by DNS and on the trusted side of the network)
8. Scroll up and click ‘Save’

Create Authorization Profiles

This assumes that there are two ACLs on the WLC. The regular redirect ACL ACL_WEBAUTH_REDIRECT will only allow ISE portal access. The ACL_ANDROID ACL will allow access to ISE portal as well as google resources using DNS ACL feature on the WLC.

1. Go to Policy > Policy Elements > Results
2. Click on Authorization > Authorization Profiles
3. Click Add
4. Enter ‘Android_Redirect’ as Name
5. Scroll down under Common tasks and check ‘Web Redirection (CWA, MDM, NSP, CPP)
6. Select Native Supplicant Provisioning
7. Enter ACL_ANDROID as ACL (This ACL needs to be pre-created on the WLC)
8. Select Android_BYOD for Value
9. Click Submit

Create policy

1. Go to Policy > Policy Sets
2. Click on ‘>’ for the Default Policy Set Name
3. Click on ‘>’ for the Authorization Policy to expand
4. Click on the cog for the Wi-Fi_Guest_Access and select ‘Duplicate Above’
5. Change the name of the duplicate rule to Android_BYOD
6. Hover mouse on the conditions for Android_BYOD rule and click ‘+’
7. Once in the conditions studio, click on ‘New’ in the editor box on the right
8. Select gray ‘Select to add an attribute’
9. Select ‘EndPoints’ > LogicalProfile
10. Select ‘Android-Logical-Profile’
11. Click ‘Use’
12. Under Results:Profiles column for the Android_BYOD rule click on ‘x’ on the ‘PermitAccess’ when asked to select new profile, select ‘Android_Redirect’
13. Click on the status column for ‘Employee_EAP-TLS’, ‘Android_BYOD’, and ‘Wi-Fi_Redirect_to_Guest_Login’ to enable the rules
14. Policy set should resemble the following

[Arne Bier]

@howon - excellent document - you have encapsulated a lot of stuff in one easy to read document.  thank you very much!

[Joseph Johnson]

Great write up! Very easy to follow.

[murat001]

hi

we are getting an error during the device registration in step 3. 

client redirect to byod portal , 1. step AD user login success  and 2. step,  user is entering the username and passwd  and in last 3. step is giving this error "Your device is currently unsupported"  and   NSP download can not start. 

same result with Windows , IOS and android and Dual, Single SSID

do you have any suggestions ? 

REgards

[dongill]

Excellent document Hosuk, however I have a question with regards to Dual-SSID flow with differentiated portal and the secondary redirection to different BYOD portal.

The Guest Portal has an Authentication Success Page option [Original Page, Success Page or URL] for when Guest Users log in, however if one of these are enabled [say, originating URL] and a Staff user logs in for BYOD registration, the resulting redirection to a different BYOD portal breaks and causes a certificate error for the user. I assume this is due to the redirect taking the user to the originating URL,  but then being redirected again and the URL not matching the certificate. It seems that the Captive Portal functions in Chrome / Edge etc, don't detect this hence the mismatch error.

It's also restricted by the the Authentication Success Page applying to both Guest and Staff BYOD users...

Are you aware of any way around this, or am I missing something?

Any help is appreciated!

Thanks

[howon]

dongill11, no easy workaround that I am aware aside from hard coding static landing page on Authentication Success page. Unfortunately, it will be shared by both guest and employee so suggest selecting a site that works for both parties.

[Jason Kunst]

@dongill have you checked the options under http://cs.co/ise-guest there are linking to other portal examples there, please in the future open a new discussion

[dongill]

Thanks for quick response, really appreciated!
No problem, I understand that restriction in that case. It’s a bit of a shame - if ISE could allow us to build that side step into a different BYOD portal flow that would be the perfect solution!
I’ll stick with the Guest Portal and BYOD flow/specified group for now then.
Not sure if you had been asked this question before, but it may be worth updating the article to point this out for anyone else who encounters this struggle!

Again, excellent article and thanks a lot for your help anyway ☺

Cheers,
Don

[scottyd]

Thanks for a great guide. I only wish ALL of the images were actually readable. Some of them are tiny. I find this a common problem with Cisco documentation. Cheers

[tdhb..hiq]

This was a great help. But I think it should include the below. As this affects all deployments after 2.2 and Android devices.

https://community.cisco.com/t5/security-documents/android-byod-provisioning-error-quot-certificate-generation/ta-p/3733734#toc-hId--1964833293

I also had trouble with getting the DNS ACL working. I believe that this does not work for SSL traffic, so could now be pointless.

Thanks again.

[LukaszC]

Is it possible limit access to MDP by AD group? or any other workaround limiting access to my devices portal?

[Ehsan Momeni Bashusqeh]

Thanks for Sharing this Useful Document

[laposilaszlo]

hi  @howon

This is a great document, working based on it to implement this.

But there is one thing that bothers me and i cannot find an answer for it.

If we provide the usage of AD credentials on the guest network, is that safe?

How will account lockout will be treated?

Basically anyone from outside can try to log in using a AD account, it is not that hard to guess a username.

Will they be able to constantly lock the accounts?

Thanks

Laszlo