Ise Wired Access Depl Guide-V01

Cisco ISE Deployment Guide
Deploying ISE for Wired Network Access
Deploying Cisco ISE for Wired Network Access
Hariprasad Holla
June 2018
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 3
Table of Contents
Introduction .................................................................................................................................... 4
About Cisco Identity Services Engine (ISE) ........................................................................................... 4
About This Guide .................................................................................................................................... 4
Define ............................................................................................................................................. 6
ISE Deployment Components .................................................................................................................................................. 6
Authentication Authorization and Accounting (AAA) ............................................................................................................... 6
Session Aware Networking.................................................................................................................................................... 10
Design........................................................................................................................................... 12
Design Considerations ......................................................................................................................... 12
Endpoint considerations ........................................................................................................................................................ 12
Network Device considerations ............................................................................................................................................. 12
ISE deployment considerations.............................................................................................................................................. 15
Deploy .......................................................................................................................................... 18
Preparing for Identity Based Network Access .................................................................................... 18
Preparing ISE for Identity Based Network Access ................................................................................................................. 18
Preparing Switch for Identity Based Network Access ............................................................................................................ 19
Validating Basic Settings ....................................................................................................................................................... 21
Best Practice Global Settings for Switch ............................................................................................ 23

Monitoring Authentications with Open Access .................................................................................. 32
Integrating ISE with Active Directory ..................................................................................................................................... 32
Configure Switch for Monitor Mode ....................................................................................................................................... 38
Configuring Microsoft Windows and Apple OS X Devices for 802.1X ................................................................................... 40
Monitoring Authentication Sessions....................................................................................................................................... 45
Deploying 802.1X for High security (Closed Mode) ............................................................................ 47

Switch Configuration for Closed Mode .................................................................................................................................. 48
Authoring Access Policies on ISE .......................................................................................................................................... 50
Closed Mode in Action .......................................................................................................................................................... 56
Pre and Post Authentication Access Control with Low Impact.......................................................... 58

Configuring and Understanding IBNS 2.0 Policy .................................................................................................................... 59
Additional Best Practice Configurations for IBNS 2.0 ............................................................................................................ 65
Downloadable ACL Authorization .......................................................................................................................................... 69
Validating ACL Authorization / Low-Impact Mode ................................................................................................................ 72
Role Based Critical Authorization ........................................................................................................ 75

IOS Changes for Role Based Critical Authorization................................................................................................................ 76
ISE Authorization with User-Role ........................................................................................................................................... 78
Validating Role Based Critical Authorization .......................................................................................................................... 80
Differentiated Authentication (With IBNS 2.0) .................................................................................... 81

Switch Configuration for Differentiated Authentication .......................................................................................................... 82
ISE Authorization Profile for Differentiated dACL ................................................................................................................... 84
Identity Based Network Access in IPv6 Wired Networks ................................................................... 85

IPv6 Network Readiness ........................................................................................................................................................ 86
IOS Identity Configurations for IPv6 ....................................................................................................................................... 87
Low-Impact Mode with IPv6 Per-User ACL .......................................................................................................................... 88
802.1X For Cisco IP Phones ................................................................................................................. 92

Basic Call Manager and Network Settings ............................................................................................................................. 93
IP Phone Authentication with MIC .......................................................................................................................................... 95
IP Phone Authentication with LSC ....................................................................................................................................... 103
Operate ...................................................................................................................................... 109

Operating ISE ..................................................................................................................................... 109
Operating the ISE Session Table ......................................................................................................................................... 109
ISE AAA Reports .................................................................................................................................................................. 111
Troubleshooting ................................................................................................................................. 112

IOS Troubleshooting ............................................................................................................................................................ 112
ISE Troubleshooting ............................................................................................................................................................. 113
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, endpoint 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 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. 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.
About This Guide

This guide is intended to provide technical guidance to design, deploy and operate Cisco Identity Services Engine (ISE) for wired
network access control. Special focus will be on the Cisco Catalyst access switch configurations to handle various scenarios.
The document provides best practice configurations for a typical environment.
Even though it's all about wired access control, this guide does not cover Cisco Meraki and 3rd party access switches. There are
other guides under ISE Design & Integration Guides, that will address these scenarios in detail.
The first half of the document focusses on the planning and design activities, the other half covers 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, you will see how to design for a secure wired
access network. Third, in the deploy part, the various configuration and best practice guidance will be provided. Lastly, in the
operate section, you will learn how to manage a wired access network controlled by Cisco ISE.
Figure2: ISE for wired implementation flow
What is covered in this document?
This document is aimed at providing guidance to Cisco ISE customers that wants to protect their wired network access operated
with the Cisco Catalyst switch platforms. The configuration example listed in this document are working configurations validated
with a Cisco Catalyst 9300 series switch running IOS version 16.6.8 and Cisco ISE version 2.4.
Figure3: Simple ISE Deployment Topology
The following are the features and variations captured 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
• 802.1X on Cisco IP Phones
What is not covered in this document?

Though the deployment guide is about securing wired network access, Cisco Meraki access switches or 3rd party access
switches are not covered in this document. The guide does not cover other wired access features such as Wired Guest Access ,
NEAT and Easy Connect
Define
This initial section focusses on defining and understanding important terms and technologies involved in identity-based
networking
ISE Deployment Components

A typical ISE based network access control solution comprises of four components, the endpoints, network devices, Cisco ISE
and external services.
Figure4: Typical ISE Deployment
The endpoints need network access. The network devices provide network access to the endpoints, based on instructions from
ISE. ISE can optionally leverage external services to understand more about the endpoints for policy decisions. When it comes to
rolling out an identity-based network, these four parts of the network will be touched, various teams and individuals needs to be
involved. Several ISE use cases such as Guest access, BYOD, Posture and more require endpoints communicating to ISE via the
network devices.
Authentication Authorization and Accounting (AAA)

The core of Identity Based Networking Services (IBNS) is the idea of users and devices authenticating to ISE and ISE applying
appropriate network access authorization, predominantly using protocols such as EAP and RADIUS. The network devices covey
the endpoint’s session status to ISE via RADIUS accounting messages. ISE centrally gains visibility in to the details of all assets
connecting to the network and their location. An ISE administrator can permit or deny access to specific user or device, specific
group of assets on the fly or based on policy configurations on ISE.
Printed in USA Cxx-xxxxxx-xx 05/17
Authentication Methodologies
IEEE 802.1X
Figure5: IEEE 802.1X Authentication
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 any services
offered by the switch or the LAN. The supplicants on the endpoints, use Extensible Authentication Protocol (EAP) to
pass the 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 an IP networks. ISE evaluates the endpoint’s
identity and instructs the network device whether to open the port or not, what VLAN and or ACL to apply, for that
endpoint’s access session.
MAC Authentication Bypass (MAB)
Figure6: MAC Authentication Bypass
MAB enables port-based access control using the MAC address of the 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 the endpoints must be whitelisted in some database, either on ISE or somewhere external to grant
network access to known endpoints. MAB is not truly an authentication method, instead an authentication bypass for the
endpoint’s inability to do 802.1X. While MAB can protect networks from unauthorized access, it’s not a secure
alternative to 802.1X, since MAC addresses can be spoofed easily.
Web Authentication
Figure7: Central Web Authentication (CWA)
Web authentications are typically used to onboard guest users for internet access. Cisco platforms provide couple of
options for web authentication, Local Web Authentication (LWA) and Central Web Authentication (CWA). In case of the
former, the web pages are hosted in the network devices (like a switch or Wireless LAN controller) and in case of the
later, all the web portals are hosted centrally on ISE. CWA being the preferred method, is typically a MAB session with
URL-Redirect authorization on the switchport. Until the endpoint is authenticated successfully, any web traffic from it
can be redirected to ISE, so that ISE can throw up a login portal for end users to input their credentials. Upon
successful authentication, ISE will initiate a Change-of-Authorization (COA) to permit more access.
Easy Connect
Figure8: ISE Easy Connect
Cisco ISE Easy Connect feature enables enterprises to implement identity-based network access without the need for
802.1X. No supplicants or supplicant configurations needed on the endpoint. Similar to the Central Web Authentication
flow, Easy Connect session starts with a MAC authentication bypass. ISE learns about the endpoint’s location, MAC
address and IP addresses via an initial MAB session. This initial MAB session will be authorized with limited access from
ISE, so that a Windows Active Directory managed endpoint can do a Windows domain login. Upon successful domain
login, the user-ID to IP address mapping from the Active Directory domain controller is pulled down to ISE and is
merged with the initial MAB session. Once the user-ID and its AD group membership are resolved, ISE can change the
authorization to permit more access.
Comparing different authentication methods
Figure9: Authentication Method Comparison
IEEE 802.1X is the most secure and flexible authentication methods out of the options discussed so far. There are
several EAP methods that allows for a variety of credentials types to be handled depending on the endpoint and the
environment type. Web authentication and Easy Connect options provide the necessary user-ID context for visibility and
access control, however they are constrained to specific type of endpoints. Like Web Authentication requires user
interaction and a device with a compatible web browser and Easy Connect works only for Window Active Directory
managed endpoints. Finally, MAB is more of a band aid than a real authentication method but is the easiest option to
turn on a basic level of controlled access.
Authorization Options
ISE authorization policy can result in to a permit, deny or limited network access. While RADIUS ACCESS-ACCEPT and
ACCESS-REJECT commands indicate the network devices to permit or deny access, ‘limited access’ authorization may vary
from environments to environments. The question to be asked is, what should be limited and how?
Figure10: Authorization Options
Dynamic VLAN Assignment
One of the traditional means of limiting network access is by putting endpoints in different VLANs based on their role.
Endpoints in specific VLANs can be access controlled by policies defined at the layer-3 boundaries such as on the
routers or firewalls. ISE can authorize endpoints to specific VLANs either by the VLAN name or number. Also, in
platforms such as Cisco 2960X, 3650, 3850 and the 9300s VLANs can be applied on a per MAC address basis.
IP Access Control Lists (ACLs)
ACLs can be used to control network access at the port level. ACLs can either be downloaded to the network from ISE
or be configured locally on the switch and be referenced by ISE during authorization. Named ACL authorization can be
done with RADIUS standard attribute called the ‘Filter-ID’ with the ACL name. For ACL downloads, either Per-User-ACL
or Downloadable ACL (dACLs) can be used. Both these ACL download options use Cisco custom RADIUS Attribute
Value Pair (AVP). The per-User ACL is limited by a size of 4000 characters, while downloadable ACLs do not have a
limit on its size. However the practical recommendation for dACLs are 64 Access Control Entries (ACE)s.
Security Group Tags (SGT)
SGTs offer an efficient alternative to VLAN based segmentation. Just like VLAN authorization, assigning an SGT alone to
an endpoint doesn't control access. Instead after SGT assignments, the endpoints must be subject to egress
enforcement policies based on Security Group Tags. Though in most cases identity-based access is necessary for SGT
based segmentation, this guide does not cover the tag-based segmentation in any detail.
URL Redirection
The access switch can redirect endpoints to specific URLs authorized by ISE for redirection. Typically, the URL
redirection are towards the ISE nodes, so that the endpoints can do 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 and Cisco network, implements what’s called, session aware networking. The idea is to attach session identifier to
endpoint’s network access session, be it wired or wireless and apply policies to it.
Figure11: ISE Session Aware Networking
When an endpoint connects to the network, the network device generates a unique session identifier that's a combination of the
network device IP address, the session count on the network device and the timestamp of endpoint’s initial connection
ISE can invoke the network device to enforce specific policies for the endpoint using the session identifier. Upon initial
authorization, ISE can issue a Change of Authorization (COA) by referencing the same session-ID. Distinct access policies for the
endpoints on the same port, can be applied because of the separation maintained by the session ID.
Design
Design Considerations
Endpoint considerations
There a few important things to consider for endpoints in an identity-based network. Firstly, how will these endpoints
authenticate to the network, is it using 802.1X or Web Authentication or some other means. Secondly, do we need custom
agents to do specific functions that the native supplicants in the OS can’t. And, finally, how to configure the endpoints for
appropriate access, which could be manual, using some centralized management tools and so on.
Agents
For most of the secure wired access stuff, an agent on the endpoint is unnecessary. However, there are a few scenarios
that can only be handled by Cisco AnyConnect endpoint agent:
EAP Chaining – Many organizations want to grant network access to trusted users on trusted devices. While
Cisco ISE feature like Machine Access Restriction (MAR) can handle such cases with native supplicants, it is
vulnerable and inflexible in various terms. With Cisco AnyConnect Network Access Manager (NAM) module on
the endpoint and Cisco ISE, user and machine authentications can be tied in a common EAP session, making it
a secure alternative to MAR.
MACSec – While protocols such as IEEE 802.1X provides authenticated network access, to keep it tightly
secure the layering of IEEE 802.1AE (MACSec) based data encryption, would be desirable. Cisco AnyConnect
is the only supplicant that can support MACSec on the endpoints.
Note: Cisco AnyConnect NAM module is compatible only on Microsoft Windows Operating systems. So
essentially both EAP Chaining and MACSec features can be enabled on Windows based endpoints only
today.
Automation
It’s evident that implementing port access control with 802.1X, means considerable changes to the endpoint. Some of
the changes that can be thought of are, supplicant configurations, certificate installation (optional), agent installation and
setup (optional). Rolling out these changes to thousands of endpoints, will need some sort of automation. Some of the
options to automate supplicant configuration are:
Endpoint Type Supplicant configuration by

Microsoft Windows systems (Managed) Active Directory – Group Policy Objects (GPO)
Cisco IP Phones Cisco Unified Call Manager
Apple devices MacOS server
BYOD (Android / Apple iDevices / Microsoft devices / Cisco ISE Client Provisioning / Mobile Device Managers
Google Chrome devices)
Always try to use some systems manager or device managers to configure endpoints at scale.
Network Device considerations

The “Network Device” or “Network Access Device (NAD)” in the context of this guide is a catalyst switch, running Cisco IOS
software. There are three major configurations that go in to a catalyst switch, for it to work with ISE.
Figure12: Network Device Configurations for ISE
The global AAA and RADIUS server configurations govern how the switch talks to ISE, how RADIUS transactions are load
balanced, how frequently accounting updates are sent, how it handles failure scenarios when ISE is not reachable, and so on.
The endpoint side configuration includes interface level commands to handle specific authentication methods like 802.1X or
MAC authentication bypass in a particular order. The port configurations can be done either in Identity Based Networking
Services (IBNS) 1.0 or 2.0 methods, which will be discussed shortly. ISE may authorize an endpoint with VLAN, ACL, Security
Group Tag (SGT), port configuration and more. Some of the authorization attributes needs to be configured locally on the switch.
Identity Based Networking Services (IBNS) 1.0 VS 2.0
One of the critical consideration, when it comes to the switch configurations required for ISE deployment, is whether to go with
IBNS 1.0 or IBNS 2.0 style commands. Identity Based Networking Services, as the name goes, are the identity-based session
management services on Cisco IOS, meant for handling access services for endpoints connecting to the network. It’s the policy
functions on the switch that determines how to facilitate endpoint’s network authentication to a centralized AAA (Authentication
Authorization and Accounting) server, how to treat the endpoint when there are authentication failures or AAA server
unreachability and so on. 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 picture depicts, in case of
IBNS 1.0, or sometimes referred to as ‘legacy’ mode in CLI, the switch local policy for handling endpoint’s identity-based
network access is all contained within interface configurations (a list of interface commands applied to a switchport). Whereas in
case of IBNS 2.0, the configurations take the structure of a Cisco Modular Quality of Service Command Line Interface (MQC).
One or more subscriber policies are used, defined by ‘policy-map’ command, that classifies various endpoint events in to
classes, that are defined by the class-map command arguments. The several endpoint event classifications are subject to
specific actions, some that are local and some that are enforced upon instructions from Cisco ISE. The use of templates
provides, modularity, flexibility and reusability of certain policy objects within the switch platform.
There are certain important benefits of using IBNS 2.0 over IBNS 1.0. The following table compares the two:
IBNS 1.0 IBNS 2.0 Description
Policy Interface IBNS 2.0 is configured similar to a router QoS policy, while IBNS
MQC style
configuration commands 1.0 is configured with a list of interface subcommands
Interface IBNS 2.0 configurations can be contained within an interface

No Yes
templates template, while 1.0 commands do not fit in
Templates
Service
No Yes IBNS 1.0 cannot use service-templates
templates
Both support assigning a fail open VLAN for endpoints that

Critical VLAN Yes Yes
cannot reach ISE during authentication
Only IBNS 2.0 can apply a custom ACL to an endpoint session,

Critical ACL No Yes
when ISE service is unavilable
Critical
authorization
Only IBNS 2.0 can assign a critical SGT when AAA server is
Critical SGT No Yes
down
With IBNS 2.0, endpoints can be MAB authenticated against a

Critical MAB No Yes
local list of MAC addresses on the switch
IBNS 2.0 facilitates for separating authentication and

Differentiated
No Yes authorization transactions between two or more AAA servers,
authentication
IBNS 1.0 cannot.
Intelligent IBNS 2.0 has better way to detect disconnects from indirectly
No Yes
aging connected hosts
Phased deployments
Enabling 802.1X on switchports 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 the device types. With wireless this is a norm, because the endpoints do
not plug to the network, rather needs to be configured (for SSIDs) to connect to the network. The notion of configure and
connect is built grounds up in wireless world, while the same is not the case with wired side of the networks. For decades the
expectation is that the endpoint must get IP address the moment they plug in to the wired Ethernet port.
Cisco recommends a phased deployment model that can allow for 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) – Is a first step. Where on the wired network access, authentication is enabled while
authorization is kept open. Which means that irrespective of the endpoint’s authentication status, either success or
failure the port is always open. When a user plugs in a device one morning after monitor mode is enabled in the
network, he or she will not see any difference to how the devices gets network services. Such a setting, provides
adequate visibility, centrally to the security operator to know how many endpoints authenticate successfully, how many
fail, why do they fail, where they are located, and so on. Once most of the failures are fixed, one of the two following
enforcement modes can be enabled.
2. Low Impact Mode – Low Impact mode builds on monitor mode. With open access in place, IP Access Control Lists
(ACLs) will be used to control pre-authentication and post-authentication network access. A Pre-Auth-ACL on the
switchport, controls the network access before an endpoint could successfully authenticate and a named or
downloadable ACL received from ISE grants specific level of access upon successful authentication. Low Impact Mode
is ideal for Preboot eXecution Environment (PXE) boot environments where the thin clients need to download the OS
from the network before attempting network authentication. Since devices get IP address immediately when they
connect to the network and authentication may happen in parallel or later, it is recommended not to do VLAN changes
in Low Impact Mode.
3. Restricted Mode (Closed Mode) – In closed 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 won’t acquire dynamic IP address without authentication, this mode is ideal for VLAN authorizations.
ISE deployment considerations

When it comes to wired network access, a carefully setup ISE service is critical. The following are some of the important
considerations:
ISE Deployment Scale and Performance
Figure15: IBNS deployment modes
ISE can be deployed as a standalone service or a cluster of multiple ISE nodes. While the former is a good option for small size
networks, the latter is the choice for medium and very 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 right deployment
type and install option, applicable to your requirements. Refer ISE Performance & Scale page for more details on the scale
limitations and performance numbers for each ISE deployment method.
The access switches need to talk to ISE servers for Authentication, Authorization and Accounting (AAA). Typically, two or more
RADIUS servers are defined on the switches for AAA and CoA. For large networks involving multiple PSNs per site, use of Load
Balancers are recommended. When Load Balancers are used, the virtual IP address of the Load Balancer must be configured as
the RADIUS server IP address on the switches. The following table summarizes the configuration practice to follow depending up
on the type of deployment and use of Load Balancers or not
Switch Side Configuration 2-Node Standalone ISE Multi Node ISE Multi Node ISE
with Load Balancers
RADIUS Server configuration IP address of the standalone IP address of the PSNs IP address of the Virtual IP address
for AAA ISE nodes of the Load Balancers
RADIUS Server configuration IP address of the standalone IP address of the PSNs and IP address of the Load Balancer VIP,
for COA ISE nodes PANs PSNs and PANs
ISE Licensing
Cisco ISE requires one or more of the three license packages, Base, Plus and Apex to service endpoints. However, for most of
the AAA and access control services, just the Base licenses are enough. 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 in to applications
and processes on endpoints and to control them Apex licenses will be needed additionally. Note, all these licenses are applied
to the endpoint’s session that is active at a given point of time, thereby budgeting for adequate licenses must not be on the total
number of endpoints, but for an estimate of active endpoints at a possible peak duration. More about licenses can be read at
Cisco ISE Ordering Guide
Certificates
Certificates are used to identify Cisco ISE to an endpoint and also to secure the communication between that endpoint and the
Cisco ISE node. Certificates are used for all HTTPS communication and the Extensible Authentication Protocol (EAP)
communication. The following is a summary of certificates and their use in the context of endpoint authentication and access
control:
Communication Uses Purpose

HTTPS • Administration Portal • Web authentication
• Centralized Web Authentication Portal • ISE Portal access for administration and
operations
• Sponsor Portal
• Client Provisioning Portal
• My Devices Portal
EAP • EAP-TLS • IEEE 802.1X authentication
• PEAP
• EAP-FAST
It is recommended not to use ISE self-signed certificates for production use, instead use a Certificate Authority (CA) signed
certificates on the ISE nodes for all possible purposes. When dealing with internal endpoints that are managed by an
organization an internal enterprise PKI (Public Key Infrastructure) can be used. For use cases such as guest internet access and
Bring-Your-Own-Device (BYOD) registration, ISE node certificates signed by public CA is recommended, to avoid poor user
experience due to certificate warnings on the endpoints. ISE has a built-in Certificate Authority service, but its largely limited to
BYOD identity and authentication. Read How To: Implement ISE Server-Side Certificates for more about certificates.
Deploy
Preparing for Identity Based Network Access
This section shows how to configure ISE and a switch for basic RADIUS connectivity.
Figure16: Switch and ISE RADIUS Connection
Preparing 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.
Step 1 Login to ISE admin node and navigate to Administration > Network Device
Step 2 Select Default Device page.

Step 3 Select Enable for Default Network Device Status and define a Shared Secret (ISEisC00L in this example)
Step 4 Save the configuration
Preparing Switch for Identity Based Network Access
Perform the following steps to configure a Cisco Catalyst Switch for basic RADIUS connectivity
Step 1 Configure the management interface for the switch
c9300-Sw(config)#interface Vlan254
c9300-Sw(config-if)#description ** Switch management interface **
c9300-Sw(config-if)#ip address 172.20.254.101 255.255.255.0
c9300-Sw(config-if)#end
Note: In the example here, 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 proper routing is setup between the access
switch and the ISE nodes.
Step 2 Login to the switch, and enable AAA
c9300-Sw(config)#aaa new-model
Step 3 Configure one or more ISE Policy Services Nodes as the RADIUS servers
Ensure that, the RADIUS key is identical to the shared secret configured on ISE
c9300-Sw(config)#radius server ISE01

c9300-Sw(config-radius-server)#address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
c9300-Sw(config-radius-server)#key ISEisC00L
c9300-Sw(config-radius-server)#exit
c9300-Sw(config)#

Note: The default authentication port (auth-port) is 1645/UDP and accounting port (acct-port) is
1646/UDP, unless explicitly configured to 1812 and 1813 respectively as above. ISE can receive
RADIUS authentication and accounting requests on either of the two port number combinations.
Step 4 Define a method-list for the ISE RADIUS servers and reference the two server definitions under it.
Also define the switch management interface as the RADIUS source-interface:
c9300-Sw(config)#aaa group server radius ISE

c9300-Sw(config-sg-radius)#server name ISE01
c9300-Sw(config-sg-radius)#server name ISE02
c9300-Sw(config-sg-radius)#ip radius source-interface VLAN 254
Step 5 Configure network authentication to use the RADIUS method-list ("ISE" in our example)
c9300-Sw(config)#aaa authentication dot1x default group ISE
Step 6 Configure the switch for network (access) authorization via ISE RADIUS Server(s). This is for network access
authorization from ISE, such as dynamic VLAN assignment, downloadable ACLs, URL-redirection and more.
c9300-Sw(config)#aaa authorization network default group ISE
Step 7 Configure switch to send accounting information to ISE upon endpoint session start and end events
c9300-Sw(config)#aaa accounting dot1x default start-stop group ISE
Step 8 For switch to send periodic accounting updates for active sessions, every 2 days once
c9300-Sw(config)#aaa accounting update newinfo periodic 2880
Note: Once 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 in 2-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
Step 1 Check for AAA Server status on the switch
c9300-Sw#show aaa servers
RADIUS: id 1, priority 1, host 172.20.254.21, auth-port 1812, acct-port 1813

State: current UP, duration 38301s, previous duration 0s
Dead: total time 0s, count 0
Platform State from SMD: current UP, duration 38301s, previous duration 0s
SMD Platform Dead: total time 0s, count 0
Platform State from WNCD: current UP, duration 0s, previous duration 0s
Platform Dead: total time 0s, count 0
Quarantined: No
!<Output truncated>

Dead: total time 0s, count 0
SMD Platform Dead: total time 0s, count 0
Platform Dead: total time 0s, count 0
Quarantined: No
!<Output truncated>
Step 2 Execute the following test command on the switch, to validate if the switch and ISE can communicate over RADIUS
The test-user and test-password are not real user names and passwords, it is to test if the switch and ISE can talk
over RADIUS protocol
c9300-Sw#test aaa group radius test-user test-password new-code

AAA/SG/TEST Platform: Testing Status
AAA/SG/TEST: Authen Requests to Send : 1
AAA/SG/TEST: Authen Requests Processed : 1
AAA/SG/TEST: Authen Requests Sent : 1
AAA/SG/TEST: Authen Requests Replied : 1
AAA/SG/TEST: Authen Requests Successful : 0
AAA/SG/TEST: Authen Requests Failed : 1
AAA/SG/TEST: Authen Requests Error : 0
AAA/SG/TEST: Authen Response Received : 1
AAA/SG/TEST: Authen No Response Recevied: 0

AAA/SG/TEST: Account Requests to Send : 0
AAA/SG/TEST: Account Requests Processed : 0
AAA/SG/TEST: Account Requests Sent : 0
AAA/SG/TEST: Account Requests Replied : 0
AAA/SG/TEST: Account Requests Successful : 0
AAA/SG/TEST: Account Requests Failed : 0
AAA/SG/TEST: Account Requests Error : 0
AAA/SG/TEST: Account Response Received : 0
AAA/SG/TEST: Account No Response Recevied: 0
User rejected
Note-1: The Authen Requests Replied : 1 message in the output indicates that a RADIUS server is
responding to the switch’s requests.
Note-2: Such detailed output for test aaa command is available only from 16.X IOS version
Step 3 Login 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
Step 4 If you click on the details page icon corresponding to the test-user, you will see the reason for failure: 22056
Subject not found in the applicable identity store(s), which means that user account “test-user” could not be
found anywhere, which is very obvious at this stage of the deployment.
Another important thing to notice 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
Step 1 Define how the 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 must be received from the ISE server
• tries - The number of times the switch must fail to receive a response from ISE server to mark it as dead
Step 2 When multiple RADIUS servers are defined, and the primary server is unavailable, it is a good practice to hold that
server’s dead status for some time. This avoids sending RADIUS requests to a server that could be flapping its
status.
In the following example the dead time is set to 15 minutes.
c9300-Sw(config)#radius-server deadtime 15
Step 3 With the configuration defined in Step-1, the switch will mark the server to be dead upon that server meeting the
dead criteria. However, to revert the server status back to “Up” state, the switch needs to send periodic probes,
which can be enabled by the following command

c9300-Sw(config-radius-server)#automate-tester username test-user ignore-acct-port probe-on
c9300-Sw(config)#
Note: The ‘test-user’ is a dummy username. The ‘ignore-acct-port’ keyword indicates that the switch
must not validate the accounting port number that the server will use and an ‘probe-on’ keyword
indicates that the switch must send test probes only when the server is marked ‘Dead’
Step 4 If the probe user is a real user account on ISE internal or external database, then a password is required too. The
password for this account can be configured on the switch as per below:
c9300-Sw(config)#username test-user password 0 test-password
Step 5 The following command, makes switch send canned EAPoL success message to the client when the port fail-opens
or fail-closes in the event when none of the ISE servers are reachable.
c9300-Sw(config)#dot1x critical eapol
Additional RADIUS Best Practice Attributes for ISE
Step 6 The following command, sends 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
Step 7 To send the IP address of the endpoint to the RADIUS server in the access request.
c9300-Sw(config)#radius-server attribute 8 include-in-access-req
Step 8 To include the class attribute in access-request for network access authorization
c9300-Sw(config)#radius-server attribute 25 access-request include
Step 9 The following command sets 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
• default - (Example: 0000.4096.3e4a)

• ietf - (Example: 00-00-40-96-3E-4A)
• unformatted - (Example: 000040963e4a)
Step 10 The following includes MAC address only, if available in the Calling Station ID of the RADIUS request
c9300-Sw(config)#radius-server attribute 31 send nas-port-detail mac-only
Change of Authorization (CoA)
Step 11 The following commands configure ISE nodes as CoA servers:
c9300-Sw(config)#aaa server radius dynamic-author

c9300-Sw(config-locsvr-da-radius)#client 172.20.254.21 server-key ISEisC00L
c9300-Sw(config-locsvr-da-radius)#client 172.20.254.22 server-key ISEisC00L
Device Tracking
Beginning in Cisco IOS XE Denali 16.1.1, the new Switch Integrated Security Features (SISF)-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 the endpoint’s IP address and map that to its network access session. It
is also essential for features such as downloadable ACLs, device profiling, URL-redirection and more.
Step 12 Configure the device tracking policy with custom name:
c9300-Sw(config)#device-tracking policy IPDT_POLICY
Step 13 Under the policy enable device tracking
c9300-Sw(config-device-tracking)#tracking enable
Step 14 It's a best practice to disable device tracking IOS feature from gleaning UDP protocols
c9300-Sw(config-device-tracking)#no protocol udp
Note: The device-tracking policy is only effective when applied under the switchports, with the
following command:
interface GigabitEthernet x/y/z

device-tracking attach-policy POLICY_NAME
This will be discussed in the subsequent sections.
Device Sensor
Device Sensor is a Cisco IOS and AireOS feature that simplifies device profiling on ISE. The switch gathers raw endpoint data
from protocols such as CDP, LLDP, DHCP and others, packages and sends it over to ISE in RADIUS accounting messages. ISE
collects these device attributes and profiles the endpoint in to specific device groups.
Step 15 The following command enables device sensor globally on the switch
c9300-Sw(config)#device-sensor accounting
Step 16 For the switch to send updates to ISE as and when the device attributes change, the following configuration must be
done:
c9300-Sw(config)#device-sensor notify all-changes
Step 17 Configure and apply filter lists for CDP, LLDP and DHCP protocols, so that only the critical attributes required for
identifying the endpoint type reaches ISE.
CDP device sensor filter:
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-sensor-cdplist)#device-sensor filter-spec cdp include list CDP-LIST
Step 18 LLDP device sensor filter:
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-sensor-lldplist)#device-sensor filter-spec lldp include list LLDP-LIST
Step 19 DHCP device sensor filter:
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 list DHCP-LIST
Note: Device sensor configuration, without filter list will overload ISE with unnecessary attributes that
does not help much in the context of device profiling. The best practice attribute list provided above
works well for most environments. For more details on profiling, refer the profiling guide
Web Authentication / URL Redirection and ACLs

Web authentications are necessary typically 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 the end
users, for certain scenarios.
For instance, when users are not able to authenticate successfully, they can be redirected to an internal portal such as the
following to inform, how to self-resolve the issue:
Step 20 Configure the HTTP service on the switch for URL redirection
c9300-Sw(config)#ip http server
Step 21 Disable web admin access to the switch, so that the HTTP server on it can be used for URL-redirection only
c9300-Sw(config)#ip http active-session-modules none
Note: HTTPS redirection is not recommended for production environments, due to the following
reasons:
• Security concern - HTTPS redirection is intended to hijack a secure web connection initiated
by the endpoint, which is not a good idea.
• Failure to work - Most web browsers block intercepted HTTPS connections.
• Certificate warnings - Even if the web browsers allow for access, there can be certificate
warnings because the switch presents its own certificate for TLS handshake
• Scalability issues - Multiple HTTPS redirections can overload the switch CPU and thereby put
the switch to denial of service
Step 22 (Optional) Domain name is required when enabling HTTPS redirect
c9300-Sw(config)#ip domain-name isedemo.lab
Step 23 (Optional) Generate 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 perform 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.
Step 24 (Optional) Enable HTTPS service
c9300-Sw(config)#ip http secure-server
Step 25 (Optional) Deny admin access to switch via HTTPS
c9300-Sw(config)#ip http secure-active-session-modules none
Step 26 Limit the number of HTTP connections (Default on Catalyst 9300 is 25, maximum 50)
c9300-Sw(config)#ip http max-connections 48
URL Redirection ACL
This ACL defines which traffic is redirected to ISE during 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 recommended that you specify only HTTP (and HTTPS) here to be permitted since this traffic
gets pushed to the switch CPU. If additional access control is needed in conjunction with the redirect ACL, then we
recommend using dACLs along with the redirect ACL.
Figure17: ISE URL Redirection
Step 27 Configure a URL redirect ACL on the switch
c9300-Sw(config)#ip access-list extended ACL_WEBAUTH_REDIRECT

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 different name is desired, make sure you update both the switch and the ISE
Authorization Profile with new redirect ACL name.
Step 28 It is also a good idea to have a separate URL redirect ACL for black listed devices on ISE. The default rules can
redirect all 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
Step 29 Configure a Pre-Authentication ACL (Pre-Auth-ACL). This is being required if the deployment transitions to low-
impact mode.
c9300-Sw(config)#ip access-list extended IPV4_PRE_AUTH_ACL

c9300-Sw(config-ext-nacl)#permit udp any any eq bootpc
c9300-Sw(config-ext-nacl)#permit udp any any eq domain
c9300-Sw(config-ext-nacl)#deny ip any any
Note: The Pre-Auth-ACL is meant to provide basic network access before successful port
authentication in low-impact mode. Thereby the rules in the ACL must permit only specific service
access 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 Endpoint Authentication
The subsequent sections will go in to the details of the configurations required for performing an 802.1X and MAB
authentications, however the following global configurations are essential for most of the deployment scenarios:
Step 30 The following command enables 802.1X globally on the switch.
c9300-Sw(config)#dot1x system-auth-control
Step 31 (Optional) This command allows sessions without dACL to connect to ACL enabled interface with full access.
c9300-Sw(config)#access-session acl default passthrough
Note: In earlier IOS versions the “epm access-control open” command was used. This feature is
useful in environments where a mixture of authorization profiles uses dACLs and others don't. For
example, user devices are enforced with dACL to limit access to the network, but no dACL is used on
IP phones. When IP Phones are connected, the IP phone is authorized to the voice resources by
MAB/802.1X (without dACL). When a user's device is connected behind 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, since the IP Phone lacks dACL for authorization. However, when this command is entered
globally, the switch dynamically inserts 'permit ip any any' ACL for any sessions without dACL, including
the IP Phone. This is also true for multiple devices connected through an unmanaged hub. If there are
multiple devices already connected without dACL, then when a new device with dACL authorization is
authenticated to the same interface that the unmanaged hub is connected to, then this feature applies
'ip permit any any' ACL to previously connected device’s sessions.
Step 32 The following command permits endpoints to move from 802.1X enabled port to another.
c9300-Sw(config)#authentication mac-move permit
Switch Global Configuration Dump for AAA, RADIUS and More
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
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
!
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
!
ip access-list extended IPV4_PRE_AUTH_ACL
permit udp any any eq bootpc
permit udp any any eq domain
deny ip any any
Monitoring Authentications with Open Access

This section covers, how to enable identity based wired network access without causing any disruption to regular network
connectivity.
Figure18: Monitor Mode
Integrating ISE with Active Directory
Assuming that most environments have a directory service, typically Microsoft Windows Active Directory (AD), the following
section focusses on the integration between ISE and Microsoft Windows AD. If your environment uses a directory service other
than Microsoft Windows AD, then follow an appropriate guide at the ISE Design & Integration Guides, page
Prerequisites for Integrating Active Directory and Cisco ISE
• The Cisco ISE servers and the Active Directory Domain Controllers (DC) must be time synced over Network Time
Protocol (NTP)
• Ensure that trust relationships exist between the domain to which Cisco ISE is connected and the other domains that
have user and machine information to which you need access.
• At least one global catalog server is operational and accessible by Cisco ISE, in the domain to which you are joining
Cisco 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 DCs. (DNS, NTP, MSRPC, Kerberos, LDAP, LDAP-GC and
IPC)
For more details, refer Active Directory Integration with Cisco ISE 2.x, guide
Configuring ISE for AD Integration
Step 1 Login to ISE (Admin node)

Step 2 Choose Administration > Identity Management > External Identity Sources > Active Directory.
Step 3 Click Add and enter a custom name for Joint Point Name and specify the Active Directory domain name.
Step 4 Click Submit to save the configuration.
Step 5 Click Yes for the subsequent notification that asks you, Would you like to Join all ISE nodes to this Active
Directory Domain?
Step 6 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.
Step 7 You should see the Join Operation Status as Completed if everything went well. Click Close to finish the join
procedure.
Whitelist Specific Active Directory Groups
Step 8 Click on the Groups tab and select Add > Select Groups From Directory option:
Step 9 Retrieve Groups, select desired AD groups that you want to use for the authorization policies and click Ok
Step 10 Click Save to save the configuration
Note: The assumption is, that there are Active Directory domain users that are members of these
whitelisted groups.
Validate ISE and AD Integration
Step 11 Click Connection tab within Active Directory configuration, check the configured ISE Node and then click Test User
Step 12 A new window will pop-up. Type a valid domain user name and password and see if the authentication succeeds
Step 13 Click Close and exit the AD authentication test.

Step 14 Login to the catalyst switch and execute the test user command to validate if end to end authentication works well
c9300-Sw#test aaa group radius harry ISEisC00L new-code

User successfully authenticated
USER ATTRIBUTES
username 0 "harry"
c9300-Sw#
AAA/SG/TEST: Authen Requests to Send : 1
AAA/SG/TEST: Authen Requests Processed : 1
<Output truncaked>
Whitelist the Network Device on ISE
Step 1 Within ISE, navigate to Administration > Network Devices
Step 2 Click Default Device and then change the status to Disabled
Step 3 Scroll down and Save the configuration
Step 4 Select Network Devices and then once the Network Device page loads, click Add
Step 5 Fill in a Name and IP Address mandatorily. Check the RADIUS Authentication Settings box and type the Shared
Secret
Note: You can optionally configure the other parameter in the Network Device configuration such as
Model Name, Software version, Location, Device type, and others. The value defined for these
attributes can used in the ISE authentication and authorization polices to match specific criteria.
Step 6 Save the configuration by clicking Submit
Note: ISE allows for bulk configuration of the network devices. One of the options is to upload a CSV file
that contains the network device details:
The other option is to use REST API calls to ISE admin node to configure the network devices. For more
details refer the Cisco ISE API Reference Guide
Configure Switch for Monitor Mode
Step 1 Login to the Catalyst Switch and get in to the interface configuration mode.
c9300-Sw(config)#interface GigabitEthernet x/y/z

c9300-Sw(config-if)#description ** Endpoints and Users **
Step 2 Configure the switch port mode as access. None of the authentication related commands will be 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
Step 3 Enable spanning tree port fast feature
c9300-Sw(config-if)#spanning-tree portfast
Step 4 Attach the device tracking policy to the port. This configuration is essential in 16.X IOS versions, for downloadable-
ACLs, URL-redirection, Security Group Tags (SGT) and other authorization options to work.
c9300-Sw(config-if)#device-tracking attach-policy IPDT_POLICY
Step 5 The following command enables monitor mode (or Open mode) access for the endpoints. Any new MAC address
detected on the port will be allowed unrestricted Layer 2 access to the network even before any authentication has
succeeded.
c9300-Sw(config-if)#authentication open
Step 6 By default, an 802.1X enabled switch port will accept only one MAC address. Since the idea of open mode is to
ensure no disruption, enabling multi-auth host mode is recommended, which allows for one voice an unlimited
number of data endpoints to authenticate on the interface.
c9300-Sw(config-if)#authentication host-mode multi-auth
Step 7 Enable port-based authentication on the switch port
c9300-Sw(config-if)#authentication port-control auto
Step 8 Configure the switch port as an 802.1X authenticator
c9300-Sw(config-if)#dot1x pae authenticator
Step 9 Enable MAC Authentication Bypass on the same switch port
c9300-Sw(config-if)#mab
Authentication Timer Settings
Step 10 By default, the 802.1X to MAB timeout period is 90 seconds. 30 second timeout for each EAP request sent to the
endpoint, with 2 retries. 90-seconds could be significant delay for certain endpoints to obtain 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 802.1X timeout period that
works for most environments is about 30 seconds. The following two commands can be configured to achieve it
c9300-Sw(config-if)#dot1x timeout tx-period 7

c9300-Sw(config-if)#dot1x max-reauth-req 3
Step 11 (Optional) Enable reauthentication & inactivity timer for the port. This command is needed whether the values is
statically assigned on the port or derived from the RADIUS server.
c9300-Sw(config-if)#authentication periodic
Step 12 (Optional) Allows reauthenticate timer interval (Session timer) to be downloaded to the switch from the RADIUS
server
c9300-Sw(config-if)#authentication timer reauthenticate server
Step 13 (Optional) Allow inactivity timer interval to be downloaded to the switch from the RADIUS server. The 'dynamic'
keyword instructs the switch to send out ARP-Probe before removing the session to make sure the device is indeed
disconnected.
c9300-Sw(config-if)#authentication timer inactivity server dynamic
Interface Configuration Dump 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
Step 1 Login to a Windows workstation.

Step 2 Go to the Services console
Step 3 Start the Wired AutoConfig service. Also set the Startup type to Automatic
Step 4 Navigate to the Wired Ethernet port’s adapter settings. Start > Settings > Ethernet > Change Adapter Settings and
click on Properties,
Step 5 In the network adapter properties, click the Authentication tab
Step 6 Click Settings for Microsoft: Protected EAP (PEAP) authentication method.
Step 7 Have the Verify the server’s identity by validating the certificate option unchecked.
Step 8 Click Configure under Select Authentication Method and in the subsequent window, uncheck Automatically use my
Windows logon name… option. If the endpoint is an Active Directory managed endpoint and if the windows domain
login name is preferred for 802.1X authentication, then this option can be checked.
Note: It is strictly not recommended to 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,
it is highly recommended to do the opposite in a production environment.
Step 9 Click OK and exit EAP MSCHAPv2 Properties.

Step 10 Click OK and exit the Protected EAP Properties.
Step 11 If in Step-8, you unchecked Automatically user my Windows logon name… then in the Authentications tab of
network adapter properties, click Additional Settings
Step 12 Specify authentication mode, it could be user / guest / computer / user or computer options. If it is for quick
validation, then it is generally user authentication option.
Step 13 Type the user name and password and save the configuration.
The Windows endpoint is now ready for wired 802.1X authentication
Note: Though the configuration explained in this section enables 802.1X on a Microsoft Windows
endpoint and can be used to validate the end to end configuration in an ISE deployment, it is not a
recommended configuration method for a large-scale production network. When it comes to production
setup, the following guidelines must be considered:
• Install the ISE server certificate or have the root-CA certificate (that signed ISE certificate)
installed on the endpoint’s trusted certificate store.
• Enable server certificate validation in the supplicant settings for PEAP
• If it is an Active Directory managed Windows endpoint, then user or computer authentication
option can be enabled
• If it is an Active Directory managed Windows endpoint, then the Windows domain login
credentials can be set to be used for 802.1X authentication, by checking the Automatically use
my Windows logon name and password option
• For Active Directory managed Windows endpoints, enable the 802.1X settings via Group Policy
management.
• For BYOD Windows endpoints, use ISE’s native supplicant provisioning flow to install server
certificate and configure the adapter settings.
Configuring Apple MacBook for Wired 802.1X
Step 1 Connect the USB to Ethernet or thunderbolt Ethernet adapter to the MacBook
Step 2 Go to System Preferences > Network
Step 3 In a few seconds an authentication window will pop up asking for 802.1X username and password. Type the
Account name and Password and click OK
Step 4 You will be asked accept the server certificate, click Continue
Step 5 At this time, you must provide the local system administrator username and password to add the ISE certificate to
the local trusted certificate store
Step 6 You should notice the change in IP address and domain name. Also, the 802.1X session timer kicks in once the
authentication is successful
Note: Like Microsoft Windows Active Directory and 3rd party systems managers for Windows endpoints,
there are systems managers available for Apple OS X devices. The systems managers can manage
inventory, build and deploy applications, and enforce polices on all the managed OS X endpoints in a
given environment. Here is an example of how a systems manager can be used to remotely manage
802.1X configuration on Apple Mac endpoints: 802.1X Network Authentication for Mac
Monitoring Authentication Sessions
Step 1 Login to ISE. In the dashboard you will see the total number of endpoints connected to the network
Step 2 Click on the number to see the details:
Step 3 Navigate to Operations > RADIUS: Live Logs, you should notice that all the endpoints connected to the network so
far have received a permit access.
Step 4 Login to the Catalyst switch and check the authentication sessions
c9300-Sw#show authentication sessions

Interface MAC Address Method Domain Status Fg Session ID
--------------------------------------------------------------------------------------------
Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 65FE14AC0000001F1D04947E
Gi1/0/1 0064.40b5.794e mab DATA Auth 65FE14AC000000201D049D86
Gi1/0/5 406C.8F39.17AE dot1x DATA Auth 65FE14AC0000000E1845E2D2
<Output trunckated>
Step 5 Check the authentication session details on specific port
c9300-Sw#show authentication session interface Gi 1/0/1 details

Interface: GigabitEthernet1/0/1
IIF-ID: 0x119631A2
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: both
Session timeout: N/A
Common Session ID: 65FE14AC0000001F1D04947E
Acct Session ID: 0x00000015
Handle: 0x3f000015
Current Policy: POLICY_Gi1/0/1
Server Policies:
Security Policy: None
Security Status: Link Unsecured
Method status list:

Method State
dot1x Authc Success
----------------------------------------
IIF-ID: 0x14A4B799
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: DATA
Oper control dir: both
Common Session ID: 65FE14AC000000201D049D86
Handle: 0xb5000016
Server Policies:
Method status list:

Method State
dot1x Stopped
mab Authc Success
Deploying 802.1X for High security (Closed Mode)
Building on top of the configurations done in the previous section, a few changes can be made in the network for restricted
network access. The idea is, once we thoroughly understand how endpoints behave in the monitor mode and fix failures, we
move on with a more controlled network access.
Since in Closed mode, there is no network access prior to successful authentication, this is the right deployment mode for
dynamic VLAN assignments.
Figure19: Closed Mode
Switch Configuration for Closed Mode
Step 1 Login to the switch. On a per port basis, disable open mode configuration done in the previous section
c9300-Sw(config)#interface gigabitEthernet x/y/z

c9300-Sw(config-if)#no authentication open
Critical Authentication
When in Closed mode, the endpoints won't have network access unless they authenticate successfully or are given
fail open access because of ISE authorization policy. What if the ISE service itself is unavailable? The best practice
recommendation thereby is to configure fail open access locally on the switch.
Step 2 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 same as the default VLAN on the port. The administrator gives limited authentication
to the hosts.
c9300-Sw(config-if)#authentication event server dead action reinitialize vlan 100
Note: To support inaccessible bypass on multiple-authentication (multi-auth) ports, you can use the
authentication event server dead action reinitialize vlan vlan-id. When a new host tries to connect to
the critical port, that port is reinitialized and all the connected hosts are moved to the user-specified
access VLAN. The authentication event server dead action reinitialize vlan vlan-id interface
configuration command is supported on all host modes.
Step 3 Enable critical voice VLAN feature to allow access to IP phones when 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),
through LLDP or DHCP.
c9300-Sw(config-if)#authentication event server dead action authorize voice
Step 4 To reinitialize a session when a previously unreachable ISE server becomes available, use the authentication event
server alive action reinitialize command in interface configuration mode.
c9300-Sw(config-if)#authentication event server alive action reinitialize
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 has been configured as a
unidirectional controlled port.
Unidirectional State
The IEEE 802.1x standard defines a unidirectional controlled port, which enables a device on the network to "wake
up" a client so that it 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.
Step 5 (Optional) Allows broadcast traffic in from the network to the unauthenticated port. This assists with WoL (Wake on
LAN) process, so the network management server can wake the clients up on demand. It also assists in MAB
process for certain types of devices that doesn't generate much traffic on its own without network request from
another host.
c9300-Sw(config-if)#authentication control-direction in
MAC Limits
Limiting the number of MAC addresses on an 802.1X enabled port is not straight forward. There are couple of
options to achieve MAC limits to a certain extent:
• Host modes – There are 4 host modes that can be configured on the port and following are the details:
Host Mode Number of endpoints Interface command
Single Host 1 Voice / Data device authentication host-mode single-host
(default in IBNS 1.0)
Multi-Domain Authentication 1 Voice and 1 Data device authentication host-mode multi-domain
(MDA)
Multi-Host Mode 1 Voice and Unlimited Data authentication host-mode multi-host
(At least one MAC address
must authenticate
successfully)
Multi-Auth Mode 1 Voice and Unlimited Data authentication host-mode multi-auth
(Each MAC address must
authenticate)
When you opt for restrictive host modes such as Single-host mode or Multi-domain authentication host
modes, when an authentication violation occurs, (such as more MAC addresses appearing on the same
port) the port will be error disabled. This may require administrator’s attention to remediate the shutdown
port state. It is thereby recommended to have a restrictive, yet non-disruptive option to handle
authentication violations:
c9300-Sw(config-if)#authentication violation restrict
• Device tracking policy - The other option to limit number of endpoints from getting identity-based
services, is to use the device tracking policy. The device tracking policy can be configured to limit the
number of endpoints (IP addresses) being tracked for the IP based services (like dACL/URL-redirect /
SGTs, etc). This does not limit the number of endpoints from connecting or authenticating on the port. The
following is the configuration:
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
Note: Even though port-security interface command enforces MAC address limit, it is not compatible
with the authentication / dot1x configurations on the switchport. In general, Cisco does not recommend
enabling port security when IEEE 802.1x is enabled.
Interface Configuration Dump for Closed Mode
authentication control-direction in
authentication event server dead action reinitialize vlan 100
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication port-control auto
authentication timer inactivity server dynamic
authentication violation restrict
mab
Authoring Access Policies on ISE
It is always important to have policy goals in mind before configuring ISE access policies. In this example, we’ll have 802.1X
authentication resulting in either basic access or access to Employee segment depending up on the user’s Active Directory
group membership. The IP Phones will be authorized for voice VLAN and rest will be subject to guest portal. When the ISE
servers are unreachable, the switch will authorize newly connecting endpoints to Critical VLAN (which can be same as the
default VLAN). Here is a flow chart on the policy, most part of the decision tree and critical authorization is already configured on
the switch, the 802.1X and MAB authorization policies must be configured on ISE:
Figure20: Authentication Authorization Flow Chart
Step 1 Login to ISE and click on Policy > Policy Elements: Results
Step 2 Navigate to Authorization > Authorization Profiles and click Add
Step 3 Create a new Authorization Profile for Employee VLAN as result:
Note: The VLAN name or number that you specify in the Authorization Profile must exactly match the
VLAN name or number configured on the access switch. In this example there exists a VLAN on the
switch named Employees:
c9300-Sw#show vlan brief | inc Employee

150 Employees active
Step 4 Navigate to Policy > Policy Sets
Step 5 You can either create a new policy-set or edit the Default policy-set that comes with the ISE installation. In this
example, we will work with the Default policy set. Click on the > icon to expand the default policy set.
Step 6 Expand the default Authorization Policy
Step 7 Scroll down and create a new rule above Basic_Authenticated_Access rule
Step 8 Give a descriptive name for the policy rule and click on the + button
Step 9 If it’s your first time configuring the policy in ISE after its installation, you will see Screen-tip explaining how to use
the condition studio. Click on the ‘x’ button and you will land on the policy editor. Within the Condition Studio, click
on the field that reads ‘Click to add an attribute’
Step 10 Once the Editor options load, click on the user group icon and then select Active directory ExternalGroups
Step 11 Configure a condition to match on Active directory group of choice. In this example we will configure a condition to
match on Active Directory Group Employees
Step 12 Scroll down and click Use
Note: Within the Condition studio, in the condition Editor, there is a Save option once you configure a
condition. If you click on the Save option, you can save this condition with an arbitrary name and reuse
the condition with that name later for other authorization policies.
Step 13 Once you land back in the Authorization policy page of the policy-set, click the field under results (reading Select
from list), then choose the authorization profile created for this user group (which is EmployeeVLAN in this
example)
Step 14 Optionally you can also add a Security Group Tag as an additional authorization result.
Step 15 To adhere to our policy goals, edit the default policy to result in a web portal.
Step 16 Once the policy looks good, click the save button
Step 17 Also note, for IP Phones, there is already a policy rule by default that authorizes profiled IP Phones with voice VLAN
permission:
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 later Attribute Value Pair (AVP) is necessary to put the IP phones in to
voice VLAN on the switch. This authorization works only if there is a voice VLAN configured on the
switch access port.
Closed Mode in Action
Step 1 Login to the Catalyst switch and test AAA authentication, you must see that the Active Directory user (member of
Employee Group) will be 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"
Step 2 If you bounce the access port where the IP Phone and employee are connected, you must observe the new
authorization results as follows:
c9300-Sw#show authentication sessions interface Gi 1/0/1 details

IIF-ID: 0x19E63EED
IPv4 Address: 172.20.150.2
User-Name: harry
Status: Authorized
Domain: DATA
Oper control dir: in
Common Session ID: 65FE14AC0000002D27DEB90F
Handle: 0xd0000023
Local Policies:
Idle timeout: 65536 sec
Server Policies:
Vlan Group: Vlan: 150
SGT Value: 4
Method status list:

Method State
dot1x Authc Success
----------------------------------------
IIF-ID: 0x1AABEBEF
IPv4 Address: 172.20.101.3
User-Name: 00-64-40-B5-79-4E
Status: Authorized
Domain: VOICE
Common Session ID: 65FE14AC0000002E27DEBD9D
Handle: 0xf7000024
Local Policies:
Server Policies:
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-57f6b0d3
Method status list:

Method State
dot1x Stopped
mab Authc Success
Step 3 Login to ISE and navigate to Operations > RADIUS: Live Logs. You will notice the two endpoints being
authenticated and authorized
Step 4 Click on the Details (magnifier) icon for the specific entry in the live log and you will see the details.
Step 5 The result Overview section shows what Authorization policy rule that was hit and what was the end result
Step 6 If you scroll down to the end of the page, you will the result details under the Results section
Pre and Post Authentication Access Control with Low Impact
Naturally after gaining enough visibility in the monitor mode, the next step is to enforce restricted access. While in Closed mode
there is no access (even IP address assignment) before successful authentication, there are scenarios where some level of
network access must be granted prior to authentication. PXE boot environments are a classic example. On top of open access
(monitor mode) IP ACLs can be used to control pre and post authentication access. While pre-authentication access control can
be done via a port based IP Access Control List (ACL), the post authentication access control can be done via downloadable or
named, ACLs.
Note: Dynamic VLAN assignment is not a recommended authorization option for Low-Impact Mode. Since
endpoints acquire IP address prior to network authentication in the default VLAN, change in the VLAN assignment
forces them to renew their IP address(s), which may not happen automatically, thereby locking them out of the
network in spite of an authorized access permission as per ISE policy.
Some endpoint types have intelligence to detect network changes. The Windows workstation for instance, will
upon receiving an EAP-Success from the switch, attempts to ping the default gateway (thrice within seconds) with
TTL=1. If the router responds, it assumes no change in VLAN and remains with its IP address, if not it releases the
IP address and re-discovers a new one. This was introduced in Windows XP SP2 with the following KB:
KB822596: DHCP does not obtain a new address when EAP reauthenticates across access points with IP
subnets that differ
The behavior with OSX is similar, but when the system receives an EAP success, it tries to reach the same DHCP
server to renew the same IP address, thrice with 1-minute wait time between the attempts.
Critical Authorization in Low Impact Mode
In open mode, we do not need critical authorization, because the port is always open for full network access. In closed mode,
we normally deal with VLAN authorizations and thereby we can apply a critical VLAN when endpoints can’t authenticate during a
server failure. In low-impact mode, we need to have a port ACL to control pre-authentication access, which leads to a problem
during AAA server unreachability. With IBNS 1.0, we can apply critical VLAN for endpoints trying to authenticate when the ISE
service is down, but the Pre-Auth ACL on the interface will still block traffic from the authenticating endpoints. IBNS 2.0
framework offers switch-local template-based authorization and thereby facilitates the idea of critical ACL; Access Control Lists
that can be applied during a critical authorization state. IBNS 2.0 thereby, because of its effectiveness in handling failure
scenarios is a recommended configuration mode to deal with low-impact mode and closed modes.
Figure21: Use of IBNS 1.0 and 2.0
Configuring and Understanding IBNS 2.0 Policy

One of the simplest way to configure IBNS 2.0 is to convert an existing IBNS 1.0 configuration on the switch. However, it is
recommended to have a composite configuration in IBNS 1.0 style, so that system can generate a best possible policy
configuration in the new-style. Note, that when you convert the configurations, there will be a policy-map (and set of class-
maps and service-templates) that will be configured for every single port that has identity related configurations. Thereby the
recommendation is to covert a single port IBNS 1.0 configuration to IBNS 2.0, in a lab possibly and then upon greater comfort
deploy it in production.
Step 1 Login to the switch. Have it pre-configured for best practice global configurations and Closed mode interface
configuration on just one interface.
Step 2 Execute the IBNS 1.0 to 2.0 conversation command
c9300-Sw#authentication display new-style
Please note that while you can revert to legacy style

configuration at any time unless you have explicitly
entered new-style configuration, the following caveats
should be carefully read and understood.
(1) If you save the config in this mode, it will be written

to NVRAM in NEW-style config, and if you subsequently
reload the router without reverting to legacy config and
saving that, you will no longer be able to revert.
(2) In this and legacy mode, Webauth is not IPv6-capable. It

will only become IPv6-capable once you have entered new-
style config manually, or have reloaded with config saved
in 'authentication display new' mode.
(3) 'Default' and 'rollback' commands should not be used in this

display mode. Either remain in legacy display mode or switch
to new-style configuration mode before use.
Step 3 You will notice on the interface that the identity configurations have changed:
c9300-Sw#show running-config interface Gi 1/0/1

Building configuration...
Current configuration : 523 bytes

!
access-session control-direction in
access-session closed
access-session port-control auto
mab
service-policy type control subscriber POLICY_Gi1/0/1
end
Note: The authentication display new-style command converts an existing IBNS 1.0 configuration to
IBNS 2.0. The new-style configurations can be reverted back to the old style with authentication display
legacy exec-mode command. If in new-style, any changes are made to the policy-map or any other
IBNS 2.0 specific commands, or if the system is reloaded with new-style configurations written to the
startup-configuration, then you won’t be able to revert back to IBNS 1.0 style configurations from IBNS
2.0
Step 4 Copy the policy-map and class-maps to a text editor and customize the configuration
c9300-Sw#show running-config partition policy-map


!
Configuration of Partition - policy-map
!
!
!
policy-map type control subscriber POLICY_Gi1/0/1
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x priority 10
<Output truncated>
c9300-Sw#show running-config partition class-map


!
Configuration of Partition - class-map
!
!
class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST
match result-type aaa-timeout
match authorization-status authorized
!
<Output trunckated>
Step 5 Convert the switch’s authentication configuration mode to new-style (aka IBNS 2.0 style)
c9300-Sw#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
c9300-Sw(config)#
c9300-Sw(config)#authentication convert-to new-style
This operation will permanently convert all relevant authentication commands to their CPL control-
policy equivalents. As this conversion is irreversible and will disable the conversion CLI
'authentication display [legacy|new-style]', you are strongly advised to back up your current
configuration before proceeding.
Do you wish to continue? [yes]: yes
c9300-Sw(config)#
Step 6 Configure a Critical ACL
c9300-Sw(config)#ip access-list extended IPV4_CRITICAL_ACL

c9300-Sw(config-ext-nacl)#permit ip any any
c9300-Sw(config-ext-nacl)#exit
Step 7 Create a Service-Template referencing the Critical ACL
c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS
c9300-Sw(config-service-template)#description ** Access Policy For IAB **
c9300-Sw(config-service-template)#access-group IPV4_CRITICAL_ACL
Step 8 Create two new class-maps to match on the new service-template
c9300-Sw(config)#class-map type control subscriber match-any IN_CRITICAL_AUTH

c9300-Sw(config-filter-control-classmap)#match activated-service-template CRITICAL_AUTH_ACCESS
c9300-Sw(config-filter-control-classmap)#match activated-service-temp DEFAULT_CRITICAL_VOICE_TEMPLATE
c9300-Sw(config-filter-control-classmap)#exit
c9300-Sw(config)#
c9300-Sw(config)#class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
c9300-Sw(config-filter-control-classmap)#match activated-service-template CRITICAL_AUTH_ACCESS
Step 9 Review the two service-template configurations before configuring the class-maps
c9300-Sw#show running-config | section service-template

...
service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
voice vlan
service-template CRITICAL_AUTH_ACCESS
description ** Access Policy For IAB **
access-group IPV4_CRITICAL_ACL
...
Step 10 Ensure the following class-maps exists in the system before configuring a new policy-map for low-impact mode
class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST

match authorization-status authorized
!
class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_HOST
match authorization-status unauthorized
!
class-map type control subscriber match-all DOT1X
match method dot1x
!
class-map type control subscriber match-all DOT1X_FAILED
match method dot1x
match result-type method dot1x authoritative
!
class-map type control subscriber match-all DOT1X_MEDIUM_PRIO
match authorizing-method-priority gt 20
!
class-map type control subscriber match-all DOT1X_NO_RESP
match method dot1x
match result-type method dot1x agent-not-found
!
class-map type control subscriber match-all DOT1X_TIMEOUT
match method dot1x
match result-type method dot1x method-timeout
!
class-map type control subscriber match-any IN_CRITICAL_AUTH
match activated-service-template CRITICAL_AUTH_ACCESS
match activated-service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
!
class-map type control subscriber match-any IN_CRITICAL_VLAN
match activated-service-template CRITICAL_AUTH_VLAN_Gi1/0/1
!
class-map type control subscriber match-all MAB
match method mab
!
class-map type control subscriber match-all MAB_FAILED
match method mab
match result-type method mab authoritative
!
class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
match activated-service-template CRITICAL_AUTH_ACCESS
!
class-map type control subscriber match-none NOT_IN_CRITICAL_VLAN
match activated-service-template CRITICAL_AUTH_VLAN_Gi1/0/1
Step 11 Configure a new policy-map as per below (in global configuration mode)
The highlighted part of the policy-map PORT-AUTH-POLICY, indicates the changes done to the system generated
policy
policy-map type control subscriber PORT-AUTH-POLICY

event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 clear-authenticated-data-hosts-on-port
20 activate service-template CRITICAL_AUTH_ACCESS
30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
40 authorize
50 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
20 authorize
30 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
40 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
10 terminate dot1x
20 terminate mab
event agent-found match-all
10 terminate mab
event aaa-available match-all
10 class IN_CRITICAL_AUTH do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_AUTH do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 clear-session
event authentication-success match-all
event violation match-all
10 restrict
!
Here is a detailed explanation of the policy
Additional Best Practice Configurations for IBNS 2.0
Step 1 Copy the interface configuration from the switchport and configure an interface template as per below
c9300-Sw(config)#template PORT-AUTH-TEMPLATE
c9300-Sw(config-template)#description ** Endpoints and Users **
c9300-Sw(config-template)#switchport access vlan 100
c9300-Sw(config-template)#switchport mode access
c9300-Sw(config-template)#switchport voice vlan 101
c9300-Sw(config-template)#authentication periodic
c9300-Sw(config-template)#authentication timer reauthenticate server
c9300-Sw(config-template)#access-session control-direction in
c9300-Sw(config-template)#access-session port-control auto
c9300-Sw(config-template)#mab
c9300-Sw(config-template)#dot1x pae authenticator
c9300-Sw(config-template)#spanning-tree portfast
c9300-Sw(config-template)#service-policy type control subscriber PORT-AUTH-POLICY
c9300-Sw(config-template)#end
Note: Certain interface commands are not supported within Interface templates today. They need to be
configured on the port explicitly. The following are the caveats:
Defect ID Un supported command(s)

CSCvd76728 ‘dot1x timeout tx-period 7’, ‘dot1x max-reauth-req 3’
CSCvd77095 ‘no lldp transmit’
CSCvd77088 ’device-tracking’
CSCvd77097 ‘spanning-tree portfast’
CSCvd78152 ‘ip verify source’
CSCvd78154 ‘ip access-group’
Note: Notice that the access-session closed command got from the conversion is being omitted in the
interface template configuration. This is because, this section focusses on low-impact mode, which is
minor variation to open mode and in IBNS 2.0 the default port mode is open mode. If you wish to move the
port to closed mode, then the access-session closed interface command must be configured explicitly
either within the interface template or on the interface directly.
Step 2 Default the port configuration and apply the interface template along with other supporting commands for IBNS
c9300-Sw(config)#default interface GigabitEthernet1/0/1

Interface GigabitEthernet1/0/1 set to default configuration
c9300-Sw(config)#
c9300-Sw(config)#interface GigabitEthernet1/0/1
c9300-Sw(config-if)#source template PORT-AUTH-TEMPLATE
c9300-Sw(config-if)#spanning-tree portfast
c9300-Sw(config-if)#dot1x timeout tx-period 7
c9300-Sw(config-if)#dot1x max-reauth-req 3
c9300-Sw(config-if)#ip access-group IPV4_PRE_AUTH_ACL in
Step 3 Verify the interface configuration
c9300-Sw#show running-config interface GigabitEthernet 1/0/1


!
ip access-group IPV4_PRE_AUTH_ACL in
source template PORT-AUTH-TEMPLATE
end
Step 4 Check the cumulative configuration applied on the port in run-time
c9300-Sw#show derived-config interface GigabitEthernet 1/0/1

Derived configuration : 525 bytes

!
mab
service-policy type control subscriber PORT-AUTH-POLICY
end
Step 5 Notice some minor changes to global configurations
c9300-Sw#show running-config aaa | include accounting

aaa accounting Identity default start-stop group ISE
Note: Global AAA and RADIUS server configuration for IBNS 1.0 and IBNS 2.0 are very alike, barring a few
minor differences.
aaa accounting dot1x command will be converted to aaa accounting Identity in IBNS 2.0 style.
authentication mac-move permit command is default in IBNS 2.0 and thereby the configuration won’t
show up in the running configuration. If you want to disable mac-move, then you need to configure
‘access-session mac-move deny’ explicitly in the global configuration mode.
device-sensor accounting command is replaced with access-session attributes filter-list command set
Switch Global Configuration Dump for AAA, RADIUS and More in IBNS 2.0
ip domain name isedemo.lab

!
interface Vlan254
ip address 172.20.254.101 255.255.255.0
!
aaa new-model
aaa session-id common
!
radius server ISE01
key ISEisC00L
!
radius server ISE02
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
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting Identity default start-stop group ISE
!
!
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_List
!
access-session acl default passthrough
!
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
!
ip access-list extended BLOCKHOLE
!
ip access-list extended IPV4_CRITICAL_ACL
permit ip any any
!
ip access-list extended IPV4_PRE_AUTH_ACL
permit udp any any eq bootpc
permit udp any any eq domain
deny ip any any
!
Downloadable ACL Authorization
Step 1 Login to ISE and navigate to Policy > Results: Authorization > Downloadable ACLs. Click Add
Step 2 Create a dACL each for Employees and IP Phones. Once the dACL rules are written they can be validated by clicking
the Check DACL Syntax option. Save the dACLs by clicking the Submit button.
Note-1: In this example, the Employees are denied access to specific subnet (Let’s say payment card
network) and are given access to everything else. The IP Phones have access to the subnet where Call
Manager, DHCP, DNS servers and other peers in the default and voice VLANs reside, rest of the
network access is denied.
Note-2: In terms of the Access Control Entries (ACEs) for the downloadable ACLs, the recommendation
is to keep it small so that it is easy to download the policy to the network device and also small ACLs
can optimize the TCAM (Ternary Content Addressable Memory) memory consumption on the access
switches. The best practice limit for dACLs are 64 ACEs (64 lines).
Step 3 Click on Authorization Profile and Click Add
Step 4 Create a new Authorization Profile and reference the Employee ACL. Click Submit once done
Step 5 Repeat the same procedure for the Voice ACL. However, for IP Phones, you need to check the Voice Domain
Permission too. Click Submit once done.
Step 6 Navigate to the ISE authorization policy page for Employees and IP Phones (Your custom policy-set if configured or
the default policy set accessible via Policy > Policy Sets)
Step 7 Update the Employee and IP Phone authorization rule as per below and save the configuration.
Validating ACL Authorization / Low-Impact Mode
Step 1 Within ISE, navigate to Operations > RADIUS: Live Logs, you will notice that both the Employee computer and the IP
Phones have dACL authorization applied to them
Step 2 Click on the details for the ACL entry
Step 3 In the details page, if you scroll down and look at the results, you will notice individual dACL rules that are
downloaded to the switch
Step 4 Login 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 now show access-session in IBNS 2.0
c9300-Sw#show access-session interface Gi 1/0/1 details

IIF-ID: 0x1639E95C
IPv4 Address: 172.20.101.3
User-Name: 00-64-40-B5-79-4E
Status: Authorized
Domain: VOICE
Common Session ID: 65FE14AC0000003532D7D09C
Acct Session ID: 0x0000002b
Handle: 0x6800002b
Current Policy: PORT-AUTH-POLICY
Local Policies:
Server Policies:
ACS ACL: xACSACLx-IP-VoiceACL-5aee9aa7
Method status list:

Method State
dot1x Stopped
mab Authc Success
----------------------------------------
IIF-ID: 0x1645C323
IPv4 Address: 172.20.100.10
User-Name: harry
Status: Authorized
Domain: DATA
Common Session ID: 65FE14AC0000003432D7C631
Acct Session ID: 0x0000002a
Handle: 0x7d00002a
Current Policy: PORT-AUTH-POLICY
Local Policies:
Server Policies:
SGT Value: 4
ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60
Method status list:

Method State
dot1x Authc Success
Note: The dACL names when downloaded the switch will be appended with session timestamps. For
instance, EmployeeAccessACL on ISE becomes xACSACLx-IP-EmployeeAccessACL-5aee9a60 on the
switch when downloaded.
Step 5 You can check the downloaded ACLs on the switch with the following show command:
c9300-Sw#show ip access-lists | section xACSACLx-IP-

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
Extended IP access list xACSACLx-IP-VoiceACL-5aee9aa7
1 permit ip any 172.20.254.0 0.0.0.255
2 permit ip any 172.20.100.0 0.0.0.255
3 permit ip any 172.20.101.0 0.0.0.255
4 deny ip any any
Step 6 Further you can run platform specific exec command(s) to understand what ACLs are applicable for specific
endpoints. Here is an example for Catalyst 9300:
In the example below, we understand 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:
c9300-Sw#show platform software fed switch 1 acl interface | begin 1/0/1

INTERFACE: GigabitEthernet1/0/1
MAC 0000.0000.0000
########################################################
intfinfo: 0x7fa8fc02cba8
Interface handle: 0xaa000027
Interface Type: Port
IIF ID: 0x8
Input IPv6: Policy Handle: 0x990000b6
Policy Name: sisf v6acl 0001DF9F
CG ID: 16
CGM Feature: [0] acl
Bind Order: 0
Input IPv4: Policy Handle: 0xef00007a

Policy Name: IPV4_PRE_AUTH_ACL
CG ID: 19
CGM Feature: [0] acl
Bind Order: 0
INTERFACE: Client MAC 0064.40b5.794e

MAC 0064.40b5.794e
########################################################
intfinfo: 0x7fa8fc036638
Interface handle: 0xc2000085
Interface Type: Group
IIF ID: 0x1c314c66
Input IPv4: Policy Handle: 0x6a0000ba
Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-VoiceACL-5aee9aa7:
CG ID: 4880
CGM Feature: [35] acl-grp
Bind Order: 0
INTERFACE: Client MAC 0050.56a7.fa8a

MAC 0050.56a7.fa8a
########################################################
intfinfo: 0x7fa8fc058078
Interface handle: 0xf9000084
Interface Type: Group
IIF ID: 0x1debb70b
Input IPv4: Policy Handle: 0x640000b7
Policy Name: IPV4_PRE_AUTH_ACL:xACSACLx-IP-EmployeeAccessACL-5aee9a60:
CG ID: 4624
CGM Feature: [35] acl-grp
Bind Order: 0
Note: Similar ACL programming information can be got on Catalyst 3650 / 3850 switch platforms with
‘show platform acl le’ exec mode command.
In the other platforms, just ‘show ip access-list interface <interface-id>’ will output the cumulative list of
Access Control Entries (ACE) applied on that 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 next time. The idea is to grant role-based access during critical
condition, instead of applying a common critical authorization.
Figure22: Role Based Critical Authorization
IOS Changes for Role Based Critical Authorization

In this example, a User-Role names ‘Employees’ is created which is exactly the Security Group Tag name on ISE. When
Employee users authenticate first time, the user-role will be downloaded from ISE and later when the same users connect to
network when ISE service is unreachable, the same network access authorization is applied locally by the Switch.
Step 1 Login to the switch and configure IP ACL for Employee users. Note, the ACL rules are same as the downloadable
ACL configured on ISE for 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
Step 2 Configure a Service Template that exactly matches the ISE authorization policy result in ISE for Employee user group
c9300-Sw(config)#service-template EMPLOYEE_CRITICAL_AUTH_ACCESS
c9300-Sw(config-service-template)#description ** Policy For Employees during IAB **
c9300-Sw(config-service-template)#access-group IPV4_EMPLOYEE_CRITICAL_ACL
c9300-Sw(config-service-template)#sgt 4
Here is the ISE policy for Employee user group
Step 3 Create a class-map to match on ‘Employee’ user-role and AAA down condition
c9300-Sw(config)#class-map type control subscriber match-all AAA_DOWN_UNAUTHD_EMPLOYEE

c9300-Sw(config-filter-control-classmap)#match result-type aaa-timeout
c9300-Sw(config-filter-control-classmap)#match authorization-status unauthorized
c9300-Sw(config-filter-control-classmap)#match user-role Employees
Step 4 Modify the two class-maps that evaluate critical authorization conditions. Note, the changes are highlighted below
c9300-Sw(config)#class-map type control subscriber match-any IN_CRITICAL_AUTH

c9300-Sw(config-filter-control-classmap)#match activated-service-temp CRITICAL_AUTH_ACCESS
c9300-Sw(config-filter-control-classmap)#match activated-service-temp EMPLOYEE_CRITICAL_AUTH_ACCESS
c9300-Sw(config)#
c9300-Sw(config)#class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
c9300-Sw(config-filter-control-classmap)#match activated-service-temp CRITICAL_AUTH_ACCESS
c9300-Sw(config-filter-control-classmap)#match activated-service-templ EMPLOYEE_CRITICAL_AUTH_ACCESS
Step 5 Either modify existing policy or create a new policy-map to match on the user-role and apply the new service-
template when the ISE service is unavailable for the Employee devices. In this example we create a new policy-map
(in global configuration mode) with minor changes compared to the previous ones. The changes are highlighted
below
policy-map type control subscriber PORT-AUTH-POLICY-II

5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
10 class AAA_DOWN_UNAUTHD_EMPLOYEE do-until-failure
20 activate service-template EMPLOYEE_CRITICAL_AUTH_ACCESS
30 authorize
15 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
20 activate service-template CRITICAL_AUTH_ACCESS
30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
40 authorize
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
20 authorize
10 terminate dot1x
40 class MAB_FAILED do-until-failure
10 terminate mab
10 terminate dot1x
20 terminate mab
event agent-found match-all
10 terminate mab
event aaa-available match-all
10 class IN_CRITICAL_AUTH do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_AUTH do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 clear-session
event authentication-success match-all
event violation match-all
10 restrict
Step 6 The new policy can now be applied to the interface
c9300-Sw(config)#template PORT-AUTH-TEMPLATE
c9300-Sw(config-template)#description ** Endpoints and Users **
c9300-Sw(config-template)#switchport access vlan 100
c9300-Sw(config-template)#switchport mode access
c9300-Sw(config-template)#switchport voice vlan 101
c9300-Sw(config-template)#authentication periodic
c9300-Sw(config-template)#authentication timer reauthenticate server
c9300-Sw(config-template)#access-session control-direction in
c9300-Sw(config-template)#access-session port-control auto
c9300-Sw(config-template)#mab
c9300-Sw(config-template)#dot1x pae authenticator
c9300-Sw(config-template)#spanning-tree portfast
c9300-Sw(config-template)#no service-policy type control subscriber PORT-AUTH-POLICY
c9300-Sw(config-template)#service-policy type control subscriber PORT-AUTH-POLICY-II
c9300-Sw(config-template)#end
ISE Authorization with User-Role
Step 1 Login to ISE and navigate to Policy > Policy Elements: Results. Click Authorization > Authorization Profiles. Click
Add, and create a new authorization profile with Cisco AV Pair: role=<user-role>, as per below
Step 2 Modify the Employee Authorization rule as per below
Step 3 Authenticate / re-authenticate Employee user. You will now see a new session info on the switch titled User-Role
c9300-Sw#show access-session interface gigabitEthernet 1/0/1 details

IIF-ID: 0x1E27B669
IPv4 Address: 172.20.100.10
User-Name: harry
User-Role: Employees
Status: Authorized
Domain: DATA
Common Session ID: 65FE14AC0000005A3912107F
Handle: 0xbb000050
Current Policy: PORT-AUTH-POLICY-II
Local Policies:
Server Policies:
SGT Value: 4
ACS ACL: xACSACLx-IP-EmployeeAccessACL-5aee9a60
Method status list:

Method State
dot1x Authc Success
Step 4 Also observe the User-role being cached on the switch
c9300-Sw#show access-session cache

Access session cache details
----------------------------------------
Device-type:
User-role: Employees
Protocol-map: 00000000
----------------------------------------
<Output truncated>
Step 5 Observe the IP ACL applied for 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
Step 1 Make sure the ISE servers are unreachable from the switch
c9300-Sw#show aaa servers | include id|State

State: current DEAD, duration 107s, previous duration 555708s
Platform State from SMD: current DEAD, duration 106s, previous duration 556543s
State: current DEAD, duration 92s, previous duration 555723s
Platform State from SMD: current DEAD, duration 91s, previous duration 556558s
Step 2 Connect the Employee PC again now when the server is unreachable. You will notice that the switch has applied the
same policies that ISE would apply, but locally this time, based on the cached user role

IIF-ID: 0x1413C541
IPv4 Address: 172.20.100.10
Status: Authorized
Domain: UNKNOWN
Common Session ID: 65FE14AC0000005C392B1226
Handle: 0x43000052
Local Policies:
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-1: Similar local policies can be configured for various other users and device-types.
Note-2: The access-session cache is cleared either when switch reloads or the endpoint does EAPOL-
Logoff. EAPOL-Logoff typically happens in most of the operating systems when user logs off the
system.
Differentiated Authentication (With IBNS 2.0)
There are instances when from the same network device, AAA transactions must be done with distinct groups of RADIUS
servers. This is very typical in the wireless network, where the 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. There are couple of possible
use cases for differentiated authentication:
1. Separate MAB and 802.1X transactions – Though not a common or recommended practice, if there is a need for
separating MAB and 802.1X transactions from the same switch interface, differentiated authentication feature can be
used.
2. Separate RADIUS servers based on switchports – Specific switchports can be configured for IBNS 2.0 policy to talk to
separate ISE servers with differentiated authentication feature.
Figure23: Differentiated Authentication
This example briefs you how to modify the switch configuration to perform differentiated authentication, so that specific set of
interfaces on the switch talk to specific ISE servers.
Switch Configuration for Differentiated Authentication
Global AAA and RADIUS Server Definition
Step 1 Before authoring the policy-map and applying it on the interface, we need to configure the global AAA and RADIUS
parameters to distinguish the two AAA server groups. Define two or more distinct RADIUS servers (in IOS global
configuration mode)
radius server ISE01

key ISEisC00L
!
radius server ISE02
key ISEisC00L
!
Step 2 Define two server groups and method-lists for AAA (in IOS global configuration mode)
aaa group server radius ISE-CUBE-1

server name ISE01
!
aaa group server radius ISE-CUBE-2
server name ISE02
!
!
aaa authentication dot1x default group radius
aaa authentication dot1x AAA_LIST1 group ISE-CUBE-1
aaa authentication dot1x AAA_LIST2 group ISE-CUBE-2
!
aaa authorization network default group radius
aaa authorization network AAA_LIST1 group ISE-CUBE-1
!
aaa accounting Identity AAA_LIST2 start-stop group ISE-CUBE-2
aaa accounting Identity AAA_LIST1 start-stop group ISE-CUBE-1
!
aaa accounting network AAA_LIST1 start-stop group ISE-CUBE-1
aaa accounting network AAA_LIST2 start-stop group ISE-CUBE-2
!
Step 3 (Optional) The following commands makes the switch, simultaneously send accounting records to the first server in
each group.
aaa accounting Identity default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2
aaa accounting network default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2
aaa accounting system default start-stop broadcast group ISE-CUBE-1 group ISE-CUBE-2
Step 4 All individual radius servers must be defined as CoA servers

auth-type any
IBNS 2.0 Policy and Interface Configuration
Step 5 Configure two IBNS 2.0 policies similar to PORT-AUTH-POLICY and make the following changes
policy-map type control subscriber PORT-AUTH-POLICY-CUBE1

10 authenticate using dot1x aaa authc-list ISE-CUBE-1 authz-list ISE-CUBE-1 priority 10
...
...
10 terminate dot1x
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

...
...
10 terminate dot1x
...
Step 6 Configure the interface templates to reference these two policy-maps
template PORT-AUTH-TEMPLATE-CUBE1
description ** Endpoints and Users on Cube-1 ISE **
mab
service-policy type control subscriber PORT-AUTH-POLICY-CUBE1
!
template PORT-AUTH-TEMPLATE-CUBE2
description ** Endpoints and Users on Cube-2 ISE **
mab
service-policy type control subscriber PORT-AUTH-POLICY-CUBE2
Step 7 Source the interface template along with the other interface specific commands for the desired ports
c9300-Sw(config)#interface range GigabitEthernet 1/0/1 - 11

c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE1
c9300-Sw(config-if-range)#exit
c9300-Sw(config)#
c9300-Sw(config)#interface range GigabitEthernet 1/0/12 - 22
c9300-Sw(config-if-range)#source template PORT-AUTH-POLICY-CUBE2
c9300-Sw(config-if-range)#exit
Differentiated Authentication for Auth Methods
Step 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
policy-map type control subscriber PORT-AUTH-POLICY-DIFF-AUTH

...
...
10 terminate dot1x
...
ISE Authorization Profile for Differentiated dACL

When two or more ISE deployments are managed in an environment and differentiated authentication is used, certain
authorization from ISE may not work well because, they will 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 since it’s not a standard session-start, the
switch would go and query ISE-Cube-1 for the ACEs. If the dACL configurations are not consistent across the ISE deployments,
then the authorization would fail. The fix is to use an additional Cisco AV Pair in the authorization to inform the switch wh ich
server group to reach 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.

!
Identity Based Network Access in IPv6 Wired Networks
IPv6 is an inevitable future and most of the ISE deployments that are on IPv4 needs to be migrated to IPv6 sometime. Cisco IOS
has the following IPv6 based identity features in contrast to IPv4
Features 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.4)
Open Mode
Yes Yes
(No Authorization)
Closed Mode
Yes Yes
(With VLAN assignments)
Low-Impact Mode Partial

Yes
(With ACL authorizations) (Limited platform support, No dACL*)
Downloadable ACL Yes No
URL Redirection Yes No
Security Group Tags Yes Yes
* - Only Filter-ID and Per-User ACL supported on Catalyst 3650, 3850 and 9300 platforms
IPv6 Network Readiness
Step 1 Login to the ISE console (via SSH if enabled) and configure the IPv6 address to the interface
ise01/admin# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.
ise01/admin(config)# interface GigabitEthernet 0
ise01/admin(config-GigabitEthernet)# ipv6 enable
ise01/admin(config-GigabitEthernet)# ipv6 address 2001:20:254::21/64
Changing the IPV6 address may result in undesired side effects on

any installed application(s).
Are you sure you want to proceed? Y/N [N]: Y
Stopping ISE Monitoring & Troubleshooting Log Collector...
Stopping ISE Monitoring & Troubleshooting Log Processor...
PassiveID WMI Service is disabled
<Output truncaked>
Note-1: In a distributed ISE deployment, each Policy Administration Node (PAN) and Policy Services
Node(s) (PSN) must be configured for an IPv6 address
Note-2: All the ISE services on the node restarts once a new IPv6 address is configured
Step 2 Login to the access switch and enable IPv6 unicast routing
c9300-Sw(config)#ipv6 unicast-routing
Step 3 Ensure there is an IPv6 address for the RADIUS source interface
c9300-Sw#show running-config interface vlan 254


!
interface Vlan254
ip address 172.20.254.101 255.255.255.0
ipv6 address 2001:20:254::101/64
ipv6 enable
end
Note: Ensure that end-to-end IPv6 routing is configured so that the access switch can talk to ISE node(s)
over IPv6 protocol.
Step 4 Ensure that the access switch can ping ISE node(s) over IPv6
c9300-Sw#ping ipv6 2001:20:254::21

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:20:254::21, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Step 5 Just to recall, in 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
c9300-Sw#show running-config | begin device-tracking

no protocol udp
tracking enable
!
Note: On 3650 and 3850 switch platforms running IOS version prior to 16.1, the following commands
must be configured 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
!
description ** Uplink Port to Distribution Switch **
ipv6 snooping attach-policy SNOOP-v6
ip dhcp snooping trust
IOS Identity Configurations for IPv6
In this section the global configuration defined under Switch Global Configuration Dump for AAA, RADIUS and More in IBNS 2.0
section will be modified for IPv6
Step 1 Change the RADIUS server configurations from IPv4 to IPv6

c9300-Sw(config-radius-server)#address ipv6 2001:20:254::21 auth-port 1812 acct-port 1813
c9300-Sw(config-radius-server)#no address ipv4 172.20.254.21 auth-port 1812 acct-port 1813
c9300-Sw(config)#

c9300-Sw(config-radius-server)#address ipv6 2001:20:254::22 auth-port 1812 acct-port 1813
c9300-Sw(config-radius-server)#no address ipv4 172.20.254.22 auth-port 1812 acct-port 1813
Step 2 Perform similar configuration changes for RADIUS CoA servers
c9300-Sw(config)#aaa server radius dynamic-author

c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::21 server-key ISEisC00L
c9300-Sw(config-locsvr-da-radius)#client 2001:20:254::22 server-key ISEisC00L
c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.21 server-key ISEisC00L
c9300-Sw(config-locsvr-da-radius)#no client 172.20.254.22 server-key ISEisC00L
c9300-Sw(config-locsvr-da-radius)#end
Step 3 Ensure that the servers are reachable and are marked ‘Up’
c9300-Sw#show aaa servers | include RADIUS|State

RADIUS: id 1, priority 1, host 2001:20:254::21, auth-port 1812, acct-port 1813
RADIUS: id 2, priority 2, host 2001:20:254::22, auth-port 1812, acct-port 1813
Low-Impact Mode with IPv6 Per-User ACL
Step 1 Configure a pre-authentication IPv6 Access Control List
c9300-Sw(config)#ipv6 access-list IPV4_PRE_AUTH_ACL

c9300-Sw(config-ipv6-acl)#permit udp any any eq bootpc
c9300-Sw(config-ipv6-acl)#permit udp any any eq domain
c9300-Sw(config-ipv6-acl)#deny ipv6 any any
The policy is very similar to the IPv4 Pre-Authentication ACL configured earlier
c9300-Sw#show ip access-lists IPV4_PRE_AUTH_ACL

Extended IP access list IPV4_PRE_AUTH_ACL
10 permit udp any any eq bootpc
20 permit udp any any eq domain
30 deny ip any any
c9300-Sw#
c9300-Sw#show ipv6 access-list IPV6_PRE_AUTH_ACL
IPv6 access list IPV6_PRE_AUTH_ACL
permit udp any any eq bootpc sequence 10
permit udp any any eq domain sequence 20
deny ipv6 any any sequence 30
Step 2 Configure a critical ACL
c9300-Sw(config)#ipv6 access-list IPV6_CRITICAL_ACL

c9300-Sw(config-ipv6-acl)#permit ipv6 any any
The policy 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
Step 3 Add the IPv6 critical ACL under CRITICAL_AUTH_ACCESS service-template
c9300-Sw(config)#service-template CRITICAL_AUTH_ACCESS
c9300-Sw(config-service-template)#access-group IPV6_CRITICAL_ACL
c9300-Sw(config-service-template)#end
c9300-Sw#show running-config | begin service-template
...
service-template CRITICAL_AUTH_ACCESS
description ** Access Policy For IAB **
!
Step 4 Apply the Pre-authentication ACL on the interface
c9300-Sw(config)#interface gigabitEthernet 1/0/1

c9300-Sw(config-if)#ipv6 traffic-filter IPV6_PRE_AUTH_ACL in
c9300-Sw#
c9300-Sw#show running-config interface GigabitEthernet 1/0/1

!
ipv6 traffic-filter IPV6_PRE_AUTH_ACL in
source template PORT-AUTH-TEMPLATE
end
Step 5 Login to ISE and modify the Network Devices configuration for the Catalyst Switch, to whitelist on IPv6 address.
Go to Administration > Network Resources: Network Devices. Click on the specific switch name, then configure
the IPv6 address and save the configuration.
Step 6 Next, navigate to Policy > Policy Elements: Results > Authorization > Authorization Profiles and configure an
authorization profile for Per-User ACL as per below
The two rules configured in this example 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 available for IPv6 today are
Filter-ID and Service-Templates:
Filter ID Service-Template Per-User-ACL

ACL local to Switch ACL local to Switch ACL download from ISE
IPv4 Yes Yes Yes

Cisco AVP:
Cisco AVP:
“subscriber:service-
RADIUS Attribute / AVP Filter-ID=ACL_Name.in “ip:inacl#1=permit ipany
name=
any”
TEMPLATE_NAME”
IPv6 Yes Yes Yes
Cisco AVP:
Cisco AVP:
Filter-ID = “subscriber:service-
RADIUS Attribute / AVP “ipv6:inacl#1=permit ipv6
ACL_NAME.in.ipv6 name=
any any”
TEMPLATE_NAME”
Step 7 Reference this Authorization profile as one of the authorization results for Employee user group
Step 8 Re-authenticate the Employee workstation and notice the IPv6 ACL download and authorization for the network
access session

IIF-ID: 0x1DD98B5E
IPv6 Address: 2001:20:100:0:4d0d:2a03:cd86:7241
2001:20:100:0:e55d:20e1:8f:d008
fe80::e55d:20e1:8f:d008
IPv4 Address: 172.20.100.13
User-Name: harry
Status: Authorized
Domain: DATA
Common Session ID: 000000000000001142C99F70
Handle: 0x03000007
Server Policies:

SGT Value: 4
ACS ACL: xACSACLx-IP-EmployeeAccessACL-5af1634e
Per-User ACL: Gi1/0/1#v6#1dd98b5e
: deny ipv6 any 2001:20:199::/64
: permit ipv6 any any
Method status list:

Method State
dot1x Authc Success
802.1X For Cisco IP Phones
There is nothing unique about 802.1X on IP Phones. They use similar protocols and authenticate using 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. The IP phones must present a password or X.509 digital certificate to authenticate successfully.
IP Phones use EAP-MD5 for password authentication, which is considered weak in contrast 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 of
authentication.
MICs versus LSCs
Figure24: MIC V/S LSC
Cisco IP Phones support two types of X.509 certificates: The Manufacturing Installed Certificate (MIC) and the Locally Significant
Certificate (LSC).
MIC as the name indicates, are the certificates that are pre-installed on the IP Phones and cannot be deleted / modified by the
administrators. They 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, but it does not validate if it is a company owned asset. Anyone can connect a
personal device that has Cisco Manufacturing CA signed certificate on it and gain network access.
LSC 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 provides greater security due to its local significance
to a given environment.
The following section covers Cisco IP Phone authentication using digital certificates.
Basic Call Manager and Network Settings

Call Manager Basic Settings
Step 1 Login to the Cisco Unified Communications Manager (CUCM):
Step 2 Go to System > Cisco Unified CM
Step 3 Click Find, the CUCM server will load. Click on the CUCM server listing
Step 4 Ensure there are device and line templates, phone numbers configured and Auto-registration is enabled
IP Phone CUCM Discovery Configuration
Step 5 The 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 CUCM server IP address. Here
is an example of the configuration done in the Windows DHCP server
Follow cisco.com guide Configuring Windows 2000 DHCP Server for Cisco CallManager for more specific steps
Step 6 The CUCM wouldn't by default serve the TFTP requests, the services need to be enabled explicitly. On the right
hand top side of the CUCM admin page, select Cisco Unified Serviceability and Click Go
Step 7 Login with the CUCM admin credentials. Select Tools > Service Activation
Step 8 Check the Cisco CallManager and Cisco Tftp services and click Save
Step 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 the IP Phone(s) were MAB authenticated and a dACL was applied for
the session. Bounce the switchport where the IP Phone is connected
Step 10 Switch to CUCM admin page, by selecting Cisco Unified CM Administration option at the top right corner of the
Serviceability page and click Go
Step 11 Click Device > Phone and move to Find and List Phones page
Step 12 Click Find with default settings and when the phone communicates to the CUCM it shows up in this page
Note: The phone status must show ‘Registered with cucm’ for the administrator to manage the phone
from the Call Manager. If the status is something else, then try resetting the IP Phone with physical
access to it.
IP Phone Authentication with MIC
Now that the IP Phone is registered with the Call Manager, necessary changes can be done 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 do 802.1X authentication using MICs. This section shows how to configure the voice
network for MIC authentication and necessary changes required in ISE to support it.
Certificate Export Import between CUCM and ISE
Step 1 Login to Cisco Unified OS Administration page
Step 2 Login with admin credentials and navigate to Security > Certificate Management
Step 3 Click on each of the CA certificates listed as CallManager-trust and export it to your local disk in PEM format. Note,
that the last three certificates need not be exported because they are by default installed in Cisco ISE’s trusted CA
store. However, make sure that those certificates exist on ISE.
Step 4 Login to ISE and navigate to Administration > System: Certificates
Step 5 Click on Trusted Certificates and you will see a list of Root CA public certificates installed on ISE. Notice the three
Cisco Manufacturing certificates that we saw in CUCM before
Step 6 Select the disabled ones and click Edit

Step 7 Change the Status to Enabled and click Save
Step 8 Enable the other CA certificate too.

Step 9 To import the other Root CA certificates exported from CUCM, click on the Import button in the Trusted
Certificates page
Step 10 Upload the CA certificate, give it a name, description and Save it with default settings
Step 11 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, then click Yes and proceed
Step 12 Repeat the certificate import procedure for all the CUCM exported certificates.
ISE Authorization Policy for MIC Authentication
Step 13 Navigate to ISE authorization policy and create a new authorization rule for IP Phones with Certificates
Step 14 Click on the + button for conditions and in the condition Editor, click on the field that says Click to add an attribute,
then click on the user icon and then select CERTIFICATE Subject – Common Name
Step 15 Define a condition to match on ‘CERTIFICATE Subject – Common Name’ Contains ‘SEP’
Step 16 Click the + New button to add another condition
Step 17 AND another condition to match on CERTIFICATE Issuer – Organization
Step 18 Define the second condition to match on ‘CERTIFICATE Issuer – Organization’ Contains ‘Cisco’
Step 19 Click Use once the conditions looks good
Step 20 Add Voice permission that has Voice Domain Permission (dACL_Voice in this example) and Save the configuration
Enabling 802.1X on IP Phones
Step 21 Login to CUCM and navigate to Device > Phone
Step 22 Find the registered phones and click on the specific phone of interest
Step 23 Scroll down under Product Specific Configuration Layout, until you see 802.1X Authentication and then enable it
Step 24 Click Save and then Apply Config
Step 25 The IP Phone in the network should now start 802.1X. If you login to the switch, you will now see the session
information for phone changed to dot1x Method
c9300-Sw#show access-session
Interface MAC Address Method Domain Status Fg Session ID
--------------------------------------------------------------------------------------------
Gi1/0/1 0064.40b5.794e dot1x VOICE Auth 000000000000005A4656E5C5
Gi1/0/1 0050.56a7.fa8a dot1x DATA Auth 00000000000000594656E2C5
<Output trunckated>
Step 26 The session details will reveal additional information about the phone’s 802.1X session
c9300-Sw#show access-session mac 0064.40b5.794e details

IIF-ID: 0x15656B9D
IPv4 Address: 172.20.101.3
User-Name: CP-9971-SEP006440b5794e
Status: Authorized
Domain: VOICE
Common Session ID: 000000000000005A4656E5C5
Handle: 0x41000050
Server Policies:
ACS ACL: xACSACLx-IP-VoiceACL-5af16326
Method status list:

Method State
dot1x Authc Success
mab Stopped
Step 27 Back in ISE, under Operations > RADIUS: Live Logs, you will notice the new session
Step 28 Click on the session details, you will see that the IP Phone is 802.1X authenticated and is been authorized with a
dACL
Step 29 If you scroll further down that page, you will notice the certificate details
Note: To enable 802.1X across all the IP Phones, specific models or locations, use the Bulk
Administration option in CUCM
IP Phone Authentication with LSC

You don't need to have MIC configured in the Voice network to do LSC. However, since MIC is quick and 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 the IP Phones and authenticate them.
Certificate Authority Proxy Function (CAPF) Service Enablement
Step 1 Login to the Cisco Unified Serviceability tool with the admin credentials
Step 2 After login, click Tools > Service Activation
Step 3 Activate the Cisco Certificate Authority Proxy Function service
Step 4 Once the CAPF service is enabled, restart the TFTP service, so that the IP Phones can download the LSCs. To do
that, click Tools > Control Center Feature Services
Step 5 Select the Cisco Tftp service
Step 6 Click Restart to reinitialize the TFTP service
CAPF Certificate Import to ISE

Step 7 Login to the Cisco Unified OS Administration tool with the admin credentials
Step 8 After login, click on Security > Certificate Management
Step 9 Export the CAPF Root CA certificate to your local system (The certificate title only has CAPF in it)
Step 10 Login to ISE, navigate to Administration > System: Certificates > Trusted Certificates and then click Import
Step 11 Import the CAPF Root CA Certificate with default settings
Step 12 Once the certificate is installed, select it and click View
Step 13 The certificate will be 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.
Step 14 Modify the ISE authorization policy to authenticate IP Phones on LSC instead of MIC
Installing LSC on IP Phones
Step 15 Login to CUCM administration page with admin credentials
Step 16 Navigate to Device > Phone
Step 17 After the page loads, click Find and then click on a specific phone where LSC must be installed
Step 18 Under CAPF Information section, set the Certificate Operation to Install/Upgrade. For Authentication Mode, you can
use one of the following option depending on the settings in your environment.
Option Description
By Authentication String Install LSC with a passcode, that needs to be keyed in locally at
the IP Phone
By Null String Install LSC without authentication
By Existing Certificate (precedence to LSC) This option is useful when a new LSC needs to be installed on an
IP Phone that already has pre-installed LSC
By Existing Certificate (precedence to MIC) Authenticate the IP phone with MIC to install a LSC
In this example we use ‘By Null String’ option
Step 19 Click Save and then Apply Config for the changes to take effect
Step 20 Back to Device > Phone page, find the IP Phones and then click on the + button
Step 21 Define a new condition to list phone on LSC issued by option and then click Find. If the LSC installation is in
process, then you will notice the LSC status as ‘Operation Pending’
Step 22 After a while, you will see the status change to Upgrade Success. At this time the LSC installation is successful
Note: To deploy LSC at scale, use the Bulk Administration option in CUCM
Operate
Operating ISE
Operating the ISE Session Table
We have seen how to use the RADIUS Live Log to see all the RADIUS authentication logs and also explored how to get to the
details of specific entries in the log table. This section covers some important operations that can be performed under RADIUS
live sessions.
Step 1 Within ISE, navigate to Operations > RADIUS: Live Sessions
Step 2 All active sessions on the network, that is controlled by ISE can be seen here:
Step 3 If you click on the target icon next to ‘Show CoA Actions’ entry, then you can see a list of Change of Authorization
actions that can be performed on a specific endpoint:
Step 4 To understand the license consumption of the live session, click on the gear icon, then check the ‘License Type’
and ‘License Details’ checkbox, and click Go
Step 5 You should be able to see the license consumption for the sessions when you scroll to the right-hand side of the live
sessions page
Note: Live sessions cannot be deleted from the ISE user interface. CoA terminate will release the
session, however the entry will still persist in the session table. In order to clear the session table, the
following REST API call can be made to ISE:
DELETE: https://<ISE_PAN_IP_Address>/admin/API/mnt/Session/Delete/All
Alternatively, you may perform a get function to gather the calling station IDs for all active sessions and
selectively delete 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_station_id>
ISE AAA Reports
ISE operational reports are very handy to track endpoint and ISE deployment related activates over time.
Step 1 Navigate to Operations > Reports
Step 2 Click on Authentication Summary, you should notice the last 24-hour activity reports in terms of RADIUS
authentications. You can change the report period by clicking on the ‘Today’ drop-down
Step 3 On the same Authentication Summary report page, some interesting stats about ISE deployment’s performance can
be noticed:
Note: The other AAA related reports include the following:
• 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
Top N Authentication by Failure Reason reports the top authentication failures in the network:
The Top N Authentication by Network Device report, tells what network devices have what percent of failure rates.
Troubleshooting
IOS Troubleshooting
Some of the IOS show and debugging commands that are handy to understand and troubleshoot ISE operations are as follows:
• show running-config aaa
• show authentication sessions
• show dot1x all
• show epm statistics mac <MAC_Address>
• show aaa servers
• show device-sensor cache all
• debug radius
• debug radius authentication
• debug dot1x all
• debug epm all
• debug mab all
• debug eap events
ISE Troubleshooting
Refer the following links for details on ISE troubleshooting:

How To: Troubleshoot ISE Failed Authentications & Authorizations
Troubleshoot and Enable Debugs on ISE
Troubleshooting Cisco's ISE without TAC
Troubleshooting TechNotes

Ise Wired Access Depl Guide-V01

Uploaded by

Copyright:

Available Formats

Ise Wired Access Depl Guide-V01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ise Wired Access Depl Guide-V01

Uploaded by

Copyright:

Available Formats

What are the main components of an ISE deployment?

What are the main components of an ISE deployment?

What are some design considerations when deploying ISE?

What are some design considerations when deploying ISE?

Cisco ISE Deployment Guide

Deploying ISE for Wired Network Access

Deploying Cisco ISE for Wired Network Access

Best Practice Global Settings for Switch ............................................................................................ 23

Deploying 802.1X for High security (Closed Mode) ............................................................................ 47

Pre and Post Authentication Access Control with Low Impact.......................................................... 58

Role Based Critical Authorization ........................................................................................................ 75

Differentiated Authentication (With IBNS 2.0) .................................................................................... 81

Identity Based Network Access in IPv6 Wired Networks ................................................................... 85

802.1X For Cisco IP Phones ................................................................................................................. 92

Operate ...................................................................................................................................... 109

Troubleshooting ................................................................................................................................. 112

Figure1: Cisco Identity Services Engine

About This Guide

Figure2: ISE for wired implementation flow

What is covered in this document?

Figure3: Simple ISE Deployment Topology

What is not covered in this document?

ISE Deployment Components

Figure4: Typical ISE Deployment

Authentication Authorization and Accounting (AAA)

Printed in USA Cxx-xxxxxx-xx 05/17

Figure5: IEEE 802.1X Authentication

MAC Authentication Bypass (MAB)

Figure6: MAC Authentication Bypass

Figure7: Central Web Authentication (CWA)

Figure8: ISE Easy Connect

Comparing different authentication methods

Figure9: Authentication Method Comparison

Figure10: Authorization Options

Dynamic VLAN Assignment

IP Access Control Lists (ACLs)

Security Group Tags (SGT)

Session Aware Networking

Figure11: ISE Session Aware Networking

Endpoint Type Supplicant configuration by

Network Device considerations

Figure12: Network Device Configurations for ISE

Identity Based Networking Services (IBNS) 1.0 VS 2.0

Figure13: Cisco IBNS 1.0 Vs IBNS 2.0

IBNS 1.0 IBNS 2.0 Description

Interface IBNS 2.0 configurations can be contained within an interface

Both support assigning a fail open VLAN for endpoints that

Only IBNS 2.0 can apply a custom ACL to an endpoint session,

With IBNS 2.0, endpoints can be MAB authenticated against a

IBNS 2.0 facilitates for separating authentication and

Figure14: IBNS Deployment Modes

ISE deployment considerations

ISE Deployment Scale and Performance

Figure15: IBNS deployment modes

Communication Uses Purpose

Figure16: Switch and ISE RADIUS Connection

Preparing ISE for Identity Based Network Access

Step 2 Select Default Device page.

Step 4 Save the configuration

Preparing Switch for Identity Based Network Access