Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf

21.07.2022, 16:29 Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community
https://community.cisco.com/t5/security-knowledge-base/cisco-ise-byod-prescriptive-deployment-guide/ta-p/3641867#toc-hId-1185476859 1/78
Cisco
Community
Welcome to the new Cisco Community. LEARN MORE about the updates and what is
coming.
Search Cisco Community Create a new article
Cisco Community
>
Technology and Support
>
Security
>
Security Knowledge Base
>
Cisco ISE BYOD Prescriptive Deployment Guide
Options

Cisco ISE BYOD Prescriptive Deployment Guide

howon

Cisco Employee
‎
07-09-2018
08:40 AM
- edited ‎
08-06-2020
04:10 PM

For an offline or printed copy of this document, simply choose ⋮ Options > Printer
Friendly Page. You may then Print, Print to PDF or copy and paste to any other
document format you like.

This deployment guide is intended to provide all the relevant design, deployment and
operations related guidance to run Cisco Identity Services Engine (ISE) for Bring Your
Own Device (BYOD), specifically on the Cisco Unified Wireless Network (CUWN)
Controllers.

Author: Hosuk Won

Table of Contents
Introduction
About Cisco Identity Services Engine (ISE)
About this guide
Define
Define your BYOD requirements
Solution Deployment Considerations
Endpoint Onboarding
Unsupported Endpoints
Password vs. Digital certificate
Network Access Device
Digital Certificates
Integration with MDM/EMM
Design
Single vs. Dual SSID Flow
PKI and ISE Internal CA
Captive Network Assistant
DNS ACL
Deploy
Configure Network Device
Define Network Device
Define Global settings

Managing and Defining Certificate Template
Defining BYOD Profiles and Resources
Manage Client Provisioning policy
Creating policy for Single-SSID BYOD flow
Creating policy for Dual-SSID BYOD flow
Note about different ISE portals
Setting up Blacklist Portal (Optional)
Setting up My Devices Portal (Optional)
Setting up Certificate provisioning portal (Optional)
Operate
Review Single-SSID BYOD Flow
User experience on iOS
Review Dual-SSID BYOD Flow
Using self-signed certificate on ISE
Managing devices via My Devices Portal
Manage issued certificates from ISE Admin UI
Managing Expired certificates
Managing ISE Internal CA
ISE Reports
Appendix
Dual-SSID flow with differentiated portal
Create endpoint groups
Create user groups
Create end users
Create BYOD portal
Configure Guest portal
Create Authorization Profiles
Create policy
Dual-SSID flow with separate Android device portal
Create Android logical profile
Create BYOD portal
Create Authorization Profiles
Create policy
Introduction
About Cisco Identity Services
Engine (ISE)

Cisco Identity Services Engine (ISE) is a market leading, identity-based network
access control and policy enforcement system. It’s a common policy engine for
controlling, endpoint access and network device administration for your enterprise.
ISE allows an administrator to centrally control access policies for wired wireless and
VPN endpoints in the network.
ISE builds context about the endpoints that include users and groups (Who), device-
type (What), access-time (When), access-location (Where), access-type
(Wired/Wireless/VPN) (how), threats and vulnerabilities. Through the sharing of vital
contextual data with technology partner integrations and the implementation of Cisco
TrustSec® policy for software-defined segmentation, Cisco ISE transforms the
network from simply a conduit for data into a security enforcer that accelerates the
time to detection and time to resolution of network threats.
About this guide
This guide is intended to provide technical guidance to design, deploy and operate
Cisco Identity Services Engine (ISE) for Bring Your Own Device (BYOD). Special focus
will be on the Cisco Unified Wireless Networks controller configurations to handle two
BYOD deployment flow; Single-SSID BYOD and Dual-SSID BYOD. The document
provides best practice configurations for a typical environment for BYOD use case.
Even though Cisco ISE BYOD supports wired access use cases, this guide does not
cover BYOD flow via wired connection.

The first half of the document focusses on the planning and design activities, the
other half goes in to the specifics of configurations and operations.
There are four major sections in this document. The initial, define part talks about
defining the problem area, planning for deployment, and other considerations. Next, in
the design section, we will see how to design for BYOD. Third, in the deploy part, the
various configuration and best practice guidance will be provided. Lastly, in the
operate section, we will learn how to manage BYOD controlled by Cisco ISE
Define
Define your BYOD requirements
If you are reading this document, you have already decided to allow users to bring in
personal devices or possibly looking into allowing personal devices. The consensus is
that BYOD increases productivity of the users as they do not need to be provisioned
with additional devices for internal network access. Before we dive into the details of
ISE BYOD, let’s discuss what BYOD is. BYOD as the term states is about bringing in
and connecting personal devices to the managed network. Now, this is simple enough
concept, but the ‘connecting’ part can have many different meanings for many
different customers. For some it could simply mean connecting to the guest network
to access the Internet, for others it could mean providing access to internal resources
as well as the Internet, and yet for others it could mean provisioning digital certificates
and MDM agent and provide network admin some control over the devices and also
providing access to the internal resources not available to guest users. So as you can
see, there may be different goals of BYOD based on the customer. However, before
allowing personal devices on the network, it is important to define what the
requirements are for BYOD access. Requirements may include, who will be allowed to
bring in personal devices and how technically savvy the users are, which level of

access will be given to BYOD, what types of devices will be allowed to be connected,
how are you going to onboard the endpoint devices on to the network to ensure the
endpoints are securely configured? The following provides guidance on the
requirements:
Users
Who should be able to bring in
personal devices and gain
network access? For a user
access network, generally there
will be employee users,
contractors, and guest users. For
a typical BYOD use cases, BYOD
is allowed for employee users
and potentially for contractor
users. Further control is possible
by allowing BYOD for certain set
of users based on user groups if
necessary. When users are
bringing in personal devices,
what is the role of the admin
users?
Devices
What types of devices are allowed to the
network as part of BYOD? Are these user
devices, where user can interactively configure
the devices such as PC or mobile devices? Or
are the devices headless devices, where there
are no user interface (UI) such as IoT devices?
Does the device support 802.1X or only PSK?
Are the devices personal devices or are you
going to consider corporate owned devices as
BYOD? How many devices will be allowed to be
tied to a single user needs to be considered as
well.

Access Control
Compared to managed devices,
generally organizations lack
control for BYOD endpoints. Due
to lack of control, BYOD
endpoints cannot be confirmed to
be compliant before granting
access whereas managed
devices can be trusted to have
certain elements such as anti-
malware, MDM, hotfix, etc. Due
to lack of control, administrators
may limit BYOD endpoints to
Internet only access or to certain
set of web based applications.
The access control can be
achieved by assigning different
permissions in the form of ACL,
VLAN, or SGT.
Onboarding
Depending on the customer requirement, BYOD
may simple as allowing personal endpoints
connect to the network without automated
onboarding process. Which assumes the end
user is responsible for configuration of the
endpoint to connect and gain network access.
For many organizations, this level of BYOD may
meet their requirement. However, the benefit of
ISE BYOD flow is that ISE can assist the end user
to onboard their endpoints by provisioning CA
signed endpoint certificate as well as configure
the network interface and OS native supplicant
to utilize the provisioned certificate for network
access. The other benefit of ISE BYOD is the ‘My
Devices Porta’
, which allows end users to
Create/Read/Update/Delete (CRUD) on
endpoints that they own.

Solution Deployment
Considerations

As mentioned earlier, there are different ways to onboard endpoints to the network.
One way is to simply let users connect their personal devices to the existing guest or
internal network, where endpoint simply gets Internet only access or in the case of
internal network, the endpoint will gain same level access as managed devices. The
other end of the spectrum is where endpoint is onboarded via ISE BYOD flow. When
ISE BYOD onboards the endpoint, ISE can issue Certificate Authority (CA) signed
certificate as well as automatically configure endpoint network settings to use the
endpoint certificate that has been signed to gain network access. At the same time,
ISE can mark the device as BYOD endpoint and also tie the endpoint with the user.
Furthermore, the end user can logon to the ISE my devices portal to manage the
endpoint that he/she owns without the need of involvement from IT team.
When it comes to ISE BYOD, there are two distinct ways to design the user
experience flows; Single SSID BYOD and Dual SSID BYOD flow. If the goal is to
minimize number of SSIDs, there are no separate guest WLAN, or if the guest access
is using hotspot access (rather than named guest account access) then single-SSID
BYOD is recommended as the open SSID using hotspot portal cannot be used for
initial BYOD portal at the same time. With Single-SSID BYOD, the endpoint associates
to a secure WLAN gets onboarded then after the endpoint automatically reconnects
the endpoint is granted full network access via same WLAN.
If guest access is utilizing one of the named guest account, then same guest portal
can be used for employee BYOD portal. This flow is called Dual-SSID BYOD, where
the endpoint is associated to a provisioning WLAN which is typically shared with guest
access. When the ISE confirms that the user is an employee user, then ISE will direct
the user to the BYOD flow where the endpoint gets onboarded. Once provisioned with
the WLAN settings and possibly CA signed certificate, then the endpoint is
reconnected to the secured WLAN for full network access.

Endpoint Onboarding
When leveraging ISE for BYOD, there are few actions that the endpoint needs to
perform, which includes starting the communication with proper ISE node via the
BYOD portal, creating digital certificate pairs, submitting certificate signing request,
and configuring network profile. Some O/S has provisions for such functions natively
while others require downloading and running an application temporarily to assist with
the flow. Aside from Apple mobile devices (iOS), ISE leverages Network Setup
Assistant (NSA or AKA Supplicant Provisioning Wizard (SPW)) to ease the BYOD flow
for the users. NSA is an application that is downloaded to the endpoint either from the
ISE itself or from app store for each of the endpoint types. NSA assists the user to
generate certificate pair, install signed certificate, and configure network and proxy
settings on the endpoint.
Windows OS & macOS
For Windows and macOS, the NSA is located on the ISE PSN itself. When the
endpoint goes through onboarding flow, ISE instructs the user to download and install
NSA, which in turn guides the user through the BYOD process. Since there are newer
version of Windows and macOS that are introduced to the market, admin user will
need to update the NSA on the ISE periodically to assure support for newer OS.
Apple mobile devices (iOS)

The way Apple iOS work is different from other OS in that it doesn’t require ISE NSA
application for BYOD flow. Rather ISE will leverage iOS’ existing capabilities (Apple
Over-the-air (OTA)) to generate key pair, install signed certificate, and configure WiFi
settings. Even though ISE is leveraging OTA, iOS gets instructions from ISE in the form
of profiles which gets installed on the iOS. As there are no applications to download,
iOS can be onboarded without access to the Apple App store.
Android devices
For Android devices, ISE will force installation of NSA during the onboarding flow if it
is not installed already. NSA assists the user to generate key pair, install signed
certificate, and configure WiFi settings. Since Android devices download applications
from Google Play store, the temporary ACL assigned during onboarding flow needs to
be modified to allow such access. Since it is not practical to use IP address based
ACL to allow access to play store, it is recommended to utilize DNS ACL on the NAD
to allow access. This ensures that access to play store is allowed even when there are
IP changes for services related to play store access. Aside from allowing access to
the play store, it is also recommended to guide users to pre-download the NSA via
other means such as cellular network or different WLAN to simplify the onboarding
process when the endpoint is connected to the network.

Chromebooks
BYOD flow on Chromebook devices is different from other OS. Unlike other OS where
there is no requirement for the endpoints to be pre-registered, the Chromebook
devices needs to be enrolled to the Google-Suite before it can go through the ISE
BYOD flow. The G-Suite admin needs to configure Chromebook policy on the G-Suite
to force installation of NSA Chrome extension. Also, G-Suite admin needs to
configure WiFi settings on the Google admin console. This is different from other OS
where they get network settings pushed from the ISE directly. Just like Android

devices, Chromebook requires the endpoint to have access to the Google resources
for BYOD flow to work. The temporary ACL assigned during onboarding flow needs to
be modified to allow such access. Since it is not practical to use IP address based
ACL to allow access to play store, it is recommended to utilize DNS ACL on the NAD
to allow access. This ensures that access to the G-Suite resources is allowed even
when there are IP changes for services related to play store access
Unsupported Endpoints
As noted above, ISE supports Windows, macOS, iOS, Android, and Chromebooks for
BYOD flow. For other OSes, ISE global settings can be toggled to determine what
access will be given to unsupported devices. You can dictate what level of access will
be given in the case of unsupported devices using policy or unconditionally provide
network access. Another option is to manually onboard devices by issuing certificates
from certificate portal and enabling network settings to connect to the network. You
can further secure the network by forcing endpoints to be registered to the ISE by
using my devices portal. Lastly, if dual SSID BYOD flow is used, you can provide
option to allow Internet only access if user chooses not to go through the BYOD flow.
Following summarizes characteristics of different endpoints going through ISE BYOD
flow:
Endpoint Characteristics
MS
Windows
NSA located on ISE PSN node
Latest NSA can be downloaded to ISE from ISE GUI
Can use ECC certificate (Windows 8+)
As part of onboarding flow following settings can be configured:
- Both wireless and wired interface
- Web proxy settings
Can configure user, machine, or both for identity
Apple
macOS
NSA located on ISE PSN node
Latest NSA can be downloaded to ISE from ISE GUI
Also supports EAP-FAST
As part of onboarding flow following settings can be configured:
- Both wireless and wired interface
- Web proxy settings

Endpoint Characteristics
Apple iOS Use iOS native capability (Over-the-Air (OTA)) instead of NSA
With iOS 11+, and self-signed identity certificate is used for ISE admin
GUI, then ISE identity certificate must be explicitly trusted before BYOD
flow can complete
Also supports EAP-FAST
Web proxy settings can be configured along with wireless profile
Newer iOS may not work if the Top Level Domain (TLD) of the FQDN is
not a valid one such as .local.
Google
Android
NSA located in the Google Play Store
The NSA needs to be pre-downloaded or the Play Store needs to be
accessible during the BYOD flow
Can use ECC certificate (Android 4.4+)
Google
Chromebook
NSA located in the G-Suite Chrome extension
Chromebook needs to be managed devices
G-Suite app policy needs to be configured to force NSA extension to
be pre-installed
Other OS In the case of dual-SSID flow, BYOD portal can be configured to allow
guest access if employee does not want to go through the BYOD flow
ISE Policy can be used to allow devices based on profiling
Global setting can be configured to allow network access
unconditionally
My Devices Portal can be used to allow endpoints without 802.1X
capability to connect
Certificate provisioning portal can be used to issue certificates for
added security, however configuration of endpoint network settings to
use certificate is manual process

Password vs. Digital certificate
While ISE supports various EAP types for 802.1X authentication, with ISE BYOD, there
are three EAP Types that can be used; EAP-TLS, EAP-PEAP-MSCHAPv2, and EAP-
FAST. With EAP-TLS ISE identifies itself by providing EAP Identity certificate to the

endpoint, once the ISE identity certificate is validated by the endpoint, the endpoint
will provide its own endpoint identity certificate that was previously signed by ISE.
Once ISE confirms its validity, then the endpoint is authorized on to the network. With
EAP-PEAP-MSCHAPv2, ISE identifies itself by providing EAP Identity certificate to the
endpoint, once the ISE identity certificate is validated by the endpoint, the endpoint
provides a combination of username and password that ISE can authenticate. Once
ISE validates the user, then the endpoint is authorized to the network. In both EAP
types, first ISE provides its own certificate to the endpoint and the main difference is
whether the endpoint provides a digital certificate or username/password. ISE
supports both endpoint identity, but it is recommended to use endpoint certificates for
better security and manageability.
Password (EAP-PEAP-MSCHAPv2 & EAP-FAST) Digital Certificate
(EAP-TLS)
Pros Simple to use Certificates are
generally valid for
longer period than
passwords
Added security as
the certificate is
purpose built for
BYOD only
ISE BYOD certificates
are tied to the
endpoint MAC
address
Cons Generally, passwords are required to be changed
every X number of days. When the password has been
changed, user has to manually change it on all
endpoints in short periods of time to avoid connectivity
issues.
May need to
consider integration
with enterprise PKI
for better BYOD user
experience

Network Access Device

ISE BYOD is supported on wireless and wired networks regardless of network device
vendor. However, depending on the feature set available on the NAD, deployment may
be easier for devices that supports standards based features. For instance, Cisco
WLC supports standards based CoA and RADIUS based URL-redirect as well as DNS
ACLs, all of which makes it easy to deploy ISE BYOD. Furthermore, Cisco WLC is
supported by ISE Secure Access Wizard, where ISE can configure the WLC and ISE
policies for BYOD user cases. In the case of other network devices that lacks certain
features, ISE can still support BYOD flow by leveraging 3 party NAD support. ISE can
be configured to leverage WebAuth capabilities built into the 3 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 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
party devices which lacks the feature, how ISE 3 party NAD feature can still support
the network devices.

NAD
Feature
Description ISE 3 party NAD feature
rd
rd
rd
rd
rd
rd
d

NAD
Feature
URL-
Redirect
This allows endpoints to be redirected to a web portal
when the user opens up a browser on the endpoint. This
is essential to the ISE BYOD as ISE needs to interact with
the end user to guide through the process. There are two
main components of URL-Redirect. First is the ACL
which dictates what traffic will be allowed without being
redirected or not and the second is the URL destination
to direct the web traffic to when the traffic is denied.
Also, there are two distinct ways to perform URL-
Redirect:
- Dynamic URL-Redirect: When an endpoint is
authenticated via RADIUS, ISE can send back a
name of ACL and Destination URL as part of
RADIUS response. Most of Cisco devices and
limited number of 3 party NAD supports this
method
- Static URL-Redirect: The URL destination and
the ACL is predefined on the NAD as static
configuration. This is common method of URL-
Redirect in most of 3 party NAD
In the case of NAD without
URL-Redirect feature, ISE
can be configured to
provide URL-Redirect
using DNS-Sinkholing.
With DNS-Sinkholing, any
web request destinations
are re-written with ISE IP
address, where ISE can
provide web portal
CoA Change of Authorization is essential to BYOD as it
provides ways to transition from limited access during
pre-onboarding to full access once onboarding is
complete. ISE has two different ways to provide CoA:
- RADIUS Based CoA: This is using RADIUS to
communicate between ISE and the NAD
- SNMP Based CoA: For some 3 party NAD that
does not support RADIUS based CoA, ISE can
use SNMP to change the access. This is done by
ISE issuing SNMP Write command to the NAD for
the interface to shut down the interface and
immediately bring it back up. As the interface is
brought back up, ISE can assign different
permissions to the interface
ISE SNMP CoA still
requires MAB configured
and functional on the
interface.
rd
d
rd
rd
rd

NAD
Feature
DNS
based
ACLs
Google Android and Chromebook requires access to
NSA which is located in the cloud. NSA can be
preinstalled, but if required to download NSA during the
onboarding flow, then the ACL need to be modified to
allow access to cloud resources. Cisco WLC running 7.6
(8.2 and above supports up to 20 DNS entries per ACL,
while older versions supports 10 entries) and up has
feature to craft ACL based on FQDN
Some 3 party NDA
supports DNS based
ACLs, for others without
the feature, ISE DNS-
Sinkholing can be used to
provide the feature.

Digital Certificates
ISE relies on digital certificates for various aspects of the solution. As noted above,
ISE utilizes certificates to identify itself to the endpoints for EAP, but it also uses
certificates to identity itself for web portals. In some cases, the EAP identity certificate
and web portal certificate could be different, but in many cases, it could be using the
same certificate for both to save on management cost. This is especially true when
the certificate is signed by well-known Certificate Authority (CA).
One of the main benefit of ISE BYOD is that ISE can provide signed certificate for the
endpoints as part of the BYOD flow. For endpoint certificates, ISE can utilize internal
CA to issue signed certificates. ISE is already enabled with internal PKI which can be
integrated with customer’s existing PKI infrastructure and also provide web portal to
manage endpoint certificates. Here are characteristics of ISE Internal CA:
- Generally used for BYOD
- Can also be used for other purposes such as to secure pxGrid communication
- Full certificate lifecycle management including multiple templates, expiry, revocation
(OCSP)
- Supports validity dates up to 10 years for endpoint certificates
- Supports up to 1 million certificates
Integration with MDM/EMM
ISE can leverage MDM/EMM to check posture of the mobile endpoints prior to
providing full network access. ISE itself doesn’t provide native MDM/EMM capabilities
such as checking for pin lock, encryption, jail broken status, but as endpoints connect
to the network ISE can reference the MDM/EMM system to see if the endpoint is
rd
rd

compliant. If compliant ISE can provide full network access, however, if the endpoint is
not registered with MDM/EMM or is not compliant, ISE can guide the end user to
address the issue without having to involve IT.
When My Devices Portal is used in conjunction with MSM/EMM, the portal allows end
user to issue MDM/EMM commands such as remote lock, remote wipe, corporate
wipe, etc.
Also, if endpoints are managed via MDM/EMM, some of the MDM/EMM vendors can
issue certificates as well as configure network settings without the need of ISE BYOD.
If using MDM/EMM for certificate provisioning and network configuration, ISE can be
configured to trust MDM/EMM signed endpoint certificate for better user experience.
Following is sample of MDM attributes ISE can look up for an endpoint during
authorization:
MDM Attribute Description
DaysSinceLastCheckin How many days elapsed from last MDM check for particular endpoint
DeviceCompliantStatus Attribute validate that complaint status been confirmed by MDM server
for particular endpoint
DeviceRegisterStatus Endpoint is known to MDM server and been previously registered
DiskEncryptionStatus Disk encryption is not enabled on the endpoint
IMEI IMEI value. Match based on endpoint IMEI value from MDM server
response
JailBrokenStatus Match endpoint status JailBroken based on MDM server response
Manufacturer Manufacturer name. Match based on mobile device manufacturer name
from MDM server response
MDMFailureReason FailureReason value
MDMServerName Match based on MDMServerName from endpoint attributes
MDMServerReachable Match reachable status of MDM server
MEID MEID Value. Match based on endpoint mobile equipment
identifier(MEID) value from MDM server response
Model Model Value. Match based on mobile device model from MDM server
response
OsVersion OsVersion Value. Match based on mobile device OS version from MDM
server response
PhoneNumber PhoneNumber Value. Match based on phone number of mobile device
PinLockStatus Pinlock disabled on endpoint
SerialNumber SerialNumber Value. Match based on mobile device serial number from
MDM server response
ServerType Server on which endpoint registered belongs to Desktop Device
Manager type (ex: Microsoft System Center) or Mobile Device Manager
type (regular MDM server)

MDM Attribute Description
UDID UDID Value. Match based on Unique Device Identifier (Apple specific)
UserNotified User has not been notified previously about requirement to register
device (Desktop Device Manager specific check)

Please note that this document will not cover the integration of ISE with MDM/EMM.

Design
Single vs. Dual SSID Flow
As noted earlier there are two BYOD flows. Here we will compare the two BYOD
flows. First let’s look at the flow of Single SSID flow:
As its name signifies there is only one SSID used for the onboarding, which is secured
by 802.1X. User initially connects using username/password and is registered then
optionally can get a signed endpoint certificate issued to the endpoint which is used
to reconnect to the same SSID and gets elevated access.
Now let’s look at the dual SSID flow:

In the case of dual-SSID flow, user initially starts on one SSID which may be shared
with guest access. But once onboarded, the endpoint is reconnected to the secured
SSID to gain elevated access. The initial SSID may be secured via WPA-PSK if the
WLC supports WPA-PSK and ISE-NAC (RADIUS-NAC on the same WLAN).
Note that when guest portal is used for BYOD flow, all employee users will go through
the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using
the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal
can be used based on authorization condition. This flow allows, for instance, different
user groups to have different BYOD portal and also allows each groups to register the
devices into different endpoint groups.
Note that in either flow, once the devices have been onboarded, there is no difference
in terms of the access to the secured network. Here are pros and cons of the different
BYOD flows:
Single SSID Dual SSID Dual SSID w/
differentiated BYOD
portal

differentiated BYOD
portal
Pros User experience is better for iOS
users as SSID switching from OPEN
to SECURED does not require user
intervention

This is a unique capability of ISE
where competitor solution forces
user to login twice while ISE can
take user information from 802.1X
session without asking for the user
to login again to the web portal

Can provide different BYOD portal
based on authorization condition.
BYOD portal can be tied to different
endpoint group for registration.
Some organizations
prefer having a
dedicated SSID for on-
boarding devices.

Can provide visible
guidance to the user on
the BYOD process
before logging in

Better security: User can
confirm that the BYOD
server is legitimate as
the user does not get
prompted to manually
trust the EAP certificate

ID Store is LDAP and
cannot start with PEAP
with MSCHAPv2
currently to LDAP store

Wired deployment
where cannot assume
client already has
802.1X enabled on
wired interface

Can be configured to
use secured SSID that is
not broadcasting

In the case of dual-SSID
flow, BYOD portal can
be configured to allow
guest access if
employee does not want
to go through the BYOD
flow
Some organizations
prefer having a
dedicated SSID for on-
boarding devices.

Can provide visible
guidance to the user on
the BYOD process
before logging in

Better security: User can
confirm that the BYOD
server is legitimate as
the user does not get
prompted to manually
trust the EAP certificate

ID Store is LDAP and
cannot start with PEAP
with MSCHAPv2
currently to LDAP store

Wired deployment
where cannot assume
client already has
802.1X enabled on
wired interface

Can be configured to
use secured SSID that is
not broadcasting

Can provide different
BYOD portal based on
authorization condition.
BYOD portal can be tied
to different endpoint
groups for registration.

differentiated BYOD
portal
Cons Fast-SSID change setting needs to
be enabled on the WLC to
accommodate iOS devices

When end users connect to the
SSID for the first time there is no
easy way to validate whether server
provided certificate is from the
trusted source
Others see dual SSID as
an extra management
burden.

A second SSID adds
channel overhead and
may degrade wireless
performance
Requires iOS users to
manually switch SSID

Pre-authentication ACL
is shared between guest
and employee users
Others see dual SSID as
an extra management
burden.

A second SSID adds
channel overhead and
may degrade wireless
performance
Requires iOS users to
manually switch SSID

Some client OS may
have issues with multiple
redirects

PKI and ISE Internal CA
Although issuing signed certificates to the endpoints for BYOD is optional, many
customers will consider issuing certificates to the endpoints as it provides better
security and user experience for subsequent connections. When ISE is installed the
internal CA is installed and enabled by default. Here are the characteristics of ISE
internal CA.
- Primary Admin node is the root CA
- Both primary and Secondary admin node is also Sub-CA of the root called
Node_CA. This added layer of hierarchy allows single root hierarchy which simplifies
the deployment when new PSNs are added while the primary node is not the active
admin node
- PSN runs both CA, RA, and OCSP responder
When ISE is installed, the first node will become a Root_CA. Then each of the Admin
node including the first node will become a sub CA of the hierarchy called Node_CA.
This added layer of CA hierarchy was done to ensure the ISE BYOD certificate
authority is setup with single root. This makes the deployment much simpler as it
allows PSNs to be added at a later time regardless of which admin node is up during
the addition of PSN. In the below diagram, even though PSN3 was added while S-
PAN (Secondary PAN) was active, the certificate hierarchy is still maintained up to the
Root-CA. This allows certificates generated by PSN3 to be trusted by the other PSNs
without additional work.

Also, note that all the nodes run both RA and CA services along with OCSP. Both
Registration Authority (RA) and Certificate Authority (CA) is required for ISE to validate
requests and issue certificates to the endpoints. Having both services on each node
ensures that certificates can be issued autonomously by each PSN. Also, the Online
Certificate Status Protocol (OCSP) service confirms whether the certificate is still valid
or not and having the OCSP service locally on PSN node ensures all aspects of BYOD
operation can be covered by each PSN. Note that ISE Internal CA does not support
CRL as OCSP is available for CRL checking.
When it comes to PKI, ISE can be deployed in 3 options. First two leverages the
internal CA feature and are mutually exclusive, while the last option simply proxies the
signing requests to 3 party CA server and can also be enabled along with first or
second option.
Self-Signed CA
This is the initial state of the ISE BYOD setting. The Internal CA i
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 a
opposed to having unified PKI for enterprise use and BYOD. Wit
separate PKI, it is easier to assign different permissions for BYO
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 alread
trusts the existing CA If this is mode of operations that is
rd

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 reques
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.htm

The following table summarizes the 3 ways ISE can issue signed certificates to the
endpoint:
SCEP to enterprise CA Sub CA of
enterprise PKI
ISE Self-Signed CA
Pros Provide single point of
management for all endpoint
certificates; 3 party CA console
as ISE simply proxies all certificate
signing request to 3 party CA
ISE Internal
Certificates need to
be re-issued if
already deployed as
distributed
deployment
Easiest deployment method.
No configuration is necessary.
ISE is already enabled with
Self-signed CA to use with
BYOD endpoints

If there is existing PKI, ISE
internal CA provides
distinction between enterprise
CA issued certificates for
managed devices, vs. BYOD
rd
rd

SCEP to enterprise CA Sub CA of
enterprise PKI
ISE Self-Signed CA
Cons Most complex deployment mode

Only been validated with MS CA
(Requires MS enterprise license
for SCEP feature)

There may be licensing cost with
3 party CA for each signed
endpoint certificate
There may be
licensing cost with
3 party CA for
each signed
endpoint certificate
Additional effort may be
needed to ensure the self-
signed CA is trusted on the
network.

Captive Network Assistant
Apple CNA (Captive Network Assistant, AKA Apple mini browser) is an Apple iOS
feature that allows a browser like window to pop-up whenever network access is
needed and the CNA determines that the network requires user interaction to gain full
network access. This typically happens when the user associates to an open wireless
LAN and even though an IP address is provided to the device, the network still
restricts the user to take further actions, such as accepting an Acceptable Use Page
(AUP), providing a shared password, or logging in as a guest user. This enhances
user experience as it saves the user from manually opening up a Safari browser
window. It also provides assistance even during non-initial association to the WLAN.
For instance, if the endpoint device goes into sleep mode and the session is torn
down on the WLC and subsequently the user tries to use a non-web browser
application that requires network connectivity, the iOS device can sense that the
device is in captive portal state and pop-up the mini browser for user to take further
action to gain network access. As one can see having the iOS CNA feature operate
on a guest network is a good idea, however, when BYOD is enabled on the same
WLAN, as is the case with ISE dual-SSID flow, the CNA breaks the ISE BYOD process.
One of the reason for that is due to ISE BYOD process forcing the CNA mini browser
to go into the background as it asks the end user to accept the iOS profiles, which
includes CA certificate and enrollment package, and when the CNA mini browser is
moved to the background it immediately disconnects the device from the WLAN,
which in turn breaks the BYOD process.
Prior to ISE 2.2, the ISE was setup to warn the user that the browser is not supported
and user had no easy way aside from reporting it to the network administrator and
subsequently the administrator had to enable captive bypass on the WLC which
disabled the pop-up of the CNA mini browser on the controller level. Unfortunately,
the captive bypass feature on WLC 8.3 and below required to be ran controller wide,
which meant that all of the WLANs that the controller was servicing disabled the apple
CNA. Cisco ISE version 2.2 is the first version to support Dual-SSID BYOD flow
rd
rd

through Apple CNA. Here is link to the document that explains how to configure the
ISE and Cisco WLC to provide Dual-SSID BYOD even when the captive portal bypass
feature is disabled on the WLC https://communities.cisco.com/docs/DOC-71398
For other options on how to deal with Apple CNA, please go to following document:
Dealing with Apple CNA (AKA Mini browser) for ISE BYOD
https://communities.cisco.com/docs/DOC-71469
DNS ACL
For Android device and Chromebook, endpoint OS requires endpoint access to the
Google play store and Chrome extensions while going through the ISE BYOD process.
This is different from Apple iOS, macOS, and Windows BYOD process. For Apple iOS
ISE leverages native OTA capabilities to provision certificates and network settings,
and for macOS and Windows ISE provides Network Setup Assistant that is pushed to
the endpoint locally from the ISE node which does not require endpoint access
beyond the ISE node itself.
To allow the Android devices and Chromebook to download the Network Setup
Assistant, the easiest way to get the NSA downloaded to the endpoint is to do it prior
to going through the BYOD flow. This can be done out-of-band by notifying users to
download it from the play store while connected to the Internet by other means.
However, if the endpoint going through the BYOD does not have NSA pre-
downloaded, the way to control access to the Google play store and Chrome
extension is via DNS ACL feature available on Cisco WLC 7.6 and above. This feature
works by snooping the endpoint DNS request from the AP and dynamically inserting
IP ACL for the DNS response that endpoint gets from the DNS server. Aside from the
WLC version, here are additional notes around this feature:
The ACL prepends and appends wildcard which means a string value of .google.co will
match play.google.com and also www.google.co.ca
Not supported on auto-anchored WLAN
WLC AireOS version 8.2 and above can support up to 20 DNS ACE while previous versions
can support up to 10 DNS ACE
WLC AireOS version 8.7 and above supports DNS-ACL with FlexConnect ACL
Not supported on Auto-Anchored WLAN

Deploy

To understand configuration needed to make ISE BYOD work, this section is broken
down into smaller parts.

First is the Setup part which describes steps needed to configure the WLC and
general global BYOD settings on ISE. The major part of the configuration will be in
Policy section. ISE utilizes multiple policy to control how authentication and
authorization flows, but also for controlling how endpoints are onboarded for BYOD.
As such there are two main policies to modify, one is the policy set, which includes
both authentication and authorization and the other policy is the Client Provisioning
policy which controls which OS is supported for BYOD and how the endpoints will get
onboarded as well as how the certificates will be signed. Following table shows the
difference between the two policies:
Policy Type Description
Client
Provisioning
Policy
This is policy to control which BYOD profile will be pushed based on endpoint
type or user group. BYOD profile includes certificate template, SSID name, proxy
settings, etc.
Authentication
&
Authorization
Policy
This is the policy to control which portal will be presented to the user going
through the BYOD flow. It also dictates how user will be authenticated and which
network or SSID will be forced to go through BYOD. It can also control what to
do in the event of expired certificates.

Aside from policies, there are elements that comprises the policy such as Certificate
template and Native Supplicant Profile. Certificate template controls how the endpoint
certificate will be signed including subject name, key size, and duration. The NSP
controls which certificate template to use and how the network setting will be
configured on the endpoint, including SSID name, EAP-Type, proxy settings and
more.

Lastly, there are two portals that end user can use as part of the ISE BYOD. My
devices portal and the certificate provisioning portal. This document will describe
where the settings are located for these two portals and show to control access to
the portals.
Following diagram shows the relationship between various elements and the two
policies.
Configure Network Device
This section assumes the Cisco WLC and the network is already setup with basic
settings, including management IP, interfaces, and DHCP. This section will go through
setting up WLC/ISE communication using RADIUS, relative WLANs, and ACLs. For
complete Cisco WLC configuration for ISE please use:
https://communities.cisco.com/docs/DOC-68172
Enable fast-ssid-change feature (Optional)
This is needed for Dual-SSID flow for better user experience. Enabling this feature
allows wireless clients to transition from Open SSID to Secured SSID without delay. In
dual SSID flow, if the transition from Open to Secured SSID keeps on failing on the
endpoint, then check the following on the WLC settings:
1. Access the WLC GUI and navigate to Controller > General
2. Enable Fast SSID Change
3. Click Apply and Save Configuration

Configure ISE as RADIUS Authentication and Accounting server
1. Go to Security > RADIUS Authentication
2. Click New... on the top-right corner to add a new RADIUS authentication server
3. RADIUS authentication server settings are listed in the table below (Use default value if not
specified)

Attribute Value or description
Server Index
(Priority)
{Available Index Value}
Server IP
Address
{ISE PSN IP}
Shared Secret
Format
ASCII
Shared Secret {Shared RADIUS Key}
Port Number 1812
Server Status Enabled
Support for
RFC 3576
Enabled (This option enabled CoA)
Server Timeout 5 (Recommended to use 5 seconds or higher)
Network User Disabled (As the RADIUS server is defined in the AAA section of WLAN,
this can be disabled globally)
Management Disabled

4. Click Apply and Save Configuration.
5. Click Accounting and New... to add RADIUS accounting servers
6. RADIUS accounting server settings are listed in table below (Use default value if not
specified)

Attribute Value or description
Server Index (Priority) {Available Index Value}
Server IP Address {ISE PSN IP}
Shared Secret Format ASCII
Shared Secret {Shared RADIUS Key}
Port Number 1813
Server Status Enabled
Server Timeout 5
Network User Disabled

7. Click Apply and Save Configuration (If there are multiple ISE PSN nodes, add both RADIUS
authentication and accounting for each PSNs)

Create Redirect ACL
Single ACL will be created for redirect that applies to both single-SSID flow and dual-
SSID flow
1. Go to Security > Access Control Lists > Access Control Lists
2. Click on ‘New’ and create ‘ACL_WEBAUTH_REDIRECT’ ACL with following parameters. The
ACL name ‘ACL_WEBAUTH_REDIRECT’ is the default ACL name referenced by ISE, so if
using different ACL name on the WLC, make sure to change it on the ISE Authorization profile
as well. Note that the WLC ACL is stateless so reverse of the allowed ACE needs to be
created.

Action Source IP / Mask Dest. IP / Mask Protocol Source
Port
Dest
Port
Directio
Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8443 Any Outbou
Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8443 Inbound
Permit
{ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8084 Any Outbou
Permit
0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8084 Inbound
Note: Even when explicitly not stated, DHCP and DNS is permitted pre-web-authentcation on
the WLC. If you would like to deny access to Internet DNS servers, ACL can be added to limit
DNS to certain servers. Also note that this ACL works with ISE 2.4, however older version of
ISE may require additional TCP ports to be open.
3. Click ‘Back’ on the top right corner
4. Click down arrow next to the ACL and select ‘Add-Remove URL’
5. Here enter following entries one by one

.google.co
accounts.youtube.com
gstatic.com
.googleapis.com
.appspot.com
ggpht.com
gvt1.com
market.android.com

android.pool.ntp.org
.googleusercontent.com
.google-analytics.com
6. Click Back
7. Click Apply

Create Blacklist ACL
Single ACL will be created for Blacklist portal
1. Go to Security > Access Control Lists > Access Control Lists
2. Click on ‘New’ and create ‘BLACKHOLE’ ACL with following parameters. The ACL name
‘BLACKHOLE’ is the default ACL name referenced by ISE, so if using different ACL name on
the WLC, make sure to change it on the ISE Authorization profile as well. Note that the WLC
ACL is stateless so reverse of the allowed ACE needs to be created.Note that this ACL
allows full IP access to the ISE node but can be changed to limit ISE exposure from end
users.

Action Source IP / Mask Dest. IP / Mask Protocol Source
Port
Dest
Port
Directio
Note: Even when explicitly not stated, DHCP and DNS is permitted pre-web-
authentcation on the WLC. If you would like to deny access to Internet DNS
servers, ACL can be added to limit DNS to certain servers
3. Click ‘Back’ on the top right corner
4. Click Apply

Secured SSID
1. Go to WLAN
2. Click on Add New and create WLAN with following parameters
Tab Attribute Value or description
General WLAN ID Available WLAN ID
Profile Name /
SSID
Secured
Status Enabled

Security Layer 2
Security
WPA+WPA2
WPA+WPA2
Parameters
WPA2 Policy
WPA2
Encryption
AES
Authentication
Key
Management
802.1X
Layer 3 Captive Network Assistant Bypass Enabled
AAA Servers Authentication & Accounting Enabled and ISE PSN nodes selected
(If multiple PSNs defined, list them here for both Authentication &
Accounting in order)
RADIUS
Server
Accounting
Interim Update Enabled, Interim Interval 0
Advanced Allow AAA
Override
Enabled
NAC State ISE NAC (Or RADIUS NAC)
RADIUS Client
Profiling
HTTP & DHCP Enabled

Open SSID (Optional)
If there is an existing guest WLAN, same portal can be used for employee BYOD as
well. As employee user logs in to the guest portal ISE recognizes the guest users and
employee users and apply different flows. For guest users, ISE automatically applies
guest related access. Only named guest access portal such as self-service or
sponsored guest portal can be used as employee BYOD portal at the same time. If
hotspot guest access is used, then the same portal cannot be used for both hotspot
and employee BYOD portal. To create the open WLAN:
1. Go to WLAN
2. Click on Add New and create WLAN with following parameters
General WLAN ID Available WLAN ID
Profile
Name /
SSID
Open

Status Enabled
Security Layer 2
Security
None, MAC Filtering
Layer 3 Captive Network Assistant Bypass Enabled
AAA
Servers
Authentication & Accounting Enabled and ISE PSN nodes selected (If
multiple PSNs defined, list them here for both Authentication &
Accounting in order)
RADIUS
Server
Accounting
Interim Update Enabled, Interim Interval 0
Advanced Allow AAA
Override
Enabled
NAC State ISE NAC (Or RADIUS NAC)
RADIUS
Client
Profiling
HTTP & DHCP Enabled

Define Network Device
Starting with his section, the configurations are for the ISE itself. This document
assumes the Cisco ISE is installed and the management IP address is accessible via
GUI.
1. Go to Administration > Network Resources > Network Devices
2. Click on Add
3. Provide Name, IP
4. Check RADIUS Authentication Settings and the section will expand for more options
5. Provide Shared Secret
6. Click Save

Attribute Value
Name Name of the NAD
IP IP address of the NAD
RADIUS Shared Secret Shared secret between ISE and NAD

Define Global settings
To Control how many devices that can be registered by each user, go to Work
Centers > BYOD > Settings > Employee Registered Devices and change the value in
the box. The default is 5 devices, but can be set between 1 to 999 devices. Note that
this applies to all BYOD users globally.
The Retry URL allows administrator to configure URL that ISE will try to force a new
URL-Redirect when the initial onboarding flow failed for any reasons. For instance, if
the user abandoned the onboarding flow in the middle and came back, the existing
session may have been torn down and the user will need to re-initiate the flow. ISE
re-initiates this by forcing the browser to try the retry URL specified in the setting. By
default, if the Retry URL is not specified, ISE will try 1.1.1.1 to force a redirect.
By default, devices without NSA support follows the main authorization policy for
network access, but to allow network access unconditionally for unsupported devices,
select ‘Allow Network Access’ for the ‘Native Supplicant Provisioning Policy
Unavailable’ option.
Managing and Defining Certificate
Template
This is an optional step if EAP-PEAP-MSCHAPv2 or EAP-FAST will be used instead of
EAP-TLS. Fresh ISE installation comes with default certificate template called
‘EAP_Authentication_Certificate_Template’
, which is used when signing certificates
during BYOD flow. Subject content can be populated to reflect the customer’s
environment but also note that the content within the subject can be used during
authorization to assign different permissions. For instance, two separate certificate

template can be created for two different Organization Unit and used to provision
certificates to two different OU. When the BYOD devices connect back after being
onboarded, ISE can use the OU to differentiate and assign different ACLs or VLANs.
Existing certificate template should work for most environment, but it is recommended
to change the subject attributes to reflect the site that ISE is being deployed at.
Additionally, the certificate properties such as key type, key size, and valid period can
be changed with the template as well. To change the CN (organization, organization
unit, city, state, and country) and other certificate properties, follow the steps below.
1. Go to Administration > System > Certificates > Certificate Authority > Certificate Templates
2. Click on Add (Or Edit to edit default ‘EAP_Authentication_Certificate_Template’)
3. Enter Site specific information in the Subject fields. CN field is auto populated by ISE with the
user ID of the user going through the BYOD process
4. ISE also auto populates endpoint MAC address in to the certificate SAN field. The endpoint
MAC address is collected during initial authentication of the endpoint either via MAB or
802.1X and embedded in to the certificate for security purpose. By doing so, ISE policy can
be crafted to match the actual endpoint MAC address and the certificate MAC address to
prevent BYOD issued certificates from being used for other endpoint other than the one that
was issued for.
5. The template also allows settings to change Key Types (RSA & ECC), Key Size, and Valid
Period. Valid period for the certificates can be changed from default of 2 years to maximum

of 10 years. Note that newer client OS requires key size of 2048 or bigger

Attribute Value
Name Name of the Certificate Template. Provide descriptive name as this field can be
used as AuthC/Z condition
Subject CN is auto populated with the username that is going through the BYOD flow. Other
attributes can be entered here to reflect the site. If differentiating different endpoint
or users based on certificate is needed, then any of the attributes here can be
changed and can be used during AuthZ to provide differentiated access. For
instance if OU=HR, the endpoint can have access to HR resources, while other
endpoints cannot access HR resources
Subject
Alternative
Name
(SAN)
Currently, only value available is the MAC Address. The MAC Address is pulled
from the RADIUS session from the endpoint that initiated the BYOD flow. This is one
way ISE allows admin user to tie the certificate to the actual endpoint that it was
signed for.
Key Type RSA or ECC. ECC is currently supported by Windows and Android devices only.
Key Size 1024, 2048, 4096. For compatibility, recommended minimum value is 2048.
SCEP RA
Profile
ISE Internal CA. If using SCEP to 3 party CA, then this setting can be changed to
send certificate signing request to 3 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
rd
rd

secured WLAN that is used. Follow the steps below to make changes to the existing
NSP or create a new NSP. If creating new NSP, then the Client provisioning policy
needs to be modified to use the newly created NSP.
1. Go to Policy > Policy Elements > Results > Client Provisioning > Resources
2. Edit Cisco-ISE-NSP (Or Add > Native Supplicant Profile)
3. If editing default NSP, there is existing SSID ‘ISE’
, which can be edited for the secure SSID
used on site. Edit the default SSID by checking it and clicking on Edit
4. Change SSID Name
5. (Optional) Configure proxy related settings
6. Recommended to leave Security to WPA2 Enterprise
7. For Allowed Protocol, select among TLS (For digital certificate), PEAP (For username &
Password), or EAP-FAST (For macOS and iOS). Note that if TLS is used, certificate template
needs to be selected as well.
8. Expand Optional Settings can be used to configure additional settings:
1. For Windows endpoints, use of machine or user store for certificate settings SSID
broadcast settings can be set here
2. For iOS devices, SSID broadcast settings can be set here
9. Click Submit
10. If Wired interface is to be used, then ‘Wired Profile’ check box can be enabled for Windows
and macOS

Within the the Client Provisioning Resources page, updated version of NSA for
Windows and macOS can be downloaded. To download latest NSA, follow the
directions here:
1. Click on Add > Agent Resources from Cisco site
2. After screen refreshes there will be list of available agents that can be downloaded from
Cisco site. This includes NSA as well as posture agents (If the ISE node does not have
access to the Internet, this page will not be able to download the NSA, in that case,
download the NSA manually from cisco.com and add them manually by using Add > Agent
Resources from local disk). Select latest version of MacOsXSPWizard x.x.x.x and
WinSPWizard x.x.x.x.
3. Click Save

4. Once downloaded, the newly downloaded NSA can be used in Client Provisioning Policy

Manage Client Provisioning policy
Client Provisioning policy dictates what OS will be supported and which NSP will be
used. Designation of NSP also controls which certificate template will be used to sign
endpoint certificates. Also, if new NSA has been downloaded, Client Provisioning
policy can be updated to reflect which NSA will be used to assist user to onboard the
device. This may be necessary when new version of endpoint OS have been
introduced to the market.
Lastly, note that this same policy also affects posture client provisioning as well, which
controls which type of posture agent and compliance module will be enforced.
Although two different client settings are present in a single rule, ISE can enforce
different client settings based on the flow. The top portion titled ‘Agent Configuration’
controls posture agent for the rule, while the bottom portion titled ‘Native Supplicant
Configuration’ controls settings for the BYOD provisioning. Following shows default
Client Provisioning policy on newly installed ISE 2.4 system which includes policy rule
for ISE supported OS.
In general, the existing client provisioning policy should work for most environments,
however, if new NSA for Windows or macOS has been downloaded, then the client
provisioning policy will need to be updated to reflect the change. Also, if different
native supplicant profile other than the system provided one is used, then the client

provisioning policy needs to be updated to reflect the change. Lastly, if separate NSP
is required for certain set of users, ‘Other Conditions’ can be modified to match
certain user groups to specific NSP. To create new Client Provisioning rule:
1. Go to Policy > Client Provisioning
2. All of the OS policies are already predefined, however, if new policy is needed click on the
down arrow on the right of any rule and select ‘Insert new policy …’ (Note that the policy
works top down, so if there are more specific rule that needs to be matched, ensure that the
new rule is on top of other rules)
3. Provide Rule name
4. If specific rule should match on certain internal user or endpoint group, it can be specified
here
5. Select Operating Systems. If specific version of Windows or macOS needs to specified, then
it can be specified here
6. Use Other Conditions to further qualify policy rule. AD groups/attributes, location, EAP-
Types, etc. can be used here.
7. Result section dictates version of NSA and NSP. Note that version is only available if Windows
and macOS is selected for the Operating Systems as these two OS downloads NSP directly
from PSN, while other OS relies on native capability or from cloud resources.

Creating policy for Single-SSID
BYOD flow
When ISE is installed, there are set of AuthZ policy rules that are pre-created for
BYOD flow. Although the policy rules are in place, the rules are deactivated. Admin
user can simply enable the two rules to activate BYOD policy. The two rules are
‘Employee_EAP-TLS’ and ‘Employee_Onboarding’
.
When the user connects to the secured SSID using username and password, the
user’s endpoint does not have digital certificate, so the session will match
‘Employee_Onboarding’ policy rule which forces the endpoint to be onboarded. As
the endpoint goes through onboarding flow, the endpoint MAC address is registered
to ISE and the signed certificate is provisioned to the endpoint, at that point the
endpoint will be forced to reauthenticate to the same SSID where the session will
match ‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess
permission.

Although
pre-
configure
d policy
rules work
for simple
deployme
nts, when
setting up ISE Authentication and Authorization policies, it is recommended to create
separate policy set for each SSIDs. By doing so the policies are much easier to view
and predictable. Here we are going to create a policy set for Secured SSID used for
single-SSID BYOD flow. Initially the endpoints associate to the SSID using username &
password using PEAP-MSCHAPv2. When user opens up a web browser, instead of
getting to the user’s browser destination or home page, the user will get redirected to
BYOD portal where the user is guided to follow steps to get the endpoint onboarded.
1. Go to Policy > Policy Sets
2. Click on ‘+’
3. Change the new policy set name to ‘Secured SSID’
4. In the conditions use ‘Normalized RADIUS : SSID ends with SECURED’
5. Click on Use
6. Select Default Network Access for Allowed Protocols
7. Click Save
8. Click on ‘>’
9. Click on ‘>’ on Authorization policy
10. Click ‘x’ on Deny Access on Results:Profiles Column
11. Select NSP_Onboard
12. Click ‘+’ above default rule
13. Change name to ‘TLS’
14. Click on ‘+’
15. In the conditions use ‘Network Access:EAPAUthentication equals EAP-TLS’ (Other conditions
such as matching on certificate SAN with the MAC address learned from RADIUS session as
well as BYOD registered status can be used here as well)

16. For Results:Profiles Column select PermitAccess
17. Click Save

Creating policy for Dual-SSID
BYOD flow
As with the Single SSID flow, also for dual SSID, when ISE is installed, there are set of
AuthZ policy rules that are pre-created for BYOD flow. Although the policy rules are in
place, the rules are deactivated. Admin user can simply enable the two rules to
activate BYOD policy. The two rules are ‘Employee_EAP-TLS’ and
‘WiFi_Redirected_to_Guest_Login’
. The ‘WiFi_Redirected_to_Guest_Login’ rule is also
used for general self-service named guest access.
If self-service guest service is not needed, then it can be disabled from the guest
portal settings. This can be done by going to the guest portal in use for BYOD
purpose and unchecking the ‘Allow guest to create accounts’ option.
To make guest portal also support employee BYOD, the BYOD setting on the portal
needs to be modified. Go to the guest portal and expand ‘BYOD Settings’
, then check
‘Allow employees to use personal devices on the network’ option. Notice that as soon
as this option is checked the contextual guest flow diagram on the right reflects the
change. The ‘Allow employees to choose to guest access only’ option allows the
employees to bypass the BYOD process and opt to get guest access only.

Note that when guest portal is used for BYOD flow, all employee users will go through
the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using
the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal
can be used based on authorization condition. Instructions on how to configure the
flow is shown in the appendix.
In the case of dual SSID BYOD, when the user connects to the open SSID, the
endpoint is unconditionally authorized to limited network access which provide
enough access to get to ISE guest portal.
This is done by using advanced authentication options for MAB to ‘CONTINUE’ even
when user is not found. The ‘CONTINUE’ option in the Authentication policy allows
unknown MAC addresses to bypass authentication and get conditionally authorized to
limited access where the endpoint can reach the ISE portal page for web login. This
allows the user to open up the web browser, and the user is redirected to the guest
portal. When the user logs in using username and password, ISE identifies the user as
employee as the account used to login to the portal is not in the guest user database,
which forces the user to BYOD portal instead of guest access.

As the endpoint goes through onboarding flow, the endpoint MAC address is
registered to ISE and the signed certificate is provisioned to the endpoint, at that point
the endpoint will be forced to reconnect to the secured SSID where the session will
match ‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess
permission.
If not using default policy set, then following instructions can be used. Here we are
going to create a policy set for Open SSID used for dual-SSID BYOD flow. Initially the
endpoints associate to the Open SSID. When user opens up a web browser, instead
of getting to the user’s browser destination, the user will get redirected to guest
portal. When user enters credential for employees to the guest portal the user is
guided to follow steps to get the endpoint onboarded. The ISE can differentiate
between the employees and guests by identifying the identity store that is being used
at the time of authentication. Since the endpoint will connect to the secured SSID
after the onboarding is complete, the steps for single-SSID flow needs to be
completed. Also note that the BYOD portal has no bearing when using dual-SSID flow
as the BYOD flow is subset of the main guest portal.
1. Go to the Guest portal that is currently referenced by ‘Cisco WebAuth’ Authorization profile (If
this is fresh install of ISE, then it should be ‘Self-Registered Guest Portal (Default)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Click ‘Allow employees to use personal devices on the network’
6. Scroll up and click ‘Save’
7. Go to Policy > Policy Sets
8. Click on ‘+’
9. Change the new policy set name to ‘Open SSID’
10. In the conditions use ‘Normalized RADIUS : SSID ends with OPEN’

11. Click on Use
12. Select Default Network Access for Allowed Protocols
13. Click Save
14. Click on ‘>’
15. Click on ‘>’ on Authentication policy
16. On the ‘Use’ column, select Internal Endpoints instead of All_User_ID_Stores
17. Click on ‘> Options’
18. Change If User Not found from REJECT to CONTINUE (Setting this as CONTINUE allows ISE
to unconditionally authenticate the unknown MAC addresses so the session can continue
through the Authorization instead of getting instant REJECT. This is essential to make the flow
work as most of the endpoints connecting to the Open SSID will be initially unknown to ISE
and yet, ISE needs to be able to assign limited network access so user can be directed to the
ISE portal page)
19. Click on ‘>’ on Authorization policy
20. Click ‘x’ on Deny Access on Results:Profiles Column
21. Select Cisco WebAuth
22. Click Save (In real deployment if the same portal is used for guest users then we would be
creating the guest access rule as above the default rule)

Note about different ISE portals
So far the document provided instructions on how to use Guest portal and BYOD
portal, however, there are other portals that can be used to provide more control for
the end users:
Portal Type Config
Location
Used for
Guest
Portal
Work Center >
Guest Access
> Portals &
Components >
Guest Portals
User portal that end user goes through for onboarding. This is
only used for dual-SSID flow. Existing guest portal can be used
for guest and BYOD at the same time, provided that the customer
is using named guest access as opposed to hotspot guest
access.

Portal Type Config
Location
Used for
BYOD Portal Work Center >
BYOD >
Portals &
Components >
BYOD Portals

Or

Administration
> Device
Portal
Management
> BYOD
User portal that end user goes through for onboarding. This is
only used for sing-SSID flow
Blacklist
Portal
Administration
> Device
Portal
Management
> Blacklist
User portal for users with endpoints in blacklist group. Instead of
denying network access for blacklisted devices, it may be useful
to provide visual guidance on how to proceed to get the device
back on the network when their device is blacklisted.
My Devices
Portal
(MDP)
Work Center >
BYOD >
Portals &
Components >
My Devices
Portals

Or

Administration
> Device
Portal
Management
> My Devices
Used for end users to manage their own devices. Here users can
view onboarded devices as well as add devices manually. User
can also mark devices as stolen or lost which can impact
network access. If ISE is integrated with MDM/EMM, user can
also issue lock, full wipe, and corporate wipe from the portal.
Certificate
Provisioning
Portal
Administration
> Device
Portal
Management
> Certificate
Provisioning
Portal
Used for signing and generating certificates manually.
Certificates can be signed by importing CSR or certificate pair
can be generated from the portal. Access to the portal can be
controlled via ID store and groups.

Setting up Blacklist Portal
(Optional)
The blacklist portal is already setup but note that it runs on different TCP port 8444
compared to the guest or BYOD portal which runs on 8443. Also, the blacklist portal
utilizes different ACL on the WLC. The policy for Blacklisted devices is already created
and active, but following steps can be used to change the content that users are
presented when their devices are blacklisted:
1. Go to Administration > Device Portal Management > Blacklist
2. Click on Blackist Portal (default)
3. Click on Portal Page Customization
4. Page title and the message can be modified
5. Click Save

Note that the policy for blacklist is already setup and enabled on ISE, It still requires
the ‘BLACKHOLE’ ACL to be present on the NAD to work.
Setting up My Devices Portal
(Optional)
The My Devices Portal is hosted on the PSNs and already enabled by default. MDP is
typically used for non-guest end users to manage their personal devices. Follow the
below steps to reconfigure the behavior of My Devices Portal
1. Go to Work Centers > BYOD > Portals & Components > My Devices Portals
2. Click on My Devices Portal (default)
3. Expand Portal Settings
4. Certificate group tag
5. Fully qualified domain (FQDN) and host names (If FQDN is configured here, the DNS server
needs to be updated to point to PSNs as well in order to direct users to the MDP using
FQDN. Also, if the portal certificate used is not a wildcard certificate, it should also contain
the FQDN as SAN to avoid security popup on the web browser trying to access the portal)
6. Endpoint identity group

7. Authentication method (Currently, there is no way to control access to the MDP based on end
user groups from internal ID or AD. In other words, if an ID store is enabled to login to MDP,
any user with valid user credential can access the MDP)
8. Scroll up and click on Portal Page Customization
9. Under Pages, click on Manage Device
10. Click on Settings on the right hand preview pane
11. You can select which options are available to end users

Setting up Certificate provisioning
portal (Optional)
The Certificate Provisioning Portal is hosted on the PSNs but authorization groups
need to be assigned before user can login to the portal. Follow the below steps to
reconfigure the behavior of Certificate Provisioning Portal
1. Go to Administration > Device Portal Management > Certificate Provisioning
2. Click on Certificate Provisioning Portal (default)
3. Expand Portal Settings
4. Certificate group tag
5. Authentication method
6. Configure authorized groups
7. Fully qualified domain (FQDN) and host names (If FQDN is configured here, the DNS server
needs to be updated to point to PSNs as well in order to direct users to the Certificate
Provisioning Portal using FQDN. Also, if the portal certificate used is not a wildcard certificate,
it should also contain the FQDN as SAN to avoid security popup on the web browser trying to
access the portal)

Operate
Review Single-SSID BYOD Flow

Step User Experience
1

2

3

4

5


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

1

2
3

4

5


ISE Live log
1. Starting from the bottom, the user associates to the open SSID, the user is unknown and is
identified as the MAC address as the user has not logged in
2. User logs into the guest portal as Employee user
3. The lines with only Endpoint ID represents CoA that was successful. Multiple CoA may be
sent depending on the CoA settings to ensure proper endpoint session is assigned
4. Shows the endpoint Authorization Profile transitioned from Cisco_WebAuth to PermitAccess
5. Top most line indicates the session which combines the RADIUS authentication to the
information learned from RADIUS accounting which includes the endpoint IP Address

Using self-signed certificate on
ISE
If the ISE is not using 3 party signed certificate, Apple iOS 11 and above does not
allow the user to accept the enrollment profile without first trusting the ISE certificate
as trusted CA. It is recommended to use ISE certificate that is already signed by well-
known CA to avoid getting errors during the BYOD flow. In case the ISE is using the
self-signed certificate, user will need to manually trust the certificate in to the trusted
root CA within iOS. This is done by going to iOS settings after step 4.
Step User Experience Note
4a During the last step of the flow in either single or dual SSID
flow described in the previous steps, instead of succeeding in
the provisioning flow, user will get following error page: Profile
installation Failed
4b On the iOS click home button, go to Settings > General >
About > Certificate Trust Settings. Enable the trust for the
certificate as root CA by sliding the option bar to the right and
select Continue to accept the changes
rd

4c Click Home button and open Safari and go through the BYOD
flow again. This time the flow should be able to complete
without the error.

Note: If Retry button does not work, enter an external URL in
the address bar to initiate redirect.

If the ISE certificate is signed by well-known 3 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
rd

My Devices Portal (MDP) can be used to manage onboarded devices as well as
manually add devices that cannot be onboarded through the NSP flow. Note that
there is no policy associated with the MDP, and anyone with account in the valid
identity store can log in to the MDP. For instance, if AD is enabled with MDP then
anyone with AD credential can login to the MDP to manage endpoints. There are 5
states a device can be set to in the my devices portal
State Status
Registered EP has been through BYOD flow(either NSP or MDP) and is currently
registered(HAS been seen on the network, 20 minute delay from PENDING to
registered because it is done by MnT)
Pending EP has been through BYOD flow(either NSP or MDP) and is currently registered
BUT has NOT been seen on the network yet.
Not
Registered
EP hasn't been through BYOD flow(this is the default for every end point in the
system)
Stolen EP status changed to Stolen by owner or admin. When you identify a device as
stolen, the system prevents the device from connecting to the network. Once
reinstated, the status will revert to Not Registered status and has to be provisioned
before it can connect to the network. For My Devices, device will need to be
deleted and re-added. Devices reported as Stolen are assigned to the Blacklist
Identity Group.
Lost EP status changed to Lost by owner or admin. When you identify a device as lost,
when you identify a device as stolen, the system prevents the device from
connecting to the network. Once reinstated, the status will revert to previous state
prior to reporting as Lost. Devices reported as Lost are assigned to the Blacklist
Identity Group.

Manage issued certificates from
ISE Admin UI
As noted in the previous section, BYOD issued certificates can be revoked by end
user via MDP when the endpoint is marked as stolen. However, as ISE admin user,
one can login to the Admin GUI and also manage the endpoint certificates as well as
monitor the status of the certificates. To revoke certificates from the admin console,
go to Administration > System > Certificates > Certificate Authority > Issued
Certificates, select the certificate to be revoked and click Revoke. The revoked
certificate cannot be undone and if the endpoint needs to get certificate re-issued,
the user has to go through the BYOD flow again.

Note that revoked certificates takes 30 days to be removed from ISE GUI.

Managing Expired certificates
One of the benefits of using endpoint certificates for BYOD is that it is no longer linked
to the username & password which generally has shorter refresh cycle for the
passwords. However, certificates are also created with validity dates which may
impact endpoint access to the network. In general, it is recommended to provide
enough time for life of the endpoint. For instance, for higher educational customers,
admin could set validity period of the endpoint certificates to be 4 years to cover the
student endpoint for the duration of student enrollment at the school or enterprise
may require certificates to be valid for 2 years to match general lifecycle of the mobile
device purchase in the market. Too frequent requirement to refresh the BYOD
certificate may increase calls to the helpdesk and add to the user frustration.
When dealing with expired or near expiry of certificates, ISE provides several options
to address the renewal of certificates.
1. Policy condition: As part of authentication ISE can validate how many days are left on the
certificate that the endpoint is using. Based on the remaining days, ISE can force end users
to renew certificates prior to expiry. There are two conditions that can be used;
CERTIFICATE: Days to Expiry & CERTIFICATE: Is Expired. If allowing endpoints with expired
certificates to authenticate, it is recommended to always use CERTIFICATE: Is Expired in the
authorization rule to limit network access for devices with expired certificates.

2. Authorization profile: Checking ‘Display Certificates Renewal Message’ allows the portal to be
used for renewing certificates that the endpoint is using

3. Allowed Protocol: By default, Cisco ISE rejects a request that comes from a device whose
certificate has expired. However, you can change this default behavior and configure ISE to
process such requests and prompt the user to renew the certificate. EAP-TLS Section in the
Allowed Protocols includes option to allow authentication for expired certificate. This option is
disabled by default as it is not secure to allow expired certificate, but if there is a need to
allow expired certificate to authenticate then this option can be enabled. However, if using
this option, be sure to use AuthZ condition in conjunction with this option to limit access for
users with expired certificate.

Note: Some devices allow you to renew the certificates before and after their expiry.
But on Windows devices, you can renew the certificates only before it expires. Apple
iOS, Mac OSX, and Android devices allow you to renew the certificates before or after
their expiry.

Managing ISE Internal CA
You must back up the Cisco ISE CA certificates and keys securely to be able to
restore them back on a Secondary Administration Node in case of a PAN failure and
you want to promote the Secondary Administration Node to function as the root CA or
intermediate CA of an external PKI. The Cisco ISE configuration backup does not
include the CA certificates and keys. Instead, you should use the Command Line
Interface (CLI) to export the CA certificates and keys to a repository and to import
them. The ‘application configure ise’ command includes export and import
options to backup and restore CA certificates and keys.
For more information on managing ISE Internal CA, please review The ISE
Administrator Guide for Certificate Management in Cisco ISE .


ISE Reports
Although not part of the reports, ISE Live log shows live status of all the authentication
requests including the BYOD endpoints. Here one can confirm which policy the
endpoint is matching.
You can also control which columns are shown as well. Here different attributes can
be enabled or disabled to show or could be dragged in different order as well.

ISE also includes several BYOD related reports that can assist with trouble shooting
and to understand statistics on BYOD endpoints. Here is list of BYOD related reports
available ISE 2.4.
Report Note
External Mobile
Device
Management
Shows the integration between ISE and external MDM. Also shows endpoint
status from the ISE without having to login to the external MDM portal.
Manual Certificate
Provisioning
Combined report that tracks:
Login activity
Manual certificate requests performed via Certificate provisioning
portal
Registered
Endpoints
Displays personal devices registered by employee users.
Supplicant
Provisioning
Provides details on the supplicant and certificates provisioned by
onboarding for employees.
My Devices Login
and Audit
Combined report that tracks:
Login activity
Device related operations performed by users in the MDP

Appendix
Dual-SSID flow with differentiated
portal
This flow is similar to dual-SSID flow, but instead of utilizing the BYOD setting within
the guest portal, the BYOD portal is used for employees. Once employee user logs in
to the guest portal, the user is presented with BYOD portal based on the authorization
condition. In the example below, the user group will be used to provide different
BYOD portal. This example utilizes the NAD settings and NSP settings in the main
section of the document.
Create endpoint groups
1. Go to Administration > Identity Management > Groups
2. Click on ‘Endpoint Identity Groups’ on the left and click ‘Add’

3. Provide name ‘EP_Group_A’ for the group and click Submit
4. Repeat above for ‘EP_Group_B’

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

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

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


Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf

Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf

Recommended

Recommended

More Related Content

Similar to Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf

Similar to Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf (20)

Recently uploaded

Recently uploaded (20)

Cisco ISE BYOD Prescriptive Deployment Guide - Cisco Community.pdf