Deploying ISE For Bring Your Own Device (BYOD) : Hosuk Won

Deploying ISE for Bring Your Own Device
(BYOD)
This deployment guide is intended to provide all the relevant design, deployment and operations related
guidance to run Cisco Identity Services Engine (ISE) for Bring Your Own Device (BYOD), specifically on the Cisco
Unified Wireless Network (CUWN) Controllers.
Hosuk Won
June 2018
Cisco ISE Deployment Guide
Deploying ISE for Bring Your Own Device (BYOD)
Table of Contents
Introduction ............................................................................................................................................................ 4
About Cisco Identity Services Engine (ISE)............................................................................................................................ 4
About this guide ................................................................................................................................................................... 4
Define ...................................................................................................................................................................... 6
Define your BYOD requirements........................................................................................................................................... 6
Solution deployment considerations .................................................................................................................................... 7
Endpoint Onboarding ........................................................................................................................................................................................7
Password vs. Digital certificate.................................................................................................................................................................... 10
Network Access Device .................................................................................................................................................................................. 10
Digital Certificates............................................................................................................................................................................................ 11
Integration with MDM/EMM ....................................................................................................................................................................... 11
Design.................................................................................................................................................................... 13
Single vs. Dual SSID Flow.................................................................................................................................................... 13
PKI and ISE Internal CA ....................................................................................................................................................... 14
Captive Network Assistant ................................................................................................................................................. 16
DNS ACL .............................................................................................................................................................................. 16
Deploy ................................................................................................................................................................... 17
Configure Network Device.................................................................................................................................................. 18
Define Network Device ....................................................................................................................................................... 21
Define Global settings ........................................................................................................................................................ 21
Managing and defining Certificate Template .................................................................................................................... 22
Defining BYOD Profiles and Resources ............................................................................................................................... 23
Manage Client Provisioning policy ..................................................................................................................................... 23
Creating policy for Single-SSID BYOD flow ......................................................................................................................... 24
Creating policy for Dual-SSID BYOD flow ........................................................................................................................... 25
Note about different ISE portals......................................................................................................................................... 28
Setting up Blacklist Portal (Optional) ................................................................................................................................. 28
Setting up My Devices Portal (Optional) ............................................................................................................................ 28
Setting up Certificate provisioning portal (Optional) ......................................................................................................... 29
Operate ................................................................................................................................................................. 30
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Review Single-SSID BYOD Flow ........................................................................................................................................... 30

Review Dual-SSID BYOD Flow ............................................................................................................................................. 31
Using self-signed certificate on ISE .................................................................................................................................... 33
Managing devices via My Devices Portal ........................................................................................................................... 34
Manage issued certificates from ISE Admin UI .................................................................................................................. 35
Managing Expired certificates ........................................................................................................................................... 35
Managing ISE Internal CA .................................................................................................................................................. 36
ISE Reports ......................................................................................................................................................................... 36
Introduction
About Cisco Identity Services Engine (ISE)
Cisco Identity Services Engine

SIEM, MDM, NBA, IPS, IPAM, etc.
Cisco ISE CISCO ISE
WHO WHEN
WHAT WHERE PxGRID
Cisco Identity Services Engine & APIs
(ISE) is an industry leading, HOW HEALTH
Network Access Control and THREATS CVSS
Partner Eco System
Policy Enforcement platform ACCESS POLICY
FOR ENDPOINTS FOR NETWORK
Visibility WIRED WIRELESS VPN
Context about everything
touching the network VPN
Control
Network access control
and segmentation
Compliance
Enterprises comply to
industry regulations Role- based Access Control | Guest Access | BYOD | Secure Access
© 2017 Cisco and/ or its affiliates. All rights reserved. Cisco Confidential
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.
STEP 1 STEP 3
DEFINE DEPLOY
STEP 2 STEP 4
DESIGN OPERATE
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 Devices
Who should be able to bring in personal devices and gain What types of devices are allowed to the network as part of
network access? For a user access network, generally there will BYOD? Are these user devices, where user can interactively
be employee users, contractors, and guest users. For a typical configure the devices such as PC or mobile devices? Or are the
BYOD use cases, BYOD is allowed for employee users and devices headless devices, where there are no user interface (UI)
potentially for contractor users. Further control is possible by such as IoT devices? Does the device support 802.1X or only PSK?
allowing BYOD for certain set of users based on user groups if Are the devices personal devices or are you going to consider
necessary. When users are bringing in personal devices, what is corporate owned devices as BYOD? How many devices will be
the role of the admin users? allowed to be tied to a single user needs to be considered as well.
Access Control Onboarding
Compared to managed devices, generally organizations lack Depending on the customer requirement, BYOD may simple as
control for BYOD endpoints. Due to lack of control, BYOD allowing personal endpoints connect to the network without
endpoints cannot be confirmed to be compliant before granting automated onboarding process. Which assumes the end user is
access whereas managed devices can be trusted to have certain responsible for configuration of the endpoint to connect and gain
elements such as anti-malware, MDM, hotfix, etc. Due to lack of network access. For many organizations, this level of BYOD may
control, administrators may limit BYOD endpoints to Internet meet their requirement. However, the benefit of ISE BYOD flow
only access or to certain set of web based applications. The is that ISE can assist the end user to onboard their endpoints by
access control can be achieved by assigning different provisioning CA signed endpoint certificate as well as configure
permissions in the form of ACL, VLAN, or SGT. 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
Cisco ISE
- Users - Switches - Standalone ISE - AD/LDAP

- Devices - WLCs / Aps - Multi- node ISE - MDM
- Things - VPN gateways - VM/Appliance - Security services
Endpoints Network Devices Cisco ISE External Services
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 NSA located in the G-Suite Chrome extension
Chromebook 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 May need to consider integration with enterprise PKI for better BYOD user
days. When the password has been changed, user has to manually experience
change it on all endpoints in short periods of time to avoid
connectivity issues.
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 3rd party NAD support. ISE can be configured to leverage WebAuth capabilities built into the
3rd 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 3rd party NAD feature can still
support the network devices.
10
NAD Description ISE 3rd party NAD feature

Feature
URL-Redirect This allows endpoints to be redirected to a web portal when the user opens up a browser In the case of NAD without URL-Redirect feature, ISE
on the endpoint. This is essential to the ISE BYOD as ISE needs to interact with the end can be configured to provide URL-Redirect using
user to guide through the process. There are two main components of URL-Redirect. First DNS-Sinkholing. With DNS-Sinkholing, any web
is the ACL which dictates what traffic will be allowed without being redirected or not and the request destinations are re-written with ISE IP
second is the URL destination to direct the web traffic to when the traffic is denied. Also, address, where ISE can provide web portal
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
CoA Change of Authorization is essential to BYOD as it provides ways to transition from limited ISE SNMP CoA still requires MAB configured and
access during pre-onboarding to full access once onboarding is complete. ISE has two functional on the interface.
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
DNS based Google Android and Chromebook requires access to NSA which is located in the cloud. Some 3rd party NDA supports DNS based ACLs, for
ACLs NSA can be preinstalled, but if required to download NSA during the onboarding flow, then others without the feature, ISE DNS-Sinkholing can
the ACL need to be modified to allow access to cloud resources. Cisco WLC running 7.6 be used to provide the feature.
(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
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:
11
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.
12
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
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 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 BYOD flow:
Single SSID Dual SSID
Pros User experience is better for iOS users as SSID switching from Some organizations prefer having a dedicated SSID for on-boarding devices.
OPEN to SECURED does not require user intervention
Can provide visible guidance to the user on the BYOD process before logging in
This is a unique capability of ISE where competitor solution forces
user to login twice while ISE can take user information from 802.1X Better security: User can confirm that the BYOD server is legitimate as the user
session without asking for the user to login again to the web portal does not get prompted to manually trust the EAP certificate
13
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
Cons Fast-SSID change setting needs to be enabled on the WLC to Others see dual SSID as an extra management burden.
accommodate iOS devices A second SSID adds channel overhead and may degrade wireless performance
When end users connect to the SSID for the first time there is no Requires iOS users to manually switch SSID
easy way to validate whether server provided certificate is from the
trusted source
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 3rd party CA server and can also be enabled along with first or second option.
14
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
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 ISE Internal Certificates need to be re-issued if Easiest deployment method. No configuration is
endpoint certificates; 3rd party CA console already deployed as distributed deployment necessary. ISE is already enabled with Self-signed
as ISE simply proxies all certificate signing CA to use with BYOD endpoints
request to 3rd party CA
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 There may be licensing cost with 3rd party CA for Additional effort may be needed to ensure the self-
Only been validated with MS CA (Requires each signed endpoint certificate signed CA is trusted on the network.
MS enterprise license for SCEP feature)
15
There may be licensing cost with 3 rd party

CA for each signed endpoint certificate
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
16
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 This is the policy to control which portal will be presented to the user going through the BYOD flow. It also dictates
Policy 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.
17
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)
18
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 Dest Direction
Port Port
Permit {DNS}/255.255.255.255 0.0.0.0 / 0.0.0.0 UDP DNS Any Outbound
Permit 0.0.0.0 / 0.0.0.0 {DNS}/255.255.255.255 UDP Any DNS Inbound
Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8443 Any Outbound
Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8443 Inbound
Note that this ACL works with ISE 2.4, however older version of ISE may require additional TCP ports to be open.
3. Click ‘Back’ on the top right corner
4. Click down arrow next to the ACL and select ‘Add-Remove ACL’
5. Here enter following entries one by one
.google.co
accounts.youtube.com
gstatic.com
.googleapis.com
.appspot.com
19
ggpht.com
gvt1.com
market.android.com
android.pool.ntp.org
.googleusercontent.com
.google-analytics.com
6. Click Back
7. Click Apply
Create Blacklist ACL
Single ACL will be created for Blacklist portal

1. Go to Security > Access Control Lists > Access Control Lists
2. Click on ‘New’ and create ‘BLACKHOLE’ ACL with following parameters. The ACL name ‘BLACKHOLE’ is the default ACL name
referenced by ISE, so if using different ACL name on the WLC, make sure to change it on the ISE Authorization profile as well.
Note that the WLC ACL is stateless so reverse of the allowed ACE needs to be created.
Action Source IP / Mask Dest. IP / Mask Protocol Source Dest Direction
Port Port
Permit {DNS}/255.255.255.255 0.0.0.0 / 0.0.0.0 UDP DNS Any Outbound
Permit 0.0.0.0 / 0.0.0.0 {DNS}/255.255.255.255 UDP Any DNS Inbound
Note that this ACL allows full IP access to the ISE node but can be changed to limit ISE exposure from end users.
3. Click ‘Back’ on the top right corner
4. Click Apply
Secured SSID
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.
20
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 > 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.
21
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
22
Subject Alternative Name Currently, only value available is the MAC Address. The MAC Address is pulled from the RADIUS session from the
(SAN) 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:
a. For Windows endpoints, use of machine or user store for certificate settings SSID broadcast settings can be set here
b. For iOS devices, SSID broadcast settings can be set here
9. Click Save
10. If Wired interface is to be used, then ‘Wired Profile’ check box can be enabled for Windows and macOS
Within the same page, updated version of NSA for Windows and macOS can be downloaded. To download latest NSA, follow the directions here:
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
MaxOsXSPWizard 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.
23
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.
24
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
25
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.
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.
26
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
27
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 & User portal that end user goes through for onboarding. This is only used for dual-SSID
Components > Guest Portals 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 User portal that end user goes through for onboarding. This is only used for sing-SSID
> BYOD Portals flow
Or
Administration > Device Portal Management >
BYOD
Blacklist Portal Administration > Device Portal Management > User portal for users with endpoints in blacklist group. Instead of denying network
Blacklist 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 Work Center > BYOD > Portals & Components Used for end users to manage their own devices. Here users can view onboarded
(MDP) > My Devices Portals devices as well as add devices manually. User can also mark devices as stolen or lost
Or 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.
Administration > Device Portal Management >
My Devices
Certificate Administration > Device Portal Management > Used for signing and generating certificates manually. Certificates can be signed by
Provisioning Portal Certificate Provisioning Portal 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
28
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)
29
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.
30
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
31
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.
32
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 3rd 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.

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
33
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 3rd 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.
34
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
35
3. Allowed Protocol: By default, Cisco ISE rejects a request that comes from a device whose certificate has expired. However, you can
change this default behavior and configure ISE to process such requests and prompt the user to renew the certificate. EAP-TLS Section in
the Allowed Protocols includes option to allow authentication for expired certificate. This option is disabled by default as it is not secure
to allow expired certificate, but if there is a need to allow expired certificate to authenticate then this option can be enabled. However, if
using this option, be sure to use AuthZ condition in conjunction with this option to limit access for users with expired certificate.
Note: Some devices allow you to renew the certificates before and after their expiry. But on Windows devices, you can renew the certificates
only before it expires. Apple iOS, Mac OSX, and Android devices allow you to renew the certificates before or after their expiry.
Managing ISE Internal CA

You must back up the Cisco ISE CA certificates and keys securely to be able to restore them back on a Secondary Administration Node in case of a
PAN failure and you want to promote the Secondary Administration Node to function as the root CA or intermediate CA of an external PKI. The
Cisco ISE configuration backup does not include the CA certificates and keys. Instead, you should use the Command Line Interface (CLI) to export
the CA certificates and keys to a repository and to import them. The ‘application configure ise’ command includes export and import options to
backup and restore CA certificates and keys.
For more information on managing ISE Internal CA, please review following document: https://www.cisco.com/c/en/us/td/docs/security/ise/2-
4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_0111.html#concept_435C4E3FF56949B1B4D5A0C73671AB22
ISE Reports
Although not part of the reports, ISE Live log shows live status of all the authentication requests including the BYOD endpoints. Here one can
confirm which policy the endpoint is matching.
36
One 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 Shows the integration between ISE and external MDM. Also shows endpoint status from the ISE without having
Management to login to the external MDM portal.
Manual Certificate Combined report that tracks:
Provisioning ¤ 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
37
Printed in USA Cxx-xxxxxx-xx 06/18

38

Deploying ISE For Bring Your Own Device (BYOD) : Hosuk Won

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Deploying ISE For Bring Your Own Device (BYOD) : Hosuk Won

Transféré par

Droits d'auteur :

Formats disponibles

Deploying ISE for Bring Your Own Device

Review Single-SSID BYOD Flow ........................................................................................................................................... 30

About Cisco Identity Services Engine (ISE)

Cisco Identity Services Engine

About this guide

Define your BYOD requirements

Access Control Onboarding

provisioned certificate for network access. The other benefit of

Solution deployment considerations

- Users - Switches - Standalone ISE - AD/LDAP

Endpoints Network Devices Cisco ISE External Services

Windows OS & macOS

Apple mobile devices (iOS)

MS Windows NSA located on ISE PSN node

Password vs. Digital certificate

Network Access Device

NAD Description ISE 3rd party NAD feature

Integration with MDM/EMM

MDM Attribute Description

DeviceRegisterStatus Endpoint is known to MDM server and been previously registered

DiskEncryptionStatus Disk encryption is not enabled on the endpoint

JailBrokenStatus Match endpoint status JailBroken based on MDM server response

MDMFailureReason FailureReason value

MDMServerName Match based on MDMServerName from endpoint attributes

MDMServerReachable Match reachable status of MDM server

PhoneNumber PhoneNumber Value. Match based on phone number of mobile device

PinLockStatus Pinlock disabled on endpoint

Now let’s look at the dual SSID flow:

PKI and ISE Internal CA

SCEP to enterprise CA Sub CA of enterprise PKI ISE Self-Signed CA

There may be licensing cost with 3 rd party

Captive Network Assistant

Configure Network Device

Enable fast-ssid-change feature (Optional)

Configure ISE as RADIUS Authentication and Accounting server

1. Go to Security > RADIUS Authentication

Attribute Value or description

4. Click Apply and Save Configuration.

Create Redirect ACL

Create Blacklist ACL

Single ACL will be created for Blacklist portal

Open SSID (Optional)

Define Network Device

1. Go to Administration > Network Resources > Network Devices

Define Global settings

Managing and defining Certificate Template

Existing certificate template should work for most environment,

1. Go to Administration > System > Certificates > Certificate

Defining BYOD Profiles and Resources

Manage Client Provisioning policy

Creating policy for Single-SSID BYOD flow

1. Go to Policy > Policy Sets

Creating policy for Dual-SSID BYOD flow

If self-service guest service is not needed, then it can be disabled

To make guest portal also support employee BYOD, the BYOD

Note about different ISE portals

Setting up Blacklist Portal (Optional)

Setting up Certificate provisioning portal (Optional)

Review Single-SSID BYOD Flow

Step User Experience Note

2 Once associated to the secure SSID, user opens

Note: If the pseudo (Apple CNA) browser

3 2nd page of the BYOD portal allows end user to