1.

Cisco anyconnect vpn access (part1)

Problem
To be honest it’s probably a LOT easier to do this with Dynamic Access Policies, but
hey, if you have ISE then why not use it for RADIUS, and let it deploy downloadable
ACL’s to your remote clients and give them different levels of access, based on their
group membership.
I’m going to keep things simple, I will have a group for admins that can access
anything, and a group for users that can only RDP to internal servers.
I always assume things will break, so I’m also going to create a local user on the ISE
deployment, so if Active Directory is down I will have a user account I can use to gain
full access in the event of an emergency.

Solution
In production you will have plenty of users, but to test Im going to create a test user, and
a test admin user.
Then put those users in an appropriate Active Directory security group, (here I’m using
VPN-Users and VPN-Admins).

Now you will also need a ‘Tunnel-Group and a matching Group-Policy on the ASA to
map the user groups to. That way, when a user connects they can pick the appropriate
tunnel group like so;
So what I’ve done is setup AnyConnect and configured it properly, (see article below) then
I’ve simply ‘cloned‘ the tunnel group, and group policy to create a VPN-ADMIN and
VPN-USERS tunnel-group ,and a group-policy. So my ASA config is as follows;
1. Show run ip local pool

Petes-ASA# show run ip local pool

ip local pool ANYCONNECT-POOL 192.168.101.1-192.168.101.254 mask 255.255.2
55.0
Petes-ASA#

2. Show Group-Policy

Petes-ASA# show run group-policy

group-policy GroupPolicy_ANYCONNECT-PROFILE internal
group-policy GroupPolicy_ANYCONNECT-PROFILE attributes
wins-server none
dns-server value 192.168.100.10
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL
default-domain value petenetlive.com
webvpn
anyconnect profiles value PNL-Profile type user
group-policy VPN-ADMINS internal
group-policy VPN-ADMINS attributes
wins-server none
dns-server value 192.168.100.10
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL
 default-domain value petenetlive.com
webvpn
anyconnect profiles value PNL-Profile type user
group-policy VPN-USERS internal
group-policy VPN-USERS attributes
wins-server none
dns-server value 192.168.100.10
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL
default-domain value petenetlive.com
webvpn
anyconnect profiles value PNL-Profile type user
Petes-ASA#

Show Tunnel Groups

Petes-ASA# show run tunnel

tunnel-group ANYCONNECT-PROFILE type remote-access
tunnel-group ANYCONNECT-PROFILE general-attributes
address-pool ANYCONNECT-POOL
default-group-policy GroupPolicy_ANYCONNECT-PROFILE
tunnel-group ANYCONNECT-PROFILE webvpn-attributes
group-alias ANYCONNECT-PROFILE enable
tunnel-group VPN-ADMINS type remote-access
tunnel-group VPN-ADMINS general-attributes
address-pool ANYCONNECT-POOL
default-group-policy VPN-ADMINS
tunnel-group VPN-ADMINS webvpn-attributes
group-alias VPN-ADMINS enable
tunnel-group VPN-USERS type remote-access
tunnel-group VPN-USERS general-attributes
address-pool ANYCONNECT-POOL
default-group-policy VPN-USERS
tunnel-group VPN-USERS webvpn-attributes
group-alias VPN-USERS enable
Petes-ASA#

Create a Local Admin Group in Cisco ISE

On your Cisco ISE Deployment > Identity Management > Groups > Add.
Give the group a name and optional description > Save.

To create an admin user > Administration > Identity Management > Identities > Add.
Create the new admin user > set the password > add the user to the group you create
above.

Adding Domain Groups To Cisco ISE

I’m assuming you have joined ISE toActive Directory > To check Administration >
Identity Management > External Identity Sources > Ensure the domain is joined and
operational.

Groups > Add.

Locate and add the groups you created above.

Add An Active Directory Identity Source Sequence
We need to authenticate against our AD, but we want it to fail back to the ISE local
database, (for our local admin). To do that we use and identity source sequence.
Administration > Identity Management > Identity Source Sequence > Add.
Give the sequence a name and add your AD and Internal Users.

MAKE SURE you select ‘Treat as if the user was not found and proceed to the next
store in the sequence’ > Submit.

Add Cisco ASA to Cisco ISE as a RADIUS Device.

Administration > Network Resources > Network Device Groups > All Device Types >
Add.

Add a device GROUP for your ASA(s) > Submit.

Administration > Network Resources > Network Devices > Add.

Add in the ASA > Provide its IP address, and add it to the group you created above >
Set a RADIUS Shared Secret > Submit.

The shared secret must be the same on the ASA in the AAA config, like so;
Petes-ASA(config)# aaa-server Cisco-ISE protocol radius
Petes-ASA(config-aaa-server-group)# aaa-server Cisco-ISE host 192.168.100.
11
Petes-ASA(config-aaa-server-host)# key 123456
Petes-ASA(config-aaa-server-host)# radius-common-pw 123456
Petes-ASA(config-aaa-server-host)# exit
Petes-ASA(config)#

Cisco ISE Create Downloadable Access Control Lists

DACL
Policy > Policy Elements > Results > Authorisation > Downloadable ACL’s > Add.

Create an ACL for our VPN-USER group, that will only allow RDP (TCP 3389) > Submit.
Repeat the process to create an ACL that allows everything, (for our VPN-ADMINS) >
Submit.

Cisco ISE Create Authorisation Profiles

Policy > Policy Elements > Results > Authorisation > Authorisation Profiles > Add.
Create a profile for VPN-ADMINS > Set the correct DACL.

Set the advanced attributes > Change to RADIUS.

Class-25

Set the OU to equal the group-policy that you want the ASA to apply > Submit.
Create another profile for your VPN-USERS > Set the correct ACL.

RADIUS > Class-25 > OU set to the group-policy on your ASA for the normal users >
Submit.
Cisco ISE Enable Policy Sets
Note: only available on newer versions of ISE: Administration > System > Settings >
Policy Sets > Enabled > Submit.

Policy > Policy Sets > Add.

 2. Cisco anyconnect vpn access (part2)
Problem
Carrying on from PART 1

Solution
Add > Create Before.

Edit the Policy

Give the policy set a name and description > Create a new condition.

Set Description to Device Type.

Equals > All Device Types (The Device Group You Created Above).

Add attribute value.

Set Description to RADIUS.

NAS-Port-Type-[61].
Equals > Virtual.

Edit the Authentication Policy.

Change the identity source to the the identity source sequence you created above.

Authorisation Policy > Insert New Rule Above.

Give it a Name i.e. VPN-ADMIN-RULE > Create New Condition.

Set Description to your Active Directory.

External Groups.

Select your AD group (VPN-Admins).

Set Permissions to Standard.

Select your VPN-Admins authorisation profile.

Add another rule (directly below) of your VPN-Users and set this one to use the user
profile.

Add a further rule (below that) for your LOCAL admin in the ISE database.
Set User Identity Groups to VPN-Admins.

Note: this is the LOCAL group in ISE, NOT the domain security group.
Again use the admin authorisation profile.

Finally you need to change the ‘Default’ rule to ‘Deny Access’, (or they will just hit the
default allow and get in anyway!)
Now you can test.
 3. Cisco ISE Secure Wired Access
Prescriptive Deployment Guide

Hariprasad Holla

Mahesh Nagireddy

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.

Table of Contents

 Introduction
 About Cisco Identity Services Engine (ISE)
 About This Guide
 Define
 ISE Deployment Components
 Authentication, Authorization, and Accounting (AAA)
 Design
 Design Considerations
 Network Device Considerations
 Identity-Based Networking Services (IBNS) 1.0 vs. 2.0
  Phased Deployments
 ISE Deployment Considerations
 Deploy
 Preparing for Identity-Based Network Access
 Preparing ISE for Identity-Based Network Access
 Preparing a Switch for Identity-Based Network Access
 Validating Basic Settings
 Monitoring Authentications with Open Access
 Integrating ISE with Active Directory
 Configure the Switch for Monitor Mode
 Configuring Microsoft Windows and Apple OS X Devices for 802.1X
 Monitoring Authentication Sessions
 Configuring and Understanding the IBNS 2.0 Policy
 Additional Best-Practice Configurations for IBNS 2.0
 Migrating from Monitor Mode
 Pre-Authentication and Post-Authentication Access Control with Low Impact
 Switch Configuration for Low Impact Mode
 Downloadable ACL Authorization
 Validating ACL Authorization/Low-Impact Mode
 Role-Based Critical Authorization
 Cisco IOS Changes for Role-Based Critical Authorization
 ISE Authorization with User Role
 Validating Role-Based Critical Authorization
 Differentiated Authentication with IBNS 2.0
 Switch Configuration for Differentiated Authentication
 ISE Authorization Profile for Differentiated dACL
 Identity-Based Network Access in IPv6 Wired Networks
 IPv6 Network Readiness
 Cisco IOS Identity Configurations for IPv6
 Low-Impact Mode with IPv6 Per-User ACL
 Deploying 802.1X for High Security (Closed Mode)
 Switch Configuration for Closed Mode
 Authoring Access Policies on ISE
 Closed Mode in Action
 802.1X for Cisco IP Phones
 Basic Call Manager and Network Settings
 IP Phone Authentication with MIC
 IP Phone Authentication with LSC
 NEAT with Interface Templates
 Overview
 NEAT with Macros/Interface-Template
 Configuring NEAT with Interface templates
 Validating NEAT
 Operate
 Operating ISE
 Operating the ISE Session Table
 ISE AAA Reports
 Troubleshooting
  Cisco IOS Troubleshooting
 ISE Troubleshooting

Introduction
About Cisco Identity Services Engine (ISE)

Figure1: Cisco Identity Services Engine

Cisco ISE is a leading, identity-based network access control and policy enforcement
system. It is a common policy engine for controlling end-point access and network
device administration for enterprises. ISE allows an administrator to centrally control
access policies for wired, wireless, and VPN end points in a network.

ISE builds contexts about endpoints, including users and groups (Who), device type
(What), access time (When), access location (Where), access type
(Wired/Wireless/VPN) (How), threats, and vulnerabilities. By sharing vital contextual
data with technology partner integrations and the implementation of the Cisco
TrustSec® policy for software-defined segmentation, ISE transforms a network from a
 conduit for data into a security enforcer that accelerates the time-to-detection and time-
to-resolution of network threats.

What is Covered in This Document?

This document aims to provide guidance to Cisco ISE customers who want to protect
their wired network access, which is being designed with the Cisco Catalyst switch
platforms. The configuration examples listed in this document are working
configurations that have been validated on a Cisco Catalyst 9300 Series switch
running Cisco IOS XE Version 16.9.1 with Network Essential License and Cisco ISE
Version 2.4.

Figure2: Endpoint onboarding Physical network topology

The following are the IOS XE features and deployment variations described in this
document:

 Cisco Identity-Based Networking Services (IBNS) 1.0 and 2.0

 Monitor, Low-Impact, and Closed Deployment Modes
 Critical Access Control List
 Role-Based Critical Authorization
 Identity-Based Wired Access in IPv6 Networks
 1X on Cisco IP Phone

What is Not Covered in This Document?

Although this deployment guide is about securing wired network access, Cisco Meraki
access switches or third-party access switches are not covered in this document. For
more information about these, see the ISE Design and Integration Guides page.This
 guide does not cover other wired access features, such as Wired Guest Access,
Network Edge Authentication Topology (NEAT) and EasyConnect.

About This Guide

This guide is intended to provide technical guidance to design, deploy, and operate
Cisco ISE for wired network access control. It focuses on the Cisco Catalyst access
switch configurations to handle various endpoint onboarding scenarios. The document
also provides best-practice configurations for a typical enterprise environment.

Figure3: ISE for Wired

Implementation Flow

This document contains four major sections:

 The Define section defines problem areas and provides information about how to plan for
deployment, and other considerations.
 The Design section shows how to design a secure, wired access network.
 The Deploy section provides information about various configuration and best practices.

The Operate section shows how to manage a wired access network controlled by Cisco ISE.
Define
 This section provides an high level overview of Wired access control solution, different
authentication methods available during the endpoint onboarding process, problem
areas to focus on and various authorization options.

ISE Deployment Components

A typical ISE-based network access control solution comprises four components,

endpoints, network devices, Cisco ISE, and external services.

Figure4: ISE solution components

Endpoints need network access and the network devices provide network access to
endpoints, based on instructions from ISE. ISE can optionally leverage external services
to understand more about the corresponding endpoints for policy decisions. When it
comes to rolling out an identity-based network, because these four parts of the network
are involved, various teams and individuals need to be engaged. Various ISE use
cases, such as Guest access, BYOD, Posture, and so on require endpoints
communicating to ISE via network devices.
Authentication, Authorization, and Accounting (AAA)

The core of IBNS is the idea of users and devices authenticating to ISE, and ISE
applying the appropriate network access authorization, using protocols such as EAP
and RADIUS. Network devices covey an endpoint’s session status to ISE via RADIUS
accounting messages. ISE gains visibility into the details of all the assets connecting to
the network and their location. An ISE administrator can permit or deny access to a
specific user or device or a specific group of assets either on the fly or based on ISE
policy configurations.

Authentication Methodologies
IEEE 802.1X

Figure5: 802.1x Authentication Workflow

The 802.1x standard defines a client/server-based access control and authentication

protocol that prevents unauthorized clients from connecting to a LAN through publicly
accessible ports unless they are properly authenticated. The authentication server
authenticates each client connected to a switch port before making available the
services offered by the switch or the LAN. The supplicants on the endpoints use
Extensible Authentication Protocol (EAP) to pass credentials, such as passwords or
certificates, to ISE. EAP payloads are typically transported over 802.1X in Ethernet
networks (EAP over LAN or simply EAPoL) and over RADIUS in IP networks. ISE
evaluates an endpoint’s identity and instructs the corresponding network device about
whether to open the port or not, the VLAN or ACL or both VLAN and ACL that are to be
applied for that endpoint’s access session.

MAC Authentication Bypass (MAB)

Figure6: MAB Authentication Workflow

MAB enables port-based access control using the MAC address of an endpoint. A MAB-
enabled port on the switch can be dynamically enabled or disabled based on the MAC
address of the device that connects to it. The MAC addresses of endpoints must be
whitelisted in a database that is present in ISE or in an external location in order to grant
network access to known endpoints. MAB is not truly an authentication method; it
functions more as an authentication bypass when an endpoint is unable to perform
802.1X authentication. While MAB can protect networks from unauthorized access, it is
not a secure alternative to 802.1X because MAC addresses can be spoofed easily.

Web Authentication

Figure7: Web Authentication Workflow

Web authentications are typically used to onboard guest users for internet access.
Cisco platforms provide a couple of options, Local Web Authentication (LWA) and
Central Web Authentication (CWA). In the former, web pages are hosted in network
devices such as a switch or a wireless LAN controller, and in the latter, all web portals
are hosted centrally on ISE. CWA, which is the preferred method, is typically a MAB
session with URL-redirect authorization on the switch port. Until the corresponding
endpoint is authenticated successfully, web traffic from the endpoint is redirected to ISE
via a login portal for end users to enter their credentials. Upon successful
authentication, ISE initiates a Change-of-Authorization (CoA) to permit additional
access.

EasyConnect

Figure8: EasyConnect Authentication Workflow

The Cisco ISE EasyConnect feature enables enterprises to implement identity-based

network access without the need for 802.1X. No supplicants or supplicant configurations
are needed on endpoints. An EasyConnect session, which is similar to the CWA flow,
starts with a MAC authentication bypass. ISE learns about an endpoint’s location, MAC
address, and IP addresses via an initial MAB session. This initial MAB session is
authorized with limited access from ISE to enable a Windows Active Directory-managed
endpoint to perform a Windows domain login. Upon successful domain login, the user
ID to IP address mapping from the Active Directory (AD) domain controller is
retrieved to ISE and merged with the initial MAB session. After the user ID and its AD
group membership is resolved, ISE changes the authorization to permit additional
access.

A Comparison of the Different Authentication Methods

Figure9: Complexity analysis of Authentication methods

Of the various authentication options discussed until now, IEEE 802.1X is the most
secure and flexible authentication method. There are several EAP methods that allow a
variety of credential types to be handled, depending on the endpoint and the
environment type. Although the Web Authentication and EasyConnect options provide
the necessary user ID context for visibility and access control, they are constrained to
specific types of endpoints, for example, Web Authentication requires user interaction
and a device with a compatible web browser and EasyConnect works only for Windows
Active Directory-managed endpoints. Finally, MAB is less secure authentication method
and fall back mechanism for IEEE 802.1X, but is the easiest option to configure basic
level of controlled access.

Authorization Options

An ISE authorization policy is composed of authorization rules defined for a specific

users and group of users to permit, deny or provide limited access to network
resources. Authorization profiles let you choose the attributes to be returned when a
RADIUS request is accepted or rejected with RADIUS ACCESS-ACCEPT and
ACCESS-REJECT access type commands. Limited access authorization may vary from
environment to environment. The question to be asked is, what should be limited, and
how?
Figure10: ISE Enforcement authorization attributes
Dynamic VLAN Assignment

One of the traditional means of limiting network access is by placing endpoints in

different VLANs based on their role. Endpoints in specific VLANs can be access
controlled by policies that are defined at Layer 3 boundaries, such as on routers or
firewalls. ISE can authorize endpoints to specific VLANs using a VLAN name or a VLAN
number. Also, in platforms such as Cisco Catalyst 2960X, 3650 Series, 3850 Series,
and 9300 Series, VLANs can be applied on a per-MAC address basis.

Best Practice: When doing dynamic VLAN assignment, we recommend using VLAN
names rather than numbers. This will make your ISE authorization easier to read,
understand and maintain. When you have a large switch, it is better to let the switch
locally determine the actual VLAN number assigned with a name.

IP Access Control Lists (ACLs)

ACLs can be used to control network access at the port level. They can either be
downloaded to the network from ISE, or be configured locally on a switch and be
referenced by ISE during authorization. Named ACL authorization can be carried out
with a RADIUS-standard attribute called Filter-ID, using the ACL name. For ACL
downloads, either a Per-User ACL or a Downloadable ACL (dACL) can be used. Both
these ACL download options use Cisco custom RADIUS Attribute Value Pairs (AVPs).
While Per-User ACLs have a 4000-character limit, dACLs do not. However, the practical
recommendation for dACLs are 64 Access Control Entries (ACEs).

Security Group Tags (SGTs)

SGTs offer an efficient alternative to VLAN-based segmentation. Just like VLAN

authorization, assigning an SGT alone to an endpoint does not control access. Instead,
after SGT assignments, endpoints must be subject to egress enforcement policies
based on SGTs. Note that although in most cases, identity-based access is necessary
for SGT-based segmentation, this document does not cover tag-based segmentation in
any detail.

URL Redirection

An access switch can redirect endpoints to specific URLs that are authorized by ISE for
redirection. Typically, URL redirection is towards the ISE nodes so that the endpoints
can carry out web authentication with ISE. However, endpoints can be subject to
custom URLs as part of RADIUS authorization from ISE. Custom AVPs are used for
URL redirection in an identity-based network.

Session-Aware Networking

ISE along with Cisco Catalyst switches implement session-aware networking which
offers consistent way to configure features across technologies, easy deployment and
features customization along with robust policy control engine . Under this, a session
identifier is attached to an endpoint’s network access session (wired or wireless), and
session ID is used for all reporting purposes such as show commands, MIBs, and
RADIUS messages and allows users to distinguish messages for one session to other
sessions. This common session ID is used consistently across all authentication
methods and features applied to a session.
Figure11: ISE Session-Aware Networking

When an endpoint connects to network, the network device generates a unique session
identifier that is a combination of the network device IP address, the session count on
the network device, and the timestamp of the corresponding endpoint’s initial

connection.

ISE can invoke the network device to enforce specific policies for the endpoint using the
Session ID. After the initial authorization, ISE issues a CoA by referencing the same
Session ID. Distinct access policies for the endpoints on the same port are applied
because of the separation maintained by the Session ID.

Design

Design Considerations
This section focuses on overall design considerations for a secure wired access
solution.

End-Point Considerations

There are a few important things to consider with regard to endpoints in an identity-
based network. Firstly, how will these endpoints authenticate to the network, and are
these using 802.1X, Web Authentication, or some other means? Secondly, do you
require custom agents to perform specific functions that the native supplicants in the
operating system cannot? And, finally, how should endpoints be configured for
appropriate access, for example, manual, using centralized management tools, and so
on?

Agents

For most of the secure wired access environment, an agent on an endpoint is

unnecessary. However, there are a few scenarios that can be handled only by a Cisco
AnyConnect end-point agent:

EAP Chaining–Many organizations want to grant network access to trusted users on

trusted devices. While the Cisco ISE feature such as Machine Access Restriction
(MAR) can handle such cases with native supplicants, it can do so only in various
terms. With the presence of Cisco AnyConnect Network Access Manager (NAM)
module on the endpoint and Cisco ISE, user and machine authentications can be
combined in a common EAP session, making EAP Chaining a secure alternative to
MAR.

MACsec–In addition to authenticated network access using IEEE 802.1X, IEEE

802.1AE(MACsec) encryption can be layered on top of IEEE 802.1X to encrypt packets
on the link between the endpoint and the switch (point-to-point encryption) ... Cisco
AnyConnect is the only supplicant that supports MACsec on endpoints.

Note: The Cisco AnyConnect NAM module is compatible only on Microsoft

Windows operating systems. Therefore, both EAP Chaining and MACSec features
can be enabled only on Windows-based endpoints currently.
Automation

It is a known fact that implementing port access control with 802.1X means
considerable changes to endpoints. Some of the changes pertain to supplicant
configurations, certificate installation (optional), and agent installation and setup
(optional). Rolling out these changes to thousands of endpoints requires a certain
degree of automation. Some of the options to automate supplicant configuration are:

Endpoint Type Supplicant Configuration By

Active Directory – Group Policy Objects

Microsoft Windows systems (Managed)
(GPO)

Cisco IP phones Cisco Unified Call Manager

Apple devices MacOS server

BYOD (Android/Apple iDevices/Microsoft Cisco ISE Client Provisioning / Mobile

devices/ Google Chrome devices) Device Managers

Table1: Endpoint Automation

Note: Always use a systems manager or device manager to configure endpoints at

scale.

Network Device Considerations

In the context of this document, “network device” or “Network Access Device (NAD)”
indicates a Cisco Catalyst switch that runs on Cisco IOS software. There are three
major configurations to perform on Catalyst switch for it to work with ISE.
 Figure12: Network Device Configurations for ISE

 The global AAA and RADIUS server configurations govern how a switch talks to ISE, how
RADIUS transactions are load balanced, how frequently accounting updates are sent, how the
switch handles failure scenarios when ISE is not reachable.
 The endpoint side configuration includes interface level commands to handle specific
authentication methods such as 802.1X or MAC authentication bypass in a particular order.
 The port configurations can be done using IBNS 1.0 or 2.0 methods, which is described next.

ISE might authorize an endpoint with a VLAN, ACL, SGT configuration or URL
redirection. Note that some authorization-related configurations have to be done locally
on the switch.

Identity-Based Networking Services (IBNS) 1.0 vs. 2.0

When it comes to the switch configurations required for ISE deployment, one of the
most important considerations is whether to go with IBNS 1.0 or IBNS 2.0 MQC-style
commands. IBNS are the identity-based session management services on Cisco IOS,
which are meant to handle access services for endpoints connecting to a network. The
policy functions on a switch determine how to facilitate an endpoint’s network
authentication with a centralized AAA server, how to treat the endpoint when there are
authentication failures or how to handle AAA server unreachability. IBNS can be
implemented in two ways, depending on the platform support and policy needs.
Figure13: Cisco IBNS 1.0 vs. IBNS 2.0

Apart from significant changes in the Cisco IOS components that handle identity-based
services, from an administration and operations perspective, there are considerable
differences between IBNS 1.0 and IBNS 2.0. As the figure above depicts, in case of
IBNS 1.0, which is sometimes referred to as legacy mode in CLI, a switch’s local policy
for handling an endpoint’s identity-based network access is all contained within interface
configurations (a list of interface commands applied to a switch port). On the other
hand, in case of IBNS 2.0, the configurations take the structure of a Cisco Modular
Quality of Service CLI (MQC). One or more subscriber policies are used; these policies
are defined by the policy-map command, which classifies various endpoint events into
classes that are defined by the <class-map> command arguments. The various
endpoint event classifications are subject to specific actions, some of which are local
and some of which are enforced on instructions from ISE. The use of templates
provides modularity, flexibility, and reusability of certain policy objects within the switch
platform.

There are several benefits to using IBNS 2.0 over IBNS 1.0. The following table
compares the two:
 IBNS
IBNS 1.0 Description
2.0

IBNS 2.0 is configured the same

Policy Interface MQC way as a router QoS policy, while
Configuration commands Style IBNS 1.0 is configured with a list of
interface subcommands.

IBNS 2.0 configurations can be

contained within an interface
Interface
No Yes template, while IBNS 1.0 all
templates
configuration are interface specific
Templates commands.

Service IBNS 1.0 cannot use service

No Yes
templates templates.

Both support assigning a fail-open

Critical
Yes Yes VLAN for endpoints that cannot
VLAN
reach ISE during authentication.

Only IBNS 2.0 can apply a custom

Critical
No Yes ACL to an endpoint session when
ACL
ISE service is unavailable.
Critical
Authorization
Only IBNS 2.0 can assign a critical
Critical
No Yes SGT when the AAA server is
SGT
down.

With IBNS 2.0, endpoints can be

Critical MAB authenticated against a local
No Yes
MAB list of MAC addresses on the
switch.
 IBNS 2.0 facilitates the task of
separating authentication and
Differentiated
No Yes authorization transactions between
Authentication
two or more AAA servers, while
IBNS 1.0 cannot do this.

IBNS 2.0 has a better way of

Intelligent
No Yes detecting the disconnects from
Aging
indirectly connected hosts.

Table2: Cisco IBNS 1.0 vs. IBNS 2.0

Phased Deployments

Enabling 802.1X on switch ports can be disruptive. The need for endpoints to prove
their identity with some sort of authentication and then get network access, may not
work well for all device types. With wireless, this is a norm because the endpoints do
not plug to the network; rather, they have to be configured (for SSIDs) to connect to the
network. The notion of configure and connect is built ground up in the wireless world,
while the same is not the case with the wired side of networks. For decades, the
expectation is that the endpoint must get IP address the moment they plug in to the
wired Ethernet port.

We recommend a phased deployment model that has limited impact on network access
while gradually introducing authentication and authorization on the wired network. The
three deployment modes are:
 Figure14: IBNS Deployment Modes

1. Monitor Mode (Open Mode)– This Mode enables authentication across Wired infrastructure,
while authorization is kept open. This means that irrespective of the endpoint’s authentication
status (success or failure), the port is always open. When a user plugs in a device after monitor
mode is enabled in the network, there is no impact to the end user irrespective of the
authentication status. Such a setting provides adequate visibility centrally to the security
operator to know how many endpoints authenticate successfully, how many fail, why they fail,
where they are located, and so on. After most of the failures are fixed, one of the below two
enforcement modes can be enabled. Note,Monitor Mode is not for validating enforcement of
more advanced authorization results such as Scalable Group Tags(SGT’s), Scalable Group
ACL’s(SGACL’s), downloadable ACL’s(dACL’s) or even dynamic Vlan Assignment. We simply
want the authentication server to send back a basic RADIUS access accept or access reject to
the authenticator (access switch).

2. Low-Impact Mode–This mode builds on the monitor mode. With open access in place, IP ACLs
are used to control pre-authentication and post-authentication network access. A Pre-Auth ACL
on the switch port controls network access before an endpoint can successfully authenticate. A
named or downloadable ACL that is received from ISE grants specific level of access upon
successful authentication. The Low-Impact mode is ideal for a Preboot Execution Environment
(PXE) boot environments where thin clients have to download the operating system from the
network before attempting network authentication. Since devices get IP address immediately
after they connect to the network, and authentication may take place in parallel or later, we
recommend that you do not make VLAN changes in the Low-Impact mode.
3. Restricted Mode (Closed Mode)–In this mode, the port is closed by default. Only EAPoL
payloads are allowed for 802.1X authentication. Upon successful authentication, the endpoints
can have access to network services. Since endpoints do not acquire dynamic IP addresses
without authentication, this mode is ideal for VLAN authorizations.

ISE Deployment Considerations

When it comes to wired network access, a carefully set up ISE service is critical. The
following are some of the important considerations:

ISE Deployment Scale and Performance

Figure15: ISE Deployments

ISE can be deployed as a standalone service or a cluster of multiple ISE nodes. While
the former is a good option for small-sized networks, the latter is the choice for medium
and large environments. Both standalone and multi-node ISE deployments can be done
on bare metal servers (Cisco Secure Network Server [SNS]) or on supported
Hypervisors.

Choose the deployment type and install option depending on your requirements. See
the ISE Performance & Scale page for more details about scale limitations and
performance numbers for each ISE deployment method.

Access switches need to talk to ISE servers for AAA. Typically, two or more RADIUS
servers are defined on the switches for AAA and CoA. For large networks involving
multiple PSNs per site, we recommend that use of Load Balancers. When Load
 Balancers are used, the virtual IP addresses of these Load Balancers must be
configured as RADIUS server IP addresses on the switches.

The following table summarizes the configuration practice that should be followed,
depending upon the type of deployment and whether Load Balancers are used or not.

Switch-Side Multi-Node ISE

2-Node Standalone ISE Multi-Node ISE
Configuration with Load Bala

RADIUS Server IP address of the either ISE IP address of th

IP address of the PSNs
configuration for AAA nodes address of the

RADIUS Server IP addresses of the IP addresses of the PSNs IP addresses o

configuration for CoA either ISE nodes and PANs Balancer VIP, P

Table3: Deployment Configuration best practices

ISE Licensing

Cisco ISE licensing provides the ability to manage the application features and access,
such as the number of concurrent endpoints that can use Cisco ISE network resources.
ISE requires one or more of the following three license packages to service wired
endpoints:

 Base
 Plus
 Apex

However, for most of the AAA and access control services, the Base licenses will
suffice. For ISE to automatically detect the endpoint type using profiling service, and to
control access to them, both Base and Plus licenses are required. For deeper visibility
into applications and processes on endpoints and to control them, Apex licenses are
also needed. Note that all these licenses are applied to the endpoint’s session that is
active at a given point of time. Therefore, budgeting for adequate licenses must not be
on the total number of endpoints, but for an estimated number of active endpoints at a
probable peak duration. For more information about licenses, see the Cisco ISE
Ordering Guide.
Certificates

Certificates are used to identify ISE to an endpoint and also to secure the
communication between that endpoint and the ISE node. Certificates are used for all
HTTPS communication and Extensible Authentication Protocol (EAP) communication.
The following is a summary of the certificates and their use in the context of endpoint
authentication and access control:

Communication Uses Purpose

· Administration Portal

· Centralized Web Authentication Portal

· Web authentication
HTTPS · Sponsor Portal
· ISE Portal access for ad
operations
· Client Provisioning Portal

· My Devices Portal

· EAP-TLS

EAP · PEAP · IEEE 802.1X authentica

· EAP-FAST

Table 4: Certificate Use Cases in context of Endpoint authentication

We recommend that you do not use ISE self-signed certificates for production. Instead,
use a Certificate Authority-signed certificate on the ISE nodes for all purposes. When
dealing with internal endpoints that are managed by an organization, an internal
enterprise Public Key Infrastructure (PKI) can be used. For use cases such as guest
internet access and BYOD registration, ISE node certificates signed by a public CA is
recommended to avoid poor user experience due to certificate warnings on the
endpoints. ISE has a built-in CA service, but this is largely limited to BYOD identity and
 authentication. For more information about certificates, see How To: Implement ISE
Server-Side Certificates.

Deploy

This section focuses on deployment guidelines with various best practices to greatly
simplify secured wired implementations.

Preparing for Identity-Based Network Access

This section shows how to configure ISE and a switch for basic RADIUS connectivity.
Cisco ISE supports the default device definition for RADIUS and TACACS
authentications. You can define a default network device that Cisco ISE can use if it
does not find a device definition for a particular IP address. For advanced flows (such
as SNMP,CDP,LLDP) you must add separate device definition for each network device.

Figure16: Switch to ISE Communication ProtocolPreparing ISE for Identity-Based Network

Access

This section covers the minimum required configuration on ISE for it to accept AAA
requests from a Cisco Catalyst switch.

1. Log in to ISE in admin node.

2. Navigate to Administration > Network Device.

3. In the left navigation pane, click Default Device.
4. From the Default Network Device Status drop-down list, choose Enable.
5. Define a Shared Secret (in this exampl

e, ISEisC00L) and Click Save

Preparing a Switch for Identity-Based Network Access

Perform the following steps to configure a Cisco Catalyst Switch for basic RADIUS
connectivity.

1. Configure the management interface for the switch:

2. c9300-Sw(config)#interface Vlan254
3. c9300-Sw(config-if)#description ** Switch management interface **
4. c9300-Sw(config-if)#ip address 172.20.254.101 255.255.255.0

c9300-Sw(config-if)#end

Note: In the example above, the switch is a VTP client and has the necessary VLANs
configured. Also, the uplink port connected to the data center is configured as a trunk
port. The management IP address for the switch can be an SVI or a Loopback interface.
Ensure that proper routing is set up between the access switch and the ISE nodes

2. Log in to the switch and enable AAA:

c9300-Sw(config)#aaa new-model

3. Configure one or more ISE Policy Service nodes as RADIUS servers. Ensure that the RADIUS
key is identical to the shared secret configured on ISE:

4. c9300-Sw(config)#radius server ISE01

5. c9300-Sw(config-radius-server)#address ipv4 172.20.254.21 auth-port 1812 a
cct-port 1813
6. c9300-Sw(config-radius-server)#key ISEisC00L
7. c9300-Sw(config-radius-server)#exit
8. c9300-Sw(config)#
9. c9300-Sw(config)#radius server ISE02
10. c9300-Sw(config-radius-server)#address ipv4 172.20.254.22 auth-por
t 1812 acct-port 1813
11. c9300-Sw(config-radius-server)#key ISEisC00L

c9300-Sw(config-radius-server)#exit

Note: For networks with multi-vendor devices, Its recommended to use Ports 1812 for
authentication and 1813 for accounting, however ISE can receive RADIUS
authentication and accounting requests on either of the two port number combinations.

4. Define a method list for the ISE RADIUS servers and use the switch management interface as
the RADIUS source interface:

5. c9300-Sw(config)#aaa group server radius ISE

6. c9300-Sw(config-sg-radius)#server name ISE01
7. c9300-Sw(config-sg-radius)#server name ISE02
8. c9300-Sw(config-sg-radius)#ip radius source-interface VLAN 254

5. Configure network authentication to use the RADIUS method list (in this example, ISE):
 c9300-Sw(config)#aaa authentication dot1x default group ISE

6. Configure the switch for network (access) authorization via ISE RADIUS servers. This is for
network access authorization from ISE, such as dynamic VLAN assignment, downloadable
ACLs, URL redirection, and so on:

c9300-Sw(config)#aaa authorization network default group ISE

7. Configure the switch to send accounting information to ISE at endpoint session start and end
events:

c9300-Sw(config)#aaa accounting identity default start-stop group ISE

8. Configure the switch to send periodic accounting updates for active sessions once every two
days:

c9300-Sw(config)#aaa accounting update newinfo periodic 2880

Note: After a network access session of an endpoint is logged to ISE, it stays there for
5-days without any additional accounting updates. In order to keep the session active
on ISE, a periodic accounting update once every two days is a best practice.

Validating Basic Settings

Perform the following tasks to validate if the basic AAA and RADIUS configurations are
working as expected:

1. Check the AAA server status on the switch

2. c9300-Sw#show aaa servers

3.
4. RADIUS: id 1, priority 1, host 172.20.254.21, auth-port 1812, acct-port 18
13
5. State: current UP, duration 38301s, previous duration 0s
6. Dead: total time 0s, count 0
7. Platform State from SMD: current UP, duration 38301s, previous durati
on 0s
8. SMD Platform Dead: total time 0s, count 0
9. Platform State from WNCD: current UP, duration 0s, previous duration
0s
10. Platform Dead: total time 0s, count 0
11. Quarantined: No
12. !<Output truncated>
13.
14. RADIUS: id 2, priority 2, host 172.20.254.22, auth-port 1812, acct
-port 1813
15. State: current UP, duration 38295s, previous duration 0s
16. Dead: total time 0s, count 0
17. Platform State from SMD: current UP, duration 38295s, previou
s duration 0s
18. SMD Platform Dead: total time 0s, count 0
19. Platform State from WNCD: current UP, duration 0s, previous d
uration 0s
20. Platform Dead: total time 0s, count 0
21. Quarantined: No

!<Output truncated>

2. Execute the following test command on the switch to validate if the switch and ISE can
communicate over RADIUS or if the credentials result in a passed or failed authentication. test-
user and test-password are not a real user name and password; these are variables used to
test RADIUS communication between Switch and ISE

3. c9300-Sw#test aaa group radius test-user test-password new-code

4. AAA/SG/TEST Platform: Testing Status
5. AAA/SG/TEST: Authen Requests to Send : 1
6. AAA/SG/TEST: Authen Requests Processed : 1
7. AAA/SG/TEST: Authen Requests Sent : 1
8. AAA/SG/TEST: Authen Requests Replied : 1
9. AAA/SG/TEST: Authen Requests Successful : 0
10. AAA/SG/TEST: Authen Requests Failed : 1
11. AAA/SG/TEST: Authen Requests Error : 0
12. AAA/SG/TEST: Authen Response Received : 1
13. AAA/SG/TEST: Authen No Response Recevied: 0
14.
15. AAA/SG/TEST Platform: Testing Status
16. AAA/SG/TEST: Account Requests to Send : 0
17. AAA/SG/TEST: Account Requests Processed : 0
18. AAA/SG/TEST: Account Requests Sent : 0
19. AAA/SG/TEST: Account Requests Replied : 0
20. AAA/SG/TEST: Account Requests Successful : 0
21. AAA/SG/TEST: Account Requests Failed : 0
22. AAA/SG/TEST: Account Requests Error : 0
23. AAA/SG/TEST: Account Response Received : 0
24. AAA/SG/TEST: Account No Response Recevied: 0
25. User rejected

Note: The Authen Requests Replied: 1 message in the output indicates that a RADIUS
server is responding to the switch’s requests. Such detailed output for test
aaa command is available only from Cisco IOS Version 16.x

3. Log in to ISE web User Interface (UI) and navigate to Operations > RADIUS > Live Logs.

You must see one or two failed entries for test-user identity, which indicates that the
switch and ISE are talking over RADIUS successfully.
 When you click the Details icon corresponding to a test user, you will see the reason
for failure: 22056 Subject not found in the applicable identity store(s), which means that
the test user account cannot be found, which is obvious at this stage of the deployment.

Another important thing to note is that the switch is using its management IP address to
communicate with ISE.
 Best Practice Global Settings for Switch

The following section covers the best practice global configuration for Cisco Catalyst
switch.

RADIUS Server Failure Detection

1. Define how a switch must detect a RADIUS server reachability failure:

c9300-Sw(config)#radius-server dead-criteria time 10 tries 3

 time-The time during which no properly formed response received from the ISE server.
 tries-The number of consecutive timeouts that must occur on the switch before the RADIUS
server is marked dead.

2. When multiple RADIUS servers are defined and the primary server is unavailable, it is a good
practice to mark that server’s Dead to improve the RADIUS response time . This prevents the
RADIUS requests from being sent to a server that could be flapping its status.

The following example shows that the Dead time is set to 15 minutes:

c9300-Sw(config)#radius-server deadtime 15

3. With the configuration defined in previous steps, switch will mark the server as dead for the
amount of time specified in in Step 2. With expiry of dead time, the switch will mark the server
as alive again and begin sending RADIUS traffic to the server. If the RADIUS deadtime is not
specified, it will default to a value of 0, which will bring the server back to the UP state right
away. Because of this behavior, the RADIUS server state could flap, causing additional
authentication issues. To revert the server state back to the UP state before the specified
deadtime expires, a RADIUS probe can be configured. This will periodically test the RADIUS
server to see if it is responding to RADIUS requests. Upon receiving a response to a probe, the
switch will mark the RADIUS server as alive.

4. c9300-Sw(config)#radius server ISE01

5. c9300-Sw(config-radius-server)#address ipv4 172.20.254.21 auth-port 1812 a
cct-port 1813
6. c9300-Sw(config-radius-server)#automate-tester username test-user ignore-a
cct-port probe-on
7. c9300-Sw(config-radius-server)#key ISEisC00L
8. c9300-Sw(config-radius-server)#exit
9. c9300-Sw(config)#
10. c9300-Sw(config)#radius server ISE02
11. c9300-Sw(config-radius-server)#address ipv4 172.20.254.22 auth-por
t 1812 acct-port 1813
12. c9300-Sw(config-radius-server)#automate-tester username test-user
ignore-acct-port probe-on
13. c9300-Sw(config-radius-server)#key ISEisC00L
14. c9300-Sw(config-radius-server)#exit

Note: As mentioned earlier, test-user is a test user ID Username. The ignore-acct-

port keyword indicates that the switch must not validate the accounting port number
that the server will use. The probe-on keyword indicates that the switch must send test
probes only when the server is marked as Dead.

4. In the case of an actual probe user account on the ISE’s internal or external database, a
password is required. In the example below, “test-user” is the username and “test-password” is
the password stored in the identity store that the RADIUS server refers to authenticate. A “User
rejected” message too (unless a timeout occurs) indicates that the RADIUS server is alive.

c9300-Sw(config)#username test-user password 0 test-password

5. To make the switch send an EAPoL success message to the corresponding client when the port
fail-opens or fail-closes in the event that none of the ISE servers are reachable,

c9300-Sw(config)#dot1x critical eapol

Additional RADIUS Best Practice Attributes for ISE

6. Send the Service-Type attribute in the authentication packets, which is important for ISE to
distinguish between the different authentication methods:

c9300-Sw(config)#radius-server attribute 6 on-for-login-auth

7. Send the IP address of an endpoint to the RADIUS server in the access request:

c9300-Sw(config)#radius-server attribute 8 include-in-access-req

8. Include the class attribute in an access request for network access authorization:

c9300-Sw(config)#radius-server attribute 25 access-request include

9. Set the MAC address of the endpoint in IETF format and in upper case:
 c9300-Sw(config)#radius-server attribute 31 mac format ietf upper-case

radius-server attribute 31 mac format {default | ietf | unformatted}

default-Example: 0000.4096.3e4a

ietf-Example: 00-00-40-96-3E-4A

unformatted-Example: 000040963e4a

10. To include NAS port & MAC address details in Calling-Station-ID (attribute 31) for Access and
Accounting requests:

c9300-Sw(config)#radius-server attribute 31 send nas-port-detail mac-only

Change of Authorization (CoA)

11. Use the following commands to configure ISE nodes as CoA servers

12. c9300-Sw(config)#aaa server radius dynamic-author

13. c9300-Sw(config-locsvr-da-radius)#client 172.20.254.21 server-key
ISEisC00L
14. c9300-Sw(config-locsvr-da-radius)#client 172.20.254.22 server-key
ISEisC00L

Device Tracking

Starting Cisco IOS XE Denali 16.1.1 version, the new Switch Integrated Security
Features-based “IP Device Tracking” feature acts as a container policy that enables
snooping and device-tracking features available with First Hop Security (FHS) in both
IPv4 and IPv6, using IP agnostic CLI commands.

The device-tracking configuration is very critical to learn an endpoint’s IP address and

map that to its network access session. The device-tracking configuration is also
essential for many features, such as downloadable ACLs, device profiling, URL
redirection, and more.Refer to the URL for More Information on Device tracking.
12. Configure the device-tracking policy with a custom name:

c9300-Sw(config)#device-tracking policy IPDT_POLICY

13. Under the policy (IPDT_POLICY), enable device tracking.

c9300-Sw(config-device-tracking)#tracking enable

Note: It is a best practice to disable the Device tracking for obtaining information about UDP
protocols.

c9300-Sw(config-device-tracking)#no protocol udp

Note: The device-tracking policy is effective only when applying the policy to switchport
using the following command:

interface GigabitEthernet x/y/z

device-tracking attach-policy POLICY_NAME

Device Sensor

Device Sensor is a Cisco IOS and Cisco AireOS feature that simplifies device profiling
on ISE. The switch gathers raw endpoint data from protocols such as CDP, LLDP &
DHCP and it made available to ISE through RADIUS accounting messages. ISE
collects these device attributes and profiles the endpoints into specific device groups.

14. Enable device sensor globally on the switch:

c9300-Sw(config)#device-sensor accounting

15. Configure below command for the switch to trigger updates to ISE as and when the device
attributes change:

c9300-Sw(config)#device-sensor notify all-changes

16. Configure and apply filters for CDP, LLDP, and DHCP protocols so that only the critical
attributes required for identifying the endpoint type reaches ISE.

The following is an example of a CDP device sensor filter and apply the protocol filter to
the sensor output.

c9300-Sw(config)#cdp run

c9300-Sw(config)#device-sensor filter-list cdp list CDP-LIST

c9300-Sw(config-sensor-cdplist)#tlv name device-name
c9300-Sw(config-sensor-cdplist)#tlv name capabilities-type
c9300-Sw(config-sensor-cdplist)#tlv name version-type
c9300-Sw(config-sensor-cdplist)#tlv name platform-type
c9300-Sw(config-sensor-cdplist)#tlv name address-type

c9300-Sw(config)#device-sensor filter-spec cdp include list CDP-LIST

The following is an example of an LLDP device sensor filter and apply the protocol filter
to sensor output:

c9300-Sw(config)#lldp run

c9300-Sw(config)#device-sensor filter-list lldp list LLDP-LIST

c9300-Sw(config-sensor-lldplist)#tlv name system-name
c9300-Sw(config-sensor-lldplist)#tlv name system-description
c9300-Sw(config-sensor-lldplist)#tlv name system-capabilities

c9300-Sw(config)#device-sensor filter-spec lldp include list LLDP-LIST

The following is an example of a DHCP device sensor filter and apply the protocol filter
to sensor output:

c9300-Sw(config)#device-sensor filter-list dhcp list DHCP-LIST

c9300-Sw(config-sensor-dhcplist)#option name host-name
c9300-Sw(config-sensor-dhcplist)#option name parameter-request-list
c9300-Sw(config-sensor-dhcplist)#option name class-identifier
c9300-Sw(config-sensor-dhcplist)#option name client-identifier
c9300-Sw(config-sensor-dhcplist)#option name requested-address
c9300-Sw(config-sensor-dhcplist)#device-sensor filter-spec dhcp include li
st DHCP-LIST
 Note: Device sensor configuration without a filter list will overload ISE with unnecessary
attributes that does not help in the context of device profiling. The best practice attribute
list provided in the example above works well for most environments. For more details
on profiling, see the ISE Profiling Design Guide.

Web Authentication/URL Redirection and ACLs

Web authentications are necessary for guest internet access. Even if wired guest
access is not a requirement for your environment, it is a good idea to have the
infrastructure set up for URL redirection because it facilitates notifications to end users
in certain scenarios. For instance, when users are not able to authenticate successfully,
they can be redirected to an internal portal such as the following, which will guide them
about how to resolve the issue themselves.

Figure17: Web Authentication Internal portal support page

17. Configure the HTTP service on the switch for URL redirection:

c9300-Sw(config)#ip http server

18. Switch’s internal HTTP/HTTPS server is used for redirection process and its highly encouraged
to decouple this service from Switch Management if HTTP/HTTPS isn’t used for Switch
Management. You can accomplish this using below CLI’s:

19. c9300-Sw(config)#ip http active-session-modules none

c9300-Sw(config)#ip http secure-active-session-modules none

Note:

HTTPS redirection is not recommended for production environments because of the following reasons

 Security concern-HTTPS redirection is intended to hijack a secure web connection initiated by an endpoint, w
idea.
 Failure to work-Most web browsers block intercepted HTTPS connections.
 Certificate warnings-Even if web browsers allow access, there can be certificate warnings because the switch
certificate for TLS handshake.
 Scalability issues-Multiple HTTPS redirections can overload the switch CPU there by degrading the Switch pe

19. (Optional) Provide a domain name when enabling HTTPS redirect:

c9300-Sw(config)#ip domain-name isedemo.lab

20. (Optional) Generate the crypto keys to be used for HTTPS redirection:

c9300-Sw(config)#crypto key generate rsa general-keys mod 2048

Note: Do not run the ip http secure-server command prior to generating the keys. If
you run the commands out of order, the switch automatically generates a certificate with
a smaller key size. This certificate can cause undesirable behavior when redirecting
HTTPS traffic.

21. (Optional) Enable the HTTPS service.

c9300-Sw(config)#ip http secure-server

22. Limit the number of HTTP connections. (The default on a Catalyst 9300 switch is 25, and the
maximum is 50.)

c9300-Sw(config)#ip http max-connections 48

URL Redirection ACL

This ACL defines which traffic is redirected to ISE during the CWA, BYOD, and Posture
scenarios. Any traffic that is permitted per ACL is redirected (192.168.1.10 in the
example below). Implicit deny prevents other traffic types from being redirected. We
recommend that you specify that only HTTP and HTTPS should be permitted since this
traffic gets pushed to the switch CPU. If additional access control is needed in
conjunction with the redirect ACL, we recommend that you use dACL in conjunction with
the redirect ACL.

Note: ACL_WEBAUTH_REDIRECT or Pre-Auth-ACL are port-based ACL which are

configured on the interface. However, the dACL or Per_User_ACL pushed from ISE
takes precedence over the Port ACL that is applied to the Interface.

Figure18: URL Redirection workflow

23. Configure a URL redirect ACL on the switch:

24. c9300-Sw(config)#ip access-list extended ACL_WEBAUTH_REDIRECT

25. c9300-Sw(config-ext-nacl)#permit tcp any any eq www

c9300-Sw(config-ext-nacl)#permit tcp any any eq 443

Note: The ACL name referenced above is identical to the default redirect ACL name
used in fresh ISE 2.0 installation. If you want a different name, make sure that you
update both the switch and the ISE Authorization Profile with a new redirect ACL name.

It is also a good idea to have a separate URL redirect ACL for blacklisted devices on
ISE. The default rules can redirect all the web traffic. However, depending on your
environment and policies, bypass redirection to specific services.

c9300-Sw(config)#ip access-list extended BLOCKHOLE

c9300-Sw(config-ext-nacl)#permit tcp any any eq www
c9300-Sw(config-ext-nacl)#permit tcp any any eq 443

24. Configure a Pre-Authentication ACL (Pre-Auth-ACL). This is required if the deployment

transitions to low-impact mode.

25. c9300-Sw(config)#ip access-list extended IPV4_PRE_AUTH_ACL

26. c9300-Sw(config-ext-nacl)#permit udp any eq bootpc any eq bootps
27. c9300-Sw(config-ext-nacl)#permit udp any any eq domain

c9300-Sw(config-ext-nacl)#deny ip any any

Note: Pre-Auth-ACL is meant to provide basic network access before successful port
authentication in low-impact mode. Therefore, the rules in the ACL must permit only
specific service access that is deemed necessary in a given environment. Typically,
DHCP and DNS services are permitted so that time-sensitive assets can acquire
dynamic IP address while their authentication request is processed by ISE.

Basic Global Configuration for End-Point Authentication

The subsequent sections describe details of the configurations required for performing
802.1X and MAB authentications. However, the following global configurations are
essential for most of the deployment scenarios:
25. Enable 802.1X globally on the switch,use the dot1x system-auth-controlcommand in global
configuration mode.

c9300-Sw(config)#dot1x system-auth-control

(Optional) Allow sessions without dACL to connect to ACL-enabled interfaces with full
access, by running below access-session acl command.

c9300-Sw(config)#access-session acl default passthrough

Note: In older Cisco IOS versions, the epm access-control open command was used
for hosts without an authorization policy to access ports configured with a static
ACL.This feature is useful in an environment where there is a mixture of authorization
profiles that use dACL and ones that do not. For example, user devices are enforced
with dACL to limit access to the network, but no dACL is used on IP phones. When an
IP phone is connected, the IP phone is authorized to voice resources by MAB/802.1X
(without dACL). When a user's device is connected to the back of the IP phone, the
switch enforces user-device dACL, which applies the ACL at the interface level. This
denies IP access to the IP phone because the IP phone lacks dACL for authorization.
However, when the above command is entered globally, the switch dynamically inserts
the permit ip any any ACL for sessions without dACL, including the IP phone.

This is also true for multiple devices connected through an unmanaged hub. If multiple
devices are already connected without dACL, when a new device with dACL AuthZ is
authenticated to the same interface that the unmanaged hub is connected to, then
above feature applies the ip permit any anyACL to the previously connected devices
sessions.

26. Permit endpoints to move from one 802.1X-enabled port to another by running below command:

c9300-Sw(config)#authentication mac-move permit

Switch Global Configuration Dump for AAA, RADIUS

ip domain name isedemo.lab

!
interface Vlan254
description ** Switch management interface **
ip address 172.20.254.101 255.255.255.0
!
aaa new-model
aaa session-id common
!
radius server ISE01
address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
radius server ISE02
address ipv4 172.20.254.22 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
username test-user password 0 test-password
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 3
radius-server deadtime 15
!
aaa group server radius ISE
server name ISE01
server name ISE02
ip radius source-interface Vlan254
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting update newinfo periodic 2880
aaa accounting dot1x default start-stop group ISE
!
aaa server radius dynamic-author
client 172.20.254.21 server-key ISEisC00L
client 172.20.254.22 server-key ISEisC00L
!
lldp run
!
device-sensor filter-list dhcp list DHCP-LIST
option name host-name
option name requested-address
option name parameter-request-list
 option name class-identifier
option name client-identifier
!
device-sensor filter-list lldp list LLDP-LIST
tlv name system-name
tlv name system-description
tlv name system-capabilities
!
device-sensor filter-list cdp list CDP-LIST
tlv name device-name
tlv name address-type
tlv name capabilities-type
tlv name version-type
tlv name platform-type
!
device-sensor filter-spec dhcp include list DHCP-LIST
device-sensor filter-spec lldp include list LLDP-LIST
device-sensor filter-spec cdp include list CDP-LIST
!
device-sensor accounting
device-sensor notify all-changes
!
access-session acl default passthrough
!
Authentication mac-move permit
!
device-tracking policy IPDT_POLICY
no protocol udp
tracking enable
!
crypto key generate rsa general-keys mod 2048
!
ip http server
ip http authentication local
ip http secure-server
ip http secure-active-session-modules none
ip http max-connections 48
ip http active-session-modules none
!
ip access-list extended ACL_WEBAUTH_REDIRECT
permit tcp any any eq www
permit tcp any any eq 443
!
ip access-list extended BLOCKHOLE
permit tcp any any eq www
permit tcp any any eq 443
!
 ip access-list extended IPV4_PRE_AUTH_ACL
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
deny ip any any

Monitoring Authentications with Open Access

This section provides information about how to enable identity-based wired network
access without causing any disruption to regular network connectivity.

Figure19: Open Authentication Workflow

Integrating ISE with Active Directory

Assuming that most environments have a directory server, which is typically Microsoft
Windows Active Directory (AD), the following section focuses on the integration
between ISE and Microsoft Windows AD. If your environment uses a directory service
other than Microsoft Windows AD, see the appropriate guide in the ISE Design &
Integration Guides page.

Prerequisites for Integrating Active Directory and Cisco ISE

 The ISE servers and the Active Directory Domain Controllers must be time synced over Network
Time Protocol (NTP).

 Ensure that trust relationships exist between the domain to which ISE is connected and the
other domains that have user and machine information to which you need access.

 At least one global catalog server that is operational and accessible by ISE in the domain to
which you are joining ISE.
 Domain user account with rights to search, add, and delete machine accounts for ISE, in the
Active Directory domain.

 TCP/UDP ports open for communication between ISE and Domain Controllers (DNS, NTP,
MSRPC, Kerberos, LDAP, LDAP-GC and IPC).

For more details, see Active Directory Integration with Cisco ISE 2.x.

Configuring ISE for Active Directory Integration

1. Log in to ISE(admin node)

2. Navigate to Administration > Identity Management > External Identity Sources > Active
Directory.
3. Click ADD

4. Enter a custom name in the Joint Point Name field, and the domain name in the Active
Directory domain field

5. Click Submit to save the configuration.

6. ClickYes for subsequent notification.

7. Enter the Active Directory username and password.

Note:The credentials used for the join or leave operation are not stored in Cisco ISE.
Only the newly created Cisco ISE machine account credentials are stored.

8. In the Join Operation Status window, verify if the status is Completed

9. Click Close to finish the join procedure.
 Whitelist specific Active Directory Groups

10. Click on the Groups taband select Add > Select Groups from Directory option:
11. UnderRetrieve Groups, select the Active Directory groups that you want to use for the
authorization policies and click OK.

12. Click Save.

 Note: The assumption is that Active Directory domain users who are members of these
whitelisted groups exist.

Let us now see how to validate ISE and Active Directory integration.

13. Click the Connection tab within Active Directory configuration, check the configured ISE node
in the Join Point Name field, and click Test User.
14. In the Test User Authentication window that is displayed, enter a valid domain username and
password and check if the authentication succeeds.
15. Click Close and exit the Active Directory authentication test.

16. Log in to the Catalyst switch and execute the testuser command to validate whether end-to-end
authentication is working well.

17. c9300-Sw#test aaa group radius harry ISEisC00L new-code

18. User successfully authenticated
19.
20. USER ATTRIBUTES
21.
22. username 0 "harry"
23. c9300-Sw#
24. AAA/SG/TEST Platform: Testing Status
25. AAA/SG/TEST: Authen Requests to Send : 1
26. AAA/SG/TEST: Authen Requests Processed : 1
27.
28. <Output truncaked>

Let us now see how to whitelist the network device on ISE.

17. In ISE, navigate to Administration > Network Devices.

18. In the left pane, click Default Device.

19. From the Default Network Device Statusdrop-down list, choose Disabled.

20. Click Save.

21. In the left pane, click Network Devices.

22. In Network Devices area, click Add.

23. In the dialog box displayed, enter the corresponding values in the Name,Description and IP
address

24. Check the RADIUS Authentication Settings checkbox and enter the Shared Secret key in
the Shared Secret field.
 Note: Optionally, you can configure the other parameters in the Network Device
configuration, such as Model Name, Software Version, Location, Device Type, and so
on. The value defined for these attributes can be used in the ISE authentication and
authorization polices to match specific criteria.
25. Click Submit.

Note: ISE allows for bulk configuration of network devices.

One of the options is to upload a CSV file that contains network device details.

The other option is to use REST API calls to the ISE admin node to configure network devices.

For more information, see the Cisco ISE API Reference Guide.

Configure the Switch for Monitor Mode

1. Log in to the Catalyst switch and to configure a physical interface (port), use the interface global
configuration command to enter interface configuration mode.

2. c9300-Sw(config)#interface GigabitEthernet x/y/z

c9300-Sw(config-if)#description ** Endpoints and Users **

2. Configure the switch port mode as access.

Note: None of the authentication-related commands are accepted on the interface

without this basic configuration.

c9300-Sw(config-if)#switchport mode access

c9300-Sw(config-if)#switchport access vlan 100
c9300-Sw(config-if)#switchport voice vlan 101
3. Enable the Spanning Tree PortFast feature.

c9300-Sw(config-if)#spanning-tree portfast

4. Attach the device-tracking policy to the port. (This configuration is essential in Cisco IOS
Version 16.xfor downloadable ACL, URL redirection, SGT, and other authorization options to
work.

c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY

5. To enable open access on the port, use the authentication open command in interface
configuration mode. This command enables monitor mode for the endpoints. New MAC
addresses that are detected on the port are allowed unrestricted Layer 2 access to the network
even before any authentication has succeeded.

c9300-Sw(config-if)#authentication open

6. By default, an 802.1X-enabled switch port accepts only one MAC address. Since the idea of
open mode is to ensure that there is no disruption, enabling multi-auth host mode is
recommended, which allows for one IP Phone an unlimited number of
workstations/data_endpoints to authenticate on the interface.

c9300-Sw(config-if)#authentication host-mode multi-auth

7. For switch to initiate authentication when the link state changes from down to up state, use the
below command to enable authentication on the switch port

c9300-Sw(config-if)#authentication port-control auto

8. Configure the switch port as an 802.1X authenticator.

c9300-Sw(config-if)#dot1x pae authenticator

9. Enable MAC Authentication Bypass on the same switch port.

c9300-Sw(config-if)#mab
 Authentication Timer Settings

10. By default, the 802.1X to MAB timeout period is 90 seconds; a 30-second timeout for each EAP
request sent to the endpoint, with 2 retries. 90 seconds can cause a significant delay for certain
endpoints in obtaining an IP address and gain network access. In open mode, this is not a
concern because the port is always open. However, when the network transitions to closed
mode, this could be a concern. The best practice configuration for the 802.1X timeout period
that works for most environments is about 30 seconds. Configure dot1x timeout and dot1x max-
reauth-req interface configuration commands to achieve it.

11. c9300-Sw(config-if)#dot1x timeout tx-period 7

c9300-Sw(config-if)#dot1x max-reauth-req 3

11. (Optional) Enable the reauthentication and inactivity timer for the port. Use the authentication
periodic command to enable automatic reauthentication on a port whether the values are
statically assigned on the port or are derived from the RADIUS server.

c9300-Sw(config-if)#authentication periodic

12. (Optional) To specify the period of time to reauthenticate the authorized port and to allow the
reauthentication timer interval (session timer) to be downloaded to the switch from the RADIUS
server:

c9300-Sw(config-if)#authentication timer reauthenticate server

13. (Optional) Allow the inactivity timer interval to be downloaded to the switch from the RADIUS
server. The dynamic keyword instructs the switch to send out an ARP probe before removing
the session to make sure the device is indeed disconnected.

c9300-Sw(config-if)#authentication timer inactivity server dynamic

IBNS 1.0 interface Configuration for Monitor Mode

interface GigabitEthernet1/0/1
description ** Endpoints and Users **
switchport access vlan 100
switchport mode access
 switchport voice vlan 101
device-tracking attach-policy IPDT_POLICY
authentication host-mode multi-auth
authentication open
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication timer inactivity server dynamic
mab
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
spanning-tree portfast

Configuring Microsoft Windows and Apple OS X Devices for 802.1X

Configuring Microsoft Windows 10 for Wired 802.1X

1. Log in to a Windows workstation.

2. Go to the Services
3. Start the Wired AutoConfig
4. From the Startup type drop-down list, choose Automatic.

5. Navigate to the Wired Ethernet port’s adapter settings by choosing Start > Settings > Ethernet
> Change Adapter Settings.
6. Click Properties.

7. Click the Authentication

8. From the Settings drop-down list, choose the Microsoft: Protected EAP (PEAP)authentication
method.
9. Have the Verify the server’s identity by validating the certificateoption unchecked.
Recommended to have correct CA certificate imported on the endpoints, unchecking this option
should only be for testing purpose prior to importing the CA Certificate.

10. Uncheck the Automatically user my Windows logon name…

11. Click Configure under Select Authentication Method.

12. In the EAP MSCHAPv2 Propertiesdialog box that is displayed, if the endpoint is an Active
Directory-managed endpoint, and if the Windows domain login name is preferred for 802.1X
authentication, check the “Automatically use my Windows logon name and password” check
box.
 Note: We strongly recommend that you do not disable the server certificate validation
option on the supplicant. This can subject endpoints to Man-in-the-middle and various
other attacks. While disabling the server certificate validation in the supplicant can help
in quickly testing an endpoint for 802.1X authentication, we strongly recommended that
you do the exact opposite in a production environment.

13. Click OK in the EAP MSCHAPv2 Properties dialog box.

14. Click OK in the Protected EAP Properties

15. If you unchecked the Automatically user my Windows logon name check box, under
the EAP MSCHAPv2 Properties, click Additional Settings.

16. From Specify authentication mode drop-down list, choose the authentication mode
(user/computer/user/guest). For quick validation, choose User Authentication.

17. Enter the username and password and click OK.

 The Windows endpoint is now ready for wired 802.1X authentication.

Note: Although the configuration explained in this section enables 802.1X on a Microsoft Windows en
be used to validate the end-to-end configuration in an ISE deployment, it is not a recommended config
for a large-scale production network. When it comes to a production setup, the following guidelines m
considered:

 Install the ISE server certificate or have the root CA certificate (a signed ISE certificate) installed on the endpo
certificate store.
 Enable server certificate validation in the supplicant settings for PEAP.
 If it is an Active Directory-managed Windows endpoint, enable the user or computer authentication option.
 If it is an Active Directory-managed Windows endpoint, set the Windows domain login credentials to be used fo
authentication by checking the Automatically use my Windows logon name and password check box.
 For Active Directory-managed Windows endpoints, enable 802.1x settings via Group Policy Management…. Fo
information, see Configure 802.1X Wired Access Clients by using Group Policy Management.
 For BYOD Windows endpoints, use ISE’s native supplicant provisioning flow to install the server certificate and
adapter settings.

Configuring an Apple MacBook for Wired 802.1X

1. Connect the USB to Ethernet or the Apple Thunderbolt Ethernet adapter to the MacBook.

2. Navigate to System Preferences > Network.

 In a few seconds, an authentication window is displayed, asking you enter 802.1X
username and password.

3. In the Account name and Password fields, enter the corresponding values and click OK.
4. You will be asked to accept the server certificate. Click Continue.
5. In the dialog box that is displayed, provide the local system administrator username and
password to add the ISE certificate to the local trusted certificate store.
You should see the change in IP address and the domain name. Also, note that the
802.1X session timer starts after successful authentication.
 Note: As with Microsoft Windows Active Directory and third-party systems managers for Windows end
managers are available for Apple OS X devices. These managers can manage inventory, build and de
applications, and enforce polices on all the managed OS X endpoints in a given environment. For an e
systems manager can be used to remotely manage 802.1X configurations on Apple Mac endpoints, s
Network Authentication for Mac.

Monitoring Authentication Sessions

1. Log in to ISE.

The dashboard displays the total number of endpoints that are connected to the
network.
2. Click on a number to see the details:
3. Navigate to Operations > RADIUS: Live Logs.You will see that all the endpoints connected to
the network so far have received a permit access.

4. Log in to the Catalyst switch and check the authentication sessions

5. c9300-Sw#show authentication sessions

6. Interface MAC Address Method Domain Status Fg Session
ID
7. --------------------------------------------------------------------------
------------------
8. Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 65FE14
AC0000001F1D04947E
9. Gi1/0/1 0064.40b5.794e mab DATA Auth 65FE14
AC000000201D049D86
10. Gi1/0/5 406C.8F39.17AE dot1x DATA Auth
65FE14AC0000000E1845E2D2
11.
12. <Output trunckated>

5. Check the authentication session details on a specific port

6. c9300-Sw#show authentication session interface Gi 1/0/1 details

7. Interface: GigabitEthernet1/0/1
8. IIF-ID: 0x119631A2
9. MAC Address: 0050.56a7.fa8a
10. IPv6 Address: fe80::e55d:20e1:8f:d008
11. IPv4 Address: 172.20.100.10
12. User-Name: harry
13. Status: Authorized
14. Domain: DATA
15. Oper host mode: multi-auth
16. Oper control dir: both
17. Session timeout: N/A
18. Common Session ID: 65FE14AC0000001F1D04947E
19. Acct Session ID: 0x00000015
20. Handle: 0x3f000015
21. Current Policy: POLICY_Gi1/0/1
22.
23. Server Policies:
24. Security Policy: None
25. Security Status: Link Unsecured
26.
27. Method status list:
28. Method State
29. dot1x Authc Success
30.
31. ----------------------------------------
32. Interface: GigabitEthernet1/0/1
33. IIF-ID: 0x14A4B799
34. MAC Address: 0064.40b5.794e
35. IPv6 Address: Unknown
36. IPv4 Address: 172.20.101.3
37. User-Name: 00-64-40-B5-79-4E
38. Status: Authorized
39. Domain: DATA
40. Oper host mode: multi-auth
41. Oper control dir: both
42. Session timeout: N/A
43. Common Session ID: 65FE14AC000000201D049D86
44. Acct Session ID: 0x00000016
45. Handle: 0xb5000016
46. Current Policy: POLICY_Gi1/0/1
47.
48. Server Policies:
49.
50. Method status list:
51. Method State
52. dot1x Stopped
53. mab Authc Success

Configuring and Understanding the IBNS 2.0 Policy

One of the simplest ways to configure IBNS 2.0 is to convert an existing IBNS 1.0
configuration on the switch. However,using a composite configuration in IBNS 1.0 style
is recommended for the system to generate the best possible policy configuration in the
new style. Note that when you convert the configurations, a policy map, a set of class
maps, and service templates that will be configured for every single port that has the
identity-related configuration. Therefore, the recommendation is to covert a single-port
IBNS 1.0 configuration to IBNS 2.0 in a lab, and once a level of comfort is reached in
this setting, deploy it in production.

1. Log in to the switch.

2. Pre-configure the switch for best practice global configurationsand Open mode interface
configurationon one interface.
3. Execute the IBNS 1.0 to 2.0 conversation command “authentication display new-style”

4. c9300-Sw#authentication display new-style

5.
6. Please note that while you can revert to legacy style
7. configuration at any time unless you have explicitly
8. entered new-style configuration, the following caveats
9. should be carefully read and understood.
10.
11. (1) If you save the config in this mode, it will be written
12. to NVRAM in NEW-style config, and if you subsequently
13. reload the router without reverting to legacy config and
14. saving that, you will no longer be able to revert.
15.
16. (2) In this and legacy mode, Webauth is not IPv6-capable. It
17. will only become IPv6-capable once you have entered new-
18. style config manually, or have reloaded with config saved
19. in 'authentication display new' mode.
20.
21. (3) 'Default' and 'rollback' commands should not be used in this
22. display mode. Either remain in legacy display mode or switch
23. to new-style configuration mode before use.

You will notice that the identity configurations have changed on the interface and new
control policy added

c9300-Sw#show running-config interface Gi 1/0/1

Building configuration...

Current configuration : 523 bytes

!
interface GigabitEthernet1/0/1
description ** Endpoints and Users **
switchport access vlan 100
switchport mode access
switchport voice vlan 101
device-tracking attach-policy IPDT_POLICY
authentication periodic
authentication timer reauthenticate server
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
spanning-tree portfast
service-policy type control subscriber POLICY_Gi1/0/1
end

Note: The authentication display new-style command converts an existing IBNS 1.0 configuration t
new style configurations can be reverted to the old style with the authentication display legacy priv
mode command. However, note that in the new style, if any changes are made to the policy map or an
specific commands, or if the system is reloaded with new style configurations written to the startup co
will not be able to revert back to the IBNS 1.0 style configurations from IBNS 2.0.
4. Convert the system authentication configuration mode to the new style, that is, the IBNS 2.0
style

5. c9300-Sw#configure terminal
6. Enter configuration commands, one per line. End with CNTL/Z.
7. c9300-Sw(config)#
8. c9300-Sw(config)#authentication convert-to new-style
9. This operation will permanently convert all relevant authentication comman
ds to their CPL
10. control-policy equivalents. As this conversion is irreversible and
will disable the conversion
11. CLI 'authentication display [legacy|new-style]', you are strongly
advised to back up your current
12. configuration before proceeding.
13. Do you wish to continue? [yes]: yes

5. Review the class-maps and policy-map configuration:

Table5: IBNS 2.0 Class-Map Configurations

 Table6: IBNS 2.0 Policy-Map Configurations

6. Switch now running new style configuration mode, show authentication commands are now
replaced with show access-session

Additional Best-Practice Configurations for IBNS 2.0

1. Copy the interface configuration from the switch port and configure an interface template

2. c9300-Sw(config)#template PORT-AUTH-TEMPLATE
3. c9300-Sw(config-template)#description ** Endpoints and Users **
4. c9300-Sw(config-template)#switchport access vlan 100
5. c9300-Sw(config-template)#switchport mode access
6. c9300-Sw(config-template)#switchport voice vlan 101
7. c9300-Sw(config-template)#authentication periodic
8. c9300-Sw(config-template)#authentication timer reauthenticate server
9. c9300-Sw(config-template)#access-session port-control auto
10. c9300-Sw(config-template)#mab
11. c9300-Sw(config-template)#dot1x pae authenticator
12. c9300-Sw(config-template)#spanning-tree portfast
13. c9300-Sw(config-template)#service-policy type control subscriber P
OLICY_Gi1/0/1
14. c9300-Sw(config-template)#end
15.

Note: Certain interface commands are not supported within interface templates currently.
They need to be explicitly configured on the port. The following are the caveats:

Defect ID Unsupported command(s)

CSCvd77095 ‘no lldp transmit’

CSCvd77088 ‘device-tracking’

CSCvd78152 ‘ip verify source’

CSCvd78154 ‘ip access-group’

Note: Notice that the access-session closed command (as on Step 3) is part of the
conversion and is being omitted in the interface template configuration. This is because
the section focuses on low-impact mode, which is a minor variation of the open mode; in
IBNS 2.0, the default port mode is open mode. To move the port to closed mode,
configure the access-session closed interface command explicitly either within the
interface template or on the physical port

2. Reset the configuration on the interface back to default using “default interface” command and
apply the interface template along with other supporting commands for IBNS

3. c9300-Sw(config)#default interface GigabitEthernet1/0/1

4. Interface GigabitEthernet1/0/1 set to default configuration
5. c9300-Sw(config)#
6. c9300-Sw(config)#interface GigabitEthernet1/0/1
7. c9300-Sw(config-if)#source template PORT-AUTH-TEMPLATE
8. c9300-Sw(config-if)#spanning-tree portfast
9. c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY
10. c9300-Sw(config-if)#end
11. c9300-Sw#

3. Verify the interface configuration

4. c9300-Sw#show running-config interface GigabitEthernet 1/0/1

5. Building configuration...
6.
7. Current configuration : 192 bytes
8. !
9. interface GigabitEthernet1/0/1
10. device-tracking attach-policy IPDT_POLICY
11. source template PORT-AUTH-TEMPLATE
12. spanning-tree portfast
13. end

4. Check the cumulative configuration applied on the port at runtime

5. c9300-Sw#show derived-config interface GigabitEthernet 1/0/1

6. Building configuration...
7.
8. Derived configuration : 525 bytes
9. !
10. interface GigabitEthernet1/0/1
11. description ** Endpoints and Users **
12. switchport access vlan 100
13. switchport mode access
14. switchport voice vlan 101
15. device-tracking attach-policy IPDT_POLICY
16. authentication periodic
17. authentication timer reauthenticate server
18. access-session port-control auto
19. mab
20. dot1x pae authenticator
21. dot1x timeout tx-period 7
22. dot1x max-reauth-req 3
23. spanning-tree portfast
24. service-policy type control subscriber POLICY_Gi1/0/1
25. end

You will also notice some minor changes to the global configuration:
 c9300-Sw#show running-config aaa | include accounting
aaa accounting Identity default start-stop group ISE
aaa accounting update newinfo periodic 2880

Note:

Global AAA and RADIUS server configurations for IBNS 1.0 and IBNS 2.0 are very alike, barring a few
differences:

 The aaa accounting dot1x command is converted to aaa accounting identity in IBNS 2.0 style.
 The authentication mac-move permit command is the default in IBNS 2.0, and therefore, the configuration do
the running configuration. If you want to disable mac-move, configure access-session mac-move deny explic
configuration mode.
 The device-sensor accounting command is replaced with the access-session attributes filter-list command

Switch Global Configuration for AAA, RADIUS in IBNS 2.0

Below is Switch Global AAA,Radius & device sensor configurations

ip domain name isedemo.lab

!
interface Vlan254
description ** Switch management interface **
ip address 172.20.254.101 255.255.255.0
!
aaa new-model
aaa session-id common
!
radius server ISE01
address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
radius server ISE02
address ipv4 172.20.254.22 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
dot1x system-auth-control
dot1x critical eapol
!
username test-user password 0 test-password
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 3
radius-server deadtime 15
!
aaa group server radius ISE
server name ISE01
server name ISE02
ip radius source-interface Vlan254
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting Identity default start-stop group ISE
aaa accounting update newinfo periodic 2880
!
aaa server radius dynamic-author
client 172.20.254.21 server-key ISEisC00L
client 172.20.254.22 server-key ISEisC00L
!
lldp run
!
device-sensor filter-list dhcp list DHCP-LIST
option name host-name
option name requested-address
option name parameter-request-list
option name class-identifier
option name client-identifier
!
device-sensor filter-list lldp list LLDP-LIST
tlv name system-name
tlv name system-description
tlv name system-capabilities
!
device-sensor filter-list cdp list CDP-LIST
tlv name device-name
tlv name address-type
tlv name capabilities-type
tlv name version-type
tlv name platform-type
!
device-sensor filter-spec dhcp include list DHCP-LIST
device-sensor filter-spec lldp include list LLDP-LIST
device-sensor filter-spec cdp include list CDP-LIST
!
device-sensor notify all-changes
!
access-session attributes filter-list list Def_Acct_List
cdp
lldp
dhcp
http
access-session accounting attributes filter-spec include list Def_Acct_Lis
t
!
access-session acl default passthrough
!
device-tracking policy IPDT_POLICY
no protocol udp
tracking enable
!
crypto key generate rsa general-keys mod 2048
!
ip http server
ip http authentication local
ip http secure-server
ip http secure-active-session-modules none
ip http max-connections 48
ip http active-session-modules none
!
ip access-list extended ACL_WEBAUTH_REDIRECT
permit tcp any any eq www
permit tcp any any eq 443
!
ip access-list extended BLOCKHOLE
permit tcp any any eq www
permit tcp any any eq 443
!
ip access-list extended IPV4_CRITICAL_ACL
permit ip any any
!
ip access-list extended IPV4_PRE_AUTH_ACL
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
deny ip any any
!
5. Create a backup of your current configuration file on Flash using copy running-config flash: so
that you can restore a Monitor-mode configuration when migrating to Closed Mode.

Migrating from Monitor Mode

In Monitor Mode, authentication occurs but network access is not restricted based on
the authentication result. A combination of Cisco Identity Services Engine (ISE) policies
and switchport commands is used to give all devices full access to the network. In
Monitor Mode, network administrators can determine which users or devices would
have failed authentication and why.

Cisco Recommends deploying 802.1x in a staged approach. The stages begin with
Monitor Mode as the initial stage and end state will be either Low-Impact Mode or
Closed Mode. The deployment modes beyond Monitor-Mode gradually builds access
controls into the design through Port-based ACLs, dACLS and /or VLAN authorizations.

Pre-Authentication and Post-Authentication Access

Control with Low Impact
After gaining enough visibility in the monitor mode, the next step is to enforce restricted
access. Low-Impact mode incrementally increases the security level of the network by
configuring an ingress port ACL on top of Monitor-Mode interface configurations. This
provides basic connectivity for hosts while selectively limiting access and introducing a
higher level of security. Pre-authentication access control is be done via port access
control lists which are locally defined on the switchport, post-authentication access
control can be done via downloadable or named access control lists. Such level of
access is required for PXE boot environments where network access must be granted
prior to authentication.

Note: Dynamic VLAN assignment is not a recommended authorization option for low-impact mode. S
acquire IP address before network authentication in the default VLAN, a change in the VLAN assignm
endpoints to renew their IP addresses, which might not happen automatically, thereby locking them ou
in spite of an authorized access as per ISE policy.

Some endpoint types have the intelligence to detect network changes. The Windows workstation for in
attempts to ping the default gateway (thrice within seconds) with TTL=1, upon receiving an EAP-Succ
from the switch, endpoint assumes that there is no change in the VLAN and retains its IP address. If
 doesn’t respondendpoint releases the IP address . This feature was introduced in Windows XP SP2 w
KB:

KB822596: DHCP does not obtain a new address when EAP reauthenticates across access points w
that differ.

The behavior with Apple macOS X is similar. However, when the system receives an EAP success m
endpoint tries to reach the DHCP server to renew its IP address, thrice with a minute wait time betwee

Switch Configuration for Low Impact Mode

1. Log in to the switch.

2. Verify the Pre-Authentication AC(Pre-Auth-ACL) configured in “URL Redirection ACL” Section

3. c9300-Sw#show ip access-list IPV4_PRE_AUTH_ACL

4. Extended IP access list IPV4_PRE_AUTH_ACL
5. 10 permit udp any eq bootpc any eq bootps
6. 20 permit udp any any eq domain
7. 30 deny ip any any

3. On a per-port basis, Apply the Pre-Auth-ACL in the ingress direction to convert the port from
Monitor mode to Low Impact Mode.

4. c9300-Sw(config)#interface gigabitEthernet 1/0/1

c9300-Sw(config-if)#ip access-group IPV4_PRE_AUTH_ACL in

4. Check the cumulative configuration applied on the port at runtime

5. c9300-Sw#show derived-config interface GigabitEthernet 1/0/1
6. Building configuration...
7.
8. Derived configuration : 525 bytes
9. !
10. interface GigabitEthernet1/0/1
11. description ** Endpoints and Users **
12. switchport access vlan 100
13. switchport mode access
14. switchport voice vlan 101
15. device-tracking attach-policy IPDT_POLICY
16. ip access-group IPV4_PRE_AUTH_ACL in
17. authentication periodic
18. authentication timer reauthenticate server
19. access-session control-direction in
20. access-session port-control auto
21. mab
22. dot1x pae authenticator
23. dot1x timeout tx-period 7
24. dot1x max-reauth-req 3
25. spanning-tree portfast
26. service-policy type control subscriber POLICY_Gi1/0/1
27. end

Downloadable ACL Authorization

5. Log in to ISE and navigate to Policy > Results

6. In the left pane, click Authorization > Downloadable ACLs.
7. Click Add.
8. Create a dACL each for Employees and IP phones.
9. After the dACL rules are written, validate them by clicking the Check DACL Syntax
10. Click Submit.

Note: In this example, Employees are denied access to a specific subnet PCI network and are given a
everything else. IP phones have access to the subnet where the Call Manager, DHCP, DNS servers a
in the default and voice VLANs reside,

and the rest of the network access is denied.

In terms of the Access Control Entries (ACEs) for the downloadable ACLs, the recommendation is to k
that it is easy to download the policy to the network device. In addition, small ACLs can optimize the T
Addressable Memory (TCAM) memory consumption on the access switch. The best practice limit for d
ACEs (64 lines).

11. In the left pane, click Authorization Profiles and then click Add.
12. Create a new Authorization Profile and reference the Employee ACL.
13. Click Submit.
14. Repeat the same procedure for the Voice ACL. However, for IP phones, you should check
the Voice Domain Permission authorization check box.
15. Click Submit.
16. Navigate to the Policy > Policy Sets>Authorization Policypage for Employees and IP phones
policy. (Below two policies can be configured using custom policy set or modified default policy
set )
17. Update or create the Employee and IP phone authorization rule as show below and save the
configuration.
 Validating ACL Authorization/Low-Impact Mode

18. Log in to ISE.

19. Navigate to Operations > RADIUS: Live Logs.

You will see that both the Employee PC and the IP phones have dACL authorization.

20. Click the Details icon pertaining to an ACL entry.

In the Result dialog box, you will see individual dACL rules that are downloaded to the
switch.
21. Log in to the switch, and check the authentication sessions.

Note: In IBNS 2.0, most of the authentication commands are converted to access-
session commands. So, show authentication sessions is show access-session in
IBNS 2.0.

c9300-Sw#show access-session interface Gi 1/0/1 details

Interface: GigabitEthernet1/0/1
IIF-ID: 0x1639E95C
MAC Address: 0064.40b5.794e
IPv6 Address: Unknown
IPv4 Address: 172.20.101.3
User-Name: 00-64-40-B5-79-4E
Status: Authorized
Domain: VOICE
 Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 65FE14AC0000003532D7D09C
Acct Session ID: 0x0000002b
Handle: 0x6800002b
Current Policy: POLICY_Gi1/0/1

Local Policies:
Idle timeout: 65536 sec

Server Policies:
ACS ACL: xACSACLx-IP-VoiceACL-5aee9aa7

Method status list:

Method State
dot1x Stopped
mab Authc Success

----------------------------------------
Interface: GigabitEthernet1/0/1
IIF-ID: 0x1645C323
MAC Address: 0050.56a7.fa8a
IPv6 Address: fe80::e55d:20e1:8f:d008
IPv4 Address: 172.20.100.10
User-Name: harry
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 65FE14AC0000003432D7C631
Acct Session ID: 0x0000002a
Handle: 0x7d00002a
Current Policy: POLICY_Gi1/0/1

Local Policies:
Idle timeout: 65536 sec

Server Policies:
Security Policy: None
Security Status: Link Unsecured
SGT Value: 4
ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60

Method status list:

Method State
 dot1x Authc Success

Note: The dACL names are appended with session timestamps when downloaded from
ISE.

22. Verify the downloaded ACL on the switch using “show ip access-list” command

23. c9300-Sw#show ip access-lists | section xACSACLx-IP-

24. Extended IP access list xACSACLx-IP-EmployeeAccessACL-5aee9a60
25. 1 deny ip any 172.20.199.0 0.0.0.255
26. 2 permit ip any any
27. Extended IP access list xACSACLx-IP-VoiceACL-5aee9aa7
28. 1 permit ip any 172.20.254.0 0.0.0.255
29. 2 permit ip any 172.20.100.0 0.0.0.255
30. 3 permit ip any 172.20.101.0 0.0.0.255
31. 4 deny ip any any
32.

23. Further you can run platform-specific command to understand which ACLs are applicable for
specific endpoints. In the example below, which is for a Catalyst 9300 switch, you can see that
on GigabitEthernet 1/0/1 interface, any MAC address (0000.0000.0000) is subject to
IPV4_PRE_AUTH_ACL, the IP phone MAC address is subject to IP-Voice-ACL +
IPV4_PRE_AUTH_ACL, and the Employee’s PC is access controlled by EmployeeAccessACL
+ IPV4_PRE_AUTH_ACLs

24. c9300-Sw#show platform software fed switch 1 acl interface | begin

1/0/1
25. INTERFACE: GigabitEthernet1/0/1
26. MAC 0000.0000.0000
27. ########################################################
28. intfinfo: 0x7fa8fc02cba8
29. Interface handle: 0xaa000027
30. Interface Type: Port
31. IIF ID: 0x8
32. Input IPv6: Policy Handle: 0x990000b6
33. Policy Name: sisf v6acl 0001DF9F
34. CG ID: 16
35. CGM Feature: [0] acl
36. Bind Order: 0
37.
38. Input IPv4: Policy Handle: 0xef00007a
39. Policy Name: IPV4_PRE_AUTH_ACL
40. CG ID: 19
41. CGM Feature: [0] acl
42. Bind Order: 0
43.
44. INTERFACE: Client MAC 0064.40b5.794e
45. MAC 0064.40b5.794e
46. ########################################################
47. intfinfo: 0x7fa8fc036638
48. Interface handle: 0xc2000085
49. Interface Type: Group
50. IIF ID: 0x1c314c66
51. Input IPv4: Policy Handle: 0x6a0000ba
52. Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-VoiceACL-5aee9a
a7:
53. CG ID: 4880
54. CGM Feature: [35] acl-grp
55. Bind Order: 0
56.
57. INTERFACE: Client MAC 0050.56a7.fa8a
58. MAC 0050.56a7.fa8a
59. ########################################################
60. intfinfo: 0x7fa8fc058078
61. Interface handle: 0xf9000084
62. Interface Type: Group
63. IIF ID: 0x1debb70b
64. Input IPv4: Policy Handle: 0x640000b7
65. Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-EmployeeAccessA
CL-5aee9a60:
66. CG ID: 4624
67. CGM Feature: [35] acl-grp

Bind Order: 0

Note: Similar ACL programming information can be obtained on the Catalyst 3650 and
3850 switch platforms by running the show platform acl le privileged EXEC mode
command.

In the other platforms, running the show ip access-list interface <interface-id>

command will provide the cumulative list of ACEs that are applied on a specific port.

Role-Based Critical Authorization

 One of the many advantages of using IBNS 2.0 is that it can handle failure scenarios
efficiently. With a few additional tweaks to the previously configured IBNS 2.0
configuration, endpoints that have been authorized previously by ISE can be given the
same level of network access even when the server is not reachable the next time. The
idea is to grant role-based access during critical conditions, instead of applying a
common critical authorization.

Figure20: Critical Authorization in Low-Impact Mode

Cisco IOS Changes for Role-Based Critical Authorization

In the following procedure, a user role ‘Employees’ is created which is the same name
as Security Group Tag on ISE. When Employee users authenticate the first time, the
user role is downloaded from ISE. Later, when the same users re-connect to the
network when ISE is unreachable, the same network access authorization is applied
locally by the switch.

24. Log in to the switch and configure IP ACL for Employee users.
 Note that the ACL rules are the same as the downloadable ACLs configured on ISE for
the Employee user group.

c9300-Sw(config)#ip access-list extended IPV4_EMPLOYEE_CRITICAL_ACL

c9300-Sw(config-ext-nacl)#deny ip any 172.20.199.0 0.0.0.255
c9300-Sw(config-ext-nacl)#permit ip any any

25. Configure a service template that matches the ISE authorization policy results in ISE for the
Employee user group exactly.

26. c9300-Sw(config)#service-template EMPLOYEE_CRITICAL_AUTH_ACCESS

27. c9300-Sw(config-service-template)#description ** Policy For Employ
ees during IAB **
28. c9300-Sw(config-service-template)#access-group IPV4_EMPLOYEE_CRIT
ICAL_ACL
29. c9300-Sw(config-service-template)#sgt 4

Current ISE policy for the Employee user group

26. Create a class map to match the Employee user role and the AAA down condition.

27. c9300-Sw(config)#class-map type control subscriber match-all AAA_D

OWN_UNAUTHD_EMPLOYEE
28. c9300-Sw(config-filter-control-classmap)#match result-type aaa-tim
eout
29. c9300-Sw(config-filter-control-classmap)#match authorization-statu
s unauthorized

c9300-Sw(config-filter-control-classmap)#match user-role Employees

27. Create two class maps that evaluate the critical authorization conditions.
28. c9300-Sw(config)# class-map type control subscriber match-any IN_C
RITICAL_AUTH
29. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp CRITICAL_AUTH_ACCESS
30. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp DEFAULT_CRITICAL_VOICE_TEMPLATE
31. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp EMPLOYEE_CRITICAL_AUTH_ACCESS
32. c9300-Sw(config-filter-control-classmap)#exit
33.
34. c9300-Sw(config)#class-map type control subscriber match-none NOT_
IN_CRITICAL_AUTH
35. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp CRITICAL_AUTH_ACCESS
36. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp DEFAULT_CRITICAL_VOICE_TEMPLATE
37. c9300-Sw(config-filter-control-classmap)#match activated-service-t
empl EMPLOYEE_CRITICAL_AUTH_ACCESS
38. c9300-Sw(config-filter-control-classmap)#exit

28. Either modify the existing policy or create a new policy map to match the differentiated critical
authorization state and apply the new service template when the ISE service is unavailable for
the Employee devices. In this sample procedure, a new policy map is created in global
configuration mode with changes that are minor when compared to the previous ones. Note the
highlighted sections in the following example.

29. policy-map type control subscriber PORT-AUTH-POLICY

30. event session-started match-all
31. 10 class always do-until-failure
32. 10 authenticate using dot1x priority 10
33. event authentication-failure match-first
34. 5 class DOT1X_FAILED do-until-failure
35. 10 terminate dot1x
36. 20 authenticate using mab priority 20
37. 15 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
38. 10 clear-authenticated-data-hosts-on-port
39. 20 activate service-template EMPLOYEE_CRITICAL_AUTH_ACCESS
40. 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
41. 40 authorize
42. 50 pause reauthentication
43. 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
44. 10 pause reauthentication
45. 20 authorize
46. 30 class DOT1X_NO_RESP do-until-failure
47. 10 terminate dot1x
48. 20 authenticate using mab priority 20
49. 40 class MAB_FAILED do-until-failure
50. 10 terminate mab
51. 20 authentication-restart 60
52. 60 class always do-until-failure
53. 10 terminate dot1x
54. 20 terminate mab
55. 30 authentication-restart 60
56. event agent-found match-all
57. 10 class always do-until-failure
58. 10 terminate mab
59. 20 authenticate using dot1x priority 10
60. event aaa-available match-all
61. 10 class IN_CRITICAL_AUTH do-until-failure
62. 10 clear-session
63. 20 class NOT_IN_CRITICAL_AUTH do-until-failure
64. 10 resume reauthentication
65. event inactivity-timeout match-all
66. 10 class always do-until-failure
67. 10 clear-session
68. event authentication-success match-all
69. event violation match-all
70. 10 class always do-until-failure

10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE

29. Apply the new policy to the interface.

30. c9300-Sw(config)#template PORT-AUTH-TEMPLATE

31. c9300-Sw(config-template)#description ** Endpoints and Users **
32. c9300-Sw(config-template)#switchport access vlan 100
33. c9300-Sw(config-template)#switchport mode access
34. c9300-Sw(config-template)#switchport voice vlan 101
35. c9300-Sw(config-template)#authentication periodic
36. c9300-Sw(config-template)#authentication timer reauthenticate serv
er
37. c9300-Sw(config-template)#access-session control-direction in
38. c9300-Sw(config-template)#access-session port-control auto
39. c9300-Sw(config-template)#mab
40. c9300-Sw(config-template)#dot1x pae authenticator
41. c9300-Sw(config-template)#spanning-tree portfast
42. c9300-Sw(config-template)#no service-policy type control subscribe
r PORT-AUTH-POLICY
43. c9300-Sw(config-template)#service-policy type control subscriber P
ORT-AUTH-POLICY
44. c9300-Sw(config-template)#end

ISE Authorization with User Role

30. Log in to ISE.

31. Navigate to Policy > Policy Elements > Results.
32. In the left pane, click Authorization > Authorization Profiles.
33. ClickAdd.
34. Create a new authorization profile with Cisco AV Pair: role=<user-role>.
35. Modify the Employee Authorization rule.

36. Authenticate or re-authenticate the Employee user.

37. c9300-Sw#show access-session interface gigabitEthernet 1/0/1 detai

ls
38. Interface: GigabitEthernet1/0/1
39. IIF-ID: 0x1E27B669
40. MAC Address: 0050.56a7.fa8a
41. IPv6 Address: Unknown
42. IPv4 Address: 172.20.100.10
43. User-Name: harry
44. User-Role: Employees
45. Status: Authorized
46. Domain: DATA
47. Oper host mode: multi-auth
48. Oper control dir: in
49. Session timeout: N/A
50. Common Session ID: 65FE14AC0000005A3912107F
51. Acct Session ID: 0x00000050
52. Handle: 0xbb000050
53. Current Policy: PORT-AUTH-POLICY
54.
55.
56. Local Policies:
57. Idle timeout: 65536 sec
58.
59. Server Policies:
60. Security Policy: None
61. Security Status: Link Unsecured
62. SGT Value: 4
63. ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60
64.
65. Method status list:
66. Method State

dot1x Authc Succes

The user role is cached on the switch.

Note: In case of empty cache, make sure “device classifier” is enabled.

c9300-Sw#show access-session cache

Access session cache details
----------------------------------------
MAC Address: 0050.56a7.fa8a
Device-type:
User-role: Employees
Protocol-map: 00000000
----------------------------------------
<Output truncated>

The IP ACL is applied to the Employee’s session.

c9300-Sw#show ip access-lists xACSACLx-IP-EmployeeAccessACL-5aee9a60

Extended IP access list xACSACLx-IP-EmployeeAccessACL-5aee9a60
1 deny ip any 172.20.199.0 0.0.0.255
2 permit ip any any
 Validating Role-Based Critical Authorization

37. Make sure the ISE servers are unreachable from ISE.

38. c9300-Sw#show aaa servers | include id|State

39. RADIUS: id 1, priority 1, host 172.20.254.21, auth-port 1812, acct
-port 1813
40. State: current DEAD, duration 107s, previous duration 555708s
41. Platform State from SMD: current DEAD, duration 106s, previou
s duration 556543s
42. Platform State from WNCD: current UP, duration 0s, previous d
uration 0s
43. RADIUS: id 2, priority 2, host 172.20.254.22, auth-port 1812, acct
-port 1813
44. State: current DEAD, duration 92s, previous duration 555723s
45. Platform State from SMD: current DEAD, duration 91s, previous
duration 556558s
46. Platform State from WNCD: current UP, duration 0s, previous d
uration 0s

38. Connect the Employee PC again when the server is unreachable.

You will notice that the switch has applied the same policies that ISE would apply, but
locally, based on the cached user role

c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details

Interface: GigabitEthernet1/0/1
IIF-ID: 0x1413C541
MAC Address: 0050.56a7.fa8a
IPv6 Address: fe80::e55d:20e1:8f:d008
IPv4 Address: 172.20.100.10
User-Role: Employees
Status: Authorized
Domain: UNKNOWN
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 65FE14AC0000005C392B1226
Acct Session ID: 0x00000052
Handle: 0x43000052
Current Policy: PORT-AUTH-POLICY

Local Policies:
Idle timeout: 65536 sec
 Service Template: EMPLOYEE_CRITICAL_AUTH_ACCESS (priority 150)
Filter-ID: IPV4_EMPLOYEE_CRITICAL_ACL
SGT Value: 4

Method status list:

Method State
dot1x Authc Failed

Note: Similar local policies can be configured for other users or device types.

The access-session cache is cleared either when the switch reloads or the endpoint logoff (EAPOL-Lo
typically occurs in most of the operating systems.

Differentiated Authentication with IBNS 2.0

There are scenarios where AAA transactions must be carried out from the same
network device, with distinct groups of RADIUS servers. This is typical in wireless
networks, where configurations can be done on a per SSID basis. However, on the
switch side, such differentiated authentication was not possible until the introduction of
IBNS 2.0. The following are a couple of use cases for differentiated authentication:

 Separate MAB and 802.1X transactions–Not a common or recommended practice. Can be

performed if there is a need to separate MAB and 802.1X transactions from the same switch
interface.
 Separate RADIUS servers based on switch port–Specific switch ports can be configured for
the IBNS 2.0 policy to talk to separate ISE servers.
 Figure21: Differentiated Authentication with IBNS 2.0

Example below briefs you how to modify the switch configuration to perform
differentiated authentication so that specific sets of interfaces on the switch talk to
specific ISE servers.

Switch Configuration for Differentiated Authentication

Global AAA and RADIUS Server Definition

1. Before authoring a policy-map and applying it on the interface, configure the global AAA and
RADIUS parameters to distinguish the two AAA server groups. Define two or more distinct
RADIUS servers in global configuration mode.

2. radius server ISE01

3. address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
4. automate-tester username test-user ignore-acct-port probe-on
5. key ISEisC00L
6. !
7. radius server ISE02
8. address ipv4 172.20.254.22 auth-port 1812 acct-port 1813
9. automate-tester username test-user ignore-acct-port probe-on
10. key ISEisC00L

!
2. Define two server groups and method lists for AAA in global configuration mode.

3. aaa group server radius ISE-CUBE-1

4. server name ISE01
5. ip radius source-interface Vlan254
6. !
7. aaa group server radius ISE-CUBE-2
8. server name ISE02
9. ip radius source-interface Vlan254
10. !
11. aaa authentication dot1x default group radius
12. aaa authentication dot1x AAA_LIST1 group ISE-CUBE-1
13. aaa authentication dot1x AAA_LIST2 group ISE-CUBE-2
14. !
15. aaa authorization network default group radius
16. aaa authorization network AAA_LIST1 group ISE-CUBE-1
17. aaa authorization network AAA_LIST2 group ISE-CUBE-2
18. !
19. aaa accounting Identity AAA_LIST2 start-stop group ISE-CUBE-2
20. aaa accounting Identity AAA_LIST1 start-stop group ISE-CUBE-1
21. !
22. aaa accounting network AAA_LIST1 start-stop group ISE-CUBE-1
23. aaa accounting network AAA_LIST2 start-stop group ISE-CUBE-2

3. (Optional) Run the below AAA accounting commands to make the switch simultaneously send
accounting records to the first server in each group.

4. aaa accounting Identity default start-stop broadcast group ISE-CUBE-1 grou

p ISE-CUBE-2
5. aaa accounting network default start-stop broadcast group ISE-CUBE-1 group
ISE-CUBE-2
6. aaa accounting system default start-stop broadcast group ISE-CUBE-1 group
ISE-CUBE-2

4. Define all the individual RADIUS servers as CoA servers.

5. aaa server radius dynamic-author

6. client 172.20.254.21 server-key ISEisC00L
7. client 172.20.254.22 server-key ISEisC00L

auth-type any
 IBNS 2.0 Policy and Interface Configuration

5. Configure two IBNS 2.0 policies similar to the PORT-AUTH-POLICY(Section: Configuring and
Understanding the IBNS 2.0 Policy – step10) and make the following changes.

6. policy-map type control subscriber PORT-AUTH-POLICY-CUBE1

7. event session-started match-all
8. 10 class always do-until-failure
9. 10 authenticate using dot1x aaa authc-list ISE-CUBE-1 authz-list ISE-CU
BE-1 priority 10
10. ...
11. event authentication-failure match-first
12. ...
13. 30 class DOT1X_NO_RESP do-until-failure
14. 10 terminate dot1x
15. 20 authenticate using mab aaa authc-list ISE-CUBE-1 authz-list
ISE-CUBE-1 priority 20

...
policy-map type control subscriber PORT-AUTH-POLICY-CUBE2
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x aaa authc-list ISE-CUBE-2 authz-list ISE-CU
BE-2 priority 10
...
event authentication-failure match-first
...
30 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab aaa authc-list ISE-CUBE-2 authz-list ISE-CUBE
-2 priority 20
...

6. Configure the interface templates to reference above two policies maps.

7. template PORT-AUTH-TEMPLATE-CUBE1
8. description ** Endpoints and Users on Cube-1 ISE **
9. spanning-tree portfast
10. dot1x pae authenticator
11. switchport access vlan 100
12. switchport mode access
13. switchport voice vlan 101
14. mab
15. access-session control-direction in
16. access-session closed
17. access-session port-control auto
18. authentication periodic
19. authentication timer reauthenticate server
20. service-policy type control subscriber PORT-AUTH-POLICY-CUBE1
21. !
22. template PORT-AUTH-TEMPLATE-CUBE2
23. description ** Endpoints and Users on Cube-2 ISE **
24. spanning-tree portfast
25. dot1x pae authenticator
26. switchport access vlan 100
27. switchport mode access
28. switchport voice vlan 101
29. mab
30. access-session control-direction in
31. access-session closed
32. access-session port-control auto
33. authentication periodic
34. authentication timer reauthenticate server

service-policy type control subscriber PORT-AUTH-POLICY-CUBE2

7. Source the interface template along with the other interface-specific commands for the desired
ports.

8. c9300-Sw(config)#interface range GigabitEthernet 1/0/1 - 11

9. c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE1
10. c9300-Sw(config-if-range)#exit
11. c9300-Sw(config)#
12. c9300-Sw(config)#interface range GigabitEthernet 1/0/12 - 22
13. c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE2

c9300-Sw(config-if-range)#exit

Differentiated Authentication for Authentication Methods

8. Here is an example of how to configure an IBNS 2.0 policy for differentiated authentication for
802.1X and MAB on the same switchport.

9. policy-map type control subscriber PORT-AUTH-POLICY-DIFF-AUTH

10. event session-started match-all
11. 10 class always do-until-failure
12. 10 authenticate using dot1x aaa authc-list ISE-CUBE-1 authz-lis
t ISE-CUBE-1 priority 10
13. ...
14. event authentication-failure match-first
15. ...
16. 30 class DOT1X_NO_RESP do-until-failure
17. 10 terminate dot1x
18. 20 authenticate using mab aaa authc-list ISE-CUBE-2 authz-list
ISE-CUBE-2 priority 20

...

ISE Authorization Profile for Differentiated dACL

When two or more ISE deployments are managed in an environment and differentiated
authentication is used, certain authorizations from ISE may not work well because they
require communication with specific ISE servers for additional attributes. For example,
when an endpoint is authorized for a downloadable ACL from ISE-Cube-2, the switch
only gets the ACL name in the initial flow. In the second flow, it needs to download the
ACL rules, but because it is not a standard session-start, the switch will query ISE-
Cube-1 for ACEs. If the dACL configurations are not consistent across the ISE
deployments, the authorization fails. The fix is to use an additional Cisco AV pair in the
authorization to inform the switch about which server group to reach out for additional
attributes. The following ISE authorization profile shows the downloadable ACL and the
special AVP.

Note: The Method-List AVP (AAA_LIST1 in the example above) on ISE must match the AAA
method list on the switch and not the AAA server group:
!

aaa authorization network AAA_LIST1 group ISE-CUBE-1

aaa authorization network AAA_LIST2 group ISE-CUBE-2

Identity-Based Network Access in IPv6 Wired Networks

IPv6 is an inevitable future and most of the ISE deployments that are on IPv4 should be
migrated to IPv6 in the future. When it comes to dealing with an ISE-based solution for
a Cisco Catalyst switch in IPv6 networks, the following table compares the possibilities
in contrast to IPv4 networks:

Feature IPV4 Network IPV6 Network

ISE and Switch Addressing Yes Yes

IPV4/IPV6 device tracking on switch Yes Yes

Yes
Network device configuration on ISE Yes
(Starting ISE 2.

Open Mode(No Authorization) Yes Yes

Closed Mode(With VLAN assignments) Yes Yes

Partial(Limited p
Low-Impact Mode(With ACL authorizations) Yes
no dACL*)
 Downloadable ACLs Yes No

URL Redirection Yes No

Security Group Tags Yes Yes

Table7: IBNS 2.0 v4/v6 Feature parity

* Only Filter ID and Per-User ACLs are supported on Catalyst 3650, 3850, and 9300
platforms.

IPv6 Network Readiness

1. Log in to the ISE console (via SSH if it is enabled) and configure the IPv6 address to the
interface.

2. ise01/admin# configure terminal

3. Enter configuration commands, one per line. End with CNTL/Z.
4. ise01/admin(config)# interface GigabitEthernet 0
5. ise01/admin(config-GigabitEthernet)# ipv6 enable
6. ise01/admin(config-GigabitEthernet)# ipv6 address 2001:20:254::21/64
7.
8. Changing the IPV6 address may result in undesired side effects on
9. any installed application(s).
10. Are you sure you want to proceed? Y/N [N]: Y
11. Stopping ISE Monitoring & Troubleshooting Log Collector...
12. Stopping ISE Monitoring & Troubleshooting Log Processor...
13. PassiveID WMI Service is disabled
14.

<Output truncaked>

Note: In a distributed ISE deployment, each Policy Administration Node (PAN) and Policy Services N
be configured with an IPv6 address.
 All the ISE services on a node restart after a new IPv6 address is configured.

2. Log in to the access switch and enable IPv6 unicast routing.

c9300-Sw(config)#ipv6 unicast-routing

3. Verify if there is an IPv6 address for the RADIUS source interface.

4. c9300-Sw#show running-config interface vlan 254
5. Building configuration...
6. Current configuration : 160 bytes
7. !
8. interface Vlan254
9. description ** Switch management interface **
10. ip address 172.20.254.101 255.255.255.0
11. ipv6 address 2001:20:254::101/64
12. ipv6 enable

end

Note: Ensure that end-to-end IPv6 routing is configured so that the access switch can
talk to ISE nodes over IPv6.

4. Ensure that the access switch can ping ISE nodes over IPv6.

5. c9300-Sw#ping ipv6 2001:20:254::21

6. Type escape sequence to abort.
7. Sending 5, 100-byte ICMP Echos to 2001:20:254::21, timeout is 2 seconds:
8. !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

5. In Cisco IOS 16.X, device tracking is common for both IPv4 and IPv6. Ensure that the device-
tracking policy is configured and is applied for the access ports.

6. c9300-Sw#show running-config | begin device-tracking

7. device-tracking policy IPDT_POLICY
8. no protocol udp
9. tracking enable
10. !
11. interface GigabitEthernet1/0/1

device-tracking attach-policy IPDT_POLICY

Note: On C3650 and C3850 switch platforms running Cisco IOS version earlier than 16.1, configure th
commands for IPv6 device tracking:

ipv6 neighbor tracking

ipv6 neighbor binding

vlan configuration 100-101

ipv6 nd suppress

ipv6 snooping

ipv6 snooping policy SNOOP-V6

trusted-port

interface GigabitEthernet1/0/24

description ** Uplink Port to Distribution Switch **

ipv6 snooping attach-policy SNOOP-v6

ip dhcp snooping trust

 !

Cisco IOS Identity Configurations for IPv6

This section provides information about how the global configuration described in
the Switch Global Configuration Dump for AAA, RADIUS and More in IBNS 2.0 section
is modified for IPv6.

1. Change the RADIUS server configurations from IPv4 to IPv6.

2. c9300-Sw(config)#radius server ISE01

3. c9300-Sw(config-radius-server)#address ipv6 2001:20:254::21 auth-port 1812
acct-port 1813
4. c9300-Sw(config-radius-server)#no address ipv4 172.20.254.21 auth-port 181
2 acct-port 1813
5. c9300-Sw(config-radius-server)#automate-tester username test-user ignore-a
cct-port probe-on
6. c9300-Sw(config-radius-server)#key ISEisC00L
7. c9300-Sw(config-radius-server)#exit
8. c9300-Sw(config)#
9. c9300-Sw(config)#radius server ISE02
10. c9300-Sw(config-radius-server)#address ipv6 2001:20:254::22 auth-p
ort 1812 acct-port 1813
11. c9300-Sw(config-radius-server)#no address ipv4 172.20.254.22 auth-
port 1812 acct-port 1813
12. c9300-Sw(config-radius-server)#automate-tester username test-user
ignore-acct-port probe-on
13. c9300-Sw(config-radius-server)#key ISEisC00L
14. c9300-Sw(config-radius-server)#exit

2. Perform similar configuration changes for RADIUS CoA servers.

3. c9300-Sw(config)#aaa server radius dynamic-author

4. c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::21 server-key ISEisC
00L
5. c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::22 server-key ISEisC
00L
6. c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.21 server-key ISEis
C00L
7. c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.22 server-key ISEis
C00L
8. c9300-Sw(config-locsvr-da-radius)#end

3. Ensure that the servers are reachable and are marked as Up.

4. c9300-Sw#show aaa servers | include RADIUS|State

5. RADIUS: id 1, priority 1, host 2001:20:254::21, auth-port 1812, acct-port
1813
6. State: current UP, duration 19s, previous duration 199s
7. Platform State from SMD: current UP, duration 19s, previous duration
2885s
8. Platform State from WNCD: current UP, duration 0s, previous duration
0s
9. RADIUS: id 2, priority 2, host 2001:20:254::22, auth-port 1812, acct-port
1813
10. State: current UP, duration 17s, previous duration 0s
11. Platform State from SMD: current UP, duration 17s, previous d
uration 0s
12. Platform State from WNCD: current UP, duration 0s, previous d
uration 0s

Low-Impact Mode with IPv6 Per-User ACL

1. Configure a pre-authentication IPv6 ACL.

2. c9300-Sw(config)#ipv6 access-list IPV6_PRE_AUTH_ACL

3. c9300-Sw(config-ipv6-acl)#permit udp any any eq bootpc
4. c9300-Sw(config-ipv6-acl)#permit udp any any eq domain

c9300-Sw(config-ipv6-acl)#deny ipv6 any any

IPv6 Pre-authentication ACL is very similar to the IPv4 Pre-Authentication ACL

configuration

c9300-Sw#show ip access-lists IPV4_PRE_AUTH_ACL

Extended IP access list IPV4_PRE_AUTH_ACL
10 permit udp any eq bootpc any eq bootps
20 permit udp any any eq domain
30 deny ip any any

c9300-Sw#show ipv6 access-list IPV6_PRE_AUTH_ACL

IPv6 access list IPV6_PRE_AUTH_ACL
permit udp any eq bootpc any eq bootps sequence 10
permit udp any any eq domain sequence 20
 deny ipv6 any any sequence 30

2. Configure a critical ACL.

3. c9300-Sw(config)#ipv6 access-list IPV6_CRITICAL_ACL
4. c9300-Sw(config-ipv6-acl)#permit ipv6 any any

IPv6 Critical ACL is very similar to IPv4 Critical ACL configured earlier

c9300-Sw#show ip access-lists IPV4_CRITICAL_ACL

Extended IP access list IPV4_CRITICAL_ACL
10 permit ip any any

3. Add the IPv6 critical ACL in the CRITICAL_AUTH_ACCESS service template

4. c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS
5. c9300-Sw(config-service-template)#access-group IPV6_CRITICAL_ACL
6. c9300-Sw(config-service-template)#end
7. c9300-Sw#show running-config | begin service-template
8. ...
9. service-template CRITICAL_AUTH_ACCESS
10. description ** Access Policy For IAB **
11. access-group IPV4_CRITICAL_ACL
12. access-group IPV6_CRITICAL_ACL

4. Apply the pre-authentication ACL on the interface.

5. c9300-Sw(config)#interface gigabitEthernet 1/0/1
6. c9300-Sw(config-if)#ipv6 traffic-filter IPV6_PRE_AUTH_ACL in
7. c9300-Sw(config-if)#end
8.
9. c9300-Sw#show running-config interface GigabitEthernet 1/0/1
10. Building configuration...
11. Current configuration : 272 bytes
12. !
13. interface GigabitEthernet1/0/1
14. device-tracking attach-policy IPDT_POLICY
15. ip access-group IPV4_PRE_AUTH_ACL in
16. ipv6 traffic-filter IPV6_PRE_AUTH_ACL in
17. source template PORT-AUTH-TEMPLATE
18. spanning-tree portfast

end

5. Log in to ISE, and modify the Network Devices configuration for the Catalyst switch to whitelist
on IPv6 address. Navigate to Administration > Network Resources > Network Devices. Click
the specific switch name, and then configure the IPv6 address and save the configuration.

6. Navigate to Policy > Policy Elements > Results > Authorization > Authorization
Profiles and configure an authorization profile for a Per-User ACL.

Note: Current Cisco IOS & ISE software implementation doesn’t support native IPv6
dACL’s over RADIUS. Its currently implementation of IPv6 on RADIUS uses Cisco
Vendor Specific Attributes(VSA).

The two rules configured in this sample procedure are:

 ipv6:inacl#1=deny ipv6 any 2001:20:199::/64
 ipv6:inacl#2=permit ipv6 any any
Note: Apart from Per-User ACL, the other two ACL authorization options for IPv6 currently are Filter I
Template.

Filter ID Service Template Per-User ACL

(Per Session) (Per Interface) (Per Session)

ACL local to Switch ACL local to Switch ACL download f

IPv4 Yes Yes Yes

 Cisco AVP: Cisco AVP:
RADIUS Attribute/AVP Filter-ID=ACL_Name.in “subscriber:service-name= “ip:inacl#1=perm
TEMPLATE_NAME” any”

IPv6 Yes Yes Yes

Cisco AVP: Cisco AVP:

Filter-ID =
RADIUS Attribute/AVP “subscriber:service-name= “ipv6:inacl#1=pe
ACL_NAME.in.ipv6
TEMPLATE_NAME” any any”

7. Reference this Authorization profile as one of the authorization results for the Employee user
group

8. Re-authenticate the Employee workstation and verify IPv6 ACL download and authorization for
the network access session.

9. c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details

10. Interface: GigabitEthernet1/0/1
11. IIF-ID: 0x1DD98B5E
12. MAC Address: 0050.56a7.fa8a
13. IPv6 Address: 2001:20:100:0:4d0d:2a03:cd86:7241
14. 2001:20:100:0:e55d:20e1:8f:d008
15. fe80::e55d:20e1:8f:d008
16. IPv4 Address: 172.20.100.13
17. User-Name: harry
18. User-Role: Employees
19. Status: Authorized
20. Domain: DATA
21. Oper host mode: multi-auth
22. Oper control dir: in
23. Session timeout: N/A
24. Common Session ID: 000000000000001142C99F70
25. Acct Session ID: 0x00000007
26. Handle: 0x03000007
27. Current Policy: PORT-AUTH-POLICY
28.
29. Server Policies:
30. Security Policy: None
31. Security Status: Link Unsecured
32. SGT Value: 4
33. ACS ACL: xACSACLx-IP-EmployeeAccessACL-5af1634e
34. Per-User ACL: Gi1/0/1#v6#1dd98b5e
35. : deny ipv6 any 2001:20:199::/64
36. : permit ipv6 any any
37.
38. Method status list:
39. Method State
40. dot1x Authc Success

Deploying 802.1X for High Security (Closed Mode)

Closed Mode is a more traditional deployment model of 802.1X. In a properly prepared
network, Closed Mode provides total control over switch-level (Layer 2) network access.
This type of deployment is recommended only for environments that are experienced
with 802.1X deployments and have considered all the nuances that go along with it.
Think of this mode as a “deploy with caution” mode.

In Closed Mode, the switchport does not allow traffic except EAP over LAN(EAPoL) until
a successful authentication takes place. No pre-authentication access to DHCP, DNS,
HTTP and PXE boot servers are allowed while authentication is in progress. Closed
Mode is ideal for Vlan-based enforcement since the client does not get an IP address
until successfully authenticated.
Deploying Closed Mode with Vlan Assignment can have a significant impact on network
architecture. Understanding these potential impacts is essentials for successful
deployment of this mode.

Vlan Considerations: Dynamic VLAN assignment requires that every dynamic VLAN
be supported on every access switch to which a user might connect and authenticate.
Hence a good campus design dictate a fewer VLANs which helps in more manageable
and scalable solution.

Granting Limited Access if primary authentication fails: If some level of access is

needed for devices that fail 802.1X authentication, it is possible to configure switch port
to open the port into a special VLAN (the Auth-fail VLAN) or be fall back to MAB and
download a dACL to permit some basic access.

Before transitioning to Closed Mode, you should ensure that all endpoints can
authenticate. All identity store database should be up to date and online.

Building on top of the configurations done in Monitor Mode, a few changes can be made
in the network for restricted network access. The idea is that after you have understood
how endpoints behave in the monitor mode and how to fix failures, you are ready to
move on to understanding controlled network access.

Figure22: Closed Authentication Workflow

 Switch Configuration for Closed Mode

1. Log in to the switch.

2. Write Erase and restore the Monitor-Mode configuration from the backed-up information, using
“configure replace flash:filename”
3. On a per-port basis, disable the open mode configuration, which was explained in the Configure
the Switch for Monitor Mode.

4. c9300-Sw(config)#template PORT-AUTH-TEMPLATE
5. c9300-Sw(config-if)#access-session closed

Critical Authentication

In closed mode, the endpoints do not have network access unless they authenticate
successfully or are given fail open access because of ISE authorization policy. What if
the ISE server itself is unreachable? The best practice recommendation is therefore, to
configure the fail open access locally on the switch.

Use the Inaccessible Authentication Bypass (IAB) feature, also referred to as critical
authentication or the AAA fail policy, when the switch cannot reach the configured
RADIUS servers and new hosts cannot be authenticated. When a new host tries to
connect to the critical port, that host is moved to a user-specified access VLAN, the
critical VLAN. The critical VLAN can be the same as the default VLAN on the port. The
administrator gives limited authentication to the hosts.

Enable the critical voice VLAN feature to allow access to IP phones when the ISE
server is unreachable for its authentication. When traffic coming from the host is tagged
with the voice VLAN, the connected device (the phone) is put in the configured voice
VLAN for the port. The IP phones learn the voice VLAN identification through CDP
(Cisco devices) or through LLDP or DHCP.

4. Create a service template referencing the Critical Vlan & Voice Vlan

5. c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS
6. c9300-Sw(config-service-template)#vlan 100
7.
8. c9300-Sw(config)#service-template DEFAULT_CRITICAL_VOICE_TEMPLATE

c9300-Sw(config-service-template)#voice vlan
 Note: To support inaccessible bypass on multiple-authentication (multi-auth) ports, use the authentica
dead action reinitialize vlan VLAN ID. When a new host tries to connect to the critical port, that port is
all the connected hosts are moved to the user-specified access VLAN. The authentication event serve
reinitialize vlan <vlan-id> interface configuration command is supported on all host modes

To reinitialize a session when a previously unreachable ISE server becomes available,

use the below configuration

5. Create two new class maps or edit the existing class map to match the new service template
created in Step 3:

6. c9300-Sw(config)#class-map type control subscriber match-any IN_CRITICAL_A

UTH
7. c9300-Sw(config-filter-control-classmap)#match activated-service-template
CRITICAL_AUTH_ACCESS
8. c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFA
ULT_CRITICAL_VOICE_TEMPLATE
9. c9300-Sw(config-filter-control-classmap)#exit
10. c9300-Sw(config)#
11. c9300-Sw(config)#class-map type control subscriber match-none NOT_
IN_CRITICAL_AUTH
12. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emplate CRITICAL_AUTH_ACCESS
13. c9300-Sw(config-filter-control-classmap)#match activated-service-t
emp DEFAULT_CRITICAL_VOICE_TEMPLATE

c9300-Sw(config-filter-control-classmap)#exit

6. Ensure that the following class maps exist in the system before configuring a new policy map for
Closed mode:

7. class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST

8. match result-type aaa-timeout
9. match authorization-status authorized
10. !
11. class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_H
OST
12. match result-type aaa-timeout
13. match authorization-status unauthorized
14. !
15. class-map type control subscriber match-all DOT1X
16. match method dot1x
17. !
18. class-map type control subscriber match-all DOT1X_FAILED
19. match method dot1x
20. match result-type method dot1x authoritative
21. !
22. class-map type control subscriber match-all DOT1X_MEDIUM_PRIO
23. match authorizing-method-priority gt 20
24. !
25. class-map type control subscriber match-all DOT1X_NO_RESP
26. match method dot1x
27. match result-type method dot1x agent-not-found
28. !
29. class-map type control subscriber match-all DOT1X_TIMEOUT
30. match method dot1x
31. match result-type method dot1x method-timeout
32. !
33. class-map type control subscriber match-any IN_CRITICAL_AUTH
34. match activated-service-template CRITICAL_AUTH_ACCESS
35. match activated-service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
36. !
37. class-map type control subscriber match-all MAB
38. match method mab
39. !
40. class-map type control subscriber match-all MAB_FAILED
41. match method mab
42. match result-type method mab authoritative
43. !
44. class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
45. match activated-service-template CRITICAL_AUTH_ACCESS
46. match activated-service-template DEFAULT_CRITICAL_VOICE_TEMPLATE

7. Configure a new policy map in global configuration mode. The highlighted parts in the example
below indicates the additional classes added to the system-generated policy as in Monitor-
mode:

8. policy-map type control subscriber PORT-AUTH-POLICY-I

9. event session-started match-all
10. 10 class always do-until-failure
11. 10 authenticate using dot1x priority 10
12. event authentication-failure match-first
13. 5 class DOT1X_FAILED do-until-failure
14. 10 terminate dot1x
15. 20 authenticate using mab priority 20
16. 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
17. 10 clear-authenticated-data-hosts-on-port
18. 20 activate service-template CRITICAL_AUTH_ACCESS
19. 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
20. 40 authorize
21. 50 pause reauthentication
22. 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
23. 10 pause reauthentication
24. 20 authorize
25. 30 class DOT1X_NO_RESP do-until-failure
26. 10 terminate dot1x
27. 20 authenticate using mab priority 20
28. 40 class MAB_FAILED do-until-failure
29. 10 terminate mab
30. 20 authentication-restart 60
31. 60 class always do-until-failure
32. 10 terminate dot1x
33. 20 terminate mab
34. 30 authentication-restart 60
35. event agent-found match-all
36. 10 class always do-until-failure
37. 10 terminate mab
38. 20 authenticate using dot1x priority 10
39. event aaa-available match-all
40. 10 class IN_CRITICAL_AUTH do-until-failure
41. 10 clear-session
42. 20 class NOT_IN_CRITICAL_AUTH do-until-failure
43. 10 resume reauthentication
44. event inactivity-timeout match-all
45. 10 class always do-until-failure
46. 10 clear-session
47. event authentication-success match-all
48. 10 class always do-until-failure

10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE

Wake-On-LAN

The IEEE 802.1x standard is implemented to block traffic between the unauthenticated
clients and network resources. This means that unauthenticated clients cannot
communicate with any device on the network except the authenticator. The reverse is
true, except for one circumstance, when the port is configured as a unidirectional
controlled port.
 Unidirectional State

The IEEE 802.1x standard states that a unidirectional controlled port enables a device
on the network to wake up a client so that the client continues to be reauthenticated.
When you use the authentication control-direction in command to configure the port
as unidirectional, the port changes to the spanning-tree forwarding state, thus allowing a
device on the network to wake the client and force it to reauthenticate.

Bidirectional State

When you use the authentication control-direction both command to configure a port
as bidirectional, access to the port is controlled in both directions. In this state, the port
does not receive or send packets.

(Optional) Allows broadcast traffic from the network to the unauthenticated port. This
assists with the Wake-on-LAN (WoL)) process so that the network management server
can wake up clients on demand. It also assists in the MAB process for certain types of
devices that do not generate much traffic on their own without network request from
another host.

c9300-Sw(config)#template PORT-AUTH-TEMPLATE
c9300-Sw(config-if)#access-session control-direction in

MAC Limits

Limiting the number of MAC addresses on an 802.1X-enabled port is not a

straightforward process. However, there are a couple of options to achieve MAC limits
to a certain extent:

 Host modes–Four host modes can be configured on a port.

Host Mode Number of Endpoints Interface Command

 Single Host
1 Voice/Data device access-session host-mod
(default in IBNS 1.0)

Multi-Domain Authentication
1 Voice and 1 Data device access-session host-mod
(MDA)

1 Voice and Unlimited Data

Multi-Host Mode access-session host-mod
(At least one MAC address must
authenticate successfully)

1 Voice and Unlimited Data

Multi-Auth Mode access-session host-mod
(Each MAC address must
authenticate)

Table8: Multiple Endpoints per Port

When you opt for restrictive host modes such as single-host mode or multi-domain
authentication host mode, and an authentication violation occurs, for example, more
MAC addresses appearing on the same port, the port will be error disabled. This might
require the immediate attention of the administrator to remediate the shutdown port
state. We, therefore, recommended that you have a restrictive, yet non-disruptive option
to handle authentication violations using below IBNS 2.0 CLI.

8. Edit the current policy-map to include the authentication violations. The highlighted parts in the
example below indicate the additional configs.

9. policy-map type control subscriber PORT-AUTH-POLICY-I

10. event session-started match-all
11. 10 class always do-until-failure
12. 10 authenticate using dot1x priority 10
13. event authentication-failure match-first
14. 5 class DOT1X_FAILED do-until-failure
15. 10 terminate dot1x
16. 20 authenticate using mab priority 20
17. 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
18. 10 clear-authenticated-data-hosts-on-port
19. 20 activate service-template CRITICAL_AUTH_ACCESS
20. 30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
21. 40 authorize
22. 50 pause reauthentication
23. 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
24. 10 pause reauthentication
25. 20 authorize
26. 30 class DOT1X_NO_RESP do-until-failure
27. 10 terminate dot1x
28. 20 authenticate using mab priority 20
29. 40 class MAB_FAILED do-until-failure
30. 10 terminate mab
31. 20 authentication-restart 60
32. 60 class always do-until-failure
33. 10 terminate dot1x
34. 20 terminate mab
35. 30 authentication-restart 60
36. event agent-found match-all
37. 10 class always do-until-failure
38. 10 terminate mab
39. 20 authenticate using dot1x priority 10
40. event aaa-available match-all
41. 10 class IN_CRITICAL_AUTH do-until-failure
42. 10 clear-session
43. 20 class NOT_IN_CRITICAL_AUTH do-until-failure
44. 10 resume reauthentication
45. event inactivity-timeout match-all
46. 10 class always do-until-failure
47. 10 clear-session
48. event authentication-success match-all
49. 10 class always do-until-failure
50. 10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SE
CURE
51. event violation match-all
52. 10 class always do-until-failure

10 restrict

 Device-tracking policy-The other option to limit the number of endpoints getting identity-based
services in the device-tracking policy. This policy can be configured to limit the number of
endpoints (IP addresses) being tracked for IP-based services such as dACL/URL-
 redirect/SGTs, and so on. This does not limit the number of endpoints from connecting or
authenticating on the port. Use “Limit address-count maximum“CLI under the device-tracking
policy to limit the number of endpoints allowed to use identity-based services.

 c9300-Sw(config)#device-tracking policy IPDT_POLICY

 c9300-Sw(config-device-tracking)#no protocol udp
 c9300-Sw(config-device-tracking)#tracking enable
 c9300-Sw(config-device-tracking)#limit address-count 10
 c9300-Sw(config-device-tracking)#exit
 !
 c9300-Sw(config)#interface gigabitEthernet 1/0/1

c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY

Note: Even though the port-security interface command enforces MAC address limit, it is not compa
authentication/dot1x configurations on the switch port. In general, we recommend that you do not e
security when IEEE 802.1x is enabled.

9. Apply the new policy-map to the interface

10. c9300-Sw(config)#template PORT-AUTH-TEMPLATE

11. c9300-Sw(config-template)#no service-policy type control subscribe
r PORT-AUTH-POLICY
12. c9300-Sw(config-template)#service-policy type control subscriber P
ORT-AUTH-POLICY-I

Interface Configuration for Closed Mode

c9300-Sw#show derived-config interface GigabitEthernet 1/0/1

Building configuration...

Derived configuration : 525 bytes

!
interface GigabitEthernet1/0/1
description ** Endpoints and Users **
switchport access vlan 100
switchport mode access
switchport voice vlan 101
device-tracking attach-policy IPDT_POLICY
authentication periodic
authentication timer reauthenticate server
access-session control-direction in
 access-session closed
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
spanning-tree portfast
service-policy type control subscriber PORT-AUTH-POLICY-I
end

Authoring Access Policies on ISE

It is always important to have policy goals in mind before configuring ISE access
policies. Figure21 highlights 802.1X authentication workflow, resulting in either basic
access or access to an employee segment depending on a user’s Active Directory
group membership. IP phones are authorized for voice VLAN and the unknown
endpoints are subject to the guest portal. When the ISE servers are unreachable, the
switch authorizes newly connecting endpoints to the critical VLAN, which can be the
same as the default VLAN. The following is a flow chart of the 802.1x authentication
policy, most part of the decision tree and critical authorization is already configured on
the switch, the right-hand side part in terms of 802.1X and MAB authorization policies
must be configured on ISE:
 Figure23: 802.1x Authentication flowchart

1. Login to ISE and navigate to Policy > Policy Elements: Results

2. In the left pane, click Authorization > Authorization Profiles.

3. In the Standard Authorization Profiles area, click Add.

4. Create a new Authorization Profile for Employee VLAN result by providing the corresponding
information:
Note: The VLAN name or number that you specify in the Authorization Profile must match the VLAN n
configured on the access switch exactly. In this example, a VLAN exists on the switch name Employe

c9300-Sw#show vlan brief | inc Employee

 150 Employees active

5. Navigate to Policy > Policy Sets

6. You can either create a new policy set or edit the default policy set that comes with the ISE
installation. In this example, the default policy set is taken into consideration. Click the > icon to
expand the default policy set.
7. Expand the default Authorization Policy.

8. Scroll down and create a new rule above the Basic_Authenticated_Access

9. Provide a descriptive name for the policy rule and click the +

10. If you are configuring the policy in ISE for the first time after its installation, a screen tip is
displayed, explaining how to use the Conditions Studio. Click the x
11. In the Editor area, click the field that reads ‘Click to add an attribute’

12. After the Editor options load, click the user group icon and select the ExternalGroups Active
Directory.
13. Configure a condition to match on Active Directory group. In this example,
the Employees Active Directory Group is configured.

14. Click Use.

Note: If you click Save (Conditions Studio > Editor) after you configure a condition, you can save th
an arbitrary name and reuse the condition with that name later for other authorization policies.
15. To select a Result for the policy created, choose the corresponding “profile” option(in this case
EmployeeVLAN created in step 2)

16. Optionally, you can also add an SGT as an additional authorization result.
17. To adhere to our policy goals as per flowchart on Figure21 , edit the “Default” authorization
policy to fallback to Web Authentication as Tertiary option or as a last resort .
18. Click Save.
Note that for IP phones, a policy rule exists by default. This rule authorizes profiled IP
phones with voice VLAN authorization. Pre-requisites being the IP Phone MAC address
are manually added to the endpoint identity group.

Note: Both Cisco_IP_Phones and Non_Cisco_IP_Phones authorization profiles contain

a PERMIT_ALL_TRAFFIC (permit ip any any) downloadable ACL and cisco-av-pair=device-traffic-
class=voice authorization. The latter Attribute Value Pair (AVP) is necessary to tag the IP phone into
the switch.
Closed Mode in Action

1. Log in to a Catalyst switch and test AAA authentication using “Test aaa group radius”
CLI .

2. Ensure that the corresponding Active Directory user (a member of

the Employee group) is returned with VLAN authorization.

c9300-Sw#test aaa group radius harry ISEisC00L new-code

User successfully authenticated

USER ATTRIBUTES

username 0 "harry"
tunnel-type 1 13 [vlan]
tunnel-medium-type 1 6 [ALL_802]
tunnel-private-group 1 "Employees"
security-group-tag 0 "0004-0"

3. If you bounce the access port in which the corresponding IP phone and employee are
connected, the new authorization results should be displayed as below.

c9300-Sw#show access-sesison sessions interface Gi 1/0/1 details

Interface: GigabitEthernet1/0/1
IIF-ID: 0x19E63EED
MAC Address: 0050.56a7.fa8a
IPv6 Address: Unknown
IPv4 Address: 172.20.150.2
User-Name: harry
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 65FE14AC0000002D27DEB90F
Acct Session ID: 0x00000023
Handle: 0xd0000023
Current Policy: PORT-AUTH-POLICY-I

Local Policies:
Idle timeout: 65536 sec

Server Policies:
Vlan Group: Vlan: 150
 Security Policy: None
Security Status: Link Unsecured
SGT Value: 4

Method status list:

Method State
dot1x Authc Success

----------------------------------------
Interface: GigabitEthernet1/0/1
IIF-ID: 0x1AABEBEF
MAC Address: 0064.40b5.794e
IPv6 Address: Unknown
IPv4 Address: 172.20.101.3
User-Name: 00-64-40-B5-79-4E
Status: Authorized
Domain: VOICE
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 65FE14AC0000002E27DEBD9D
Acct Session ID: 0x00000024
Handle: 0xf7000024
Current Policy: PORT-AUTH-POLICY-I

Local Policies:
Idle timeout: 65536 sec

Server Policies:
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-57f6b0d3

Method status list:

Method State
dot1x Stopped
mab Authc Success

4. Log in to ISE and navigate to Operations > RADIUS: Live Logs.

You will notice two endpoints being authenticated and authorized.

5. Click the Details icon to view details about the entry.

The Overview dialog box shown below highlights the authorization policy rule matched
and what the end result .

6. If you scroll down to the end of the page, you will see the Result details with License
consumed.
802.1X for Cisco IP Phones
With Multi-Domain Authentication enabled, both the phone and device behind the phone
can authenticate using dot1x. Phones use similar protocols and authenticate using the
same type of credentials as other users and devices that perform 802.1X. However,
there are some specific requirements for preparing the voice network for authentication
of IP phones. These phones must present a password or X.509 digital certificate to
authenticate successfully. IP phones use EAP-MD5 for password authentication. This is
considered weak when compared to other password- based EAP methods such as
Protected EAP (PEAP) or EAP Flexible Authentication via Secure Tunneling (EAP-
FAST). Most Cisco IP phones support authentication via X.509 certificates using the
EAP-Transport Layer Security (EAP-TLS) or EAP-FAST methods.

Manufacturing Installed Certificates (MIC) versus Locally Significant Certificates (LSC)

Cisco IP phones support two types of X.509 certificates: the Manufacturing Installed
Certificates (MICs) and the Locally Significant Certificates (LSCs).
 As the name indicates, MICs are the certificates that are preinstalled on IP phones and
cannot be deleted or modified by administrators. The certification pre-installed on the
phones are signed by one of the Cisco Manufacturing Certificate Authorities. When an
IP phone authenticates using MIC, it proves that it is a valid Cisco IP phone; however, it
does not validate if the phone is a company-owned asset. Anyone can connect a
personal device that has a Cisco Manufacturing CA-signed certificate on it and gain
network access.

LSCs on the other hand are administrator installed certificates that are signed by the
Cisco Unified Call Manager. These certificates serve the same purpose as MICs in
terms of authentication, but provide greater security because of their local significance
to a given environment.

Basic Call Manager and Network Settings

The following section covers Cisco IP phone authentication using digital certificates

Call Manager Basic Settings

1. Log in to the Cisco Unified Communications Manager (CUCM).

2. Navigate to System > Cisco Unified CM.

Click Find,the CUCM server loads.

3. Click the corresponding CUCM server listing.

4. Ensure that device and line templates are present, phone numbers are configured, and auto
registration is enabled.
 IP Phone CUCM Discovery Configuration

5. Cisco IP phones download the configurations from CUCM over TFTP. They discover the TFTP
server (CUCM) address via DHCP Option 150. Configure your DHCP server to send Option 150
with the CUCM server IP address. The following is an example of the configuration done in a
Windows DHCP server.

For information about the procedure, see the Configuring Windows 2000 DHCP Server
for Cisco CallManager document.

6. By default, the CUCM does not serve the TFTP requests; the services have to be enabled
explicitly. On the top right-hand corner of the CUCM admin window, from the Navigation drop-
down list, choose Cisco Unified Serviceability and click Go.
7. Log in with the CUCM admin credentials and Navigate to Tools > Service Activation.

8. Check the Cisco CallManager and Cisco Tftp check boxes and click Save.
9. Ensure that the phone has open access to the network services or is authorized by ISE for
access to DHCP, DNS, and TFTP services. In the previous example described in Configuring
and Understanding IBNS 2.0 Policy section, the IP phones were MAB-authenticated and a
dACL was applied for the session. Bounce the switch port where the IP phone is connected.

10. Switch to the CUCM admin window by choosing Cisco Unified CM Administration from the
Navigation drop-down list at the top-right corner of the Serviceability window, and click Go.
11. Navigate to Device > Phone and search for the phone on the Find and List Phones Page.

12. Click Find button with default settings. When the phone communicates to the CUCM, it shows
up on Find and List Phones page.

Note: The phone’s status must show Registered with CUCM for the administrator to manage the pho
Manager. If the status is something else, try Hard Reset the phone to Registered back to CUCM.
IP Phone Authentication with MIC

After the IP phone is registered with the Call Manager, necessary changes can be
performed in the system to enable 802.1X authentication. For MIC based 802.1X
authentication, the relevant manufacturer CA certificates must be trusted in ISE and the
IP phones must be configured via CUCM to perform 802.1X authentication using MICs.

This section provides information about how to configure the voice network for MIC
authentication and the changes that are required in ISE to support it.

Certificate Import/Export between CUCM and ISE

1. Log in to the Cisco Unified OS Administration window using with admin

credentials.

2. Navigate to Security > Certificate Management.

3. Click each of the CA certificates listed as CallManager-trust and export them to

your local disk in PEM format. Note that the last three certificates need not be exported
because they are installed by default in Cisco ISE’s trusted CA store. However, make
sure that those certificates exist on ISE.
4. Log in to ISE and Navigate to Administration > System > Certificates.

5. In the left pane, click Trusted Certificates. You will see a list of Root CA public
certificates that are installed on ISE. Notice the three Cisco Manufacturer certificates
you could see in CUCM as in Step 3.
6. Select the disabled ones and click Edit to change the Status to Enabled and Click
Save

7. Enable the other Disabled CA certificates .

8. To import the other root CA certificates that are exported from CUCM, click Import in
the Trusted Certificates area.
9. Upload the CA certificate, give it a name and description, and save it with default
settings.

10. If the certificate has weaker key strength or an outdated algorithm, a warning
message is shown. If it is permissible in the given environment to use such certificates,
click Yes and proceed.
11. Repeat the certificate import procedure for all the exported certificates.

ISE Authorization Policy for MIC Authentication

12. Navigate to the corresponding ISE authorization policy and create a new
authorization rule for IP phones with certificates.

13. Click the + button for conditions and in the condition Editor window, click the field
that states Click to add an attribute and Click the user icon and Select CERTIFICATE
Subject – Common Name.

14. Define a condition to match such that CERTIFICATE Subject – Common

Name contains SEP.
15. Click the New button to add another condition to match CERTIFICATE Issuer –
Organization

16. Define the second condition to match such that CERTIFICATE Issuer –
Organization contains Cisco

17. Click Use When the conditions matches the snapshot provide below.
18. Add the voice permission that has Voice Domain Permission(Select the Results
Profiles with dACL_Voice in this procedure) and save the configurations.

Enabling 802.1X on IP Phones

19. Log in to CUCM and navigate to Device > Phone

20. Use the Find field to locate a specific registered phone and click a name from the
list that is displayed under Device Name (Line)

21. Use the Find field to locate a specific registered phone and click a name from the
list that is displayed under Device Name (Line)

22. Scroll down the Product Specific Configuration Layout until you see 802.1x
Authentication. Enable it,

click Save, and then click Apply Config at the top of the window

23. The IP phone in the network should now authenticate 802.1x. If you log in to the
switch, you can see the session information.

c9300-Sw#show access-session
Interface MAC Address Method Domain Status Fg Session
ID
--------------------------------------------------------------------------
------------------
Gi1/0/1 0064.40b5.794e dot1x VOICE Auth 000000
000000005A4656E5C5
Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 000000
00000000594656E2C5

<Output trunckated>

24. The session details display additional information about the phone’s network access
session:
c9300-Sw#show access-session mac 0064.40b5.794e details
Interface: GigabitEthernet1/0/1
IIF-ID: 0x15656B9D
MAC Address: 0064.40b5.794e
IPv6 Address: Unknown
IPv4 Address: 172.20.101.3
User-Name: CP-9971-SEP006440b5794e
Status: Authorized
Domain: VOICE
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 000000000000005A4656E5C5
Acct Session ID: 0x00000050
Handle: 0x41000050
Current Policy: PORT-AUTH-POLICY-I

Server Policies:
ACS ACL: xACSACLx-IP-VoiceACL-5af16326
Security Policy: None
Security Status: Link Unsecured

Method status list:

Method State
dot1x Authc Success
mab Stopped

25. To view the new session status on ISE, Navigate to Operations > RADIUS > Live
Logs

26. Click on the Details Icon to see that the IP phone is 802.1X authenticated and is
authorized with a dACL
27. Scroll further down the page to view the certificate details.
Note: To enable 802.1X across all the IP phones, specific models or locations, use the Bulk Adminis
CUCM.
IP Phone Authentication with LSC

You do not require MIC to be configured in the voice network, IP Phones can be
authenticated with LSC. However, since MIC is quick and is an easy option to enable
authenticated network access to phones, most enterprises tend to start with MIC and
move to LSC. This section explains how to build on the previous configurations to install
LSC on IP phones and authenticate them.

Certificate Authority Proxy Function (CAPF) Service Enablement

28. Log in to the Cisco Unified Serviceability tool with admin credentials.

29. Navigate to Tools > Service Activation.

30. Activate the Cisco Certificate Authority Proxy Function service.

31. After the CAPF service is enabled, restart the TFTP service so that the IP phones
can download the LSCs. To restart, navigate to Tools > Control Center Feature
Services.
32. Click the Cisco Tftp service radio button.

33. Click Restart to reinitialize the TFTP service.

CAPF Certificate Import to ISE

34. Log in to the Cisco Unified OS Administration tool with admin credentials
35. After log in, navigate to Security > Certificate Management.

36. Export the CAPF Root CA certificate to your local system. (The certificate title has
only CAPF in it.)

37. Log in to ISE and Navigate to Administration > System > Certificates > Trusted
Certificates.

38. In the left pane, navigate to Certificate Management > Trusted Certificates, and
click Import.
39. Import the CAPF Root CA certificate with default settings.

40. After the certificate is installed, select it by checking the corresponding check box,
and click View.
41. The certificate is locally signed by the CUCM and the organization name with your
specific company name. Make a note of the organization name and close the certificate
view window.
42. Modify the ISE authorization policy to authenticate IP phones on an LSC instead of
an MIC.

Installing an LSC on IP Phones

43. Log in to the CUCM Administration window with admin credentials

44. Navigate to Device > Phone.

45. Use the Find field to locate a specific phone or click the corresponding phone name
under Device Name (Line)

46. In the CAPF Information section, from the Certificate Operation drop-down list,
choose Install/Upgrade.

From the Authentication Mode drop-down list, choose one of the following options
depending on the settings in your environment. In this procedure, the By Null
String option is used.

Option Description
 By Authentication String Installs LSC with a passcode that needs to be keyed in
phone.

By Null String Installs LSC without authentication.

By Existing Certificate Useful when a new LSC needs to be installed on an IP

(precedence to LSC) already has preinstalled LSCs.

By Existing Certificate Authenticates the IP phone with MIC to install an LSC.

(precedence to MIC)

47. Click Save and then Apply Config for the changes to take effect.

48. Navigate to Device > Phone, locate the IP phones, and then click the + button.

49. Define a new condition to list phone on LSC issued By option from the newly
created search filter and then click Find. If the LSC installation is in progress, you will
see that the LSC Status is Operation Pending.
50. Upon upgrade completion, LSC Status changes from Operation Pending to Upgrade
Success .

Note: To deploy LSC at scale, use the Bulk Administration option in CUCM.

NEAT with Interface Templates

Overview

Most of the enterprise customers are using 802.1x based admission control for securing
the network. Majority of these deployments were focused on implementing user-based
admission control to authenticate the users before they gain network access where a
PC or IP-phone acts as a supplicant and the switch acts an authenticator. However,
there is also a need to implement device-based admission control for tighter security
because there are deployment scenarios where a switch acting as 802.1X authenticator
is placed in an unsecured location. For example, compact switch placed outside wiring
closet can potentially be swapped with hacker devices to gain access to the network,
 compromising network security. This creates a requirement whereby an edge switch
(Supplicant) is required to authenticate itself against upstream switch (Authenticator).

Network Edge Authentication Topology (NEAT) offers secure extension of the Layer 2
network beyond the wiring closet. It ensures that a supplicant switch (compact switch
outside the wiring closet) is allowed access to the network only if it authenticates
successfully. For more information on the NEAT click here. This document covers the
NEAT configurations with IOS Interface-templates.

Figure24: NEAT Network Topology

NEAT feature enables extended secure access in areas outside the wiring closet (such
as conference rooms). 802.1x supplicant switch acts as a supplicant to another switch
by using the 802.1X supplicant feature for secure connectivity. Once the supplicant
switch authenticates successfully, RADIUS servers sends down Cisco AV Pair
attributes along with ACCESS-ACCEPT to the Authenticator switch.

The following scenario with the Topology above depicts an overview of typical solution: -

1. The Supplicant switch located in unsecured location first authenticates with wiring closet or
distribution Authenticator Switch. The Authenticator contacts RADIUS server and receives an
authentication success message with Cisco AV-Pair Value specifying “device-traffic-OR
“interface-template-name= …” depending on the type of authorization profile selected on
RADIUS Server.
2. On successful authentication the downlink port on Authenticator Switch is opened in the single-
host mode (by default) or multi-host, multi-auth/MDA (if explicitly specified) and Authenticator
Switch will initially allow only a single MAC (Supplicant Switch MAC that got authenticated), thus
extends a trust model.
3. The switch auto-config/Interface template is applied on the Authenticator port to change the port
mode to TRUNK up receiving the Cisco AV-Pair attributed from the RADIUS Server.
4. Authenticator switch now trusts the Supplicant switch and network access is granted for switch
and all the clients behind the Supplicant Switch.
5. Supplicant switch triggers a CISP update to the Authenticator switch when a user’s/host
connect/disconnect network to add/remove MAC Address from the database.
 NEAT with Macros/Interface-Template

As explained before, when a Supplicant Switch successfully authenticates, the RADIUS

Server sends down Cisco AV Pair “device-traffic-along with ACCESSACCEPT to the
Authenticator switch. The authenticator switch then changes the port configuration from
access to “trunk-mode” with the help of a built-in macro.

The current macro based NEAT solution has two limitations:

1. The macros modify the interface running configuration. When a Supplicant Switch is
authenticated, if a script or administrator saves the running-config on the Authenticator Switch,
then on a power cycle the default port configuration would be lost.
2. If the admin prefers to make modifications to the default macro, it can’t be done. For this
purpose, an ASP macro must be configured on the ASw and ISE must be configured to
authorize the supplicant with the “ASP macro name” along with the custom Cisco AVP for
NEAT.

The solution to this problem is to use the interface-templates instead of macros for port
configuration related changes.

Interface template is a port configuration container that can be applied to a specific

interface or a user’s network access session. Almost all the interface specific
commands can be configured under the “template” and then either manually applied on
the port (with “source template” interface command) or can be applied dynamically on
the port, based on either device discovery (AutoConf, similar to AutoSmartPorts) or via
RADIUS authorization. One of the major advantages of interface templates is that the
running-configuration will have a fixed configuration, where the interface specific (active)
configuration will be placed under a separate runtime memory. The configuration that is
currently applied on a physical interface can be seen with the “show derived-config
interface <interface>” exec command. Interface templates are supported from Cisco
IOS 15.2(2)E / XE 03.06.00E.

Particulars NEAT with Macros NEAT with Interface

Supplicant EAP Methods All methods (MD5, PEAP, EAP-TLS) All methods (MD5, PE

CISP for MAC notification Yes Yes

Cisco AVP device-traffic-class=switch interface-template-na

Supplicant switch authorization

Yes No
modifies running-config on ASw

Modifying post-authc interface Modify the original au

With additional ASP Macro
configuration template referenced b

Table9: Macro Neat and Neat with Interface Template Comparison

Configuring NEAT with Interface templates

Configuring AAA & Radius on Authenticator and Supplicant switch

1. Log in to Authenticator and Supplicant switch and execute/verify the below basic
authentication, authorization and accounting (AAA) configurations.

aaa new-model
aaa session-id common
!
radius server ISE01
address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
radius server ISE02
address ipv4 172.20.254.22 auth-port 1812 acct-port 1813
automate-tester username test-user ignore-acct-port probe-on
key ISEisC00L
!
dot1x system-auth-control
dot1x critical eapol
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 3
radius-server deadtime 15
!
aaa group server radius ISE
server name ISE01
server name ISE02
ip radius source-interface Vlan254
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting Identity default start-stop group ISE
aaa accounting update newinfo periodic 2880
!
aaa server radius dynamic-author
client 172.20.254.21 server-key ISEisC00L
client 172.20.254.22 server-key ISEisC00L!
!
crypto key generate rsa general-keys mod 2048

Authenticator Switch Configurations

2. Enable CISP Framework.

c9300-Sw(config)#cisp enable

The Client Information Signaling Protocol (CISP) is a layer 2 control plane protocol used
to transport the MAC addresses of the hosts (both authenticated MAC and MAC learnt
by normal learning) from a Supplicant Switch to an Authenticator Switch. CISP uses
CDP address (Cisco Reserved Multicast Address) as a destination MAC Address and
frames are generated only by Supplicant Switch to which Authenticator switches acts as
a responder to the received frames.

3. Configure downlink port as access port with dot1x authentication

interface GigabitEthernet1/0/1
description ** Downlink to supplicant switch **
switchport mode access
 switchport access vlan 254
device-tracking attach-policy IPDT_POLICY
access-session port-control auto
dot1x pae authenticator
spanning-tree portfast trunk
spanning-tree bpduguard disable
service-policy type control subscriber PORT-AUTH-POLICY-I

4. Configure interface-template which can be referenced later by ISE as part of the

authorization policy.

template neat-authz
switchport trunk native vlan 254
switchport mode trunk

Supplicant Switch Configurations

The subsequent sections describe details of the configurations required for performing
NEAT on Supplicant Switch.

5. Enable 802.1X globally on the switch to authenticate device connected, use the dot1x
system-auth-control command in global configuration mode.

c9300-Sw(config)#dot1x system-auth-control

6. Configure switch to force sending only multicast EAPOL packets when it receives
either unicast or multicast packets, which allows NEAT to work on the supplicant switch
in all host modes & enable CISP framework globally.

c9300-Sw(config)#dot1x supplicant force-multicast

c9300-Sw(config)#cisp enable
7. Configure EAP mode & credentials used by supplicant switch to authenticate itself to
authenticator switch.

Note: In this configuration example EAP-MD5 is used as the EAP method between the
supplicant switch and ISE. However NEAT supplicants support many other EAP
methods. “show eap registrations” EXEC command tells the EAP support on the
supplicant switch

c3560CX-Sw(config)#eap profile eap-md5

c3560CX-Sw(config-eap-profile)# description PEAP-MD5 Supplicant
c3560CX-Sw(config-eap-profile)# method md5

c3560CX-Sw(config)#dot1x credentials eap-md5-cred

c3560CX-Sw(config-dot1x-creden)# username ssw01
c3560CX-Sw(config-dot1x-creden)# password 0 cisco@123
c3560CX-Sw(config-dot1x-creden)# anonymous-id ssw01

8. The connection of the supplicant to the authenticator is already configured to be a

trunk port (in contrast to access port configuration on the authenticator). At this stage,
this is expected; configuration on the authenticator will dynamically change when the
ISE returns the correct attribute

c3560CX-Sw(config)#interface TenGigabitEthernet1/0/8
c3560CX-Sw(config-if) description ** Upstream Authenticator switch **
c3560CX-Sw(config-if) switchport trunk native vlan 254
c3560CX-Sw(config-if) switchport mode trunk
c3560CX-Sw(config-if) dot1x pae supplicant
c3560CX-Sw(config-if) dot1x credentials eap-md5-cred
c3560CX-Sw(config-if) dot1x supplicant eap profile eap-md5
c3560CX-Sw(config-if) spanning-tree portfast edge

| configure the downlink port that connects to the endpoints..

c3560CX-Sw(config)#interface GigabitEthernet1/0/1
c3560CX-Sw(config-if) switchport access vlan 100
c3560CX-Sw(config-if) switchport mode access
c3560CX-Sw(config-if) switchport voice vlan 101
c3560CX-Sw(config-if) authentication periodic
c3560CX-Sw(config-if) authentication timer reauthenticate server
c3560CX-Sw(config-if) access-session host-mode single-host
c3560CX-Sw(config-if) access-session port-control auto
c3560CX-Sw(config-if) mab
c3560CX-Sw(config-if) dot1x pae authenticator
c3560CX-Sw(config-if) dot1x timeout tx-period 7
c3560CX-Sw(config-if) dot1x max-reauth-req 3
c3560CX-Sw(config-if) spanning-tree portfast edge
c3560CX-Sw(config-if) service-policy type control subscriber POLICY_Gi1/0/
1

ISE configuration for NEAT with Interface-template

ISE needs to be configured with the user identity and policies to authenticate and
authorize the NEAT supplicant. Follow these steps:

9. Add Supplicant Switch to the appropriate group. Navigate to Administration >

Network Resources > Network Devices, and click Add.

10. Create NEAT Switch User Account and add the user to NeatSupplicants group.
Navigate to Administration > Identity Management > identities, and click Add.
11. Enable the required authentication protocols. Navigate to Policy > Results >
Authentication > Allowed protocols, select the protocol service list used by wired
dot1x, and ensure the protocols in this step are enabled.
12. Create a new Authorization Profile and reference the interface-template. Navigate
to Policy > Policy Elements > Results > Authorization Profiles and click Add

Note: On ISE, one major difference between traditional NEAT and “NEAT with
Interface-template” configuration, is that the authorization profile for the former is Cisco
AVP “device-traffic-whereas for the later it is “interface-template-name=<name>”.

13. Navigate to the Policy > Policy Sets >Authorization Policy page and add new
policies as showing below and save the configuration.
 Validating NEAT

Use this section to confirm that your configuration works properly. This section
describes two behaviors:

 Authentication between switches

 Authentication between the Windows PC and the supplicant

Once authentication and authorization succeed, the CISP exchange occurs. Each
exchange has a REQUEST, which is sent by the supplicant, and a RESPONSE, which
serves as a reply and acknowledgment from the authenticator.

Two distinct exchanges are performed: REGISTRATION and ADD_CLIENT. During the
REGISTRATION exchange, the supplicant informs the authenticator that it is CISP-
capable, and the authenticator then acknowledges this message. The ADD_CLIENT
exchange is used to inform the authenticator about devices connected to the
supplicant's local port. As with REGISTRATION, ADD-CLIENT is initiated on the
supplicant and acknowledged by the authenticator.

Supplicant Switch Authentication to Authenticator Switch

In this example, the supplicant authenticates to the authenticator. The steps in the
process are

 The supplicant is configured and plugged into port Te1/0/1. The dot1x exchange causes the
supplicant to use EAP in order to send a pre-configured username and password to the
authenticator.
 The authenticator performs a RADIUS exchange and provides credentials for ISE validation.
 If the credentials are correct, the ISE returns attributes required by NEAT (“interface-template-
name=), and the authenticator changes its switchport mode from access to trunk.

 Communication from the supplicant


 2018/12/01 01:09:26.873 {smd_R0-0}{1}: [epm-tunnel] [22503]: UUID: 0, ra: 0, TID: 0 (
ERR): Linksec failure but policy is not must-secure. So return SUCCESS
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g):
 RADIUS/DECODE: parse unknown cisco vsa "profile-name=Unknown" - IGNORE
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius-authen] [22503]: UUID: 0, ra: 0, TID:
0 (debug): RADIUS(00000000): Received from id 1812/184
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS:rad_code 2, suppress reject flag 0
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 22 "profile-name=Unknown"
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 28
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 36 "interface-template-name=neat-authz"
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 42
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Message-Authenticator[80] 18
 RADIUS: 00 46 b6 01 a1 60 74 8a 1f 9c 12 f7 35 65 ed 09 [ F`t5e]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Message-Authenticator[80] 18 ...
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: EAP-Message [79] 6
 RADIUS: 03 52 00 04 [ R]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: EAP-Message [79] 6 ...
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 37 33 39 [ 739]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 65 2d 31 2f 33 32 39 32 34 30 31 38 32 2f 38 34 [e-1/329240182/84]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 30 30 31 33 31 36 37 34 46 42 37 36 38 3a 69 73 [00131674FB768:is]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Class [25] 53
 RADIUS: 43 41 43 53 3a 30 35 30 32 41 38 43 30 30 30 30 [CACS:0502A8C0000]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Class [25] 53 ...
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 34 46 42 37 36 38 [ 4FB768]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 30 32 41 38 43 30 30 30 30 30 30 31 33 31 36 37 [02A8C00000013167]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: State [24] 40
 RADIUS: 52 65 61 75 74 68 53 65 73 73 69 6f 6e 3a 30 35 [ReauthSession:05]
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: State [24] 40 ...
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: User-Name [1] 7 "ssw01"
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: authenticator b7 67 04 03 56 f9 d9 fa - 0b 03 b5 cf 1b ff 97 43
 2018/12/01 01:09:26.872 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Received from id 1812/184 10.1.100.21:0, Access-Accept, len 214
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Started a sec timeout
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS(00000000): Sending a IPv4 Radius Packet
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Calling-Station-Id [31] 19 "2C-AB-EB-A8-4F-88"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 31 38 32 2f 38 34 37 33 39 3b [ 182/84739;]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 6e 49 44 3d 69 73 65 2d 31 2f 33 32 39 32 34 30 [nID=ise-1/329240^@]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 37 34 46 42 37 36 38 3b 33 31 53 65 73 73 69 6f [74FB768;31Sessio^@]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: 35 30 32 41 38 43 30 30 30 30 30 30 31 33 31 36 [502A8C0000001316^@]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: State [24] 76
 RADIUS: 33 37 43 50 4d 53 65 73 73 69 6f 6e 49 44 3d 30 [37CPMSessionID=0^@]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: State [24] 76 ...
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: NAS-Port [5] 6 50101
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: NAS-Port-Id [87] 25 "TenGigabitEthernet1/0/1"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: NAS-IP-Address [4] 6 172.16.1.2
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 25 "client-iif-id=355993491"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 31
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 14 "method=dot1x"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 20
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 43 "audit-session-id=0502A8C000000131674FB76
8"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 49
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: EAP-Key-Name [102] 2 *
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: EAP-Key-Name [102] 2 *
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Message-Authenticator[80] 18
 RADIUS: 99 57 5f 79 e9 0a 25 a6 89 fc 5a ad 9b d9 7c 1d [ W_y?Z|]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Message-Authenticator[80] 18 ...
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: EAP-Message [79] 24
 RADIUS: 02 52 00 16 04 10 d1 fa e0 c1 cc b9 67 4b ba 88 bd a1 08 72 a4 db
[ RgKr]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: EAP-Message [79] 24 ...
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Framed-MTU [12] 6 1472
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Cisco AVpair [1] 21 "service-type=Framed"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Vendor, Cisco [26] 27
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (debu
g): RADIUS: Service-Type [6] 6 Framed [2]
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: User-Name [1] 7 "ssw01"
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: authenticator 9e f3 b4 12 9c 7b a9 b1 - d3 6f b0 4e da 45 bf 43
 2018/12/01 01:09:26.830 {smd_R0-0}{1}: [radius] [22503]: UUID: 0, ra: 0, TID: 0 (info
): RADIUS: Send Access-Request to 10.1.100.21:1812 id 1812/184, len 348

In order to verify behavior on the authenticator, enter the below show cisp command:

c9300-Sw#show cisp summary

CISP is running on the following interface(s):
----------------------------------------------
Te1/0/1 (Authenticator)

c9300-Sw#show cisp interface te1/0/1

CISP Status for interface Te1/0/1
-------------------------------------
Version: 1
Mode: Authenticator
Peer Mode: Supplicant
Auth State: Idle

c9300-Sw#show cisp clients

Authenticator Client Table:
------------------------
MAC Address VLAN Interface
---------------------------------
2cab.eba8.4fc2 200 Te1/0/1

In the example above, the role of authenticator is correctly assigned to the correct
interface (Te1/0/1) and Vlan 200 MAC address is registered.

Verification of dot1x authentication session indicate Te1/0/1 port already authenticated.

This is the dot1x exchange that is triggered where supplicant switch is plugged in.

c9300-Sw#show dot1x interface tenGigabitEthernet 1/0/1 det

Dot1x Info for TenGigabitEthernet1/0/1
--------------------------------------------
PAE = AUTHENTICATOR
QuietPeriod = 60
ServerTimeout = 0
SuppTimeout = 30
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30

Dot1x Authenticator Client List

-------------------------------
EAP Method = MD5
Supplicant = 2cab.eba8.4f88
Session ID = 0502A8C000000133675DCDD3
Auth SM State = AUTHENTICATED
Auth BEND SM State = IDLE

c9300-Sw#show authentication sessions int te1/0/1 det

Interface: TenGigabitEthernet1/0/1
IIF-ID: 0x1AE7F215
MAC Address: 2cab.eba8.4f88
IPv6 Address: Unknown
IPv4 Address: Unknown
User-Name: ssw01
Device-type: Cisco-Switch
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0502A8C000000133675DCDD3
Acct Session ID: 0x00000011
Handle: 0xc40000dd
Current Policy: PORT-AUTH-POLICY-I

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 1
50)
Security Policy: Should Secure
Idle timeout: 65536 sec

Server Policies:
Interface Template: neat-authz

c3560CX-Sw#sh int te1/0/8

TenGigabitEthernet1/0/8 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 2cab.eba8.4f88 (bia 2cab.eb
a8.4f88)

The interface on the authenticator is configured as access port prior to authentication

and derived interface configs after supplicant authentication.

c9300-Sw#sh running-config int te1/0/1

Building configuration...

Current configuration : 311 bytes

!
interface TenGigabitEthernet1/0/1
switchport access vlan 200
switchport mode access
device-tracking attach-policy IPDT_POLICY
access-session port-control auto
dot1x pae authenticator
spanning-tree portfast
spanning-tree bpduguard disable
service-policy type control subscriber PORT-AUTH-POLICY-I
end

c9300-Sw#sh derived-config int tenGigabitEthernet 1/0/1

Building configuration...

Derived configuration : 344 bytes

!
interface TenGigabitEthernet1/0/1
switchport access vlan 200
switchport trunk native vlan 200
switchport mode trunk
device-tracking attach-policy IPDT_POLICY
access-session port-control auto
dot1x pae authenticator
spanning-tree portfast
spanning-tree bpduguard disable
service-policy type control subscriber PORT-AUTH-POLICY-I
end
 Windows PC Authentication to Supplicant Switch

In this example, the Windows PC authenticates to the supplicant. The steps in the
process are:

 The Windows PC is plugged into Gi1/0/1interface on c3560CX-Sw (the supplicant).

 The supplicant performs authentication and authorization with the ISE.
 The supplicant informs the authenticator that a new client is connected on the port.

Dec 3 21:32:28.187: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/1: Power gr

anted
Dec 3 21:32:32.273: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, chang
ed state to up
Dec 3 21:32:33.276: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gigab
itEthernet1/0/1, changed state to up
Dec 3 21:32:33.276: CISP-EVENT (Gi1/0/1): Received action Link UpDown
Dec 3 21:32:33.276: CISP-EVENT (Gi1/0/1): Authenticator received event Li
nk UP in state Not Running (no-op)
Dec 3 21:32:35.754: CISP-EVENT (Gi1/0/1): Received action Add Client
Dec 3 21:32:35.754: CISP-EVENT (Gi1/0/1): Adding client 0050.56a3.9670 (v
lan: 100) to supplicant list
Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Supplicant received event Add C
lient in state Idle
Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Adding client 0050.56a3.9670 (v
lan: 100) to the ADD list
Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Adding client 0050.56a3.9670 (v
lan: 100) to ADD CLIENT req
Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): ADD CLIENT req full
Dec 3 21:32:35.754: CISP-EVENT (Te1/0/8): Transmitting a CISP Packet
Dec 3 21:32:35.754: CISP-TXPAK (Te1/0/8): Code:REQUEST ID:0x60 Length:0
x0029 Type:ADD_CLIENT
Dec 3 21:32:35.754: Payload: 010011020009005056A396700300050 ...
Dec 3 21:32:35.758: CISP-EVENT (Te1/0/8): Started 'retransmit' timer (30s
)
Dec 3 21:32:35.758: CISP-EVENT: Started CISP tick timer
Dec 3 21:32:35.758: CISP-EVENT (Te1/0/8): Supplicant state changed to Req
uest
Dec 3 21:32:35.988: CISP-RXPAK (Te1/0/8): Code:RESPONSE ID:0x60 Length:
0x0018 Type:ADD_CLIENT
Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Supplicant received event Recei
ve Packet in state Request
Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Stopped 'retransmit' timer
Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): All Clients implicitly ACKed
Dec 3 21:32:35.988: CISP-EVENT (Te1/0/8): Supplicant state changed to Idl
e
Dec 3 21:32:36.436: CISP-EVENT (Gi1/0/1): Received action Add Client
Dec 3 21:32:36.436: CISP-EVENT (Gi1/0/1): Adding client 000e.d72e.460b (v
lan: 101) to supplicant list
Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Supplicant received event Add C
lient in state Idle
Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Adding client 000e.d72e.460b (v
lan: 101) to the ADD list
Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): Adding client 000e.d72e.460b (v
lan: 101) to ADD CLIENT req
Dec 3 21:32:36.436: CISP-EVENT (Te1/0/8): ADD CLIENT req full
Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Transmitting a CISP Packet
Dec 3 21:32:36.439: CISP-TXPAK (Te1/0/8): Code:REQUEST ID:0x61 Length:0
x0029 Type:ADD_CLIENT
Dec 3 21:32:36.439: Payload: 010011020009000ED72E460B0300050 ...
Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Started 'retransmit' timer (30s
)
Dec 3 21:32:36.439: CISP-EVENT: Started CISP tick timer
Dec 3 21:32:36.439: CISP-EVENT (Te1/0/8): Supplicant state changed to Req
uest
Dec 3 21:32:36.988: CISP-RXPAK (Te1/0/8): Code:RESPONSE ID:0x61 Length:
0x0018 Type:ADD_CLIENT
Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Supplicant received event Recei
ve Packet in state Request
Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Stopped 'retransmit' timer
Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): All Clients implicitly ACKed
Dec 3 21:32:36.988: CISP-EVENT (Te1/0/8): Supplicant state changed to Idl
e

An ADD_CLIENT exchange occurs, but no REGISTRATION exchange is needed. In

order to verify behavior on the supplicant, enter the show cisp registrations command:

c3560CX-Sw#show cisp registrations

Interface(s) with CISP registered user(s):
------------------------------------------
Gi1/0/1
Auth Mgr (Authenticator)
Te1/0/8
802.1x Sup (Supplicant)

c9300-Sw#show cisp clients

Authenticator Client Table:
------------------------
MAC Address VLAN Interface
---------------------------------
 2cab.eba8.4fc2 200 Te1/0/1
000e.d72e.460b 101 Te1/0/1
0050.56a3.9670 100 Te1/0/1

c3560CX-Sw#show access-session int g1/0/1

Interface MAC Address Method Domain Status Fg Session ID
----------------------------------------------------------------------
Gi1/0/1 0050.56a3.9670 dot1x DATA Auth AC110102000000721614
63FF

c3560CX-Sw#show access-session int g1/0/1 details

Interface: GigabitEthernet1/0/1
MAC Address: 0050.56a3.9670
IPv6 Address: Unknown
IPv4 Address: 10.100.100.8
User-Name: Bob
Device-type: VMWare-Device
Status: Authorized
Domain: DATA
Oper host mode: single-host
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: 172800s (local), Remaining: 172226s
Common Session ID: AC11010200000072161463FF
Acct Session ID: 0x00000043
Handle: 0xDB00004A
Current Policy: POLICY_Gi1/0/1

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 1
50)
Security Policy: Should Secure
Security Status: Link Unsecure

Server Policies:
Vlan Group: Vlan: 100
SGT Value: 4

Method status list:

Method State

dot1x Authc Success

 mab Stopped

Log in to ISE web User Interface (UI) and navigate to Operations > RADIUS > Live
Logs.

Operate

The Operate section provides a comprehensive identity solution for all Cisco ISE run-
time services. The Monitoring component provides a real-time presentation of
meaningful data representing the state of access activities on a network. The
Troubleshooting component provides contextual guidance for resolving access issues
on networks.

Operating ISE
Operating the ISE Session Table

The monitoring component on ISE describes how to use the RADIUS Live Log to view
all the RADIUS authentication logs and how to get details about a specific entry in the
log table. This section covers some important operations that can be performed under
RADIUS live sessions.

1. Log in to ISE.

2. Navigate to Operations > RADIUS > Live Sessions.

All the active sessions on the network which are controlled by ISE are displayed.

3. Click the Target icon next to Show CoA Actions to view a list of CoA actions that
can be performed on a specific endpoint. For information about the list of CoA actions
,refer to Change Authorization for Radius Sessions

4. Click Gear icon to understand the license information of a live session.

5. Check the License Type and License Details check boxes, and click Go.
License information about the sessions are displayed when you scroll to the right-hand
side of the Live Sessions window.

Note: Live sessions cannot be deleted from the ISE user interface. CoA Session Termination will rele
active session, however, the entry still persists in the session table. In order to clear the entry from the
table, perform the below REST API call to ISE:

DELETE: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/Delete/All
Alternatively, perform a get function to gather the calling station IDs for all the active sessions and sel
them one by one using the following session API:

GET: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/AuthList/null/

DELETE: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/Delete/MACAddress/<calling_stati

ISE AAA Reports

Use the ISE operational reports to track endpoint and ISE deployment-related activities
over time.

1. Log in to ISE.

2. Navigate to Operations > Reports.

3. In the left pane, navigate to Reports > Endpoints and Users > Authentication
Summary.

4. By default, report for current data is generated and displayed. To change the report
period, click the Today drop-down list.
 On the same Authentication Summary window, statistics about the ISE deployment’s
performance is displayed.

Note: The other AAA-related reports include:

 Current Active Sessions

 RADIUS Accounting
 RADIUS Authentications
 Rejected Endpoints
 Top Authorizations by Endpoints
 Top Authorizations by Users
 Top N Authentication by Access Service
 Top N Authentication by Failure Reason
 Top N Authentication by Network Device
 Top N Authentication by User

The Top N Authentication by Failure Reason provides information about the top
authentication failures in the network.
 The Top N Authentication by Network Device report provides information about
which network devices have what percent of failure rates.

Troubleshooting
The following sections addresses several troubleshooting information that are related to
identifying and resolving problems that you may experience when you use Cisco ISE &
Cisco Catalyst Switches.

Cisco IOS Troubleshooting

Some of the Cisco IOS show and debug commands that help you understand and
troubleshoot ISE operations are:

 show running-config aaa - Displays AAA configuration in the running configuration.

 show authentication sessions/show access-session – Displays current authentication
manager sessions like interface, mac, method, session-id & status.
 show dot1x all – Displays 802.1x status for all interfaces
 show aaa servers – Displays status and number of packets that are sent to and received from
all AAA servers.
 show device-sensor cache all – Displays Protocol, Name/Len/Value of TLVfor the cached
entries
 show device-tracking database – Displays entries in the ip device tracking table.
 show platform hardware fed switch active fwd-asic resource tcam utilization – Displays
device-specific hardware resource usage information
 show platform software fed switch active acl usage – Displays number of ACL entries used
for different ACL feature types
 Operation Sequence Overview

The high-level functional sequence in Figure 25 shows how the components and
protocols of 802.1x work together.

Figure25: High-level 802.1x Sequence

Starting 16.x IOS XE, tracing functionality logs internal events where trace files are
automatically created and saved to the trace logs subdirectory.

The Contents of trace files are useful for troubleshooting & Debugging operations. To
modify the trace level to increase or decrease the amount of trace messages output
(Default set to NOTICE) you can set a new trace level using the set platform software
trace command.

 set platform software trace smd switch active R0 aaa-authen debug

 set platform software trace smd switch active R0 radius debug
 set platform software trace smd switch active R0 dot1x debug
 set platform software trace smd switch active R0 epm debug
 set platform software trace smd switch active R0 mab debug
 set platform software trace smd switch active R0 eap debug

To view the trace levels for respective module under a specific process (Session
Manager process/smd), use the show platform software trace level command

 show platform software trace level smd switch active R0

To view the most recent trace information, use the show platform software
trace message command

 show platform software trace message smd switch active R0



Refer to attachment below for the sample trace captures for dot1x success and Failed
sessions and major events are highlighted in bold..
 4. Cisco ISE BYOD Prescriptive
Deployment Guide

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

Author: Hosuk Won

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

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

Access Control Onboarding

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

 Endpoint Characteristics

- 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
 Endpoint Characteristics

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 May need to consider
every X number of days. When the password has integration with enterprise
been changed, user has to manually change it on all
 Password (EAP-PEAP-MSCHAPv2 & EAP-FAST) Digital Certificate (EAP-
TLS)

endpoints in short periods of time to avoid PKI for better BYOD user
connectivity issues. 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 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 3rd party devices which
lacks the feature, how ISE 3rd party NAD feature can still support the network devices.
 NAD Description ISE 3rd party NAD feature
Feature

URL- This allows endpoints to be redirected to a In the case of NAD without URL-
Redirect web portal when the user opens up a browser Redirect feature, ISE can be
on the endpoint. This is essential to the ISE configured to provide URL-
BYOD as ISE needs to interact with the end Redirect using DNS-Sinkholing.
user to guide through the process. There are With DNS-Sinkholing, any web
two main components of URL-Redirect. First request destinations are re-written
is the ACL which dictates what traffic will be with ISE IP address, where ISE
allowed without being redirected or not and can provide web portal
the second is the URL destination to direct
the web traffic to when the traffic is denied.
Also, there are two distinct ways to perform
URL-Redirect:

- Dynamic URL-Redirect: When an

endpoint is authenticated via RADIUS,
ISE can send back a name of ACL and
Destination URL as part of RADIUS
response. Most of Cisco devices and
limited number of 3rd party NAD supports
this method

- Static URL-Redirect: The URL

destination and the ACL is predefined on
the NAD as static configuration. This is
common method of URL-Redirect in most
of 3rd party NAD

CoA Change of Authorization is essential to BYOD ISE SNMP CoA still requires MAB
as it provides ways to transition from limited configured and functional on the
access during pre-onboarding to full access interface.
once onboarding is complete. ISE has two
different ways to provide CoA:

- RADIUS Based CoA: This is using

RADIUS to communicate between ISE
and the NAD

- SNMP Based CoA: For some 3rd party

NAD that does not support RADIUS
based CoA, ISE can use SNMP to
change the access. This is done by ISE
issuing SNMP Write command to the
NAD for the interface to shut down the
 NAD Description ISE 3rd party NAD feature
Feature

interface and immediately bring it back

up. As the interface is brought back up,
ISE can assign different permissions to
the interface

DNS Google Android and Chromebook requires Some 3rd party NDA supports DNS
based access to NSA which is located in the cloud. based ACLs, for others without the
ACLs NSA can be preinstalled, but if required to feature, ISE DNS-Sinkholing can
download NSA during the onboarding flow, be used to provide the feature.
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

Digital Certificates

ISE relies on digital certificates for various aspects of the solution. As noted above, ISE
utilizes certificates to identify itself to the endpoints for EAP, but it also uses certificates
to identity itself for web portals. In some cases, the EAP identity certificate and web
portal certificate could be different, but in many cases, it could be using the same
certificate for both to save on management cost. This is especially true when the
certificate is signed by well-known Certificate Authority (CA).

One of the main benefit of ISE BYOD is that ISE can provide signed certificate for the
endpoints as part of the BYOD flow. For endpoint certificates, ISE can utilize internal CA
to issue signed certificates. ISE is already enabled with internal PKI which can be
integrated with customer’s existing PKI infrastructure and also provide web portal to
manage endpoint certificates. Here are characteristics of ISE Internal CA:

- Generally used for BYOD

- Can also be used for other purposes such as to secure pxGrid communication

- Full certificate lifecycle management including multiple templates, expiry, revocation

(OCSP)

- Supports validity dates up to 10 years for endpoint certificates

- Supports up to 1 million certificates

Integration with MDM/EMM

ISE can leverage MDM/EMM to check posture of the mobile endpoints prior to providing
full network access. ISE itself doesn’t provide native MDM/EMM capabilities such as
checking for pin lock, encryption, jail broken status, but as endpoints connect to the
network ISE can reference the MDM/EMM system to see if the endpoint is compliant. If
compliant ISE can provide full network access, however, if the endpoint is not registered
with MDM/EMM or is not compliant, ISE can guide the end user to address the issue
without having to involve IT.

When My Devices Portal is used in conjunction with MSM/EMM, the portal allows end
user to issue MDM/EMM commands such as remote lock, remote wipe, corporate wipe,
etc.

Also, if endpoints are managed via MDM/EMM, some of the MDM/EMM vendors can
issue certificates as well as configure network settings without the need of ISE BYOD. If
using MDM/EMM for certificate provisioning and network configuration, ISE can be
configured to trust MDM/EMM signed endpoint certificate for better user experience.
Following is sample of MDM attributes ISE can look up for an endpoint during
authorization:

MDM Attribute Description

DaysSinceLastCheckin How many days elapsed from last MDM check for particular endpoint

DeviceCompliantStatus Attribute validate that complaint status been confirmed by MDM

server for particular endpoint

DeviceRegisterStatus Endpoint is known to MDM server and been previously registered

DiskEncryptionStatus Disk encryption is not enabled on the endpoint

IMEI IMEI value. Match based on endpoint IMEI value from MDM server
response

JailBrokenStatus Match endpoint status JailBroken based on MDM server response

Manufacturer Manufacturer name. Match based on mobile device manufacturer

name from MDM server response

MDMFailureReason FailureReason value

MDMServerName Match based on MDMServerName from endpoint attributes

MDMServerReachable Match reachable status of MDM server

 MDM Attribute Description

MEID MEID Value. Match based on endpoint mobile equipment

identifier(MEID) value from MDM server response

Model Model Value. Match based on mobile device model from MDM server
response

OsVersion OsVersion Value. Match based on mobile device OS version from

MDM server response

PhoneNumber PhoneNumber Value. Match based on phone number of mobile

device

PinLockStatus Pinlock disabled on endpoint

SerialNumber SerialNumber Value. Match based on mobile device serial number

from MDM server response

ServerType Server on which endpoint registered belongs to Desktop Device

Manager type (ex: Microsoft System Center) or Mobile Device
Manager type (regular MDM server)

UDID UDID Value. Match based on Unique Device Identifier (Apple

specific)

UserNotified User has not been notified previously about requirement to register
device (Desktop Device Manager specific check)

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

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

Now let’s look at the dual SSID flow:

In the case of dual-SSID flow, user initially starts on one SSID which may be shared
with guest access. But once onboarded, the endpoint is reconnected to the secured
SSID to gain elevated access. The initial SSID may be secured via WPA-PSK if the
WLC supports WPA-PSK and ISE-NAC (RADIUS-NAC on the same WLAN).

Note that when guest portal is used for BYOD flow, all employee users will go through
the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using
the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal can
be used based on authorization condition. This flow allows, for instance, different user
groups to have different BYOD portal and also allows each groups to register the
devices into different endpoint groups.
Note that in either flow, once the devices have been onboarded, there is no difference in
terms of the access to the secured network. Here are pros and cons of the different
BYOD flows:

Single SSID Dual SSID Dual SSID w/

differentiated BYOD
portal

Pros User experience is better for Some organizations Some organizations

iOS users as SSID switching prefer having a dedicated prefer having a dedicated
from OPEN to SECURED does SSID for on-boarding SSID for on-boarding
not require user intervention devices. devices.
This is a unique capability of Can provide visible Can provide visible
ISE where competitor solution guidance to the user on guidance to the user on
forces user to login twice while the BYOD process before the BYOD process before
ISE can take user information logging in logging in
from 802.1X session without Better security: User can Better security: User can
asking for the user to login confirm that the BYOD confirm that the BYOD
again to the web portal server is legitimate as the server is legitimate as the
Can provide different BYOD user does not get user does not get
portal based on authorization prompted to manually prompted to manually
condition. BYOD portal can be trust the EAP certificate trust the EAP certificate
tied to different endpoint group ID Store is LDAP and ID Store is LDAP and
for registration. cannot start with PEAP cannot start with PEAP
with MSCHAPv2 currently with MSCHAPv2 currently
to LDAP store to LDAP store
Wired deployment where Wired deployment where
cannot assume client cannot assume client
already has 802.1X already has 802.1X
enabled on wired enabled on wired
interface interface
Can be configured to use Can be configured to use
secured SSID that is not secured SSID that is not
broadcasting broadcasting
In the case of dual-SSID Can provide different
flow, BYOD portal can be BYOD portal based on
configured to allow guest authorization condition.
access if employee does BYOD portal can be tied
not want to go through to different endpoint
the BYOD flow groups for registration.

Cons Fast-SSID change setting Others see dual SSID as Others see dual SSID as
needs to be enabled on the an extra management an extra management
WLC to accommodate iOS burden. burden.
devices A second SSID adds A second SSID adds
When end users connect to the channel overhead and channel overhead and
SSID for the first time there is may degrade wireless may degrade wireless
 Single SSID Dual SSID Dual SSID w/
differentiated BYOD
portal

no easy way to validate performance performance

whether server provided Requires iOS users to Requires iOS users to
certificate is from the trusted manually switch SSID manually switch SSID
source Pre-authentication ACL is Some client OS may have
shared between guest issues with multiple
and employee users 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 3rd party CA server and can also be enabled along with first or second
option.

Self-Signed CA

This is the initial state of the ISE BYOD setting. The Internal CA
is enabled by default and ready to issue certificates for BYOD
endpoints. There are no additional actions to take in terms of
setting up the CA. This mode of deployment will be ideal for
PoC, pilot, or if the customer intends to separate PKI for BYOD
as opposed to having unified PKI for enterprise use and BYOD.
With separate PKI, it is easier to assign different permissions for
BYOD endpoints vs. enterprise endpoints.
 Subordinate CA

ISE internal CA can be integrated with customer’s existing PKI

such as MS CA services. In this mode ISE will be able to sign
BYOD certificates that is recognized by other entities that
already trusts the existing CA. If this is mode of operations that
is desired, then recommendation is to add the initial ISE node as
sub-CA of the existing PKI prior to adding secondary ISE nodes
to the deployment.

SCEP Proxy

This is legacy mode of operation, where ISE does not leverage

its internal CA, rather ISE forwards the certificate signing
request to external CA. Once signed ISE relays the certificate to
the endpoint which uses to identify itself. In this mode the
management of certificates can only be done with the CA itself.
For more information on this mode, please refer to the following
guide: https://www.cisco.com/c/en/us/support/docs/security/ident
ity-services-engine-software/116068-configure-product-00.html

The following table summarizes the 3 ways ISE can issue signed certificates to the
endpoint:

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

PKI

Pros Provide single point of ISE Internal Easiest deployment method.

management for all endpoint Certificates need to No configuration is
certificates; 3rd party CA be re-issued if already necessary. ISE is already
console as ISE simply proxies deployed as enabled with Self-signed CA
all certificate signing request to distributed to use with BYOD endpoints
3rd party CA deployment If there is existing PKI, ISE
internal CA provides
distinction between
enterprise CA issued
certificates for managed
devices, vs. BYOD

Cons Most complex deployment There may be Additional effort may be

mode licensing cost with needed to ensure the self-
 SCEP to enterprise CA Sub CA of enterprise ISE Self-Signed CA
PKI

Only been validated with MS 3rd party CA for each signed CA is trusted on the
CA (Requires MS enterprise signed endpoint network.
license for SCEP feature) certificate
There may be licensing cost
with 3rd 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

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 This is policy to control which BYOD profile will be pushed based on
Policy endpoint type or user group. BYOD profile includes certificate
template, SSID name, proxy settings, etc.

Authentication & This is the policy to control which portal will be presented to the user
Authorization Policy 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 {Available Index Value}

(Priority)

Server IP Address {ISE PSN IP}

Shared Secret ASCII

Format

Shared Secret {Shared RADIUS Key}

Port Number 1812

Server Status Enabled

Support for RFC Enabled (This option enabled CoA)

3576

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.

5. Click Apply and Save Configuration.

6. Click Accounting and New... to add RADIUS accounting servers
7. 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

8.

9. 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

Permit {ISE}/255.255.255.255 0.0.0.0 / 0.0.0.0 TCP 8905 Any Outbound

Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8905 Inbound

3. Note that this ACL works with ISE 2.4, however older version of ISE may require additional TCP
ports to be open.
4. Click ‘Back’ on the top right corner
5. Click down arrow next to the ACL and select ‘Add-Remove ACL’
6. 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

7. Click Back
8. 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 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 8444 Any Outbound

Permit 0.0.0.0 / 0.0.0.0 {ISE}/255.255.255.255 TCP Any 8444 Inbound

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

WLAN ID Available WLAN ID

General
Profile Name / SSID Secured

Status Enabled

Layer 2 Security WPA+WPA2

Security
WPA+WPA2 WPA2 Policy
Parameters

WPA2 Encryption AES

Authentication Key 802.1X

Management

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 Interim Update Enabled, Interim Interval 0

Accounting

Allow AAA Override Enabled

Advanced
NAC State ISE NAC (Or RADIUS NAC)
 Tab Attribute Value or description

RADIUS Client HTTP & DHCP Enabled

Profiling

Open SSID (Optional)

If there is an existing guest WLAN, same portal can be used for employee BYOD as
well. As employee user logs in to the guest portal ISE recognizes the guest users and
employee users and apply different flows. For guest users, ISE automatically applies
guest related access. Only named guest access portal such as self-service or
sponsored guest portal can be used as employee BYOD portal at the same time. If
hotspot guest access is used, then the same portal cannot be used for both hotspot and
employee BYOD portal. To create the open WLAN:

1. Go to WLAN
2. Click on Add New and create WLAN with following parameters

Tab Attribute Value or description

General WLAN ID Available WLAN ID

Profile Name / Open

SSID

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 Interim Update Enabled, Interim Interval 0

Accounting

Advanced Allow AAA Enabled

Override

NAC State ISE NAC (Or RADIUS NAC)

RADIUS Client HTTP & DHCP Enabled

Profiling
 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.

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 Currently, only value available is the MAC Address. The MAC Address is
Alternative pulled from the RADIUS session from the endpoint that initiated the BYOD
Name (SAN) 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 ISE Internal CA. If using SCEP to 3rd party CA, then this setting can be
Profile 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 For the BYOD use, only Client Authentication option needs to be checked
Usage

Defining BYOD Profiles and Resources

Here you can manage Windows and macOS Network Setup Assistant (NSA) and also
compile Native Supplicant Profile (NSP). There are two predefined NSP; one for
Chromebook and another shared among all other supported OS. With Chromebook
much of the network settings are pushed via G-Suite, so only setting to change within
the NSP is which certificate template is to be used. For other OS, multiple wireless
profiles can be automatically defined and created for any WLANs. Within the Wireless
setting, proxy settings, WPA settings, EAP type, and certificate template.

Native Supplicant Profile (NSP) controls certificate signing template, Wireless settings,
proxy settings, EAP type, and Wired network settings. At minimum, existing Native
Supplicant Profile (NSP) needs to be modified to reflect the SSID name of the secured
WLAN that is used. Follow the steps below to make changes to the existing NSP or
 create a new NSP. If creating new NSP, then the Client provisioning policy needs to be
modified to use the newly created NSP.

1. Go to Policy > Policy Elements > Results > Client Provisioning > Resources
2. Edit Cisco-ISE-NSP (Or Add > Native Supplicant Profile)
3. If editing default NSP, there is existing SSID ‘ISE’, which can be edited for the secure SSID
used on site. Edit the default SSID by checking it and clicking on Edit
4. Change SSID Name
5. (Optional) Configure proxy related settings
6. Recommended to leave Security to WPA2 Enterprise
7. For Allowed Protocol, select among TLS (For digital certificate), PEAP (For username &
Password), or EAP-FAST (For macOS and iOS). Note that if TLS is used, certificate template
needs to be selected as well.
8. Expand Optional Settings can be used to configure additional settings:
1. For Windows endpoints, use of machine or user store for certificate settings SSID broadcast
settings can be set here
2. For iOS devices, SSID broadcast settings can be set here
9. Click 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.
 Lastly, note that this same policy also affects posture client provisioning as well, which
controls which type of posture agent and compliance module will be enforced. Although
two different client settings are present in a single rule, ISE can enforce different client
settings based on the flow. The top portion titled ‘Agent Configuration’ controls posture
agent for the rule, while the bottom portion titled ‘Native Supplicant Configuration’
controls settings for the BYOD provisioning. Following shows default Client Provisioning
policy on newly installed ISE 2.4 system which includes policy rule for ISE supported
OS.

In general, the existing client provisioning policy should work for most environments,
however, if new NSA for Windows or macOS has been downloaded, then the client
provisioning policy will need to be updated to reflect the change. Also, if different native
supplicant profile other than the system provided one is used, then the client
provisioning policy needs to be updated to reflect the change. Lastly, if separate NSP is
required for certain set of users, ‘Other Conditions’ can be modified to match certain
user groups to specific NSP. To create new Client Provisioning rule:

1. Go to Policy > Client Provisioning

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

Creating policy for Single-SSID BYOD flow

When ISE is installed, there are set of AuthZ policy rules that are pre-created for BYOD
flow. Although the policy rules are in place, the rules are deactivated. Admin user can
simply enable the two rules to activate BYOD policy. The two rules are ‘Employee_EAP-
TLS’ and ‘Employee_Onboarding’.

When the user connects to the secured SSID using username and password, the user’s
endpoint does not have digital certificate, so the session will match
‘Employee_Onboarding’ policy rule which forces the endpoint to be onboarded. As the
endpoint goes through onboarding flow, the endpoint MAC address is registered to ISE
and the signed certificate is provisioned to the endpoint, at that point the endpoint will
be forced to reauthenticate to the same SSID where the session will match
‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess permission.

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

Creating policy for Dual-SSID BYOD flow

As with the Single SSID flow, also for dual SSID, when ISE is installed, there are set of
AuthZ policy rules that are pre-created for BYOD flow. Although the policy rules are in
place, the rules are deactivated. Admin user can simply enable the two rules to activate
BYOD policy. The two rules are ‘Employee_EAP-TLS’ and
‘WiFi_Redirected_to_Guest_Login’. The ‘WiFi_Redirected_to_Guest_Login’ rule is also
used for general self-service named guest access.

If self-service guest service is not needed, then it can be disabled from the guest portal
settings. This can be done by going to the guest portal in use for BYOD purpose and
unchecking the ‘Allow guest to create accounts’ option.

To make guest portal also support employee BYOD, the BYOD setting on the portal
needs to be modified. Go to the guest portal and expand ‘BYOD Settings’, then check
‘Allow employees to use personal devices on the network’ option. Notice that as soon
as this option is checked the contextual guest flow diagram on the right reflects the
change. The ‘Allow employees to choose to guest access only’ option allows the
employees to bypass the BYOD process and opt to get guest access only.

Note that when guest portal is used for BYOD flow, all employee users will go through
the same BYOD portal as the BYOD portal is tied to the guest portal. Instead of using
the BYOD portal that is tied to the guest portal as seen above, multiple BYOD portal can
be used based on authorization condition. Instructions on how to configure the flow is
shown in the appendix.

In the case of dual SSID BYOD, when the user connects to the open SSID, the endpoint
is unconditionally authorized to limited network access which provide enough access to
get to ISE guest portal.
This is done by using advanced authentication options for MAB to ‘CONTINUE’ even
when user is not found. The ‘CONTINUE’ option in the Authentication policy allows
unknown MAC addresses to bypass authentication and get conditionally authorized to
limited access where the endpoint can reach the ISE portal page for web login. This
allows the user to open up the web browser, and the user is redirected to the guest
portal. When the user logs in using username and password, ISE identifies the user as
employee as the account used to login to the portal is not in the guest user database,
which forces the user to BYOD portal instead of guest access.

As the endpoint goes through onboarding flow, the endpoint MAC address is registered
to ISE and the signed certificate is provisioned to the endpoint, at that point the endpoint
will be forced to reconnect to the secured SSID where the session will match
‘Employee_EAP-TLS’ policy rule and the endpoint gets PermitAccess permission.

If not using default policy set, then following instructions can be used. Here we are
going to create a policy set for Open SSID used for dual-SSID BYOD flow. Initially the
endpoints associate to the Open SSID. When user opens up a web browser, instead of
getting to the user’s browser destination, the user will get redirected to guest portal.
 When user enters credential for employees to the guest portal the user is guided to
follow steps to get the endpoint onboarded. The ISE can differentiate between the
employees and guests by identifying the identity store that is being used at the time of
authentication. Since the endpoint will connect to the secured SSID after the onboarding
is complete, the steps for single-SSID flow needs to be completed. Also note that the
BYOD portal has no bearing when using dual-SSID flow as the BYOD flow is subset of
the main guest portal.

1. Go to the Guest portal that is currently referenced by ‘Cisco WebAuth’ Authorization profile (If
this is fresh install of ISE, then it should be ‘Self-Registered Guest Portal (Default)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Click ‘Allow employees to use personal devices on the network’
6. Scroll up and click ‘Save’
7. Go to Policy > Policy Sets
8. Click on ‘+’
9. Change the new policy set name to ‘Open SSID’
10. In the conditions use ‘Normalized RADIUS : SSID ends with OPEN’
11. Click on Use
12. Select Default Network Access for Allowed Protocols
13. Click Save
14. Click on ‘>’
15. Click on ‘>’ on Authentication policy
16. On the ‘Use’ column, select Internal Endpoints instead of All_User_ID_Stores
17. Click on ‘> Options’
18. Change If User Not found from REJECT to CONTINUE (Setting this as CONTINUE allows ISE
to unconditionally authenticate the unknown MAC addresses so the session can continue
through the Authorization instead of getting instant REJECT. This is essential to make the flow
work as most of the endpoints connecting to the Open SSID will be initially unknown to ISE and
yet, ISE needs to be able to assign limited network access so user can be directed to the ISE
portal page)
19. Click on ‘>’ on Authorization policy
20. Click ‘x’ on Deny Access on Results:Profiles Column
21. Select Cisco WebAuth
22. Click Save (In real deployment if the same portal is used for guest users then we would be
creating the guest access rule as above the default rule)

Note about different ISE portals

So far the document provided instructions on how to use Guest portal and BYOD portal,
however, there are other portals that can be used to provide more control for the end
users:
 Portal Type Config Location Used for

Guest Portal Work Center > Guest User portal that end user goes through for
Access > Portals & onboarding. This is only used for dual-SSID flow.
Components > Guest Existing guest portal can be used for guest and
Portals 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 User portal that end user goes through for
> Portals & onboarding. This is only used for sing-SSID flow
Components > BYOD
Portals
Or
Administration >
Device Portal
Management > BYOD

Blacklist Administration > User portal for users with endpoints in blacklist
Portal Device Portal group. Instead of denying network access for
Management > blacklisted devices, it may be useful to provide
Blacklist visual guidance on how to proceed to get the device
back on the network when their device is
blacklisted.

My Devices Work Center > BYOD Used for end users to manage their own devices.
Portal (MDP) > Portals & Here users can view onboarded devices as well as
Components > My add devices manually. User can also mark devices
Devices Portals as stolen or lost which can impact network access.
Or If ISE is integrated with MDM/EMM, user can also
Administration > issue lock, full wipe, and corporate wipe from the
Device Portal portal.
Management > My
Devices

Certificate Administration > Used for signing and generating certificates

Provisioning Device Portal manually. Certificates can be signed by importing
Portal Management > CSR or certificate pair can be generated from the
Certificate portal. Access to the portal can be controlled via ID
Provisioning Portal store and groups.

Setting up Blacklist Portal (Optional)

The blacklist portal is already setup but note that it runs on different TCP port 8444
compared to the guest or BYOD portal which runs on 8443. Also, the blacklist portal
 utilizes different ACL on the WLC. The policy for Blacklisted devices is already created
and active, but following steps can be used to change the content that users are
presented when their devices are blacklisted:

1. Go to Administration > Device Portal Management > Blacklist

2. Click on Blackist Portal (default)
3. Click on Portal Page Customization
4. Page title and the message can be modified
5. Click Save

Note that the policy for blacklist is already setup and enabled on ISE, It still requires the
‘BLACKHOLE’ ACL to be present on the NAD to work.

Setting up My Devices Portal (Optional)

The My Devices Portal is hosted on the PSNs and already enabled by default. MDP is
typically used for non-guest end users to manage their personal devices. Follow the
below steps to reconfigure the behavior of My Devices Portal

1. Go to Work Centers > BYOD > Portals & Components > My Devices Portals
2. Click on My Devices Portal (default)
3. Expand Portal Settings
4. Certificate group tag
5. Fully qualified domain (FQDN) and host names (If FQDN is configured here, the DNS server
needs to be updated to point to PSNs as well in order to direct users to the MDP using FQDN.
Also, if the portal certificate used is not a wildcard certificate, it should also contain the FQDN as
SAN to avoid security popup on the web browser trying to access the portal)
6. Endpoint identity group
7. Authentication method (Currently, there is no way to control access to the MDP based on end
user groups from internal ID or AD. In other words, if an ID store is enabled to login to MDP, any
user with valid user credential can access the MDP)
8. Scroll up and click on Portal Page Customization
9. Under Pages, click on Manage Device
10. Click on Settings on the right hand preview pane
11. You can select which options are available to end users

Setting up Certificate provisioning portal (Optional)

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

Operate
Review Single-SSID BYOD Flow
User experience on iOS
Ste User Experience Note
p

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
Ste User Experience Note
p

sending
credential
s.
Although
user is
associate
d to the
WLAN,
user is
limited to
ISE portal
and
associate
d services
to get
BYOD
onboardin
g flow
work.
This
includes
DHCP,
DNS, and
access G-
suite or
Google
Play
store.
Ste User Experience Note
p

2 Once
associate
d to the
secure
SSID,
user
opens up
the
browser
and the
browser
automatic
ally
redirects
user to
the BYOD
Portal.
Note: If
the
pseudo
(Apple
CNA)
browser
automatic
ally opens
up that
means
the
captive
portal
bypass
feature
was not
enabled
on the
WLC or
the
WLAN.
Ste User Experience Note
p

3 2nd page
of the
BYOD
portal
allows
end user
to provide
device
name and
descriptio
n 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
automatic
ally
configure
s the
network
interface
or WLAN
profile per
the
settings
specified
Ste User Experience Note
p

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.
Dependin
g on the
iOS
security
settings,
user may
be
prompted
to enter
iOS PIN
to trust
the
download
ed
settings
and
profiles.
Note: If
self-
signed
certificate
is used,
due to
XXX, iOS
10.3 and
Ste User Experience Note
p

above
requires
extra
steps to
trust the
ISE
certificate
. Please
see
appendix
for more
informatio
n.

5 Once the
onboardin
g is
successfu
l, 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
destinatio
n.

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
Ste User Experience Note
p

1 User
connects
to the open
SSID and
opens up
the Safari
browser.
User is
automatica
lly
redirected
to the
guest
portal. If
the guest
portal
certificate
is not
signed by
known CA,
user may
Ste User Experience Note
p

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
Ste User Experience Note
p

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
automatica
lly
configures
the
network
interface or
WLAN
profile per
the
settings
specified
on the ISE
NSP as
Ste User Experience Note
p

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
downloade
d 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
Ste User Experience Note
p

for more
information
.

5 Once the
onboarding
is
successful,
user is
sent back
to Safari
browser.
The last
page of
portal
notifies the
user that
the user
has to
manually
change
over to the
secure
SSID by
going to
settings.
This is due
to iOS
restriction
as it does
not allow
change of
SSID
automatica
lly. Once
connected
to the
secure
SSID, user
can open
app or
browse to
other
 Ste User Experience Note
p

destination
.

Note that
the
manual
switchove
r to
secure
SSID is
only
required
for iOS
devices.
Other OS
can be
switched
over
automatic
ally.

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.

Step User Experience Note

4a During the last step of the flow in either single or dual SSID
flow described in the previous steps, instead of succeeding in
the provisioning flow, user will get following error page: Profile
installation Failed

4b On the iOS click home button, go to Settings > General >

About > Certificate Trust Settings. Enable the trust for the
certificate as root CA by sliding the option bar to the right and
select Continue to accept the changes
4c Click Home button and open Safari and go through the BYOD
flow again. This time the flow should be able to complete
without the error.
Note: If Retry button does not work, enter an external URL in
the address bar to initiate redirect.

If the ISE certificate is signed by well-known 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 EP hasn't been through BYOD flow(this is the default for every end point in the
Registered 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 Shows the integration between ISE and external MDM. Also shows
Device Management endpoint status from the ISE without having 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.

 Report Note

Supplicant Provides details on the supplicant and certificates provisioned by

Provisioning onboarding for employees.

My Devices Login and Combined report that tracks:

Audit
 Login activity
 Device related operations performed by users in the MDP

Appendix
Dual-SSID flow with differentiated portal
This flow is similar to dual-SSID flow, but instead of utilizing the BYOD setting within the
guest portal, the BYOD portal is used for employees. Once employee user logs in to the
guest portal, the user is presented with BYOD portal based on the authorization
condition. In the example below, the user group will be used to provide different BYOD
portal. This example utilizes the NAD settings and NSP settings in the main section of
the document.

Create endpoint groups

1. Go to Administration > Identity Management > Groups

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

Create user groups

1. Go to Administration > Identity Management > Groups

2. Click on ‘User Identity Groups’ on the left and click ‘Add’
3. Provide name ‘User_Group_A’ for the group and click Submit
4. Repeat above for ‘User_Group_B’
 Create end users

1. Go to Administration > Identity Management > Identities

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

Create BYOD portal

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

Configure Guest portal

1. Go to the Guest portal that is currently referenced by ‘Cisco WebAuth’ Authorization profile (If
this is fresh install of ISE, then it should be ‘Self-Registered Guest Portal (Default)’)
2. Go to Work Centers > Guest Access > Portals & Components > Guest Portals
3. Click on Self-Registered Guest Portal (default)
4. Scroll down to BYOD Settings and click > to expand
5. Make sure ‘Allow employees to use personal devices on the network’ is unchecked
6. Scroll down to ‘Authentication Success Settings’ and click > to expand
7. Select URL and enter www.cisco.com (Or any site that is resolvable by DNS and on the trusted
side of the network)
8. Scroll up and click ‘Save’

Create Authorization Profiles

1. Go to Policy > Policy Elements > Results

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

Create policy

1. Go to Policy > Policy Sets

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

Author: Jason Kunst

 Table of Contents
 Introduction
 About Cisco Identity Services Engine (ISE)
 What is Covered in This Guide?
 What is Not Covered in This Guide?
 Define
 What is Guest Access?
 Guest Access with Hotspot Guest Portals
 Licensing
 Design
 ISE Deployment Model Considerations
 Survivability
 Configuration Best Practices for Cisco WLC
 Apple Captive Network Assistant (CNA)
 IP Address and VLAN changes
 Caveats
 Wireless Deployment Models
 Deploy
 Configuring the WLC for ISE Web Authentication
 Configure ISE as RADIUS Authentication Server on WLC
 Configure a Guest WLAN (SSID)
 Configure an ACL to Redirect Guest Devices to the ISE Guest Portal
 Configure a Catalyst Switch for Guest Access
 Switch Capabiliities
 Example Switch Configuration
 Configure ISE for Guest Access
 Add the Network Access Device to ISE
 Policy Set for Credentialed Guest Access
 Understanding Guest Flow
 Using Guest_Flow to Match Guest User Type
 ISE Authorization Policy for Contractor Guest Type
 Guest User Experience
 The Guest “Remember Me” Feature
 Guest User Experience with “Remember Me”
 Policy Configuration for the Guest “Remember Me” Feature
 Using an Authorization Profile to Redirect Guest Endpoints to ISE
 Access Control for Guest Traffic
 Configure the Minimum Settings for Self-Registered Guest Flow
 Configuring Guest Type Access Times, Location, and Time Zone
 Configuring From First Login
 About the “From Sponsor-Specified Date” Option
 Working with Locations and Time Zones
 Configure Settings for the Sponsored Guest Flow
 Guest Portal for the Sponsored Flow
  Configure Sponsored Guest Access
 Configure Authorization Profile and Policy for Sponsored Guest Access
 Working with Sponsor Accounts
 Using Sponsor Accounts from Active Directory
 Set Up the Active Directory Sponsor Group in All_Accounts
 Set Up ISE Sponsor Portal FQDN-Based Access
 Configure Basic Portal Customization
 Setting up a Well-Known Certificate
 Create a Certificate-Signing Request and Submit it to a Certificate Authority
 Import Certificates to the Trusted Certificate Store
 Bind the CA-Signed Certificate to the Signing Request
 Operate
 Validation of flows
 Testing Web Portals
 Clearing Guest Endpoints
 Monitoring Guest Connections
 For Self-Registered Guest Flow
 Viewing the Guest Users List
 Access without Sponsor Portal
 Access with Sponsor Portal
 Troubleshooting Common Issues
 Miscellaneous
 How Do I Get Support?

Introduction

About Cisco Identity Services Engine (ISE)

Figure1: Cisco Identity Services Engine

Cisco ISE is a leading, identity-based network access control and policy-enforcement

system. It is a common policy engine for controlling end-point access and network
device administration for enterprises. ISE allows an administrator to centrally control
access policies for wired, wireless, and VPN endpoints in a network.

ISE builds context about endpoints, including users and groups (Who), device type
(What), access time (When), access location (Where), access type
(Wired/Wireless/VPN) (How), threats, and vulnerabilities. By sharing vital contextual
data with technology partner integrations and the implementation of a Cisco Software
Defined Segmentation policy, ISE transforms a network from a conduit for data into a
security enforcer that accelerates the time-to-detect and time-to-resolution of network
threats.

About This Guide

This guide describes the process and best practices for configuring ISE with a Cisco
Wireless LAN Controller (WLC) or a Cisco switch to provide guest access.

This guide is designed to be used in an environment where WLC and ISE have already
been set up.

The purpose of this guide is to help you with common setup and deployment questions,
and to describe
configurations with a Cisco WLC, Cisco switch, and ISE. Note that the guide does not
 cover more complex configurations, such as configuring load balancing or
foreign/anchor controllers.

Figure2: ISE for Guest Implementation Flow

There are four major sections in this document. The Define section shows how to
define problem areas, plan for deployment, and other considerations;
the Design section shows how to design a guest access network; the Deploy section
provides guidance about the various configurations and best practices; and lastly,
the Operate section shows how to manage a guest network controlled by Cisco ISE.

What is Covered in This Guide?

This guide provides information about the following configurations:

 Basic portal settings in ISE 2.3.

 Authorization polices and rules for hotspot, self-registered, and sponsored Guest portals.
 Minimum settings required for a guest flow.
 Configuring a Cisco WLC 8.5 and later with any type of Guest portal in ISE.
 Configuring a Cisco switch, for example, Cisco Catalyst 3850 Series Switch for guest access.

What is Not Covered in This Guide?

This guide does not cover the following topics:

 Tools required to configure multiple controllers and switches
 Deployment models and modes, such as:
o SDA/DNA
o VRF
o Other Wireless systems, such as:
 Mobility Express
 CMX
 ISE Third-Party NAD Profiles and Configs
 How To: Integrate Meraki Networks with ISE
 Easy setup wireless tools, such as:
o Wireless Easy Simplified Controller Setup
o ISE Secure Access Wizard
o ISE Profiling Guide
o ISE Load Balancing
o ISE Guest & Web Authentication

Define
What is Guest Access?
When people outside your company attempt to use your company’s network to access
the internet or the resources and services in your network, you can provide them with
network access using Guest Access portals. Guests typically include authorized visitors,
contractors, customers, or other temporary users who require access to your network.

The two types of Guest Access portals supported by this guide are:

 Guest Access with Hotspot Guest Portals

 Guest Access with Credentialed Guest Portals

Guest Access with Hotspot Guest Portals

A Hotspot Guest Portal provides network access to guests without requiring usernames
and passwords. This type of guest access eliminates the overhead required to manage
each individual guest account. When guests connect to a network, they are redirected
to the ISE Hotspot Guest Portal where they must accept an Acceptable Use Policy
(AUP) to gain access to the network, and eventually, the internet.

Guest Access with Credentialed Guest Portals

A Credentialed Guest Portal requires guests to have a username and password to gain
access. Using a self-registration portal, guests can create their own account credentials,
which they can then use to log in to the Guest portal. Credentials can also be created
for a guest by a sponsor. A sponsor can be an employee or a lobby ambassador. When
guests connect to a network, they are redirected to a portal. They log in to that portal
using the credentials that they created through self-registration, or were provided by a
sponsor. After guests log in, they may be required to accept an AUP before they can
access the network, depending on the portal. Access can also be set up using a
Sponsored Guest Portal, which requires users to have the credentials created by a
Sponsor.

For more information about Guest portals and features, refer to the “Cisco Guest
Access” section in the Cisco Identity Services Engine Administrator Guide.

Licensing
ISE guest access requires base license for each guest endpoint. For more information
about licensing, see the community page for ISE Licensing.

Design
ISE Deployment Model Considerations
A frequent question that is asked is about safely deploying an ISE Guest portal in DMZ.
While multiple options exist, it is the customers' prerogative to determine the best
approach, based on their requirements. The following are some general guidelines:
ISE PSN in the DMZ — You
must enable communication
between the PSN and the PAN
and MNT nodes for database
synchronization. Note that in
this context, this PSN is only
used for Guest portals. You
should use more than one
PSN for redundancy. Your
sponsors connect to a PSN
inside the network to create
guest accounts.

ISE PSN with an interface in

the DMZ - You will have a
separate interface on the
internal ISE PSN for Guest
portal traffic by having an
interface in the DMZ. Here,
you will only allow
communication to the PSN
from the wireless controllers
and clients for RADIUS and
the Guest portal. This same
PSN can be utilized to offer
the Sponsor portal. Two PSNs
with interfaces in the DMZ are
recommended for redundancy.
 Separate ISE deployment in
the DMZ – For customers who
are extremely security-
conscious, you can dedicate a
separate ISE deployment for
handling guest access.
Depending on how many
locations you want to service,
you could start with a high-
availability standalone setup
with 2 PAN +MNT/PSNs
located in your DMZ.

Survivability
If a PSN loses contact with the PAN, you will see one of behaviors listed below. This list
provides an overview of the major issues you may encounter. We recommend that you
plan for WAN redundancy to mitigate these risks.

 Sponsors are unable to create, update, or delete guest accounts related to users connecting to
a specific PSN.
 Sponsor portal operations are severely impacted.
 Hotspot and self-registration flows will fail.
 Existing guest accounts will be able to access the network.

Configuration Best Practices for Cisco WLC

The wireless controller team has incorporated configuration options in their GUI in order
to implement best practices for quicker configuration of ISE. These changes were
introduced in Version 8.5, which is the version referred to in the configuration sections
of this document. In the WLC GUI, see the following options and associated shortcut
information:
 Please reference TAC Recommended AireOS Builds for best code version.

1. SECURITY > AAA > RADIUS > Authentication Servers > Apply Cisco ISE Default
Settings — Checking the Apply Cisco ISE Default Settings check box enables Change-Of-
Authorization (CoA), sets the RADIUS authentication port to 1812/UDP, and duplicates and
creates the settings for a RADIUS accounting server.
2. WLAN > Security > AAA Servers > Apply Cisco ISE Default Settings — Checking the Apply
Cisco ISE Default check box enables Allow AAA Override, sets NAC State = ISE NAC, and
enables Radius Client Profiling for DHCP/HTTP Profiling (Probes).

Note: The NAC State setting of ISE NAC (RADIUS NAC, prior to AireOS Version 8.5) enables ISE to send a Co
which allows a user to authenticate and access the network. Essentially, this setting gives ISE the ability to
state of a client on the fly, without requiring a new session. For example, after being redirected to ISE for p
authentication, the client is authenticated and allowed access to the network. Please reference TAC Recom
AireOS Builds for best code version.

For more information about best practices and timers with Cisco Wireless Controller,
refer to How To: Universal Wireless Controller (WLC) Configuration for ISE.

Apple Captive Network Assistant (CNA)

When connecting to guest networks with Apple iOS devices, Apple uses a mini pseudo
browser called the Captive Network Assistant (CNA). This browser is not the native
Safari browser. The CNA pops up automatically when the device gets into a captive
portal situation. Sometimes, the CNA window is hidden behind a splash page, such as a
hotspot or Guest portal, and the users cannot see it, and cannot gain access to the
internet. Cisco ISE supports CNA only for basic guest access. The CNA browser may
be limited in its capabilities to support BYOD (device onboarding), social login for guest
access, and SAML SSO-based logins. Hence, it is not recommended for these
workflows.

If you have to suppress the Apple CNA, you can do so per WLAN, or globally, using the
captive portal bypass feature on WLC. For most guest use cases, you do not have to
enable the bypass feature. For more information, see the following links:

 Configuring Captive Network Assistant Bypass per WLAN (GUI)

 Dealing with Apple CNA (AKA Mini browser) for ISE BYOD
 Dual SSID BYOD with Apple Captive Network Assistant (CNA) Browser

IP Address and VLAN changes

 Another frequently asked question is whether you can change the IP addresses of the
guests after they log in to the portal, for example, if you have distinct VLANs for guests,
contractors, and employees. ISE has no control over the endpoints when it is connected
to an open network because there is no supplicant involved. In 802.1x networks, the
supplicant has the intelligence to release/renew the IP address on the machine.
However, we recommend that you do not change the IP address after login, for the
following reasons:

 Dynamic VLAN changes work only on Windows operating systems.

 You can perform IP address renewal when new VLAN authorization takes place by running
activeX and Java controls on the browsers. However, this is not supported today in most of the
browsers; besides, running them requires local administrator rights on the endpoint.
 The connection must be to an open network, without encryption, which is not true separation.

In order to support network separation, we recommend that you set up a Guest WLAN
with 802.1X, set up guest types as Guests and Contractors, and allow them to bypass
the web login. However, note that you will not be able to utilize the settings in the guest
types, such as allowed login hours, or how many times a user can log in to the portal
with different devices.

If it is absolutely necessary to separate guest traffic with web authentication and not
802.1X, we recommend that you set up a low DHCP timer for initial network access so
that when a device switches networks, it can renew its IP address in the new VLAN.
Alternatively, you can use Cisco Software Defined Segmentation solution, and deploy
scalable group tags for segmentation.

Caveats
At the time of publishing this document, we have the following caveat:

 IPv6 is not supported on ISE Guest portals.

Wireless Deployment Models

We recommend that your deployment model use wireless auto-anchor mobility (also
called guest tunneling), where guest traffic is tunneled through the anchor controller.
This model requires the controller to be in the DMZ.
 This document describes a high-level recommendation; it does not discuss the different
wireless models. For more information about wireless design and WLC auto anchor,
see the following sections in the How To: Universal Wireless Controller (WLC)
Configuration for ISE.

 Chapter: Configuring Auto-Anchor Mobility

 Guest Anchor Priority

Note:

Because of the caveat specified in CSCul83594, you cannot enable RADIUS accounting o
Both WLCs sending accounting start and stop messages with different session IDs, will co
When this occurs, an "Error 500" message is displayed to end users (typically, when they
to the ISE portal). This issue occurs on a per WLAN basis. If you have other WLANs that a
ISE services, this issue might not occur. The issue lies with the new simplified configuratio
on the WLC named “Apply Cisco ISE Default Settings”. When enabling the check box, i
configures an authentication server and an accounting server with the same IP and setting
settings are ported to the WLAN configuration too. The problem occurs when you configur
checkbox on both WLCs. Accounting needs to be configured on the foreign controller.

In WLC version 8.6+, the session id will be shared between anchor and foreign controllers
accounting will then be possible to enable on both.

Please reference TAC Recommended AireOS Builds for best code version.

If you are using FlexConnect, we recommend that you use central switching mode.
Local switching does not support URL-based DNS ACLs. If you want to use
FlexConnect Local switching, for example, branch, be aware of the following caveat:

Without using URL-based ACLs, you cannot easily implement ACLs that open up cloud-
based SSO providers, such as SAML or social media access. One workaround is to
permit access to all the internet and enable URL-redirect only for internal sites (for
example, for employee SAML SSO). Writing IP ACLs for social media access could be
cumbersome because they typically resolve to several IP addresses.

Deploy
Configuring the WLC for ISE Web Authentication
This section shows how to configure the necessary security settings on the WLC to
work with ISE. If you are working with a switch, see Configure a Switch for Guest
Access.
 Note: This section provides information about how to set up a single controller. If you want to crea
configuration using a foreign anchor model, see the documents listed under Wireless Deployment

Configure ISE as RADIUS Authentication Server on WLC

1. Log in to the WLC server’s GUI using admin credentials.

2. Click Advanced.
3. Choose Security > AAA > RADIUS > Authentication from the left menu, as shown in the
following figure:

4. Click New.

The RADIUS Authentication Server window is displayed, as shown in the following

figure:
5. Enter the ISE IP address for Server IP address and the RADIUS shared secret for Shared
Secret fields.
6. Check the Apply Cisco ISE Default Settings check box.

Note: Checking the “Apply Cisco ISE Default Settings” check box enables support for CoA, which is required
duplicates this setting for RADIUS Accounting.

7. Click Apply.
8. Click the Security tab and choose, Security > AAA > RADIUS > Accounting.

ISE will be automatically configured as a RADIUS accounting server, as shown in the

following figure:

Configure a Guest WLAN (SSID)

1. Click the WLANs tab.

From the drop-down list on the right side of the window (see the figure below)
choose Create New and click Go.

2. Enter a Profile Name and SSID.

3. Enable the Status check box, and from the Interface/Interface Group(G) drop-down list,
choose your interface, in this case, guest.

4. Click the Security tab.

5. Choose None for Layer 2 Security configuration.

Note:

From WLC Version 8.3.102, ISE guests with WPA+PSK are supported. This is not related to Ident
(IPSK). For more information, see Release Notes for Cisco Wireless Controllers and Lightweight A
for Cisco Wireless Release 8.3.102.0.

Please reference TAC Recommended AireOS Builds for best code version.

This allows enterprises to protect their network from users on other floors or in the parking lot from
to your OPEN SSID, and exhausting the DHCP pools or ISE base licenses. To enable this feature, p
following procedure:

o Under Security > Layer 2, choose WPA+WPA2.

o Check the MAC Filtering check box.
o Set Authentication Key Management to PSK.
6. Check the MAC Filtering check box

7. Click the AAA Servers tab.

8. Check the Apply Cisco ISE Default Settings check box.
9. Under Authentication Servers and Accounting Servers, check the Enabled check boxes,
and from the Server 1 drop-down lists, choose your ISE server, as shown in the figure below:

10. Click the Advanced Tab.

The Advanced Tab options are displayed, as shown in the following figures:
 The following defaults are enabled when you selected Apply Cisco ISE Default Settings in
the AAA servers window:

o Allow AAA Override – Enabled

o NAC State – ISE NAC
 Changes the state from a web redirection state to permit access state.
o Radius Client Profiling - DHCP Profiling and HTTP Profiling are enabled.
 Used for identifying your device type, for example, whether you are using an iPad or iPhone; the
WLC packages the device-identifying data and sends it to ISE via RADIUS accounting packets.
11. Uncheck the FlexConnect Local Switching, Enabled check box.

Note:

If you are using local switching (see Wireless Deployment Models), leave this enabled.

12. Click Apply.

13. Navigate to Security > Layer 3, and from the Captive Network Assistant Bypass drop-down
list, choose Disable, as shown in the following figure:

Note:

When you apply Cisco ISE Default Settings, it enables Captive Portal Bypass, which suppress the A
browser. We recommend that you disable Captive Portal Bypass to make the mini browser (Captive
Assistant) pop up automatically when connecting to a guest network, and use it for guest access.

14.
Captive Network Assistant Bypass options:
o None - Uses the current global Captive Portal Bypass setting.
o Disabled - Disables CNA on the WLAN, regardless of the global Captive Portal Bypass setting.
o Enabled - Enables CNA on the WLAN, regardless of the global Captive Portal Bypass setting.
15. Click Apply to save your WLAN configuration.

Configure an ACL to Redirect Guest Devices to the ISE Guest Portal

This section describes how to configure an ACL on the WLC. The objective is to
configure an ACL that allows guest clients to access guest services.

1. In the WLC GUI, choose Security > Access Control Lists > Access Control Lists.
The Access Control Lists window is displayed, as shown in the figure below. This window lists
the ACLs that are configured on the WLC. It also enables you to edit or remove any of the
ACLs.
2. Click New to create a new ACL

3. In the Access Control List Name field, enter ACL_WEBAUTH_REDIRECT as the ACL name,
as shown below:

4. Click the ACL name, to edit it

5. Click Add New Rule.

6. The Access Control Lists > Rules window is displayed.

7. Configure the rules, as shown in the following figure:

Note:

198.18.133.27 is the IP address of ISE in this example. We recommend that you use your ISE IP ad
add all the PSN nodes that are servicing the Guest portal with this ACL. If you change the TCP por
your Guest portal, make the same change here (from 8443 to the new port number).

8. (Optional) Configure Guest ACL

If your deployment is set up in a DMZ, and your guest network already has ACLs in place, you
can skip on to the next section. If you have setup your guest network in a configuration where
your network has access to internal resources then you will need to configure an ACL to permit
guest access to the internet and block access to internal resources after guest authorization. To
ensure that the rules of the new ACL to permit guest access to the internet. This ACL must
permit access to the internet, your ISE PSN IP address(s), and the internal resources that you
want them to have access to as seen in the screenshot below. You can use the same procedure
 above to setup a permit internet ACL using the following example.

Note:

In the above example, 198.18.133.0/24 is the internal network that guests cannot access. If your gu
in a DMZ, you will not have to limit access to your internal network since the DMZ is outside the i
network.

Configure a Catalyst Switch for Guest Access

This section covers the minimal required configuration on a Catalyst Series switch to
work with ISE guest. This was validated with IOS and IOS-XE platforms.

When using network devices with ISE, make sure they are running the minimum code
version provided in the corresponding compatibility guide. If you need a higher code
revision, you should test it in a lab before going into production. The ISE team does not
test all the devices with all the code versions. If you need additional support, reach out
to the respective device teams at Cisco.

If your switch is not listed, and you have a question about its compatibility with ISE, see
the community post, Does ISE Support My Network Access Device?

Additionally, if deploying with SGT’s then review the validated hardware and software
versions within the latest capability matrix.

Use the following links for information about general best practices on Cisco Catalyst
switches with ISE.

 ISE Secure Wired Access Prescriptive Deployment Guide

 Cisco TrustSec Quick Start Configuration Guide

Switch Capabiliities

Your switch must meet the following requirements to work in an ISE guest setup:

 Layer 3 SVI for your guest network – the switch requires a routable Layer 3 interface that can
communicate with endpoints in order to redirect the browser to the ISE Guest portal.
o Note: If the access layer switches are layer 2 only then this routable interface can exist on an
upstream device. Example your access switch only has an management network (port/SVI) and
cannot communicate with the endpoint networks.
o For more information (this applies to many switching platforms) : ISE Traffic Redirection on the
Catalyst 3750 Series Switch
 Ip device tracking – usually enabled by default but critical on tracking the endpoint. For IBNS
2.0 device tracking please refer to the ISE Secure Wired Access Prescriptive Deployment Guide
 Switch management IP – Communicates with ISE via RADIUS in order to control AAA
functionality.
 Global RADIUS and AAA configurations – The switch is configured for AAA using ISE.
 Pre-Auth ACL – This is manually configured on the switch. When a user device initially
connects to the network, this ACL restricts what that device can access until authenticated by
ISE. The device must at least be able to communicate with ISE to see the Guest portal. You can
also open access to a company portal by adding a link to the Guest portal. For example, you
might want to give access to a hospital’s welcome page containing information about the hours
of operation, a directory of departments, and so on.
 Redirect ACL – This is manually configured on the switch to identify traffic that will be
redirected to the Guest portal. Here, you can also identify traffic that is not redirected, for
example, to the company website mentioned previously.
 Enable HTTP service – This configuration on the switch redirects the endpoint HTTP requests
to the Guest portal. Note: HTTPS redirection is not recommended. For more information about
this, see ISE Guest CWA and HTTPS redirection.
 Change of Authorization (COA) – Cisco Network Access Devices utilize RADIUS COA to
allow changes in the Guest use case from a redirect state to a permit state. For example: A
device connects to the wire. When its first authorized its based of simple MAB (MAC
Authentication Bypass). ISE is setup to redirect any basic MAB from unknown endpoints to the
Central Web Authentication (CWA) portal. This portal can host an Acceptable Use Policy (AUP)
page like a hotspot or a credentialed login portal. The user clicks to accept or enters their
credentials. At this point ISE sends a COA to the switch with a new authorization result. This
time without a redirect ACL and likely with a permit ACL that allows internet access. For more
information on RADIUS COA see Chapter: RADIUS Change of Authorization in the
Authentication, Authorization, and Accounting Configuration Guide, Cisco IOS Release 15SY
 DOT1X System Auth Control required to enable authentication manager on a port.
Example Switch Configuration

This sample configuration gives full network access even if the user is not
authenticated; therefore, you might want to restrict access to unauthenticated users.

In this configuration, HTTP and HTTPS browsing does not work without authentication
(per the other ACL) since ISE is configured to use a redirect ACL (named redirect).
Here is the definition on the switch:

ip access-list extended ACL_WEBAUTH_REDIRECT

deny ip any host <ISE ip address>
permit TCP any any eq www
permit TCP any any eq 443

This access list must be defined on the switch in order to define on which traffic the
switch will perform the redirection. (It matches on permit.) In this example, any HTTP or
HTTPS traffic that the client sends triggers a web redirection. This example also denies
the ISE IP address so traffic to the ISE goes to the ISE and does not redirect in a loop.
(In this scenario, deny does not block the traffic; it just does not redirect the traffic.) If
you use unusual HTTP ports or a proxy, you can add other ports.

Another possibility is to allow HTTP access to some web sites and redirect other web
sites. For example, if you define in the ACL a permit for internal web servers only,
clients could browse the web without authenticating but would encounter the redirect if
they try to access an internal web server.

The last step is to allow CoA on the switch. Otherwise, the ISE cannot force the switch
to reauthenticate the client after the login to the guest portal.

aaa server radius dynamic-author

client <ISE ip address> server-key <radius shared secret>

This command is required for the switch to redirect based on HTTP traffic:

ip http server

This command is required to redirect based on HTTPS traffic:

ip http secure-server
 These commands are also important:

radius-server vsa send authentication

radius-server vsa send accounting

dot1x system-auth-control

Here is the switchport configuration

interface GigabitEthernet1/0/1
description ISE Port
switchport access vlan 100
switchport mode access
authentication open
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication timer inactivity server
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
spanning-tree bpduguard enable

Configure ISE for Guest Access

Now that you have configured your network access device to work with ISE web
authentication, you must complete the necessary steps on ISE.

Add the Network Access Device to ISE

Perform the following procedure to add a wireless controller or switch to ISE:

1. Log in to ISE Admin UI.

2. Navigate to Administration > Network Resources > Network Devices.
3. Click Add, as shown in the following figure:
4. In the Name field, enter the device name.
5. Choose IP Address from the drop-down list and enter the corresponding device’s IP address:

6. Check the RADIUS Authentication Settings check box.

7. In the Shared Secret field, enter the corresponding information:

8. Click Submit.

If software defined segmentation is deployed then enable the Advanced TrustSec

Settings and complete the details as explained in the following guide: Cisco TrustSec
Quick Start Configuration Guide.
 Policy Set for Credentialed Guest Access

From ISE 2.3, the only way to configure authentication and authorization rules is to
use Policy Sets. By default, sample authorization rules are available for credentialed
guest access. This section describes how to enable these rules.

1. Navigate to Policy > Policy Sets.

2. Click the arrow to expand the default policy set, as shown in the figure below:

3. Expand the Authorization Policy.

4. Scroll down until you see the built-in Wi-Fi policies for Guest Access and then enable them.

Note: Like other built in policies, an SGT is applied to the Guest Access by default. This
can be utilized in your Software Defined Segmentation story, for more information
please see the Segmentation and group based policy resources community.

Understanding Guest Flow

Guest-access authorization with ISE happens in two stages. The initial flow is a MAC
authentication Bypass (MAB), where ISE authorizes the endpoint for URL redirect to
itself. This results in the web traffic from the guest user’s device to be redirected to the
ISE Guest portal. Note that at this stage, the network device (switch or WLC) and ISE
will track the endpoint’s network connection with a common session ID. When a guest
user logs in with guest credentials, the guest user ID is merged with the existing MAB
session. This part of the process is termed as Guest Flow, where an existing MAB
session gets guest user context appended to it. Therefore, there are two authorization
rules for guest access; the Wi-Fi Redirect to Guest Login rule redirects unknown
endpoints to the Cisco_WebAuth profile for presenting to a Guest portal, and the Wi-Fi
Guest Access rule is used after users enter their credentials (Guest Flow). This grants
them internet access (permit access).

The following figure shows central web authentication:

 Using Guest_Flow to Match Guest User Type

Guest user accounts can be created with several attributes that determine their roles
and responsibilities in the network. ISE has 3 built-in guest types. As an administrator,
you can create your own custom guest types. The following are the built-in guest types:

 Contractor — Users who need access to the network for an extended amount of time, up to a
year.
 Daily — Guests who need access to the resources on the network for just 1 to 5 days.
 Weekly — Users who need access to the network for a couple of weeks.

ISE Authorization Policy for Contractor Guest Type

1. Enable both the Wi-Fi Redirect to Guest Login and the Wi-Fi Guest Access policies.
2. Click Save.
3. Under Policy Sets, you can edit the existing rule for Wi-Fi_Guest_Access policy. Click the
pencil icon. Make the changes, as shown in the figures below, and then click Save.
4. When you complete this procedure, your policy will look like this. Remember to save the new
policy.

Guest User Experience

The following figure depicts guest user experience:

1. Guest user’s device connects to the network.
2. The web traffic from the guest device is redirected to the ISE Guest portal, where users can
sign-up for an account or enter their credentials.
3. Once users enter their guest credentials, they are in the Guest Flow, and will be granted
access to the Wi-Fi Guest Access rule.
4. The device is permitted access to the internet.

Note that if the device goes to sleep or if users leave the network and come back, they
will be required to go through the login process again.

Guest users are required to log in to the ISE Guest portal every time they connect to the
network. For example, users may put their device to sleep, resume from sleep mode, or
get a new wireless session ID. The default wireless user Idle Timeout value on the WLC
is 180 seconds. This user experience can be avoided with the Guest Remember
Me feature on ISE.

The Guest “Remember Me” Feature

This section describes how to allow a guest to access the network without being
redirected to ISE every time after the initial login. With the previous rule set
(Guest_Flow), when a device leaves the network and comes back, the device is
redirected to the login process again.

The Remember Me feature works by using the endpoint group to track users. Currently,
there are caveats, with ISE granting access based on the endpoint group. This is
because there is no user logging into the Guest portal. Instead, access is based on
MAB, using the MAC address. Be aware of the following:

 Reporting issues (MAC address is shown in the ISE reports instead of usernames.)
 Guest Type options will not work if there is no portal login.
o Time-based restrictions, for example, access only from 9 a.m. to 5 p.m.

Restrict access times by utilizing the authorization policy conditions.

o Maximum number of simultaneous logins with the same guest account:

Instead, you can restrict the number of devices that are allowed to register under Guest
Type for wireless.

Note: Another way to remember guests is to use the Sleeping Client feature in
the wireless controller. This feature keeps the wireless session cached in
memory. The potential problem with this is that only a certain number of
sessions can be stored in the controller’s memory. However, this document
does not cover that feature.
 Guest User Experience with “Remember Me”

1. User connects to the Guest network.

2. Device is redirected to the ISE guest login window.
3. User logs in.
4. Device MAC address is registered in Guest Endpoints group.
5. Device goes away and returns for new wireless session.
6. Device is granted access based on its MAC address membership in the Guest
Endpoints group.

Note: This is the same configuration that is used for a hotspot portal. The only
difference is that with hotspot, you redirect guests to a hotspot portal instead of
to a self-registered Guest portal.

Policy Configuration for the Guest “Remember Me” Feature

1. Navigate to Policy > Policy Sets.

2. Click the arrow to expand the default policy set.
3. Click Wi-Fi_Guest_Access conditions to edit the rules.

4. Under Editor, remove the Guest_Flow by clicking the (x) icon.

5. Click Add to add a new condition.

6. Define the condition as IdentityGroup:Name Equals Endpoint Identity Groups:
GuestEndpoints.

7. Click Use.

Note: Clicking on Save with allow you to use the Guest Endpoints MAB condition again
in another rule if you like, since its not complex you don’t need to re-use so instead we
go direct to Use.
8. Click Save to save the policy set

Note: For wired guest access, the policy can be modified in two ways.
The WiFi_Redirect_to_Guest_Login policy can be duplicated, and in the new rule, the
endpoint’s session can be matched with Wired_MAB instead
of Wireless_MAB. Alternatively, the WiFi_Redirect_to_Guest_Login policy can be
edited to match Wireless_MAB or Wired_MAB with an “OR” condition check.

The Remember Me feature is a simple MAB function based on

the GuestEndpoint Endpoint Identity group. The MAC address of any guest user’s
device that is authenticated once will automatically be registered
under GuestEndpoint within ISE. A user has to accept an Acceptable Use Policy
(AUP) for hotspot access, or enter certain credentials for credentialed guest flows only
once. From then on, access is based on the guest device’s registered MAC address.
Thus, the guest will not be redirected to the ISE portal for AUP or login, on subsequent
network connections, until the MAC address is purged from the GuestEndpoint group.
The default purge period is 30 days and can be customized for individual environments.
Note that this is not guest account purging, just a guest device’s MAC address. To
change the endpoint purge period, perform either of these tasks:

 For Hotspot, endpoint purge configuration can be done under portal settings.
 For credentialed guest flow navigate to Administration > Identity Management > Settings >
Endpoint Purge
o As long as the endpoint is in the Endpoint group called out in the authorization rule then the
device will have access without having to login to the credentialed portal. You can set the
EndpointPurge rule as low as 1 day. An example would be if GuestEndponts AND
ENDPOINTPURGE: ElapsedDays LESSTHAN 9999. This will remove all endpoints in the guest
database when the purge runs on its daily schedule.
 For Credentialed guest accounts, the endpoint duration can be configured under the Guest
Type settings.
 Using an Authorization Profile to Redirect Guest Endpoints
to ISE
As explained in Understanding Guest Flow, when endpoints first access the network,
they are authenticated with MAB, and must be redirected to the Guest portal for
authorization. ISE comes with a built-in profile called Cisco_WebAuth that references a
built-in self-registered Guest portal. This section shows you how to modify this
authorization profile to use other portals and URL-redirect ACLs.

The following configuration can be used for both wireless and wired environments. The
WLC and switch require a preconfigured redirect ACL which you completed earlier in
this document.

1. Navigate to Policy > Policy Elements > Results.

2. Expand Authorization and click Authorization Profiles.
3. Check the Cisco_WebAuth check box.

4. Change the profile to work for your setup:

o From the Web Redirection drop-down list, choose Hotspot or Centralized Web
Authentication (for Self-Registration or Sponsored Guest Flows).
o ACL – Enter the ACL being used for the redirection. This example uses the pre-configured ACL

Note: The ACL is case-sensitive and must match the definition in the Network Device
exactly.

o From the Value drop-down list, choose the appropriate default portal (Hotspot, Self-
Registration, or Sponsored).
5. Click Save.
Example: Authorization Profile for Hotspot Guest Access

Example: Authorization Profile for Self-Registered Guest Access

Access Control for Guest Traffic
In a typical scenario, the guest Wi-Fi traffic is isolated in the DMZ, and the guest wired
traffic is segmented using a Guest VLAN, as shown in the figure below. In some
environments, the guest wireless traffic may be within a campus with separate SSID
and VLANs too. How you want to manage your guest network is up to you. However,
note that controlling guest traffic from accessing internal resources is important.

While VLAN segmentation helps in keeping the traffic separate, as explained in the IP
Address and VLAN changes section, it is not a good idea to change VLANs dynamically
for guests. The use of IP ACLs and/or SGTs can be a remedy for this issue. For guest
traffic segmented on DMZ, an ACL and/or SGT policy to permit all IP traffic can be
applied, and for the guest traffic within a campus network, an IP ACL and/or SGT to
deny access to private IP addresses will suffice in most of the cases. This section
describes the optional tasks of authoring and authorizing an ACL for a guest user
connecting internally.
 Overall the recommendation would be to consider using segmentation using Scalable
Group Tags (SGTs) in your deployment to help reduce the overall management costs
and help with your organization segmentation story.

For more information please see the Segmentation and group based policy resources
community.

1. Navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs.
2. Click Add.

3. Create an ACL with the following requirements:

o Permit the ISE PSN IP address on port 8443 (allow access to Guest portal).
o Permit access to internal sites, if necessary.
o Deny access to internal networks.
o Permit everything else.
o The following figure shows a sample ACL:

permit tcp any host 192.168.133.27 eq 8443

deny ip any 192.168.0.0 0.0.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 10.0.0.0 0.255.255.255
permit ip any any

4. The DACL on ISE can be validated by the Check DACL Syntax option.
5. Click Submit to save the ACL.
6. Click Authorization, then click Authorization Profiles, and finally, click Add.

7. Configure the Authorization Profile, as shown in the following figures (the left figure indicates
for a wired guest and the right figure indicates for a wireless guest):
 Note: AireOS does not support downloadable ACLs. Therefore, ACLs must be
configured locally on the wireless controller (or access points in FlexConnect mode).
The ACL names must match in both ISE and in AireOS. The Guest ACL configuration on
the WLC is very similar to the DACL configuration on ISE.

8. Save the authorization profile.

9. Navigate to Policy > Policy Sets.
10. Expand Default Policy Set and Authorization Policy.
11. Modify the Wi-Fi_Guest_Access authorization rule, as shown in the figure below:

12. Click Save.

This completes the steps required to get a portal up and running with your network
device (switch or WLC).

If you are using a hotspot portal for guest access, you can go to the Configure Basic
Portal Customization section.

If you are using the self-registration or sponsored flows (Credentialed Guest Access),
then additional configuration is required. Continue with the next section, Configure the
Minimum Settings for Self-Registered Guest Flow.

Configure the Minimum Settings for Self-Registered Guest

Flow
The default portal settings for self-registered guest access redirects guest users to the
login window after successful account creation. This is a cumbersome task for the
guests. For ease-of-use, we recommend that you allow guest users to log in to the
network directly after registration. The following steps show you how to configure this:

1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).
3. Under Portal Behavior and Flow Settings, select Self-Registration Success Settings.

4. Scroll down to the bottom of the window and check the Allow guests to log in directly from
the Self-Registration Success page check box.

5. Expand the Guest Device Registration Settings

6. Check the box to Automatically register guest devices.

Note: This setting is highly recommended for use with “Remember Me” functionality.
This allows the device to be remembered after the user initially logs into the Guest
Portal. Using this flow is a better user experience as they only have to log in once per
device until the device is purged.

7. Expand Post-Login Banner Page Settings, and uncheck the Include a Post-Login Banner
page check box.

8. Scroll up and save the portal settings by clicking Save.

Configuring Guest Type Access Times, Location, and

Time Zone
In ISE 2.1, the option of From first login was introduced in the Guest Type. This option
improves the ISE Guest Access setup. However, by default, the From sponsor-
specified date option is selected for all guest types. We recommend that you switch all
your guest types to use From first login.
 From first login enables a guest account immediately after a sponsor creates that
account, or when the user self-registers on the Guest portal. This is particularly useful
for those who want simple guest access that is activated immediately and lasts for a
specific amount of time. The account can be valid for a day or a week, and you do not
have to worry about limiting access to a set time of day or a specific amount of time.

With the From first login option, you do not have to worry about creating location and
associated time zones unless you want to limit the time range during which a user can
log in to the Guest portal. If you want to set strict limits on access hours, you should set
up locations and time zones. However, if you only want guests to be able to use the
account starting at a specified time, you will have to work with the sponsor-specified
date. For more information about this, see Working with Locations and Time Zones.

Configuring From First Login

1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Types.

2. Change the following settings for a specific guest type of interest or all guest types
(except SocialLogin(default)).
About the “From Sponsor-Specified Date” Option

Instead of the From first login option, if the sponsor-specified date option is chosen
for guest account start time, the location and time zones corresponding to the locations
where the guests will be accessing the network, must be configured. Your guest or
sponsor can easily choose the time zones when the accounts are activated. Use this
setting if you require a specific set of times during which your guests can use their
account for network access. Unlike the From first login option that activates an
account immediately, this setting activates an account at a specific time, which is when
the account is registered by the guest, or when the sponsor sets its start time.

Note: If you do not configure a location, the account will not get activated at the
correct time, and the user will not be able to log in.
 Ensure that the time on your ISE server is correct. Even if it is only a few minutes faster
than your browser, you may notice that it takes a few minutes for the accounts created
using self-registration or sponsored flows to start working. When this happens, an
Authentication Failed message is displayed to the end user using the Guest portal.

Also, under Operations > RADIUS > Live Logs in ISE, you can see failure entry details
stating that the account is not yet active.

Working with Locations and Time Zones

If you need to restrict access to certain times of the day, you must configure locations
and time zones. If only one location is configured in your portal and sponsor group,
guests and sponsors will not be presented with the option to select a location.

Since only one location, San Jose, is available out-of-the-box, there is a problem with
new setups in other time zones. For example, when an ISE administrator sets up a
system in Boston, it is 9. a.m. there. The admin goes to the self-registration window or
the Sponsor portal window to create an account, thinking that he/she is working with the
local time. However, the time zone is PST. The account (unless the admin is using
From First Login) will not be activated for another 3 hours, and the guests will not be
able to log in. Unless the guest users connect to the network in PST time, a separate
location configuration must be done in ISE to cater to those users in different time
zones.

Deployments in the PST time zone can use the San Jose location that is built into ISE. If
that time zone is acceptable to you, skip to the Configure Settings for the Sponsored
Guest Flow section.

Note: You cannot change the name of the default San Jose location. However,
you do not have to remove it because it will not be displayed if you do not
choose to use it.

For more information about location and SSIDs, see Assign Guest Locations and
SSIDs in the Administrators guide.

To configure guest locations and time zones, perform the following steps:

1. Navigate to Work Centers > Guest Access > Settings > Guest Locations and SSIDs.

The Guest Locations and SSIDs window is displayed.

2. Enter a Location Name and Time zone, for example, Boston (EST) using EST5EDT or
America/New York.

Do not delete the San Jose Location.

3. Click Add.
4. Click Save.

Configure Settings for the Sponsored Guest Flow

Guest Portal for the Sponsored Flow

From a guest user’s perspective, there are a couple of options to provide sponsored
guest access:

 Self-registered guest access with sponsor approval – A guest user registers the account by
filling in all the mandated fields during the initial Guest Flow, and upon notification, the sponsor
approves or declines access.
 Sponsored guest access – A guest user cannot register an account, but has to collect the
credentials from the sponsor via SMS or email to log in to the guest network. To configure this,
see Configure Sponsored Guest Access.

Configure Self-Registered Guest Access with Sponsor Approval

1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).

3. Under Portal Behavior and Flow Settings, select Registration Form Settings.

4. Check the Person being visited check box and the Require guests to be approved check
box.

5. Scroll down and chose the notification methods applicable to your environment.
6. Scroll up and Save the configuration.
7. If you’re decided to use self-registration portal as configured above then next you will need to
configuration an Authorization Policy, Configure Authorization Policy

Configure Sponsored Guest Access

The default self-registration portal can be used for both self-registered and sponsored
guest access. The following table explains the options for both the scenarios:

Guest Type Guest Can Sponsor Role Guest Portal

Create Own
Accounts

Self-registered Yes (Optional) Can approve or Self-Registered Guest Portal

guest user deny guest access

Sponsored No Must create guest account

guest user and share credentials to Sponsored Guest Portal
guest user
Or

Self-Registered Guest
Portal
(with settings to deny guests
the permission to create
own accounts)

If you are looking at only sponsored guest access, and do not want to allow guests to
self-register, perform these steps:

1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).
3. Under Portal Behavior and Flow Settings, select Login Page Settings.

4. Uncheck the Allow guests to create their own accounts check box.

5. On the right-hand side, when you click Guest Flow, the flow should appear, as shown in the
figure below:
 Note: The Guest Flow for both Self-Registered Guest Portal (with the Allow guests to
create their own accounts option unchecked) and Sponsored Guest Portal is exactly the
same. The default sponsored Guest portal is available under Work Centers > Guest
Access > Portals & Components > Guest Portals.

 Scroll up and Save the configuration.

Configure Authorization Profile and Policy for Sponsored Guest Access

1. Navigate to Policy > Policy Elements > Results, select Authorization Profiles, and check
the Cisco_WebAuth check box.
2. Ensure that the authorization policy redirects guest users to the portal you are using. Use the
following configuration as an example:

3. Ensure that the ISE authorization policy results for Cisco_WebAuth profile for guest user’s initial
MAB session. To do so, check the corresponding policy under Policy > Policy Sets: Default >
Authorization Policy > Wi-Fi_Redirect_to_Guest_Login.
 Working with Sponsor Accounts

Set up your sponsors by either creating an internal account or configuring ISE to

integrate with Active Directory. If you are integrating with Active Directory, skip to the

Using Sponsor Accounts from Active Directory section

To create an internal account, perform the following steps:

1. Navigate to Administration > Identity Management > Identities > Users.

2. Click Add.

3. Fill in the information for the Sponsor.

4. Under User Groups, if ALL_ACCOUNTS, which is the default, is not selected, select it.
5. Click Submit.

Using Sponsor Accounts from Active Directory

Perform the procedures described in this section and the Setup the Active Directory
Sponsor Group in All_Accounts only if you are integrating your Guest Access system
with an Active Directory server that contains your sponsor groups.

For more information see the Active Directory as an External Identity Source section in
the Cisco Identity Service Engine Administrator Guide.

To create sponsor accounts from Active Directory, perform the following steps:

1. Navigate to Administration > Identity Management > External Identity Sources.

2. Select Active Directory.
3. Click Add.

4. Enter the Join Point Name and Active Directory Domain.

5. Click Submit.

A “Would you like to join all ISE Nodes to the Active Directory Domain?” message is
displayed.

6. Click Yes.
7. You are asked to enter your credentials to join the domain. Note that the Specify the
Organizational Unit field is optional. Click the information icons next to each field for more
details on what is required.
8. Click OK.
 Note: The domain credentials are not saved by ISE. The credentials are used only once
to create a machine account for ISE in the Active Directory.

9. A Successful message is displayed

10. Click Close.

11. Click the Groups tab.
12. Click Add, and select Groups from Directory, as shown in the figure below:

13. Click Retrieve Groups.

14. After you choose the groups that contain the users who will be sponsoring guests, click OK at
the bottom of the window.

15. After you choose your groups, the configuration will look, as shown in the following figure:

16. Click Save at the bottom of the window.

You have now completed the task of setting up Active Directory Groups that can be
mapped to your sponsor groups.
 Set Up the Active Directory Sponsor Group in All_Accounts

The following steps show how to associate the group containing your sponsors or
employees to the sponsor group. In the example described here, we use Domain Users.

1. Navigate to Work Centers > Guest Access > Portals & Components > Sponsor Groups >
ALL_ACCOUNTS.

The Sponsor Group window is displayed, as shown in the figure below:

2. From the members list under Available User Groups, move the domain users under Selected
User Groups, as shown in the figure below:
3. Click OK.
4. Click Save.
It is important to configure correct locations that can be used when sponsors create your guest
accounts. If you are fine with using San Jose as the location, or do not have to use locations
because of your guest types, you can skip Steps 5-8.
5. From the Select the locations that guests will be visiting section, select the locations you
want your sponsors to use, as shown in the figure below.

6. Add in the locations you plan to use in your deployment.

7. Scroll to the top of the window, and click Save.
8. Click Close.

Set Up ISE Sponsor Portal FQDN-Based Access

A Sponsor portal allows a sponsor to create temporary accounts for guests, visitors,
contractors, consultants, and so on. It also allows you to view the accounts that guests
create for themselves.

The following are the three options that are available to access the Sponsor portal; the
first two methods require no special configuration, and can be accessed via the ISE
admin GUI:

 Using the Manage Accounts button – Navigate to Work Centers > Guest Access > Manage
Accounts.

This window is reserved for administrators to quickly see what is going on with guests.
However, we recommend that you do not use this to manage guests and sponsors. Use
it only to quickly access the guest listing, mainly for deployments that do not use
 a Sponsor Portal. We highly recommend that you set up an easy-to-use Sponsor
portal.

 Using the Portal Test URL - This URL can be sent to your sponsors so that they can easily
bookmark the site. This is the default option.
 Using Sponsor Portal FQDN – This is an easy-to-remember URL that requires some additional
configuration.

We recommend that you provide your sponsors with an easy Sponsor Portal URL, for
example, Error! Hyperlink reference not valid..

Perform these steps to provide easy access to the Sponsor portal:

1. Navigate to Work Centers > Guest Access > Portals & Components > Sponsor Portals.
2. Click Sponsor portal (default).

The Portal Settings pane appears, as shown in the figure below:

3. Click Portal test URL.

The Portal Test URL window is displayed.

 Note:

Clicking Portal test URL displays the Sponsor portal with a complicated URL
that can be sent to your sponsors. However, if you continue with the subsequent
steps, a simpler URL can be generated.

Sample Portal test URL from an ISE deployment:

https://ise.securitydemo.net:8443/sponsorportal/PortalSetup.action?portal=28981f
50-e96e-11e4-a30a-005056bf01c9

4. Close the Portal Test URL window as this was only to test its working.
5. In the Sponsor Settings and Customization window, click Portal Settings.

6. In the Fully qualified domain names (FQDN) and host names field, enter a friendly
Sponsor portal FQDN:

7. Scroll to the top and click Save.

8. You should now update your DNS Server to ensure that this friendly FQDN resolves to your ISE
IP address. For more information please see the section for Fully Qualified Domain Name
(FQDN) under Portal Settings for Sponsor Portals in the Cisco Identity Services Engine
Administrator Guide.

Configure Basic Portal Customization

 Note that this is an optional task. It is not critically necessary to get your system up and
running for Guest access. It is an optional process to help familiarize with the basic
customization options for your new Guest portal. If you are not interested in customizing
your portal, skip this procedure and continue to the Setting up a Well-Known
Certificate section of the Cisco Identity Services Engine Administrator Guide.

For more information about guest customization, see the Customize End-User Web
Portals section of the Cisco I, and the HowTo: ISE Web Portal Customization
Options section in the ISE Guest & Web Auth community page.

To customize a Guest portal, perform the following steps.

1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click the portal you are using (Hotspot, Self-Registered, or Sponsored) to edit that portal.

The active portal is indicated by a check mark in a green circle, as shown in the figure
below:

3. Click Portal Page Customization, as shown in the figure below:

ISE provides you with the advantage of basic customization built into the product. ISE
also makes it easy to see what changes you are making in real time. Notice that the top
of the window provides you with options to change logos, the banner, and main text
elements. You can also choose from built-in color themes. Depending on your portal
settings and portal type, you will see different options on the left side of the window. You
can tweak the text in the different areas too.
4. To change the theme colors of your portal, use a built-in Portal Theme or the Tweaks option,
as shown in the following figure:

5. After performing customization, preview the window by clicking Desktop Preview.

Note: Portal testing provides a real end-user experience and helps you validate a
certain configuration, without the need for a real endpoint or network access session.

6. Close the Desktop Preview window.

7. Click Save at the top of the window, as show in the figure below:
You have now completed basic customization of your Guest portal. You can do the
same with your Sponsor portal if you are using Sponsored Guest Access. To do this,
navigate to Work Centers > Guest Access > Portals & Components > Sponsor
Portals > Select the default portal, and follow the same steps you used to customize
your Guest portal.

Setting up a Well-Known Certificate

Note that this is an optional task. It is not required to get your system up and running for
guest access for basic testing, but is highly recommended. To ensure that your users
will not have to accept an invalid certificate when connecting to the Guest, Sponsor, or
Administrator portals via their web browser, use a certificate that has been signed by a
well-known Certificate Authority (CA). We recommend that you do not use self-signed
certificates.

In the example described in this section, a certificate from SSL.com is used as an

example of a provider that will work correctly with ISE. However, we do not recommend
any specific provider. We only recommend that before purchasing a certificate, you get
a test certificate from the CA to test with.
 Note: Each certificate provider may refer to a certificate type by different names.
It often helps to call the company, or use their online contact options to explain
what is needed in the SAN fields. Tell them that you are looking for a certificate
containing a wildcard and FQDN in the SAN field, and a FQDN in the CN= field.

For more information about wildcard certificates and certificates in general, see the
following section in these documents:

 Cisco Identity Services Engine Administrator Guide - Wildcard Certificate Support in Cisco
ISE

 MovingPackets.net article - When SSL Certificates Go Wild

 Aaron Woland’s Network World Blog - Wildcard certificates and how to use with ISE
 Aaron Woland’s - HowTo: Implement Cisco ISE and Server Side Certificates

Create a Certificate-Signing Request and Submit it to a Certificate Authority

The steps listed here show an example of how to set up a Unified Communications
Certificate (UCC) with a wildcard in SAN from SSL.com, which is a subordinate of
Comodo:

1. Navigate to Administration > System > Certificates > Certificate Signing Requests.
2. Click Generate Certificate Signing Requests (CSR).
3. Enter the values for generating a CSR, as shown in the following figure:
 Usage

o Certificate(s) will be used

for: Multi-use
o Allow Wildcard
Certificates: Checked

Subject

o Common
name: <yourdomain.com>
o Replace the other sections of the
subject with the information
pertaining to your organization.
o Subject Alternative Name (SAN)=
SAN DNS Name 1 =
<yourise.yourcompany.com>
SAN DNS Name 2 =
<*.yourcompany.com>
o Retain the default value for the last
two fields.

4. Click Generate.
The CSR is generated, as shown in the figure below:

5. Click Export to save the file

6. Open the file in a text editor.
7. Copy all the text from “---- BEGIN CERTIFICATE REQUEST-----“ through “-----END
CERTIFICATE REQUEST----.”
8. Paste the contents of the CSR into the certificate request of a chosen CA. The following figure
shows an example of the SSL.com portal:

9. Download the signed certificate.

Note: Some CAs might email the signed certificate to you. The resulting
download or email attachment is often in the form of a zip file that contains the
newly signed certificate and the public certificates of the CA. Save the digitally
signed certificate, root CA certificate, and other intermediate CA certificates (if
applicable) to the local system running your client browser in order to be
imported. For more information about importing, see the section below, Import
Certificate to the Trusted Certificate Store.

Import Certificates to the Trusted Certificate Store

This section shows you how to import the necessary certificates to ensure trusted client
and server communication. Along with the server certificate, ISE also presents the root
and intermediate (if required) certificates to the client when communicating.
 Note: Not all providers have intermediate certificates that are required to be
installed. Intermediate certificates come from the subordinate CAs. The example
provided here uses SSL.com, which is a subordinate of Comodo. Comodo is a
subordinate to the AddTrust root CA. Therefore, this example shows how to
import a root certificate as well as certificates for the two subordinates.

To import all three certificates, perform the following steps:

1. Navigate to Administration > System > Certificates > Trusted Certificates.

2. Click Import.

The Import a new Certificate into the Certificate Store pane is displayed, as shown
in the figure below:

o Click Browse
to select the
root CA
certificate.
o Enter
a Friendly
Name.
o Choose the
root
certificate
returned by
your CA.
o Under Trust
ed For,
check
the Trust for
Authenticati
on within
ISE check
box and
the Trust for
client
authenticati
on and
Syslog check
box.
o Check
the Validate
Certificate
Extensions c
heck box.
 o Enter
a Descriptio
n.
o Click Submit
.

3. Import all the CA certificates in the chain:

o Root CA: AddTrustExternalCARoot.crt
o Subordinate CA: SSLcomDVCA_2.crt
o Subordinate CA: USERTrustRSAAddTrustCA.crt

The values specified above are specific to this example. Otherwise, the values vary
according to your service provider's chain.

Bind the CA-Signed Certificate to the Signing Request

Now that you have received the digitally signed certificate from your CA, and imported
the CA certificates, the next step is to bind the certificate signed by the CA to the CSR,
from ISE. This pairs the certificate and private key that was used to generate the CSR.

1. Navigate to Administration > System > Certificates > Certificate Signing Requests.
2. Select the entry for your signing request.
3. Click Bind Certificate, as shown in the figure below:

4. Configure as follows:
 o Click Browse to
choose the CA-
signed
certificate.
o Specify
a Friendly
Name for the
certificate.
o Under Usage,
check
the Admin, EAP
Authentication,
and Portal chec
k boxes.
o From the Portal
Group
tag drop-down
list,
choose Default
Portal
Certificate
Group.
o Click Submit to
bind the CA-
signed
certificate.
Figure x Bind Signed Certificate

5. After you click Submit, the system will restart and be inaccessible for about 5 minutes.

This completes the task of setting up ISE with a well-known certificate for ISE. For more
information about working with certificates, see the Managing Certificates section of
the Cisco Identity Services Enginer Administration Guide.

Operate
Validation of flows
After configuring your ISE server, use the following steps to validate your deployment:
 Testing Web Portals
Note: For guest flows, you can use the Portal Test URL at the top of the Portal
Settings window to quickly test the flow, without having any network device or
real clients.

1. Navigate to Work Centers > Guest Access > Portal & Components > Guest Portals.
2. Choose the Guest portal you want to test.
3. Click the associated portal test URL.

If, for some reason, your portal does not load, here are a few tips:

 The test portal always opens up with ISE’s real IP address. If the ISE node is behind a NAT
router, its public IP address must be replaced in the test URL.
 If DNS is not resolving correctly, you can replace the ISE’s FQDN with IP address.

From this point, you can go through the complete flow. Note that the final success
redirection to a static or originating URL needs a real session for this to work
completely.

Clearing Guest Endpoints

If, however, you are going to perform different flows with the same device, you should
do the following between each flow test:

1. Turn off the Wi-Fi on the device, go to the device settings and click Forget SSID if you have
multiple profiles set up.
2. On the WLC, clear the session for the device by navigating to Monitor > Clients.
3. On ISE, navigate to Context Visibility > Endpoints and remove guest devices.

If you want to switch between a hotspot portal and a credentialed portal using the same
authorization rules, you can do so by going into your Authorization profile and switching
between the two.
 Monitoring Guest Connections

For Hot Spot Guest Flow

1. Connect to your Guest SSID.

2. Open a browser if it does not auto launch. (Apple iOS devices should also auto launch.)
3. Accept the AUP via the Hotspot Portal.
4. Access the internet.
5. In ISE, navigate to Operations > RADIUS > Live Logs.

Here is an example of what you will see when going through a flow with an endpoint.

Look at the image below, from bottom to top, the flow the device or user goes through is
depicted:

6. Device connects to SSID and is authorized to be redirected to the webauth portal because the
mac address is unknown.
7. The user accepts the AUP or logs in to the portal, and the guest user device is added to the
GuestEndpoint group.
8. ISE initiates CoA for reauthentication.
9. The device is authorized (granted access) based off the endpoint group and permitted access.

For Self-Registered Guest Flow

1. Connect to your Guest SSID.

2. Open a browser if it does not auto launch. (Apple iOS devices should also auto launch.)
3. Click the Or register for guest access link to register for guest access.

4. Enter information, if needed, and then click Register.

5. Click Sign-on.

Note that if you did not enable sign-on from the Self-Registration Success window,
you should copy the username and password information to enter in the same login
window.

6. Access the internet.

The following procedure shows how a guest credentialed access will present itself. Look
at the image, from bottom to top, the flow the device or user goes through is depicted:

1. Device connects to SSID and is authorized to be redirected to the webauth portal because the
mac address is unknown.
2. The user logs in to the portal, and the guest user device is added to the GuestEndpoint group.
3. ISE initiates CoA for reauthentication
4. The user is authorized and permitted access per the guest flow.

Viewing the Guest Users List

Access without Sponsor Portal

Navigate to Work Centers > Guest Access > Manage Accounts.

The Managed Accounts is reserved for administrators to quickly see what is going on
with guests. Note that we do not recommend this to manage guests and sponsors. It
should be used only to quickly access guest listing, mainly for those systems that do not
use a Sponsor portal. We, however, recommend that you set up an easy-to-use
Sponsor portal.
 Access with Sponsor Portal

1. Using a machine in the internal network, connect to the Sponsor Portal via the Sponsor portal
easy FQDN or use the Portal Test URL for Sponsor portal access. This is explained in in
the Setup ISE Sponsor Portal FQDN Based Access section.
2. Log in with a sponsor account.
3. Create a guest account.
4. Using another client, connect to the Guest SSID.
5. Log in with the newly created guest account.
 6. Configure New Cisco ISE 2.4 Install
for Use as TACACS+ Server
Now that we have functioning Cisco ISE (Identity Services Engine) 2.4 virtual appliance install,
it’s time to configure it to act as a TACACS+ server.

The first thing I recommend anyone do with a new Cisco ISE install is disable the default
password expiration setting. By default it’s set to 45 days. It’s no fun to wake up and find you’ve
been locked out of your own ISE server and the steps to reset the password aren’t fun either.

1. After logging into your Cisco ISE server navigate to Administration -> System -> Admin Access ->
Password Policy -> Password Lifetime and uncheck the box next to Administrator passwords expire.

2. Click Save.

Of course if you want to have the password expire, leave it checked and make sure to check the
box to send an email reminder before it expires.

Create Active Directory Groups

To control the level of access users have when logging into networking equipment we need some
groups created in Active Directory. For my setup I’m going to create two groups; ISE Network
Infrastructure and ISE Network Operations.

In my environment the Infrastructure Team manages the networking equipment. The Operations
Team mostly manages things at the server application level. It’s still handy for the Operations
Team to be able to log into networking equipment and see how things are configured but we
don’t want them making any changes.
The goal is to give the Infrastructure Team full access to networking equipment and limit the
Operations Team to “show” commands.

Verify DNS is Configured

For ISE to work properly with AD you need to make sure that you set your domain name and
DNS servers during the initial setup. You can verify these settings with the console (or SSH)
command:

show run | include name

Join ISE to Active Directory Domain

The next thing we need to do is get ISE joined to the Active Directory Domain. This is what will
allow ISE to match on the AD groups we created earlier.
1. Navigate to Administration -> External Identity Sources -> Active Directory and click on Add.

2. Enter your domain name in both the Join Point Name and Active Directory Domain boxes.

Join Point Name is essential a display name for your AD join. You can have multiple AD joins
and the Join Point Name helps you tell them apart. In this setup we’re only using one domain so
it doesn’t really matter.

3. Click the Submit button.

4. Click Yes to join all ISE nodes to this Active Directory domain when prompted.

Here is another “it doesn’t really matter” situation since we are only configuring one ISE node in
this setup.
5. Enter the credentials you use when joining machines to your domain.

You could also check the box to specify the organizational unit you want the ISE object to end
up in. In my setup I’m not going to do this. I’ll simply move the object in AD if I decide I want it
somewhere specific.

As for the “Store Credentials” box. You would use this if you wanted to save the credentials for
joining other nodes. I don’t have any other nodes to join so I’m not going to check this box.

6. Click OK.

You should now see the status of your Join Point change to Operational and list your domain
controller.

Add Active Directory Groups to ISE

Now we are going to add the AD security groups we created earlier to ISE.
1. At the same screen you were at to join AD, click the Groups Tab.

2. Click Add -> Select Groups from Directory.

3. Search for the groups you created and check the boxes in front of them.

In my case they were ISE Network Infrastructure and ISE Network Operations so I put “ISE*” in
the Name Filter box to find only groups starting with ISE.

4. Click Ok.

This next step is optional but I like to do it because it makes it easier to log into devices. You
will be able to log into your networking devices without having to specify the entire FQDN.
5. In the same window you were in to search the groups click the Advanced Settings tab and select the
“Search in all the Whitelisted Domains” section” radio button.

6. Click Save.

Create an Identity Source Sequence

The next step is to create and Identity Source Sequence. This will tell ISE what order of
databases to search for a user account when authenticating to a device.

1. Navigate to Administration -> Identity Management -> Identity Source Sequences -> New.

2. Give you Identity Source Sequence a Name.

3. Move your domain and the Internal Users group over to Selected from Available.
4. Select the “Treat as if the user was not found” radio button.

The reason I choose the Treat as if the user was not found button is to allow using a local user
created on the ISE server when active directory cannot be contacted. This prevents you from
 having to use the local account on the network device in cases where AD is unavailable. It’s not
necessary but it’s another layer of protection.

5. Click Submit.

Enabling TACACS
The first thing we need to do is make sure the Device Admin Services is running. To do this:

1. Navigate to Administration -> System -> Deployment.

2. Check the box next to your ISE server and click Edit.

3. Check the box next to Enable Device Admin Service.

4. Click Save.

Adding Devices to ISE

 Now that we have enabled TACACS we need to add some network devices. It’s up to you how
you want to add devices. You can add them by individually, by subnet, or set up a profile to
match all devices.

I’m going to add my devices individually.

1. Navigate to Work Centers -> Device Administration -> Network Resources -> Network Devices and click
Add.

2. Fill in the Name and IP.

In my case I’m using a 4506 chassis switch with a sup8l-e supervisor card for testing so I’m
going to leave the device profile as Cisco
3. Check the box next to TACACS and enter the shared secret you wish to use with that
device.

The checkbox for Enable Single Connect Mode is optional but it’s a good idea to use it if you
have a stable network connection between your devices and the ISE server. What this setting
does, in very basic terms, is keep a single tcp connection open between the device and the ISE
server while authenticated to the device. Without this option the server will open a new
connection for every subsequent TACACS+ request from the device. This means less network
overhead and response times.

Configuring TACACS Command Sets

Now that we’ve added a network device we need to configure some command sets. Command
Sets control what commands an authenticated user can enter into a network device.

I want to configure a set that allows my ISE Network Infrastructure group to have full access to
all commands within a device and another set that only allows “show” commands for my ISE
Network Operations group.
1. Navigate to Work Centers -> Device Administration -> Policy Elements -> Results -> TACACS
Command Sets and click Add.

2. Type Permit All in the Name box and check the “Permit any command that is not listed below” box. Do
not add anything to the list below that.

By not specifying anything in the list below this rule is basically saying allow all commands.
This will be the command set used for the ISE Network Infrastructure group later.
3. Add another policy set and name it Show Only. Then click Add and select Permit under Grant and type
show* in the command box.

Within the Command box you can use * as a wild card. That means show* will allow any form
of show command. If you want to limit the arguments after show you need to know that * is not
a wildcard in that box. The arguments box uses REGEX so you would type .* for wild card
statements. For example v.* would allow version and any other argument starting with a V.

4. Click submit.

We should now have a total of 3 command sets, the default Deny All and our Permit All and
Show Only sets.

Configuring TACACS Authentication Policy

Now we need to tell ISE what Identity Source Sequence to use and then define the
Authentication Policies that will give our AD groups the right command sets.

1. Navigate to Work Centers -> Device Administration -> Device Admin Policy Sets and click on the
Default policy set.
 This one is a little tricky. You have to click the right arrow (or sideways carrot) icon. Also, if you
prefer, you can create a new policy set instead of editing the default. This is meant to be a simple
TACACS setup so I opted to just make the changes to the default policy set.

2. Click the down arrow (or upside down carrot) to expand Authentication Policy and change the Use box to
the AD_Internal Identity Source Sequence we created earlier.

3. Expand Authorization Policy and click the + icon.

4. Give your policy a name. In my case it’s Allow All Infrastructure Group. Set the command set to Permit
All. Set the Shell Profile to Default Shell Profile (we aren’t going to worry about shell profiles for now).
Then, click the + icon.
5. In the editor that opens click into the Click to add an attribute box and select “Yourdomain.com External
Groups” and then choose ISE Network Infrastructure from the List in the box to the right of Equals.

6. Click Use.

7. Repeat 3-6 for the Operations Group except change the command set to Show Only and give it a unique
Rule Name.

8. Click Save.

Configuring the Networking Equipment for

TACACS+ through ISE
We’ve now configured ISE well enough to act as a basic TACACS+ server. Now we need to tell
our networking equipment to look to the ISE server for authentication requests.

I’m going to assume that if you’re working with Cisco ISE then you know how to configure
AAA on a Cisco device. Because of that I’m not going to cover this in detail. What I will show
are the settings I applied to get this working on my 4506.

aaa new-model
!
aaa group server tacacs+ default
server name TAC_ISE
!
aaa authentication login default local group tacacs+
aaa authentication login console local
aaa authentication enable default group tacacs+ enable
aaa authorization config-commands
aaa authorization exec default local group tacacs+
aaa authorization commands 15 default local group tacacs+
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
tacacs server TAC_ISE
address ipv4 X.X.X.X
key mysharedsecret
!
line con 0
privilege level 15
login authentication console
line vty 0 4
privilege level 15
transport input ssh
line vty 5 15
privilege level 15
transport input ssh
!

This configuration allows local authentication which falls back to tacacs+ if the credentials
entered aren’t in the local database. It also requires local credentials at the console. I did this to
allow using either local or tacacs+ credentials through SSH and local only at the console.

A more secure setup would be to have group tacacs+ first before local on the auth lines which
would prevent use of a local account when your ISE server is online and would log all login
attempts to the ISE server.

Checking the ISE Logs for TACACS Results

If you navigate to Operations -> TACACS -> Live Logs you can see your TACACS login
events. In my case I am part of the Infrastructure group that has full access to the networking
equipment. You can see in the below screenshot that I was successfully authenticated and
Authorization Policy given to me was the Allow All Infrastructure.
When I submitted show run and conf t commands they worked properly.

I removed myself from the ISE Network Infrastructure Group and added myself to the ISE
Network Operations group in AD and ISE reported appropriately.

When I tried to submit a conf t command my result was “Command authorization failed.”
Success.

Finally I removed myself from the Operations group and made sure I wasn’t in the Infrastructure
group and ISE properly rejected my authentication request to the switch.
7. Central Web Authentication on the
WLC and ISE Configuration Example
Introduction
This document describes a configuration example that is used in order to complete Central
Web Authentication (CWA) on the Wireless LAN Controller (WLC).

It is superseded by the more complete Guest deployment guide available here :

https://communities.cisco.com/docs/DOC-77590

Prerequisites
Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

 Cisco Identity Services Engine Software Release 2.0

 Cisco WLC Software Release 8.2.141.0

Configure
The first method of web authentication is local web authentication. In this case, the WLC
redirects the HTTP traffic to an internal or external server where the user is prompted to
authenticate. The WLC then fetches the credentials (sent back via an HTTP GET request in the
case of an external server) and makes a RADIUS authentication. In the case of a guest user, an
external server (such as Identity Services Engine (ISE) or NAC Guest Server (NGS)) is required
because the portal provides features such as device registering and self-provisioning. The flow
includes these steps:

1. The user associates to the web authentication Service Set Identifier (SSID).

2. The user opens the browser.

3. The WLC redirects to the guest portal (such as ISE or NGS) as soon as a URL is entered.

4. The user authenticates on the portal.

 5. The guest portal redirects back to the WLC with the credentials entered.

6. The WLC authenticates the guest user via RADIUS.

7. The WLC redirects back to the original URL.

This flow includes several redirections. The new approach is to use CWA. This method works
with ISE (versions later than 1.1) and WLC (versions later than 7.2). The flow includes these
steps:

1. The user associates to the web authentication SSID, which is in fact open+macfiltering and no
layer 3 security.

2. The user opens the browser.

3. The WLC redirects to the guest portal.

4. The user authenticates on the portal.

5. The ISE sends a RADIUS Change of Authorization (CoA - UDP Port 1700) to indicate to the
controller that the user is valid, and eventually pushes RADIUS attributes such as the Access
Control List (ACL).

6. The user is prompted to retry the original URL.

The setup used is:

WLC Configuration

The WLC configuration is fairly straightforward. A trick is used (same as on switches) in order
to obtain the dynamic authentication URL from the ISE (since it uses Change of Authorization
(CoA), a session must be created and the session ID is part of the URL). The SSID is configured
in order to use MAC filtering. The ISE is configured in order to return an access-accept even if
the MAC address is not found, so that it sends the redirection URL for all users.

In addition to this, ISE Network Admission Control (NAC) and Authentication, Authorization,
and Accounting (AAA) Override must be enabled. The ISE NAC allows the ISE to send a CoA
request that indicates that the user is now authenticated and is able to access the network. It is
also used for posture assessment, in which case the ISE changes the user profile based on the
posture result.

Ensure that the RADIUS server has "Support for CoA" enabled, which is by default.
The final step is to create a redirect ACL. This ACL is referenced in the access-accept of the ISE
and defines what traffic should be redirected (denied by the ACL) and what traffic should not be
redirected (permitted by the ACL). Here you just prevent from redirection traffic towards the
ISE. You might want to be more specific and only prevent traffic to/from the ISE on port 8443
(guest portal), but still redirect if a user tries to access the ISE on port 80/443.
Note: Earlier versions of WLC software such as 7.2 or 7.3 did not require you to specify Domain
Name System (DNS), but later code versions require you to permit DNS traffic on that redirect
ACL.

Configuration is now complete on the WLC.

ISE Configuration
Create the Authorization Profile

On the ISE, the authorization profile must be created. Then, the authentication and authorization
policies are configured. The WLC should already be configured as a network device.

In the authorization profile, enter the name of the ACL created earlier on the WLC.

1. Click Policy, and then click Policy Elements.

2. Click Results.

3. Expand Authorization, and then click Authorization profile.

4. Click the Add button in order to create a new authorization profile for central webauth.

5. In the Name field, enter a name for the profile. This example uses WLC_CWA.

6. Choose ACCESS_ACCEPT from the Access Type drop-down list.

7. Check the Web Redirection check box, and choose Centralized Web Auth from the drop-down
list.

8. In the ACL field, enter the name of the ACL on the switch that defines the traffic to be
redirected. This example uses cwa_redirect.
 9. In the value field, one can choose Sponsored Guest Portal or Self-Registered Guest Portal from
the drop-down list. In sponsored guest portal, sponsors create guest accounts, and guests access
the network using their assigned username and password while in self-registration guest portal,
guests are allowed to create their own accounts and access the network using their assigned
username and password. This example uses Sponsored Guest Portal.

Create an Authentication Rule

Ensure that the ISE accepts all of the MAC authentications from the WLC and make sure it will
pursue authentication even if the user is not found.

Under the Policy menu, click Authentication.

The next image shows an example of how to configure the authentication policy rule. In this
example, a rule is configured that triggers when MAB is detected.

1. Enter a name for your authentication rule. This example uses MAB, which already exists by
default on ISE Version 1.2.

2. Select the plus (+) icon in the If condition field.

3. Choose Compound condition, and then choose Wired_MAB OR Wireless_MAB.

4. Click the arrow located next to and ... in order to expand the rule further.
 5. Click the + icon in the Identity Source field, and choose Internal endpoints.

6. Choose Continue from the If user not found drop-down list.

Note: Now there is a MAB authentication rule created on the ISE by default.

Create an Authorization Policy

Configure the authorization policy. One important point to understand is that there are two
authentications/authorizations:

 The first is when the user associates to the SSID ("CWA" in this case) and the CWA profile is
returned.
In this example Airespace-Wlan-Id is used as a condition. When a client connects to the SSID,
the RADIUS access request to ISE contains the Airespace-WLAN-ID attribute. This attribute is
used to make policy decisions in ISE. So when an unknown client connects to SSID CWA, ISE
sends an acceess-accept with redirect URL (web portal) and ACL. Use of the Airespace-Wlan-Id
rule ensures that the portal page is presented to users that only connect to the CWA SSID.

 The second is when the user authenticates on the web portal. This one matches the default rule
(internal users) in this configuration (it can be configured in order to meet your requirements). It
is important that the authorization part does not match the CWA profile again. Otherwise, there
will be a redirection loop. The Network Access:UseCase Equals Guest Flow attribute can be
used in order to match this second authentication. The result looks like this:
Complete these steps in order to create the authorization rules as shown in the previous images:

1. Create a new rule, and enter a name. This example uses Guest Redirection.

2. Click the plus (+) icon in the condition field, and choose to create a new condition.

3. Expand the Expression drop-down list.

4. Choose Airespace, and expand it.

5. Click Airespace-Wlan-Id--[1], and choose the Equals operator.

6. Enter the WLAN ID in the right-hand field, in this example 1.

7. On the General Authorization page, choose WLC_CWA (Authorization Profile) in the field to the
right of the word then.

This step allows the ISE to continue even though the user (or the MAC address) is not known
when connected to CWA SSID and present them with the login portal.

8. Click the Actions button located at the end of the Guest Redirection rule, and choose to insert a
new rule before it.

Note: It is very important that this new rule comes before the Guest Redirection rule.

9. Enter a name for the new rule. This example uses Guest Portal Auth.

10. In the condition field, click the plus (+) icon, and choose to create a new condition.

11. Choose Network Access, and click UseCase.

12. Choose Equals as the operator.

 13. Choose GuestFlow as the right operand.

14. On the authorization page, click the plus (+) icon (located next to then) in order to choose a
result for your rule.

You can choose a Permit Access option or create a custom profile in order to return the VLAN or
attributes that you like. Note that on top of If GuestFlow, you can add more conditions in order
to return various authz profiles based on the user group. As mentioned in Step 7, this Guest
Portal Auth rule matches upon the second MAC address authentication initiated after the
successful portal login and after ISE sent a CoA in order to reauthenticate the client. The
difference with this second authentication is that, instead of coming to ISE with simply its MAC
address, ISE remembers the username given in the portal. You can make this authorization rule
take into account the credentials entered a few milliseconds before in the guest portal.

Note: In a multi controller environment the WLAN-ID should be the same across the WLCs. If
one does not want to use the Airespace-Wlan-Id attribute as a condition, then it is better to match
Wireless_MAB (Built-in condition) requests.

Enable the IP Renewal (Optional - not recommended)

If you assign a VLAN, the final step is for the client PC to renew its IP address. This step is
achieved by the guest portal for Windows clients. If you did not set a VLAN for the 2nd AUTH
rule earlier, you can skip this step. This is not a recommended design as changing the client vlan
after it already got an ip address will disrupt connectivity, some clients might wrongly react to it
and it requires elevated Windows privileges to work fine.

If you assigned a VLAN, complete these steps in order to enable IP renewal:

1. Click Guest Access, and then click Configure.

2. Click Guest Portals.

3. Click Sponsored Guest Portal (used in this example), and then expand VLAN DHCP Release Page
Settings.

4. Click the VLAN DHCP Release check box.

 Note: This option works only for Windows clients.

Anchor-Foreign Scenario

This setup can also work with the auto-anchor feature of the WLCs. The only catch is that since
this web authentication method is Layer 2, you have to be aware that it will be the foreign WLC
that does all of the RADIUS work. Only the foreign WLC contacts the ISE, and the redirection
ACL must be present also on the foreign WLC.

Just like in other scenarios, the foreign WLC quickly shows the client to be in the RUN state,
which is not entirely true. It simply means that traffic is sent to the anchor from there. The real
client state can be seen on the anchor where it should display CENTRAL_WEBAUTH_REQD.

Here is the flow in an anchor-foreign setup:

1. The client connects to the SSID on the foreign WLC. The foreign WLC contacts the ISE server for
MAB. ISE sends access-accept with the redirect URL and redirect ACL to the foreign.
2. Now the client is anchored to the anchor WLC where it gets an IP address and is put in
CENTRAL_WEBAUTH_REQD.
3. When the client tries to access a website, the anchor WLC redirects the client to the ISE portal
page. The client is presented with the login page.
4. After successful login, ISE sends a CoA to the foreign WLC.
5. The foreign WLC contacts the anchor WLC to let it know to put the client in the RUN state.
6. All the client traffic is forwarded from foreign to anchor, and goes out of the anchor WLC.

The firewall ports which are required to allow communication between the WLC and ISE are:

 UDP:1645, 1812 (RADIUS Authentication)

 UDP:1646, 1813 (RADIUS Accounting)
 UDP:1700 (RADIUS CoA)
 TCP:8443 Guest Portal or 8905 if you have Posturing.

Note: The anchor-foreign setup with Central Web Authentication (CWA) only works in Releases
7.3 or later.
Note: Due to Cisco bug ID CSCul83594 , you cannot run accounting on both anchor and
foreign because it causes the profiling to become inaccurate due to a potential lack of IP-to-MAC
binding. It also creates many issues with the session ID for guest portals. If you desire to
configure accounting, then configure it on the foreign controller. Note that this should not be the
case anymore starting 8.6 WLC software where the session id will be shared between anchor and
foreign controllers and accounting will then be possible to enable on both.

Verify
Use this section in order to confirm that your configuration works properly.

1. Once the user is associated to the SSID, WLC contacts the ISE (as MAC filtering is configured). ISE
has been configured to return access accept with redirect URL and ACL. This is the first
authentication.

The client details in the WLC show that the redirection URL and ACL are applied.

In the WLC client and AAA all debug, you can see access accept with the redirect URL
and ACL sent from the ISE.

*radiusTransportThread: 5c:c5:d4:b1:09:95 Access-Accept received from

RADIUS server 10.48.39.161
*radiusTransportThread: AVP[04] Cisco / Url-Redirect-
Acl.................cwa_redirect (12 bytes)
*radiusTransportThread: AVP[05] Cisco / Url-
Redirect.....................DATA (177 bytes)

*apfReceiveTask: 5c:c5:d4:b1:09:95 Redirect URL received for client

from RADIUS.
Client will be moved to WebAuth_Reqd state to facilitate redirection.
Skip web-auth Flag = 0
*apfReceiveTask: 5c:c5:d4:b1:09:95 AAA Override Url-Redirect-Acl
'cwa_redirect'
 The same thing can also be verified in the ISE. Choose Operations > Radius livelogs.
Click the detail for that MAC.

You can see that for the first authentication (MAC filtering) ISE returns the AuthZ profile
WLC_CWA as it hits the authentication rule MAB and authz policy Guest
Redirection.

2. At this point the client gets an IP address. Now the client is in CENTRAL_WEB_AUTH state.
When any address is opened on the client, the browser is redirected to the ISE. Ensure that the
DNS is set up correctly.
3. Once the correct credentials are entered, network access is granted. This is the second
authentication.

When the credentials are entered, ISE authenticates the client and sends the CoA.

On the WLC this can be seen in AAA all debugs.

*radiusCoASupportTransportThread: audit session ID recieved in CoA =

0a30279c0000003b58887c51
*radiusCoASupportTransportThread: Received a 'CoA-Request' from
10.48.39.161

*radiusCoASupportTransportThread: CoA - Received IP Address :

10.48.39.156
*radiusCoASupportTransportThread: 5c:c5:d4:b1:09:95 Calling-Station-Id
---> 5c:c5:d4:b1:09:95
*radiusCoASupportTransportThread: Handling a valid 'CoA-Request'
regarding station 5c:c5:d4:b1:09:95
*radiusCoASupportTransportThread: 5c:c5:d4:b1:09:95 Reauthenticating
 station 5c:c5:d4:b1:09:95
*radiusCoASupportTransportThread: Sent a 'CoA-Ack' to 10.48.39.161

4. After this the client is reauthenticated and granted access to the network.

5. On the controller, the Policy Manager state and RADIUS NAC state changes from
CENTRAL_WEB_AUTH to RUN.

Note: In Release 7.2 or earlier, the state CENTRAL_WEB_AUTH was called

POSTURE_REQD.

Note that the type of CoA returned by ISE evolved across versions. ISE 2.0 will request the
WLC to re-run the authentication rather than plainly disconnect the client.

Example of ISE 2.0 CoA request :

The WLC will then not send a disassociation frame to the client and will run a radius
authentication again and apply the new result transparently to the client.

However, things are still different if a PSK is in use. Since 8.3, the WLC supports setting a WPA
pre-shared key on a CWA SSID. In that kind of situation, upon reception of the same CoA from
ISE as above, the WLC will have to trigger a new WPA key exchange again. Therefore in case
of PSK, the WLC will have to send a disassociate frame to the client which will have to
reconnect. In classical non-PSK scenarios, the WLC will not send a disassociate frame to the
client and will simply apply the new authorization result. However an "association response" will
be still sent ot the client although no "association request" was ever received from the client,
which might seem curious when analyzing sniffer traces.

Troubleshoot
Complete these steps in order to troubleshoot or isolate a CWA problem:

1. Enter the debug client <mac address of client> command on the controller and monitor in order
to determine whether the client reaches the CENTRAL_WEBAUTH_REQD state. A common
problem is observed when the ISE returns a redirect ACL that does not exist (or is not properly
input) on the WLC. If this is the case, then the client is deauthenticated once the
CENTRAL_WEBAUTH_REQD state is reached, which causes the process to begin again.

2. If the correct client state can be reached, then navigate to monitor > clients on the WLC web
GUI and verify that the correct redirect ACL and URL are applied for the client.

3. Verify that the correct DNS is used. The client should have the ability to resolve internet
websites and the ISE hostname. You can verify this via nslookup.

4. Verify that all authentication steps occur on the ISE:

o The MAC authentication should occur first, to which CWA attributes are returned.

o The portal login authentication occurs.

o The dynamic authorization occurs.

o The final authentication is a MAC authentication that shows the portal username on the
ISE, to which the final authorization results are returned (such as the final VLAN and
ACL).
8. ISE and Catalyst 9800 Series Integration
Guide
Introduction

Cisco Catalyst 9800 (C9800) series wireless controller running 16.10.1 has feature parity with
AireOS 8.8, which means that all the feature that works between AireOS & ISE also works
between C9800 & ISE. However, the configuration of C9800 is different from AireOS and this
document shows how to configure C9800 to work with ISE. For more information on Cisco
Catalyst 9800 series, please go to: https://www.cisco.com/c/en/us/products/wireless/catalyst-
9800-series-wireless-controllers/index.html

Setup
Components used:
WLC: Catalyst 9800-CL running 16.10.1
AP: Cisco 1815i

ISE: 2.4p3 (Previous versions of ISE should work with C9800 as well)

The document does not cover details on how to bootstrap the ISE, C9800, and AP. The
document assumes the C9800 is accessible from the management PC and AP is associated to the
C9800. The document also assumes underlying network elements are already configured, which
includes, VLANs, SVIs, Subnets, DHCP, routing, and DNS. The following diagram and table
shows settings for the components.

C9800 IP 192.168.201.61

ISE IP 192.168.201.93

DNS IP 192.168.201.71

OPEN SSID OPEN

SECURE SSID SECURE

Guest VLAN 30

Guest Subnet 192.168.30.0/24

User VLAN 10

User Subnet 192.168.10.0/24

Notes:
  If static ACL needs to be applied to a session, use AireSpace-ACL-Name (6) attribute to send
down a ACL name. The ACL needs to be pre-created on C9800
 C9800 supports dACL for central switching. Support for dACL requires use of 'default' as
authorization list name. See authorization list section for more information
 If dVLAN needs to be applied to a session, use AireSpace-VLAN-Name (5) attribute to send down
a VLAN name/ID. The VLAN needs to be pre-created on C9800. Alternatively standard RADIUS 3
tuple attributes can be used for VLAN assignment using VLAN name/ID
 Redirect ACL follows Catalyst IOS syntax instead of AireOS syntax. So permit statement means
the matching traffic is redirected, while deny means it will be allowed without redirect
 With local mode, unlike AireOS, DNS ACL entries are not tied to the redirect ACL. URL entries
needs to be defined in the URL Filters and called upon via separate RADIUS attribute during the
authentication. More information on this at the end of the document on ISE section.
 With FlexConnect mode, URL filter is tied to the redirect ACL within the flex profile, so URL filter
does not need to be called upon via separate RADIUS attribute

Catalyst 9800 Configuration

Following diagram shows the C9800 configuration at a high level. Each box represents
individual configuration profile with relevant options shown and how each profile feeds into
other profiles to make a working configuration. The bullet points within the profile that are in
bold represents sub profile being fed into the profile. It also includes the suggested order to
create the profiles that maps to the main section of the document.
Steps 1 - 3: Define AAA
1. Go to Configuration > Security > AAA > Servers / Groups > Servers, Click Add
Enter following information (Any configuration not defined in the table assumes default
settings):

Name ISE01

IP 192.168.201.93

Key ***** (Match with ISE)

Support for CoA Checked

2. Click Server Groups, Click Add

Enter following information:

Name ISE

Available Servers ISE01

3. Go to Configuration > Security > AAA > AAA Method List > Authentication, Click Add
Create Authentication list using following information that will be used for both OPEN SSID and
SECURE SSID:

Name default

Type dot1x

Group-Type Group

Available Server Groups ISE

4. Note: If clients are failing to associate and authentication request does not show up on
ISE Live Log, try setting the authentication list name to 'default' as shown above.
5. Go to Configuration > Security > AAA > AAA Method List > Authorization, Click
Add
6. Enter following information for AAA Authorization list that will be shared for both SSIDs:

Name default

Type Network

Group-Type Group

Available Server Groups ISE

 7. Note: The Authorization name 'default' is significant here since there is no Authorization list that
can be defined within the 802.1X WLAN. By using 'default' as name, C9800 can use the ISE to get
additional authorization details such as for dACL operation. If default authorization list cannot
be used or desired, then named authorization can be created and can be referenced via RADIUS
server as a Cisco VSA. The Cisco VSA to use is 'Method-List={authorization-method-list}', which
can be configured in ISE advanced Attribute Settings. Please see examples at the end of the
document.
8. Go to Configuration > Security > AAA > AAA Method List > Accounting, Click Add
9. Enter following information for AAA Authorization list that will be shared for both SSIDs:

Name default

Type Identity

Available Server Groups ISE

Step 4: Create Webauth Parameter Map (Required for

BYOD)
This will only be used in the SECURE SSID to suppress Apple CNA (AKA mini browser) from
popping up upon association to the WLAN. This is required as the Apple CNA is unable to fulfill
the BYOD onboarding flow.

1. Go to Configuration > Security > Webauth > Webauth Parameter Map, Click Add
2. Enter Name ‘Captive-Bypass-Portal, Click Apply to Device
3. Click ‘Captive-Bypass-Portal’ parameter map from the list
4. Check Captive Bypass Portal, Click Update & Apply

Step 5: Create VLANs

1. Go to Configuration > Layer 2 > VLAN > VLAN, Click Add
2. Add two VLANs using following table for User VLAN and Guest VLAN. These VLANs will be
mapped to SECURE SSID and OPEN SSID respectively using policy profiles and tags:

VLAN ID 10 30

Name User Guest

State Activated Activated

 Port Members Gi2 Gi2

3.

4. Click Save & Apply to Device

Step 6: Create WLANs

1. Go to Configuration > Tags & Profiles > WLANs, Click Add
2. Add WLANs using following table for OPEN WLAN and SECURE WLAN. These WLANs will be
mapped to the AP using tags (Any configuration not defined in the table assumes default
settings):

General Profile Name OPEN SECURE

SSID OPEN SECURE

Status Enabled Enabled

Security > Layer 2 Layer 2 Security Mode None WPA + WPA2

MAC Filtering Enabled

Authorization List default

Security > Layer 3 Webauth Parameter Map Captive-Bypass-Portal

Security > AAA Authentication List default default

3. Note: There is no reference to Authorization List for 'SECURE' SSID. This is not an issue for AAA
override operation that applies authorization directly from RADIUS ACCESS-ACCEPT response.
However, this is an issue for applying dACL as it requires additional RADIUS communication
which requires authorization list. To address this issue, either use special name 'default' as
authorization list as configured above or configure ISE to send Cisco VSA 'Method-
List={authorization-method-list}' with ACCESS-ACCEPT when dACL is used. See ISE section below
for more information.
4. Click Save & Apply to Device
Step 7: Create Policy Profiles
1. Go to Configuration > Tags & Profiles > Policy, Click Add
2. Add Policy Profiles for both WLANs using following table. Policy profile covers device sensor,
default VLAN, CoA, and RADIUS Accounting. Since VLANs are different, two profiles are created
one for each WLAN. These profiles will be mapped to the WLANs using tags (Any configuration
not defined in the table assumes default settings):

General Name Guest User

Status Enabled Enabled

Access Policies HTTP TLV Caching Checked Checked

RADIUS Profiling Checked Checked

DHCP TLV Caching Checked Checked

VLAN/VLAN Group Guest User

Advanced Allow AAA Override Checked Checked

NAC State Checked Checked

Accounting List default default

3. Click Save & Apply to Device

Step 8: Create Policy Tag

1. Go to Configuration > Tags & Profiles > Tags, under Policy Click Add
2. Enter Name: ISE Enabled
3. Within the 'ISE Enabled' Tag window, click Add to map following WLANs to matching policy
profiles. This ties the WLAN to the respective Policy Profile.

WLAN Profile Policy Profile

OPEN Guest

SECURE User
 4.
5. Click Save & Apply to Device

Step 9: Assign Policy Tag to AP

Finally, apply the tag to the AP. This section shows instructions on tying it to a single AP. Using
Advanced Wireless Setup Wizard on C9800, same tag can be applied to multiple APs at the
same time.

1. Go to Configuration > Wireless > Access Points

2. Click on the AP Name or MAC address
3. Under General > Tags, Select 'ISE Enabled'

4. Click Update & Apply to Device

Step 10a: Create Redirect ACL for Guest flow

1. Go to Configuration > Security > ACL, Click Add
 2. Use ACL Name: ACL_WEBAUTH_REDIRECT
3. For ACL Type, select IPv4 Extended
4. Enter following rules in the ACL for Guest only access redirect ACL

Sequence Action Source IP Destination IP Protocol Source Port Destination Port

10 deny any 192.168.201.93 tcp eq 8443

20 deny any 192.168.201.71 udp eq domain (53)

30 permit any any tcp eq www (80)

5. Click Save & Apply to Device

Step 10b: Create Redirect ACL for BYOD flow

1. Enter following rules in the ACL for Guest and BYOD (Sequence 20 is needed for any endpoints
using Network Setup Assistant for BYOD)

Sequence Action Source IP Destination IP Protocol Source Port Destination Port

10 deny any 192.168.201.93 tcp eq 8443

20 deny any 192.168.201.93 tcp eq 8905

30 deny any 192.168.201.71 udp eq domain (53)

40 permit any any tcp eq www (80)

2. Click Save & Apply to Device

Step 11a: Create URL Filter for BYOD flow

Unlike AireOS which allows DNS entries to be part of redirect ACL, separate URL filter have to
be created and be called upon via RADIUS attribute from ISE to permit access to Internet hosts
using FQDNs.

1. Go to Configuration > Security > URL Filters, Click Add

2. Add URL Filter using following table (Example here is to allow access to Google Play store for
BYOD):
 Name BYOD-URL-Filter
Type PRE-AUTH

Action Permit

*.google.com
accounts.youtube.com
gstatic.com
*.googleapis.com
*.appspot.com
URLs ggpht.com
gvt1.com
market.android.com
android.pool.ntp.org
*.googleusercontent.com
*.google-analytics.com

3. Note: The PRE-AUTH URL filter always works as if the 'Action' is Permit regardless of whether it
is setup as Permit or Deny.
4. Click Save & Apply to Device

Step 11b: Create URL Filter for Social Network Guest

access - Facebook
1. Go to Configuration > Security > URL Filters, Click Add
2. Add URL Filter using following table (Example here is to allow access to Facebook OAUTH2 login
for Guest access):

Name Guest-URL-Filter
Type PRE-AUTH

Action Permit

*.facebook.com
*.akamai.com
URLs
*.fbcdn.net
*.akamaihd.net

3. Click Save & Apply to Device

ISE Configuration
Authorization Profile with URL Filter
Policy Setup on ISE is identical to the one for AireOS controller aside from the URL ACL that needs to be
defined as separate RADIUS attribute. This is done by sending Cisco VSA "url-filter-
preauth={URL_Filter_Name}". Here is an example of ISE Authorization profile for BYOD that allows
Android devices to access the Google play store using the pre-auth URL filter defined above. Note the
Cisco AV pair defined in the 'Advanced Attribute Settings' section.

Authorization Profile with dACL using AAA 'Method-List'

Cisco VSA
As noted above in AAA section, to support dACL, authorization method list name should be set as
'default'. Alternatively, you can choose to use other names for authorization method list, however,
doing so requires specifying authorization method list using RADIUS attribute. Here is an example of
applying dACL by sending down authorization method list 'ISE-AUTHZ' within the ISE authorization
profile. Note that the Cisco VSA 'Method-List' is case sensitive.
For rest of the ISE configuration, please use following guide for rest of the ISE configurations:

Guest: https://community.cisco.com/t5/security-documents/ise-guest-access-prescriptive-
deployment-guide/ta-p/3640475

BYOD: https://community.cisco.com/t5/security-documents/cisco-ise-byod-prescriptive-
deployment-guide/ta-p/3641867

Posture: https://community.cisco.com/t5/security-documents/ise-posture-prescriptive-
deployment-guide/ta-p/3680273
Catalyst 9800 Configuration for FlexConnect Local
switching
This section describes additional configuration needed to configure the WLAN as FlexConnect
Local switching and integrate it with ISE. This section will utilize existing configurations made
above.

Modify Policy Profile

1. Go to Configuration > Tags & Profiles > Policy, Click profile name that maps to the WLAN to
change to local switching
2. Under WLAN Switching Policy section, uncheck Central Switching
3. Click Update & Apply to Device
4. Repeat above steps for other policy profiles that maps to the WLANs to be converted to local
switching

Create Flex Profile

1. Go to Configuration > Tags & Profiles > Flex, Click Add
2. Add Flex Profile using following table

General Name Flex

Policy ACL ACL Name ACL_WEBAUTH_REDIRECT

Central WebAuth Checked

Pre Auth URL Filter (If this is for BYOD, select BYOD-URL-Filter, else blank)

VLAN VLAN Name User Guest

VLAN Id 10 30

3. Note: When 'Central WebAuth' is checked, the C9800 automatically creates a Flex ACL that is in
reverse of selected redirect ACL. The permit statements are changed to deny and deny
statements are changed to permit. This is due to differences between the two redirect ACL
types and slight modification is needed on the ACL to make it work with FlexConnect mode. This
option should only be checked for ACL that is going to be used for redirect purpose and for post-
authentication ACL, this option should not be checked. See ACL section below for more
information.
4. Click Save & Apply to Device
Create Site Tag
1. Go to Configuration > Tags & Profiles > Tags, Click Site, Click Add
2. Add Site Tag using following table

Name Branch

Flex Profile Flex

Enable Local Site Unchecked

3. Note: Unchecking 'Enable Local Site' will reveal Flex Profile option
4. Click Save & Apply to Device

Assign Site Tag to AP

1. Go to Configuration > Wireless > Access Points
2. Click on the AP Name or MAC address
3. Under General > Tags > Site, Select 'Branch'
4. Click Update & Apply to Device
Note: The AP will disconnect for few minutes and when reconnected to the controller, it will be
in FlexConnect mode

Modify Redirect ACL

When ACL is translated to the FlexConnect ACL, it requires return traffic to be allowed for it to
work. If deny is missing for return traffic the endpoint in Central_WebAuth state will not be able
to finish the redirect flow. Following changes to the existing ACL will make ACL wotk for both
local mode and FlexConnect mode.

1. Go to Configuration > Security > ACL, Click ACL name ACL_WEBAUTH_REDIRECT

2. For any deny statement ensure that deny ACE entry is added for return traffic. See sequence 11
& 12 for example:

Sequence Action Source IP Destination IP Protocol Source Port Destination Port

10 deny any 192.168.201.93 tcp eq 8443

 11 deny 192.168.201.93 any tcp eq 8443

20 deny any 192.168.201.71 udp eq domain (53)

21 deny 192.168.201.71 any udp eq domain (53)

30 permit any any tcp eq www (80)

3. Click Update & Apply to Device