SISAS Student Guide Vol 1

SISASI
Implementing Cisco
Security Access
Solutions
Version 1.0 Student Guide
PM NUmber: 97-3328-01
. Jje.al•• Americas Headquarters
Cisco Systems . ~-
Ae&a Pacifi c Headquarters
Cisco Systems {USA) Pte. Ltd.
Europe Headquarters
Clsoo Systems lntema~ooal 9V
CISCO San Jose, CA Singapore Amsterdam, The Nethet'lanas
Cisco has mote than 200 otfloos wottd>Mde. Addresses. phone numbers, aod fax numbers ave listed on the
Ctsco Website at W»w.dsco.com.'gQ.(pff)ces.
Cisco and lhe Clsoo lOgo ere trademarkS or registered traaem~Wsof Cisco and/or Its affiliates In lhe U.S. and
ottler counlrles. To view a list of O'sco lrademarks, go 10 lhls URL: WHY!'-clsco.oomtgol'tt:ademarkS. Third
party trac1ema11<s mentioned are the prope<ty of the" respecttve owners. The use of lhe word partner does
not Imply a partnership relationship between Clsoo and any other company. (1110R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIOEO ~AS IS' AND AS SUCH MAY INCLUDE TYPOGRAPHICAL.
GRAPHICS, OR FORMATTING ERRORS. CISCO MAKES AND 'YOU RECEIVE NO WARRANTIES IN CONNECTION 'N'ITH THE
CONTENT PROV1DEO H!:REUNOER. EXPRESS, IMPLIED. STATUTORY OR IN ANY OTHER PROVISION OF THlS CONTENT
OR COMMUNICATION BETWEEN CISCO ANO YOU. CISCO SPECtFtCALLY DISCLAIMS ALL IMPLIED WARRANTIES.
INCLUOING WARRANTIES OF MERCHANTABILITY. NON·INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE,
OR ARISING FROM A COURSE OF OEA1.1NG, USAGE OR TRADE PRACTICE. This learning produC1 may oon!aln earty rebease
oon1en1., and wt'lle Cisco believes It 10 be accutate. l1 fals su~IIO !he diSClaimer above.
C 2014 Cisoo Systems. Inc.

Welcome Students
N ote Students, this lelt&r describes impoftan1 cOUrSe) evaluatiOn access informatiOn.
\Velcome to Cisco Systems Learning. Through the Cisco Leam.ing Parmer Program, Cisco is committed to
bringing you the highest-quality training in the industry. Cisco learning products are designed to advance
your professional goals and give you the expertise that you need to build and maintain strategic networks.
Cisco relies on customer feedback to guide business decisions. 'J'berefore, your valuable input will help
shape future Cisco course curricula, products, and training offerings. Please complete a brief Cisco online
course evaluation of your instructor and the course materials in this student kit On the final day of class,
your instructor will provide you with a URL, directing you to a short postwcourse evaluation. Jfdlere i.:s no
lntemet access in the classroom. please complete the evaluation within the next 48 hours or as soon as you
can access the web.
On behalf of Cisco, thank you for choosing Cisco Learning fanners for your Internet technology uaining.
Sincerely,
Cisco Systems Learning
Table of Contents
Course Introduction 1-1
OVerview 1-1
Course Goal and Objectives 1-3
Course Flow 14
Your Training Curriculum 1-5
Additional References 1-8
Threat Mitigation Through Identity Services 1-1
Identity Services 1-3
Cisco Modular Networic Ard'litecture 1-4
Cisco Modular Networic Architecture Example Networ1c 1-5
Secure Access Control 1-7
Secure Access Solution Portfolio 1-8
Authentication 1-9
Authorization 1-10
Accounting 1-11
Change of Authorization 1-12
Identity Sources 1-13
RADIUS 1-14
TACACS+ 1-15
Summary 1-16
802.1X and EAP 1-17
IEEE 802.1X Overview 1-19
802.1X Message Flow 1-20
802.1X Authorization 1-21
802.1X VLAN Assignment 1-22
802.1X Downloadable ACLs 1-24
802.1X Host Modes 1-25
802.1X Phased Deployment 1-27
802.1X Monttor Mode 1-28
802.1X Low Impact Mode 1-29
802.1X Closed Mode 1-30
802.1X Deployment Mode Comparison 1-31
802.1X Phased Deployment Guidelines 1-32
Change of Authorization 1-33
MAC Authentication Bypass 1-34
Extensible Authentication Protocol 1-35
Tunnel and Non-Tunnel EAP 1-36
Non-Tunnel EAP Types 1-37
Tunnel EAP Types 1-38
Traditional User and Machine Authentication 1-39
EAP Chaining 1-40
EAP Chaining Operation 1·41
EAP Chaining: Corporate Asset and User 1-42
EAP Chaining: Corporate Asset, User Logged Off 1-43
EAP Chaining: Personal Asset with NAM 1·441
EAP Chaining: Personal 3rd Party Asset 1-45
Cisco AnyConnect 3.x Supplicant 1-46
Summary 1-47
Identity System Quick Start 1-49
Logging in to Cisco JSE 1-50
Organization of Cisco ISE GUI 1-51
Local User Database 1-52
Networ1c Access Devices in Cisco ISE 1-53
Cisco tSE Default Authentication Policy 1-55
SWitch Configuration Procedure 1-56
Configure Global AAA Parameters 1-57
Configure RADIUS Pee<ing 1-58
Configure Switch for 602.1X Monitor Mode 1-60
Windows Native Supplicant 1·62
Verify Authentication on ISE 1-63
Verify Authentication on Switch 1-65
Summary 1-66
Module Summary 1-67
References 1·67
Module Self-Check 1-69
Cisco ISE Fundamentals 2-1
Cisco ISE Overview 2-3
Cisco ISE Technologies 2-41
Cisco ISE Operational Components 2-5
Cisco JSE as Policy Platform 2-7
Cisco ISE High-Level Flow 2-8
Cisco ISE Personas 2·9
Cisco ISE Deployment Examples 2·10
Summary 2-11
Cisco ISE PKI 2-13
Server Authentication in EAP 2·141
TLS.Protected Communication 2-15
X.509v3 Certificates 2-16
Use of Server Certificate 2·18
First Validation: Verify Server Certificate 2·19
Second Validation: Verify Server Signature 2-20
PKJ Enrollment Procedure 2-21
Step 1: Import CA Root Certificate 2· 22
Step 2: Generate CSR 2·23
Step 5: Bind Certificate to Pending CSR 2-25
lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.

Verify PKI Enrollment 2·27
Summary 2·28
Cisco ISE Authentication 2·29
Cisco ISE Authentication 2·30
Policy Elements in Cisco ISE 2·31
Cisco ISE Authentication Policy Example 2·32
Cisco ISE Rule-Based Authentication 2·33
Authentication Conditions 2·34
Tune Rule--Based Authentication (Situational) 2·35
Define Simple Conditions (Optional) 2·36
Create or Tune Compound Conditions (Optional) 2·37
Define Allowed Protocols (Optional) 2·38
Tune Of Create Authentication Rules (Optional) 2·39
Tune Default Authentication Rule (Optional") 2·41
Cisco Network Access Manager 2·42
Networks and Network Groups in Cisco NAM 2·43
Network Settings in Cisco NAM 2·44
Summary 2·45
Cisco ISE External Authentication 2-47
External Authentication 2·48
Active Directory 2·49
Authentication Methods with Active Directory 2·51
AD·Oerived Group Membership 2·52
Active Directory Integration Methods 2·53
Active Directory Integration Procedure 2·54
Configure AD Domain and Store 2·55
Test AD Connection 2·56
Join Active Oire<:tory 2·57
Select Groups from Directory 2·58
Cisco ISE Identity Source Sequence 2·59
Configure Identity Source Sequence 2·60
Apply Identity Source Sequence 2·62
Verify External Authentication 2·63
Summary 2·64
Module Summary 2·65
References 2·65
Module Self-Check 2·67
Advanced Access Control 3·1
Certificate-Based User Authentication 3·3
EAP·TLS Bidirectional Authentication 3-4
Verification of Client Certificates 3-5
Implementation Procedure for EAP·TLS in Cisco ISE Deployment 3-6
Select CA Certificate for EAP Verification 3-7
Deploy Certificates on Clients 3-8
C 2014 Clsoo Sys1ems. Inc. Student Guide Ill

Configure 802.1X Supplicant to Use EAP·TLS 3·9
Configure Supplicant to Use Certificates 3-10
Configure Certificate Authentication Profile 3-11
Apply Certificate Authentication Profile to Identity Source Sequence 3-12
Verily EAP·TLS Operation 3-13
Summary 3-1<11
Authorization 3-15
Authorization in Cisco ISE 3-16
Authorization Policy Overview 3-17
Downloadable ACLs 3-19
Authorization Profile 3-20
Authorization Policy 3-21
Building Conditions 3-22
Authorization Configuration Procedure 3-23
Configure Rule Matching Logic 3-24!
Configure Authorization Profile 3-25
Configure Authorization Policy Rule 3-27
Tune Default Authorization Rule 3-28
Verify User Authorization on ISE 3-29
Verify Machine Authorization on ISE 3-30
Verify Authorization on Switch 3-31
Verify dACL Assignment on Switch 3-32
Summary 3-33
Cisco TrustSec and MACsec 3-35
Cisco TrustSec Overview 3-37
Cisco TrustSec Benefits 3-39
SGT Classification 3-41
lnline SGT Transport 3-42
SGT Exchange Protocol 3-43
Enforcement Using SGACls J.-44!
Enforcement Using SGFW 3-45
SGA Deployment Procedure 3-46
Configure CTS Between ISE and NAD 3-47
Define Seauity Groups 3-48
Implement Dynamic Classification 3-49
Implement Static Classification 3-50
Implement SGT Transport 3-51
Define SGACLs 3-52
Implement SGACL Enforcement 3-53
Implement SGFW Enforcement on the ASA 3-55
MAC Security 3-56
MACsec Cryptography 3-57
MACsec Hop-by-Hop Operation 3-58
Implement Downlink MACsec on the ISE 3-59
Implement Downlink MACsec on the NAM 3-60
W lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Implement Downlink MACsec on the Switch 3-61
Verify Downlink MACsec 3-62
Summary 3-63
Module Summary 3-65
References 3-65
Web Authentication and Guest Access 4-1
Deploying WebAuth 4-3
Web Authentication 4-5
WebAuth Process 4-6
WebAuth Scenarios 4-7
Central WebAuth Operation 4-8
Central WebAuth Configuration Procedure 4-10
Configure Switch for WebAuth 4-11
Configure MAS to Continue If User Not Found 4-12
Tune the WebAuth Identity Source Sequence 4-13
Configure Pre-WebAuth dACL 4-14
WebAuth Redirect: Authorization Profile 4-15
WebAuth Redirect: Authorization Policy Rule 4·16
Configure Authorization for WebAuth Users 4·17
Verify WebAuth Initiation on the ISE 4·18
Verify WebAuth Redirect on the Switch 4-20
Verify WebAuth Redirect on the Client 4-21
Verify Completed WebAuth on the ISE 4-22
Verify Completed WebAuth on Switcll and Client 4-23
Summary 4-24
Deploying Guest Service 4-25
Guest Service Overview 4-27
Guest Service and WebAuth 4-28
Cisco ISE Guest Service Applications 4-29
Admin Portal Configuration Scope 4-30
Sponsor Portal Configuration Scope 4· 31
Guest User Portal Functions 4-32
Portal Services Location 4· 33
Sponsor Portal Configuration Procedure 4· 34
Configure Portal HTTPS Ports 4-35
Manage Sponsor Groups 4-36
Assign Users to Sponsor Groups 4-38
Configure Guest Policies 4-39
Manage Guest Portals: Default or CUstom 4-40
Configure Guest Authorization 4-42
Provision Guest Accounts in Sponsor Portal 4-43
Verify Guest Access 4-44
Monitor Guest Access on ISE 4-45
C 2014 Clsoo Sys1ems. Inc. Student Guide v

Summary 4-46
Module Summary 4-41
References 4-47
Endpoint Access Control Enhancements 5-1
Deploying Posture Service 5-3
Cisco ISE Posture Service Overview 5-5
Posture in Cisco ISE 5-6
Persistent Agents (Windows and Mac) 5· 7
Web Agent 5-8
O ient Provisioning Process 5·9
Posture Conditions 5-10
GoA in Posture Assessment 5-12
Posture Configuration Procedure 5-13
Download Client Provisioning Resources 5-14!
Configure Client Provisioning Policy: Operating System and Conditions 5-15
Posture Policy Building Blocks 5-16
Configure Posture: Condition 5-17
Configure Posture: Remediation 5-18
Configure Posture Policy: Posture Requirement 5-19
Configure Posture: Posture Policy 5-20
Redirect Q ients to Client Provisioning Portal 5-21
Configure Authorization Policy for Posture 5-22
Verify Redirection to CPP 5-23
Verify Remediation 5-24!
Verify Posture Compliance 5-25
Summary 5-26
Deploying Profiler Service 5-27
Cisco JSE Profiler Service Overview 5-29
Profiler in Cisco ISE 5-31
Cisco ISE Probes 5-32
Commonly Deployed Probes 5-34!
Profiting Without Probes 5-37
Cisco ISE Profiler and CoA 5-38
Profiling Policies 5-39
Parent Profiling Policies 5-40
Child Profiling Policies 5-42
Profiling Configuration Procedure and Scenario 5-43
Enable Profiler Service 5-44!
Enable CoA in Profiling Feature 5-45
Configure Probes 5-46
Examine Parent Policy 5-47
Examine Parent Conditions 5-48
Configure Profiler Condjtions 5-49
>A lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Configure Profiling Policy 5-50
Configure Authorization for Profiled Endpoints 5-51
View Profiled Endpoint Identity Groups 5-52
Verify Profiling in Authentications Page 5-53
View Profiled Endpoints 5-54
Summary 5-55
Implementing BYOD 5-57
The BYOD Ch allenge 5-58
Device Onboarding 5-60
Single and Dual SSID Design 5-62
Dual SSID Flow 5-63
Authorization Policy in Dual SSID Design 5-64
Connei:ting to the Network 5-65
Guest Access 5-66
Employee Access Before Endpoint Provisioning 5-67
Native Supplicant Provisioning for Employees 5-68
Provisioning for Employees: Wi· Fi Profile 5-69
Client Provisioning Policy for Employees 5-70
Employee Access After Endpoint Provisioning 5-71
Verify BYOD: Device Registration 5-72
Verify BYOO: Client Provisioning 5-73
Verify BYOD: Connect to the SSID 5-74
Summary 5-75
Module Summary 5-77
References 5-77
Access Control Troubleshooting 6-1
Troubleshooting Network Access Controls 6-3
Troubleshooting Procedure 6-4
Cisco ISE Troubleshooting Tools 6-6
RADIUS Authentication Troubleshooting 6-7
Execute Network Device Command 6-8
Evaluate Configuration Validator 6-9
Posture Troubleshooting 6-10
TCP Dump 6-11
Troubleshooting Authentication Overview 6-12
Troubleshoot 8 02.1X on Switch 6-13
Troubleshoot RADIUS Peering 6-19
Troubleshoot Peering with User Database 6-22
Troubleshoot Identity Source Sequencing 6-24
Troubleshoot Client-Side Certificate Issues 6-25
Troubleshoot Disallowed Authentication Protocol 6-26
Troubleshoot M achine Authentication 6-27
Web Authentication Troubleshooting Overview 6-28
C 2014 Clsoo Sys1ems. Inc. Student Guide vii

Review ISE Authentication Policy for WebAuth 6-29
Review ISE Authorizatioo Policy for WebAuth 6-30
Review Authorization Profile for WebAuth 6-31
Troubleshoot Mismatch of ACL Name 6-32
Posture Troubleshooting Overview 6-36
Review Posture: Client Provisioning Policy 6-37
Review Posture Policy 6-38
Review Posture Requirements 6-39
Troubleshoot Posture 6-40
case Study: Troubleshoot Profiling 6-41
Summary 6-42
Module Summary 6-43
References 6-43
Glossary G-1
viii lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Course Introduction
Overview
The Implementing Cisco Security Access Solutions (SISAS) course describes an access control solution
that centers on the Cisco Identity Services Engine (.ISE). Tbe learners build the solution by implementing
basic authentication and then extending the system with the authorization, guest services, Cisco TrustSec,
posture, and profiling components. The most fundamental concepts include the authentication methods,
such as 802.1X, MAC Authentication Bypass (MAil!), and Web authentication (WebAuth). The learners
i:mplement various types of the Extensible Authenttcation Protocol (EAP) using two different 802.1X
supplicants: the native Windows OS supplicant and the Cisco AnyConnect supplicant The Cisco
AnyConnect supplicant is used for a range of scenarios, including EAP chaining. Although the Web
Authentication and tlle guest services are often deployed together, the learners first implement the WebAuth
feature for employee access and then enable the guest feature to aU ow guest access. The posture service on
the LSE is wed to determine the security posture status of the endpoints. ·fhe learners use the built ~ in
posture elements pre.configured in the ISE, and aiSlO implement a custom remediation to automatically
install antivirus software. The ISE offers a wide range of profiling capabilities. ·The learners test lhe default
functionality with the common probes enabled, and! extend the profiling granularity by defining custom
policies. The course ends with a troubleshooting lesson and an optional troubleshooting lab exercise.
Learner Skills and Knowledge
111is subtopic lists the skills and knowledge rbat learners must possess to benefit fully from the course. The
subtopjc also includes recommended Cisco learning offerings that learners should fJISt complete to benefit
fully from this course.
Leamer Skills and Knowledge

Familiarity with basic Cisco access control solutions and 802.1 X
Famitiarity with general networi<ing principles equivalent to the CCNA
level
Familiarity with basic network security concepts equMIIent to the
CCNA Security level
~ ·--
1·2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Course Goal and Objectives
This topic describes the course goal and objectives.
Upon completing this

course, you will be able to
meet these objectives:
• Deploy Cisco ISE
• l mpleme<>t 802. 1X and MAS
Course Goal • Deploy SeC<Jrity Group Access

and MAC Security
lmpleme<lt WebAuth and guest

service
Deploy posture
Implement profiling
....... _
C 2014 Clsoo Sys1ems. Inc. Student Guide 1-3

Course Flow
'J'bis topic present~ the suggested flow of the course materials.
Course Flow
Threat Mitigation ThrOugh Identity

Services (Cont.)
Threat MitiQation Through klentity C isoo ISE Fundamentats
SerW::es
Cisco ISE Fundamentals {Cont.) A.d\fanoed Access Control
Advanced Ac:te:ss Control (Cont.) Web AuthenticatiOn and Guest

A<:coss
Web AuthenticatiOn and Guest Endpoint Access Control
Access {Cont.) Enhanooments
Endpoint A.cc.Qss Cor.trol Access COntrol Trouble:shoOting
E nMno&ll'IEtntS (Coot) {C ont.)
Tbe schedule reflects the recommended structure for this ·course. This structure allows enough time for the
insouc·tor to present the course information and for you to work through the lab activities. The exact timing
of the subject materiaJs and labs depends on the pace of your specific class.
I"" lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Your Training Curriculum
This topic presents the training curriculum for this course.
Cisco Career Certifications
....... _.
You are encouraged £0 join the Cisco Certification Community. a discussion forum open to anyone holding
a valid Cisco Career Certification (such as Cisco CCIE"', C.'CNA"'· CCDA"', CCNI"", CCDP11, CCU'" '•
CCNP"' Security and CCN!,® Voice, or CCSI""'). It provides a gathering place for Cisco certified
professionals to share questions, suggestions. and infonnation about Cisco Career Certification programs
and other certification ~related topics. For more information, visit hn p ·HMyw cis-eo com£iolcenificat jons .
C 2014 Clsoo Sys1ems. Inc. Student Guide 1·5

Tral nlng Curriculum
111is subtopic presents the rraining curriculum for this course.
Cisco Career Certifications

Expand Your Professional Options, Advance Your Career
Recx:wNi&-TI3iJWng11wougi>Cisoo
~-
•
I
•
•
-
I
I
OlcD£iciOot,....,..~
O.O.,...c....t~
Cllat s-e,.t.ae.. SeM1M1

c:r.c.a..:.........,~
For more information on certifications, visit http://www.cisco.com/go/certifications.
Note Cisco prOVides three levels of general e&rtifications few IT prote.s.siOm:'IIS with S4WOral different tracks to
mo~t individual needs. Cisco also provid6S focused certifications for desigoatoo areas such as cabt.o
communications al'ld security. Th&r& am f'n<:lny pathS to CiSCO certification, but only ooe requirement-
passing one or tr.ora exams demonstrating knowledge and skill. For detailS, go to www cisco comtgot
oortjficaljgns
1-6 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Leamer Introductions
Your name
Your company
Job responsibilities
Skills and knowledge
Brief history
Objective

Additional References
'J'his topic presents the Cisco icons and symbols thar are used in this course, as well as information on
where to find additional technical references..
Cisco Icons and Symbols
.....
w....
--·
....... -- -
Cisco Glossary of Terms
For additional information on Cisco tenninology, refer to the Cisco lnternetworking Terms and Acronyms
glossary of terms at bttp·Udocwjkj cjsco com/wjkj/
Categordntemetworking Tenns and Acronyms OTA).
Module 11
Threat Mitigatiion Through

Identity Services
To protect against unauthorized access to controlled or confidenrial information, enterprise networks require
an effective network access control embedded within the network infrastructure.
The Cisco Identity Services Engine is a next~generation identity and access control policy platform that
enables enterprises to enforce compliance, enhance infrastructure security, and streamline their service
operations. The unique architecrure of Cisco lSE atlows enterprises to gather real~ti me contextual
i:nformation from networks, users, and devices. The administrator can use that information to make
proactive governance decisions by tying identity to various network element.~ including access switches,
\VLCs, VPN gate\l.<ays, and data cemer switches. This module introduces the main components of the Cisco
[SE architecture and explains the its rote in the network access control solution.
Upon completing this module. you will be able to meet these objectives:
.. Describe the role of identity services in the secure access solution
• Implement 802.1X and EAI'
Jwnp stilll ~te secun: access solution
Lesson 11
Identity Services
Overview
The most secure solution at the access edge is to leverage the intelligence of the network. Cisco offers a
host of services designed to enable secure user and host access to enterprise networks. It provides Slandards·
based network access control at lhe access layer by using the 802. IX protocol to secure the physical ports
where end users connect
This lesson describes the secure access solution and identifies its key componems, such as authentication,
autl1orization, accounting, the identity stores, as well as the main authentication proxy protocols: RAI;?fUS
and TACACS+.
Upon compledng this lesson, you will be able to meet these objectives:
• Describe the Cisco modular network architecture.
• Describe the Cisco secure access solution
• Describe the secure access portfolio
• Describe the authentication
• Describe the authori2ation
• Describe AAA accounting
.. Describe the CoA
.. Describe the identity sources
• Describe RADIUS
• Describe TACACS+
Cis.co Modular Network Architecture
Tbis topic describes Cisco modular network architecture solution.
Cisco Modular Network Architecture

Cisco modular network architecture delivers defense-in-<lepth
by strategically positioning Cisco products and capabilities
throughout the network.
~~==1
.... -----~"·
~.... --
·-·
Cisco modular network architecture delivers defense-in-depth by strategically positioning Cisco products
and capabiUties throughout the network and by using the ,collaborative capabilities between the platforms. A
wide range of security technologies are deployed in multiple layers, under a common strategy and
administration. Products and capabilities are positioned where they deliver the most value, white facilitating
collaboration and operations. The figure illustrates the Cisco modular network architecture.
Cisco modular network architecture is delivered in the form of design blueprints and security solutions:
Design blueprints-Cisco validated designs and security best practice guides. Prescriptive design
gu:idance is provided in CVDs which cover the various piNs present in an entetprise network, such as
campus, WAN edge, branches, and data center. Design guidance is alo;o provided for technologies such
as unified communications, network virtualization, and network foundation protection, which are
present in multiple places in the network. The selection of platforms and capabilities within those
designs, is driven by the application of the Cisco Security Control framework.
Security solutions- The Cisco SCf' and !he design blueprints provide !he foundation for industry
security solutions which address the requirements of specific industries such as retail, financial,
healthcare, and manufacturing.
As illu:strated in figure above, Cisco security services are embedded as an intrinsic part of the architecru.re.
Tbe Cisco security services support the solution lifecycle and the security products included in the designs.
1-4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Cisco Modular Network Architecture Example
Network
This topic provides an example of Cisco modular netv.·ork architecture network design.
Cisco Modular Network Architecture Example

Network
The figure illustrates the range of security technologies and products in an example of a network, which is
built based on the modular network architecture design principles. ln the network, multiple layers of
security controls are implemented throughout the ne~·ork. All network devices and security controls are
implemented in the high availability mode, providing confidentiality, integrity, and availability of data,
applications, endpoints, and the network itself.
The security architecture shown in the figure is made up of the following security products and
technologies:
Endpoint security: organizations today use a complex and diverse set of endpoints, both wired and
wireless. ]1tese device.c; need to be secure from. data loss, data theft, and privacy invasion, and must
meet the local country and
state security requirements. tndpoim security within the example architecture includes the following
products:
Cisco SecureX Context·A~'are Security
Cisco Identity Services Engine
Cisco Wireless LAN Controller
Cisco AnyConnect Secure Mobili<y Client
.. Network security: One of the most fundamental elements of the Cisco security controls is netv.·ork
security, whicb is designed to protect the integrity of the network infrastructure itself, where entire
network segments may be the target of attacks such as theft of service, service abuse, Do$,, and data
loss. Network security within the example architecrure includes the following products:
Cisco Adaptive Securi<y Appliance 5500-X Series
C 2014 Clsoo Sys1ems. Inc. Student Guide 1-S

Cisco Catalyst 6500 ASA Services Module
Cisco ASA !OOOV Cloud Firewall
Cisco Virtual Security Gateway
Cisco JSR G2lntegrated Security Firewall
Cisco Cloud Services Router IOOOV Series
VPN
Infrastructure protection on all devices
Content and application security: Organizations can be vulnerable to attacks on data and content. Spa~
phishing through e-mail, and web content attacks have all been used £0 provide an attacker access to a
target system. Content security within the example architecture includes the following products:
• Cisco Email Security Appliance
• Cisco Web Security Appliance
• Cisco Intru.sion Prevention System
• Cisco ASA SSOO·X Series NGFW
System network and event management: Network management tools help providers automate, simplifY..
and integrate their network to reduce operational costs. Netv.•ork management within the
example architecture includes the following products::
Cisco Security Manager
Cisco Prime Infrastructure
Cisco Secure Access Control System
1-6 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Secure Access Control
This topic describes the Cisco TrustSec solution.
Secure Access Control
* ~w•o
I8ui!Mtt·R~ovant
Polocltl
C~1ra1act
~ UWM! Poticy Eng nc
Where OynamiePOirc1
and
~nonngand
cport:ng
Enforcement
When ,_
··· ~.,
The Cisco secure access solution nUtigates security risks by providing comprehensive visibility into where
and where who is connecting from what across the entire network infrastructure. It provides exceptional
conU'Ol over who and what accesses the network and where they can go.
Cisco secure access solution builds upon your existing identlty·aware access layer infrastructure (switches,
routers, wireless controllers, and so on) and is a fully validated solution in which all the components are
thoroughly vetted and rigorously tested as an integrated system.
The Cisco secure access system uses standards~based identity and enforcement models, such as fEE~
802.1X and yLAN control. It also has many more advanced identity and enforcement capabilities, such as
tlexjble authentication, d.ACLs, SGA. device profiling, posture assessments, guest access management, and
more.
C 2014 Clsoo Sys1ems. Inc. Student Guide

,_,
Secure Access Solution Portfolio
'J'bis topic describes the Cisco secure access solution portfolio.
Secure Access Solution Portfolio

Pohcy
Admm••U•ton
Po&tcy 0.-•on
Pohcy
Enfofcement
_.
Poloty
InformaDon
.......... __ ;,;;•.;--
NA.C Ao-
----.•:;..;;.'
tjA,C VMAoMI
At the .heart of lhe Cisco secure access solution you will find the Cisco Identity Services Engine. Cisco ISE
provides a centralized, identity~based policy platfonn for context aware access control decisions across the
4
wired, wireless, and VPN infrastructure. Cisco lSE combines AAA, posture, profiler, and guest
management features in a single, unified appliance, providing a single point for policy management,
monitoring, and troubleshooting.
Tbe switched, wireless, and routing infrastructure provides the policy enforcement building block. The
network devices ensure that only the expected communications is permitted through the network.
'J'h e thi rd tier is responsible for cying the endpoint into the secure access solution. Among other things. it
collects the infonnation about the user identities and their endpoints and communicates with other
components in the secure access solution. This functionality is typically available as software elements
installed on me endpoints. such as the Cisco AnyCoMect Mobility client. or the .iNAC agents.
1-8 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
Authentication
This topic describes the authentication.
Authentication
-who you are"
At the core of the access control .solution
Determines the jdentity of a user an endpoint or both using:
802.1X
Web auU'IEmtication
MAC AuthentiCation Bypass
VPN authentication
....... _.
The authentication is used to detennine the identity of a user or endpoint. for users, it answers the question
who the user is. The authentication plays a fundamental role in the access conrrol solution, as many other
functions rely on it 'The authentication can be perfonned using a verity of methods.
802.1X authentication requires an agent, which is referred [0 as a supplicant, to run on the endpoint Most
modern PC operating systems offer a native supplicant. Some vendors, such as Cisco, offer premium
supplicants tha< extend the 802. IX supplicant functionality wi<h additional features.
\Veb authentication provides an authentication option for endpoints that lack an 802.1 X supplicant and for
endpoints that do have an 802.1 X supplicant, but the user fails authentication. An example use case is for
guest user access to the network.
MAB is an option to allow certain systems that do not have an 802.1X supplicant, such as a printer or a
security camera, to access the network while still maintaining a consistent configuration across switch!
access ports. MAB utilizes a database of the MAC a~s~ of systems that are allowed access to the
oetwork.lt is important to note that MAS is not ''MAC authentication." Instead it is an "authentication
bypass" that is ba~ed on MAC address. MAB specifies a set of MAC addresses that are allowed to skip
authentication.
Other common authentication metl1ods include the VPN authentication, in which the users mwt provide
their aocess credentials before a VPN connection is established.

Authorization
'J'bis topic describes the authorization.
Authorization
'What you are allowed to do"
~~·
--
~"'".
-- --
. ... 11' .............
by ~It IP _,...
"'-- , .......... 4114 thllt
<IAQ.o .. -
----
- ~...:..
- 0 ...
. ...d..,...,
After network users and devices are authenticated and conft.rmed to comply with an organization's security
policy. they are allowed network access. Their subsequent resource and service entitlement is accomplished
by the authorization process. Tbe Cisco access conrrol solution supports multiple authorization methods,
includi.ngills, VLANs, and SGA.
Tbese choices help organizations design their security architecture and services offerings with maximum
flexibility and effectiveness. Downloadable, per·session ACL" on the switches, which are named ACLs on
wireless LAN controllers, and dynamic VLAN assignments can be implemented at the ingress point where
users and devices gain their initial entry to the network. ln addition. SGA allows user identity information
to be captured and tagged with each data packet. SGACLs can be implemented at an egress point where a
network resource (such as a file server) is located. SGA·based access control allows organizations to keep
the existing logical design at the access layer, and with flexible policies and services. meet different
business requirements without having to redeploy the security controls. This solution tags every packet at
the ingress network device and enables the egress network de\~ces to enforce rraftic control closest to the
destination.
1·10 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Accounting
This topic describes the accounting..
Accounting
-what you have done"
Tracks the services that users are accessing and the amount of
network resources that they are consuming
Accounting record contains accounting AV pairs
Analyzed for network managemeflt, client b illing, and audrting
Required to determine when a session tenninates
Authentication and authorizatiOn inform abOut sessiOn start only
Input fOf roporling and pc.r-sessi«l licensing
....... _.
The AAA accounting feature enables you to track the services that users are accessing and the amountt of
network resources tbat they are consuming. When AAA accounting is enabled, the network access server
reports user activity to the accounting server in the form of accounting records.. Each accounting record
contains accounting A V pairs and is stored on the security server. This data can then be analyzed for
network management, client billing, and auditing.
The Cisco Identity -Services Engine uses AAA accounting to determine which access sessions are still
active. 1'he autbenticarion and authorization provide information about the session start, but not about
se.~sion tennination. The data about session termination is needed for reporting, per-session licensing, and
staristics calculation.

Change of Authorization
'Jllis topic describes the ~
Standards-based method to change an endpoint authorization
status:
1. After successful authentication:
Basic oonnedivity
Profiling and det&nnining of sowrity posture
2. After confirmation of endpofnt compliance:
AuthenticatiOn sarver sands COA message
COtltext appropriate access privil&ges applt&d
Traditional RAOfUS allows the RADIUS client to make AAA requests to RADIUS servelli. If the
circumstances changed, there was no mechanism for the RADIUS server to dynamically return to the client
with an updated authorization policy. To address this, RADIUS CoA was developed and defined in RfC
5176.
The AAA framework uses CoA me.~sages to dynamically modify active subscriber sessions. For example,
RADfUS attributes in CoA messages might instruct the framework to create, modify, or terminate a
subscriber service.
After successful authentication, an endpoint is allowed basic network connectivity. This basic connectivity
profile enables the Cisco Identity Services Engine to perfOrm profiling and security posture functions.. Once
the Cis:co IS£ establishes the endpoint compliance, it sends a CoA message to the authenticator and supplies
extended access privileges, which are typically described in the form of an appropriate dACL.
CoA is also utilized for centralized web authentication. Web authentication is often used as a fallback
authentication method. When authentication fails at ISE, IS£ can be configured to push an initial policy that
only aiJO\\'S web traffic and redirects that web traffic to the web authentication portal. lf the user can
successfully authenticate via the web authentication porral, then IS£ issues a CoA to update the policy on
the ~ as appropriate by context.
Identity Sources
This topic describes the identity sources.
Identity Sources
Used to validate credentials for authentication functions
Used to retrieve group information for use in authorization policies
On Cisco ISE, can be grouped in1o identity source sequences
Internal or external
External: RAD I US,~ LDAP, Token servers
~- ... ·~
-- ~~--<l~iH-111
~1+------1.
--~- =::-,---
,_,.-.,.._,,._,.o....y • lOAP
....... _.
The identity source is the user or endpoint database used to validate credentials for user authentication
functions. l t can also offer group membership information that is used to detennine the applicable
autl1orization policy. Some authenticators, such as the Cisco Identity Services Engine, can group multiple
identity sources into an identity source sequence. When specified. Cisco IS'E searches these identity sources
in the order in which they are defined in rhis sequence.
tdentity sources can be intemaJ or externaL Cisco ISE maintains intemaJ databases that can be used as
identity sources during the authentication process. The internal user database is commonly used to support
guest Jogins. The intemaJ endpoint database is primarily populated using the Cisco lSE profiler function.
Cisco IS£ integrate.'i with external identity sources to validate credentials in user authentication functions,
and to retrieve group infonnation and other attributes that are associated with the user for use in
authorization policies. Cisco ISE supportS several commonly implemented identity sources. including
Active Directory and LDAP.

RADIUS
'Jllis topic describes RADIUS.
RADIUS
Standards· based authentication proxy protocol
AV pairs carry authorization and accounting infonnation
Vendors can defme their custom AV dictionaries
Authentication and authorization results carried in one message
·····~-- -· • E::..'
- RADIUS '
RADIUS is a standards-ba(jed network protocol that facilitates centralized AAA services. RADIUS uses
AV pairs to carry AAA information between the RADIUS client and the RADIUS server. The .!JlTE has
defined a standard set of RADlUS attributes. RADfUS is also extendible by vendors who can define VSAs.
Cisco ndentity Services Engine uses dictionaries to organ~ze RADfUS AV pairs. h has built~in system·
deflned dictionaries for the lETf standard set of AV Pairs as well as several vendor specific dictionaries.
New. user-defined dictionaries can be created to support o ther vendors, if necessary.
RADIUS combines authentication and authorization. An access-accept packet sent by the RADfUS server
to the client contains the appropriate authorization details. This makes it difficult to decouple authentication
and authorization.
1-H lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
TACACS+
This topic describes TACACS+.
TACACS+
Developed by Cisco
Independent authentication, authorization, and accounting
Often used for command authorization and accounting
Not supported in Cisco ISE version 1.2
I ~,_,_;~~r_,_w..,..,..._ '
~ "- ~ IIIM""'"''*""'-.r,t"'-
....... _.
TACACS+ is an AAA protocol developed by CL<co. It differs from RADIUS mainly d1rough the
independent AAA architecture. This allow'S separate authentication solutions that can still use TACACS+
for authorization and accounting.
A common use of the feature is in the control administrative access to netv.•ork devices. TACACS+ supports
command authorization and accounting on a command by command basis. During a management session, if
additional authorization checking is needed, the TACACS+ client checks with aTACACS+ server to
determine if the user is granted pennission to use a particular command. Also, with conunand ac.counting,
an accounting record can be sent to the TACACS+ server, facilitating a centralized audit trail of
administrative activities. This provides greater control over the commands that can be executed on the
access server while deooupling from the authentication mechanism.
TACACS+ is not supported in Cisco Identity Services Engine version 1.2. If you want to control the
administrative access from the Cisco ISB I.Z or earlier, there are options using R.'\OfUS. You can authorize
exec sessions using privilege levels. In ISE, you can assign a privilege level to a user and this privilege level
can be used to define the user's administrative privileges. Also, if the devices have been configured lOS
Role Based Access Control, you can assign a CLI view name to a user to define that user's administrative
privileges.

Summary
'J'bis topic summarize.c; the key points that were discussed in this lesson.
Summary
Cisco secure access solution mitigates security risks.
The central element of the Cisco sea..re access solution is the Cisco
Identity Service Engine.
Authentication determines the identity o f a user Of endpoint.
Authorization enforces appropriate access privileges.
Accounting provides details about the session duration and connection
parameters.
1-16 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Lesson 21
802.1Xand EAP
802.1X is an JEEE standard for media~level access control, offering tlle capability to pennit or deny
oetv.·ork connectivity, control~ access and apply traffic policy, based on user or machine identity.
802.1X uses the E.AP to authenticate users who wis:h to access the network.
This lesson describes the 802.1 X framework and the commonly used EAl, variants.
Upon completing this lesson, you will be able to meet these objectives:
• Provide an overview of802.1X
• Describe the 802.1X message flow
• Describe the 802.1X authorization
• Describe the 802.1X VLAN assignment
• Describe the downloadable ACLs
• Describe the 802.1X host modes
• Describe the 802.1X phased deployment
• Describe the monitor mode
.. Describe the low impact mode
• Describe the closed mode
• Compare !he 802.1 X deployment modes
• Describe the 802.1X phased deployment guidetines
• Describe CoA
• Describe MAB
• Describe EAP
Describe tunnel and non.tunnel EAP
Describe non~runneled EAJ, types
• Describe tunnel EAP types
Describe tlle lJ'aditional user and machine authentication
• Describe EAP chaining
Describe tlle EAP chaining operation
Describe the EAP chaining flow for corporate asset and user
Describe the EAP chaining flow for co~porate as.~;et and user logged off
• Describe the EAP chaining flow for personal asset with NAM
Describe the EAI' chaining flow for personal asset with third party supplicant
Describe !he AnyConnect supplicant
1-1& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
IEEE 802.1X Overview
This topic describes the 802.1X framework.
IEEE 802.1X Overview

Provides authentication--based port access control and authorization
Network devices have specific roles:
Supplicant (agQnt or serviOe running on d .iBnt)
AuthGttticatOt {switch or wireross LAN contro!IGr)
Authentication Sel'Y'Qr (Cisoo ISE or RADIUS servor)
A~ hEflll: t :1!1'1
3!r,'<?r
\Vith 802.1 X port~ba~ed authentication, network devices have these roles:

• Supplic.ant: This role is an agent or service rul!ming on the device that requests access to the network.
It responds to requests from the switch. The so:ftware code of the supplicant must be 802.1 X~compliant
• Authentic-ator: This rote controls physical access to the network based on the authentication statlJS of
the client. This device acts as an intermediary {proxy) between the client and the authentication server.
It request.1i identity information from the client~ verifies that information with the authentication server,
and relays the authentication server's response to the client. Tbe authenticator includes the RADfUS
client functionality, which is responsible for encapsulating and de~encapsulating the EAP frames :and
interacting with the authentication server. The most common authenticators are LAN switches and
wireless LAN controllers.
• Authentication sen·er: Tbis role performs the actuaJ authentication of the client ·ne authenticarion
server validates clle identity of the client and notifies the switch if the client is authorized to access the
network. Because the authenticator acts as the p roxy, the authentication service is transparent to the
client Cisco Identity Services Engine acts as the authentication server.
\Vhen the authenticator receives EAPOL frames an-d relays them to the authentication server, the ]:the met
header is stripped and the remaining EAP frame is re-encapsulated into RAOfUS format The EAI' frames
are not modified during encapsulation, and the autbentication server must support EAP within tlle nat~ve
frame format. The opposite happens in the other direction. When the authenticator receives frames fro:m the
authentication server, the RADIUS header of the server is removed, leaving the EAP frame. The EAP frame
is then encapsulated using EAPOL and sent to the supplicant

802.1X Message Flow
'Jllis topic describes the 802. I X message flow.
802.1X Message Flow

....
..
0
~--·., - - ,....
...
(;
.
"
----, ........_ · iiii·z
,___
-
7
• . , .
-- - i JIAo;IU:
-- •'
'
~~
I
....-
The authentication can be initiated by the supplicant or the authenticator. The authenticator initiates
authentication when the link state changes from down to up, or periodically as long as the port remains up
and un.authenticated.
Tbe authenticator sends an EAP request or identity frame to tl1e client to request its identity. Upon receipt of
the frame, the supplicant responds with an EAJ, response or identity frame. However, if during bootup, the
supplicant does not receive an EAP request or identity frame from the authenticator, the supplicant can
initiate authentication by sending an &\POL start frame, which prompts the authenticator to request the
identity of the client.
Note If B02.1 X is not &nabf&d or supported on the NAD, any EAPOL frames from tM supplicant are dropped.
It th& supplicant doos not rocoive an EAP requ&st or idenlity frame after thrOO attem pts, the supplicant
~nds fram&s as if the port was in authorized state. A port in authOrized stat& cffcctivofy means that the
suppliCant ha$ boon wcce$$1ully al.lthenticated.
When the supplicant provides its identity, the authenticator begins its role as the intermediary and passes
£AJ> frames between the supplicant and the authentication server until authentication succeeds or fails. If
the authentication succeeds, the authenticator port is authorized.
'J1le specific exchange of EAP frames depends on the autllentication method that is used. Tbe figure shows
a message exchange that was initiated by the supplicant using the .Q.:!:l authentication method with Cisco
Identity Services Engine.
802.1X Authorization
This topic describes the 802.1 X authorization.
802.1X Authorization
Cisco ISE can perform per-user and per·group networ1<
authorization:
VLAN assignment: AppUes a specific VLAN
ACL assignment: Applies a specific ACL
Time-based access: Limits network access based on time of day
Cisco TrustSec:
Topology-independent, scalable access control
Classifies data traffic for a particular rOle
Ingress tagging via .§.9.1
Egress filtering via SGACLS
....... _.
The 802.1X framework provides authentication and authorization of clients that seek network access. The
authorization features include the following:
• VLAN assignment: With VLAN assignment, ·the authentication server can associate a VLAN with a
particular user or group, and instruct lhe switch to dynamically assign the authenticated user into that
VLAN. If yow organization uses an access control method that is based on different VLANs (with
routed ACLs or a firewall system configured egress to the VLANs), this method can ea.~ily provide
strong access control and auditing within an enterprise network.
.. ACL assignment: With ACL assignment, the :authentication server can associate an ACL with a
particular wer or group, and instruct the NAD to dynamically assign the ACL to the session oftb,e user.
This mechanism provides a very granular aocess control method because it extends to the port level.
.. Time-based access: With time-based aocess, the authentication server can control the times at which a
eertain user is allowed to Mnnectro the nei\Vork.
.. Cisco Tru.stSec: Security group access provides topology-independent. scalable acces.~ control. \Vith
security group access, tlle ingress swi£ches classify data traffic for a particular role and tag the traffic
with security group tags. The egress network devices evaluate the security group tags and perfontt
filtering by applying !he appropria<e security gJroup ACLs to the packets.
C 2014 Clsoo Sys1ems. Inc. Student Guide 1·2 1

802.1X VLAN Assignment
'lllis topic describes the 802. I X VLAN assignment.
802.1X VLAN Assignment
Doi...\I~Nt
......-~OK
,.. tiUJl - . ,. .
"'--
.........
Descrtption
Assigned VlAN DynamicallY assigned by the authenticatiOn server.
Guest YLAN Assigned if oo supplicant dotoot&d and~ does not apply.

R&stricted VLAN Assigned if the supplicant failS the authentication.
Default VLAN 08fault VLAN COtlfiQured on the port. Used with successful
authenticatiOn whO.n no specific VLAN is assigned.
Critical VLAN Assigned if the authenticatiOn servar iS unavailable.
Asslg ned VLAN

'J1le assigned VLAN is specified by the Authentic-ation Server in the RADIUS Access-Accept message.
Traditionally this is used to alisign the appropriate VLAN for users that can successfully authenticate with
the Aut.hentication Server. But it can also be used when authentication fails at the Authentication Server.
For example, the Authentication Server can be configured to assign a VLAN associated with guest users
when both u..c;er authentication and MAB fail This is different than the Guest VlAN described next. Tbe
advantage to using an Authentication Server assigned VLAN for guest access is that the guest VLAN
assignment and guest access will be centrally logged in the AAA system. This centralized audit trail is not
available for any of the other VLAN types described belo.w. The other VLANs described below are
managed locally on the switch. For example, if the Authentication Server passes an Access. Reject message
back to the switch and the s..-vitcb uses it's locally configured Guest VLAN or Restricted VLAN, there
won't be the centralized audit trail recording access in the .1\AA system.
Guest VLAN
When 802.1X is enabled on an access port, a user without an 802.1X client is typically denied access to the
network. By using the guest VLAN feature of 802.IX, you can offer limited network access to such users.
You can configure a guest VLAN for each 802. I X port.
If a guest VLAN is enabled on an 802.1X port, the switch assigns a client to the guest VLAN if the client
does not send EAPOL packets or doe.~ not reply to the EAP request or identity frame from the
authentication server. Multiple non-802.1X·capable clienJts may be allowed access when the switch port is
moved to the guest VLAN.
Restricted VLAN
You can configure a restricted VLAN (sometimes called an authentication. failed VLAN) for each 802.1X
port on a switch to provide Limited services to clients t:bat cannot access the guest VLAN. These clienns are
802.1X..eompliant and cannot access another VLAN because tlley fail ilie authentication process. A
restricted VLAN allows users who do not have valid credentials on an authentication server (typically.
visitors to an enterprise) to access a limited set of services. The administrator can control the services ·that
are available [0 the restricted VLAN.
Note A VLAN can bQ configured to be both tho guest VLAN and th~Hastrided VLAN, it you wantto provide
the same services to both types of uSer$.
The switch (authenticator) keeps a count of failed authentication attempts for any client. When me count
exceeds the maximum pennitted nwnber of authentication attempts, me pon moves to the restricted VLAN.
\Vhen the RADIUS server replies with either an EAJ> failure or an empty response that does not contain an
EAJl packet, tlle failed attempt count is incremented. The failed attempt counter resets when the port moves
into the restricted VLAN.
Default VLAN
The defauJt VLAN is the VLAN that is configured ·on the pon. When a client successfully authenticates to
the server and no dynamic VLAN is assigned by the authentication server, the default VLAN is retained on
the pon.
Critical VLAN
A critical VLAiN can be configured on the switch. 11le critical VLAN is tlle VlAN that is applied to tlle
802.1X-enabled interface if the authentication server is unavailable.

802.1X Downloadable ACLs
'Jllis topic describes the 802. I X downloadable ACLs.
802.1X Downloadable ACLs

Per-user dACLs provide differentiated networi< access
In RADIUS, authentication and authorization occurs in one step:
RADIUS SOf"Vt)r authenticates a user conn<~ctad to an 8Q-2.1X POf'l
RADIUS servor retriaves the ACL attributes and se.nds them to the switch
The switch applies the attributes to the 602.1X port for the duration of
the user session.
The switch removes the per-user ACl configuration when the session
is over, if authentication fails. or if a link·down condition occurs
~4:~ ......
··-···---·-···-···- --
· · ~
You can enable peHJSer ACLs to provide different levels of network access and service to an 802.1X·
authenticated user. When the RADIUS server authenticates a user that is connected lOan 802.1X port. it
retrieves the ACL attributes based on the user identity and sends them to the switch. ·111e switch applies the
attributes to the 802. 1X port for the duration of the user session. The switch removes the per·user ACL
configuration when the session is over, if authentication f.:ails. or if a link·down condition occurs. The
s..-vitch does not save RADfUS-specified ACLs in the running configuration. When the port is unauthorized,
the swi tch removes the ACL from the pan.
RADIUS supports pe.r·user attributes, including vendor·specific attributes. ·111ese VSJ\s are in octet·string
format and are passed to the switch line·hy·line as a resuh of the authorization process. The VSAs that are
used for per·user ACLs are inacl#<n>. 'Jlle following is an example depicting the syntax of a dACL:
tp : inaclt lOO•permit tp any 209 . 165 . 201 . 2 2SS . 2S5. 2SS . 2SS
tp : inaelt200 ~permit ip any 209 . 165 . 201 . 3 25S . 2SS . 2SS . 2SS
tp : inac1t300•deny ip any any
1-2<11 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 Qsco Sy&ems. Inc.
802.1X Host Modes
This topic describes the 802.1 X host modes.
802.1X Host Modes

Single Host mode:
Only 000 dGviCG (MAC addrO:S.$) per port
Seoond cfiG.nt causes unauthorized port state
Multiple Host mode:
One device (first MAC address) a utMnlk:atM
All subse<::juent devices get access
MDAmode:
One data and one voico VLAN per port
Independent authentiCatiOn of phOne and PC
Multiple Authentication mode:
Superset of MOA
AuthMticates twery MAC address
One VLAN for au devices, per devioo dACL
._ !JS4)d for hubs, access points, Virtual Machines
The host mode of the 802.1X port determines whether more than one client can be authenticated on the pon
and how authentication will be enforced. You can configure an 802. 1X port to use any of the fow host
modes that are described below. 1n addition, each mode may be modified to allow pre~authentication open
access.
Single Host Mode
Ln single·host mode, only one client can be connected to the 802.1X enabled pon. The switch detects the
4
client when the port changes to the up state and sen.ds out an EAJ>OL frame. Access is provided for the
client after authentication. Packets from other hosts: are dropped. If the client leaves or Lc; replaced with
another client, the switch changes the port Link state to down, and the port returns to the unauthorized state.
Multiple Host Mode
(n Multiple Host mode (often called multi·host mode), you can attach multiple hosts to a single 802.1X·
enabled port. ln this mode, only one of the attached! clients must be authorized for aU clients to be granted
network access. If the port becomes unauthorized (reauthentication fails or an EAPOL Logoff message is
received), the authenticator denies network access to all of the attached clients.
Multiple Domain Authentication Mode
MDA mode (often called multi-domain mode) allows an U• phone and a single host behind the U• phone to
authenticate independently, using 802.1X, MAS, or (for the host only) web·based authentication. In this
application, multidomain refers to two domains (data and voice VLAN), and only one MAC address is
allowed per domain. The switch can place the host 'in the data VLAN and the 1J>phone in the voice VLAN,
but they appear on the same switch port. The data and voice VLAN assignment can be obtained from the
VSAs received from the AAA server.

Multiple Authentication Mode
Multiple Authentication mode (often called multi-auth mode) allows one 802.1X or MAS client on the
voice VL.A!l"' and multiple authenticated 802.1X, MAS, or web authorization clients on the data VLAN.
When a hub or access point is connected to an 802.1X port, multi~ auth mode provides enhanced security
over the multi-host mode by requiring authentication of each connected client For non~802. 1 X devices,
MAS or web..based authentication can be used as the fallback method for individual host authentications,
which aUO\\'S different hosts to be authenticated through d ifferent methods on a single port.
In thi~; mode, the first host that is authorized on the port d etines the VLAN assignment, and subsequent
hosts wiiJ be added to the same VLAN. They may either ~ave no VLAN assignment in the RADIUS
database, or their configured group VLAN must match the assigned group VLAN on the port. Otherwise
they w:ill be denied access to the port.
Also, if the Authentication Server assigns a dACL, the dACL will be modified to use the authenticated
host's lP address as the source address. That is, in multi-auth mode, per-host differentiated dACLs are
supported.
802.1X Phased Deployment
This topic describes the 802.1 X phased deployment.
802.1X Phased Deploym ent

Phased approach for 802.1x deployment
Gradual authorization enforcement
Visibility into who wmsucceed and who will fail
0t)termir.e th& failure r$<lSOn
Remediate before implementing- stronger enforcement
Modes:
Monitor mOde
Low impact mode
ClOsed mOde
....... _.
802.1X can be implemented using a phased deployment model that allows for limited impact on network
access while gradually introducing authentication and authorization. ln the phased approach dle network
administrators can gain visibility who will succeed and who will fail, detennine the failure reason, and
remediate the problem before enabling a stronger enforcement mode. The three modes are: monitor, low
i:mpact, and closed mode.
A phased deployment will utilize monitor mode first and then will shift to either low impact mode or closed
mode. A phased deployment typically also includes the strategy of phases across a topology. for example,
implementation may occur sequentially through each remote site and finish with headquarters. Another
example would be to implement on wireless networks first and then implement on wired networks.

802.1X Monitor Mode
'J'bis topic describes the 802.1X monitor mode.
802.1X Monitor Mode

. Even failed authentication will allow access
. Network administrators can:
Se>e whO would haw failed
Rasolv& thoQ problem before causing a Denial of 5erviee
. No effect on user or endpoint access
. AAA RADIUS accounting provides visibilrty into 802.1X operation
tnutt!•ee C1g;a!ltt£t1:et:t~ct0/l
ll'.li:l:o.ntte~t-ton l'..on-M<Io. l'lulct·a~tll
·~~~~:-"~1:.-«':io" tfo!~
o'.ltl!oelttl'C«~ion PQtt-c:x.~rol outo
=·
dc~lx ~~ a~~hcr.t ~c~~r
·-~
The monitor mode allows for the deployment of the authentication methods 802.1X, MAB, or web
authentication without any effect on user or endpoint access to the ne[Work. Monitor mode is like placing a
security camera at the door to monitor and record port access behavior. With AAA RADIUS accounting
enabled, you can log authentication attempts and gain visibility of whom and what is connecting to your
network with an audit trail. You can discover the following infonnation:
W.hich endpoints, such as PCs, printers, cameras, and so on, are connecting to your ne[Work
W.here these endpoints connect to the network (switch, port)
Whetherthey are 802.1X-capable or not
W.hether they have valid credentials
In the event of failed MAB attempts, whether [he endpoints have known, valid MAC addresses
Monitor mode is enabled using 80i.IX with d>e open acc.ess and multiauth mode Cisco !OS Sot\ware
features. Monitor mode is configured with tlle authentication open command.
The default behavior of 802.1X is to block all data traffic except EAI'OL. However, the open access feature
allows you the option of providing unrestricted access to all traffic, even though authentication (802.1X,
MAS, or web authorization) is enabled. Open access is accomplished with no impact to end users or
network-attached hosts.
1-2& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
802.1X Low Impact Mode
This topic describes the 802.1 X low impact mode.
802.1X Low Impact Mode

Limrted, basic access prior to authentication
Port ACL applied to the switch in terface
Default port ACL, it no intarfac& ACL &xists
Grant specific access after successful authentication
~.reooiv&d from SGrv&r
lr.te~fate Gt~4bitttber~t 0/1
autbe~tle6tion h~t-~ode ~ultl-4Utb
~nf!ES'!io~
.t\ltlwtl'lt.!~ttor~ po:'t-eo..'!t:rc:. 4\lto
~·
; ~~~t~dc:ato: ~
~1i~ iSC !LlL~~
....... _.
\Vith low-impact mode, you are able to strengthen l!he security stance by adding an ingress ACL to the
802.1X-enabled switch port that is configured in open mode. lhis ACL provides the ability to maintai:n
whatever basic connectivity is required for unauthenticated hosts.
This procedure can be used to provide a host that is. attached to a default port with the ability to use DHCJ>,
~. and perhaps get to the internet, while blocking access to internal resources.
\Vhen a device connected to that switch port authenticates, an appropriate authorization policy can be
applied. Options for authorization policies include downloadable ACLs, dynamic VLAN assignment or
security group tags.

802.1X Closed Mode
'lllis topic describes the 802. I X closed mode.
802.1X Closed Mode

. No access p<ior to login (only EAPol)
. Specific access after successful authentication
. Defau~ 802.1X behavior
. Most restrictive method
in~t'rfooe Gio;obnstnernet ¢/J.
o~t~,~icot~on hoot-mode ~lti-outh
....
~utho~t1e~t 1cn po!t-cor.~ t¢1 a~~
d ~t• ~ P5C outht'~tic«tor
·-~
The default behavior on a Cisco S\\~ tcb port configured for 802.1X is closed mode. With closed mode, only
£AI>OL traffic is allowed until lhe authentication process completes. Authentication is required before any
basic network services are available, including DHCP. Consideration of802.1X limers is very important
with closed mode.
When a device connected to that switch port authenticates, an appropriate authorizat ion policy can be
applied. Options for authorization policies include downloadable ACLs, dynamic VLAN a.lisignment or
security group tags.
Closed mode was previously called high security mode. 'this tenn can be a misnomer. Closed mode is not
necessarily more secure than a properly configured low impact mode.
1~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.

802.1X Deployment Mode Comparison
This topic contraSts the 802.1 X deployment modes.
802.1X Deployment Mode Comparison
IEEE 802.1X Wired Modes

Monttor Low-Impact
Mode Closed Mode
Mode Mode
r~. "-·-·
""''""""'···"' .......""_ ""'·""-
., ,., ...
c~-'<>'·''""'
""'" """" I • ... t "'' \
...,...,
"'~'"""''-"'~
,........ ,.,.>\(_ ' -"""
o l f<.o Oq
r• .-~•·•
·~
....... _.
This figure summarizes the pre~authentication and posr~authentication behavior of the three 802.1X
deployment phases: monitor, low-impact, and closed modes.
[n monitor mode, the open access feature rransforms the normal behavior of blocking traffic on an 802.1X·
enabled port until authentication and authorization are successfully perfonned. Full access is provided
independently of the authentication results.
Ln low-impact mode, a pre--authentication ACL is added to the port to permit some basic connectivity. After
successful authentication, options to enforce authorization policy include downloadable ACLs, dynamic
VLAN assignment and Security Group Tags.
[n closed mode, only EAPOL traffic is petmitted Wltil the user authenticates. After successful
authentication, options to enforce authorization policy include downloadable ACLs, dynamic VLAN
assignment and security group tags. The authorization options available in closed mode are identical to the
options available in low.lmpact mode.

802.1X Phased Deployment Guidelines
'Jllis topic describes the 802. I X phased deployment guidelines.
802.1X Phased Deployment Guidelines

Begin with monitor mode on a definab le area of the network
Gain visibility. what succeeds and wflat fails
Dotermino the failure r eason
Rom.&diate
Select End State
Low impact modo
Closed mod&
Incremental Phases
Transition area from monitor mexia to end state
Extend to otMr areas of the network
802. 1X can be implemented using a phased deployment model that allows for limited impact on network
access while gradually imroducing authentication and authorization. It is generaiJy recommended to begin
the phased deployment with monitor mode in a well defmed area of the network. lhink of this phase as an
audit phase. Your network administrators can gain visibil:ity into who will succeed and who will fail,
determ:ine the failure reason, and remediate the problem before enabling a stronger enforcement mode.
Before moving from monitor mode to a stronger enforcement mode, you must decide whether low impact
mode or closed mode is most appropriate. The choice will depend on factors internal to your organization
and your organization's security policy. It is possible that different modes may be appropriate in different
areas of your network. f'or example it may be optimal to use low impact mode at the headquarters campus
and closed mode at branch offices.
After a successful phase of deployment, it is time to move to the next phase. After a successful audit phase,
you can move to the preferred enforcement mode for that area of the network. You can also extend the
identity solution to other areas of the network using monhor mode.
1~2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, l nc.
This topic describes the~-
1 Endpoint connects
2. 802. 1X authentication completes successfully
3. Initial authorization policy: allow posture assessment and remediation
4. Posture assessment completes, endpoint is compliant
5. CoA message from ISE to switch, allow context appropriate access
••
••
. ...... _.
Traditional RADIUS allows the RADfUS client to make AAA requests to RADIUS servers. lfthe
circumstances changed, there was no mechanism for the RADIUS server to dynamically rerurn to the •Client
,.;than upda!ed authorization policy. To address d>.is, RADIUS CoA was developed and defined in RFC
5 176.
The figure depicts one example of the potential flow using CoA. Note that the example is simplified for
instructional pwposes and does not necessarily include all real*wortd considerations or demonstrate real
configuration syntax. An explanadon of dle flow foUows:
I . At initial state, a switch port is in an unauthenticated state. The ACL that is in place on the switch: port
will allow some basic network functionality without authentication. such as DHCP ·ba~ed til address
assignment, TFTP download of lP phone configurations, Active Directory machine authentication and,
of course, 802.1X authentication. An endpoint connects and user authentication that is based on 8:02.1X
comple!es successfully.
2 . Cisco Identity Services Engine is aware of the user identity, but has not yet performed posture
assessment. As such, it associates a temporary policy with this session.
3. Cisco ISE sends a RADIUS Access~Accept message to the switch, specifying an authorization pc>licy
that allows two things. (1) lP connectivity to Cisco ISE to allow the posture assessment to complete.
(2) W connectivity to a remediation server in ca~e posture assessment fails. Tllls policy is dynamically
applied to the switch using a d.ACL.
4. The posture assessment completes and the endpoint is found to be compliant. Cisco lSE associates a
full access policy with me session.
5. Ci.iiico ISE issues a CoA message to the switch, which causes an update to the authorization policy that
is assigned to the switch port, granting context appropriate network access.

MAC Authentication Bypass
'Jllis topic describes the MAB feature.
MAC Authentication Bypass

A method to allow exemptions from 802.1X authentication
Certain MAC addresses skip the regular authentication process
MAC address sent in RADIUS Access-Request message
Exempted MAC addresses defined as endpoints on the server
ijiM8'#=*
Not all netWork devices support an 802. 1X supplicant. Pr.inters, security cameras and badge readers are a
few examples. Prior to MAS, it was common to simply n10t configure 802.1X on switch ports supporting
such devices. This approach has several drawbacks. It doesn't allow consistent configuration of aU access
s"'<itch ports. It doesn't allow the RADIUS server to maintain access records on those switch ports. It
requires reconfiguration of switch ports if devices move. at allo\\'S someone with physical access to the wall
port to replace the expected device with any device of their choosing. MAS provides a better way of
handling devices that do not support an 802.1 X supplican.t.
When the MAB feature is enabled on an 802.1X port, the authenticator uses the MAC address as the client
identity. The authentication server has a database of client !vtAC addresses that are allowed to access the
network. After detecting a client on an 802.1X port, the authenticator waits for an Ethernet frame from the
client. Tbe authenticator sends an Access·Request message using the MAC address of the endpoint as both
the usemame and the password to the RADfUS server. ·Jbe RADfUS server can then compare the MAC
address against enoies in its policy database to make authorization decisions.
Jf an EAPOL packet is detected on the interface during th~ lifetime oftlle link, the authenticator determines
that the device connected to that interface is an 802.1X·capable supplicant and uses 802.1X authentication
(nor MAB) to authorize the interface.
1~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Extensible Authentication Protocol
This topic describes the Extensible Authentication Protocol.
Extensible Authentication Protocol

Authentication exchange direi:t between the supplicant and the
authentication server
Encapsulation:
Between supplicant and authenti<:ator • in th& edge LAN protocol (EAPOL:
Ethernet, 802.1 1)
Between authenticator and a ulh~ntication server • inside RAD IUS
- -
...............
....... _.
802.1X uses the EAP ro authenticate users who wish to access the network. EAP messages are exchanged
between a supplicant and an authenticator, which are tunneled inside the EAPOL and RADIUS protocols.
The authenticator is aware of this interaction, but does not actively participate in it. Instead, it waits for the
decision of the authentication server, which is communicated to it natively over the RAOlUS protocoti. The
specific exchange ofEAP frames depends on the authentication method (that is, EAP variety) being used.
Protocols from the EAl, family offload the authentication process from typical authenticators such as
systems, applications, and network devices to EAJ, authentication servers. EAP introduces the philosophy
that the supplicant should talk directly to the authentication server, with all intermediate devices acting only
as relays. EAP provides two way authentication between the client and the authentication server. Many
4
authentication methods (some of them hybrid) are poosible, and they support many types of credentials.
On the edge of the network, between me authenticating entity (the supplicant) and the authenticator
(typically the edge network devic.:), Ei\P is di~tly encapsulated in the Li\N protocol using Ci\POL
encapsulation. 'Between the authenticator and the authentication server, EAP is encapsulated inside
RADIUS, with the authenticator acting only as a relay between EAPOL and RADIUS EAI' payloads. ·111e
result of the authentication process is communicated from the authentication server to the authenticator
natively over RADIUS.
The main advantage of £AJ> is that it is extensible to implement almost arbitrary authentication processes.
Furthennore, rather than requiring the authenticator (for example, a LAN switch) to be updated to support
each new authentication method, £AP only requires that the authenticating entity (supplicant) and the
authentication server speak the authentication protocol. Therefore, using £AP, the interoperability and
compatibility of authentication methods becomes simpler.

Tunnel and Non-Tunnel EAP
'J'bis topic describes the tunneled and non~runneled EAJ,.
Tunnel and Non-Tunnel EAP
In the simple, non*tunnel EAP architecture a single EAP session exists between the supplicant and the
authentication server. In this architecture, the supplicant sends its identity (name) in the clear to the
authentication server. Tbis is followed by an exchange that authenticates the authentication server to dle
user, and the user to the authentication server. lftbe user is successfully authenticated, the authentication
server signals this to the authenticator via the RADIUS protocol. This mode is simple [0 understand, but has
the limitation of transmitting the user identity ~ ut not the credentials) in the clear. This limitation may not
be considered a risk for many organizations. Transmitting the challenge-response authentication exchange
in the clear can facilitate some passive dictionary attacks, if user passwords are weak. Also, these EAP
architectures cannot easily support onewtime passwords, because these passwords do not support challenge~
response methods that are typically used inside the EAJ, authentication exchange.
To overcome these limitations, you can use a tunneled EAP architecture, in wbjch an outer EAJ,
encapsulates an inner EAP. The outer EAP provides server authentication, and a cryptographically secure
runnel for the inner EAP method to run in. Typical outer 'EAl's are I'EAP and EAP-1'AST. EAP·
MSCHAI>v2, pAl'· TLS and Ji!\1'-QTG are commonly used for the inner EAI' .
1~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Non-Tunnel EAP Types
This topic describes the non ~tunnel EAP types.
Non-Tunnel EAP Types

Authontlcation Supported
EAPTypo WMntoU&e
Protocol Crodentlala
EAP M05
4 Challenge Passwords fOr client AVO(d. Vulnerable to
response with authQntieation. No man-in-the-middle
hasf'ling server authentication. attackS.
EAP- Challenge- Passwords for client In Active DiteCtOiy
MSCHAPv2 response with ands:erver environments
hashing authQntieation
EAP-TLS Challenge c.trtificates for Client With client-side

response with and s.Etrver certificat06
public keys authentiCation
EAP-GTC Ctoartexl Passvrords or OTPs OTP environment

transfer of for client
passwords autOOntieation
....... _.
EAP has many variations that use different classes of authentication protocols and support different
credentials. The most common non-tunneled EAP types are described below.
EAP·~IDS: This EAI' type is like ,l;.J:!AJ?. and uses a challenge response mechanism with hashing. It only
supports passwords as client credentials and does not authenticate the server, making it vulnerable to man·
in-the--middle attacks. EAP·MDS should be avoided, unless it is tunneled inside another EAP that
authenticates the server (for example, PEAP).
EAP·MSC8AI'v2: This EAP type is like EAP-MD5 but provides bidirectional authentication. It supports
passwords for both client and server credentials, aOO can also work with Microsoft password hashes instead
of passwords, making it suitable for integration with Windows (domain) password databases. EAP·
MSCHAPv2 is therefore recommended in authentication architectures that use plain passwords and can be
deployed over untrusted channels.
EAP-TLS: This BAP type is a challenge-response method using public key cryptography. II supports
public and private key pairs as client and server credentials. EAJ,. TLS requires a public key infrastructure
(PKI) for public key (certificate) distribution.
EAP..CTC: Tbis is a simple EAP type. It sends the: cleartext password or one--time password to the
authentication server. EAP..OTC is the only protocol that supports one time passwords as client credentials,
4
but should always be tunneled inside l'EAP or EAP·fAST, which provide a secure communications
channel.

Tunnel EAP Types
'Jllis topic describes the tunneled EAP types.
Tunnel EAP Types

Aulhontlcat1on Supported '
EAPTypa WhontoUse
Protocol CMdentlal:s
EAP-FAST Cha!lengo- Passwords or To support plain

rMponse with OTPS for cliet'lt, passwords as
symm-etric and passwords fOr diGnt and server
cryptography serve-r cred-entials
authenticatiOn
PEAP Challengo Certificate ~rver· To tunnel other

msponse with side rtner EAP
pu~lic key autheonucatioo. variatiOO$: EAP·
cryptography Other creden tial$ MSCHAPV20<
inside PEAP· EAP-GTC
tunneled proloc:ols
EAP-FAST: This EAJ, type is a runnelingprotoool that c:an runnel inner EAP varieties requiring a secure
channeL EAP ~ fAST can use either passwords or a certificate to authenticate a server. Jt may require secure
initial provisioning of server credentials (called the PAC) on clients. You will typically use EAP-f ASTor
EAP-TLS to tunnel EAP-MSCHAPv2 inside i!, to provid>e identity protection, or to tunnel EAP-GTC inside
it. This is particularly aue if you need a single authentication protocol that does not require certificates for
both your wired and wireless infrastructures.
PEAP: An EAP tunneling protocol that can tunnel inner EAP varietie." requiring a secure channeL PEAl,
authenticates authentication servers using public and private key pairs. It requires administrators to
provision the autl1entication server certificate or root CA certificate on clients. You will typically use P-EAP
to tunnel EAP MSCHAPv2 or EAP· TLS inside it, to provide identity protection, or to tunnel EAP~GTC
8
inside it.
1~ lmplemen~ng Cisco Security Access Sot\Jtlons -0 2014 asco Sy&ems, l nc.

Traditional User and Machine Authentication
This topic describes the user and machine authentication.
Traditional User and Machine Authentication

Separate, independent EAP procedures and results for:
User auth&nticaUon
Ma:chine authentication
User authentication when user lo,gged on
Machine authentication when user logged off
Support in:
CiscoNAM
WindOiYS and other native supplicants
....... _.
Traditional machine and user authentication works by treating the machine and user as two separate and
independent entities. The user authentication is performed when the user logs on. When the user logs off,
machine autllentication is performed. This traditional philosophy does not have the intelligence of
evaluating me user authentication in combination with the machine authentication.
The traditional user and machine authentication is supported by all common supplicants, including the
AnyConnect supplicant . NAM, the Windows native supplicant, and other third party vendors.

EAP Chaining
'J'bis topic describes the EAP chaining.
EAP Chaining
Two EAP exchanges inside the same T LS outer tunnel
Example: determine if enterprise user connects from corporate d evice
First Implemented in EAP· FASTv2
Supported in Cisco NAM 3.1 and Cisco ISE 1.1 .1 and later
IETF standardization p rocess: TEAP
8 -- 0 ·- - 0 0
~ 8 - G (.-- J
CAP chaining supports machine and user authentication but both authentications are perfonned inside a
single outer TLS tunnel. EAP-FAST protocol is used to establish the outer tunnel and control the order of
the inner exchanges. EAP chaining allows you to combine the results of the machine and user
authentications into a single overall authentication result. Based on this infonnation you can, for example,
assign a the widest privilege set to enterprise users who connect from corporate-managed endpoints.
EAP clhaining was flrst implemented in EAP~ FASTv2. EAP~fASTv2 is a Cisco-engineered solution
supported by Cisco Network Access Manager 3.1 and Cisco Identity Services Engine 1.1.1 and later. The
IETF is working on the standards-based equivalent, TEAl'.
EAP Chaining Operation
This topic describes the EAP chaining operation.
EAP Chaining Operation

1 TlS tunnel is negotiated to protect the inner MS.CHAPv2 exchanges
2. Cisco ISE sends an Identity..Type TLV: machine Of user
3. AnyConnect suppUcant responds.:
By prOviding appropriate au1henlieation credentials (machine Or user)
By rGturning the other Identity-Typo TLV
4. ISE may proceed with the second Identity·Type TLV
5. ISE determines the status of the user and endpoint
....... _.
EAP·FAST authentication occurs in two phases. In the first phase EAP· FAST employs a TlS handshake to
provide and authenticate key exchanges using TLV' objects to establish a protected runnel. These TLV
objects are used to convey authentication related data betwee.n the client and server. Once the tunnel is
established, the second phase begins with the client and Cisco Identity Services Engine node engaging in
further conversations to establish the required authentication and authorization policies. EAP Chaining
employsan optional Identity-Type TLV at the stan of the second phase of llAP· FAST authentication.
When the secure TLS tunnel has been established, l!he general EAP chaining flow is based on a request/
response exchange:
.. The lS.E server sends the optional ldentity·Type TLV. machine or user, and request identity to the
client
.. The client responds back with either lhe same ldentity·Type TLV, or proposes anot:ber identity·type.
This exchange wiU be demonstrated in several deployment scenarios.

EAP Chaining: Corporate Asset and User
'J'bis topic describes the EAP chaining flow with corporate asset and user.
EAP Chaining: Corporate Asset and User

........
ljl~ ....
•• - -•
I .e '"""'... -
- ,... _
lll............. IIN'•'"'"'~
D<•' PC'IJ
I I ~·
- .,.,..
i
r JW'.n.::::.... ~
....·~ r-
~
. . .tut ........
-
_ ''" 1-
JE-,P.n-. • ...,...rEAP -
I ,_
'''' - .......
~lf.ll'.nv;-~
....,..,...fJ ..II''
·~ous
' • ~n.v•~
' I£N'" f\.U ~

---~u..l-='0 ~
'' '' ~
'lJ
~~~ -
•
: - lt."((IU5.!
[ EAPC:hltningResull Equali "User .ci ! 1 I Cbt 4 bolh" h-r J
This diagram illustrates the EAP chaining flow when a enterprise user attempts access from a corporate·
managed endpoint.
When the TLS tunnel is successfully negotiated, the Cisco l dentity Services Engine sends an Identity·Type
TLV of type "Machine". Next, the ISE seJVer will recognize whether the client supports EAI' Chaining by
analyzing the response to the Identity-Type TLV request If the response contains a matching Identity-Type
TLV then the client suppons £AP Chaining. ln this exam.{)le, me client matches both Machine and User
Identity· Type TLV requests deeming it as a corporate device. ·Jlte result as presented by the IS£ will be
described by the expression "EA I,CbainingResult Equals User and Machine both succeeded".
EAP Chaining: Corporate Asset, User Logged Off
This topic describes the EAP chaining flow with corporate asset and user logged off.
EAP Chaining: Corporate Asset, User Logged

Off
----
~·,_._ ""
" ~ - C lll ~ - iAATIOIN •~
I ~ Jill'". · ~n.V • """""''

- IWIIUI~IMifllooOoo,~U~• .,.._I
c:;;; _, .._.....
--
'' (.J!O.
~
jLY>f\V ..............~,, -
tl'i' •-~ IIEN' IC '.-:I
I
I - .-.n.. ..
£«111t.........
U.P• ~;· ..
u..t - .J'AO'If.Ac(-~ ILVI'•'I\V •
-- -
uwt
_,_ . . .,. -
f-
I ,_..__l\\'. , ....... ~ AACIUIAtOMI-IM
'' j( .,.._.YI.v•r.....,..
u...,
! ~ot• S:
c EAPOwh*;o? «Equal8 "MMIC:ttinnt tu •:led.NoUW l

....... _.
This diagram illustrates the EAP chaining flow when a corporate·managed endpoint is connected to the
network and the user is logged off.
[n the EAl, exchange for user authentication, the supplicant rerums the Result*TLV set to "failure". T.his
result allows the Cisco Identity Services Engine to aocept the access request as a successful machine
authentication with no user access.

EAP Chaining: Personal Asset with NAM
'J'bis topic describes the EAP chaining flow with personal asset running the AnyConnect supplicant.
EAP Chaining: Personal Asset with NAM

~ :=. ..... -IWII I • r e 0..*- •
Tbis diagram illustrates the EAP chaining flow when an enterprise user connects from personal asset
running the AnyConnect supplicant
In this example, the client does not match the server's Machine Identity·Type tLV request, since this
device is not enrolled in the corporate domain. Authentication continues and matches on the server's User
Identity· Type TLV request, thus deeming it as a non·corporate device. The user authentication is
successful The result presented by the Cisco Identity Services £nginc will be "EAPChaining.Result Equals
User Succeeded and Machine failed".
1-4<11 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
EAP Chaining: Personal 3rd Party Asset
This topic describes the EAP chaining flow with personal asset running a third party supplicant.
EAP Chaining: Personal 3rd Party Asset
....... _.
This diagram illustrates the EAP chaining flow when an enterprise user connects from personal asset
running a third party supplicant.
[f there is no Identity·Type TLV in the response then EAP Chaining is not supported by the client. Nomlal
processing for existing EAP·f"ASTvl implementation applies. In rhis example, the client, being an Android
tablet, does not support EAP Chaining and continues with EAP·FAST authentication, deeming this as a
non..corporate device. The result presented by the Cisco Identity Services Engine '"'ill be
'"EAPChainingResult Equals No Chaining". The user or machine authentication may succeed using the
traditional EAP-FASTv2 method. Depending on the ISE policy, appropriate access privileges will be
assigned to the endpoint.

Cis.co AnyConnect 3.x Supplicant
'J'bis topic describes the Cisco AnyConnect 3.x Supplicant
Cisco AnyConnect 3.x Supplicant

Network Access Manager
Layer 2 dOVioe manag&mont and authetntication, induding 802.1X
EAP d'lai'ling
Downlink MACSGc
Other integrated modules include:
Host Scan
Tal&m&try
Cloud Web Security
-----
f = ···--
-
$ ...... """"'
The Cisco AnyConnect Secure Mobility client is the next·· generation VPN client that, starting in version
3.0, integrates several modules of special interest to Cisco Identity Services Engine. Tbe key component is
the Network Access Manager. It provides Layer 2 device management and authentication for access to both
wired and wireless networks. 'J'his functionality includes the 802.1X supplicant and offers support for
downlink MACsec. Downlink MACsec offers Layer 2 encryption of traffic between the AnyConnect
endpoint and the adjacent switch.
Other integrated modules include:
Host Scan-Provides the AnyConnect Secure Mobility Client the ability to identify the operating
system, antivirus, antispyware, and firewall so~<are installed on the host prior to creating a remote
access connection to the Cisco Adaptive Security Appliance. Based on this prelog:in evaluation, you
can control which host~ are allowed to create a remote access connection to the security appliance. Tbe
Host Scan application is delivered with the posture module and is the application that gathers this
infonnation.
Telemeay- .Sends information about the origin ofm:alicious content detected by the antivirus software
to the web filtering infrastructure, which uses this data to provide better URL filtering rules.
Cloud Web Securicy- Routes HTfl' and HTTI'S traffic to the Cloud Web Security scanning proxy
server for content analysis, detection of malware, and administration of acceptable use policies.
Summary
This topic summarizes the key points that were discussed in tbis Jesson.
Summary
802.1X is an IEEE standard for media~level access control.
802.1X can be deployed inaemefltally in the monitor, low-impact, and
closed mode.
MAC Authentication Bypass is used to handle 802.1X exemptions.
602.1X uses the Extensible Authentication Protocol (EAP) to
authenticate users who wish to access the network.
EAP chaining offers a method to perfonn user and machine
authentication ins;de a single TLS tunnel.
....... _
C 2014 Clsoo Sys1ems. Inc. Student Guide 1·41'

Lesson 31
Identity System Quick Start

There is a great deaJ of complexity in a full secure access solution. This Jesson is intended to provide details
on the minimum configuration necessary to quickly get an .!§g§ 802.1X environment running in monitor
mode using the native Windows supplicant, a Cisco switch as rbe authenticator and Cisco ldentity Services
Engine as the authentication server. It describes bow to configure the Cisco switch for Al":A,.B-1.\DfUS and
802.1X. It describes the configuration of local users and network access devices in Cisco Identity Services
Engine. It also explores me default authentication policy in Cisco ISE. IEEE 802.1X monitor mode. It will
be up to other lessons to build upon the base that is provided in this lesson.
• Describe the logging into the IS£
• Describe the organization of the Cisco JSB GUD
.. Describe how to use the internal user database on the Cisco ldentity Services Engine
Describe the NADs
.. Describe the default authentication policy on Cisco Identity Services Bngine
.. Describe the 802.1X authenticator configu.ratiol!l procedure
• I:lescribe the the global AAA settings
.. Describe how to configure the RADIUS peering
• Configure the 802.1X global and port settings ior monitor mode
.. Describe the 802.1X Windows native supplicant
.. Describe how to verifY authentication on the Cisco ldentity Services Engine
Describe how to verifY the authentication status on the switc.h
Logging in to Cisco ISE
Tbis topic describes how to log in to the Cisco Identity Services Engine .QYJ.
Logging in to Cisco ISE

https:/J<your-ise-hostname>
If ISE is not yet enrolled in .~KI , expect a sea .Hity warning
- _.... . . . -.....
---
-- -~·
-
. . .=.-=.---- -
~
-
·- .. ·-·
'J'he GUI is the primary configwation and administration method for Cisco tsE. You access the Cisco IS"E
GUI from a web browser by connecting to the Cisco J'SE v ia H"ITl'S.
Prior to the ftrs t login to the GUI. Cisco ISE must have its base configuration set from the CU. There is a
setup script which walks the administrator through the process. The script prompts for settings such as
hostname. domain name, lJ> address. default gateway, ON~ server and NTP server. The setup script also
prompts for administrator credentials which will be used for future logins to rhe CLI and to the GU!.
It must be noted that there are separate admini.~trator accounts for the CLI and for the GUl. rhe setup script
will define rwo accounts with identical credentials. However. any changes [0 either account after this
assignment are not automatically reflected in the other account. To keep the credentials synchronized
requires changing the credentials in both the CLI and the GUl.
Organization of Cisco ISE GUI
This topic describes the organization of the Cisco Identity Services £ngine GUl
Organization of Cisco ISE GUI

Policy·based configuration
,_·---
·-___
~ -- ·--
--- ---
·- ---- - ·-- ·--
..,
-
--·-
-- -
·---
-·--- ·--
·---
--
-- -
_..._.,_
- -- --
---
-
--
~
I
··-
l'i!r--- !. . _r: .;.=
--=- !. .
- • • • ,-
-- ------ -·---
__
- -- ........_,. --
-_ -- -· __
··- ·---
·--- -- ,.
·-- --
·-· ·-.
...
·--
,
... __ _ --~
The four main tabs are:

.. Home-Provides a dashboard populated with customizable dashlets that allow you to view important
system health and operational status at a glance.
.. Operations- Provides a list of various monitoring, reponing and troubleshooting tools
.. Policy- Provides the configuration point to Cisco ISE's policy oriented features such as authentication,
authorization, profiling and posture.
.. Administration-l,rovides the configuration point [0 Cisco ISE's deploymem ~relevant parameters.

Local User Database
'J'bis topic describes bow to use the internal user database on the Cisco Identity Services £ngine.
Local User Database

Identity source that does not require any external servers
Database of user accounts
1
-=- - - - - · -·
--- ~-.-·
--.. --------
~. :...-- ~~~-- ~--
---
-
·- . ~·
-·-· -
·-·--- ·--
• .::;:~
. --
..·-·-
= ~J
.
·-·-•
·-- ~-
---
·---- -
·-- - I •
--
---.., I
The inttemal user database offers a simple \\'3Y to provision users and endpoints locally on the Cisco ISE.
Tbis approach does not require any external servers and is thus applicable to test beds, temporary
instatlations, and very small deployments.
For easier management of user accounts, assign users to user groups. User accounts have a set of attributes.
Password Lli a mandatory attribute of an internal Cisco ISE user.
Note, some protocols, such as 'EAP- TLS and 'PEAf-J LS., do not use password~based authentication. The
internal database does not support the use of these.protocols.
1-.52 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Network Access Devices in Cisco ISE
This topic describes the role oftL.AQs in a Cisco ld~ntity Services Engine deployment.
Network Access Devices in Cisco ISE

Enforce network poUcies
Common enforcement mechanisms: dACLs, VLANs, security groups
Network device types: switches, W LCs, Cisco ASA
Can be grouped for e fficient administration
Act as:
802.1X authenticalorS
RADIUS c!iGn ts
--
.. --·-·· __,._ ...
~== ----' , -. . . .-- -·-· - ..!o
....... _.
NADs are RADIUS clients and Cisco Identity Services Engine is their RADIUS server. They perfonn the
role of authenticators in an 802.1X environment. They must act as the proxy between the supplicant on the
endpoint and Cisco ISE as the authentication server. They are also responsible for enforcing the
authorization policy as specified by Cisco lSE.
Cisco CSE decides whether the client traffic should be permitted into the enterprise network and which
enforcement mechanisms should be applied. The lSE oommunicales the decision to the NAO. The NAD is
directly responsible for implementing the enforcement options. Common enforcement options include:
.. VLAN assigrunem
dACLs
• Security group tags
Basic NAD types include !be following:
LAN switches
• WLCs
.. Adaptive security appliances

Network Access Devices in Cisco ISE (Cont.)
Many NAD settings are optionaL
-- -- ·- ....
---
•
·-- -
··- La,~
- ..<i:::J
'
--=...J --""""--I
--
- - c:::::=:J
·--- o-o..TpMd~
•
--~
- a=
·--
I
--
l
---
-- -
- -- -
$NMP _,.,.
·--
·---
--.~
..... r-.. ·---
, -~ ---·- -
, __--~
'J'he device name. lP address and network device group settings are required settings for NADs in Cisco
ISE. Many settings, such as SNMI\ or Security Group Access parameters (in the figure referred to a~
TrustSec) are optional, and will be used when the enterprise scenario demands it.
Network Device Groups are useful for organizing and selecting devices. By default, Cisco JSE utilizes rn·o
device group hierarchies: 'Device Type and Location. Other hierarchies can be defmed 'For example, in an
enterprise environment using a phased roll out, a parent group named Stage with child groups Monitor
Mode, Low Impact Mode and Closed Mode mig)lt be defined.
1-S-4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Cisco ISE Default Authentication Policy
This topic describes the default authentication policy on Cisco Identity Services Engine.
Cisco ISE Default Authentication Policy

Three pre-configured rules in the default authentication policy
Rule-based authentication policy is the default type
No tuning necessary for basic access scenarios
- --· . -·~...-
----·
----..... --- ·--
..
~-------·-··--
~-, 1 ' \ - ... - -
...
. .... , _,---- -- ""1
-- ......____._____
• -... ·-- .-.. -- --- ..
._--- ~ ·
•
•
-- -·
--- --- --- -· ~
• --·..- -- --- -- --
•
-·
....... _.
Authentication requests are processed immediately after an endpoint anempts to access the network through
the NAD. The Cisco ISE evaluates the access path over which the endpoint enters the network and checks
the credentials that are stored in the identity source.
The Cisco ISE has an authentication policy that gathers multiple checks into a centralized decision point.
The authentication policy contains criteria that define bow to validate the user identity and through wbich
NADs the user is allowed to enter. The validation of the user identity is performed against an identity
source. The identity source can be the internal database, an external server, or a sequence of multiple
sources.
Authentication policies define the protocol1i that Cisco IS£ should use to communicate with the network
devices, and the identity sources that it should use for authentication. A policy is a set of conditions and a
result.
Two types of authentication policies are available in the Cisco ISB: simple and rule-based authentication.
Simple authentication does not use any conditions and is not commonly used. Rule·based authentication
consists of a set of rules, and each ruJe can deftne conditions and resulting actions. Rule--based
authentication is the default and more commonly used option.
The ISE comes ·with three authentication rules preconfigured by default. You do not need to rune the policy
for most basic access scenarios.

Switch Configuration Procedure
'J'bis topic describes the switch configuration procedure.
Switch Configuration Procedure

1. Configure global AAA parameters
2. Configure RADIUS peering
3. Configure 802.1X:
A. Enabla 802. 1X globally
B. COtrfigure 802.1X on potts
authentication open tn monitor/lOw impact modes
Port ACL in low impact mode
Optional MAS
Optional tuning
To deploy 802.1X on wired switches, perfonn these steps:

I. Configure the global AAA parameters.
2. Configure RADfUS association.
3. Configure 802.1X. The 802. I X settings on the switcb consist of <he command that globally enables
800.1X on the device, and the configuration of indivfdual ports.
Configure Global AAA Parameters
This topic describes how to configure the global AAA settings.
Configure Global MA Parameters

,.,.........,...........,.
~ . . AAA ........... Iillt=tlli
..... lf .... .,..,IIW~frlloWtle ..
.. II
-
'
''
l
............."'u• •t.a .. •n• •t•11h ,_....,.. ...-.....

..- . ,.,._, , . .,,. . . .,~,- •4• •1t. , ,. ,.. rA4l1111 ~· ..---·--· I
•~AW~oC--fto.wl
_......,_11:·~
. . . . . . . .. , , ~ ~~- . ., ....l , · ~·,-·~ ···~ .~ ...
. ...... _.
Before you can configure AAA authentication. authorization and accounting, AAA must be globally
enabled on the switch. Use the aaa new..model command in global configuration mode to do this.
AAA servers can be logically organized into AAA :server groups. Group radius is an AAA server group that
is defined by default and includes all of the RADIUS servers fiat are configured on the switch. It is very
conunon to simply reference the group radius in AAA configuration commands.
Use the aaa authentic-ation dotlx default group radius command in global configuration mode to define
the authentication method used by default on switclhpons that are configured for 802.1X access.
Configure the defauJt AAA authorization method wed for network access by issuing me aaa authorization
network default group radius command in global. configuration mode. This command is used to configure
the switch to facilitate RADIUS authorization for all network~related service requests. such as 802.1X per·
user ACLs or VLAN assignment.
Configure default AAA accounting method used with &02. 1X by issuing the aaa accounting dotlx default
s tart--stop group radius command in global configuration mode. This command will cause the switch to
send RADlUS accounting messages when sessions start and when sessions terminate.
Note that all of the commands shown in this scenarjo reference the method named default. The method
named default indicates the method that will be used if no specific method is configured on an interface or
line or service. ln more complex scenarios it may be required to configure multiple named methods and
reference the named method in appropriate sections of the configuration.

Configure RADIUS Peering
'lllis topic describes bow to configure the RADIUS peering.
Configure RADIUS Peering

l~:==::::::: .J ~~,...... .........
:. u41i•• eM...·J•~rt- vt.!too
..... .................
_ ....... ca..-... - -
'rtldUo•·M..-v.f e tU.._,\M ' ..., .... J.. .I.•• . .\1111

r-allhi•·Mrv•r au''"'"'" 1 ,.,.l""·&•·-••·r""t 1-
n •dJu·-no•r eu.rU..t<t 2$ -• · r~u t.IO.;O:I..S.
r-aclJu• •aano•.- ......,.-c,.it•ria t-~ J-fl tn . . J
r acl.iu•·-I'VN" ._..., 10 . 1.0 , ) , 2-0 • e tlo.,..rt ttl:-~ 1 • 1-J
o:adho• •-ryar - . ... 10 , 10 , ).~1 • • U....,..wt 1Ul
rectlu • ·-ry•~r waa --.t _..u"9
UlJ- a.ccl"•.,...-i
--......
----·
~---
__.,
_,_ -- --
r...tiu • • -rYa r- vaa .....t • u U..cat.ic.a.t.ioa
o..--..a.e--
... '.....'(.. ...

I ......~JICI'liJ.......
I
'
ip Mvi- t r .ad<t."'9 ~ -~- ..._...._
I ~-
I£.............. 1SE•1IJO:t.
I._...'*'
te• t ..,.. oz~ r....u.u tu e.u- ~ ---1 ---fUOUS-., I
Configure the RADIUS server using the radills·sen·e.r bost <host> autb~po rt <port> acc.f.·port <port>
command in global configuration mode. By default, the ports that are used for the Cisco Identity Services
Engine should be 1812 for authentication and authorization and 18 13 for accounting..
Config:ure the interface fro m which all RADfUS traffic will be sourced by issuing the ip radius source..
inte-rfac~ <interface> command in global configuration mode. This command will cause all RADfUS
traffic 10 be sourced from the same interface. If the switch consistently uses lhe same source interface, then
lhe RADIUS can use the traffic's source W address to eas:ily the switch as the source. The fp address of the
source interface is the Jll address that should be configured for the NAD in JSE.
Configure the RADIUS server dead criteria by issuing the radius--server dead·c.riteria command in global
configuration mode. This conunand ha.~ two primary components:
• Time: Set the time in seconds during which the switch does not need to get a valid response from the
Rl\DlUS server. The range is from I to 120 seconds..
Tr:ies: Set the number of times that the switch does not get a valid response fro m the RADl US server
before the server is considered unavailable. The rangte is from I to 100.
Not all RADIUS attribute.~ are used in all RADfUS servers in all scenarios. Tbere are some attribute.~ that
ISE uses in an 802.1X environment that are not enabled on the switch by default Configure these RADIUS
attributes using the following commands in global configuration mode:
radius--ser\'er attribute 6 on ·for~Jogin·autb: This C·ommand sends the Service Type attribute in the
authentication requests. ISE uses tlle service~cype to help distinguish betv.reen 802.1X supplicant login
request.~ and MAC Authentication Bypass requests.
radius--sen·er attribute 8 includf>in·access·req: This command causes the switch to include the
endpoint IP address in the authentication request. Tbe IP address is carried in the Framed~ ll'~Address
RADIUS field.
1-6& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
.. radius-se.rve.r attribute 2S acc.ess..request include: This command causes the switch to include 1he
RADIUS Class attribute in the authentication request. This specifies the group of which the user ~sa
member.
.. radius·serve.r vsa send acc.ounting: This command configures the switch to include vendor~specific
attributes in accounting updates.
.. radius·serve.r vsa send authentication: This command configures the switch to include vendor·
specific attributes in authentication requests.
The ip device traddng command enables the switch to keep a table of source 11' addresses utilizing the
switchports. The lP addresses will be included in RADIUS authentication requests as long as RAOlUS
attribute 6 is enabled.

Configure Switch for 802.1X Monitor Mode
'J'bis topic describes bow to configure the switch for 802.1X monitor mode.
Configure Switch for 802.1X Monitor Mode

802.1X Monitor mode uses open mode without a pre--auth ACL
I~
Before 802. 1X can function on any panicular switch port, it must be globaUy enabled on the switch. Tbis is
done in global configuration mode using the dotlx system..auth--control configuration command.
Enter interface configuration mode using tlle interface command to configure pon specific settings.
4
Config.'W'e the switch port for the conect VLANs by issuing s\\o;tc.bport commands.
Configure the switch to allow network traffic to the Jocatny assigned VLAN before 802.1X authentication
has taken place by issuing the authentic.ation open command in interface configuration mode. By default,
802. 1X drops all non-EAPOL traffic before a successful 802.1X (or MAS) authentication or web
author~zation initialization. This mode is referred to as closed mode. The authentic.ation open command
enables open~access mode, which allows traffic (in both the data and voice VLANs). before successful
authentication. If that traffic is not restricted by an ACL locally assigned to the port. it is considered
monhor mode. If a locally assigned ACL is in place, limiting the craffic that is allowed before
authentication, then it is conside~ low impact mode.
You may enable MAS on tl1e desired port by issuing the mab command in interface configuration mode.
Configure the authentication priority using the authentication priority command in interface configuration
mode. It is; best practice to prefer the stronger authentication method (802. 1X), as depicted above.
You may configure the authentication order for the pon hy issuing the authentication order command in
interface configuration mode. It is usually the best practice to maintain the order of 802.1X followed by
MAS, as depicted above. But in unusual environments which predominantly use MAB, a performance
improv ement may be seen if the order is reversed.
1.00 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
'fhe port starts in the unauthorized state. While the port is in this state, the port that is not configured as a
voice VLAN port disallows all ingress and egress traffic except for 802.1X, Cisco Discovery Protocol, and
STP packets. When a client is successfully authenticated, the port changes to the authorized state and allows
aU traffic for the client to flow nomtally. lf the port· is configured as a voice VLAN port, the port allows
VofP traffic and 802.1X protocol packets before the client is successfully authenticated. If a client that does
not support 802.1X connects to an unauthorized 802.1X port, the switch requests the identity of the client.
ln this situation. if the client does not respond to the request, the port remains in the unauthorized state, and
the client is not granted access to the network.
ln contrast, when an 802. 1X-enabled client connects to a port that is not running the 802.1 X standard, the
client initiates the authentication process by sending the £..\POL start frame. When no respon-se is received,
the client repeats the request for a fixed number of times. Because no response is received, the client begins
sending frames as if the port was in the authorized state. You control the port authorization state by using
the dot h port-control interface configuration command and these keywords:
• force--authorized: This keyword djsables 802. 1X authentication and causes the port to change to the
authorized state without any authentication exchange required. Tbe port sends and receives nonnal
traffic without 802. 1X~based authentication of the client. This setting is the default setting.
• force--unauthorized: This keyword causes the port to remain in the unauthorized slate, and ignore all
attempts by the eliem to authenticate. The switcll cannot provide authentication services to tlle elient
through the pan.
• auto: This keyword enables 802.1X autltentication and causes the port to begin in the unauthorized
state, allowing the processing of EAPOL frames that are sent and received through the port. The
authentication process begins when the link state oftbe pon changes from down to up or when an
EAPOL stan frame is received. The switch requests the identity of the client and begins relaying
authentication messages between the client and the authentication server. Each client that attempts to
access the network is uniquely identified by the switch using the MAC address of the client.
[f the client is successfully authenticated (receives an Accept frame from the authentication server), the port
state changes to authorized, and all frames from the authenticated client are allowed through the port. If the
authentication fails, the port remains in the unauthorized state, but authentication can be retried. lf the
authentication server caMot be reached, the switch can resend the reque."it. lfno response is received from
the server after the specified number of attempts, authentication fails and network access is not granted.
\Vhen a client logs otT, it sends an EAPOL logoff message, causing the switch port to change to the
unauthorized state. The pon will also change to the unauthorized state if the link state of a port changes
from up to down.

Windows Native Supplicant
'J'bis topic describes the 802.1X Windows native supplicant
Windows Native Supplicant

Required service: Wired AutoConfig
Defauh method:
PEAP with MSCHAPv2 as in.n&r methOd
Mad'lioo Or user authentiCation with WindOws cmdenlials
_... _
--
=----
-
~-
Windows operating systems include a native 802.1X supplicant that is disabled by default. Within an
organization, the service is often enabled by Active Direc1ory group policies. You can enable it manually by
starting the Wired AutoConfig service. The native supplicant supports PEAl, and EAJ>..YTC.
By default the supplicant uses PEAP with EAP-MSCHAPv2 as the inner authentication method, and is
configured for machine or user authentication. If a user is logged in, it will use the user credentials. lf no
user is logged in and it is a member of AD it will use the machine credentials. Machine credentials are
available only after the machine joins the Active Directory. The credentials are provisioned on AD
members by the AD controller at the time ofjoining..
1.02 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Verify Authentication on ISE
This topic describes how to verify authentication on the Cisco Identity Services Engine.
Verify Authentication on ISE

Authentication can be monitored in Operations> Authentications
You can select which details to display:
Add or Remove Columns button
---- ___
Most options are disabled in this: screenshOt
..,._
- 0"",.._
. . - . ...; • ·-- .
The Cisco ISE dashboard provides a summary of ahl authentications that take place in your network in the
Operations> AuthenticAtion menu. The informati on displays also £he authentication method. session ID
and other details. You can select which fields are displayed on this page through the Add or Remove
Columns button. Tlli.s screenshot displays only a few of the fields to improve !he readability.
Verify Authentication on ISE (Cont.)

You can display:
·--·
--
Session start and update time
--·-
e--..
IP address (requires IP !racking)
Selectable CoA action
Session iD
·-··----
••
.. --·
e--·
NAS name. IP address and port
--
--·--
·----
Auth method and prolocol
Endpoint profile
a---
___
·-·-
Posture status
Traffic statistics ·-
.... _
----
"-
- -..
--
When you click the Add or Remove Columns button you will be able to select various details about the
access attempt. You need to to save the selection to be effective.
Verify Authentication on Switch
This topic describes how to verify the authentication status on the switch.
Verify Authentication on Switch

Session 10 identifies the same session on the switch and ISE.
Authentication status and authorization status are provided.
L3·S~• t ho- auttAftelt•~1oft ••~• to~• 1ne.rt•c. g1gab1eZth• rn• e 0/ 1
I!'ltllr!~ee: C:19.tMt..!t.!Uttneo:0/ 1
~c Add~$o: a~36.9fla.3bbl
tP A.ddn~ .u: Cr.kr:ocwr.
I!.!Uil'•I<4M: ~jL"I
St,1tllll: lol!thJ: S'.ICCQU
OONU.n: tlA'IA
~~:~ty Poliey: S~~uld Sec~re
S.eur~ty St.ttllll: on,Qcu~
<:opor !lott :noao:t : ttl'lglo-1lo:~ t
()per -eontrol d!.r: hoth

A~,:tboc-ueday: Autbe..-.<:ic;ouoo Set'-·ec
v:11n Poitc:y: ~1/A
S.Saion ~iftQCUt: ~ /A
tdl o: tine-out: '$/A

coown ~don ;o: rOi,<ioiA.o'">"'t"tlft""'Oll"O"'"'"'f"ili!llli"""""
'J
.\cet Sustor. :o: Ox'OOQOG!I44
l!.tr..<!.:o: OltO:Cl~OtP'7
ftJ;J~ru:lhle net1tod11 lbt:
Mo~)\:~;~'1;.~
i!Z?l~
ln addition to viewing them on the Cisco Identity Services Engine, you may monitor the authentication
resuhs on the iN ADs. The ourput of the show authentic-ation session interface command provides very
detailed specifications of authentication and authorization status. It includes the ll(iemame of the
autl1enticated user, a(i well a~ the authentication status, operational status and tlle authorization policies that
have been applied. Tbe common session lD is a uni:que identifier which is used as a key field to keep t he
representation of the session synchronized between ISE and the switch. Tbe common session ID can be
very useful when troubleshooting 802.1X environments. Tbe session lD can be viewed. using add.ition:al
conunands, such as the show authentication interface command.

Summary
Summary
Cisco ISE configuration is based on policies.
802.1X authenticators are defined as network access devices in the
ISE
Cisco ISE rule-based authentication policy consists by default of three
pre-defined rules.
Cisco ISE can authenticate the users against the local or an external
database.
To configure IEEE 802.1X authentication on a switch, configure a
RADIUS association between the $Witch and the AAA server. Then
enable AAA and use RADIUS for network AAA. Enable 802.1X globally
on a switch and enable 802.1X port control on user switch ports.
Module Summary
This topic summarizes the key points that were discussed in this module.
Module Summary
Identity services enable a range of security features in the network
access layer.
Cisco Identity Services Engine is a next..generation identity and access
control policy platform.
602. 1X is an IEEE standard for media ·level access control.
602.1X offers the capabilrty to apply traffic policy based on user or
machine identity.
602.1X uses the Extensible Authentication Protocol (EAP) to
authenticate users who wish to access the network.
Bootstrapping the authentication system requires basic configuration of
the ISE, network access device, and a 802.1X supplicant.
0,.,.__.._
References
f or additional infonnation refer to this resource:
• Cisco Identity Services Engine User Guide
Module Self-Check
Questions
Use the questions here to review what you learned in this module. 11le correct answers and solutions are
found in the Module Self-Check Answer Key.
I. Which two are components of the Cisco secure access solution? (Choose ~·o .) (Source: Identity
Services)
A. stateful firewalllng
B. posture service
C. application layer gateways
0. TLS encryption
E. SGA
2. Which two functions leverage CoA? (Choose two.) (Source: Identity Services)
A. RADIUS
B. authentication
C. posture
D. accounting
E. profiling
3. What is a benefit ofTACACS+ over RADIUS? (Source: Identity Services)

A. Developed by Cisco
ll. Standards-based protocol
C. Granular authorization allows command authorization
D. Granular authorization allows CoA
E. Granular accounting allows recording of session termination
4. Which 802.1X host mode distinguishes between multiple authenticated 802.1X, MAll, or web
authorization clients on the data VLAl'<? (Source: 802.1X and EAl')
A. Single Host Mode
B. Multiple Authentication Mode
C. Multiple Domain Authentication Mode
D. Multiple Host Mode
5. \Vhich two EAP methods use certificate-based server-side authentication? (Source: 802. 1X and
EAI')
A. PEAP
B. &\P-MOS
C. EAP-TLS
D. &\P-MSCHAPv2
E. EAP-GTC
6. Which EAl' method can return the EAP Chaining Result of"User and Machine beth succeeded"?
(Source: 802.1X and EAP)
A. &\P-FASTv l
B. &\P-FASTv2
C. &\P-TLS
D. EAP-PEAI'
E. EAP Chaining method
7. Which 802. 1X deployment mode(s) do you configwre using the authentication open command?
(Source: Identity System Quick Start)
A. Open
B. Low-impact
C. Monitor
D. Monitor and low-impact
E. Low-impact and closed
8. \Vhich two commands do you need to enable the 802.1X supplicant on a s\vitcb? (Source: Identity
System Quick Start)
A. aaa authentication dot Ix
B. aaa authentication network
C. aaa authorization dot 1x
D. aaa authorization network
E. aaa authorization exec
1-70 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
9. Which two statements describe PEAl' (EAP-MSCHAJ'v2)? (Source: Identity System Quick Start)
A. Rarely deployed
B. Default method in the AnyConnect supplicant
C. Use of certificate(s)
D. Engineered by CL<co
E. Inner EAP-MSCHAPv2 exchange protected by TLS

Answer Key
I. B, E
2. C, E
3. c
4. B
5. A,C
6. B
7. D
8. A,D
9. C, E
Module 21
Cisco ISE Fundamentals

The Cisco Identity Services Engine is a next·generation identity and access control policy platfonn that
enables enterprises to enforce compliance, enhance infrastructure security. and streamline their service
operations. The unique architecture of Cisco lSE atlows enterprises to gather real4ime contextual
information from networks, users, and devices. This module introduces the key components of the Cisco
LSE architecture and explains the its function in the network access oontrol solution.
Upon completing <his module, you will be able to:
• Describe the key characteristics of Cisco ISE
• Enroll the Cisco JSE in the PKJ
• l mplement Cisco JSE internal authentication
• Implement Cisco ISE external authentication
·0 2014 asco Sy&ems, lnc.
Lesson 11
Cisco ISE Overview

Overview
This lesson provides an overview of the Cisco Identity Services Engine platfonn. Cisco ISE is a key
component of the Cisco secure access architecture. Tbe various concepts that are associated with the Cisco
ISE deployment include nodes, personas, and roles. The Cisco JSE solution supports distributed
deployments, where the functions are split among separate nodes.
Upon completing this lesson, you will be able to meet the following objectives:
• IdentifY !he Cisco JSE technology areas
• List the access control operational components
• Describe the ISE as a policy platform
• Describe the Cisco !SE lllgh-level flow
.. Describe Cisco IS£ nodes, personas, and roles
• Describe the Cisco !SE deployment examples
Cis,co ISE Technologies
Tbis topic describes the Cisco secure access technology areas.
Cisco ISE Technologies
·-·------ · Guest-
_.,._
Net-'< ld..,.,.y ond
Enforcement
• ~lca«ioff (8:12. uc. t.WI,
~
---
h-
--....... .. _
,_ ......,... __
~ .............._-.
--__ ·-
• Aulhortullioft £,. .
(\1\.Att, ~ SGA. SOT,
••• ,
SGA.Cl. ~ ..... """'-')
,_..
... _
.___ _,_
....,_
·__
_-----·
·--"' __
,...,""'
·- .. ·-· --...
___..............
~- ..
'J'he Cisco secure access solution i..~; deployed in enterprise environments \\1th various security technologies.
Tbe Cisco Identity Services Engine offers, among others, these services:
Authentication @Ell 802.1X, MAB.l~ebAutb)
Authorization (VLAN, dACL, §XP or SGt. SGACL, identity-based firewall)
Tbe gu:est access fearure enables rich options for provisioning and profiling of guest accounts.
'J1le endpoint profiling service dynamically identifies endpoint devices. It manages these devices
intelligently, based on predefined security policies. The profiling service allows you to identify, manage,
and inventory all of the fP-enabled devices accessing the network. The posture function verifies endpoint
compli.ance with the governing security policy. Hop~by·h.op encryption is accomplished via MACsec.
Cisco Security Group Access establishes clouds of trusted networks to build secure networks. Instead of
relying on fP-ba1ied configuration, access authorization is based on context, including user identity.

Cisco ISE Operational Components
This topic identifies the Cisco Identity Services Engine operational components.
Access Control Operational Components
....... _.
The key operational components of the access control work together to provide a comprehensive solulrion.
The central decision-making platfonn, the Cisco Identity Services Engine utili2es standards~based RJ)...Q!.~~
for authentication and authorization functions. Authentication processes are carried out from the endpoints
through the W,.Qs to Cisco JSE using802.JX, MAB, or WebAuth. 802.1X is a standards-based network
access conrrol that works at Layer 2. MAS is used as an exception to authentication to allow devices dlat do
oot have an 802.1X supplicant (such as a security camera or a printer) £0 access the network based on their
MAC address. WebAuth aiJO\\'S users to log in via standard web browsers and is generaUy deployed for
guest logins or to support endpoints that lack an 802.1X supplicant
User credentials are passed from the NAD to Cisco lSE via a RADfUS Access ~ Request message. Cisco ISE
generally consults an external identity source, such as Microsoft Active Directory or LDAP, for credential
verification and for user and group attributes. For guest users who do not have accounts within the external
identity sources. Cisco ISB provides guest service features that allow for the management of the life cycle
of guest accounts.
After the user identity is verified and its account attributes are processed. an appropriate authorization
profile can be applied to its session. Cisco IS£ conveys the associated authorization policy to the NAD in a
RADIUS Access-Accepr reply.
The Cisco JSE posture service allows characteristics of the physical endpoint security posture to be
interrogated. f'or example. operating system service packs and antivirus software status can be examined.
The Cisco ISE profiler service can use several probe methodologies to collect many endpoint
characteristics. Tbese characteristics are then used co categorize the device into classification groups such as
Apple devices or iPhone or iPad.
Profile and posture infomtation can be used to determine the authorization policy. Utilization of this
information generally relies on the CoA mechanism. CoA is a standards-based method that allows the
RADIUS server to send authorization updates to the RADIUS client (the NAD) after the initial
authentication and authorization exchange.

Administration and monitoring of all Cisco lSE compone.nts, even when the deployment is distributed, is
accomplished via a web browser connection to a single centralized interfaoe.
Cisco ISE as Policy Platform
This topic identifies the policy.centric Cisco Identity Services Engine architecture.
Cisco ISE as Policy Platfonn

Multiple services in a single unified platform:
AAA
Posture
Profiler
Oovic:e onbOarding
Guest management
Centralized policy administration
Centralized monitoring:
CGnltalized tracking of users and devicos
Centralized detailed auditing
H istorical reporting
Real-lime reporting
....... _.
A policy-based networking approach helps IT staff to accomplish business goals. For example, they may
give authorized users access to sensitive data when they are in certain locations or using specific devices,
while restricting access from other locations or from other devices. f·or a more precise example, a policy
might pennit a finance manager to access data from anywhere using a company laptop, but restrict access to
a specific resource from a personal device outside the office.
A policy is broadJy defmed as "a definite course or method of action, to guide and detennine both present
and future decisions:·
• AIJows enterprises to authenticate and authorize users and endpoints through wired, wireless. and .VP_!;i
networks.
• Provides complete guest life-cycle management services.
• 'Enables the ability to discover, classify, and as:sociate identity for all endpoints connecting to the
network.
• Performs de\•ice onboarding, whlch is used to install required client software on the user endpoints.
Examples include supplicants, ~£ agents, and other packages.
• Enforces security poHcies by blocking, isolating. and repairing noncompliant machines in a quarantine
area without needing administrator attention.
• Offers a built-in monitoring. reporting. and D'Oubleshooting console for belpdesk operators and
administrators.

Cis.co ISE High-Level Flow
'J'bis topic present~ the bigh~level flow in Cisco Identity Services Engine processing.
Cisco ISE High-Level Flow

Endpoint ...,... attempt
I
Authontu:i\IJOn
- -
I eoo~ro~~ec~ endpO!n!- I
Tbe diagram depicts the general flow of Cisco ISE policy decisions:
1. The endpoint attempts network access via a NAD.
2. Using 802.1X, MAB, or WebAuth, the authentication process ensues.
3. Based on the characteristics of the authentication process, an authorization policy is selected and
communicated to the NAD, leading to controlled endpoint access.
4. If posturing services are deployed, the authorization profile that is selected immediately after
authentication does not normally provide full network access. Instead, it is normally restricted to allow
co·nnectivity only to the Ci..(iCO ISE components that are required for posture assessment and porentiaiJy
to remediation servers. Posture assessment can then begin. If the endpoint is determined to be
co.mpliant with the organization security policy, then a more pennissive authorization policy can be
assigned to the session. To convey the change in policy to the NAD, a CoA message is senL
5. Similarly, profiler services also make use ofCoA. If .a profiler is deployed, and a new endpoint
co.nnects for the fits[ time, tlle authorizarjon profile will be one that is associated with unknown
devices. After profiling is completed and the endpoint classification is identified, a new authorization
policy can be assigned to the session. The new authorization policy is communicated to the NAD using
a CoA message.
6. The results ofprofiler probes are stored in the Cisco lSE internal endpoint database. The endpoint
MAC address is lhe key field in lhe database entry and uniquely identifies !he endpoint On subsequent
access attempts from this endpoint, the endpoint classification from the last pro filer update is available
as additional context for the initial authorization assignment decision.
2-8 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Cisco ISE Personas
This topic explains the concepts of Cisco Identity Services Engine nodes, personas, and roles.
Cisco ISE Nodes, Personas, and Roles

Persona 09&ertp tion
Administration Interface flY configuring policies ...

• Polides automatically dlstrtiOied to oltler
oomponenls
Policy ServiCes • Engine tha! makes ~y decisions

• Attribute re-trieval and evaluation
MonilCH'ing Interface tor IOggl'ng and repottlng data

Repon and elann genetatloo
....... _.
A Cisco JSE node is a running installation of the C~sco JSE software. Th.is installation can be on a physical
appliance or on a Y..f!1 within a VMware environment. THe Cisco ISE architecture allows for me separation
of services for scalability. perfomtance and high availability. Cisco ISE has three major collections seTVices
that are organized into personas. These personas are responsible for different functions within the Cisco ISE
architecture. They may be collocated on a single node or distributed across multiple nodes. The three
personas are:
.. Administration persona: This persona is me interface for configuring policies. This persona is dle
concrol center in the Cisco IS£ deployment, and it also controls the licensing and contains the user
interface. The administration persona is also responsible for pushing the configurations out to oth-er
nodes in a distributed deployment Nodes that implement the administration persona are often referred
to as admin nodes.
Policy service persona: This persona is me engine that makes policy decisions. This persona is the
main runtime engine that processes all the network messaging mat pertains to the Cisco CS£
deployment. This massaging includes DHCI', Cisco Discovery Protocol, Netflow, and RADIUS,
among others. Nodes that implement the policy service persona are often referred to as policy service
nodes.
.. Monitoring persona: This persona is the interface for logging and report data. This engine collects all
logs and correlates them. In addition, it is used to generate reports and any alanns for the Cisco IS£
sys£em. Nodes that implement the monitoring persona are often referred to as monitoring nodes.

Cis.co ISE Deployment Examples
'J'bis topic explains the concepts of Cisco ldenticy Services Engine nodes, personas, and roles.
Cisco ISE Deployment Examples
--··--
Four-node dep4oyment e'JCample
·-·-
--
-.-. --·--
·--
ln the figure, the first example shov..-s a single~node deployment The initial state of a Cisco ISE node,
immediately after installation, is standalone mode. In this mode, all three running personas are collocated
on a single Cisco ISE node. A chief limitation of rhis deployment model is a lack of fault tolerance. There
are also scalability limitations because it will support a maximum of2000 endpoints, regardless ofthe
physical hardware that is used to implement the node.
Tbe second example depicts a distributed deployment. It adds fault tolerance and improves scaJability. Note
that distributed deployment introduces the concept of a role. There are two adminisrration personas. One
has the primary role and the other has the secondary role. The same is m1.e for the monitoring persona. To
efficiently spread the workload, the primary roles are implemented on different nodes.
Tbe second example also has improved scalability due to the separation of the policy service persona from
the administration and monitoring nodes. When a node only runs the policy service persona. the maximum
numbe-r of endpoints !bat is supported by that policy servf~ node is dependent on the hardware platform.
Note that there is no concept of primary or secondary role with the policy service persona. Policy service
nodes play the role of RADIUS server to the NADs in the deployment. A particular NAD may be
configured to assign a higher priority to one policy service node over another, but the policy service nodes
themselves are unaware of the perspective of the NAD.
·0 2014 asco Sy&ems.lnc.

Summary
Summary
Cisco ISE provides a platform that unifies AAA, posture, profiler. and
guest management into a cohesive system.
Cisco ISE offers centralized policy administration and centralized
monitoring.
The Cisco ISE architecture utilizes three personas: Administration,
Policy Service, and Monitoring.
Cisco ISE can be deployed on a simpfe standalone node, or in a
distributed fashion that provides fault tolerance and increased
scalability.
. ...... _
C 2014 Clsoo Sys1ems. Inc. Student Guide 2· 11

Lesson 21
Cisco ISE PKI

I?KJ offers a scaJable method to secure networks, reduce management overhead, and simplify the
deployment of network infrastructures. PKJ manages encryption keys and identity infonnation for dle
components of a netv.·ork, which participate in secured communications. Any network, from small business
networks to the core systems of the wortdl.s largest service provider networks, can benefit from the PKJ.
This lesson describes bow to enroll the Cisco Identity Services Engine in the PKl.
.. Describe the server authentication in EAP
• Describe the TLS protection in a Cisco ISE environment
• Describe the X.509v3 certificates
• Describe the use of the server certificate
Describe the validation of the ISE cenificate
• Describe the validation of the ISE signature
• Describe the procedure of enrolling the ISE in PKI
Describe how to import theCA root certificate into the JSE cenificate ston:
.. Describe how to generate a certificate signing request (CSR)
• Describe how to bind the returned certificate to the pending CSR
• Describe how to verifY the ISE enrollment in the I,KJ
Server Authentication in EAP
Tbis topic describes the serverAside authentication in~·
Server Authentication in EAP

Clients need to verify server's authenticity.
Most common server authentication is certificate-based.
Guest users will trust only certificates signed by public !1.A
CAIOG4~ •••••·
··-...
~..... •...·•·. .-··-1?--..... I
·- .. --·
EAP differentiates between rn'O authentication halves: s.e~er and client authentication. ln server
authentication the clients verify the server authenticity. In client authentication the server validates the
client authenticity. While the eli em authentication methods differ significantly among various EAP types,
the server authentication is based on certificates in most of the common and trusted EAl, types.
'J'here are cv.·o cypes of certificates:
Local ce-rtificates: ·nlese credentials are used to identify the Cisco Identity Services Engine server to
otlher entities such as EAP supplicants, external policy servers, or management clients. Local
certificates are also known as identity certificate.~. Along with the local certificate, a private key is
stored in Cisco lS£ to prove its authenticity.
• Certificate authority certificates: These credentials are used co verify remote certificates that are
presented to Cisco IS£. Certificate authority cenificates have a dependency relation that forms a CTL
hierarchy. This hierarchy connects a certificate with its ultimate root CA and verifies the authenticity of
the certificate.
Cisco nSE acts as the EAP server in many secure access w lutions. It requires a certificate that can be
validated by the clients. When you install a new IS£ in the network, it comes with a pre· installed certificate
that by default cannot be verified by the client suppJjcants. To allow a successful certificate validation, a
Certificate Authority is used to sign the JSE certificate. The enrollment of the lSE with theCA involves
severa£steps: theCA root certificate must be installed on the IS£, the lSE must issue a CSR to theCA, the
CA must grant the requested cenificate, and the ISE ceniiicate must be installed on the ISE.
11le supplicant will be able to validate the JSE certificate if it bas theCA root certificate.
·0 2014 asco Sy&ems. lnc.

TLS-Protected Communication
This topic describes .!1..~~protected communication in the Cisco Identity Services Engine environment.
TLS-Protected Communication
TlS protection of tunneled EAP protocols and EAP· TlS
HTIPS.based administrative access and WebAuth
TLS-based node connectivity within ISE deployment
),DAP§
it
-----·'f'lf · I
• @
. ...... _.
The Cisco ISE relies on a PKI to provide secure communication for the following:
.. Client and server authentication for TLS ~ related EAP protocols.
• HTTPS communication between client browser and the Cisco ISE node for administration sessions.
• TLS-based protection of com.municarions ·within a Cisco ISE deployment
• LDAPS

X.509v3 Certificates
'J'bis topic describes the X.509v3 certificates.
X .509v3 Certifi cates
~::
--- -
IR-. -... .-..,.
")tt4S0.6SIOICIICIIXIGD
' ..
---
-4(~
.....
..... .
"""""'·.............,....
t!Qo'~-~.-
.........................
..........-
.,._...,
• • .., .. "' . . .Of:R:R--
~~(I .U.....
-...
~~IQ9tOicMI(I!Irt.,.
U):ll~ ~:c.....
(t~w-lo(uw.A«.H
tJ91;ti~O:.,~-
~(11'-W•l '152loMl'l:u"' ...
A digital certificate contains specific fields that convey the identity infonnation that is associated with the
certificate subject (that is, the entity to which the certificate was issued). The certificate also contains
infonn-ation about the certificate issuer and the issuer signature. The issuer produces the signature by
c-reating a hash of the certificate data and then encrypting the hash with its private key. Other systems
receiving a certificate can verify its authenticity using the public key of the issuer, which they generally get
from tbe issuer's own certificate. To verify a certificate, the receiver decrypts the signature using the public
key of the issuer. This key should be the ha~h of the original certificate data. The receiver then hashes the
data from the certificate that it received. If the hash matches the decrypted signature, then the cenificate
data has been verified. Generally, other considerations are taken into account when validating a certificate,
inctudi.ng the valid from and valid to date.c; that are defined within the certificate.
Tbe public key of the certificate subject is a critical piece of identity infonnation. Other entities can send
private messages to the subject by encrypting data with the public key of the subjecL Because only the
subject has the corresponding private key, only !he subject can read !he message. The (act that only the
subject can decrypt the message can be used for authentication.
For example, a simplified description of the setup of a TLS session follows:
1. The client initiates a connection to the TLS server.
2. The server presents its certificate to the client.
3. The client validates the signature on the certificate.
4. The client generates a session key to use for a shared key encrypted session. ·The client uses the public
ke-y of the server, wbjch is retrieved from t:be validated certificate, to encrypt the session key.
5. The client sends the encrypted session key to the server and requires future traffic to be encrypted. with
the session key.

6. The server uses its private key to decrypt tl1e session key, and uses it to encrypt the rest of the traffic
that is associated with that session.

Use of Server Certificate
'J'bis topic describes the use of the server certificate.
Use of Server Certificate

In PEAP, EAP·GTC, EAP·TLS, PEAP·111.S, and EAP·FAST
Client must have one of these:
CA root certffieato
Explicit trust relation to server certificate
.,. ___
For most SAP methods, Cisco Identity Services Engine needs to have an identity certificate that the clients
will be able to verify. ln l'EAI, and EAP-GTC, clients vel!'ify the server certificate, and dle server
authenticates the clients using other credentials. ln EA.P·'fLS and l'EAP~T LS, the sides verify each other
using certificates.
If certi:ficate.based authentication is used, the client needs to verify the server certificate fltSt. This process
is used. in PEAP, EAI'·GTC, EAP-'fLS, J>EAl' ·TLS, and :EAJ>. fAST. Cisco ISE acts as the server side and
presents its identity certificate to t:he client.
'J'he Cisco lSE identity certificate is either self~signed or bas been issued by a CA. The self·signed
certificate is preinstalled on Cisco lSE and can be refreshed. 'Deploy certificates using theCA to achleve a
secure and scalable solution. If the Cisco ISE identity certificate is setf.signed, the client needs to be
configured to trust it. Tbe client does not have any scalable method to verify self-signed certificates. lftbe
Cisco DSB identity certificate has been issued by a CA, the client needs theCA root certificate to veritY any
identity certificate thar is issued by that CA.
·0 2014 asco Sy&ems,lnc.

First Validation: Verify Server Certificate
This topic describes how the client validates the server certificate.
First Validation: Verify Server Certificate

_ _, , , _ , , ,_ _M"'"'- " " ' " " - " " "'" - "
.._...
ISE cdlc:Me
CA-- --
--- ..j..
-- CA..-..... - ( - )- ( • )
---
"'-
_ _ __
""-
., .......__,.
Jlt:!:r. Ill........
.._,....... ..........
T
Hn!lc. .II 1111,.,._
, .....,_.........
. ...... _.
The clients validate the server authenticity in ~·o fundamental steps: first they verifY the server cenifi.cate
and then they verify the server signature.
\Vhen the Cisco Identity Services Engine sends the client its identity certificate that has been signed by a
CA, the client needs the CA root certificate to veri.fY the ISE certificate. Tbe client extracts the CA public
key from theCA root certificate and uses it to decrypt theCA signature in the ISE certificate. TheCA
signarure in the ISE certificate has been computed by hashing the fSE certificate fields and encrypting the
result \\;th theCA private key. After the client decrypted theCA signature using theCA public key, tl!le
obtained hash, also known as fingerprint or thumbprint, is compared with the hash calculated over the lSE
certificate fields. lfthe fingerprints match, the received JSE certificate is authentic, e.g.. it bas been siped
by theCA with theCA private key.

Second Validation: Verify Server Signature
'J'bis topic describes bow the client validates the server signature.
Second Validation: Verify Server Signature
,__ , -
I
.._
--
---
ln the second fundamental step the client examines the data arriving from the server. l be data, in additional
to transporting the Cisco Identity Services Engine certifi~te, is signed, and the signature is appended to the
payload. The signature is hashed by the IS£ and the hash is encrypted using the IS£ private key. ·n,e client
extracts the IS£ public key from !he already verified ISE certificate and uses it to decrypt the !SE signature.
Tbe resulting hash is compared with a hash of the received data.. If the fmgerprints match, the arriving
traffic ; s aulhentic, e.g. it has been signed by !he ISE with the lSE private key.
2·20 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

PKI Enrollment Procedure
This topic describes the procedure of enrolling the Cisco Identity Services Engine in PKJ.
PKI Enrollment Procedure

1 Import theCA root certificate into the Cisco ISE.
2. Generate a CSR.
3. Export the CSR to the CA.
4. Issue and retum the identity certificate (pefformed on CA).
5. Bind (install) the rerumed certificate to the pending CSR.
CAfiOOIC-*-
~
------ . -----
-
c..J
S. Eopew«CSR
.... El-
-""""
-.. ISE WUkN
• ~
c:J
....... _.
To enroU the Cisco lSE with a PKI, perfom> these steps:
I. lmpon theCA certificate into Cisco JSE. You need to obtain theCA certificate from theCA to install it
on Cisco ISE.
2. Generate a CSR.
3. Export the CSR and provide it to theCA using an appropriate metl>od.
4. 'TheCA administrator must sign and return Cisco lSE identity certificate. ·J1Us step may involve some
additionaJ verification checks that are imposed by theCA on the enrolling systems.
5. Bind (install) the returned certificate to the pending CSR.

Step 1: Import CA Root Certificate
'J'his topic describes bow to import the CA root certificate into the Cisco Identity Services Engine certificate
store.
Step 1: Import CA Root Certificate

Method of obtaining root certificate depends on the vendor
Yau can enable the CA root certificate to:
Validat& supplicant or securo Sys!og certifiCates
.-
Examine additional client certifica:to attribut&s
---
·-- ·--
-- ·--
- - --
- ----
-··-·· - ·
-·- --- - ...
·-
-~-
·---- ---c-- ___
...... _c.w........~....
___ _
___,._====•---..--
_..,- -....g.O..,.-.
----·-·--..-·
.. _._,. ___.... -w
c----·--
------.. -
-- - ======::~
Start tine enrollment procedure by obtaining the root CA certificate from the CA. The details vary depending
on the CA vendor and type, but usually involve retrieving it via HTfP or FTP. 1n a l'Kl, you have to verify
the root certificate authenticity over an out-of-band channel. This verification mitigates the risk of accepting
a spoofed certificate from an impostor CA.
Import the root certificate into the Cisco ISE certificate store, in the Administration> System>
Certific.ates > CertificAte Store menu by clicking the Import button.
Note that there is a self·signed certificate that is provisioned during the Cisco lSE installation process. This
certificate will be used by default, but its usage does not scale welL You could set up a multinode
deployment without a CA. In that case, use the self~signed certificates that are installed on each Cisco ISC
node during the installation process. You need to copy the self-signed certificate onto other nodes. This
process increases the administralive burden each lime yo\l need 10 add a new node or change the curren1
deploy.ment. Tbere are similar complexities that are associated with distributing certificates to endpoints. (t
is recommended to enroll Cisco ISE with an appropriate PKI.
Tbe CA root certificate is automatically enabled for securing LOAP sessions to an external LDAP server. In!
many cases, you will use certificates to authenticate clients. For that reason, you need to enable the root
certificate for client authentication or secure Syslog services by checking the appropriate check box and
optionally allow it to be used for certificate extensions. C.ertificate extensions allow you to retrieve user
certificate information from external user databases and validate additional certificate attributes.
2: 22
4 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems.lnc.
Step 2: Generate CSR
This topic describes how to generate a CSR.
Step 2: Generate CSR

CSR:
Contains the Cisco ISE identity information and public key
Is saved as file and submitted to theCA
--- --· -·- --

·- ·--
---- .-
·--
- ·---- ..- ·
......- ---
--
·--
·--
·--
·---
·-- -----
• +-• ..
-·-
...
o- =:!:::!"-
IC
....... _.
To obtain an identity certificate, the Cisco Identity Services Engine needs to generate a CSR. A CSR
contains t:he Cisco IS£ identity information and public key and is generated through the Administration>
Syste.m > Certificates> Local Ce.rtificates > Add> Generate CSR menu.
Step 2: Generate CSR (Cont.)

Certificate subjed must at least contain common name or FQDN
SAN allow for multiple subje<:t names
---·--
:~-
--- ·--
-- ·---
-·-
...---
-- -·----
.. --
Subject name or SAN must be resolvable via DNS
---
·-
·-
·-- ......-
-~
_._ "5~~~================::JI •
·-·-..-
'":_ l£0----.t
-
·--~s··
--
·-toO.,.
c----·

Tbe certificate subjec[ of the generated CSR must at least contain a common name or a FQDN. You can
al<o specify SANs, which allow the mapping of multiple subject names to the same public/private key pair.
Cisco nSE supports key lengths of 1024, 2048, or 4096 bits. The key length affects the signature strength. A
key length greater than 2048 will currently not allow Ci.o;co lP phones to authenticate using an EAP method,
becauoe their maximum key length is 2048.
The hash algorithm options include the methods !)HA· l and SHA-256.
Step 5: Bind Certificate to Pending CSR
This topic describes how to bind the returned certificate to the pending CSR.
Step 5: Bind Certificate to Pending CSR

At theCA:
AdminiStrator &uos the identity certfficato
Vendor dependent, not shown h ere
Bind CA signed certificate:
Installs the return&d CA-sign&d certificate
AsSOCiates the identity certificate with the pending CSR
-- - · ...~ -~
- ~~
-
-----
llli-
-·-
·--
-
-·- ---
- · - - .,., _ _ _ _ - - -
·--
·--
·- tr:"--
-----
.........
I
......--
+-•
·----
~ X
·-- ~
....... _.
\Vhen you submit the CSR to theCA and obtain an identity certificate from theCA, you need to install the
CA~approved and CA-signed identity certificate on the Cisco Identity Services Engine. Install the certificate
using the Bind CA Certificate operation, which is a·vailable in the Administration> System> CertificAtes
> Local Certificates> Add> Bind CA Certificate menu. The binding associates the returned CA*signed
certificate with the pending CSR.
Step 5: Bind Certificate to CSR (Cont.)

Wildcard certificates:
Apply for a range of hosts
Example: entire subdomain r .seo.Jre·x.local}
... - ..... -
Protocol options: client EAP sessions. HTTPS management
--- - --
-
--·
..... -~ .- _, . - ·
____..,_-·- -- .._.
11!*!"-~--.. -.._ ·- - s--~ ~-
• --
-
.--.~----"·
·--
~...-... Clor'Mt-
·---
·-- ---
c.---~-----·
-----·--"*---·
--
g o _... _ _ _........_ _

To perform the bind operation, you need to navigate to tbe identity cenificate file. You have several options
that define the use of the identity certificate:
Enable the use of this identity cenificate for certificate extensions that validate certain certificate
attributes using an external user database.
Enable the use of wildcard certificates that can apply to a range of hostnarues, for example an entire
subdomain
Enable the certificate use for EAJ' authentication of client network access.
• Enable the identity certificate to secure the HTTPS..OOsed administrative access to the Cisco JSE.
Click Submit to install cbe identity certificate on the system. The ISE application service will restart and
you wi ll be logged out of the .QUI.
2: 26
4 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Verify PKI Enrollment
This topic describes how to verify the Cisco ldentity Services Engine enrollment in lhe PKJ.
Verify PKI Enrollment

Verification methods:
View certificate in ISE GUI
Examine certificate chain in HTTI?S trust
Observe if supplicants proceed with client-side authentication:
S~rver-sid~ authentication pertorrn&d fir'$t
Exchange stops if S$rvGr oortitlcata rejected
·-··---
-- ·-- •
....... _.
You can verify a successful enrollment of the lSE in PKJ using three methods. You can view the ISE
identity certificate rhrough the ISE GUI, in the Administration > System> CertificAtes> Certificate
Store menu. You can connect via HTfPS to the lSE and verifY the crust relationship. as shown in the ·figure
above. You can also observe EAP authentications. Since server authentication is al\\<ays performed before
client authentication, lhe supplicants must successfully have validated the IS£ cenificate before you can see
any access attempts in the IS£ GUI.

Summary
Summary
The ISE relies on a PKJ to provide security for client EAP sessions,
HTIPS management, TLS protection o·f communications within a
Cisco ISE deploymenL and LDAPS.
Digital certificates contain convey the identity information associated
w ith the certificate subject.
Guest users will trust certificates signed by a public CA.
The CSR contains the Cisco ISE identity information and public key.
Bind operation associates the returned CA·signed certificate with the
pending CSR.
2·2& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Lesson 31
Cisco ISE Authentication

Cisco Identity Services £ngine can authenticate the users and endpoints against tlle internal database or
against external identity sources. The internal database is often used in a simple deploymenc without any
external servers.
Authentication can be configured on the Cisco lSE as a simple or rule-based authentication policy. Th.is
lesson explains the difference between the two types of policies and explains how to configure
authentication.
• Describe the authentication on Cisco Identity Services Engine
• Describe the policy elements in Cisco JSE
• Describe the aurhentication policy example in Cisco ISE
Describe the rule·based authentication on the Cisco IS£
• Describe the authentication conditions
• Describe how to implement rule~based authentication on the Cisco lSE
Describe how to configure simple authentication conditions
.. Describe how to create or rune compound conditions
.. Describe how to define the allowed protocols
.. Describe how to rune or create authentication roles
.. Describe how to rune the defauh authentication rule
.. Describe the Cisco Network Aocess Manager
.. Describe the networks and network groups in the Cisco Ne[Work Access Manager
.. Describe the network settings in the Cisco Network Aocess Manager
Cis.co ISE Authentication
Tbis topic describes the authentication on Cisco Identity Services Engine.
Cisco ISE Authentication
r-·····-············--·----·····----··j
Authentication POliCy
I <S>-11
I
---
--- 6
-'7i
..
Aull>oma.... P.....
:1
_. ,
[~~~~~~~c~•~-~~:1~~~·~--~~~~~r---~--~
~ 11
=-. -=11:.. "=
--
11=- -
IEJ BII§J ~1 11 .::.. 11 -11 -11
L........~~?!~!...ik:-1'1 \ ' " L - :StMoes j POWte
·- .. ·-·
Authentication requests are processed immediately after an endpoint attempts to access the network through
a NAD. The Cisco ISE evaluates the access path over which me endpoint enters the network and checks the
credentials that are stored in the identity source.
'J1le Cisco lSE has an authentication policy that gathers multiple checks into a centralized decision point.
11le authentication policy contains criteria that define how to validate the user identity and through which
NADs the user is allowed to enter. The validation of the user identity is performed against an identity
source. The identity source can be the internal database, an external server, or a sequence of multiple
sources.
Authentication poticie." define the protocols that Cisco ISE should use to communicate with the network
devices, and the identity sources tllat it should use for authentication. A policy is a set of conditions and a
result.
A policy condition consists of an operand (attribute), an operator (equal ro, not equal to, greater than, etc.),
and a v alue. Compound conditions are made up of one or more simple conditions that are connected by the
AND or OR operator. At run time, the Cisco ISE evaluates d>e policy condition and then applies the result
that you have defined based on whether rbe policy evaluation returns a true or a false value.
You can configure two cypes of authentication policies on the Cisco ISE: simple and rule--based
authentication. Simple authenrication does not use any conditions, and is not commonly deployed. Rule-
based authentication consist.~ of a set of rules, and each rule can defi ne conditions and resulting actions.
'J'his Jesson discusses the more common rule-based authentication.
2..3() lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Policy Elements in Cisco ISE
This topic describes the policy elements in Cisco Identity Services Engine.
Policy Elements in Cisco ISE

ISE policies: Authentication, Autl'lorization, Profiling, Posture. Client
Provisioni ng ,~
Policies are built based on policy etements:
0 ictiOn.atiOS
Conditions
Results
___
Iloilo) • - ...!.._
t,., - .....
A#llltN ........ 0 11 I llflMOOOI
..~·-·
,._ -
IF [ ~ J fHEN
........
Aum.IIO:.I• -..-· ~.,..,,..,.,.
......,_ ..;.---
-----·-
._ ,_
--
~~*"'~
......
l ~tf
.._
-·
....... _.
The ISE is a policy centric platform. Its logic centers on several policies: authentication, authorization.
4
profiling, posture, client provisioning, and Security Group Access. Tbe policies are generally built of
conditional statements: if a oondition is met then a result will be applied. The conditions and results differ
based on the policy type. The results in the authenti:cation policy will define the allowed authentication
protocols and the authentication database. The results in lhe authorization policy will specifY the
authorization profile to restrict the client privileges. The results in the profiling policy wiU classify an
endpoint to an endpoint identity group. The results in the posrure policy will check the security smrus ·o f an
endpoint. Tbe result~ in the client provisioning po11cy will specify an agent to be installed on the endpoint.
The results in the SGA policy will classify and filter traffic.
Policies use policy elements as building blocks.. ISE defines three types of policy elements: dictionaries,
conditions and results. Dictionaries specify attributes that are available for use within conditions.
Conditions specify a set of requirements that indicate a particular context. Results define the actions that
[SE will take when d>e conditions o( a particular policy are meL

Cis-co ISE Authentication Policy Example
'J'bis topic describes the policy e lements in Cisco Identity Services Engine.
..___ .. _...,,..
ISE Authentication Policy Example
,_
-
-·-. ,. - •
Poitcv
~
·- ---~-
-·
--
IRHUit
-:- - --
~F
-- -
•. --- I
~ a---.·
."
,. - -· ---- ~·i
·-~
F
~
- . i.::- ::
•
--- ----
• ,
'J'be screen clippings displayed here show an example of h ow the policy elements (dictionaries, conditions
and results) are assembled together to define polic ies. Th~s policy and these policy elements are among
those that are predeftned in lSE and are used by default after IS£ installation. The authentication policy
named MAS is shown. This policy references cv.·o conditions: Wired_'MAB and Wireless_MAB. 'The
Wired_ MAB condition is also shown. It uses two vatues defined in the RADfUS dictionary. 'The RADIUS
dictionary is also shown, but only the first two attributes in the dictionary are sho~<n. The Wired_MAB
conditi on uses two attributes from the RADfUS dictionary: Service-Type and NAS·I'ort·Type. The
conditi on requires that the Service-Type to be Call Check and the J::!l,~·Port-Type to be Ethernet The
Wireless_MAB condition (not shown) is similar, requirin_g the Service-Type to be Call Check and the NAS-
Port-Type to be Wireless . IEEE 802.1 L There are similar conditions (also not shown) used to match wired
and wireless 802.1X. They differ from the MAB conditions by requiring the Service-Type to be framed.
Conditions provide a fram~·ork to identify if the context matches a particular situation. The MAB
authentication policy reference-s two conditions with a logical or, If either of the conditions ma1c~, then t~e
results will be applied ln this case, tlle result is to set the allowed EAP protocols to be what is defined in
the All owed Protocols list named Default Network Acces-s. This list can be edited by checking and
unchecking the autllentication protocol options provided by 1St.
Cisco ISE Rule-Based Authentication
This topic describes the rule based authentication on the Cisco Identity Services E'ngine.
4
Cisco ISE Rule-Based A uthentication

Policy Types: Simple vs. Rule-Based
Conditions: Simple vs. Complex
--
..... - "
-~-- .. _..._
- ·--·
--·--·-
'i- -
·
...._._____ .......___.... .. ___
~ --- ,_ ... _
_
•- -_,., -- --- -- --- ..
._
• -
•
•-
~-
--
-- .. -
·--~-
.... __
~
V
v .
•
• ---- -- --- ~ ·
....... _.
The default authentication policy is the rule-based authentication policy. It is far more common than the
simple authentication policy. The rule-based authentication policy consists of attribute-based conditions that
determine [be allowed protocols and the identity source or identity source sequence to be used for
processing the requests. ln a simple authentication policy, you can defme the allowed protocols and identity
source statically. ln a rule·based policy, you can ddine conditions that allow Cisco lSE to dynamically
choose the allowed protocols and identity sources. You can define one or more conditions using any of the
attributes from the Cisco JSE dictionary.
Cisco ISE allows you to create conditions as individual, reus;able policy elements that can be referenced
fiom other rule~based policies. You can also create conditions from within the policy creation page. There
are two types of conditions:
Simple condition: A simple condition consists ·o f three components: attribute, operand, and value. It
can be saved and reused in other rule~ based policies. You can use any atrribute from the Cisco ISE
dictionary and specifY any value that fits the attribute.
Compound condition: A compound condition is made up of one or more simple conditions with an
AND or OR relationship. These conditions are built in addition to simple conditions and can be saved
and reused in other rule-based policies.

Authentication Conditions
'J'bis topic describes the authentication conditions.
Authentication Conditions
""'" Simple oondilon
~ ~~~ ) .. s
I DI!VlCE. DtWle ~
~
I~ I
COmpoundCOMI.hon
~I
-s I
I CERTIFICAT£ Sol"'- II EOIMU II MOITIQ I

I """ I~ t
1-•-·u-•.... 11 £0\IAU II•-••••• a I
An example of a simple condition is: DEVICE: Device Type Equals Wireless. This syntax includes an
attribute, which is written in the format OICrtONARY: dictionary·attribute, dle operand, and the value.
11le example of the compound condition shown in the figure combines two individual conditions
(certifJ.oCate serial number check and Cisco Identity Services Engine hostname check) wing the AN"D
operator. The operands available for use depend on the data type of the attribute (i.e. 'contains' and 'starts
with' are available for attributes of type String but not Nu:meric). The attributes are defined in Cisco fSE.
dictionaries. The operator that combines the individual conditions can be AND or OR.
Tune Rule-Based Authentication {Situational)
This topic describes how to implement rule~based authentication on the Cisco Identity Services Engine.
Tune Rule-Based Authentication (Situational)

1 Define simple conditions
2. Define compound conditions
3. Define allowed protocols
4. Tune or create authentication policy rules:
S&!act oondilion(s)
Add conditions
Choose allowed protocols
Select identity source(s)
5. Tune defautt rule:

Default rule applies wMn no match has boon toun.d
OGfau!t rutc has the follOwing def'ault values:
Allowed protocols: Default Network
....... _. Identity source: Internal Cis.::o ISE database
The procedure shown above describes bow to defme a rule·based authentication policy on Cisco lSE. You
will use the procedure only in environments where the default authentication policy must be tuned. All
these steps are optional:
I . Define simple conditions
2. Create or rune compound conditions
3. Define aUowed protocols
4. Define a rule~based authentication policy. Within this step you will create a new rule, define or add
conditions. specify allowed protocols, and choose identity sources
5. Tune the default rule. The defauJt rule defmes actions [0 be taken when no specific malch is found The
defauJt settings are to use the Default Network list as the allowed protocols set, and the internal Cisco
!Sf. database as the identity source.

Define Simple Conditions (Opt ional)
'J'bis topic describes bow to configure simple authenticatio n conditions.
Define Simple Conditions (Optional)

For subsequent use in rule~based authentication policies
Allows modular definrtions of policies
·oictionary: attribute--operand·value" expression
--- - - 0 ••
•- a-..,. ...-.. -- -
.....
- •
·--
.. =-;;:...~
·---- ·-
--- - ·- ·-
·-
L ·-
--------~--~~--~====~~ ·-
·-
·-
·--
,_
.
-- ·-
::- •
Tbe figure shows how to create a simple condition. It consists of an attribute, an operator, and a value. You
can create simple conditions from within t:he policy pages and also as separate policy elements that can be
reused in policies.
Create or Tune Compound Conditions (Optional)
This topic describes how to create or tune compound conditions.
Create or Tune Compound Conditions

(Optional)
Predefmed compound conditions for the most common use cases
List of expressions or existing conditions
Combined using operatOr (AND 1 OR)
Mix of ANOs and ORs not permitted w ithin a single condition definitiOn
Member conditions can be ereat&d, addE~-d from libraty, or delated
- ·--· -"""' ·
-- -
.. - - -
---
.....
- - e;-... .. o-.._.............~-
..·--··
#, - o l n -
---
--
O• • · ...
....... _.
--
Compound conditions are made up of two or more s imple conditions. You can create compound conditions
as reusable objects from within the Policy Creation page or from the Conditions page. Cisco ldentity
Services Engine comes witll predefmed compound conditions for some of the most common use cases.
Compound conditions contain multiple expressions. that are combined using an AND or OR operator. You
can use only a single operator within a compound condition. Mixing of ANDs and ORs is not allowed!. for
complex rulesets, you may achieve a mix of ANDs and ORs by nesting compound conditions within a
hierarchy. A lower·level compound condition may use one of these operators, while a higher 1evel 4
condition may use the other. Bear in mind that such complexity makes rhe rulesets difficult to read and
understand and should be used with caution.
The example in this figure illustrates a pr~defined !Compound condition Wired_8021.X consisting ofnwo
individual conditions that are combined using the AN'D operator. This condition is used to match 802.\X
access requests from wired switches. The first condition checks if the RADIUS: Service-Type is equal to
f ramed. The second condition checks if the RADTUS:NAS-Port-Type is Ethernet.

Define Allowed Protocols (Optional)
'J'bis topic describes bow to define the aJiowed protocols.
Define Allowed Protocols (Optional)

Policy rules specify allowed authentication protocols.
~Default Networ1c: Access" permits all common protocols .
---
.. -"-
-.. ..
·--
---- - --r-- -
··--
I
~·
··-
· ~ ·--
···-
··--
---- . --. - ..-- •
a--
·•--
' ----·
··---
ln Cisco Identity Services Engine you have the option of using the built·in allowed protocol set or create a
custom list of allowed authentication protocols. You can view and customize the default protocol set. It is
named Default Network Access and can be edited in tlle Policy> l,olicy Elements-> Results>
Autbe.n tication >Allowed Protocols Services menu.
·The Default Network Access protocol set is added to the Cisco IS£ as a result of the installation procedure.
It allows the use of all major EAP methods.
You can modify the Default Network Access protocol set to meet your needs or configure a custom allowed.
protocol set. The allowed protocol set is referenced by the authentication policy rules.
2-.3& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Tune or Create Authenticataon Rules (Cont.)
Spe<:ify the allowed protocols
Define identity source
.- . -- -
Optionally specify additional conditional identity sources
_.---..
. - ..
""--·
-----·
_..,.__ ... ·----·--·--------... --·-
-·-
Oo -
-- --
• --- ---
-- II
·-.-
.___. . ...- -·--
- - 0
• •• - -0
.... - 0
'J'he next component of an authentication rule is the allowed protocols service. This example use.~ the
Default Network Access object, which you may modifY. You unfold the Network Access Services menu by
clickin_g the arrow~down symbol of the Select Network Access field.
'J1le last element of the authentication rule is the identity source that will be used to authenticate the users
when title previously defined conditions and access protocols are matched. "fhe identity source can be the
internal database, an external server, or an identity source sequence. An identity source sequence defines
the orcfer in which Cisco ISE will look for user credentials in the databases.
An aufi:hentication rule can use more than one identity source or identity source sequence. Although not
shown in the figure. you can configure an additional set o.f conditions that need to be matched for a specific
identity source to be used for authentication. The conditions that are defined in this section constitute
another layer of conditions. 'The authentication rule itself define.li one or more parent·level conditions. ·ne
conditi.ons that are used for selecting the identity sources :should be thought of as child-level conditions.
which are evaluated. after the parent·level conditions are met.
Tune Default Authentication Rule {Optional)
This topic describes how to tune the default authentication rule.
Tune Default Authentication Rule (Optional)

The last row in this Policy page is the default policy
Default policy will be applied if none of the rules match the request
Default settings: Default Networi< Access. Internal Users
":;;;;;:":"-~~ - .~ - .
...---
-: -
-·--
\ ·-
·---
---
-
~-
-- ---
- - - 1.;, _ _ .. , _,_
·---
...---
--·--- . ..
.-I ••
-···
.---
~· -----
.......
·-
01
....... _.
The rule-based authentication policy ends with a default policy that acts as a "catch-aU" statement for
authentication requests that have not been matched by any previous rules. Like all other rules, it matches the
allowed protocols service and selects an identity source or identity source sequence. It does not inclu<fe any
conditions.

Cis.co Network Access Manager
'J'bis topic describes the Cisco Network Access Manager.
Cisco Network Access Manager

OS· independent 802.1X supplicant
Element of the Cisco AnyConnect package
_
Supports EAP chaining
.. •
- -- --
........... _........ _
- -- ,_
--
The Cisco NAM is a Cisco-engineered OS ~ independent client software that provides a secure Layer 2
network in accordance with policies set forth by the enterprise network administrators. The Network Access
Manager detects and selects the Layer 2 access network and performs device authentication for access to
both wired and wireless networks. The Network Access Manager manages user and device identity and the
network access protocols required for secure access. Jt can prevent end users from making connections that
are in violation of administrator~defmed policies.
Cisco NA.i\1 is a component of the Cisco AnyConnect Security Mobility Client portfolio that can be
combined with its other optional elements, such as the Web Security Module. Together with Cisco Identity
Services Engine it supports EAP chaining. which allows you to evaluate the type of the client devices that
users connec[ from.
2~2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Networks and Network Groups in Cisco NAM
This topic describes the networks and network groups in the Cisco Network Acce.c;s Manager.
Networks and Network Groups in Cisco NAM

Containers for 802.1X authentication settings
Configured using the Networi< Access Manager Profile Editor
Network groups jointly define par.ameters for similar networks
One network predefined by default wired
..... .... .........

·---.. --
-·
~
lt-- -- --
!~
liii""-
....
.....
L "'"
....... _.
The Cisco iN AM Profile Editor allo\\'S you to configure pre-<l.efined ne~·orks for your enterprise user. You
can either configure networks that are available to all groups, or create groups with specific networks. A
group is a oontainer for autllentication settings applied when tlle user attempts connection to a given
oetv.·ork type. The Nerv.·orks window runs a wizard. that sometimes adds panes to the existing window.
A group, fundamentally, is a collection of configured connections (networks). Every configured connection
must belong [0 a group or a member of aU groups.

Network Settings in Cisco NAM
'J'bis topic describes the network settings in the Cisco Net\\•ork Access Manager.
Network Settings in Cisco NAM

Separate templates for machine and user authentication
Gathered into a configuration profiie
Configured in categolies: certificates, PAC files. credentials
.........
----
-....- .......- ..
--·--
.... _.. _
,...-
-· .. --
...- ...-. --
--·--~
~---
Tbe Cisco NAM Proftle Editor enables you to create or edit a wired or a wireless network. The settings for
each network vary depending on whether you choose wired or wireless. Tbe settings are grouped in
categories. ·J1te figure above shows tlle categories available for the default 'wired' network of media type
"Wired (802.3)". They include Security Level, Connecti<rn Type, Machine Authentication, along with the
related categories Certificates. PAC Files, Credentials, and the User Authentication, along with the related
categories Certificates, PAC Files, Credentials. Depending on your scenario you will have to edit only the
required settings and leave all other parameters at their defauJt values.
2~4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
Summary
Summary
Cisco ISE rule·based authentication policy consists of rules that are
buitt with conditions and authentication resutts.
Cisco ISE supports simple and compound conditions.
Allowed protocols define the pennitted authentication protocols.
Cisco ISE can authenticate the users against the local or an extemal
database.
Cisco NAM is the 05-independent 802.1X supplicant that supports
EAP chaining.
. ...... _

Lesson 41
Cisco ISE External

Authentication
Cisco Identity Services Engine supports a number of external authentication sources, which are also
referred to as authentication servers. The authentication servers maintain user databases and store various
user attributes. External authentication sources are common in enterprise deployments because they provide
a single configuration point for user accounts between various enterprise applications, services, and
systems.
• Describe the external authentication
• Describe the Active Directory
• Describe the authentication methods with Active Directory
• Describe the AD..derlved group membership
• Describe the methods of integrating Cisco lSE with the Active Directory
• Describe the A~tive Directory integration pro~edure
• Describe how to configure the AD domain and :store
.. Describe how to test the connection to the Active Directory
.. Describe how to join tlle lSE [0 the Active Directory
.. Describe how to select groups from the directory
.. Describe the Cisco lSE identity source sequences
.. Describe how to configure the identity source sequence
.. Describe how to apply the identity source sequence in the authentication policy
.. Describe how to verify external authentication
External Authentication
Tbis topic describes the external authentication.
External Authentication
Cisco ISE can authenticate clients against the following:
A singfe authentication sourCG
A sa<:;OOOOQ of authentication sources
Supported extemal authentication sources include Active Directory,
LDAP, RADIUS, and RSA serve<s
·- .. ·-·
Most companies deploy a scalable authentication framework that utilizes external repositories for storing
user accounts and user attributes. Such approach allows multiple systems lO connect to a single centralized
database and request the required information. The external identity source is configured in a redundant
fashion to provide a highly available authentication soluti on.
Cisco Udentity Services Engine can authenticate clients against a single authentication source or a sequence
of authentication sources.
Tbe supported external authentication sources include Active Directory, LDAP, RADIUS, and Secure RSA
servers.
2~& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
Active Directory
This topic describes the Active Directory.
Active Directory
Widely deployed directory structure
Hierarchical format that allows foreS1
lOgical grouping of users or devices
Can bo U'S4)d to assign pormissiOns
to userS, network dovk:Cs, and
ob;ect groups
I "".
treeA / treiS
Requires accurate time
Max 5 minutes differonoo M tween
ISE and AD
domainA domainS
Firewalling constraints between
/ 11
Cisco ISE and Active Directory:
Certain ports need to be opened
No support for~ OU-1 OU-2 OU-3
....... _. / '
objeCIA objectS
Active Directory is a hierarcbjcal data store that serves as a repository for network user and device
information. This network information is stored as individual entities, which are known as objects. Objects
may describe devices and entities that are found on the network, such as servers, printers, client PC.c;, and
user accounts.
This directory structure allows network administrators to place objects into groups that share similar
network permissions, function, or location on the network. Active Directory is designed to provide
permissions for users and network devices that are based on configured corporate policies.
Active DirectoJ)' utilizes a topology structure that is like DNS, which utilizes a tree for tlle hierarchical
layers. Active Directory includes the following layers:
.. Object: An object in the Active DirectoJ)' is any user, client PC, network server, printer, or other
device that is integrated within the directory.
.. Organizational Unit: An organizational unit i:s a logical grouping of objects within the domain.
Organizational units are organized based on the network design. They may be collections of users in
the same corporate group, servers in the same cluster, printers on tlle same floor, or any other grouping
of corporate significance.
.. Domain: A domain is a grouping of objects that shares the same database. This domain may contain a
host of objects that are logically g10uped as organizational units.
.. Tree: A tree is a collection of one or more domains that share trust relationships.
.. Forest: ·This layer is the top level of the Active DirectoJ)'. The forest contains one or more trees, and
any objects within the same forest share the same global catalog, directOJY schema, logical structure,
and directory configuration.

Jfrbere is a firewall between Cisco Identity Services Engine and Active Directory, certain ports need to be
opened to allow Cisco ISE to oonununicate \\ith Active Directory. Ensure that the following default ports
are open:
PrOtOCd Port
LOAP 389 t UDP), 389 (!£e)
LDAPS 636(TCP)
SMB 445{TCP)
KDC 88 (TCP)
GlobaJ CalaiOg 3268 (TCP), 3269 (TCP)
KPASS 4ll4 (TCP)
NTP 123 (UDP)
2--60 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Authentication Methods with Active Directory
This topic describes the authentication methods supported with Active Directory.
Authentication Methods with Active Directory

Most common authentication methods are supported in
a Cisco ISE with Active Directory integration.
EAP·TLS and PEAP· TLS use d ient-side certificates.
- - - - - -·· PJI\PilSCi
Activo Directory records may ind ud.o one or more
W:Wt
certificates.
W:OkiM
Cisoo ISE can retri&ve these certificates and use tMm to
verity the identity of tM ~r or maChine. w.n:s
.......
f'W
N!Ai'-M
EliP$ASf
!AP-Gte
....... _.
Cisco Identity Services Engine supports the foiJowEng authentication protocols when using Active Directory
as the external authentication source:
• EAP·FA..' n andP£AP: Cisco lS£ supports user and machine authentication and password changes
against Active Directory using EAI' -FASl and PEAl' with an inner method of MS-CHAI>v2 and~
GTC.
PAP: Cisco ISS supports authentication against Active Directory using PAP and also allows you to
change Active Directory user passwords.
.. MS...CHAP\'1: Cisco lSE supports user and machine authentication against Active Directory using
MS-CI-!APv l.
.. MS...CHAP\•2: Cisco JSE: supports user and machine authentication against Active Directory using
MS-CHAPv2.
.. EAP...CTC: Cisco ISE supports user and machine authentication ag.ains[ Active Directory using EAP~
GTC.
.. EAP·TLS: Cisco JSE uses the certificate retrieval option to support user and machine authentical!ion
against Active Direc[ory using EAl, ~TLS.
.. l,EAP..TLS: Cisco ISE supports user and machine authentication against Active Directory using
PEAP-TLS.
.. LEAP: Cisco IS£ supports user authentication against Active Directory using LEAP.

AD-Derived Group Membership
'Jllis topic describes the AD-derived group membership.
AD-Derived Group Membership

Users belong to user groups
Group membership improves manageability
PrivilegM assigned to usGr groups
For domain users:
Group membership d.ofinod in AD
Groups downloaded from tho AD
Group membership US(Jd in ISE policy deciSiOnS
Thi!JG_"_Ittel~Kt.- ..... .,.~~....... Go ......a _ _.,

UM•b'OIIIIXMI-... _ , .......... .....,. • . , . . _ - - - - - - - -
~ ~~:::·:~::::::::~~~~~~~
.... ,____ .__, · =
-=":.:'"'=-.,....-=--,
--
~,
o- ....._
0 -~..o·~
0
0
M<-t:oniC.r,.V>G
...._
••t
. . .
........
You can improve the manageability of an authentication system by assigning users to groups. Group
membership is typically leveraged for assigning lhe same privileges to a user group. If the users reside in an
external repository, tl1e group membership infonnation must be also kept there.
Cisco ndentity Services Engine provides an Active Directory as a policy element when AD integration is
configured. You can download the appropriate groups from AD into the dictionary. Group membership is
then an attribute that can be referenced in conditions £hat <define the requirements for context sensitive
polices that are assigned by JSE.
2..52 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Active Directory Integration Methods
This topic describes the methods of integrating Cisco Identity Services Engine with the Active Directory.
Active Directory Integration Methods

Active Directory Activo Directory
Charaetarlstles
Aeces.sed N'.ativaty Accesud as LDAP
Attribute scope Ri ch attribute SGt Fewer attributes
PGrfOtmance Faster Slower
Support fOf' multiple trees Only s ingle dir&ctory Can join m ultiple
{dtrecc tie} directories
s earCh capabilities Up Of dOwn th& troe Down tM tree only
....... _.
LDAP is a standards·bas.ed net\\•orking protocol for querying and modif)ting directory services that run on
!gPil~. LDAP is a lightweigh< mechanism for accessing an X.500-based direc<ory server. Cisco !SE
integrates \\rith an LOAJl external database by using the LOAJ> protocol.
An LDAP directory is organized in a simple tree hierarchy and can be di~tributed among many servers.
Each server can have a replicated version of the total directory, which is synchronized periodically. An
enrry in the tree contains a set of attributes. Each attribute has a name (an attribute type or attribute
description) and one or more values. The attributes are defined in a schema. Cisco IS£ bali three
preconfigured LDAP scbemas: Active Directory, Sun Directory Server, and Novell eDirectory.
You can access the Active Directory database either as Active Directory or as LDAP server. Both methods
have their pros and cons. (fyou connect to the AD repository using the Active Directory method, you gain
the advantages resuJting from the direct tie between me lSE and AD: an extensive attribute range, good
performance, search up or down ~1e tree. In Ibis fashion, <he ISE can join only a single airec<ory.lfyou
connect to the AD as an LDAP server, you gain the option ofjoining multipte directories. This method,
however, stows down the performance, offers fewer attributes, and supports sean;h down the tree only.

Active Directory Integration Procedure
'J'bis topic describes bow to integrate Cisco Identity Services Engine with an Active Directory database.
Active Directory Integration Procedure

1. Configure Active Directory domain name and store name in Cisco ISE
2. Test server connection (optionaf)
3. Join Cisco ISE nodes to the directory
4. Select groops from the directory (optional)
Perform these steps to integrate the Chico Identity Services Engine with an Active Directory database:
1. Configure Active Directory domain name and store name in Cisco ISE
2. Test server connection (optional)
3. Join Cisco ISE nodes to the directory
4. Select groups from the directory (optional)
2--5-4 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Configure AD Domain and Store
This topic describes how to configure the AD domain and store.
Configure AD Domain and Store

Enter domain name of the Active Directory server.
Enter a friendly identity store name.
··- ·-
Save the changes.
---
-- -·-·
----·-
--· --- -
--
·---
••••
--
·--
----
---- -__-_ . -
••
-·---·--·-·---
,.
- ___
,·------
.
-··-···-
~-
_ .. _ _ _ _ _ _ .. _..
Vt'O _ _ _
.....
·--.J-.... ==1
.___,_,_
ILIYL
·---·---··
..-·---·--
---·---,·-·--·--·-
•
..
....... _.
To connect to an Active Directoty domain, complete the following steps:
I . Choose Administration > Identity Management> External Identity Sources.
2. From the External identity Sources navigation pane on the left, click Active Directory. The Active
Directory page appears.
3. Enter the domain name in the 'Domain Name text box.
4. Enter a friendly name in the Identity Store Name text box for your Active Directory identity source (by
default, this value will be AD 1).
5. Click Save Configuration. Saving the configuration saves the Active Directory domain configuration
globally (in the primary as well as the secondary l'olicy Service nodes).
C 2014 Clsoo Sys1ems. Inc. Student Guide 2-SS

Test AD Connect ion
'J'bis topic describes bow to te.c;t the connection to the Active Directory.
Test AD Connection
Click Test Connection and select Basiic or Detailed Test
Must have Super Admin or System Admin role
--- -- ·--:--· - - I
-·--...;::::::.-..
- - -..-a.... ::~:...- ··-·--·--·--..-
. -.-:::-:,. -=-; -·--- -
.
Ii. . ...--·-
·-- - ~-
---
.. .. ___
_ .
...._ --
.. . .........,.
'..,._ -......,a:..u.u ;.
_..,. ..,....
··-~~-·
_,,...·-·
·-
----
-- ~·-····
--·...
~---·-
.
After you save the domain name and identity store name, you are presented with the options to join, leave
the joined directory, and test the connection to the domain.
You may test the connection by selecting a specific node from the deployment, clicking the Test
Connection button, and choosing one of two a\-ailable methods: Basic Test or Detailed Test. The
difference between the two types lies in the output verbosity.
When you click the Test Connection button, a dialog box appears and prompts you to enter the Active
Directory usemame and password.
2--66 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Join Active Directory
This topic describes how to join the Cisco Identity Services Engine to the Active Directory.
Join Active Directory

Creating the connection does nou automatically join the AD
Join one or multiple nodes in a si ngle step
-- - ..._ - ·-
____ ......
_
Click Join and provide the Active Directory username and password
~·· ·
-·-------·--··-·--·--·--·-
,.,._ ·--~
- t - ·t-
__________
- t! -
lt!i - .... __ _ --
•- -
......
I T1' . . - . . . . .- . - · -·--
•
._:. _
1·- a
.,
·. -! ---
----------
·-
---- . - -·----
•~
~~----~=-----~
....... _.
Although you submitted the configuration in a previous step, you have to click J oin to connect your Cisco
(dentity Services Engine node lO the Active Directory domain. You must manually perfonn the Join
operation for each Policy Service node that should be oonnected to the Active Directory domain.
ln the Administration > System > Active Directory Operations menu, choose the node to be joined, click
Join, and enter the Active Directory administrator username and password in the Join Domain diaJog box
that appears.

Select Groups from Directory
'J'bis topic describes bow to select groups from the directory.
Select Groups from Directory

Import groups for use in policy conditioms and rules
-
Later changes in AD are not automatically reflected in ISE
--_- -
_,_,....._
~-r -· x:--
-
n.. ........
"
...... ~·--
i
. . . ............. -..
·~.,......... _._.-~-
~ ...-_._....,.......
..
____.J
~ Cli:l;_
_..................
--
lil _ _ ...... _
........................ ._,_
.
•
"" r·
... f'OOO- ,.,._
....
~•
Q ........ ...--I 1
-.. .....................
0 ............._.._.. ~""----..
0 __•• .....,.........
""A
......
"""'
.
0 -
li!J
QJ ,.
"'
-··
""''fiUIIotrlC'
~ ....
no...-_,.._~
_..--
___,
.....
--
......
"""
.
When the Cisco Identity Services Engine bas joined the Active Directory dom.ain, you can retrieve groups
-,..
for use with authentication and authorization policies. The retrieved groups are kept on the Cisco ISE. and
do not change in Cisco ISE when the group information changes in the Active Direcc01y. To update the
group i nformation on the Cisco lSE, you need to repeat tbe retrieve operation.
To configure Active Directory groups that will be available for use in authorization policy conditions,
navigate to the Administration> lde.ntity Management> External Identity Sources menu and select
Active Directory. Select the Groups tab and the Add> Select Groups From Directory from the toolbar.
Enter title domain name and optionally a filter, and click Retrieve Groups. Adding a group in the Cisco JS'E
does not create the group within the Active Directory database.
Tbe Cisco IS£ pulls the group information from the directory and presents the groups in a list. Note, the
maximum number of groups that are retrieved with a single query is 100. If your query filter matches more
!han l 00 groups, the group list will be truncated. You can check the groups that should be retrieved and
uncheck the ones that you will not use in authentication and authorization definitions. All retrieved groups
are checked by default.
2--6& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Cisco ISE Identity Source Sequence
This topic describes the Cisco Identity Services Engine identity source sequences.
Cisco ISE Identity Source Sequence

A sequence of identity databases that is used for authentication
Always proceed to next store if user not found
Optionally proceed to next store ff current source failed
FallbaCk behavior dEl'finOO in the Advanced Search List settings
Example illustrates a case with ..Proceed to the next store in sequence"
option it the store cannot b& acc·essed for authentication
~ ~occ-.-.r
~- ----====---
....... _.
(dentity source sequences define the order in which! the Cisco ISE will look for user credentials in different
databases. If your user information is in more than one database dlat is connected to your Cisco ISE:, you
can define the order in which you want the ISE to look for user information in these databases.
Once a match is found, Cisco IS£ does not look any further, but evaJuates the credentials and returns l!be
result to the user. Tbi1i policy is the first match policy.
The Cisco ISE behavior is configurabte for situations when a certain database cannot be accessed. The two
available settings are to continue searching other databases or stop processing.
This example illustrates an identity source sequence of three databases: Active Directory, LDAP, and an
intemal lSE database. The user is not found in the AD database, and the IS£ proceeds to searching the
second source. Because the LDAP server is down and the option .. Proceed to the next store in the sequence"
bas been configured, tlle Cisco lSE falls back to tl1e third identity source. As the user does not exist in the
internal !SB database, the authentication fails.

Configure Identity Source Sequence
'J'bis topic describes bow to configure the identity source :sequence.
--
Configure Identity Source Sequence
-
- ·- --- .. ....._.. ... - .
..
- ---
.
. . . . .-ool.......
- ·~ ~ .
___
_
. ·-:
_,.,. f~~ I
..o -~--
·-·---.
- . .-------.
- -J .
~-. .......,.~I
r=J~i~
_ . _
._... _... ..____..__
..
~
I
oe.-------- -·- d
··--·---------·----..- _.-J
~.,ftr.llli:bela)
..-e ·····•'U'*
·-~
Configure Identity Source Sequence (Cont.)

. By defautt, processing stops after the identity source cannot be
accessed.
. Do not accoos other storOS in tho soquenoo
. Sets tM AutMnticatiOn Status to Prooess Error
. To enable rollover:
Choose 2nd radio box
Treat as if tho user was not found and procooo to the next storo in the
seo.uence
---
These two options define the behavior when the databa~e is not accessible:
Do Not Ac.c.ess Other Stores in the Sequence: This option is the default method. It causes the Cisco
ldentity Services Engine to stop processing tbe list.
Tr.eat as if the User Was iNot J<'ound and Proc-eed to the Next Store in the Sequence: This method
enables failover to the next source if the database is not reachable.
2.00 lmplemen~ng Cisco Security Access Sei\Jtlons -0 2014 asco Sy&ems, lnc.
'fhis example illustrates bow to configure an identley source sequence that consists of four sources: Active
Directory database, an LOA!' repository, the internal user database, and the internal endpoint database.

Apply Identity Source Sequence
'J'bis topic describes bow to apply the identity source sequence in lhe authentication policy.
Apply Identity Source Sequence

Identity source sequence referenced by authentication rules
Options independent from chaining behavior within the sequence
.- - ·-·- ·
.-..e- ... - - - - - · •- -
-----··-------·--------------
-?.. - o- •-
----- -.
·-
·- ---· ~
•
._._..______ __
.--·..- ---------·--
·--·- ..___.._ ,
Identities source sequences are applied to the authenticat1on policy rules as result.c:; alongside with the
allowed protocol specification. The configurable options for the failure scenarios if authentication failed, if
user not found, or if process failed describe the failover behavior for the entire sequence, not for its
individual identity sources. The failover behavior within dhe identity source sequence id defined inside the
sequence itself and was shown earlier.
2.02 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Verify External Authentication
This topic describes how to verify external authentication.
Verify External Authentication

Details in the authentication pages show the actual source.
...
--
-- ........
..
-- . .__ ·-
.
••'-"
....
...... ,
,.
,.
--·-
--- -
--
------·
• --·-
-Q---·----·--· -- --·-1>
aun&~ •
......... _ .
.uu~n.-v• •
---
o
•
. . . . __
c-... -
- -·--
...... _
_7-::::::::J C::::::::J c=J c::::J L
_..,
- 1 -G;!I!iii~
-""'""'*
~
The Cisco Identity Services Engine dashboard provides a summary of all authentications that take place in
your network in the Ope.rations > Authentic-atioll! menu. You can click on the Details button and see what
identity source has been actually used to authenticale the clientln this example, sales1 is a domain user and
bas been authenticated in the Active Directory.

Summary
Summary
Cisco ISE can authenticate the users against the local or an external
database.
Active Directory is a widely used extemal user database.
Cisco ISE joins the Active Directory to authenticate the domain users
and computers.
Identity source sequence defines an authentication chain.
Identity source sequence can be referenced by the authentication
policy rules.
Module Summary
Module Summary
The Cisco ISE provides a versatile AAA platform with additional
functions.
Most EAP methods use certificate-based server authentication.
Cisco I SE authentication rules check condition s. define permitted
protocols, and spedfy the identity source.
Cisco I SE can outsource authentication to external databases, such as
Active Directory.
0,.,.__.._
References
for additional infonnation refer to this resource:
2.00 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Module Self-Check
Questions
I. Which Cisco ISE node acts as the RADIUS server to the network access devices? (Source: Cisco ISE
Overview)
A. admin
B. policy service
C. monitoring
0. rroubleshooting
B. monitoring and troubleshooting
2. Which two options are Cisco ISE persona.<? (Choose two.) (Source: CL<co ISE Overview)
A. admin
B. reporting
C. policy service
0. profiler
E. inline posture
3. How would you deploy Cisco ISE personas in a four node deployment? (Choose two.) (Source:
Cisco ISE Overview)
A. One node dedicated to admin persona
B. Only one node dedicated to policy services persona
C. Two nodes dedicated to admin and monitoring personas, with reversed primary and secondary
roles
0. Policy services persona running on all four nodes
4. \Vhich statement describes the relation between certificate validation and time accuracy? (Source:
Cisco IS£ PKI)
A. Time difference between the communicating parties must be shorter than 5 minutes
B. Time must be synchronized between the communicating parties
C. 1be current time on one end must fall within the validity range of the other system's certificate
V. Time check is optional
5. f'or which rn·o services can you enable the identity certificate on the ISE? (Choose £Wo.) (Source:
Cisco IS£ PKI)
A. EAP exchange
B. Cenificate signing
C. HTTPS negotiation
D. Secure RADIUS
E. fKE
6. \Vhich two protocols use certificate~based server authentication? (Choose two.) (Source: Cisco ISE
I' Kl)
A PEAP (l::AP-MSCHAI'V2)
B. EAP (EAP-MSCHAPv2)
C. EAP·FAST (EAP-MSCHAI'VZ)
D. EAP-TLS (EAP-MSCHAI'VZ)
E. EAP-MSCHAPv2
7. Which IWO are checked or applied in an IS£ authentication rule? (Choose two.) (Source: Cisco ISE
Authentication)
A. allowed protocols
B. profile
C. status
D. complex condition
E. identity source
8. Which IWO are policy elements on the Cisco IS&"? (Choose two.) (Source: Cisco ISE Authentication)
A. Attribute
B. Result
C. Policy
D. Rule
E. Compound condition
9. You have to configure authentication policy for the JSE to accept authentication requests? (True or
false) (Source: Cisco IS£ Authentication)
A. True
B. False
10. Which two options can use when integrating JSE with two AD domains? (Choose two.) (Source:
Ci<co JSE External Authentication)
A. Access both as Active Directory
B. Access both as LOA!'
C. Access one as Active 'Directory, another as RADfUS
D. Access one as Active Direccory. another as LDAJ>
E. Access one as LDAP, another as RAOIUS
I I. Can you deploy EAI' chaining v.>ith Active Directory? (Source: Cisco JSE External Authentication)
A. Yes, with EAI' ·FASTvl

B. Yes, with EAI' ·FASTv2
C. Yes, with EAl' ·FASTv3
D. Yes, if Active Directory is accessed as LDAP
E. No. tlle required E.AP method is not supported with Active Directory
12. An identity source sequence by default checks the next store if the previous store is unavailable.
(frue or false) (Source: Cisco JSE External Authentication)
A. True
B. False

Answer Key
I. B
2. A,C
3. c
4. c
5. A,C
6. A,C
7. A,E
8. B,E
9. B
10. B
II. B
12. B
Module 31
Advanced Access Control

This module describes certificate~based client authentication, Cisco l dentity Services Engine authorization,
Security Group Access (SGA) and MAC Security 'MACsec). These features provide enhanced access
control capabilities in the Cisoo JSE solution.
The Cisco Security Group Access (SGA) solution uses the device and user identity infonnation that it
obtains during authenticarjon to classify the packets as they enter the network. Tbis packet classification is
maintained by tagging packets when they enter the SGA network so !hat !hey can be properly identified for
the purpose of applying security and olher policy criteria along the data pach. The tag, also called the
security group tag (SGT), allows the ISE to enforce access control policies by enabling the endpoint device
to act upon the SGT co filter traffic.
MACsec is the IEEE 802.1 AE standard for authenticating and encrypting packets between two MACsec-
capable devices.
Upon completing this module, you will be able to:
.. Describe certificate-based client authentication in EAl,·TLS.
Describe the authorization in Cisco LSE.
• Describe the Cisco Security Group Aocess (SGA) solution and MACsec.
l-2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Lesson 11
Certificate-Based User
Authentication
Advanced Access Control
This lesson describes certificate·based client authentication, which is used in EAP~TLS. EAI,·TLS
advantages include the openness of the standard, wide vendor support, and high security. The disadvantages
of the EAP·TLS method include the need to provision the client certificates and additional f.!S.1
requirements.
Upon completing this lesson, you will be able to:
• Describe the use of certificates
• Describe the verification of the client certificates
• Describe the implementation procedure for certificate-based client authentication
.. Describe how to identify theCA root certificate used for verification of EAP sessions.
• Describe how to deploy certificates on clients
• Describe how to configure the 802.1X supplicant to use EAP-1LS
• Describe how to configure the 802.1 X supplicant to use appropriate certificates
• Describe the certificate authentication
Describe how to apply tlle certificate authenticarjon profile to an identity source sequence
.. Describe how to verifY me EAP·TLS operation
EAP-TLS Bidirectional Authentication
Tbis topic describes the use of certificates.
EAP-TLS Bidirectional Auth entication

EAP· TlS uses both client-side and server-side certificates
Considered one of the most secure EA~ options
Open IETF Standard
Popular for BYOO solutions
·- .. ·-·
EAP·T LS utilizes client-side certificates in addition to server·side certificates. Generally both me cJjent and
the server must enroll with the same PKJ. Both the client and the server hold a copy of their own identity
certificate and a copy of theCA root certificate. When EAP·TLS initiates, both sides wiiJ present their
identity certificate to the other and both sides will use the CA's public key to verify the signature on the
other's identity ce.rtificate.
Tbe fact that EAP-TLS uses certificates in a bi-directional fashion, it is considered one of the most secure
EAP options. There are no concerns with password capture when using EAP·TLS.
EAP-TLS is an lETf" open standard. Virtually all networking vendors support EAP-TLS and it does not
require Active Directory on tl1e back end.
EAI)·TLS is becoming a popular protocol to support BYOD in the enterprise. One complaint that is often
leveraged against EAP·TLS is that there is too much management overhead involved in the provisioning of
certificates for every client. This disadvantage may actually be turned into an advantage if strong conU'Ol
over which devices are allowed to access the network L11 desired. h is relatively easy to set up a policy that
doesn't allow connectivity of devices unle.~s they have gone through the certificate provisioning process.
ConD"' 1certificate provision and you control which devices are allowed access.
3~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.

Verification of Client Certificates
This topic describes the verification of the client certificates.
Verification of Client Certificates

Server must have CA root certificate
Client authentication perfooned after server authentication
c:r..NW*•If~ 101$E:
····-····-···················
--
....... _.
[n a Cisco Identity Services Engine deployment, it is the Policy Service Node that acts as the RADfUS
server.
\Vith EAP·TLS, the server uses the same process as the client for verifying the peer identity. Both the client
and the server have enrolled with the same PKJ and hence both have their own identity certificate and tl1e
CA root certificate. Potentially they ~'ill have the chain of certificates leading to the root CA if the PKl is
bierarchical The server uses tbe CA's public key, obtained from theCA root certificate to verify the
signature on the certificate presented by the client. If the signature proves valid, then the public key
included in the the client's certificate must also be valid. The server challenges the client to prove that the
client has the private key associated with the public key in the certificate. If the client passes the challenge,
i·ts identity is verified.

Implementation Procedure for EAP-TLS in Cisco
ISE Deployment
111is topic describes the implementation procedure for certificate--based client authentication.
Implementation Procedure for EAP-TLS in

Cisco ISE Deployment
1. Identify CA root certificate for verification of EAP sessions
2. Deploy certificates on clients
3. Configure 802.1X supplicant to use EAP· TLS
4. Configure 802.1X supplicant to use specific certificates
5. Configure certificate authentication profile
6. Apply certificate authentication profile to identity source sequence
Follow these steps to configure certificate~related tasks on tlle Cisco ldentity Services Engine and on rbe
clients:
1. Identify CA root certificate for verification of EAP sessions.
2. Deploy certificates on clients.
3. Configure 802. 1X supplicant to use EAP-TLS.
4. Configure 802.1 X supplicant to use specific certificates.
5. Configure certificate authentication profile.
6. Apply certificate authentication profile to identity source sequence.
3:.0 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Select CA Certificate for EAP Verification
This topic describes how to identify theCA root certificate used for verification of EAP sessions.
Select CA Certificate for EAP Verification

Trust a CA certificate for client authentication or secure~
With multiple CAs, not all have to be used fOf EAP
--- - - ·-
- -- --- .._._ ---
- - · - - · - - - ~
. ............
--
x.-
·-
·---
·--
·=-... c- ...
....
·-- - "----·----
------
-·--·-
--------
---- ~~-~------------------"
..
:-=-.::;.;:.::.-..-..----·""""'
....-. . . . _,_
..." . . _
--·-·-·-o.,
....... _.
-- ~ r-------------------~
Cisco Identity Services Engine must have the "Trust for client authentication or Secure Systog services"
option enabled for the root CA certificate for JSE to support EAP-TLS. When enrolling JSE into a PJU, one
of the first steps of the process is to import theCA root certificate into lSE's certificate store. At tlle tin1e of
import, you have the option enabte this option. ffthe option needs to be modified after the root certificate
~'aS imported, the certificate settings can still be edited under Administration> System> Ce,rtificates >
Certificate Store.

Deploy Certificates on Clients
'J'bis topic describes bow to deploy certificates on clients.
Deploy Certificates on Clients

On Windows in user and machine certificate stores
Can be automated with Active Directory
- __ ..._,... --
-~---
.,_.(
.. ·a o
•·---
·--
z-
.. _...__.,.
•- c -... --
----
· "="=•I
a• ..,
- ---------------- --
··--
..·--
·-- _,_ - ·--
·-- -·-·
-·
• te.!.~!.--
-- !==
·-- -·-·
t
--
----
The certificate deployment process for the cHents varies based on the operating system and supplicant type.
Tbe Windows operating system has two certificate stores: user and machine. The user certificate store is
used when a user is logged on. Note. if there are multiple user accounts on a single system, each user will
have their own certificate store. The logged on user wiiJ be able to access their own certificate store, but not
those o f other users. The current u..~;er can use a certificate: from their user store or from a smart card to
authenticate to the Cisco Identity Services Engine. The user certificate store can be viewed and managed
using the certmgr.msc or the MMC utility. The machine certificate store is consulted for EAI' challenges
when no user is logged on. It is used to authenticate the computer to the server. The machine certificate
store can be viewed and managed with the MMC program by those who have the appropriate domain
account privileges. Certificate provisioning can be cumbersome and is often the reason why enterprises are
reluctant to deploy EAP·TLS. Jt can be automated or made semi·autom.atic in an Active Directory
environment.
~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Configure 802.1X Supplicant to Use EAP-TLS
This topic describes how to configure !he 802.1X supplicant to use EAP-TLS.
Configure 802.1X Supplicant to Use EAP-TLS
- ------
~=-----
1=-.:...-
""..._ • •I t _
....... _.
The common 802. IX supplicants do not use EAP-TLS by defaul<. For example, !he Network Access
Manager of AnyConnect uses EAP·fAST by default. To configure !he ~ for EAP-TLS, it must be
selected as the EAJ, method and the option to validate the server credentials must also be selected. This
must be configured independently for machine authentication and user authentication. ln the Windows
native supplicant you need to choose the Smart Card or other cenificate option.

Configure Supplicant to Use Certificates
'J'bis topic describes bow to configure the 802.1 X supplicant to use appropriate certificates.
Configure Supplicant to Use Certificates
-·-
--
-·-
--
--
·-(lor--
--- --- --
--
--- ·--
--- --
By default, the AnyConnect supplicant requires that a smart card is used to provide the user certificates. To
allow the use the user certificate store in the OS, you need to change the setting to Prompt for Credentials
the profile editor. ·ne sub~opti on Remember while User is Logged On will allow the users logon
credentials to be passed to the server without bothering the user with an additional prompt.
3:-10 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Configure Certificate Authentication Profile
This topic describes the certificate authentication profiles.
Configure Certificate Authentication Profile

Identifies certificate attribute to be used as the principal username
U~d for other ISE policies: authorizatiOn, Client previSioning etc.
Optionally enables binary certificate comparison
With certificate copy storad in A~ or~
Ensuros exact attribut& match
---
.. •· ...
---
,_
·-·--
....... _.
-~
--- --
Certificate authentication profiles are used in authentication policies for certificate. based authentications to
verifY the authenticity of the user. The certificate authentication profiles allow you to do the following:
• Specify the certificate field that should be used as the principal usemame. Using this option. Cisco
Identity Sen'ices Engine verifies if the certificate field has the same value as the username in the
identity source. You can set this value to the Common Name, Subject AJtemative Name, Subject Serial
Number, Subject, Other Name, Email, or DN~.
• SpecifY if a binary comparison of the certificate should be perfonned. lfthis option is enabled, C<sco
lSE reoieves the user cenificate from the identity source and compares it, based on each octet, with the
received client cenificate. Client cenificates can be retrieved from Active Directory or LDAP servers.

Apply Certificate Authentication Profile to Identity
Source Sequence
111is topic describes how to apply the certificate authentication profile to an identity source sequence.
Apply Certificate Authentication Profile to

Identity Source Sequence
Select certificate authentication profile in the identity source sequence
Identity source sequence applied to an authentication rule
___....,_.. _ -
""""""'.......
. .. -
---
__.....________
e - - - - liiiiiiii::::::l
...."'
-- -
.
Certificate based authentication is an option that must be enabled in the identity source sequence. When this
option is enabled, you must select a previously defined certificate authentication profile. Tbe job of the
certificate authentication profile is to specify which field in the client identity certificate identifies the
usemame or machine name and whether or not a binary comparison with a copy of [be certificate stored in
AD or LDAP is required. Once this option is set in the identity source sequence, the identity source
sequence is in turn referenced by an authentication rule.
3:·12 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Verify EAP-TLS Operation
This topic describes how to verify the BAP~TLS operation.
Verify EAP-TLS Operation

User and machine authentication displayed separately
Identity shows the principal name
Obtain4)d via th& certificat& authentication profile
Common namG in this example
-- --- --·
0
___ 0 0 0
,.,
....... _.
You can view the successful authentications in Cisco Identity Services Engine under Operations >
Authentications> Show Live Authentications-. 0 ne of the optional cotwnns to display is Authentication
'l?rotocol. the cements of this column can be used to verify the use of EAP·TLS for authentication. 'Jbe
sample output depicted shows two EAP-TLS authentications: one user and one machine. The machine
authentication is performed when rbe user is logged off. The identity displayed in me l dentity column is the
principal name extracted from the certificate as specified by the certificate authentication profile. ln this
example the common name has been extracted from the certificate.

Summary
Summary
In EAP·TLS and PEAP·TLS both sides verify each other using
certificates.
Cisco ISE must have the appropriate C.A root certificate to verify the
client certificates.
In AnyConnect supplicant you can choose EAP· TLS separately for the
user and machine authentication.
Certificate authentication profiles specify the certificate field that should
be used as the principal username.
Certificate authentication profiles are applied to identity source
sequences.
3:· H lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Lesson 21
Authorization
This lesson describes the authorization in Cisco Identity Services Engine. Authorization is performed after
authentication, when the identity of the client is already established. The authorization attribute.~ that are
sent via RADfU~ to the network access devices are first configured in the ISE as authorization profiles. The
authorization policy applies the authorization profiles to the client sessions when appropriate conditions are
met.
.. Describe the authorization in the Cisco Identity Services Engine
• Provide an overview of the authorization policy
• Describe the downloadable ACLs
• Describe the authorization profiles
Describe the authorization policy
• Describe how to build compound conditions
• Describe the authorization configuration procedure
Describe the rule matching logic
• Describe how to configure an authorization profile
• Describe how to configure an authorization policy rule
• Describe how to rune the default authorization rule
• Describe how to verify the authorization in the lSE GUI
• Describe how to verify machine authorization in the ISE GUl
• Describe how to verify the authorization in the lSE GUI
• Describe how to verify the dACL assignment on the authenticator
Authorization in Cisco ISE
Tbis topic describes the authorization in the Cisco Identity Services Engine.
Authorization in Cisco ISE
~
: ,_,
·-·-
~- ~lEI ,_
I - - ,_, --- '1 --:-

~ 11:::- -=:1
1::.. ""=II=-
: IB Bllc;;J ~111..:..11-11-11
Guell-
--- ; -
·····-·········--·····----L-----·----·.J
I """'"'
·- .. ·-·
'
Cisco nSE perfonns authorization to assign privileges to client sessions. Authorization is perfonned after
authentication when the client identity is established. The process flow on the Cisco ISE, as shown above,
splits after authentication is complete. Three separate components-the posture service, the profiler, and the
authoriization- may be involved in these phases. The posture and profiler services can be used in addition to
the autltentication and authorization services and, if deployed, they may invoke additional information
exchange.
3:·16 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Authorization Policy Overview
This topic provides an overview of the authorization policy.
Authorization Policy Overview

•
• -··-
~
'-
. . ......
------·- -
.'
---
- ...
' ~
•
I
~~ I
I
(
- ,, --
""''
- I
II II """"'
1'
...... I
I( ..:r- I >-
1- -1 I(
......,0
fiE' -
,_ I ,..::.,. R. -
I I T- lt -- I
I •~ .
I N<AT '1- -- 1
I
'
....... _.
./
Similar to authentication, the Cisco Identity Services Engine provides a modular approach to setting up the
network authorization policy. The authorization policy is made up of rules. A rule has four components:
• Rule Name: A unque alpha~numeric identifier for the rule. lt is desirable for the rule name to imply the
purpose or the intended context of the rule.
.. Identity Group: Specification of user or endpoint groups from JSE's internal databases. Any is an
option, implying that internal group membership is not significant for this rule. Multiple groups ruay be
specified with a logical OR binding. That is, if multiple groups are specified, membership in any of the
groups will result in a match. Examples of groups that may be defined and used include black lists,
automatically profiled classes (such as Android, Apple·iDevice, or Cisco-lP·Phone), or classifications
defined ·within the enterprise such as print servers or badge readers.
.. Conditions: Specification of contextual requirements for the rule. Simple conditions specify an
attribute selected from an lSE dietionary along with the value of the attributerequired for the condition
to match. Compound conditions Link together multiple simple conditions with logical AND or OR
relationships. Some common examples of attributes lhat can be specified with conditions include
Active Directory group membership, connection type (Ethernet or Wireless . JEEJ;; 802. 11 ), or a
wireless SSID (contained in the RADIUS Called·Station-10 field).
.. Permissions: Specification of the authorization profile. Authorization profiles are defined separately
from the authorization rules. The authorization profile defines an appropriate set ofpermi~sions ba~ed
on a context sensitive match with the identity group and conditions specified by tlle authentication ruJe.
Common aspects defined in the authorization profile include a downloadable .ACb or VLAN
assignment. Sometimes authorization profiles are intended to be temporary. for example the profile
ooutd set up a posture check. After the posture check, depending on lhe results, another authorization
profile would be enforced to either require posture remediation or to grant appropriate network access.

Cisco ns·Eis an attribute-based policy system. Identity groups and conditions are us;ed to define what
attributes are important for making policy decisions. Authorization profiles, as specified in an authorization
rule's permissions, specify the results of the policy decision.
3:-1& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Downloadable ACLs
This topic describes the downloadable ACLs.
Downloadable ACLs
Common method to control network access
Source IP address set to 'any'
Assigned per port or per host depending on 802.1X host mode
Downloaded to NAD once. may be applied to many pons/clients
ISE provides a syntax checker
•-==
---
1..- - a - b....,.
-... .. -- ·----· • -~
a - _...a..o-
.,.. ...---s-LJ
~,;;. ..._ _ _
··-
._..
··--
-~-·-·-u-
-
·..··-··----
-- -··.. --
- - - ---..-.... Q.---------~
··---
.......
--...
_. ·-----
The Cisco Identity Services Engine policies are built from policy elements. Dictionaries, conditions and
results are the three cypes of policy elements. A downloadable ACL is an example of result policy element.
[t is an example of an authorization poJjcy resuJt in particular. 9AC,ks are very common elements used to
restrict client access to nern·ork resources.
The dACLs are configured and maintained centrally on the Cisco ISE and pushed to the NAD whe.n a client
is granted access to the network. The NAD applies the dACL to the client access port in the incoming
direction. The NADwill apply the dACL per port or per host depending on the configured 802.1X host
mode.
The source lP address configured in the downloada'ble ACLs is 'any'. The NAD will replace this stater.nent
with the actual host U' address. A dACL only needs to be downloaded to the NAD once. If the same d!ACL
is specified in subsequent authorizations, it wiU not be re~downloaded. The copy that is already resident on
the NAD will be applied to any other endpoints that use the same dACl.
The lSE provides a syntax checker to avoid user co.nfiguration errors. Cisco ISE is preconfigured with two
default dACLs: DENY_ALL_TRAFfiC and PERMIT_ALL_.!'RAFFIC. These two dACLs, and any
administrator defined d.ACLs, can be referenced by an authorization profile.

Authorization Profile
'J'bis topic describes the authorization profile.c;.
Authorization Profile
Set o f prM ieges and actions
Referenced by name in the authorization policy rule
-- - · -·- , __ -~ ·
---
-- -
& - .. - - . . ..
-......
··--
··-
··--
..;:~~--
··-_
··----
aa r--.a.
··-. .
...
--
·-- iiiiu;-m:=3·•
··--- ·-- ___

·-c---
,.. __ f':!oloo---.0011,-.-
...... -~
.._
Authorization profiles consist of pennissions that are chosen from a set of options. Authorization profiJes
are applied when an authorization rule that references them is matched. 1'be authentication rules use identity
group membership and context specific conditions to define when the authentication rule is applicable. If
the requirements are met, then the authorization profile. referenced by name from the authorization rule, is
applied. Downloadable ACL assignment, VlAN assignment and Voice Domain access are common
exampl es of permissions specified by an authorization profile. But any setting supported by RADfUS on the
device can be defined in the authorization profile.
l-20 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Building Conditions
'J'bis topic describes bow to build compound conditions.
Building Conditions
Simple and compound conditions
Compound conditions combined with either AND or OR
Rich set of options selectable from dictionaries, such as:
Network A.cc$ss:EAPChainingResun E·OUALS user and machine bOth
succoodod
AD1:ExternaiGroups EQUALS sOOut$-x/locaVDomainGroups/IT
---
ts-·---~ .-. - .
•, ... _ _ _ p ) - - ._
--
- - .::§:] '-
-• --""
-Al~ ··b · .!Wll
L-.. ..-.....,_.-..:__
"~-- .=. ""'= •
•tt ·="=---- ·--
Conditions can be defined as part of an authorization policy rule or they can be defined as a policy element,
added to the library, and then be referenced by one or more authorization policy rules.
Simple conditions specify an attribute from one of the Cisco Identity Services Engine dictionaries, an
operand, and a value. Compound conditions combine multiple conditions with either a logical AND or OR.
There is a robust se[ of attribute options available across the various Cisco ISE dictionaries. Among the
many options, attributes can specir; details such as Active Directory group membership, authentication
results~ netv.•ork access device characteristics, identity certificate derails, profiling results, and posture
status.
~22 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Authorization Configuration Procedure
This topic describes the authorization configuration procedure.
Authorization Configuration Procedure

1 Configure rul&-matching logic
2. Configure policy elements.• such as dACL (situational)
3. Configure authorization profile (pennissions)
4. Configure authorization conditions
5. Configure authorization rule
___ ___ --·· -- .....-_ _.. _

--
6. Tune defautt authorization rule (optional)
... .., ..
·-
-.- -- -- ........-._
~--
-
....... _.
follow this procedure to implement authorization on lhe Cisco ldentity Services Engine:
I . Configure rule·matching logic (optional)
2. Configure policy element, such as dACL (situational)
3. Configure autbori2ation profile (pennissions)
4. Configure aurbori2:ation conditions
5. Configure authorization rule
6. Tune default authorization rule (optional)

Configure Rule Matching Logic
'J'bis topic describes the rule matching logic.
Configure Rule Matching Logic

Default rule-matching method is to apply only first match
Alternative option is to apply all matched rules
Muffip!o authorization protir&s are oombin.ed
FirSt rule tak&S pr&O&denoo for permissions Of the samo type
...._,._,
---
. . _ ... -·- - -- ......
_.--',Ot_.(,:_ffi-:_~::---~.::-!:_~=::!1¢J
.. -
-• ··- ------......., -•
.. - r
• a ·l't=-
...,
;~~-
"""
LJ£1- ..
·~· -
Tbe authorization policy consists of one or more rules that are processed in order.
You can define the processing logic of the authorization policy by choosing one of two options:
First Matc.b Rule Applies: With this option, the Cisco Identity Services Engine applies the
au.thorization profile that is referenced by the first matched rule and finis hes the authorization
processing for the given client. This option is the default behavior.
Multiple Matched Rule Applies: In this method, rbe Cisco ISE continues processing each rule until
all rules have been applied. When multiple matching authorization policies are found, Cisco IS£
combines the authorization profiles. The authorizatio,n profiles of all matched rules are combined and
applied to the client. The flrst rule takes precedence for pennissions of the same type.
Typically the processing logic is set before any authorizal!ion rules are defined.. The rules are designed to
operate according to the processing logic. Changing the processing logic after a set of rules are designed
and im.plemented can lead to undesirable results.
~2<4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Configure Authorization Profile
This topic describes how to configure an authorization profile.
Configure Authorization Profile

Most common attributes enabled with check boxes
---
o/0_ , ....... 4-. a-.. .,..,..._ ~o;.--- ·--
Custom AVs configurable in the Advanced Attributes Settings
- .. ---- - ·-
.:::::. .. =
··-
• · II •
··--
·- - -- --,- ~
~~]
..
··---
··-
··-
··--
··-- ·-- !WI
,_
_... ....----
••
... { ·~ ~· ·
....... _.
Authorization profiJes combine multipte policy elements into a set that can be applied to clients. Cisco
(dentity Services Engine comes preconfigured with several default authorization profiles, such as
Blacklist_Access, Cisco_lP_Phones, DenyAccess, and PermitAocess. You can edit these built-in profiles,
but it is not recommended. ln practice, you \\'ill need more granularity. Therefore you need to create custom
authorization profiles. A preconfigured authorization profile may be duplicated to be used as the starting
point for the creation of custom authorization profiles.
AJthough not sh0\\'11 above in its entirety, authorization profiles allow you to configure these elements using
appropriate check boxes:
.. dACL Name: Tbis element is the name of the dACL, which is obtained from the Cisco JS'E and
applied to the session. The dACL will be applied per user for ports configured in Multi-Auth mode.
The dACL is downloaded once per NAD, but can be applied to the session.
• WLC ACL! The ACL applied to the endpoint on the WLC. Currently the name of the ACL gets
pushed by the ISE.
.. VLAN: This element is the VLAN that is assigned to the access port as the access VLAN.
.. Voice Domain: In multidomain authorization mode, if the network switch receives this parametel', the
endpoint is placed into the voice domain. This type of authorization is most common for Cisco II"
phones.
.. l,o.sture Discovery: This element is used to enable posture discovery of the endpoint
.. Auto Smartport: Cisco Auto Smartport technology enables appropriate~ parameters to be applied
to the port according to a template.
• Filter ID: The filter fD is an ACL name that is referenced by the Cisco ISE. The ACL must exist on
the NAD and is applied to the client session as a resuJt of the IS£ authorization instructions.
Re.authentication: This element enables reauthentication of the endpoint.

MACsec Policy: MACsec is d>e IEEE 802.IAE stan<lard for authenticating and encrypting packets
between two adjacent devices. Many Cisco Catalyst switches support 802.1AE encryption with ~KA
on downlink ports for encryption berween the switch and host devices.
NEAT: The N"£AT feature allows 802.1X implementation on a switch which is deployed in a non~
secured location, such as a conference room, with an upstream connection to a physically secured
sv..i tch. 'The downstream switch acts as the supplicant switch and the upstream switch acts as the
au.dlenticator switch. The ClSP is used to by the do\'\'llStream switch to identify aU authenticated
802.1X hosts to tlle upstream switch.
Centralized Web Autbentkation: This element enables web authentication to be performed on Cisco
l SE.
Local \\'ebAutb: Tbis value instructs the NAD to perform the authentication locaiJy on the NAD.
Cisco !SE sends the NAD a Y.1.1 along with a dACL.
ASA VPN: This parameter enables an ASA VPN group policy to be applied to the endpoint VPN
session.
In addition to these common attributes you can define custom AVs usins the Advanced Attributes Settings
section. All AVs, the common ones and the custom ones are displayed in the Attributes Details section.
~26 lmplemen~ng Cisco Security Access Sei\Jtlons -0 2014 asco Sy&ems, l nc.
Configure Authorization Policy Rule
This topic describes how to configure an authorization policy rule.
Configure Authorization Policy Rule

c ·-
---
~----
--
...
---
-
.. . . " ••••
- ..
- "'
;:-;::~
·- ~ . ... ...__
..... •
:.1
_
---- ·- .
•••• ...
·---
.
··-
·- ··- ·-----
l r--~
·--~.Q-:; ·---
-- ·--- - ·-----t
-
....
J
-
I' •
•
• ·1='- I
·- -l .
_;~~):- ··~-£
• ·-
? ,.
.... t!J' ...-='!!------~
••
·-·--
·---·- .. . •· ---
•· ... ~· . ~·
·- - • ~-
~-
0 ...... _ .
The authorization policy consists of one or more authorization policy rules. Each rule has a name, specifies
one or more conditions, and a permission setting that points to an authorization profile. The rows visible in
the l,olicy > Authorization menu represent tlle individual rules. You can drag and drop the rules to change.
the sequence. You can create new rules, duplicate and delete the existing rules wing the Edit button. ·.Th.is
figure illustrates the options of clicking various fieIds in the Cisco Identity Services Engine GUI to open the
appropriate attribute dictionaries, and select the appropriate values.

Tune Default Authorization Rule
'J'bis topic describes bow to tune the default authorization rule.
Tune Default Authorization Rule

ISE comes preconfigured with a single default authorization rule
Default action is PermitAccess
-
Change to DenyAccess for faik:lose approach
- -- ----- ---
-·-
••••
...,,....
•
=- ;;; =-=-- -
----
I
--_,..,.-
~~--- t
-
I
• --
I
• ---
~-
- --- -- •· - -
·-·- -
..:.•
•
a -"
Tbe defauh rule is the final rule in the authorization policy that is used to define the handling of all client
access requests that do not match any explicit authorization rule. Typically, you will rune the default rule,
becau~ its preconfigured action is set to PennitAocess, w hich activates a fail·open logic. Tbis default will
lead to less service disruptions during early phases of deployment, but it is not recommended in most
enterprise scenarios.
This example shows how to rune Ute default authorization rule. You click the plus symbol near the
l'errnitAccess action, which is the default acrjon within the default authorization rule. You are presented
with three pennission categories: lnline Posture Node, Security Group, and Standard. You select the
Standard category and choose your desired authorization profile.
l-2& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Verify User Authorization on ISE
This topic describes how to verify user authorization in the Cisco Identity Services E:ngine GUl.
Verify User Authorization on ISE
- -- - . -- .
--= - --- ··-
4 ~- ....
--
---· ~·
•
r-a----·-·•-
·--=
•
:-..
•
- -.... ,_
'
'· -~ ll ~- .- - j ..
• •
.: A
L -.---~
:::J-......
.......
•
_
f-.;,;,.''--
l· -
~~ .....
-- --
-~
••
-
·--
_ - . . : _ _ _ _ _ . .O..i
....... _. - '(UO)'t. .)
--~
~~-
The Cisco JSE dashboard provides a summary of ai!J authentications that take place in your netv.-·ork in the
Operations> Authentication menu. If you activate the Authorization Profiles column you will see the
autl1orization profile that has been applied to tl1e endpoint.
The top figure depicts the authentication and authorization results ofuser it I accessing from a corporate
asset. You can recognize the EAP chaining use case by the>> sign between the user and machine identity.
Consequently an appropriate authorization profile has been pushed to the session.
You can drill down into an authentication event and examine the RADfUS authentication delaits. Tbe
bottom figure illustrates a fragment of the detailed information. The Use Case is reported as EAP Chaining
with the EAJ> chaining result of 'User and mac-hine 'both succeeded."

Verify Machine Authorization on ISE
'J'bis topic describes bow to verify machine authorization in the Cisco Identity Service.c; Engine GUL
Verify Machine Authorization on ISE
-- ... __
___
·· .;....:...
...
-o---•--·. . ---• -·-• ~
• -•
.. -- - ·-
~--· •-
..... --- --
- ..-.~-. - -~ - ""
-·-·· . -·- --·-·

J---·
-~····
...
--- --
~~--
-- - ;:::::::
- ---
_NC_ _ _ _ ......_,
•l - JIQ
Tbis figure shows an access attempt of the Employee~ PC computer, when no user is logged on. The
Employee·PC is a corporate-owned asset and for this particular access attempt the authorization profile
Machine_Cotp is applied. rhe bottom figure shows the de[ails, where the Use Case is reported ali EAP
Chaining with !he EAP chaining result of "User failed and machine succeeded."
3:.3() lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Verify Authorization on Switch
This topic describes how to verify the authorization status on the authenticator.
Verify Authorization on Switch

tiO-sw; •~ow •~th.nti~• ~ion. ...,io~• in~~~·~ qj~i~th•~•~ 0/1
I:>t.etf4c:e: G1911.t>~tttl\~ tile~ 0/1
IQ.e M.d t~U ; ..~36 . 9!l.t . Jbbl
tP '-"..d"t~:U: 1~ . : 0.9 . 11
t.111C't-~:
~:;eo~ee·~
Sto.t us: iiYt «'"-'
llcfl:ltn: !:~.'!').
S.eu:~ty Policy: Sl'.culd SetC'U:'II
seeuray Stotu5: IJr.,ecure
O;lo:!: llo•t mdo:!; 171.1.ltl-~.O.$t
epce.r contto-l <lilt: l>o<h
>.utb~t!.ll<t~ By: Allthol'lt1e:u.1cn SGlt\'Olt
Vb:> Polic:y; '$/h
A":S hCi..: ~l!- • FtliiZikm'" ''~ll;atte••er pS?.L.! ec:)
StJtion ttr.oout : N/lt
!dta t1fl4<1~t ; ~II<
cor.mon ~""ic:n. 10: OAOAO li>20C 30180$4 SSru:.~2 S
Acc:t &\'~don. ;:o: ~xOOC{IUSA
I!ArA.:II: OxUCO~Bt£.
~~n~lo ~~hod~ list:
¥At.lle>a. Se4t.('
<ioclx /t.utb~ suc:eess
. ...... _ .
You may monitor the authentication and authorization results on the NADs in addition to viewing them on
the Cisco Identity Services Engine. Tbe output of the sbow authentication session interface command
includes tlte usemante of the authenticated user and the authorization results. The status of session reports
Authorization Succe.c;s, and a dACL is applied to the endpoint. The NAD is not aware of the authorization
profile name that bas been used on the Cisco ISE tn apply this ACL to the endpoint. It does, however,
receive the name of the d.ACL as defined by ISE. The command output displays also the common session
ID that is used for tracking a specific user session.

Verify dACL Assignment on Switch
'J'bis topic describes bow to verify the d.ACL assignment on the authenticator.
Verify dACL Assignment on Switch

. Downloadable ACLs are the most common authorization .
. Other attributes, such as VLANs, can be verified with other commands .
,
!!Q-Svt •how 1p aee.• •-li_.u
&J(:t!r>d<td l? 1ltC<!$1J l u t xACSACl.l(·tP..ta.p1oyo:e_.tl.eotdceeci_&M:i.-Sl?lh:e3 lfl(!r-
u.oe: I
:o ~!ly !enp ;tny lion 10. 10. 2 . 20
20 l!o:'l)f lCtsp ;tny lion 10. 10. 3 . 20
30 lien;,. tey ~ny ho4:: 10.10 .3.1¢ eq ..-....
, ~0 pe~i t i p any o~y
!!Q•Svt t bow 1p IICC.II•lLitl Lnt.r!.c• gLg&b1~thern.t 0/l

<!er.V lCr'fl) IL1Y llOJt 10. 10.2.20
~~y iem> OJ\}' 'nO$t 10.)0,3,20
®ny u:p an.y !lest 10. 10. J . 2tl oq 'IIVtt
pctm.!t !p Mly ar.y •20 l'f;ttci'.OJI)
·-~
You can verify the dACL download and contents as it will dynamically appear amongst the 11' access-Lists
present on the switch. Note that the show ip access-lists command annotates the d.ACL with "per user." If
this dACL is assigned to multiple user sessions, it only needs to be downloaded once from Cisco Identity
Services Engine. You can funher verify the actual access list that has been applied to the access port. 'J'be
output of the sbow ip ac.cess-list interfac.e command displays the actual authorization results.
~2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.

Summary
Summary
Cisco ISE performs authorization to assign privileges to client
sessions.
Authorization is performed after authentication when the client identity
is established.
Downloadable ACLs are very common authorization policy elements.
Autholization profiie is a set of privileges and actions applied to a d ient
session.
Cisco ISE authorization policy rules match conditions and apply
authorization profiles .
. ...... _

3:-3.4 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Lesson 31
Cisco TrustSec and MACsec

Cisco TrustSec simplifies tlle provisioning and management of secure access to network services and
applications. Compared to access control mechanisms that are based on network topology, Cisco TrustSec
defines policies using logical policy groupings, so secure access is consistently maintained even as
resources are moved in mobile and virtualized networks. De~coupling access entitlements from 11' address~
and VLANs simplifies security policy maintenance lasks, Jowers operational costs, and allows common
access policies to be applied to wired, wireless, and ,vv-~ access consistently.
MAC~ec is the lJ1.EE 802.1 AE standard for authenticating and encrypting packets between two MACsec·
capable devices. Cisco switches suppon MACsec o:n do\\rnlink and switch ~to-switch ports. Cisco
AnyConnect provides MACsec capabilities via software for systems with N1Cs that do not have MACsec
hardware support.
Upon completing this lesson. you will be able to meet these objectives:
.. Provide an overview of Cisco TrustSec
.. Describe the benefits of the Cisco TrustSec solution
.. Describe the classification ar the ingress
• Describe the inline SGT transport
• Describe the SGT Exchange Protocol
.. Describe the enforcement on SGT~capab l e devices
.. Describe the enforcement on SGT~aware devices
• Describe the SGA deployment procedure
.. Describe how to configure CTS between ISE and a network device
.. Describe how to define the security groups
Describe how to implement dynamic classification
.. Describe how to implement static classification
• Describe bow to implement the SGT Exchange Protocol (SXI')
• Describe how to define SGACLs
Describe how to implement SGACL enforcement
• Describe how to implement SGFW Enforcement on the ASA
Describe d>e MAC Security (MACsec)
Describe tlle MACsec cryptographic features
Describe the MACsec hop~by ~bop operation
• Describe the downlink MACsec implementation on the lSE
Describe the downlink MACsec implementation on the NAM
Describe the downlink MACsec implementation on the switch
Describe how to verify downlink MACsec
3:-36 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Cisco TrustSec Overview
This topic provides an overview of the Cisco TrustSec solution.
Cisco TrustSec Overview

§§Is:
Classification: SGT iS assigned at ingress, dynamic or static
Tf ansport: SGT is propagatoo via ini nQ tagging or SXP
Enforc&mon t: Policy is applied via SGACL or SGFW
MACsec
- --
Enforcement: Policy is applied via SGACL or SGFW
Cisco TrustSec incorporates SGTs and MACsec.

Cisco TrustSec classification, transport and policy enforcement functions are embedded in Cisco switching,
routing, wireless LAN. and firewall products. By dassifying traffic ba.~ed on the contextual identity of the
endpoint versus its fp address, Cisco TrustSec enables more flexible access controls for dynamic
networking environments and data centers. The features associated with SGTs on the nem·ork devices: can
be broken into three categories: Classification, Transport and Enforcement.
• Classification: Classification is the assignment of SGT to an IP address.. This can be accomplished
either dynamically or statically. Generally, dynamic classification is done at the access layer and static
classification is done in the data center. Dynamic classification utilizes the rich context data available
to Cisco Identity Services Engine for making policy decisions. Dynamic classification can be done
using 802.1X, MAC Authentication Bypass or Web Authentication. Static classification is generally
configured on !he switch to which servers are attached. Options for static classification include !h.e
mapping of !P address, VlAN or por< to an SGT.
• Transport: Security group mappings follow the traffic through the network. This can be accomplished
either through inline tagging or the SGT eXchange Protocol (SXP). With inline tagging, the SGT is
imbedded in the Ethernet frame header. Not all network devices support inllne tagging. SXP is us:ed to
transport SGT mappings across devices dlat do not support inline tagging.
• Enforcement: Enforcement is implementing a pennit or deny policy decision based on the source and
destination SGTs. This can be accomplished with SGACLs on switching platforms and SGFW on
routing and firewall platforms.

MACsec provides secure communication on wired LANs. When MACsec is used to secure the
communication between endpoints on a LAN, each packet on the wire is encrypted using symmetric key
cryptography so that communication cannot be monitored or altered on the wire. When MACsec is used in
conjunction with Security Group Tags, it provides protecli:ion for the tag along with the data contained in the
payload of the frame.
Suppor[ for Cisco TrustSec features varies by netvlOrk device platfonn and software version. It is important
to understand the capabilities of the devices available in the network early in the TrustSec solution design
phase.
3:-3& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Cisco TrustSec Benefits
This topic describes the benefits of the Cisco TrustSec solution.
Cisco TrustSec Benefits

Flexible. Access control is independent of:
LocatiOn: Physical or Logical
Accass m~thod : Wired, wireless Or VPN
Efficient administration:
Simplified tx:~li<:y definitiOn
Simplifi&d poliCy maintenance
TrustSec
....... _.
At the point of network access, a Cisco TrustSec policy group called a SGT is assigned to an endpoint. This
is done considering any of a rich set of attributes in~luding that endpoint's user, device cype, posture s.tarus,
and location attributes. 'The SGT denotes the endpoint's access entitlements, and all traffic from the
endpoint will carry the SGT information. The SGT is used by switches, routers, and firewalls to make
fonvarding decisions. Becawe SGT assignments can denote business roles and functions, Cisco TrustSec
controls can be defined in tenns of business needs and not underlying networking detaiL SGTs can span
physical locations. SGTs are independent of fp add:ress, subnet or VLAN. SGACL capable switches c.an
implement access controls between systems with the same or different SGT values even if they are on the
same VLAN.
lnstead of managing access control on large numbe.rs of prefJ.Xed IP addresses, access control is managed
across a relatively smaJI nwnber of relevant security group classifications. SGACLs deftne what services
are accessible between two security groups. A simple matrix assigns all SGACLs to source and destination
SGT pairs. One matrix provides all policy tor d>e entire TrustSec domain.

When compared to craditional access control policy that is implemented with static ACLs deployed at
strategic policy enforcement points, TrustSec offers much simpler maintenance procedures. Traditional
ACLs lend to have repetitive enrries that cover different source and destination 11' addresses. For example,
there may be repetitive entries that specify the same sef\'iJces for each subnet serviced by the campus
wireless network to each corporate web server [p address_ When a new wireless subnet is provisioned or a
new web server is brought online, all of the associated ACLs must be updated. ln large enterprise
environments, these ACLs can be thousands of lines long and very complex. The figure above denotes
severaHother common examples of network growth that would require substantial ACL revisions in a
craditional implemenration. Similar changes are necessary when aspect.li of a network are decommissioned
such as when a server is retired or a branch office is consolidated. 'fhese events are much simpler ro
administer in a TrustSec solution. With a TrustSec implementation, the newly provisioned resource simply
needs to have classification configured at ingress to properly maintain existing SGACL policy. ln the event
of an implementation that requires the introduction of a new security group, then a new row and column
will be added to the mauix. Tbis matrix is; updated centrally on Cisco Identity Services Engine and
dynamically propagated across the TrustSec domain.
SGT Classification
This topic describes the classification at ingress.
SGT Classification
Dynamic:
802.1X
MAC Authe-ntieatiOO Bypass
Web Authentication
Static mappings, such as:
IP host or suboet to SGT
VLANtoSGT
- -141llc f . .. ,, _
....... _.
The frames that enter the Cisco TrustSec domain are marked wing a unique 16~bit tag mat represents the
unique role of the traffic source in the network. The tag can be thought of as a privilege idenrifier oftbe
source user, device, or entity. The tagging decisions can either be dynamic. that is obtained from the Cisco
J:dentity Services Engine for each client that attempls to access the network, or static.
Dynamic tagging can be deployed in combination with 802.1X authentication, MAB authentication Bypass,
or Web authentication. In these access methods, che Cisco JSE can push a SGT to dle NAQ_ to be inserted
into the client traffic. The SGT is applied as a pennission in the authorization policy rules. This perm.i:ssion
can be assigned in addition to or instead of an authorization profile.
Static tagging can be configured on the NAD or on the ISE and then downloaded to the NAD. Examples of
static tagging include a mapping of an IP host or su.bnet to a SGT, or the mapping of a VLAN to a SGT.
Numerous other options exist, with varying support depending on the device platfonns and software
versions.
Because che SGT contains the security group of the: source, dle tag can be referred to as the source SGT.
The destination device is also assigned to a security group (the destination SG) that can be referred to for
simplicity as the DGT, although the actual Cisco TrustSec packet tag does not contain the security group
number of the destination device.

lnline SGT Transport
'J'bis topic describes the inline SGT transport.
lnline SGT Transport

SGT carried in Cisco TrustSec Meta Data header.
SGT field is 16 btts. providing 64K tag space.
MACsec implements IEEE 802.1AE,Iink4evel encryption and
authentication.
MACsec and Meta Data are compatible.
SGTs can be transported inline between two capable devices configured for Cisco TrustSec on their
connecting interfaces. Using this method, the sending device will impose the SGT in the outgoing frame's
Ethernet header on egress. the receiving device will read and process the SGT from the Edlemet header on
ingress.
The SGT is imbedded in the Cisco TrustSec Meta Data header. As with other tagging protoools, such as
802.1Q, Me<a Oa<a uses a registered elhercype value. Meta Da<a uses elhertype Ox8909. The SGT is carried
in a 16 bit field in the Meta Data header. There is about 2() bytes of overhead due to the use of the Meta
Data header.
Frames crossing a link between capable switches may also be protected with MACsec. MACsec is an
implementation of802.1AE, and il< header is marked with the ethertype Ox88E5. A MACsec protected
frame will put the other tags and the data contained within the fame between the MACsec header and the
!_CY field. These lags and !he frame data are all protected by MAC~ec encryption and aulhentication. The
increase of the MTU size that results from both 802.1AE and Cisco TrustSec overhead is roug)lly 40 bytes.
The figure illustrates the MACsec overview with !he embedded Me<a Data header cartying !he SGT.
3~2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

SGT Exchange Protocol
This topic describes the SGT Exchange Protocol.
SGT Exchange Protocol

Communicates IP ·to~SGT mappings "out of band" of IP packet
Used to propagate SGT across devices that are not inline capable
Unidirectional, speaker transmits to listener via TCP/64999
Configured on a per· peer connection basis
....... _.
Not all Cisco devices are capable of inllne SGT transport, nor are network devices from other vendors.
SXP, a control plane protocol, allows the propagation of 0, to SGT mappings across such boundaries. The
main goal is to get the SGT data from the devices tl!lat perfom1ed classification of connecting endpoinJts to
upstream devices which will perfonn Cisco TrustSec enforcement based on SGT information.
The SXP connections are point-to--point and use TCP as the underlying transport protocol, using TCP port
number 64999 when initiating a ooMection. When configuring an SXP connection to an SXP peer, you
must designate each device as a Speaker or a Listener for that connection. The Speaker mode aUO\\'S the
device to forward all active IP to SGT mappings to upstream devices fo r policy enforcement The Listener
mode enables a device to receive lP to SGT mappings from downstream devices and use that information in
perfonning policy decisions.
[f one end of an SXP connection is configured as Speaker, then me other end must be configured as a
Listener, and vice versa. If both devices on eacb end of an SX!' coMection are configured with ~1e same
role (either both as Speakers or both as Listeners). the SXP connection will fail. Care must be taken when
configuring SXJ, coMections to avoid creating loops. unless SXP version 4 or above is deployed. SXP is an
evolving protocol. lt is important to understand and consider SXP version support on the devices in your
network during the Cisco TrustSec solution design. ·nle following summarizes the capabilities of SXP
versions I through 4:
• Version I: Initial version. Supports lPv4 binding propagation.
• Version 2: Added~ binding propagation and version negotiation.
• Version 3: Added support for Subnet to SGT bindings. If speaking to a lower version listener, the
speaker will expand the subnet.
Version 4: Adds loop detection and prevention, capability exchange and a bu.ilt~ in keep--alive.
mechanism.

Enf orcement Using SGACLs
'J'bis topic describes Cisco TrustSec enforcement with SGACLs.
Enforcement Using SGACLs

- --· _.,
Using SGACLs, you can control access policies based on source and destination security gr-oup tags. Policy
enforcement within the Ci..1ico TrustSec domain is represented by a permissions matrix, with source security
group numbers on one axis and destination security group numbers on the other axis. Each cell in the body
of the matrix can contain an ordered list ofSGACLs. Each SGACL specifies the pennissions that should be
applied to packets originating from the source security group and destined for the destination security
group. lt is important to note that the source and destinations are specified in the policy matrix and not in
the SG ACL. Take, for example, the SGACL entry: deny tcp dst eq 21. The entry specifies access from the
source to the destination's TCP port 21 is denied. ·neir is no specification of the source or destination group
tags in the SGACL.lt is the application of the SGACL in the pennilisions matrix that specifies the source
and destination security groups. h is also imponant to understand that the same SGACL can be applied to
multiple source and destination security group pairs within the permissions mauix.
Sy applying access control between pairs of security groups, Cisco TrustSec achieves role-based, topology-
independent access control within the network. Changes in network topology do not nonnally require a
change in the SGACL~based security policy. Some care must be taken to insure the proper classification of
new network resources, but the access policy based on bu:siness relevant security groups does not change. lf
the changes do require the c-reation of a new security group, then the pennissions matrix will increase in
size by one row and one oolwnn. Policy for the new cells is defined cenrrally in Cisco Identity Services
Engine and dynamically deployed to all SGACL enforcement points.
Using role·based permissions greatly reduces the size of ACLs and simplifies their maintenance. With
Cisco irrustSec, the number of ACEs configured is detennined by the number of permissions specified,
resulting in a much smaller number of ACEs than in a traditionallP network. Also, only a single oopy of an
SGACL needs to reside in the TCAM of a device, regard~ess of how many times the SGACL is used. The
use ofSGACLs in Cisco TrustSec typically results in a more efficient use ofTCAM resources compared
with traditional ACls.
3:~<11 lmplemen~ng Cisco Security Access Sot\Jtlons -0 2014 asco Sy&ems,lnc.

Enforcement Using SGFW
This topic describes the enforcement with SGFW.
Enforcement Using SGFW
-
__
_--
__
- -
,,4'll_"
_,_,__ -- -
-
lllllt-
·
- -- - -
•• •' ·-
•• ·- •· n ...
.. ·-
. ...... _.
[nstead of SGACLs, the Cisco Adaptive Security Appliance and select routing platfonns enforce TrustSec
policy using SGFW features. Where SGACL policy is centrally managed from Cisco Identity Services
Engine, SGFW policy is managed independently on the device configurations. SGFW capabilities were
integrated into the ASA rule policy in version 9.0 and into the lOS Zone Based Firewall feature in version
15.2. The figure depicts utilizing security group data in an access control entry on the ASA, both from
ASDM and from the .9:-1· ln lOS Zone-Based Firewall, match security group statements can be used in
class-map definitions. In both cases, security group information can be used in conjunction with other
traffic specification mechanisms, such as source and destination IP address, protocol and port nwnbers. One
compelling use case on the ASA is to use security group information to define traffic that should be sent to
which virtuallPS sensor re.c;ident in the ASA for appropriate deep packet inspection.
ASA's security policy is configured with ACLs. You can create ACLs on the ASA that contain SGTs or
security group names. The ASA will enforce policies based on security group names or SGTs, if the ASA
has a security group table to map security group names to Sms, and an SGT-to-11' mapping exists.

SGA Deployment Procedure
'lllis topic describes the .l)y..D_ deployment procedure.
SGA Deployment Procedure

1. Configure Cisco Trustsec between the ISE and network devices.
2. Define security groups and SGACLs.
3. Implement dynamic classffication.
4. Configure SGT transport.
5. Implement static classification.
6. Implement SGACL enforcement.
7. Implement SGFW enforcement.
-
Tbis procedure describes the key steps in deploying the SGA solution:
1. Configure Cisco TrustSec between Cisco Identity Services Engine and network devices
2. Define security groups and SGACLs
3. Implement dynamic classification
4. Implement static classification
5. Configure SGT transport
6. Implement SGACL enforcement
7. Implement SGFW enforcement
3:~6 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Configure CTS Between ISE and NAD
This topic describes how to configure Cisco TrustSec bet\\•een the Cisco ldentity Services Engine and. a
network device.
Configure CTS Between ISE and NAD

rold~ta liO:t\·<a~ !SS·AAC!OS
o.d.clree-11 lSW•1 t(),l¢,2,2() llUt.ll-pott Hll2 ll«'t-port 1811
, Pile; k.:oy re-diu.,·\ey
,u..a ol\H.bO : t1.11Ul'ln :'\Ct...,ork <:tli-II'J!.b<:l'·!t.llt 9':"0'.1"1) tll.dttll

<:>:.11 ll~tlloti'llltl.<Of'l Hat <:tll · olutl'..er- l!llt
t
<:ttl C:t"e:i('r,t~elll ld I:Q•S.'.C f»SIIV;)td .......
ao-sw• aheto c.u p.ea
AiD : o7s~eo l6!)?ron;O.S691!1n2 9Sl981J.Gl'
PAC-:ofo:
PJ&- t~ "' Ci!I~O ~r<!JUt.l!.
.\!0: 078rtS£36B37fOr£05S9S0£29S39SSC?
t-10: l!O·Sif
A- >D-int'o: Id e,,tity Se:..·ic:etl &nc;i:u~
f>AC·Op.t.;".IC : OC02 ....
'
fi0-Swt llhOV c:t• ..,W-f.I'Qr.-nt.~t-a
Cl'S tll'-' iton~r>t t:ou
--~~-.-
currc..''lt.
.......·~·------
.s~t.c .. ceta>:21"£
LO$t liiUitU<I:I ,. SU<:«!$Iilft.:l
<output emitted.>
...............
-
Cisco TrustSec utilizes policies configured centrally on ISE. As such, Cisco TrustSec communication must
be enabled between JSE and the network devices.
l.n ISS, IDis is defined in the iN AD configuration under Administration> Network Resourc.es >Network
IDevices. The NAD configuration includes a sectiotl named Advanced TrustSec Settings which must be
enabled. The password used between lSE and the d.evice is configured here. Optionally, update timers, can
be modified for this device. Some devices support Ci..lico TrustSec updates via .QQD. messages. Most devices
do not. Those devices must periodically request updates from ISE. By defauJt, the update intervals are set to
I day.
The figure shows the configuration of Cisco TrustS..c on the switch. Tllls is done by specifying the PAG
keyword in the RAD(l!_~ server definition, implementing a Cisco TrustSec authorization list and speci fYing
the Cisco TNStS~ Jl) and password.
Once both sides are properly configured, the device will remeve a PAC file from the ISE. The PAC "~II be
used to secure Cilico TrustSec transactions carried out with RADIUS between the device and lSE. The
device will then download the Cisco TrustSec environment data from ISE. ·ne Cisco TrustSec envirO'.nment
data is a collection of information and policies that assists a device to function in the Cisco TrustSec
domain.

Define Security Groups
'J'bis topic describes bow to define the security groups.
Define Security Groups

.- --
Iii---
--- .-_
l'v. ..,.__ ~·~ ~-
-
,._
-- --
,___.
....
___ -· ·-·-
~-- ~--
~
'
-
'',;. ;:- ·-:r
--·~ ~
- ··
--
~
.·:- --·..
··-
··--
' *-
··---
··--"
· ·-· ·~-
·---"·
· ·~-
IIC- Sv t e.hov
C7S
~~ •=j ~~~dn•
envtror~nt ~t~
---
Seeu~ity G~oup ~ne ~oble:
;:,~:r
::! •: - ..."11:::'~
<o1.1t put o1u t. t~d>
-. ~
A security group is a grouping of network connected dev[ces that share access control policies. New
security groups are defined by the administrator in Cisco ldentity Services Engine by name with an optional
description. The pad>in ISE is Policy> Polley Elements> Results, Security Group Access> Security
Groups. JSE will automatically assign a 16 bit number to the security group tag. This number is unique
across ·the Cisco TrustSec domain.
As a result of the Cisco TrustSec environment data do\'\'llload, the network devices obtain the security group
table. The security group table maps SGTs to security group names. Security group names are created on
the ISE and provide user-frie ndly names for security groups.
Assign.ment of security group tags to devices connecting to the network happens either dynamically or
staticaUly. Dynamjc classification will happen during the authorization process of802.1X, MAB or Web
Authentication. Static classification is defined within the .configuration on a network device. Once a
secwity group tag is assigned to a network connected device, lhe tag infonnation will follow traffic from
tllat device through the Cisco TrustSec domain.
3~& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Implement Dynamic Classification
This topic describes how to implement dynamic classification.
Implement Dynamic Classification

- .........-----
Aoih
-·
-. ..-- __ .... _ .. _. _____
- .
01.,_ ...."ll'fi)014J'
• """" (rr
~~ [
I
~---......-
•---
·--
_
--·-
-
___
...--. ..__ =b
__,
--~-
~ket oo ki-).UtlCIO)
tliHS"• ehoor 111\lt~nt-i~t.ior. •"•io11• i nt.rf •la qi'J"b l..~t.heno•t- 0/1

t:<~torfAC'fl ; Ct(J,tb!t.!tbfltMt"=C/ 1
~ M.dru~ : •035. 'Hl.t. lbbl
tP A:id:'e$5: 10. 10 . 10. 10
1;~u~r-1-'4ne:
l!t;lt\llll "'
l.llthJ: SliC:CfiU
... DoN!-I'l ;
v lon f'l:)lic:y :
tM>.
10
A~ ACt.: XAC~l.x-IP"-tnployoo._f\:ll.Acc.u_OACl.-S2777e~l
_.
~,.,.. ,,
<;OUtP'Jt <mitUtCI'
.......
Cisco Tru.'itSec access control is implemented using ingress tagging and egress enforcement. At the ingress
point to the Cisco Tru.'itSec domain. traffic from the sowce is tagged with an SGT containing the security
group number of the source entity.
\Vith dynamic classification, security groups are dynamically assigned to the clients as a pemllssion within
the Cisco Identity Services Engine authorization policy rule, as shown in the figure. Authorization policy
rules can be applied as a resulc of 8-02.1X, MAB or Web Authentication. After the dynamic authentication
and authorization process is complete, you can veri:fy the SGT assignment in the authentication status on the
network device using commands such as show autbentic.ation sessions or show cts role-based sgt ~ma p.

Implement Static Classification
'J'bis topic describes bow to implement static classification.
Implement Static Classification

cts role-based sgt-map 172.16.1.50 sgt 4
nc-svt _,.ov
Ae~tY*
---..--..--..
.::~
t~-sc~ Si~dino~
,..
:roh- IHMd •'lt.-p 1"'2 , 16, 1 ,$0
t~!¢t~at1on
•--------
!I' M.tre.u Sourc.:t
112,l0.1.50 c..
cts role-based sgt-map vlan-list 3 sgt 4

l!.(l·Svf t llow ou tol•·~t•d tg~·Np lO. lC. 3 . 20
Ac::~i·.·co H'·SG!' &J.ndin<;ll t,1fOt:nOU<:n
11' ltddren SGT Source
----..~·---·~----~~-·------
10. 10. 3 . 20
• vu.•......-......
·-~
While there are other applications, static classification is generally used to define the SGTs for servers in
the data center. Staric classificarion is generally defined o.n the switch to which the server is directly
attached. Options for static assignment depend on the network device platfom1 and software version.
Option..~; can include mapping individual fp addresse.~;, subnets, VLANs, layer 2 interfaces or layer 3
interfaces to an SGT. Using the Nexus lOOOV in a virtualized environment, SGTs can be defined in port
profiles which are assigned to .Y,Ms during the provisioning process.
~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.

Implement SGT Transport
This topic describes how to implement SGT transpon.
Implement SGT Transport

tiO-Sv(eonfio;) t
Ct~ ro l e-bne<t eq~·l)jli) 172, l 6.t.SC
ceo ll ltp ~/'Ab14t
cu 11xp e~~n•e~1o~ p~e~ lG. : O.l 1 ~t:~~wo~~
"'' • ~on• ~- toe.lt :lfl~l:~~:r
tiO-A.$.1\.Iton~~<J• f
ceo :lih'v4tt>- g::-oo:p !SFl
cu :1xp otu~blo
(:~~ e xp e~neetion ~c l G,LC,t.2 !HI.li~W<l.«<. r.OCic: ~:~ode i oc«l Ueteoer
ao->.s.M • boveu u:p eonn.c:t1o~~o• br1• C

SXI' ttlablld
<QUtput cmittod>
'
::U:-~tiol',
-
.t.ec.l Conn SWhns ldd:ht :~tn:.,ed
'M<
. " .. . "
-·--·----------------------------------------------------------------------
1:22:4!1: 21
1
!!0-A.~<.Af •1\.o"' et• '9t- qp
AetlYQ !P-SC1' 8!.nl!1~11 ll'IHH'IMC-101\
li' .\~.tfllil:l !C!' !OU~Cft
···---~~.--.--------·~--~·~···~-~ .....................~
· }~ · l~.2G
l"' t:'"l ~
• ,_
SXP
. ...... ._.
SGTs can be propagated between devices via either. inline tagging or SGT Exchange Protocol (SXP). In
either case, both devices must be capable of me transport mechanism. As of software version 9.1, me
Adaptive Security Appliance does not support inlin.e tagging. Tbe slide depicts [he configuration of SXJ,
between a Catalyst 3000 family switch and an ASA.
The SXP connection is implemented via TCP from the speaker to the listener. Each device must be
configured with the peer LP address and the specification of the speaker/Listener roles. ln this example,. the
switch acts as the speaker. It bas a statically configured mapping of the fp address 172.16.1.50 to so·r 4.
You can verify the SXP connections on both the speaker and me listener with me show cts sc.p Ct)onedions
command. The output on the listener is shown abo~·e. You can also verify the received mappings using the
show cts sgt·map command.
Configuration of inline tagging between £WO devices is done at interface configuration mode on the
interfaces used to colUlect the two device$. The collifiguration can be specified locally (cts manual) or
centralized (cts dot! x). An example of manual configuration follows:
cts e":anual
policy s ~atic s9 t 2 crusted
The cts manual command enters Cisco 'frustSec configuration mode on the interface. The policy static sgt
2 trusted command specifies that any inline tags received on the interface wiiJ be honored (trusted) and any
frames arriving without a tag will have the SGT 2 imposed on the frame.

Define SGACLs
'J'bis topic describes bow to define SGACLs.
Define SGACLs
-rc::=-------,,.... ---:-=:
--- ~~-- "1 l)ooo,..
··--
··-
~-~·
.. .. -
~
··-
··--
··--- ·------·--·· _,,...
··--
·---
&-
HQ- sv • t bow
- 0(10
c~ rb• cl
r>-¥·e r'"'rl.YJt~ 1 1)
R'JIA0', :t·i ,·
dll:')1 tc•· e;:r ~
pt.c&i.!p.!.Q
r..ol:ll:" .. Poerm. t ll"-00
IUIAC"L AC&':
. -
por.fl1t ip
SGACLs are defined in Cisco Identity Services Engine under Polic.y > Polic)' Elements-> Results,
Securi-ty Group Access> Security Group ACLs. The figure also shows verification that the SGACL has
been received by tlle switch with me show cts rbacl command. Note that RBACL, the tenn used on the lOS
CLI, is synominous with SGACL (Security Group ACL).
Note that SGACLs do not explicitly specify the source SGT or destination SGT. This specification will
happen when the SGACL is applied in the permissions matrix. The following are the options for SGACL
entries on the Nexus 7000 running NOS version 4.2:
deny .a ll
deny icmp
deny igmp
deny ip
deny tep { (dest I sro) ( (eq I g't 1 l t I neq) por-t· nWllber I ra.nge port ..numberl port•
numller2) I
deny udp (tdest I arc} i{eq I gt I l t I neq} port- number- 1 range port• number-1 port•
nUI'Ilbe.r-2 1 J
perllli t all
pendt ic:p
per:rrd t 19=1>
per.l'ld t ip
per:rrd t tcp ({dest I src} { t eq I qt 1 lt I neq} port• number- I ra.nqe port• numberl port•
nUI'Ilbe.r-2} )
perllli t udp(tdeat 1 src} Ueq 1 qt 1 lt 1 neqJ port- number- 1 range port• number-1 port..-
nurnbe r2} J
~2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.

Implement SGACL Enforcement
This topic describes how to implement SGACL enforcement.
Implement SGACL Enforcement
,_,_
vo-sv (e«~fi'1) t ~t• rQl•-~••.0 •nlo~o.~t
110-S~t (c:;:ati<;) f ~t• ~l• -~••.0 ~loc~~t v l •n -li•t 3 I
---4 •-· ..,..·-_ _.. --- ---
--- •--0
-=:- ..,..._
~-
- ...
-· ·- ___
-~
..,__,.__)
....,
1- - · "
·-
........, -
____ .. ··-
, _ ·-
,..._.-.-r-
-
o -E3
!r."'-
-r;::
,,_
•
·-·-··
-·-·-
ao-s~o~•
·---- -·-......
t ho- ct•
Role-~·~usecl
o-
~ol• ·bat•d ~~•t 1or~

i'(!:ni•e.ior.ll ~f-5ult:
o-
~
'""' "';io,Q·E.li!oil
Pernit tP-CO
"S~iilG!ii:l! iJ:!:2~ i~ 1''1:11;9 9 e ~dlon·~
:illft • :-:r·-.a .·
. " --
This slide depictli three operations. First, enabling role based enforcement on a network device, both
globally and on a specific VLAN. Second, the definition of the egress permissions marri.x in Cisco Ide.ntity
Services Engine. Third, verification that the pem1is:sions matrix was successfully uansfered from IS£ to the
oetv.·ork device.
Policy enforcement within the Cisco TrustSec domain is represented by a permissions matrix, with source
security group numbers on one axis and destination security group numbers on the other axis. Each row
represents a source SGT and each column represents a destination SGT. Each cell in the marrix defines a
source SGT/destination SGT pair. Each cell can contain an ordered list of SGACLs which specify the
permissions that sbouJd be applied to packets originating from the source security group and destined for
the destination security group. The matrix can be managed in ISE at Policy> Security Group Access>
Egress Policy> Matrix. ln this scenario, the SGACL named Deny_f.'•fp is assigned to craffic originating
from SGT 3 (IT) and destined to SGT 4 (Servers).
was enabled wing the cts role~based enforc.ement and cts role~based
[n this scenario, enforcement
enforc.ement vlan ~list commands.
You can verify the enforcement using muJtiple ways. The full output of the show cts role-based
permissions command is shown here:
f!Q• Swt show ets role· based pera'liasions
I?v1 Role- !::ased permi ss io ns de! ault :
Permit I?- CO
I?v1 Role- based permi ss io ns !rom g roup 3 : IT to group ·'J : Ser-vers :
teoy_FT? · 3C
You can also view the enforcement statistics using 1he show cts role·based counten command:
f!Q- sw• show eta role• b&sed counters
Role- bas ed I?v•l counters
t •.. • i n hardware count e rs field indi c.at es s har-i~g a :·nong cells .,.ith ic!e n ~ical policies

From nw- Den1ed sw- Per.:ni t ted BW- Permitted
0 t, 5566 HS2"19
., 29 0 218S6

Implement SGFW Enforcement on the ASA
This topic describes how to implement SGf'W enfcncement on the Cisco Adaptive Security Appliance.
Implement SGFW Enforcement on the ASA

.
...
__ --·--1.),_ ... - •
-- ..
ttm1 , _..__
•
,. "'B•
. - -·-
- -
,i"\'1_.....
.._II_ _ _
''
~-- - -- - -
. ·-·-·-
~ ~ ~~ h
·- -·-- ·---
·-·--
' ' ·~
110-.0.W.I •M"' •o:;c.•• -U•~ J r~J~J4e •c~•• i 11
•ce~,,-l!•t 1~•1do_ace4s s_1~; 2-ot~~~~s:
·~
•oco•s-l1st 1~sido_4ceoss_1~ ll~o l ex:o~A~ d~~y tCP. ~~~ r~ ~~~.

~ina.,.,·"' 'r"'l 40Y p~euUl)'-ar·.. •p ..+.DQ ~ llal'~:"'"SC'!"Y'<'t'J..,
ftp (hit ent'"(H
111..11}' e~
•~el»-lillt inside_occe-!lo_in line 2 ex::el'llied pe:Dit ip •or M)' lhitent•l2~9l
....... _.
SGFW is implemented on the ASA by utilizing security group tags in the source and/or destination
specification in ACL entries. This capability was made available in version 9.0 of the ASA software. 1'he
slide depicts a policy that denies fTI' from !he source group 3 (IT) to the destination group 4 (Servers). This
policy is configured in an ACL !hat is applied inbot!llld to the inside interface. The top figure shows the
access rule definition in Cisco Adaptive Security Device Manager. and the bottom figure shows the CLJ
representation of the access list.
Note that on the ASA, ACLs can also be used by the modular policy framework to classify traffic for
various policies. For example. SGT data can be used to classify traffic that will be sem to a particular virtual
sensor implemented in a sensor module installed in the ASA.
SGFW is also available for use in lOS zone based firewall since lOS version 15.2. Wi!h zone based
firewall, security groups can be specified \vith match clauses in me class~ map statements.

MAC Security
'J'bis topic describes downlink and switch ·to~switch MACsec.
MAC Security
Layer 2 Encryption (802.1AE)
Downlink MACsec:
Industry Standard Extension to 802.1X
uses~
Enabled by Cisco AnyConnect supplicant

Supports per-davice sewnty associatiOns (for example PC and IP phone}
Switch-to-switch MACsec:
NDAC
SAP
----
MACsec is the IEEE 802.1AE standard for authenticating and encrypting packets between two MACsec-
capable devices. Cisco switches support 802.1 AE encrypttion with MKA on downlink ports for encryption
bet\\•een the switch and host devices. The switches also support MACsec link layer switch.to~switch
security by using Cisco TrustSec NDAC and the SAP key exchange. Link layer security can include both
packet authentication between switches and MACsec enc1}'J>tion between switches (encryption is optional).
Tbe 81>2.1 AE standard requires supporting protocols for key management, authentication, and authorization.
To meet this need, the IEEE proposed an additional standard, 802.lafMAC Key Agreement (802.1X-2010/
MKA), an extension of802.1X that manages short-lived session keys that are used to encode and decode
messages. 8-02.1X·20 I 0/ MKA supports per*device security associations in shared media environments, for
exampl e, with PCs connected to Cisco 11' phones. 802.1A.E must be supported on the platform and the
respective modules.

MACsec Cryptography
This topic describes the MACsec cryptographic features.
MACsec Cryptography
Layer 2 hop-by·hop encryption a01d integrity
12B·bit AES·GCM
----
ASIC technology provides line rat e encryption and decryption
Replay protection for every frame
B02.1AE encryption protects tags and data
""' -
....... _.
MACsec is a Layer 2 bop-by-hop encryption and integrity solution that is based on the 128-bit AES·GCM
cipher. Cisco switches that support MACsec utilize ASIC to provide real-time line rate encryption and
decl)'ption. MACsec ensures replay protection for every frame. MACsec standard offers encryption of the
frame payload, including !he Cisco Meta Data (which contains !he SGT) header, and the 802.1Q header.

MACsec Hop-by-Hop Operation
'Jllis topic describes the MACsec hop-by-hop operation.
MACsec Hop-by-Hop Operation

·aump-in ~the-wire" model
Packets are encrypted on egress
Packets are decrypted on ingress
Packets are in the clear across the baCkplane
Network can perform aU packet processing features:
I nsp~ction
Filtering
...-
--
jloS
----
.....1 . -
- ....
When a frame arrives at a MACsec station, the MACsec Security Entity decrypts the frame if necessary,
compU'tes an ICV on the frame. and compares it with the ICV included in the frame. If they match, the
station processes the frame as normal. If they do not match, the port processes tlle frame according to a
preset policy, usually discarding it.
'This operational model can be thought of as a "bump in the wire," in which the packets are encrypted on
egress interfaces, decrypted on ingress interfaces, and switched in the clear through the device's backplane.
1'his approach allo\\o-s the network to perform all current packet processing features, such as packet
inspection, stateless and stateful filtering, and QoS processing.
~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Implement Downlink MACsec on the ISE
This topic describes the downlink MACsec implementation on the Cisco Identity Services Engine.
Implement Downlink MACsec on the ISE

MACsec policy configurable as C ommon Task in authorization profile
Three options identical to switch settings
·- -
.- --· - ·.. - #""'I-
----
_,. .
w.- , _ ··- ~~- !,.~ ........ !;;,_,_.... _
.... _
,. --
-·-
·= .
··-
.. ·- f!P§
··-
··- -- ~~:i;i.~.i-1:.=~-------~
··---
·--- f. ;_
....... _.
Downlink MACsec policy is configured as an element in the authorization profiJe in Cisco lSt. To specify
MACsec policy for endpoints, you enable MACsec policy and then select the policy option. The options are
must~not.,secure, mustAsecure and sbould~secure. Tills populates the value for the Linksec~policy atrribute, a
Cisco AV pair sent to the network access device as pan of the RADIUS access·accept message.
The MACsec poticy defined in lSE will interact with policies configured on and capabilities of both the
NAD and the supplicant. For example, if the ISE policy is must~secure and either the supplicant or the
switch are not MACsec capable, then access will be rejected. Sbould·secure will secure if all components
are capable and willing, but will allow unsecured access if a component is not MACsec capable or is
configured with must-not--secure.

Implement Downlink MACsec on the NAM
'J'bis topic describes the downlink MACsec implementation on the M.,f\1.
Implement Downlink MACsec on the NAM

""""--·----~
~~~]:~:: r ~~
___..----------------------~
....~~
- ... ___ _
___
...........
·--
_..__ _____
---·--- -· --
---------
--, --
-
----
~-
---- ~-
-·- --
-~
-~·
•
-
----
•
·---
-----
--- ·----..-.-
··-- --·
To ena'ble downlink MACsec in the Network Access Manager of Cisco AnyConnect, you must create a
profile and configure it to use MKA as the key management method and set the encryption algorithm to
MACsec: AES-GCM-128.
3:.00 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Implement Downlink MACsec on the Switch
This topic describes the downlink MACsec implementation on the s\vitch.
Implement Downlink MACsec on the Switch

. 802.1X multioauth host mode does not support MACsec
. Authentication linksec policy
Default setting ts shOuld-secure
Avoid conflicts w ith policy oblained from CiSCO ISE
lli>-S,.(c;o.-.!io;) t
~fte.~!•c• C1~ab1tt~•~~ t0/l
~·~
~ 6et.~l~po 1iey
•~~th•n tic::a;.ion li.n:kM<: po:~ lic;y ahodd -•.e~o~..-
....... _.
This figure illustrates the configuration of the MACsec feature on the switch port. Apart from enabling
MACsec, you need to enable an MK.A policy using the mka command. The authentication linksec policy
command allows you to select one of the three options: must-secure, must-nor-secure, and should-secure.
The should-secure option is enabled by default.

Verify Downlink MACsec
'J'bis topic describes bow to verify downlink MACsec.
Verify Downlink MACsec

ltC-Sv f ehov •~tben~i~tLon •••• iQnf in t•~h~· 9i9f.bitJ:tMrn•~ on
...
11 R;irify
O:.et:-·N111f4:
•
Status:
Qel)llin:
ttl
,....
Autlw. 3\!{:CQJill
\>iii'{!~r'F.t ;:;IIJ.§_y
SUtJ \lC~
~Q~ hoJit nod4 : ll1nqlo-~~tt
<o~tput o~itt~>
HQ-Svt thow aac t • c tft~&!ao. ~19&b1tEeb•tft•t ~/l

l<i\C~ tJI Cll'lllbletd
l'epl~·..- protec~ cc;ebled
~pl~y vtnckw
'' 0
tne!uM SC!
'
C1phet! : GC.~A!S-lZ& '"
....
conf ide~ti~li~y
Co~t>ilitiC$
b SA 16
Off•et
'0
>\11)( . 1'1t SA
V51id l:l.tC
' 16
r.r41'-e.:J
?$ thnu:~l\o ld ~:.odf~(;~tion
C1pbet~ll ~~ppo ! t~
<o:n.put Ofli tto!!>
' .5tdct
:
•uv!l'(;rt
ca<-~o.::s-t:HI ' ..
~
-~~
'J'be sbow authenticAtion sessions interface command can be used to verify the MACsec policy that bas
been negotiated for the switch pon as well as the current status ofMACsec on the port. You can further
examine me crypto details using the show macsec interface command.
3:.02 lmplemen~ng Cisco Security Access Sei\Jtlons -0 2014 asco Sy&ems, l nc.
Summary
Summary
SGA abstracts the network topology from the access control policy.
Networ1< can be capable of, incapable of, or aware of SGTs.
SGT Exchange Protocol advertises mappings of SGTs to IP
addresses.
MACsec. an extension to 802.1X, provides Layer 2 encryption between
adjacent devices.
. ...... _

3:-64 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Module Summary
Module Summary
EAP·TLS uses certificates for both server and client authentication.
The ISE authorization policy is a list of rules that match conditions and
apply authorization profiles.
Cisco TrustSec simplifies the provisioning and management of secure
access to network services and applications.
MACsec is the IEEE 802.1AE standard for authenticating and
enaypting packets between two MACsec-capable devices.
0,.,.__.._
References
3:.00 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Module Self-Check
Questions
I. Which EAP method uses client~side certificates? (Source: Certificate~Based User Authentication)
A. PEAP
B. EAP·FAST
C. FAST-TLS
0. EAP·TLS
2. At minimum, how many certificates does the ISE require to support EAP with client certificates?
(Source: Certificate-Based User Authentication)
A. Depends on the number of clients
B. Depends on the total number ofCA's
C. I
0. 2
3. How do apply a certificate authentication profile in the Cisco IS£? (Source: Certificate~Based User
Authentication)
A. To an identity source
B. To the authentication policy
C. To an authentication policy rule
D. To an identity source sequence
4. \Vhich two policy elements are used in authorization? (Source: Autl1ori:zation)
A. Authorization assignment
B. ·Pennission
C. Allowed Protocols
D. dACL
E. Authorization profile
5. How is a d.ACL cransported to the destination? (Source: Authorization)

A. Via RADlUS to the client
B. Via RADfUS to the authenticator
C. Via RADIUS and EAPOL to the client
D. Via TCP to the switch
6. In which two deployment modes would you set the pennission in the default authorization rule to
DenyAccess? (ChO<>St two.) (Source: Authori2ation)
A. Access
B. Initial
C. Closed
D. Monitor
E. Low-Impact
7. Which two methods can be used to transport SGTs1 (Choose two.) (Source: Cisco TrustSec and
MACsec)
A. TrustSec (CTS) Meta Data (CMD) header in <fownlink MACsec

B. TrustSec (CTS) Meta Data (CMD) header in switch-to-switch MACsec
C. TrustSec (CTS) Meta Data (CMD) header in switch-to-ISE MACsec
D. SXP
E. EAP-FAST
f. RADIUS
8. Cisco ISE can dynamically classify VI'N traffic using SGTs. (True or false?) (Source: Cisco
TrustSec and MACsec)
A. True
B. False
9. Which statement describes the SGFW support on Cisco lOS routers? (Source: CL'co TrustSec and
MACsec)
A. Not available
B. Available with standard ACLs
C. Available with extended ACLs
D. Available with ZBPF
E. Available with fPM
3:-0& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Answer Key
I. D
2. D
3. 0
4. O, E
5. B
6. C,£
7. B,D
8. A
9. D

3:-70 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Module 41
Web Authentication and

Guest Access
\Veb Authentication (WebAuth) is a convenient method for authenticating end users who cannot be
authenticated using 802.1X. The users are redirected to the guest portal, prompted for authentication, and
depending on the outcome, applied an appropriate authorization profile by the Cisco Identity Services
Engine (lSE).
The Cisco ISE Guest service allows users, such as guests, visitors. conrractors, consulmnts, and customers
to access a network, whether the network is a corporate intranet or the public Internet. Cisco iS£ Guest
service allows users with the appropriate privileges to easily create sponsor accounts and temporary guest
accounts. Tbe Cisco ISE Guest Service performs full authentication of sponsors.
Upon completing thls module, you wiJJ be able to:
• Describe Cisco JSE IVebAuth
.. Describe the guest service features of the Cisco IS£
Lesson 11
Deploying WebAuth
Overview
lVebAuth provides network access to users who authenticate using HlTP or H1TPS. WebAutb is typically
used for guest nern·ork access and may be utilized for other clients without an.~..£: 802.1X supplicant.
This lesson provides an overview of the process for deploying WebAuth using the Cisco Identity Services
Engine platfonn.
Describe WebAuth
• Describe the WebAuth process
• Describe the WebAuth scenarios
.. Describe the Central WebAutb process
Describe the Central WebAuth configuration procedure
• Describe how to configure a switc-h for \VebAuth
• Describe how to configure the MAB to continue when user is not found
• Describe how to rune the WebAuth identity soltl'ce sequence
.. Describe how to tune the WebAuth identity source sequence
• Describe how to configure an authorization profile for traffic redirection to WebAuth
• Describe how to apply the WebAuth authorization profile
.. Describe the authorization policy rule for users who have authenticated via WebAuth
Describe how to verify how to verify the redirection to WebAuth on the ISE
• Describe how to verify the traffic redirection to WebAuth on the switch
• Describe how to verify W'ebAuth traffic redirection on the client system
• Describe how to verify how to verify the redirection to WebAuth on the ISE
Describe how to verify the completed WebAuth authentication on the switch and client

Web Authentication
This topic describes Cisco Identity Services Engine WebAuth.
Web Authentication
Enables authentication and authorization via HTTP(S) portal
Automatic HTIP(S) redirection to the authentication JX>rtal
Deployed for visitors and optiona lty as 802.1X fallback
Supports both wired and wireless access
;so; · -
= ~I
-
\VebAuth enables authentication through a portal accessed via HTTP or HTTPS, followed by the
application of the appropriate access authorization profile. Automatic redirection to the authentication web
page occurs when an non-authenticated user attempts an HTTP or HTrPS connection.
\VebAuth is used primarily for guest access but may be used as a method of last resort for users with an
IEEE 802.IX supplicant that is not installed, is misconfigured, or is not functional. If the 802.IX supplicant
is not functioning properly. WebAuth may be used to prompt the user for authentication credentials and still
provide access to the network. WebAuth may also used for guest users who have an 802.1X supplicant that
is installed but who do not have a user account in the appropriate identity database. WebAuth can be
implemented in both wired and wireless environments.

WebAuth Process
'J'bis topic illtL'itrates the WebAuth process.
WebAuth Process
1. Initial authorization assignment restricts traffic
Pr~·WebAuth dACL defines permitted traffic
Redirect ACL defines traffic to int$rtept and send to portal
2. After successful authentication: Pre..WebAuth dACL replaced, Redirect
...._
--
ACLremoved
---
• 4J •>))
..-- ., - -
--
.... ~
• J •>» __,
....__. ---
'--
·-~
When a guest user first attaches to che local network, either through a ·wireless or hardwired connection, the
connectivity is controlled and provides limited access. Generally a pre.WebAuth dACL is used for this
controti, but a VLAN assignment may be used instead of or in conjunction with the d.ACL. The d.ACL
pennits onJy WebAuth rraffic and potentially some basic .networking services. Working in conjunction with
the dACL is a locally configured ACL that defines the traffic that should be intercepted and sent to the web
authentication portal. This ACL does not limit traffic that is allowed. Instead, it specifies which oflhe
allowed traffic wiiJ be redirected.
To gain greater access to the network, the user attempts an H..JTP or HTrPS request from a browser, for
examp!e, brtp•/lwwy.• cjsco com. Based on the redirection ACL, dle NAQ. intercepts the HrrP request and
redirects it to the guest user login portal. After successful authentication, the redirection is removed and the
user is assigned an appropriate aumorization profile. This new profile specifies a new d.ACL to control
access to the enterprise resources.

WebAuth Scenarios
This topic identifies WebAurh scenarios.
WebAuth Scenarios
Scenario Daaeription
Central WobA.uth Sui)!)Of1 for vh'eles:s end wired Oetwc:w\1( access devices
User Is redlrecled ro the CISCO ISE web seMce f« BiJ!henllcatioo
AU!hentfcatlon perbmed- on policy &etVIc:e persona
Cisco tSE sends~ request to NAD after authenl:lcabon
Local WobAuth • NAD proiAdes 'Y>'eb service foraUI:henllca ~K~n

(m.._t; 0< SY<iteh) • Autttentieatlon on NAO soo Cisco ISE
• Ooes not-support CoA
• OoM not aupport c:antrallzed audit traa
• Requires conftg«Jratioo of portal on eaCh switch
Davioe Registration. • Enables ooboard~

WebAuth User Is not required to authentcale
• AUihentDcallon wtth a.MAS request
... -- Used 'o\tlen 'ills sufficieM to omtlrm h.UP
The Cisco Identity -Services Engine supportS these web authentication scenarios:
.. Ce.ntral \VebAuth: This scenario applies to wireless and wired NADs. ln this scenario. the user is
redirected to the Cisco ISE web service for autihentication. Tbe authentication is performed on the
Cisco ISE. The Cisco ISE requests a CoA from the NAD after authentication.
.. Local \VebAuth: This scenario differentiates between wireless and wired access:
In the \VLC with Local \\'ebAutb scenario. the user logs in and is directed to the WLC. Tbe
WtC then redirects the user to the guest portal the guest portal prompts the user for a usern:arue
and password, and perfonns an optional A.UP. When this process is complete, the user browser i.~
redirected back to the WLC to log in again. The WLC authenticates the user via J~IU~ and then
redirects the client browser to the original destination.
In the Wired NAD ·with Local WebAutb scenario, the guest user login portal redirects the guest
user login request to the switch. The login request is in the fonn of an HTfPS URL posted to the
switch, and oontains the user credentials. The switch receives the user login request and
authenticates the user through a RAOfUS server rbat points to the Cisco lSE.
.. Device Registration WebAutb: In this scenario, the guest user connects to the network with a wireless
connection that sends an initial MAB request to the Cisco ISE node. lf the user MAC address L~ not in
the endpoint identity store, the Cisco ISE responds with a URL redirection authorization profile. The
URL redirection presents the user with an AUP acceptance page when the user attempts to go to any
URL.

Central WebAuth Operation
'J'bis topic describes the operation of Cisco ldentity Services Engine Central WebAuth.
Central WebAuth Operation

1. Client connects to NAD: may or may not have 802.1 X supplicant
2. NAD initiates an access request
MAB requost (t\0 802.1 X supplicant)
Regular user aooess rGqu$SI {802.1X s upplicant)
3. ISE configured to continue operation

Upon ~MAB failure· or ~user not found..
TOallow the Central WebAuth prO<::lBSS to prOOGOO
4. ISE sends access~aocept message with URL-redirect to WebAuth
service
-~
~ --- - -•- -u Awm.
·-~
-·I -- 0
Tbe example that is shown in the figure outlines the steps for Central WebAuth:
I. The client connects to the NAD through a hardwired connection. The client may or may not have an
800.1X supplicant.
2. The NAD initiates a MAS request for an endpoint without a supplicant or a regular access request for
an endpoint with a supplicant.
3. ISE processes the request and does not flnd an endpoint or user. Tbe appropriate authorization rule is
co.nfigured with a restricted network profiJe, which contains URL-redirecrion parameters.
4. JSE sends an access~accept message with URL redirection for Central WebAuth to the NAO. The
redirection is to the Central WebAuth service that is running on the policy service node.
4--8 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Central WebAuth Operation (Cont.)
5. User attempts to connect to any URL.
6. NAD redirects client browser.
7. Redirected d ient browser connects to portal on ISE.
8. ISE authenticates the user.
9. ISE sends a CoA lo the NAD.
10. NAD applies new authorization settings .
•
• ...____ -·
•
• •
..,_
-- -..
-
5. The client initiate.c; an HTJ"P(S) request to any URL using a browser.
6. The NAD sends an H'ITP(S) redirect message to the client. The redirection is to the URL that is
included in the access.accept message. This URL is for the cenrral web authentication login page. The
URL encodes the conunon session ID which uniquely identifies this endpoint's f:...'Y:!. session for both
!SE and the NAO.
7. The redirected client browser connects to the web authentication portal on lSE.
8. IS£ dis-plays the authentication portal and requests the usemame and password. h then authenticates the
user against the configured identity store or stores.
9. Upon successful authentication,ISE sends the :authorization profile that is associated with the
authenticated user in the fonn of a CoA message to the NAD.
10. The NAD applies the new authorization settings and returns a CoA acknowledgement back to ISE.
After the authentication completes. an authentication successful message is displayed in the user's browser.
The message also directs the user to repeat their ori.ginal URL request The user is not redirected to their
original requested page, they have to manually repeat the request. If permitted by the authorization profile,
the connection \\till succeed for the repeated requesll.
Note In a distributEXI dGpiOymGnt. the ce.ntral web authentication portal is provid$d on nOdes whiCh run tne
poliCy servioo persona. AA ISE node wtlich only runs tM policy SGrvice persona iS often called a PS~.

Central WebAuth Configuration Procedure
'J'bis topic describes the Central WebAuth configuration procedure.
Central WebAuth Configuration Procedure

1. Configure a switch for WebAuth.
2. Configure the MAB to continue when user not found.
3. Tune the WebAuth identity source sequence (situational).
4. Configure Pre·WebA!Jth .!!Ac.b
5. Configure traffic redirect to WebAuth: authorization profile.
6. Configure traffic redirect to WebAuth: authorization policy.
7. Configure authorization policy for d ients authenticated via WebAuth.
Follow this procedure to implement Central WebAuth on the Cisco Identity Services Engine:
I. Configure a switch for WebAuth
2. Configure the MAB to continue when user not found
3. Tune the WebAuth identity source sequence (situational)
4. Configure l're-WebAuth dACL
5. Configure traffic redirect to WebAuth: authorization profile
6. Configure traffic redirect to WebAuth: authorization policy
7. Configure an authorization policy rule for clients authenticated via WebAuth
Configure Switch for WebAuth
This topic describes how to configure a switch for Central W'ebAuth.
Configure Switch for WebAuth

. Enable CoA
. Enable HTIP/HTIPS to intercept and redirect requests
. Local redirection ACL
- Excludes traffic to ISE nodes that provide central W&bAuth service
- RMirects all otMr HTIP or HTTPS traffiC
- ACL iS referenced by nama in the authorizatiOn profile on Cisco ISE
•~~ ~•rv•! T~diu~ dynAn1e·•~thor
c:hent H> . l ~ . 2.2G 4l't"':'t-Jte:r 0 .ud.l.u.:J-Jte:r
'
ip hup .so.rW!It
!p http s~~r•-a~tvor
'Pfti'Jiit tq:. ony •ny aq ""'"'

ip «C:t\'II.:J·lust ex~eod<!d toct._~&IIUtii_IIJ>Dl~t'
Pft :·r~tt. tq:. 11ny .&ny 41:q u;;.

petni.t l.ey 1111:>)' 41\.f eq 8H3
....... _.
A few features need to be configured on the NADs to support Central WebAuth.
You need to enable the CoA feature. It is enabled in the aaa se-rver radius dynamic..author configuration
mode using the client command. The client command references the Cisco Identity Services Engine I.e
address and specifies the shared key. ln the standard RADIUS process, authorization specifications are sent
to the NAD in an Access-Accept message in response to an Access--Request from the NAD. CoA allows
[SE to send new authorization specifications when lSE. recognizes the conditions have changed. CoA .does
not require the NAD to solicit the authorization request.
You must also enable the HTfP and HTTPS services. They are required at the Cisco lOS NAD so that the
NAD can intercept web requests and redirect them to the Cisco ISE. While not shown here, it is also
recommended that an access-class statement is applied to the HTI'P service to limit which rr addresses are
allowed to reach the management interface via H'n'l, or HTTPS.
Lastly, you must configure a local ACL that defines the traffic that is to be redirected. Traffic denied by the
ACL is not redirected~ traffic that is permitted will be redirected. The ACL shown in the figure, named
ACL_Wf:BAUTfi_REDIRECT, illustrates this principle. Basic network services such as ~ and .!llifJ:
are denied. Web browsing ports are permitted and thus redirected to the primary service node. If your
organization implements web proxy services, me p~oxy ports should also be redirected. This local ACL is
referenced by ISE by name in the authorization profile. The local ACL must be a named ACL Numbered
ACLs are not supported.

Configure MAB to Continue If User Not Found
'J'bis topic describes bow to configure the MAB to continue if the user is not found.
Configure MAB to Continue If User Not Found

WebAuth requires a fail·open MAB authentication rule
Configure it to continue with processing if the user is not found
User not found authorization rule specifies redirection
--- ..____- -·-.

.____-·
_ -
-·..
- -- .. _
-..............
;';;;;;:o;o.;-;- , . _ ~- n - ._ .... - .
_...,. ...
- # •
--·-
• ·--
..·-. ...-
·--
~·
_.
-·-·-·
_..
--~-
----
.. ___
·--=
··--------·--
.__,._
_~ .. _ ii
Tbe default Cisco Identity Services Engine configuration consist.~ of two built-in rules, MAS and DotlX,
and a rule named Default RuJe that is processed when none oft:he other rules produces a match. You can
modify, duplicate, and delete the existing rules, or insen a new rule at any desired position by selecting the
appropriate action in the Actions list The available actions are: fnsert new row above, lnsen new row
below, Duplicate above, Duplicate below, and Delete.
Central WebAuth makes use of a fail·open MAS authentication rule. ·n le authentication rule must be
configured to continue when the user is not found. This configuration allows funber actions to be taken by
the Cis:co IS£ and the NAD. MAB will complete with success. but assign the attribute Authentication Status
the value ofOnknownUser. An authorization policy rule that requires this condition will then be applied
and its authorization profile wiU specify the redirection to the central web authentication portal.
•H2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Tune the WebAuth Identity Source Sequence
T his topic describes how to tune the WebAuth identity source sequence.
Tune the WebAuth Identity Source Sequence
---
·--
- - ---
------
·-- _____
..
...._...
,_
.....
··
"-'·;---~
-;:;.
·-
~-
- ·-·--·--
-~
----
c----
J
·- . .-=---.. .-·---=- ~ AOI~~ee
.
- •
--
....,_ ----'---'----...1
..d '*' -· II I
·-_.------·...--·--·
PfOCMd to
-
C eo-
_·_.._
- _.,.,.
· ·- _-_
-_".,.' · · - ·-- - -
· .._not
·-- - - --- to.md
.....)
....... ..
Cisco Identity Services Engine comes preconfigured with an identity source sequence named
Guest_l'ortal_Sequence. It defines the identity stores that dle ISE consults when authenticating users via the
guest portal. By default, this sequence includes only tlle Guest Users and lhe Internal Users.
Ln scenarios where external identity sources should also be consulted, this identity source sequence sOOuld
be modified. The example in the figure shows the movement of lhe Active Directory identity source, AD I,
from the Available to the Selected identity sources.

Configure Pre-WebAuth dACL
'J'bis topic describes bow to create a d.ACL to control traffic before WebAuth authentication and
authoriization.
Configure Pre-WebAuth dACL
~--~~
-.....
- --·-·-
·-
.~ ..--- · ·--
..
·--
-------
-~~~~~
··- - - _ ======-
···-·-··-··---- -·---....--
----
-----
......
____ . ........-- . . . . . .. ..
··-
··--
··-- -----......... -
~---
--.. -
.....
When central web authentication is initiated, Ci..(iCO Identity Services Engine will send a dACL and specify
!he name of a local redirection ACL to d>e NAO. These two ACLs work togelher. The dACL will specify
what traffic is allowed prior to user authentication and authorization. The redirection ACL will specify what
oftlle allowed uaffic will be redirected to the central web authentication portaL
Tbe figure shows the definition of a dACL named Pre-WebAuth. The access control entries in me example
are defined as follo\\1"5:
permit udp any c~y eq bootps
permit udp any a~y eq do~a i n
permit 1c~p a ny a~y echo
permit ic!t'._p a ny any echo ... repl y
permit tcp any any eq www
permit tcp any eay eq ~11
permit tcp any host 10 . 10 . 2 . 20 eq 8 443
permit tcp any host 10 . 10 . 2 . 20 eq 8905
permit tcp aoy host 10 . 10 . 2 . 20 eq 8909
permit ud·p any host 10 . 10 . 2 . 20 eq 8905 8906
permit udp aoy host 10 . 10 . 2 . 20 eq 8909
Tbe requirements ofthls ACL will vary with the design scenario. In the example ACL, the first two entries
pennit OHCP and DNS, respectively. Tile two ICMP entries pennit bidirectional ping, which may be
helpM for troubleshooting scenarios. Hn·p and HrfPS ·traffic are allowed (and should be redirected by
the redi rection ACL). Port 8443 is used by the ISE guest portal. Ports 8905 and 8906 are used by the NAC
Agent Swiss protocol for lS£ posture services. l'on 8909 is used for client provisioning activity.
4·1-1 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
WebAuth Redirect: Authorization Profile
This topic describes how to configure an authorization profile for traffic redirection to WebAurh.
WebAuth Redirect: Authorization Profile

Specifies dACL defining pre-auth.entication/authorization permissions
Specifies local ACL name defining redirected traffic
--- - _.... . .... - · . -·

-.....
··- •• --
--·---
·- r--· ~-~
··---
·c.- -
··----
···-
··---
··---
--- ... 'iiii+
._ '===ac~---
.•
r:- --
·--~--·-
. . . . _. ---
The authorization profile that suppons Central WebAuth should define at least two things: It should specify
the dACL which will control what traffic is allowed from the endpoint prior to the w;er successfully
completing authentication through the central web authentication portaL It should al(jo specify a named
ACL, that must exist on the NAD, which what traffic will redirected to the central web authentication
ponal.
The named ACL on the NAO must make sure that all H'ITP and HrtPS <raffle is redirected except the
traffic that is destined to the policy service nodes.
The figure depicts the definition of the redirection ACL in the authorization profile. The dACL is als()
specified in the Common Tasks section of the authorization profile. The distance between dle two options
made it impossible to show both in a single sc.reen shot

WebAuth Redirect: Authorization Policy Rule
'J'bis topic describes bow to to configure an authorization policy rule to redirect traffic to WebAuth.
WebAuth Redirect: Authorization Policy Rule
__ ---
_
--==:""'!--~~-:::::-::--
1.. -·
_.. ___ ---·-·----- -...
"'" - - , _
..,. ·..
::::-':'·::
» ...... · -
-= ·
....-
. ... -
....
0
..
# -
___
-• ··-
.
------ .
-
...
• --- -
- --- =----
..... --
•
I
• ---
-
---·--· -·-
- . ~
•• - -
I
--
• -- -- ·-- -- -- ....
---~- -~
-
I
• -- -
•• -
- --IO,Ioo--
- --
The authorization profile needs to be assigned to an authorization policy rule to be enacted. The
authorization policy rule for central web authentication is cypically placed just before the default rule. The
authorization rule should have the condition which verifies that the UseCase attribute from the Nenvork
Acce.c:;s dictional)' is set to the value Host Lookup. This this dictionary value will be set after a failed MAB
process.
Tbe figure depic[s an authorization policy rule named WebAuth that requires Necwork Access: UseCase
EQUALS Host Lookup and assigns the authorization profile named WEBAUTH (which implements the
policy supporting redirection of web traffic to the authenti cation portal).
Configure Authorization for WebAuth Users
This topic describes the authorization policy rule for users who have authenticated via WebAurh.
Configure Authorization for WebAuth Users
---
_____
---·
~.-"- ________
......... . -. --·
- ........--
.....,.. ~ - ----
..... _.........., -
...
--··-
-• --
·-- -- -·-
...·---
• ---
- -- ..---
··-
=.."""~fl:..-=:.:.·::-..-
··-·
_ __ ,__110 ...
..,.,·-·- --
-~--
"
-
- 1 0 1 -.. - · -...
• -
• ··-
• -- -
-------oio#-· --
.. ___ _ -
<(!~---·-
_,,_
_....,
•• --
-
~--
--
- ..
• - ----~--
-
After implementing an authorization policy rule that supports the use of the central web authentication
portal, additional rules must be defined to specify authorization profiles for authenticated users. When the
user is authorized on tlle login page, Cisco ldentity Services Engine restarts a Layer 2 authentication on the
switch port, and a new MAS occurs. Tbe redirection policy \\-ill be re.implemented unless other rules are
placed ahead of the rule which implements the web redirection.
[SE sets an attribute in the Network Access dictionary to remember a guest~authenticated user. Tbi~
attribute can be verified with the expression Network Access:UseCase Equals Guestflow. This condition is
met when tlle user authenticates via WebAuth, and the switch port is set again for a new MAS. The
authorization policy rules for central web authentication authenticated u.~ers should use this expression in
the condition as well as any other expressions necessary to differentiate between lhe type.~ ofwers. The
authorization policy rule must, of course, s-pecify the appropriate authorization profile for the indicated type
of user.
This figure illustrates the s-pecific authorization policy rule for members of the Active Directory group
Employees who authenticate via central WebAuth. There are two expressions in the condition: Netwo.rk
Access:UseCase EQUALS Guestf low and ADI :ExternalGroups EQUALS secure-xJ ocai/DomainGroupsl
Employees. The authorization profile specified is E:mployee_Corp.

Verify WebAuth Initiation on the ISE
'J'bis topic shows how to verifY the redirection to WebAuth on the Cisco ldentity Services Engine.
Verify WebAuth Initiation on the ISE

Authorization Profile named WEBAUTH is assjgned to Interface G0/2
Pre·WebAuth dACL has been downloaded
A session state has started for the MAC address based identity
------
·-- - ·--- -· -·- ·
--- --- --- ---- --- ,-
.
•
--- _..,_ • •
......,_ .
•
..---.·-·-.-:::
o- ....- . ....- . -. • -
....
......
..... ,IIOW•)l.. •
. . . . . . . . .... ...1 •
•
•
·-
-· ~· ---
---
--
-- --
Tbe figure displays an example of what can be expected on the Live Authentications display on lSE when
central web authentication has been configured and an endpoint without an 802.1X supplicant connects.
'J1lls is before the user authenticates via the portal. From bottom to top, an Authorization Profile named
WESAUTH is applied to Interface G0/2. The dACL named Pr<>-WebAuth has been downloaded. A session
state associated with the identity specified by the endpoint's MAC address has been started.
Tbe following documents an example of the steps that are listed in the details report for me event showing
the WEBAUTH profile being applied.
11001 Received RADI US /~ccess ... Request
11011 RADIUS created a new session
11021 Decected Host Lookup usecase (Serv1ce• 'l"ype - Call Check 110 ))
150.49 Evaluati~g Policy Group
15008 Eva l uar.i~g service Selection Policy
15018 Queried PI P
15048 Queried PIP
15004 Ma tched rule
15041 Eva luating Identity ?olicy
15006 Macched Def a u lt Ru l e
15013 Sel ected Iden~ity Source -
_f!1209 l.oo i ng up_ !:n pont _n !nter~a En ~ !'Its IDStore ~ A0 : 36:9F: A: :"I : AE
<2•1 21 1'he host is not round n t e internal endpoiats en ~· store
220 5 6 Subject not r ound i n the applicabl e identity stor:e(s)
220S8 The adva:"\ced option t hat 1S confiqured tor a-n unknown user is used
122060 !he •continue • a(N ~~ !jd t con figured In _c_as§ "gt ;; "iDe (['
aut~e n t1 cu"!oveques
15036 Eva l uating J\ut.horizatton Policy
2<1432 Uoktng up U!'ler in Act.1ve Directory .. rt"' : 36 : 9F : ll-. : 3D: AE
2-H l LUseuos tou:1ca tn nc.Uxe ..JH::ec,tory
15048 Queried PIP
p 5004 ~a tc hed rule • WebAuth
b. SC. 6 .. e.fecteg__.r..uthoti2at icQ.:.l
'-.,;"<o
= ti''-e,..._-> "' '"
""E"BA ICJ~'I""
l
4·1& lmplemen~ng Clsoo Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
~ 22 Added the ~.CL spec e n t he A~tho~ tat on Pro e
110~2 Retur~e RA~lUS AccesswAccept
Note lhat after a failed MAS lookup, the continue option was invoked. Because authentication appeared to
complete, but the authentication status is 'UnknownUser, the authorization policy rule named WebAutih was
matched. This led to the selection and application of the authorization profile named WBBAUTH.

Verify WebAuth Redirect on the Switch
'J'bis topic shows how to verifY the ttaffic redirection to WebAuth on the switch.
Verify WebAuth Redirect on the Switch

. Redirection to WebAuth enforced by the switch
. Redirect URL contains the session 10
. When troubleshooting, you can connect to the redirect URL
ltC-Sv t ehov f.1.1tboen~ic::.tot,Lc:,n ••n i<::~nf intuh~• 9i9MitJ:tMrn•~ 0/:t
tt'l!.orraee: CtgAbt~Ethorn.t0/2
WI!: Ji~tO.U : a0:!6 . suo. :!!lb2
iP Add.t«$: 10. lO, U.l¢
O~e.t-NIIIf'!! ; A0-36-9r-1A-3B-&1
Sutus: Mtht. St.~.u
«:&.J!.f)Ut «r.ittoA...>
~~ ~~~'':l.,l!..~;x·,~~e-~"'~xth-e:roe""l
1if]Qi8'Jl:ecL tci=-'c: •Hgif.u: w p p
OIU. Roo!!!toet : http:~ : 1/iso.. setc::uro-.t. loe.t: : S44.>/gi!Ctsepona 1/gato.,.ay?
ll<lliS t.oe'I!<M00ff1Jli)C"IJt';!WA(15)f~&:7im. act iO.'I ~
SOIIdOt.l t!flOt>llt: N /A
~0 Sef~tOQ 10: J;\0<">· 16iJ00"5¢M4l3~
<oc.tput o1n t t e<:1>
·-~
The figure shows an example of the authentication session status on an interface for which centtal web
authentication bas been enforced, prior to the user authenticating via the portal. The authorization policy
sent by the Cisco Identity Services Engine include.~ a d.ACL to restrict craffic prior to user authentication. In
!his case the dACL is named Pre-WebAuth. The policy also includes !he name of a locally configured ACL
to specify what of the allowed traffic should be redirected to the portal. ln this case the name is ACL·
W'EBAUTH-REDlRECT. lSE also specifies the URL to where redirections are sent. Note the URL includes
the common session 10 for this authentication session. W'ith this lD embedded in the URL, ISE will be able
to reco,gnize authentication for this session apart from any other centraJ web authentication sessions which
may occur in parallel. The common session ID is a unique identifie.r for this authentication session and is
used to keep the NAD and JSE synchronized.
'J'bis output may be very helpful when troubleshooting. \Vhen a user is not redirected to the guest portal,
you can test the HTrl'S connectivity by going to the redirect URL, and investigating the results.
Verify WebAuth Redirect on the Client
This topic describes how to verify WebAuth traffic redirection on the client system.
Verify WebAuth Redirect on the Client

Request HTIP(S) connection to any destination
Redirected URL displayed in browser URL entry field:
bttps://ise.securo·x.!ocal:84431goos!oortaVLogU!.action?
sessipnld=-QAOAQ102000Q()QA42399QRAS
= ~=====:
....... _.
\Vhen the traffic redirection to WebAuth has been configured on the Cisco Identity Services Engine and the
switch, the user can open a browser and connect via HTfP or HTTPS to any destination. The NAD will
redirect the browser to the guest portal and the user is prompted for authentication.
[ f the user credentials are accepted by the system. me user will be presented with an Acceptable Use J•olicy
statement. The user must accept the policy to continue. After acceptance, ISE will select a new
authorization policy based on the user status and se:nd the NAD an authorization policy update via a CoA
message. This update will remove the redirection configuration and replace the dACL with one that is
appropriate for the user. The browser will display a. me.~sage that indicates authentication was successful
and instructs the user to retry their original oonnection request
The portal may be customized in many ways, including changing the logo, color scheme, AUP message and
success message. The figure displays the default portal login screen without any custom.izations.

Verify Completed WebAuth on the ISE
'J'his topic shows how to verifY the completed WebAutb autl1entication on the Cisco Identity Services
Engine.
Verify Completed WebAuth on the ISE

Continue MAB when user not found
Traffic redirect to WebAuth
dACL permitting WebAuth communication
Successful user authentication via WebAuth
Appropriate authOOzation profile appfiec::l to user session
. ..
·--· - ---
·--• . . -........, ·--
---- .........
•
o - ...- lf•·--· ·-~~-
§-§:;i-
:;:""
~'~-
~-~·~===--,· __..,.,
·-_.,.
_ll.,..___
__ •
_v.........
..
..,._,.. • .• -
-
_ _ . .. . . . . . . . .
•
0 •
-1
--
-.- -
---
- -·
-
-
_w..,,._.,, I •
--~ -·----
--
- -- -
Tbis figure depicts an example of the Live Authentications display after the user has successfully
authenticated via central web authentication. 1-l'om the bottom, the first two events are in response to cbe
setup o f the web authentication process. Then the user sales I successfully authenticate.(i. This leads to the
successful application of Dynamic Authorization policy "ia CoA. The Authorization Profile named
Employee_Corp is implemented on interface G0/2 for the Identity sales 1. 'Below provides an example of
what L1:0 seen in the details report for the event documenting the authorizarjon profile assignment via central
web authentication:
11001 Received RADIUS /~ccess • Request
11011 RADIUS created a new session
11021 Dec ected liost Lookup usecase (Servi ce• 'Iype - Call Check 110 ))
15049 Eva luati~g Policy Group
15008 Eval uating service Selection Policy
15048 Queried PIP
15048 Queried PIP
15004 Macched r ule
24423 ISE has ~ot been abl e to contir:n -previ ous successfu l !'!'.acbL"te a u thenc i cation
tor user i n Active Direcrory
15036 Evaluating Au thorization Policy
150Jl8 Queried PIP
15048 Queried PIP
15004 Macched rule ... ~~pl oyee via Webhut_h
15016 Sel ected Au tbori2ac 1cn Profile ... ~p l oyee corp
11022 Added the dACL spec i fied in the Aut hcritation ?rotile
11002 Re tu~ned RADIUS Access- Accept
4 22
4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Verify Completed WebAuth on Switch and Client
This topic shows how to verify the completed WebAuth authentication on the switch and client.
Verify Completed WebAuth on Switch and

Client
. Client access controlled by the assigned authorization profile
. Unique session 10 is maintained 'throughout the session life cycle
a;:~-sw• t hO'W t Qtt•Ail.Uutiol'l. M n 1or.t 1ne..rtae. g1ge1tZtll•rn• t 0/ 2
l'lQ-Siolhf'AW .tutblttlt.1Co1!.1C~ ~QJUiiCilll !-nt 9~'flolbitEtbl:tfi"At. fJ/ 2
lntetf~eo:: G l(,l.u>l.t &tl\o:rne:e¢/2
~c Add«~o: ~~36. 9fh.. 31»2
:p M.d tQU : lG . : ~ . ll . lO
l!iOl'-1<4M: .ffu "J!
&utus: o\1.i.t hr S.1Jeee:n
DoN.utl (l,O,lA
Stcu.-~ty
Policy: Sl'.culd SOC>l!lt
SQcunty St.lLil:l: OI".~OCUNt
O;ler ho5t ned!!': nulti•a\lth
()per -control d.l.r: both
Ju:tbO:'!tQ:! By: Allti'IMitiCII t. !CC'I SOt'\'Ol'
v:11:'1 Policy: N/A
...~~· llfxi;;vrt;.K,;,P £nQU>rQu 1Jwu11 011".1 · ~ed f
So:~sion tim-out: '$/It
i<lh tineout 1 '$/It
l::Q-" li•a"o-,._");D~ II;~~~l!Jii:Mi
_.
<o'llty.n; cmitUI:cl>
.......
You can verify the final resuJts on the client and the switch. The client can connect ev~·here within the
allowed profile. The authentication starus on the switch displays the final d.ACL applied to the user session.
The web redirection specifications have been removed. The common session lD remains the same and
identifies the session throughout its life cycle.

Summary
Summary
Cisco ISE supports Central and Local WebAuth scenarios.
In Central WebAuth, the Cisco ISE sends the redirect URL to the NAO.
which pushes the URL to the endpoint.
Central WebAuth requires a fail-open MAB authentication and an
appropriate authorization protue.
The switch must run HITP and HTIPS service and have a WebAuth
redirect ACL to support Central WebAu.th.
You can verify WebAuth by observing HTIP and HTIPS redirection
and checking the authentication state on the access device.

Lesson 21
Deploying Guest Service

Overview
Guest services provide the functions that are required to provision temporary user accounts for guest users
and to control user access to the network. This lesson provides an over.•iew of the guest services that are
offered by the_Cisco Identity Services Engine platfonn and details how to configure the user portals for a
network deployment
Upon completing this lesson you will be able to:
Describe the purpose of lhe Cisco lS'E guest services
• Describe the interaction between WebAuth and the guest services
• Describe the Cisco 1St guest service applications
.. Describe the admin portal configuration scope
Describe the sponsor portal configuration scope
• IdentifY tlle guest user portal functions
• Describe the portals on which the Cisco ISE nodes run
• Describe the guest service configuration proced'ure
• Configure !he portal HTI'PS ports
• Describes how to manage sponsor groups
• Assign users to sponsor groups
• Configure !he gnest policies
Configure the default or custom guest portal
• Describes the guest authorization
• Describe how to provision guest accounts using the sponsor portaJ
• Describe how to verifY the guest access
Monitor guest access on the lSE
4 26
4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Guest Service Overview
This topic describes the Ci..lico fdentity Services Engine guest service.
Guest Service OVerview

Management of the full life cycle of guest access
Guest services cover the following access issues:
Gu(JSt account proporti-os suCh as:
lifetime of a guest account
Password requirements
Sponsor aocount privileges
Provisioning of guest aocounts by sponsors
Creation of customit.abkJ gue.st portals
- -
-·- -
Cisco ISE guest services cover the full life cycle of guest accounts. The users with privileges to create guest
accounts are catted sponsors. Cisco ISE guest services provide customi.zable portals for both guests and
sponsors.
The Cisco ISE administrator assigns privileges to sponsors, who in tum may define the attributes of the
guest users. Any sponsor w ith appropriate privileges can easily C·reate temporary guest accounts. Cisco ISE
allo\\'S sponsors to provide account details to the guest by printout, email, or ~]vi~. Tbe enrire experience,
from user account creation to guest network access. is stored for audit and reporting purposes.

Guest Service and WebAuth
'J'bis topic describes bow the guest services and }YebAuth interoperate.
Guest Service and WebAut:h

Guest user accounts are provisioned through guest service
WebAuth is typicalty used to authenticate guests
---
Cisco ndentity Services Engine guest services are enabled by the WebAutb functionality. When a guest user
fits[ connects to the local network, either through a wireless or wired coMection, the Cisco ISE assigns that
user a r estrictive authorization profile defined to support !!he WebAuth func tion.
WebAuth allows guests, visitors, contractors, consultants, or customers to perform an HTTP or HTfPS
login to access a network, whether that network is a corporate intranet or the public Internet. Based on the
initial restrictive authorization profile, the NAD intercepts the HTIP request and redirects it to the guest
user login portal. The user is presented widl a login page and must enter a usemame and password. After
successfuJ authentication, the user is associated with the appropriate authorization profile and is provided
with controlled necwork access.

Cisco ISE Guest Service Applications
This topic describes Cisco Identity Services Engine guest service applications.
Cisco ISE Guest Service Applications

Applteatf.on Description
Fac::Uitatos configuratioo of global policies for th& sponsoc

Admin portal
al'ld guest users
Sponsor portal FaCilitates cmalirng and managing gu<tst user accounts
Facilitates tM gu-.est user lOgin and oonsiSts o1 the

foUowing elements:
• Gues1 User login screen
• Accept Use Polley screen
• Aeqtlred Password Change screen
• AIIIJW Password Change screen
Self-Regis~ratlon screen
Devloe Registration
....... _.
Cisco IS£ guest services include three applications:
.. Cisco ISE admin portal: This is ISE's main management interface and among many other things this
portal facilitates the configwation of global policies for sponsors and guest users.
.. Sponsor portal: This portal is accessed. by sponsors and facilitates the creation and management of
guest user accounts.
.. Guest use-r portal: This portal facilitates the guest user login. It consists of the Guest User Login
screen, Acceptable Use Policy screen, Required Password Change screen, Allow Password Change
screen, Self· Registration screen, and 'Device Registration facility.
[n a distributed ISE deploymem, the admin portal is implemented on the node running me primary admin
persona. The Sponsor portal and guest portal are implemented on nodes running the policy services
personal and configured to run session services.

Admin Portal Configuration Scope
'J'bis topic defines the configuration scope of the admin portal.
Admin Portal Configuration Scope

Sponsor groups and policies
General settings
Sponsor portal settings
Guest settings
Multiple guest portals
- - I
From the Cisco Identity Services Engine admin portal, you can configure the following items:
Define sponsor groups and their associated privileges and define authorization rules that specify
sponsor group membership.
Definition of general settings including: Specify portal themes including color schemes, logo and
banner images, and manner messages. Specify the TCI' port used by different portals. Configuration of
au.tomatic purging of expired guest accounts.
Sponsor portal settings, such as me language templates, sponsor portal customiz.ation, and sponsor
identity source sequence.
Guest settings, such as usemame policy, password policy, guest portal policy, guest details policy,
mt!lltiportal settings, and time profiles.
Multiple guest portals can be configured. f·or examp!e, the portal for long term conrractors can be
different than the portal for short tenn visitors.
4.3() lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Sponsor Portal Configur ation Scope
This topic defines the configuration scope of the sponsor portaL
Sponsor Portal Configuration Scope

Customizable web portal for sponscxs
Sponsor groups specify per..group privileges
Sponsor group policy specify rules assigning users to sponsor group
---- ---
.l J I
----
- ....
. ...... _.
The sponsor portal allows a guest sponsor to create, e&t, delete, suspend, reinstate, and view guest user
accounts.
Authentication for the sponsor portal uses its own identity source sequence. The default identity source
sequence defmed in Cisco Identity Services Engine: forth is purpose is named Sponsor_Portai_Sequence
which specifie.~ the internal user database. This sequence can be edited or a new sequence can be defined
and assigned to the sponsor ponal authentication.
The ISE administrator defines sponsor groups. Eaclb sponsor group has its O\Vll unique set of privileges
including a set of authorization roles, guest role options and time profile options. 'J'he ISE administrator also
defines the sponsor group policy which is a set of authorization rules that maps users to sponsor groups.

Guest User Portal Functions
'J'bis topic describes the functions of the guest user portaL
Guest User Portal Functions

Optional screens:
Acceptable Use Policy screen
Password Change screen (required or allow)
Setf-..Registration screen: set up own user accounts
Device Registration
Static populatiOn of the intemat endpoint store
Used in .~.YQQ
- c:: : : : : : :
-
-
Tbe guest user portal consists of the following customizable elements:
Guest User togin sc.reen: This screen enables guest authentication by providing the username and
password field.<.
Acce.ptable Use Polley sc.ree-n: This screen defines the Tenns of Use agreement. It can be customized
oru a per-language basis. Its use is optional. By default it is displayed at first login. Optionally it can be
set to display at every login or it can be disabled.
Required Password Change screen: By default, guests are required to change their password upon
first login. As such, they wiU be presented this screen. Tbe requirement can be disabled.
Allow Password Change sc.reen: The guest ponal can be configured to provide a change password
link at the login screen to allow users to change their passwords anytime after the first login. 'J'his
screen will be displayed if the user selects that link. This feature is enabled by default.
Self· Regi.stration screen: This screen is an optional screen that allows guests to set up their own user
accounts.
Device Registration: If enabled. this option allows guest user accounts to setf.register a predefined
nwnber of endpoints by ~~· Registration resuJts in static population of the internal endpoint
store without a default fD group assignment. User needs valid credentials to register devices.
Portal Services Location
This topic identifies the nodes on whlch the portals are running..
Portal Placement
Admin portal runs on the adminis,tration node (admin persona)
Guest and sponsor portals run on PSNs with session services enabled
--....- - - __-- -
---
:'*':'::-::"';,.. _ _
~
-----
- .......... -· . ~§.~-;__
· - - --- -.. - - - - -
~ - - ·-
·- c
•·
--
-
--
·-- ·_·-~
,.,.....,_....,.1-)
-- --- -~
I __ __..
....... _. - -·
Cisco Identity Services Engine supports a distributed deployment to allow for multiple Cisco !SE nodes to
communicate with one another, providing scalability and fault tolerance. In distributed deployments, ISE
functionality is divided amongst tl1e admin, monitoring and policy services personas.
The admin portal runs on the Cisco IS£ node running the active admin persona. The guest and sponsor
portals run on on all nodes which have the policy service persona configured with the session services
functionality enabled.
Guest portals must be located on the same policy service nodes that manage the RApru~ requests that
arrive from the NADs. For example, if a node is used. to manage RADIUS reque.~ts for a iNAD that depends
on Central WebAu!h support, the guest portal must be enabled on that node.
Ln this figure, the ISE runs in a standalone deployment. In this situation the session services are activated by
default and cannot be disabled.

Sponsor Portal Configuration Procedure
'J'bis topic describes the configuration procedure of the Cisco Identity Services Engine sponsor portal.
Guest Service Configuration Procedure

1. Configure portal HTTPS ports (optional)
2. Configure sponsor settings:
Manag& sponsor g.roups (optional}
COtlfigum sponsOr group privileges (op~ional)
Assign user$ to sponsor groups
3. Configure guest settings (optional)
Manag& default or custom guest portalS
COnftgur& guest policies
4. Configure guest authorization
5. Provision guest accounts
Tbe co.nfiguration of the ISE guest services can include many customizable elements. Tbe key steps are
listed in this procedure:
I. Configure portal HTTI'S ports (optional).
2. Configure sponsor settings:
Manage sponsor groups (optional).
Configure sponsor group privileges (optional).
Assign users lO sponsor groups.
3. Configure guest settings (optional).
Manage default or custom guest portals.
Configure guest policies.
4. Configure guest authorization.
5. Provision guest accounts.
4-3.4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Configure Portal HTTPS Ports
This topic illustrates how to configure portal§§!: ports.
Configure Portal HTTPS Ports

. --
---
·---··---
---·-- .. -----
• • 0
_......, . . .!"lf!Wol____
__ . . . _
.... .
....., I.
··-
~-
---
-
--
r=:=--c==:=7=->
·- ·
<
!
~--"":
·a-·-
·-
. --- ·-
IJ
...--.o;
--i·- i"iJ
l '- •· ·
---·-1
-- •
----
~~--._,
4 . ~6fl0"'0' pottiiPOft ....,., .J
·-·
·-- · ----··--
--..-toou_
0
__ _.. .....,_ ...

....... _. oeo---~
~
You can customize the sponsor portal and configure general sponsor settings that govern how sponsors
acces.~ customized web portals to create and manag.e guest user accounts. To manage the HTI'l'S ports,
choose Administration> Guest Management> Settings, click the icon next to General, choose ·r orts,
and review the default network ports that are used for sponsor and guest portal access. By default, TCa) port
8443 is used for secure portal access by both sponsors and guests.
Optionally, you can define an FQON for the sponsor portal that is easier for the sponsors to remember. If
you choose to implement this, you must also insure that .~":'!:i resoloution for the FQDN is set up. Also, the
certificate installed in lSE should specify this 'fQDN as a Subject Alternative Name to avoid broYt-ser
v.'3Illing.s on HTfPS sessions.

Manage Sponsor Groups
'J'bis topic describes bow to manage sponsor groups.
Manage Sponsor Groups

Sponsors acquire privileges from sponsor groups
Three default sponsor groups
.,....... _·--
- -.....----
... ---
·-- -- __-- .,....
..._ -- ---
--
--·- -
-----·-
..
·---
Users are assigned to sponsor groups, from wlUch they acquire privileges to provision guest users. Cisco
Identity Services Engine comes preconfigured with three default sponsor groups:SponsorAliAccoums,
SponsorGroupGrpAccoums, and SponsorG'roupOwnAccounts. Guest sponsor groups define the permissions
and settings for the sponsor user. Sponsor users that belong co a particular sponsor group have a certain set
of permissions and settings when they log into the sponsor portal. The fS£ administrator manages sponsor
groups and sponsor group assignments.
Sponsor group configuration is available under Administration> Web Portal Management> Sponsor
Groups. The settings for each group are configured under four tabs: General, Authorization Levels, Guest
Roles and Time Profiles.
Tbe only setting under the General tab is the sponsor group description.
Several permissions are configured under me Authorization Level tab. The allowed methods of creating
accounts is set here. Create Single Account allows for creation of accounts one at a time. Create Random
Accounts and import CSV allow the creation of a set of accounts. Also. methods of infomting guests of
their accounts including ID and password information is set here. Options include Send £mail, Send SMS,
View Guest Password and Allow Printing Guest Details. Other management features such as the ability to
View/Edit Accounts and Suspend/Reinstate Accounts is configured here.
'J'he ISE administrator can define different guest roles and allow sponsors in a given sponsor group the
privilege to create guest accounts in certain roles. Guest roles allow a sponsor to assign different levels of
access to a guest account. These roles are used in the authorization policies to relate guest user accounts to
identity groups. You configure the selectable guest roles under the Guest Roles tab within the sponsor
group configuration menu.
'fime Profiles specify the duration of a guest account in terms of minutes, hours, days or years. When the
timer begins (fromCreation, f'romFirstLogin or Starttnd) is also set under the time profile. Account
expiration notification and any time restrictions (su-ch as logins only permitted on weekdays during business
bours) are set under time profiles. Tbe lSE administrator defines the different time profiles and also defines
which time profiJes are available to the sponsor group under the Time Profiles tab.

Assign Users to Sponsor Groups
'J'bis topic describes bow to assign users to sponsor group's.
Assign Users to Sponsor Groups

Sponsor groups are populated using the Sponsor Group Policy
Policy rules consist of:
Nama
COodiliOns (identity groups and otMr conditions)
Result: assigned sponsor group
---
--- -- --
......, _____..,., .._ _ _ _ _ _ _ c-...._ _ _ __
----~,.,
•· ., --
The assignment of the sponsors to s-ponsor groups is configured in the Sponsor Group Policy. Similar to
authorization policy, the sponsor group policy consist~ of one or more rules. Each rule is identified by a
name and includes one or more conditions and a result. The conditions can either identifY a user identity
group or include other defmable conditions. The result s-pecifie.c; the sponsor group assigned to users who
meet the conditions in this policy rule. The sponsor users acquire privileges from the sponsor groups.
Configure Guest Policies
This topic explains how to configure the guest usemame policy.
Configure Guest Policies

Guest policy example: usemame policy
Method of construing the use marne: based on email or names
Additional settings, such as usemame length and randomization
--- --- ·--

---
"- .. -...._.
......
.- -·· --·-
··-- .. - .
~ .
...
-··-
·...·-._ --· -.-----
______ _ ..,...
···--
-··-_,_
-- - -·---·---- ___ .._.. __ [.....,.,__..,======:
... __
-
-
··--.......
__._,)_...._...... ~
. ...... _.
You can configure various policies that control the generation of guest accounts. One of the available
policies is the username policy, which is shown in the figure. The guest Username Policy configuration
page allows you to specify how usemames will be created for the guest accounts. The Username Poli.cy
configuration screen has two main sections: General and Random.
You can create a guest usemame that is based on the email addres.~ or the first and last name of the guest.
The configuration is perfonned in the Administration > Guest Management> Settings> Guest>
1!Jse.roame Policy menu.
The Random configuration section offers the option to choose the characters that are used for generating
random user accounts.
Other configurable policies are the details and the password policy.
The guest details policy determines the data that the sponsor needs to enter to create a guest account. In the
Details page, the Cisco Identity Services Engine administrator must define the fields that should appear on
the Sponsor Guest User Create and Edit pages and in the Guest User Self-Registration page.
The guest password policy detennines how me password should be generated for all guest accounts. You
can create a password policy that is based upon a mixture of alphabetic. numeric, and special characters.

Manage Guest Portals: Default or Custom
'J'bis topic describes bow to configure the operation of the default and custom guest portals.
Manage Guest Portals: Default or Custom

Multiple guest portals can serve different guest groups:
For example, countries with other languages
ldantified by specific u~
---
-··- ·-- ·--
--- --
··--- ---
···--
--
- -·-·-
_____
...._
-
__ -
..
..,
·--
o ~-
----·
-
··-- m---
---
2---·-----
-- ~-----
o------
----··--
The Cisco Identity Services Engine allows you to host multiple portals on the Cisco lSE policy service
nodes. The default portal pages are dynamically generated and provide features such as changing a
password and seJf.registration in the login screen.
Tbe default portal themes have standard Cisco branding by default. There are several simple customizations
that can be made under Administration> Web Portal ~t:anagement >Settings, General> Portal
Theme. 1-~or example you can provide your O\VIl login page logo and banner logo as well as background
images and color schemes.
You can also choose to completely customize a portal by uploading HTML pages lhat are specific to your
organization. These pages must use plain HTML code and must contain form actions that point to the portal
back-end servlets. You must define separate HTML pages for login, A~..f. the change~password function,
and self~registration. Additionally, when you crea[e custom portals by uploading your own HTML pages,
!he details policy,language templates, and portal themes do not apply.
Tbe predefined DefaultGuestPortal, which is shown in tihis example, is available under Guest > MuJti..
Portal Configurations.
In the Operations- tab of the portal configuration, you can defme the foiJowing guest actions:
Guest users should agree to an AUP. The selectable options are Not Used, •trst Login, and £very
Login.
Allow guest users to change passwords.
Require guest and internal users to change passwords at expiration.
Guest users should download the posture client.
Check the VLAl''i DHCP Release oprion ro refresh rbe !P addres~ of Windows clients after a VLAN
change. ·J1Us option applies to wired and wireless emti.ronments for guests with no posture.
.. Guest users should be allowed to perform self .service.
Guest users should be allowed to perform device registration.

Configure Guest Authorization
'J'bis topic describes the guest authorization.
Configure Guest Authorization

Two built-in identity groups: Guest and ActivatedGuest
Guest authorization rules built using:
ldo.ntity groups
OtMr conditiOns
-
_.., ___________....___.. _
--·-·- ·
__....._
·-
---
•'
___ __
____ ..,..,...__
___
I
I
---
--
--
- -
_._ __ ,
-~......,-
--
I
I
I
·~--
- ------·-
- -
You should configure authori2:ation policy rules for guest users if you don't want them to be authorization
using the default rule.
Cisco Udentity Services Engine defines two guest roles, Guest and ActivatedGuest. Tbe guest role mwt
authenticate via the web portal. The ActivatedGuest role may authenticate via the web portal or via 802.1X.
ISE also provides two user identity groups named Guest and Activated.Guest. Tbese rn·o groups are
assigned to dle guest role that matches their name. The guest role assignment of a user identity group is set
under Administration> \\'eb Portal Management> Settings, Guest > Guest Roles Configuration.
'J'he figure shows the authorization policy rule list, highlighting the rule that assigns users in me either the
Guest o r the ActivatedGuest user identicy group the authorization profile named Guest_Profile.
4~2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
Provision Guest Accounts in Sponsor Portal
This topic describes how to provision guest aocounltS using the sponsor portal.
Provision Guest Accounts in Sponsor Portal

Connect to https://<PSN·FODN>:8443/sponsorportal
Options: Create Single, Create Random. and Import Guest Accounts
Create Account
.....,
J __ ~-....,._
·---
- " - - - - -.
·--~ - -.
·-- r
To create guest accounts, connect to the sponsor portal and Jog in as a sponsor user. The sponsor portal is
accessible a< the address https:i/<J>SN-FQDN>:844 3/sponsorportal. Tbis address assumes that the default
port 8443 of the sponsor portal has not been changed for the adrnin portal.
One method of provisioning guest user accounts is :for a sponsor to manually create individual guest user
accounts. The attributes that are presented to the sponsor have been defmed in the guest details policy_ Tbey
generally include first name, last name, guest role and account duration.
Alternatively, you may create a number of random users w ith a single request. ln order to configure random
U.liers in the sponsor portal, choose the Create Random Guest Accounts menu from the main Sponsor
Portal window. You will then specify the number of random users to create, a username prefix (if any), and
the guest role to which these users should be added..
The third option is to import guest user accounts from a CSV file. Tbe template file determines the fonnat
of the file. The template file can be downloaded and viewed using the Download Import File Template
button. The file template contains a comma-<l.elimited list of attributes. The file template does not contain
any line feed characters.

Verify Guest Access
'J'bis topic describes bow to verify the guest acce.111s.
Verify Guest Access

"' d·
(1\(0 ~· •••
·----.
Slgn<d on sutt«sfultv
You can now type In the originol URL in 11>e .,..,....,., iddres< bor.
This sl.ide depicts the default authentication operation of t he guest portal. The user is first challenged for
credentials. If they provide valid credentials they are preSJented with the Acceptable Use PoUcy page. Wberu
user accepts the AUP conditions, they will be required to change the password (now shown here). They are
then infonned about the successful login and they can reconnect to the original URL, or make any other
network connections that are allowed by dleir authorization profile.
Tbe use of an acceptable use policy and password change requirements are options that can be changed by
the Cisco Identity Services Engine administrator.
4~4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Monitor Guest Access on ISE
This topic describes how to monitor guest access ott the Cisco Identity Services Engine.
Monitor Guest Access on ISE

ISE continues when MAS fails
Autholization profiie redirects traffic to WebAuth
Successful guest authentication
. --
Appropriate authorization profile applied to guest
---
·- - ·--
--~ •
- - -
····-
-----· --· •
· ... .....
•
-
---- ~ •
'
---·-
- ......-.. - --
~~-- · ......
_. . . .... . -
.-.~.,
..
_..._u..,».._ •
- . . ......
-"--'"
.,. •
---
--·---
----- -
- - -oo.
__
...,..,..._ . ~··---
--- - -~
You can monitor the guest access in the ISE authentication page. This figure illustrates event records from
the process. It starts with a succeeded authentication when the guest user fails the MAS and the IS£
continues because the user is not found. The lSE redirects tlle client traffic to WebAuth using tlle
\VEBAUTH authorization profile. When the guest opens a browser and attempts a web connection, the
session is redirected to the guest portal. The user successfully authenticates, and the ISE assigns the
appropriate authorization profile to the guest sessiO'.n.

Summary
Summary
Cisco ISE guest services allow sponsor,s to create guest accounts.
Guest service applications are the admin, sponsor, and guest port.als.
General guest service settings include, among others, portal HTIPS
ports.
In sponsor portal configuration, you define sponsor groups, identity
source sequence, guest conditions. and policy rules.
Cisco ISE supports multiple guest portals.
Sponsors access the sponsor portal to create individual guest
aeeounts, create multiple random user aeoounts. or import guest
accounts from a file.
Cisco ISE provides three types of reports for guest and sponsor
activities.
Module Summary
Module Summary
WebAuth enables access for usetS without an 802.1X supplicant.
Guest services provide management and operation of guest user
access.
0,.,.__.._
References
Module Self-Check
Questions
I. In which scenario would you deploy WebAuth? (Source: Deploying WebAuth)
A. network printers without an 802. \X supplicant
B. company employees with a new 802.1X supplicant
C. guest users
D. sponsors using a new endpoint type
2. Which traffic type must be pennitted in the redirection ACL that is configured on the switch?
(Source: Deploying WebAuth)
A. RADIUS communication with the Cisco IS£ nodes
B. synchronization traffic between the Cisco IS'E nodes
C. HTTP or HTI]'S traffic to the Cisco lSE policy service nodes
D. HTtl' or HH"I'S traffic that is eligible Cor redirection
E. all traffic to the Cisco ISE nodes
3. How do you configure the Cisco JSE authentication policy for WebAuth? (Source: Deploying
WebAuth)
A. to continue if the authentication failed

B. to continue if the user is not found
C. to continue if the process failed
D. to continue if the 802.1X supplicant is not available
4. \\'hat is a valid configuration for the sponsor and guest portals'? (Source: Deploying Guest Access
Services)
A selection of H"ITl' or H1Tl'S protocol that should be used
B . H·np port
C. HnPSport
V. identity cenificate to be used for authentication
5. On which Cisco ISE nodes would you enable sponsor and guest portals? (Source: Deploying Guest
Access Services)
A. the sponsor portal on different nodes lh.an £he guest portal. to distribute load
B. the guest portal preferably on redundant nodes., to distribute load
C. the sponsor portal on the policy service nodes ·that process user access requests
n. the sponsor portal on the admin nodes, because they are used only for provisioning
6. The sponsor group poliey ean be used to define guest aeeount restrictions. (Souree: Deploying Guest
Access Services)
A. true
ll. false
4--60 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Answer Key
I. c
2. 0
3. B
4. c
5. c
6. A

4.$2 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Module 51
Endpoint Access Control

Enhancements
The Cisco Identity Services Engine offers a range of advanced endpoint access control features. You can
use them to enforce compliance and enhance infrastructure security. This module discusses the posture,
profiler and Bring Your Own Device (BYOO) soiUJtions.
Upon completing !his module, you will be able to:
.. Describe the posture assessment and the use ofNAC agents
• Describe the Cisco lS£ profiler and lhe endpoint identity groups
• Describe the BYOD solution elements and device onboarding
Lesson 11
Deploying Posture Service

Overview
The Cisco Identity Services Engine posture service provides you with the ability lO check the health of
endpoints and, depending on the results, assign app.ropriate connectivity permissions. Cisco ISE detennines
the security posture by obtaining from the NAC agent of the endpoint the status of various software
components, such as service packs, software patches, and antivirus and antispyware applications.
Describe the Cisco ISE posture service
• IdentifY the posture service in the overall Cisco IS£ processing flow
• Describe the persistent iNAC agents
• Describe the Cisco NAC Web Ageot
Describe the cljem provisioning process
• Describe the posture conditions
• Describe the role of Change of Authorization in the posture assessment
• Describe the posture configuration procedure
.. Describe how to download the client provisioning resources to cbe JSE
.. Describe the configuration of the client provisioning policy
• Describe the posture policy building blocks
.. Describe the configuration of posture conditions
Describe the configuration of posture remediation
.. Describe the configuration of posture requirements
.. Describe the configuration of posture policy rules
.. Describe the configuration ofposture~related authorization conditions
Describe tl1e configuration of posrure~related authorization policy
• Describe how to verify client redirection to CPP
Describe how to verify the remediation
Describe posture verification using the Cisco ISE authentications page

Cisco ISE Posture Service Overview
This topic describes the functional areas of the post.ure service.
Cisco ISE Posture Service Overview

Functionalrty to determine the security status of the endpoints
Leverages NAG agents
ConfiguratJ.on
.,... Function
Client provisioning Automates NAC agent installatiOn and updates

Postura policy Oof10es the "hearth· raquir&ments of endpoints
Authorization ConsiderS the posturo status:
policy If unknO\m, redirect to client provlslonlog portal
If CCiflllllant. grant oontrolled access
If ooncompllant. enf<lroe ap~ate security policy
The Cisco ldentity Services Engine posture service allows you to check the security posture of the
endpoints that are connecting to your Cisco ISEwenabled network. The Cisco ISE validates that the endpoint
state is compliant with your corporate security policies before a client is given access to protected areas of
your network.
The security posture of the endpoints is communicated to the Cisco ISE policy service node by NAC
agents. The NAC agents are installed on the clients and interact with the posture service to enforce security
policies on the endpoints. They assist you in evaluating clients against posture policies and ensuring that
eliems meet requirements that are required for COnl5lliance with the security policies ofyour organization.
The posture service has three main functional areas :
• Client provisioning: Client provisioning automates NAC agent deployment by pushing the software to
endpoint~ that do not have the required version of the expected NAC agent. The cliem provisioning is
(acilitated by the client provisioning portal.
.. l,o.sture policy: Posture policy defines the terms compliant and noncompliant in a specific company
policy. For example, compliance may mean a certain version of antivirus and antispyware software that
is installed on the endpoint.
Authorization policy: Tbe authorization policy is implemented in a way that reflects the noncompliant
and compliant states of the endpoints. The authorization policy will enforce stricter security policy on
noncompliant endpoints and grant more privileges to compliant endpoints. Jftbe endpoint status is
unkno\\'ll, the authorization policy will redirectt the traffic to dle client provisioning portal.

Posture in Cisco ISE
'J'bis topic identifies the posture service in the Cisco Identity Services Engine processing.
Posture in Cisco ISE
l~jl-
<S>-11 --
······;;;~;j~~-;;;·;
·-·
.......,..._..1
c•.--....,....._ Il-l t
~' I=:: I-
-c:o..... I
I
.......
-- q --
J Aucl'loriZIIIOn Po ~~~
I I ~ .... ~
-·
- - 1-1 ~
~ll=- -=liE-- "=ll=-

IB EJI I[::::] I'C' 1111...=..11 p ..., .
11- 11
...~!.~:~!..
....... __,
..:;;:;,;,..L
'
~oKt -
'J'be posture service is an optional function of the Cisco ISE that may or may nor be deployed in a Cisco IS£
environment. The posture service interacts with the Cisoo ISE authorization function via the ~·
Immediately after authentication, the posture status of the endpoint is unknown. When the posture service is
invoked and the endpoint starus is assessed, the status will change to noncompliant or compliant:
W.hen the noncompliant status is returned by lhe posture service, a CoA is issued, and the Cisco lSE
applies the appropriate authorization policy to the endpoint. This authorization policy typically enables
the endpoint to access necessary remediation resources. After successful remediation, the endpoint is
assessed again and its status is changed to compliant..
When the compliant status is returned by the posture service, a CoA is issued, and the Cisco IS£
applies the appropriate authorization policy to the endpoint. This authorization policy enables the
endpoint to access internal enterprise resources without a risk of infection. Periodic reassessment of the
security posture ensures that the health of the system is maintained while the endpnint is pted
co.ntrolled access to lhe enterprise resources.
5.0 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
Persistent Agents {Windows and Mac)
This topic describes the persistent NAC agents for Windows and Mac endpoints.
Persistent Agents (Windows and Mac)

Typically used on managed devices
Installed from Web or MSI with administratOf rights
Guides user through posture and remediation process
....... _.
The persistent NAC agents, available for Windows and Mac computers, are typically used on managed
devices. ·ney support localization, U..(!ing the more common languages. The agents can be installed from the
\Veb browser or using the MSI package. Administrator rights are required to install or update che agent
software. The agents are capable of handling user logons and §Q in an 802.1X environment. The NAC
agents guide users through the posture service, support the posture remediation, and infomt me policy·
service node about an !t!~! change that occurs white a session is active. The Cisco Identity Services
Engine supports automatic NAC agent updates.
C 2014 Clsoo Sys1ems. Inc. Student Guide $-7

Web Agent
'J'bis topic describes the Cisco Network Admission Control Web Agent
Web Agent
Often used for unmanaged PCs, guests, and contractors
-
Temporal agent based on ActiveX or Java
Guides users through posture and limited remediation
---
-
'"' - - .
·•11·•1•·
Cttco
______..
_
___ __ --·-
C"-"··--
._
......
....____ ,.._
---··--···
-·-------~-------
0 ...
--~
~-
-
·---- .....-
Tbe Cisco NAC Web Agent is typically used for unmanaged PCs and guest access. The agent is temporal.
and requires ActiveX or Java to be installed on the endpoints. It supports the Cisco Identity -Services Engine
posture service, but offers less remediation options than tbe persistent agents. The web agent is also capable
of refreshing endpoint .Qt!ff addresses in the case where policy application enforces a~ change.
5-a lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Client Provisioning Process
This topic describes the client provisioning process.
Client Provisioning Process

1 Cisco I SE collects various data from a client via the NAG agent:
Operating system type and verSion
BrOWser type and vorsion
Custom eval.lation r$Sui1S
2. Cisco I SE processes the d-ata according to the posture policy
3 Based on the provisioning policy, the ISE applies to the endpoint:
NAC agent
Complianco modules for antivirus and antispyware
Agent customization paCkages and profiles
....... _.
Client provisioning is responsible for pushing appropriate NAC agent software or configuring a native NAC
supplicant on the endpoints. The Cisco Identity Services Engine looks at various elements when classifying
the endpoint, such as the client machine ope.rating system and version, the client machine browser type and
version, the group to which the user belongs, and the condition evaluation results (based on applied
dictionary attributes).
After lhe Cisco lSE classifies an endpoint, it uses client provisioning resource policies to ensure that the
endpoint is set up with an appropriate agent version, up-.to~date compliance modules for antivirus and
antisp)"\\'3Ie vendor support, and correct agent customization packages and profiles. The up~to.date
compliance modules for antivirus and antispyware software are needed to verify if the endpoints run the
required antivirus and antispyware applications and have up·to-<late signature databases. Instead ofus.ing
the NAC agent, client provisioning could configure an appropriate native supplicant on the client device.
The customization of the client package parameters is achieved with the use of profiles that defme the
software packages that are to be provisioned, their version, and if applicable, their database version.

Posture Conditions
'J'bis topic describes the posture conditions.
Posture Conditions
Posture policy verifies specific attributes on the client system
Posture conditions can check for the following:
Wil'ldows updata:s
Antivirus and antiSpywarQ
Registry, liJQ and servic& data
-- -
Automated rulesets for more than 350 partner applications
IJ)l
q,..
-- -
fll
-
· ®
..-._ --
·- - :>< IIIII
Posture conditions are used to check specific attributes on the client system. A posture condition can be one
or any combination of the follo\ving conditions:
'File condition: This simple condition checks the existence of a file, the date of a file, and the versions
of'a file on the client. This conclition is available for Windows computers.
Registry condition: This simple condition checks for the existence of a registry key or the value of the
registry key on the client. lhis condition is available for Windows computers.
Application condition: This simple condition checks whether an application (process) is running on
the cHent This condition is available for Windows computers.
Ser\'ice condition: This simple condition checks whether a service is running on the client. This
co.ndition is available for Windows computers.
Dictionary simple condition: Tllis simple condition checks an attribute that is associated to an
operator and the operator to a value.
Examples of common posture conditions include tlle following:
Wlndows update verification: ·nus posture condition verifies the proper service pack and patch
levels.
Vtrus appllc~tion verification: This posture condition verifies that the client has the coJTeCt antivirus
software installed. This function may also be used in a Jess restrictive capacity to verify that the client
simply has any antivirus installed.
Virus definition verification: This posture condition verifies that virus definitions are newer than a
specific date.
Wlndows screen save.r password verification: This posture condition verifies that the client has a
Windo\\'S screen saver password configured.
5·10 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, l nc.
.. Re.gistry e.otry verification: This posture condition verifies me client regL~try key.
The Cisco Identity Services Engine provides automated rulese[S w simplifY management for more than 350
panner applications, including Microsoft Windows, online services. and antivirus sofhvare vendors.
\Vhen deploying posture services. maintenance of current posture elements should be considered. IS£
supports updates from www.cisco.com. The updates can be manually initiated or scheduled to run on a
recurring timer. These features are available in the lSE adminisrration GUI under Administration>
System> Settings, Posture> Updates.

CoA in Posture Assessment
'J'bis topic describes the role of Change of Authorization ~ n the posture assessment
CoA in Posture Assessment

Status of endpoint without NAG agent is unknown
Authorization profile fOf unknown status:
Rodirects to dient proviSioning portal
Restrict$ traffic
Cisco ISE obtains infonnation from NAC agent and sends CoA
ISE applies authorization profile for compliant or noncompliant status
Tbe Cisco Identity Services Engine uses the CoA feature to facilitate the posture service. When a ne\'o'
endpoint is connected to the network, if it does not have a NAC agent then its posture status is unknown.
'J1te ISE authorization policy has a rule that matches the unknown status, redirects the client to the client
provisioning portal and restricts the client traffic. When the user opens a browser, the session wlll be
redirected to the client provisioning portal and the user wi ll install an appropriate NAC agent
·111e NAC agent collects the security po.sture information and sends to the JSE. "Jlle !SE declares the
endpoint as either compliam or noncompliant. Tbe JSE sends the CoA to signal the endpoint that a new
authoriization profile will be applied and assigns an appropriate authorization profiJe to the client session,
Posture Configuration Procedure
This topic describes the posture configuration procedure.
Posture Configuration Procedure

1 Configure posture administrative settings
2. Download client provisioning resources to the ISE
3. Configure client provisioning policy
Assig.n NAC agent type de-pe-nding on OS and otMr conditions
4. Configure posture policy
Posture requirement (met if posture condition else posture remediation)
Posture po(icy rules (if certain oonditioos then posture requireme-nt)
5. Confi9ure authorization policy
Unknown: redirod to client provisioning penal and restrict acc&SS
Compliant: grant contrOlled acc.:.ss
Nonoomp!iant: ' estrid access
....... _.
Posture administrative settings penain to the client provisioning service, agent profiJes, posture settings,
reassessments, and updates. They are omitted from this lesson in favor of the key elements. The settings are
defined under Administration > System> Settings, Posture in the Cisco Identity Services Engine
administration GUl ln a production environment, the posture update policy should be considered. Posture
updates include a set of predefined checks, rules, and suppon charts for antivirus and antispyware for 'both
\Vindows and Macintosh operating systems, and operating systems information that are supported by Cisco.
You can also update Cisco lSE offline from a fiJe o,n your local system, which contains the latest archi ves
of updates. Timer based automatic posture updates can be configured in the posture administrative sening.s.
To suppon client provisioning, you should first dov.'llload the appropriate agents to lSE.
The client provisioning function is responsible for the automatic update of installed NAC agent software
and the automatic configuration of a native supplicant, along with the required packages, on dle endpoints.
A posture policy defines the technical terms that describe the compliance requirements. For example, a
compliant endpoint can be a client machine with up.to~date antivirus software. A posture policy consists of
one or more rules, and each rule is identified by a name and configured to match one or more conditions.
Although not strictly a part of the posture service, the Ci.iiico lSE authorization policy plays a pivotal role in
the overall posture operation. The authorization policy needs to be adjusted to reflect the compliant,
noncompliant, and unknown endpoint states.

Download Client Provisioning Resources
'J'his topic describes bow to download the client provisioning resources to the Cisco Identity Services
Engine.
Download Client Provisioning Resources

Load required resources from Cisco site or local disk
Clients will fetch the resource assigned to them
WMn d ients aro r edirected to gue.st pr-ovisiOning portal
Client provisioning policy maps resources to devioo type.s
.--- --·-·-·
~ ---
-.- ~- £-
•·
··-
·\ .
··-
. - --#- - . ,_
. ..-·· .. - - .. - - .
---
~-'
--·
·- - ----
__ -~
-
;,;_
··- -·- I; •
- -·
--- l -
-- --
-- -
··--
:1=-
- --- --·-
-- --
·-_::
Client provisioning is responsible for the automatic update ofinstaiJed NAC agent software and the
automatic configuration of a native supplicant on tlle endpoints.
You need to download the required client provisioning resources to the ISE. When downloaded, the fS£
will be able to redirect the endpoints to the client provisioning portal from which they will be able to fetch
rhe NAC agenr suited for them. The type of the NAC agem appropriate for each device type is defined by
the client provisioning policy.
Configure Cl ient Provisioning Policy: Operating
System and Conditions
This topic describes the configuration of the operating system checks and conditions for a client
provisioning policy.
~------------------------------~
Configure Client Provisioning Policy

Mapping ofNAC agents to device, user, and access types
--.
• Used in other appUcations. such as~
--- c....,. a-
.
..---- - -- --
._._ ..,____
:::::!:::.."'r-
'1:!!~
,...,..., _ _ _ . .....J
.... . ...._
t )j
••••
·-·......
·-·
·-"-
·---
_.. •·
·-
·-- _..__( __
..... __--_
·-- ·-·
.~-
Ofo'll-- ·r-,.-
--~·--
The client provisioning policy is the central element oftbe client provisioning feature. The policy is built
using an intuitive approach that you know from the authentication and authorization policies. Client
provisioning consists of one or more rules that you can edit, delete, duplicate, and reorder. Each rule has a
set of conditions (identity groups, operating system cype, and other conditions) and, if they are met, the
specified results are applied. The results deftne the .required NAC agent or native supplicant software.
\Vhen specifying the operating system condition, choose from the predefined operating system types, such
as Android, Mac OS X, Apple iOS, or Microsoft Windows. You can collectively select the Windows- All
option or specify Windows 8, Windows 8.1, Windows 7, Vista, or XP individually.
Each client provisioning rule contains the Results colwnn. ·ne results contain the NAC Age.nt
Configuration and the Nath•e Supplicant Configuration sections. Tbe results are used to defme the
software that will be provisioned on the endpoint if aU conditions in the policy rule are met.
Depending on the endpoint operaring systems that are used in your environment, you may want to pro.vision
a native supplicant software. In that case, you have the option of specifYing the required configuration
wizard and wizard profile.
The NAC agent settings allow you to specify the following:
• The NAC agent type and release.
• The agem profile that you used to defme various timers.
• The compliance module.

Posture Policy Building Blocks
'lllis topic identifies the building blocks of a posrure policy.
Posture Policy Building Blocks

Posture policy rules include posture requirements
Posture requirement matches conditions and defines remediation
Example:
·Av installation Win": if WindOws then Any_AV_InstallatiOn_Win
~Any_AV_I nst.al!atiOn_Win": f or Windows met if ANY_av_win_instelse
LaunCh_Clam Win_lnsttJll$r
Po.u.w• policy . . I
11 •,.,.,..1, 1 -- I ..., ~ "" I OU>ol
I ~re require,.-,; I
11 ·...·-~I ... EJ .,,.,_,_,_ I .. 5
II
A posture policy defines the technical terms that describe the compliance requirements. For example, a up·
to--date: antivirus software may be a requirement for compliance. A posture policy consists of one or more
rules, and each rule is identified by a name and configured to match one or more conditions.
Tbe pc>sture condition can be specified as a single or com3)ound condition in several categories: file,
registry. service, application, regular compound condition, antivirus, and antispyware.
Tbe differenriator of the posture policy from other policy rypes is the requirements deftnition. Tbe
requirements are written as an expression: "Requirement for 'OS' met if'posture condition' else
'remediation."'
Tbe remediation defines the action that must be performed, if the posture condition is not met, for the
endpoint to achieve the compliant status. 1"he remediation actions can be of different types: antispyware
remediation, antivirus remediation, tiJe remediation, launch program remediation, link remediation.
Windows Server Update Services remediation, or Windows Update remediation.
'Tbe above example of a posture policy rule and a corresponding posture requirement can be used to install
ClamWin antivirus software if no AV software is found on the endpoint. The posture policy rule named
"AV Installation Win" could read: if Windows then Any_AV_installation_Win. The posture requirement
named "Any_AV_Installation_Win" could read: for Windows met if ANY_av_win_inst else
Launch_Clam Win_Installer. Tbe Any_AV_fnstallation_\Vin requirement is one of the defauh requirements
pre-.ins.talled on the Cisco Identity Services Engine. The ANY_av_win_inst condition is one of the default
cond.iti.ons preinstalted on the ISE that checks for any installed AV software. Tbe configuration of the
Launch_ClamWin_Installer remediation will be demonstrated in the configuration procedure.
S.16 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Configure Posture: Condition
This topic explains how to configure a posture condition.
Configure Posture: Condition

. Checks the state of a software component
.-
-- - - ..-,..... . .---• ...---
.... . - ·
..- - J
~ . --
... ~- ~--
/IN~CtoollliO'>o
- ..-:1 -.......·---
--
_,_.,..__-
••••
-·--
-
:.--
w--
a - ...--
,- 0--- . oa ....
- ... _ ...
......
..... !. . . . . I
·-.......
-~-
·-- ..
- r;. -~
•
....... _.
. _...__·-----·
---
-- ·-
- ___
·-
-
..... --
_""7(;;,- :::m
..___. -...
O• • •
·~
.,_
·-~
.....--..-
. • o--..-
- ·--
Posture conditions are used to check the state of a software component on the client endpoint. They can
have different cypes, including file, registry, application, and service. The ,~);:!_, .!.\§. conditions check for the
existence of and the update status of A V and AS so-fhvare.
This figure iJiustrates an AV compound condition. ·ne Vendor drop-down box allows you co match any
vendor or a specific manufacturer. 'fbe Cbeck Typ:e radio buttons allow you to specify whether the Cisco
[dentity Services Engine should only check the existence of the antivirus software on the endpoints
(Installation), or the up-co-date state (Definition). The remaining fields are used to defme the versioru
requirements.

Configure Posture: Remediation
'J'bis topic describes bow to configure the remediation.
Configure Posture: Remediation

Action to secure an endpoint
Triggered if requirement condition not met
.......___
- -
--.
._ -·--
---
··-
··-
··-...,____ ____
CO· .._.
···--
-··- ..
··-
., ___
v------
·~
......
-- ..._
. ~.,..
··--
··--- _._
-.-
--- --
·-··-- ...
Tbe remediation is an action perfonned to secure an endpoint lt is launched if the requirement condition is
not met. The remediation can be manual or automatic. There are various remediation types: AS, AV, file,
Launch Program, Link, Windows Server Update Services:, and Windows Update.
This scenario shows a launch program remediation. It will install ClamWin antivirus if no AV software is
identified on the endpoint. The remediation specifies the absolute path of the executable. The executable
will be launched automatically by the NAC agent
Configure Posture Policy: Posture Requirement
This topic describes how to configure posture requirements.
Configure Posture: Requirement

Checks conditions and, if not met, applies remediation
Default AVIAS instaiVdefinition requirements for Windows I Mac OSX
I:= 111--H-- +"@!J""I- - 1- 1- -£]

... ..., ...
--·- ·- --.- ·- ·-
- -· ·- .
··-
• • Ill• --
_,._ ..
··-
·-··-
··- -·--
-- --- -·
..
··-- -·-· -- -#-
--
-~
··--- -·- ----

-~-
_, --- ..
__..,.
. _
...... . -·
- -~
-~
--·
---
The posture requirements define the "healthy'' state of an endpoint. Eight requirements are preinstalled on
the Cisco Identity Services Engine and they are all disabled by default. The built-in conditions check for the
presence of any antivirus and antispyware software on Windows or Mac endpoints, respectively. They
provide a good starting point for defining a policy that requires antivirus and antispyware software to be
installed on the client computers without having co specify the details of the software vendor and sign-ature
database. You can manipulate the existing requirements or create your own requirements.
The posture requirements are written as a expressio;ns: "Requirement met if 'posture condition' else
'remediation.'" Although not needed in this scenario, multiple conditions may be combined using one of the
three options: All Selected Conditions Succeed, Any Selected Condition Succeeds, No Selected
Condition Succeeds-.
This figure illustrates the AVIAS requirements that are by default installed in the lSE. The first requirement
(Any_AV_Installation_ Win) has been updated to automatically install AV if the endpoint does not have any
AV software. The remediation action has been set to 'Launch·CiamWin·lnstaller'. All other requ.ierments
are left at their default values.

Configure Posture: Posture Pol icy
'J'bis topic describes bow to configure a posture policy ru~e.
Configure Posture: Posture Policy

Matches identity groups, OS, and other conditions
Defines requirements, for example:
Employees must have up-to-date AVIAS and OS patche.s
COtltractors must have up-to-date AVIAS
_ wL::. -=---~· ·----· - --~

--
--· .......
...__
---I
-~-·------
• -..
-- --
~~1 --H--1 -[EJ ... I- - 1 - ,1•
1=-.1 11-1 ·- 1 - ~ --· 1 ..__ ,
The posture policy defines the requirements that endpoints must meet to achieve the compliant status. The
policy consists of rules that check one or multiple conditions: identity groups, OS. and other conditions and
specify a given requirement.
ln this scenario, the policy consists of two rules defined for Windows endpoints: "AS Definition Win., and
"AV Installation Win". Both rules reference requirements that exist on the Cisco Identity Services 'Engine
by default: Any_AS_Definition_ Win and Any_AV_lnstallation_Win..
11le 'Any_AS_Defmition_Win' requirement enforces that any djscovered AS software will be updated. It is
it~ default configuration.
·111e 'Any_AV_Installation_Win' requirement enforces that ClamWin will be installed if no AV software is

discovered.
Redirect Clients to Client Provisioning Portal
This topic describes how to redirect traffic to the cl:ient provisioning portal.
Redirect Clients to Client Provisioning Portal

. Redirect t-.91 configured on the NAO
. ISE authorization profile used for endpoints with unknown status:
Roremnoes lhQ redirect ACL
Restricts traffic using a~
RtdirKtACL --- ·- t""'

-~
____::]
Pttmll• rtGirtct
o.n., •pett ·-·-n
-·- ii¥
_,
SWttctl(con"')I'
lp KC*..Iitt erttn"** CPP.ftEDIRECT<ACL
dtny lldp any any tct bootPt ""'
·--
.
·-.,_..,.._
.
cMny ~any any 41q domain ___... .c..._ _,.,._.,
. ...... _
deft)IIP 1ny I'IOU 10..10 220
permit ip any any
. ,
The endpointli must be redirected to the client provisioning portal to install the agent suitable for thelll!. This
redirection is configured jointly on the network access device and the Cisco ldentity Services Engine.
The switch must have a redirect ACL configured Locally. l t is referenoed by name in the authorization
profile. Tbe ACL pennits the rraffic that should be :redirected and denies the traffic that will not be
redirected. This ACL will typically deny basic serv.ices, such as OHCP and ~~ and the communication
between the NAC agent and the JSE. You can make the ACL more specific any deny only the :rq~IUPJ'
ports used by the NAC agents in your environmenL Refe r to www c jsco com for specific port numbers.
The redirect ACL configured on the switch is referenced by an authorization profile on the IS'E. The
authorization profile, in this example named CPP, has two functions. It restricts the cliem traffic using the
Unkno\\'ll_Noncompliant_d.ACL, and enforces client redirection to the CPP. The ACL name deftned on the
(SE mus< ma<ch the local ACL defined on the switch.
The authorization profile is referenced by an authori2ation policy rule. fn this scenario, the CPP
authorization profile \\111 be referenced by an authorization policy rule with a condition specifying the
posture status is unknown.

Configure Authorization Policy for Posture
'J'bis topic describes bow to configure posturewrelated authorization policy.
Configure Authorization Policy for Posture

PostureStatus attribute: Compliant NonCompliant, or Unknown
Authorization poticy for noncomplianVcompliant status controls traffic
Authorization policy for unknown status. restricts and redjrects traffic
-
-.-..--
..- - .........--·-----------
.......
..~- ...
..---·--
·--- -·-- . -.
• lie---
-- -·-.
-
Tbe co.nditions that are defined within the authorization rule should consider the posture status. The status
can be ascenained by evaluating the PostureStatus attribute, which is available in the Session system
dictionary. The attribute can assume one of three values: Compliant, NonCompliant, or Unknown.
You can configure both simple and compound conditions to evaluate the Session:PostureStatus attribute.
you could, for example, define a compound condition that combines two expressions using the OR
operator: Session:l,ostureStatus Equal NonCompliant OR Session:PostureStatus tqual Unknown.
1'his figure illustrates three authorization policy rules for the (T users accessing the network for corporate
resources. The first, named lT Corporate Compliant, matches the posture starus Compliant, and applies
appropriate pennissions. The second, named IT CoJllorate Unknown, matches the unknown posture starus,
and assigns the CPP authorization profile, which restricts access and redirects the clients to the client
provisioning portal. The third, named lT Corporate Noncompliant, matches the posture status
Noncompliant, and restricts ate client traffic.
Verify Redirection to CPP
This topic describes how to verify client redirection to CPP.
Verify Redirection to CPP

••
tiO-Swf
•
•
•~()'OJ •lilth<tnU~• t.ion
!!lttr!Aet,
-
.._.,;,on• i ne.('t.ca
Cl9.tb1t.!::bernoe0/1
-
o;.i.')ll):) i~th•uo•~ 0/1
IQ.:: .lt.'.dtOU; A~36 . 9!l.t . Jbbl

1;~er-~: l-tl
<output emitted>
· ~-... At'S AC:.: .dCSACl.~t.-II'-tr!"'L'lOlr.I_:Scr.e«npU.liU._:!.t.CL-~2MS&66
If ~dftCICt ].(';:.; C'J'lf-l{!ljfltt<:':"-A--c_ _ o;=cr
P' nil, ~~ ,t~O!II # ~II, '~C'Jr>... -ll',.e>;d :!i.fd..~ .'.'i\IOlH.;!;_;to_ '!14:t~lo'4}'
~~nl.C!I:U:d"!fr.(C~l!:ttnt ~?§Urf'gn•"''Dil
<O'IItP'.It Ofl1tUI:d>
ol ' ol '
(1\(0 ,..,._1'...·.-
.,.. .... _.... ...
1'1- '___
-*--a-.----. ...
....... ._.__
......
-_. ..,._
Cisco Identity SeMces -~...,.,.
Engine SeaJrity ............
_ _ _ _ _ ..,....... c:-1!1: .... - ..... _ ..
- -. . .....-. . . . . llilllllolloot_ . . . . . .
~_
........,_,.ll_w-.
.......
You may verify the traffic redirection to the client provisioning portal in several different ways, including:
on the Cisco Identity Services Engine, on the switch, and on the client. Tbe top most figwe shows the
information displayed in the ISE GUl. The posture status of the endpoint is reponed as pending and the
CPP authorization profile is applied to the client session. The term pending is used here to describe
unknown posture status. Tbe Cl'P authori2ation profile restricts and redirects traffic.
You can examine the restriction and redirection parameters on the switch by running the show
authentication session interfac.e command The output displays the endpoint authentication and
authorization starus, along with various authorization parameters that have been applied to the port. Tlhe
dACL has a name that incorporates the dACL name as it is defined on the lSE. This dACL is used to
restrict network access to only the nece.~sary nerwo:rk traffic. The redirect UR~ includes the client session
LD. The client is being directed to the client provisioning resource that is suitable for this client. Tbe redirect
URL also specifies the action that should be taken at the ISE portal, in this case action=cpp.
The last figure illustrates the browser redirected to the client provisioning portal. The client can download
and install the NAC agent

Verify Remediation
'J'bis topic describes bow to verify the remediation.
Verify Remediation
-=- - -
t:IJ - ··-
--
After NAC agent instaUation, the NAC agent reports posture status to the Cisco Identity Services Engine.
Tbe ISE evaluates the infonnation and may instruct theNAC agent to perfonn remediation. ln this example,.
the File Launch Remediation is used to stan the ClamWio installation. 'J'be user must complete the
installation "12ard. When the installation process has been completed and the definition files updated, the
NAC agent reports compliance status and lists the discovered AV and AS components.
Verify Posture Compliance
This topic illustrates how to verify the posture service in lhe Cisco Identity Services Engine GUI.
Verify Posture Compliance

Initially pending statu s
Pending = Unknown
CPP authOriZation profile reslricls and redirects client tralric
After remediation, status is compliant
- · _,-_. .-
- . - - --
,._. ... .
--
• ---
• ·--• -·--
ca---w.... _..._. •-
• •
-~~~ -~-ill',."'"'!_.!.· -Ifill-.. _
- -G
·--- ~~!::0- ---
~-~;:;:=:::~:~·z-::-::::::J,IIc:::-::~
IE:::-
~'-----'
_u_
_.,_..
_
. •..• ····--
"'
..,, _ •
.. - -
.. .. _ .
• --
-
..tool>. .
---
__
--
....lo
---·. . ... -·-

_..__
-...-
....... _. .. ....--
".IWJ'
01'
You can monitor the posture status of the endpoints in the live authentications page found under
Operations> Authentications in the ISE administrative GUJ. 1"he "pending'" status indicates that the status
bas not yet been established. When the posture is unknown, the CPP authorization profile is applied to the
client to restricts and redirect user traffic. When the remediation is complete, the posture status can be
detennined. In this example the posture status is compliant

Summary
Summary
The Cisco ISE posture service determines the security posture of the
endpoints.
You configure the posture service in three main areas: client
provisioning policy, posture policy, and authorization policy.
Client provisioning policy defines the NAC agents Of the packages to
be provisioned on the endpoints.
The Cisco ISE authorization policy eval:uates the complianl
noncompliant, and unknown endpoint statuses to reflect the security
posture.
The posture policy can evaluate the file, registry, service, application,
antivirus, and antispyware settings of the endpoints.
You can verify the posture seNice operation on the NAD or in the
Cisco ISE GUI.
Lesson 21
Deploying Profiler Service

Overview
To ensure and maintain appropriate access to your enterprise network. the profiler service collects an
attribute or a set of attributes of all the endpoints on your nern·ork and classifies them according to their
profiles.
This lesson provides an overview of the profiler service that is offered as part of the Cisco Identity Services
Engine platfonn and describes how to implement profiling in a Cisco ISE network.
• Describe the purpose of the profiler service
• Describe the position of the profiler in overall Cisco ISE processing
.. Describe the Cisco ISE probes
Describe the most common probes
• Describe the profiling operation ~ri thout the use of probes
• Explain the relevance of CoA for the profiler operation
• Describe the use of profiling policies
.. Describe the parent profiling policies
.. Describe the child profiling policies
.. Describe the profiler configuration procedure
.. Enable the profiler service
Enable CoA for the profiling service
• Configure the probes
.. Examine the parent policy
.. Examine the parent conditions
Configure the profiJer conditions
• Configure the profiler policy
Adjust the authorization policy for the profiler service
View the profiled endpoint identity groups
Verify profiling in the lSE authentications page
• View profiled endpoints
Cisco ISE Profiler Service Overview
This topic provides an overview of the Cisco Identity Services Engine pro filer service.
Cisco ISE Profiler Service Overview

Two main functions:
Create and maintain loearned inventory
Assig.n ef'ldpoint idQntity group, usoo in authorization policy
Classify endpoints using variable sets of attributes
The MAC address uniquely identifloo eaCh endpoint
Many otMr attributes can be used for classification
Static profile assignment option
r-~----·-.
r·-····-····························; r. . ..,
•.............•...•• L. . . . . . . . . . . . . .J ·.·•·················•·.·
The primary goal of the profiler is to classify the endpoint using the most appropriate endpoint profile. The
profile specifies the endpoint identity group. The endpoint identity group is an attribute dlat you can use
when defining conditions in the authentication and authorization policies.
·profiling is useful in situations where certain corporate assets must be differentiated from noncorporate
assets. It may be used to help regulate network access and further assign network authorization that is based
on the policy group of the device.
An endpoint is a network-capable device that connects to your enterprise network. The MAC address is
always the unique identifier of an endpoint, but you can further identify an endpoint using a varying set of
attributes and the values that are associated to tltem. (called atrribute~value pairs). You can attach a varying
set of attributes to endpoints based on their capability, the capability and configuration of the NAps, and
the methods (probes) that you use to collect these anributes.
You can associate each endpoint on your network to an existing endpoint identity group in the system, or to
a new group that you can create and associate to a parent group. By grouping endpoints, and applying
endpoint profiling policies co the group, you can determine the mapping of endpoints to the endpoint
profiles by checking the corresponding endpoint profiling policies.
Enterprises deploy the profiler service for two main reasons:
• To create a learned inventory: Tbe profiler service provides a contextual inventory of aU the
endpoints that are using your network resources. It discovers the devices that are connected to your
network and finds where these devices exist on your network. This can be used to populate the MAS
database during the monitor mode phase of a p.hased deployment.
• To determine the applicable endpoint identity group: The result of the profiler service is the binding
of a device to a device profile. The identity group that is specified by the device profile can be used as a
condition in the authorization policy, and can tibus affect the netv.·ork permissions that the endpoint
receives.

Tbe administrator can statically assign an endpoint to an endpoint identity group. lf this is done, attributes
associated \\ith the endpoint continue to be updated, but the attribute values are not evaluated. The static
assignment remains until manually removed by an administrator.
Profiter in Cisco ISE
This topic describes the position of the pro filer service in overall Cisco ldentjty Services Engine processing.
Profiler in Cisco ISE
-~-...._. . .
" •rEl
· '--
.......
<S>-11 11- 1
- - -....
Aulhorl.ttJIOn Polley
The profiter service represents an additional block in the Cisco lSE infonnation flow. You can think of it as
a function that provides the endpoint identity group attribute to the authorization policy. The authorization
v.-ill have different privileges for de\-ices with undelterm.ined and determined endpoint identity groups.

Cis.co ISE Probes
'J'bis topic describes the Cisco Identity Services Engine p~obes.
Cisco ISE Probes

All probes are disabled by default
Enabled individually to meet profiling requirements
Probes are enabled on policy service nodes
IRADIUS II HTTP IDHCPSPAN

--
o.
· ~
IOMCP I INMAP ISNMP Ou..y

IONS INetF- 1I SNMPTrap
...
"·- -
·-
"·-
A prol>e is a method that is used to collec[ an attribute or a set of attributes from an endpoint on your
network. The probe allows you to create or update endpoints with their matched profile in the database.
11le Cisco rSE Q.l:l! contains the configuration options that allow you to enable or disable the probes on
each node. The probes are activated on policy service nodes. Cisco ISE supports various probes, and
choosing the appropriate ones for a specific environment is not very straightforward.
The ISE allo"'~ you enable these probes:
Tile RAOIUS probe can be used to evaluate the RADIUS attributes received from the NAD. Of
primary relevance is the building of the MAC to fp a<ldress bindings. tn RADIUS access-requests, the
Calling-Station-ID field specifies the endpoint's MAC address and the Framed-11'-Address field
specifies the endpoinrs IP address. The RADIUS probe also enables access to the lOS Oevice Sensor
da:ta on devices that support the feature.
The SNMP Trap probe is used to receive information about MAC notification, linkup, linkdo\\>11, and
otl!ler events carried in SNMP informs. The SNMP Tnp probe receives information from the specific
NADs when ports come up or go down and endpoints disooMect or connect to yow network. ·nle
SNMI'Trap probe should always be paired with the SNMI'Query probe. It's primary purpo.se is to
trigger appropriately timed SNMP queries.
• Tile SNMP Query probe performs system queries at regular intervals, pulling system and fQ!: data
from the NAD. It also performs interface queries when triggered by the SNMI'Trap probe. The
interface query pulls interface data including~N. session and CDP data
The OHCP probe allows the Cisco ISE profiling service to collect OHCP request attributes from the
D&!CP client. DHCP requests carry a user-agent field that helps specifY the OS of the device.
lnfonnation such as the requested DHCP options and the DHCP hostname can be useful in classifying
a device.
• The DNS probe allows the profiler to lookup m endpoint, and get d>e IQDN of !hat endpoinl This
reverse DNS lookup is performed by PSN against its locally configured name server to retrieve the
endpoint FQDN The lookup is triggered upon learning the il' address of endpoinl
.. The HTfP Probe enables the profiler to capture the User*Agent field presented by a web browser to the
web server. The user·agent field typically identifies the browser, software vendor, operating system and
version information to the web server. The HTTP probe requires the lP to MAC address binding to be
provided by a different probe.
The Netflow probe allows you to collect and analyze Netflow data. NetFJow provides records of
connections between endpoints including (p addresses, protocols and ports. An example use case for
this data within ISE is to recognize which network applications and services are active on a devic~. Tbe
Netflow probe consumes a relatively large amount of resources on the CSE node. It should only boe
enabled in special use cases. 1'be Netf low probe requires anther probe to provide the W to MAC
address mapping.
.. NMAJ, is in[egrated with the Cisco ISE profiler to augment its profiling capability for better endpoint
classification, particularly mobile devices. You can either perform a manual subnet scan on a specific
subnet by using the Network Scan probe; or you can associate a network scan action to a profiler policy
to perfonn a dynamic scan on an endpoint The NMAP probe requires the IP to MAC address binding
to be provided by a different probe.

Commonly Deployed Probes
'J'bis topic describes the most common probes.
Most Common Probes

RADIUS probe:
Evaluates RADIUS attribut&s received ·from NAO
RADIUS t:~ccou nting provides fo.tA~t~IP binding
Gathers data from the Cisco lOS Oevic:o Sensor feature
Plal1onn dependant, introdu<::Gd in lOS 15.0(2), WLC 7.2.110.0
DHCP snooping, COP and .b!:QE data
Data sent to ISE RADIUS probe via a<:eounting massages
HTTP probe:
COIIec:ts HTTP paCket data from SPAN or URL-radirec:ts
Captures traffic S4lnt to PSN via Q8b. RedirectiOn
Important for mobile dEMoe r&oognition
DHCP probe:
Collect OHCP requE~:st attributes from u ser, proxy. and M lper
Traffic focwarded to ISE with helper address or SPAN
·--~
RADIUS Probe
\Vith the RADIUS request and response messages received fro m the RADfUS servers, the profiler can
collect l~DfUS attributes, which can be used fo r profiling endpoints. You can create a profiling condition
ofRADfUS type, where you can use the Framed-ll'-Address attribute to obtain the endpoint IP address.
Similarly, the Calling-Station-rD attribute can, depending on the NAD configumtion, contain the endpoint
MAC address. The MAC address can be used to obtain OUI for N]C vendor classification.
-- --
You must enable RADfUS authentication and accounting on [be nm•ork access device. You can also
include options to send various attributes via RADl US. The three options recommended for the RAOtUS
probe are:
• The radius·se.rver attribute 6 on-for ..login-auth command is used to sends the Service-Type attribute
in the autltentication packets.
• The radius-server attribute 8 include·in-ac.cess--req command is used to send the fil address of a user
to the PSN in the access request. Tbis gives the PSN a hint of the user IP address in advance of user
authentication. Based on this information the PSN builds a map of user names and addresses. Using the
mapping infonnation, the PSN begins preparin,g user login information to have available upon
successful user authentication.
• The radius-server attribute 25 command is used to include the class attribute in access-request The
class attribute is not sent by defauJt.
The Device Sensor feature, available on Cisco lOS devices, is tLiied to gather raw endpoint data from
network devices using protocols such as Cisco Discovery l,rotocol, LLOJ>, and DHCP. The Cisco Identity
Services Engine analyzer acts as the external client of the device sensor, and will use RADfUS accounting
to receive the data about the endpoint. The device sensor sends to the Cisco ISE client notifications and
accounting messages containing profiling data alon.g with the session events, and other session-related data,
such as MAC address and ingress port. By default, for eacb supported peer protocol, client notifications and
accounting events are only generated where an incoming packet includes a TLV that has not previously
been received in the context of a given session. You can enable client notifications and accounting events
for all TLV changes, where either a new TLV has been received or a previously received Tl V has been
received with a different value using CL-1 commands.
Device Sensor is enabled by defauiL The following: TLVs are included by default:
• Cisco Discovery l'rotocol filter--secondport•status-cype and powernet-event-type (type 28 and 29)
• LLDP filter--organizationally-specific (type 127)
• DHCI' filter--message-type (type 53)
HTIPProbe
The HTI'P Probe enables the profiler to capture the information provided by the web bro\vser in £he HTTP
User·Agent field, as well as other HTTP attributes from the request messages. Cisco ISE provides many
defauJt profiles, which are built into the syslem to identify endpoints based on the User·Agem attribute. The
H n ·p data is important fo r, among other things, mobile device recognition. Identifying different mobile
and portable IP enabled devices is made more reliable by having the Cisco ISE node capture data during a
guest login or client provisioning download. This allows the profiler to collect the User·Agent attribute, as
well as other HTI'l' attributes, from the request messages and then identify devices such as Apple devices.
The Cisco ISE probe listens to communication from the web browsers on both port 80, as well as port 8080.

DHCP Probe
The OIHCP probe allows the Cisco !SE profiling service to collect OHCl' request attributes from OHCP
user, proxy, and helper. The probe evaluates OHCP requests of !NIT-ReBOOT, and SELECTING message
types. Other OHCI' message types, such as RENEWfNG, and REBINDfNG, are also processed but they are
not used for profiling endpoints. Any attribute parsed out of OHCP packets is mapped to endpoint
attributes.
When y ou configure a gateway device to intemperate witib the DHCP probe, you will use the ip helper·
address command to send the DHCP requests to the Policy Service node, in addition to the real OHCP
server, proxy, or helper address.
Profiling Without Probes
This topic describes the profiling service without the use ofprobes.
Profiling Without Probes

Direct profiling using client provisjoning (posture agent)
Client provisioning captures user agent and MAC address from
session 10
I
-.....
..........
.. • lliwle•
RACfUS~!::!!; ~t<lllftl llf<wif;lon~ I PoAA.•
"""""' '
• j•
~.
. ...... _. ....
The profiter service attempts to profile the endpoints even when probes are not enabled. This figure
illustrates a successful profiling process, in which the policy service obtains the endpoint attributes from the
NAC agent that is provisioned on the endpoint by the client provisioning feature.

Cis.co ISE Profiler and CoA
'J'bis topic describes bow~ affects the profiler operation.
Cisco ISE Profiler and CoA

Profiler without GoA
Monitoring purposes
Learned endpOint invantOfy
Profiler with CoA
Capable of Changing tM authorization poi¢y assignment
·-
AuthOrization pofi¢y considerS endpoint identity group
--
-
G&- .a.====~~~~ iJ
Ptollfr ....... CoAoptnltiOIII
CoA is: not absolutely necessary fo r the Cisco Identity Services Engine profiler service operation. If you
have some NADs in your nm•ork that do not support CoA, you may still deploy the profiler service for
endpoint monitoring. ln this case, the profiler service can be used to establish a learned inventory.
When CoA is supported on the NADs, you can use the pro filer service to push tailored authorization
policies to the endpoints. When the endpoint authenticate:s, it receives a restrictive authorization policy that
enables the sensing traffic to be exchanged. Once the endpoint profile has been determined, lhe Cisco lSE
sends a CoA to the NAD and instructs the NAD to apply an adjusted policy.
Tbe profiler service implements the CoA when one of the following cases leads to a condition where a
different policy profile becomes appropriate:
Static assignment of an endpoint
Exception action L~ configured
Endpoint is profiled for the first time or endpoint is deleted
• Endpoint identity group has changed
Profiling Policies
This topic describes the profiling policies.
Profiling Policies
Use a combination of conditions to identify devices
Can be hierarchical
Rich set of default policies pre--installed in the ISE
~~-
.,. _
.,.
~=
.,_ ,_
h_
__
.. -
."C.
, __
----;:::,=-[ =::=,"1[~:._)( I
r.:::..
·-
...,_
..,_
,._
....... _.
The profiler service evaluates endpoint attributes and assigns the endpoint to endpoint identity groups. Tbe
logic of this evaluation and assignment is defined io the profiling policies. The profiting policies use a
combination of conditions to identify devices. Cisco Identity Services Engine comes with a large number of
preconfigured profiling policies. You can extend the default by configuring your custom policie.~.
This figure illustrates the hierarchical profiling policy for Apple devices and Apple iPads. When profiling
policies are in a hierarchy, the child policies are not evaluated unless the parent policy is matched. In ahis
case, the Apple-Device policy is the parent policy. It matches off a simple condition, the endpoint's MAC
address contains an Apple OfU. Ibis match allows the more refined chiJd policies to be evaluated. Data
from the endpoint hostname and its browser's User-Agent field indicate that the endpoint is an il'ad.

Parent Profiling Policies
'J'bis topic describes the parent profiling policies.
Parent Profiling Policies

Example: Apple-Device
__ __ Matches on a MAC Addres~ OUI assigned to Apple
-- __·-i-§ -
.,. Triggers a host NMAP OS scan
, .
:-~·--
.
·--·.- • 11/«. _ l ..-
-..--.. .-o-.--.---
.._._~
'folltooai._,_,_ ·- ' I
---
.......- ,
·-UIO·----
..._
Tbis figure illustrates the parem policy Apple-Device. "Jbe policy specifies two rules. The condition of the
first rule is tha< the MAC address OUI matches Apple. "Jbe OUl is the first 24 bits of the MAC address. It is
sometimes called a vendor code, but the more appropriate term is an MA*L. NlC manufactures must
register with the ,g.§..~ to obtain MA~Ls to use in the MAC addresses on their NICs. Cisco ldentity SeiVices
£ngine maintains an OUI table to detennine the NlC vendor. Tbe first rule states iliat if the OUI matches
Apple, then a network scan action should be taken. Note !!hat the ·Network Scan (NMAP) Action field
specifies an QS.scan. The results of this NMAl' OS scan will be available to the child policies. The
conditi on of the second rule is also that the MAC address OUl marches Apple. This can be confirmed by
expanding the condition or by examining the condition definition under Policy> Polic.y ·Elements>
Conditions, Profiling. The second rule stare.c; that if the OUlmatches Apple. then increase the certainty
factor of the profile by 10. Note mat the Minimwn Certainty factor is set to 10. Matching this rule is
enough to match the policy.
The profiling policy ccntains these settings:
Minimum Certainty Factor: Each policy has a minimum certainty factor (an integer value) associated
to it. Rules in the policy, if their condhions are met, can increment the certaincy factor for an endpoint
towards the profile policy match.
Exception Action: This option allows you to trigger an exception action (a single configurable action)
that is taken when an endpoint matches the profiling policy. The exception action is rriggered when the
endpoint profiling policy is matched. and at least one rule specifying an exception action matches. lhe
exception actions are conveyed to the NAD via CoA4 Options for exceprjon actions include port bounce
and reauth.
.. Network Sc.an Action: An endpoint scan action scans a single endpoint as compared to resource
intensive network scans, which you could perfomt manually when configuring the NMAP probes:. lt
improves the overall classification of endpoints, and redefines an endpoint profile for an endpoint. You
can associate a single network scan action to an endpoint profiling policy. Cisco lSE predefines three.
scanning types for a network scan actions. Once an endpoint is appropriately profiled, the configured
network scan action cannot be used against that endpoint. for example, scanning an Apple~Devic-e
allows you to classify the scanned endpoint to an Apple device. Once an OS-scan determines the
operating system that an endpoint is running, itt is matched to an appropriate profile for an Apple
device. Tbe follo·wing are the scanning types lhat are predefined in any network scan action for an
endpoint scan:
QS..scan. This type scans an operating system and OS version that an endpoint is running. It is a
resource intensive scan.
SNMPPortsAodOS..sc.an. This type scans an operating system and OS version that an endpoint is
running, as well as rriggers an SNMI' Que:rywhen SNMI' ports (161 and 162) areopen.ltca:n be
used for endpoints that are identified and matched initially with an Unknown profile for better
classification.
CommonPortsAodOS-scan. This type scans an operating system and OS version that an endpoint
is running, as well as common ports O~CI' and U!?,.r), but not SNMP ports.
.. Create Matc.bing Jdentity Group: This option allows you to create a matching identity group as a
child of the profiled identity group, when an endpoint profile matches an existing profile. for example,
the Apple~Device endpoint identity group is created on the Endpoints Jdentity Groups page when
endpoints that are discovered on your network match the Apple·Device profile.
.. Use Hierarchy: When checked, chis option alt-ows you to make use of endpoint profiling policy
hierarchy to assign endpoints to one of the matching parent endpoint identity groups, and to the
endpoint identity groups that are associated to the parent identity group. for example, endpoints that
match an existing profile are grouped under the appropriate parent endpoint identity group. Endpoints
that do not match any existing profiles are grouped under Unknown, and endpoints that match an
existing profile are grouped under Profiled endpoint identicy groups. If endpoints match the Cisco-fP-
Pbone profiJe, then they are grouped under Cisco-IP..rbone, and endpoints that match the
\Vorkstation profile are grouped under Workstation endpoint identity groups. The Ciscl)o.IP·Phone
and \Vorkstatioo identity groups are associated with the profiled endpoint identity group in the system.
.. Parent Policy: Tbis option allo\\'S you to choose an endpoint profiling policy from which this policy
can inherit conditions.

Child Profiling Policies
'J'bis topic describes the child profiling policies.
Child Profiling Policies

Example: Apple· iPad
DHCP:hostnamG contains iPad
--
IP:Usor -Agont (in HTIP) contains 'iPad", 'Mac OS' , and 'App!oWobKil'
-- ·-- ----
·--·-·-§
. --~
~
· I ~·-~ -~
-..---.. .-o---..-.. .
·e..--- 1~
• ._..._,_,_ (;.
·-..~ !..,._
·-<o.or..., [.-....,
·I
9>,..._ __,__,....
·I
•i
~
- " - 0 . .....
This figure illustrates the child policy Apple-iPad. Note the Parent Policy field specifies Apple-Device.
Tbis child policy will not be evaluated unless the parent policy first matches. This policy specifies C\\'0
rules, each capable of increasing the certainty factor by 20. Note that the minimwn certainty faccor is 20, so
matching the conditions of either rule is sufficient for the profile assignment.
The first ruJe examines the DHCP :host~name attribute. "Jbe condition matches if the attribute contains iPad.
Tbe second rule examines the user-agent srring. The condition matches if the user·agent string contains
each of the following sub-strings: iPad, Mac OS, AppleWebKit.
To examine the details of conditions specified in the rules, you can find the condition, by name, under
Policy> Polley Elements> Conditions, Profile.r. You can also perfonn a read only expansion of the
conditi.on details by hovering the mouse pointer over the condition field and clicking the details icon that
appears, as shown in the figure below.
.....
If~ IAPel••.oRultlChKIO <> I Thoni<'"'""'
Profiling Configuration Procedure and Scenario
This topic describes the profiling configuration procedure and shows an example scenario.
Profiling Configuration Procedure and Scenario

1 Enable the profiler service on a node
2. Configure CoA
3. Enable the probes
4. Examine default profiling conditions and policies
5. Configure the profiler conditions
6. Configure the profiler policy
7. Configure authorizatio n policy for p rofiled endpoin ts
Cl'ltld poltCY(l.lnQyt-PrlniS~r )
Unktyt
J
....... _.
10 10 10 QQ
I Cl'ltck IP range
(10. 10 10 9 1·10, 10 10QQ)
f ollow these steps to configure the profiler service on the Cisco Identity Services Engine:
I . Enable the profiler service on a Cisco JSE node
2 . Configure CoA
3. Configure the probes
4. Examine default profiling conditions and polic.ies
5. Optionally configure custom profiter conditioru;
6. Optionally configure custom profiler policies
7. Configure authorization policy for profiled endpoints

Enable Profiler Service
'J'bis topic describes bow to enable the profiler service.
Enable Profiler Service

On selected policy seNice nodes
.,__ ·-- ·--- ..-

Enabled by default in standalone deployment
·-
~.--- - . .. .
-- ---- -·- ---
~- ~-
··-
•• ••
-- -- --
--~
-----· ...
----- ·-~
- -- -
- - ---
---- ..
You can deploy Cisco Identity Services Engine either in a standalone environment (on a single node), or in
a distributed environment (on multiple nodes). The profiling service is associated with the Policy Service
pe.rson3. Oetennining which policy service nodes should run policy services in a distributed deployment is
an advanced design topic. To manage the Cisco lSE deployment, choose Administration> System>
Deployment, choose me appropriate node from me Deployment Nodes page, and click Edit.
·J'be configuration page contains the General settings tab to configure the deployment and the Proflling
Configuration tab to configure the probes on each node. If the poUcy service persona is disabled, or if it is
enabled but the Enable Profiling Service option is not selected, then the Cisco ISE administrator user
interface does not display the Profiling Configuration tab. If the policy service persona is disabled on any
Cisco nSE node, Cisco lSE displays only the General settings tab and does not display the Proflling
Configuration tab, which prevents you from configuring the probes on the node.
In a standalone ISE deployment, the promer service is by default enabled on the s!andalone node. As shoWill
in the figure, it cannot be disabled.
5~<11 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Enable CoA in Profiling Feature
This topic describes how to enable CoA for the profiling service.
Enable CoA in Profiling Feature

No CoA (default): Disable CoA in profiling feature
Port Bounce: Used for a single endpoint on a switch port
Reauth: Reauthenticate an alrea.dy authenticated endJX)int during
---
profiling
111;;':: :- . - - · - - """'"""'~............. --
- --
o.----
--- ---- - - ...... -
_____
-.-----=--- ... __ _
- __ _
-·- -- -
...... .:;-~-~==:;]'1..,
--
-- ___
,...,. ::::.
··- -
··------- ---·--- ....... .,.. .._,
"---
...,
--
--
....... _.
The Cisco Identity Services Engine allows a global configuration to issue a CoA for endpoints that are
already authentica[ed to the network. This global configuration of CoA gives the profiler service more
control over endpoints.
You can use the global configuration option to disable CoA by using the default No CoA option.
Alternatively, you can enable CoA by using the Pon Bounce and Reauthentication options. If you hav·e
configured Port Bounce CoA in Cisco ISE, the profiler service may still issue other CoAs on a port.
The CoA selections are as follows:
.. No CoA: Use this default option to disable the use of CoA in the profiling service.
Port Bounce: Use this option if there is only one session on a switch port. lf the port has multiple
endpoints that are attached, use the Reauth option.
• Ruutb: Use this option to enforce reauthemication of each authenticated endpoint when profiled..
[fyou have multiple active sessions on a single pont, the profiler service issues a CoA with the Reautb
option even though you have configured CoA with dle l,ort Bounce option. This function potentially avoids
disconnecting other sessions, which might occur with the Port Bounce option.

Configure Probes
'J'bis topic describes bow to configure probes.
Configure Probes
--
Some probes, such as NMAP, are CPU intensive
-..·-._
~
...
--
r~~~-1 :::
r.::;.~~I b .
b . ___
r=E---1
r=~---l ·-
A prol>e is a mechanism that is used to collect attributes associated with endpoint.~; on your network. The
probe r.esullS allow you to create or update endpoints with their matched profile in tbe database.
11le Profiling Configuration tab on the Edit Node page contains the configuration options that allow you
to enable or disable the probes on each policy service node. This allows a nodewspecific configuration of
probes in a distributed deployment. Tbe Deployment menu window displays the registered nodes in your
deployment. You can select a node from the Deployment menu window.
Examine Parent Policy
This topic describes the configuration of profiler conditions.
Examine Parent Policy

Linksys..oevice: profi1er policy bu ilt·in by default in ISE 1.2
Chook.S if eodpO{nt MAC address has UnkSys OUI
-
Chook.S if DHCP:hostname attrib uto contains 'Linksys'
__-.. _- · -·- · ... -· --

-... .. ...
··-·-
·&c- -
~-
·--
--
o- a- ---..
_ _ ._
~.:.---
•- ~·c-1;;;;;-;:;;::==::J
...._, __,
, ..,... _
-
L
-·--
_____
·-(oool-••• (;0 ~==71'
·-. --.......... .. ..,_____

.... -
...,
·--~-~-"',. ·I
. .. .... _.
-·-·---<-
·-- ll -·,~ .......-
:g-~ ......
• ti: J 1.1•
Cisco Identity Services Engine 1.2 bas a preconfigured default profiling policy, named Linksys-Device.
This profiler policy will be used as a parent policy in this configuration scenario. The policy has two rules.
Each rule is capable of increasing the certainty factor by 20. ·ne policy has a minimum certainty factor of
2 0, so matching the conditions of either rule is sufficient to meet this profiler policy. Each rule has a s:ingle
condition. The conditions are described as foUows:
• If endpoint MAC address bas Linksys OUI (for example via the RADIUS probe).
.. tfthe OHCP:hostname attribute contains the string 'Linksys'

Examine Parent Conditions
'J'bis topic describes bow to examine the parent conditions.
Examine Parent Conditions

Rules of the Li nksys~Oevice policy reference two condrtions:
LilksysOUIChadt: CMck if &ndpoint MAC address has a Unksys CUI
lilksys-OaviceRui&1Ched<1: Cheek it OHCP:hostnamo attribute contains
'linksys'
- -__·-··_
___
_..·----
_ --
--·-- ·--- -J
,
"· ·-- ·--

·-- ·--
·--
---a..- ·---
·---
· - - o.l
-~--
This figure illustrates the definition of the 1\\•o pr"Ofiling conditions that are referenced by the Linksys-
Device profiling policy. Profiling conditions are used in tlle same way that authentication and authorization
coniDtions are used in authentication and authorization pnHcies. You can use the built-in conditions or
define custom conditions. Simple conditions define a single match statement. Compound conditions specify
a set of condition statements.
5~& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Configure Profiler Conditions
This topic describes the configuration ofprofiler conditions.
Configure Profiler Conditions

Print servers in range 10.1 0.1 0.91·10.10.10.99
IP address attribute is matched a.s a string
Two condrtions used to match the range:
IP starts with 10.10.10.
IP is great(n than 10.10.10.90
----
·-··-
--·~§1
·-- .
....... _. --
· - · ~·:--
-----:3
·-·- IJP:~J'I'·
[n this scenario, the print servers are manufactured ·by Linksys and have been given static lP addresses in
the range 10. 10.10.91·1 0.10.10.99. A profiling policy will be defined that is a child of the LinksysDevice
profiler poJjcy and will further differentiate based on IP address. The figure shows the configuration of two
profiler conditions. Profiling conditions match the nP addresses as strings, not as numbers. Therefore the
two conditions required to match this address range are:
• The endpoint II' address must start with "10.10.10."
• The endpoint II' address must be greater than "10.10.10.90"

Configure Profiling Policy
'J'bis topic describes bow to configure the profiler policy.
Configure Profiling Policy

The profiler policy Li nksys~PrintServer will create a new identity group
Each of the custom conditions increases certainty factor by 10
- - -- · ~ · - ·
- 'I. -
.. ·--·---·
..-- ,_
·--
... ~- --- 4. - -
···--
••••
--·
..._....... ----
·--"'
·-----
____
-·--
__ ------
..... - - -
.__,..... ·-·-
·--- -~-===-
-- ----
-~--~~· , ....
....
ln this scenario you add a new profiling policy, named Li:nksys-PrintServer. It is defined as a child policy to
the Linksys-Device profiler policy. It contains three conditions. One condition checks the Linksys OUl and
raises teh certainty factor by 40. The two remaining conditions are used to match the lP range and each
raises the certainty factor by 20. All three conditions mus!l be met to profile the endpoint, because the
minimum required certainty factor is 60.
Configure Authorization for Profiled Endpoints
This topic describes how to adjwt the authorization policy to the profiler service.
Configure Authorization for Profiled Endpoints

Authorization policy can evaluate: profiled endpoint identity groups
.-. --.,_. . ... . --· #--- .,_

-- ~-.. ~,;;,.----
-- ----- -.-------......_ -·
_,_
----
• -
•
• --
---
- - --
'C!l_
_
-~---_.,
_,_
.-- -
• ~- _..
•• -- --- -- ~--""-
---
~ --I!Qral-
•
•
•
--- ---IQ,oiU--
·-
-
A common application of the profiler service is to provide differentiated access based on the endpoint
profile. To accomplish this, you must configure the authorization policy to reflect the device profile
assignment. This figure illustrates the authorization. rule named l,rint Serve-rs. To define the conditions
v.-ithin this authorization rule, edit the identity group details field of the authorization rule, navigate through
J!de.ntity Groups> ·Endpoint Identity Groups> Profiled, and then choose the endpoint profile that has
been created by the profiling policy.

View Profiled Endpoint Identity Groups
'J'bis topic describes bow to view the profiled endpoint identity groups.
View Profiled Endpoint Identity Groups

Can be created by profiling policies
If the option "Yes, create matching identity group" is sefected
·-·--
--
...._ ---
____ ·------
---·-·-·
·-- --
..··--- - - ..;;_.:;____--::_- ------=- .
.,.
................ -..
·.,__·-........
--- o-·- o-
--
___ --·--
·-
·-
·-
ao --
---- --
--·--
.._
---·-~
0 ~~::~------~~--~~~--~--~::~~~~
0
-- o- ·- -
o--- ----a-
--..- --
If you select the option "Yes, cre.ate matc.bing identity group" in the profiling policy configuration, a
profiled endpoint identity group will be automatically created in the Ch;co Identity Services Engine. This
group is added even before any endpoints are profiled usi:ng tlle given policy. You can view the profiled
endpoint identity group in che Administration> Identity Management> Groups> Endpoint Identity
Groups > Profiled. The figure shows that the group Linksys.. PrintServer has been created. Selecting a
particular endpoint identity group link will display a rable of all endpoints that are currently assigned to that
group.
5-52 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Verify Profiling in Authentications Page
This topic describes how to verify profiling in the Cisco Identity Services Engine authentications page.
Verify Profiling in Authentications Page

Endpoint is authenticated via MAB
ContinuG if Gndpoint not fou.nd
Profiling policy matches and assigns endpoint profile
CoA sent with appropriate authorization profile
·----
-~
•
- •
---·-··- ·
--- • ---·
~--- , ..,._
~-· •
·-
-...,_._...,_,._ . ...-. - -- •••.• ,-,c---,
-- --
- ,,_,j -.._:.-
~~--·---· ·-
~--Ufl ......
. A".,.·--= I'-:::'=:::=? ~-~~-~"-

•. •. •':·u.uo-- -- -
- -·- •
--~ . . . . . --- .... - --
.. · -· - - - • .,.. -..oo.
-- -- -
....... _.
-~- · .
The Live Authentications page, at Operations> Authentications, displays the results of the authentication,
profiling, and authorization processes. The figure cbepicts an endpoint that first bad no endpoint profile
assignment and ~<as assigned the authorization profile named WEBAUTH. After dynamic profiling, iu is
assigned the Linksys PrintServer endpoint profile and the Machine_Corp authorization profile.
4

View Profiled Endpoints
'J'bis topic describes bow to view profiled endpoints.
View Profiled Endpoints

Profiled endpoints are displayed in the endpoint list
Endpoints are identified by MAC address
MAC to IP address mapping needed to check the endpoint IP address
-- ---
- ·---------
;;:-=----.,
..
-· -·
·-- ·--- ·-- . ~ .
- . --·
·-•·-· -- -- -- ·-- ---
,.., I •- . _ . • - · • ·-· •
··-·- --
- •
To view the profiled endpoints, choose Administration> Identity Management> Identities>

Endpoints. Ibis page provides information about endpoint.li that have been discovered by profiling or that
have been statically assigned an endpoint identity group. The endpoints are identified by their MAC
addresses. In this scenario, the MAC to IP address mapping was needed to check the endpoint JP address
and properly profile the endpoint. Both attributes have been obtained using the RADIUS probe.
ln a production deployment, the number of endpoints displayed in this table can be cumbersome. This table,
like most tables in Ci..lico Identity Services Engine, does offer the option to use dle quick filter or advanced
filter to limit which entries are displayed in the table. Also, you have the option to navigate to
Administration> Identity Management> Groups and display tables for individual endpoint identity
groups.
Summary
Summary
The Cisco ISE profiler service discovers and determines the
capabilities of endpoints that are attached to the network.
A probe is a method that is used to collect an attribute or a set of
attributes from an endpoint on yoor networ1<.
Profiling requires CoA to change the authorization state of an endpoint.
but can discover endpoint properties without GoA.
Profiling policies allow you to categorize discovered endpoints on your
network and assign them to specific endpoint identity groups.
ISE comes with numerous built~in profiler condrtions and policies.
The buitt-in profiler policies are defined in a hierarchical fashion and
consist of parent and child policies.
The authorization policy can eval uate the endpoint identity groups.
You can view the profiled endpoints and their endpoint identity groups .
. ...... _.

Lesson 31
Implementing BYOD
Overview
The Cisco Identity Services Engine, combined with the Cisco Wireless LAN Controller, Cisco APs, and
wired switches, provides comprehensive !t!QQ capabilities and solutions in one system. This lesson
provides students with the knowledge and skills needed to deploy a BYOO solution to onboard comp3lly·
o~'D.ed or personally owned wireless devices.

Describe the BYOD challenge
• Describe device onboarding
• Describe the single and dual SSID designs
• Describe the dual SSlD flow
Describe the authorization policy in the dual SSID flow
• Describe how the endpoint connects to the network
• Describe guest access in BYOD
.. Describe employee access before endpoint pro\~isioning
• Describe native supplicant provisioning for employees
• Describe the Wi·f·i profile
• Describe the client provisioning policy for employees
• Describe employee access after endpoint provisioning
Describe the verification of BYOD device registration
• Describe the verification of BYOD client provis ioning
• Describe how to connect to the SSID in BYOD
The BYOD Challenge
Tbis topic describes the challenges of the BYOD phenomenon.
The BYOD Challenge

New Paradigm
MOM solution
Device Onboarding
·- .. ·-·
Apple released the first iPhone in 2007 and the first il'ad in 2010. At that time, the common opinion
amongst lT professionals was that these types of devices would never be allowed to directly access
corporate networks. ln fact, some companies originaiJy implemented the Cisco identity Services Engine to
defend against chis threat. With lSE profiling, dley could recognize iDevices and reject access for them. But
the opinions have quickly shifted, and the acceptance of B YOD is becoming common. One reason is that
employees are demanding the use of the devices which make them the most productive. Restrictions and
contronare still desired, though. Much about the security stance that is guaranteed with a corporate O\\'lled
and managed asset cannot be taken for granted with a BYOD device. Traditional systems which provided
authorization based solely on the user ID no longer suffioe. Authorization must con.(jider both user
authentication and device authentication.
MOM solutions repres;ent a technology that rose in the same time frame as BYOD. MOM solutions seek to
ensure security standards are implemented on mobile devices. Options for security standards can include
encryption, PIN protected screen locks and remote wipe capabilities. While MOM and BYOO are related,
they can exist together or independently. MDM platfonn.~ can work with mobile devices that are provided.
by the ·company or they can work with BYOD devices. ISE provides integration with several of the industry
leading MOM solutions.
MDM solutions, often licensed on a per-device basis, can be expensive. Many companies would simply like:
ro distinguish between devices that are owned by employees versus devices that are brought in with a
visitor. This is where device onboarding fits in. The idea of device onboarding is that employees can
register their own devices. The onboarding process requires the employee to authenticate and includes the
provisioning of a device certificate for the onboarded device. ISE provides a solution for employee self-
service onboarding and registration.
5.s& lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
[SE authorization policy can integrate with either JvtDM solutions and with simpler BYOD onboarding. The
figure shows a flowchart of a simple policy that considers the device. EAP~TLS requires a client side
certificate on rhe device. If the certificate identifies a corporate owned and managed device, then a more
privileged access is granted. Jfthe certificate identifies an onboarded device, then a less privileged access is
granted. If neither of these are the case, access is rejected. Certificates could also be used to identify devices
that are under the management of an MOM solution.

Device Onboarding
'J'bis topic describes the device onboarding used in the BYOD solution.
Device Onboarding
Uses existing Active Oire<:tory or guest credentials
Provisions native supplicants
WindOWS
Macosx
App!G iOS
Android
Provisions certificates with addrtional ae.tnbutes, such as username or
MAC address
End ..user selfofegistration (no involveme nt of IT administrators)
-lOS
MAC OSX
Cisco provides a comprehensive BYOD solution a.n;hitecture that combines elements across the network for
a unified approach to secure device access, visibility, and policy controL To solve the many challenges that
exist. a BYOD implementation is not a single product, but should be integrated into an intelligent network.
Wired switches are supponed in the BYOO solution, but wireless access is more common.
Onboard.ing for new devices involves certificate enrollment and profile provisioning, and should be easy for
end users with minimal intervention by IT, especially for employee..owned devices. Device choice does not
mean till at you have to give up security. IT needs to establish the minimum security baseline that any device
must meet to access the corporate network. Proper device: authentication is critical to ensure lllat the
onboarding of new devices and the access of other devices is secure and protects the entire network
infrastructure, but authentication should also be as simple as possible for both the IT personnel and the user.
11le Cisco Identity Services Engine offers a suite of security features:
Supplicant provisioning on all major platfonns using profiling
(n.band and out~of~band asset registration portal
Self-service user·based registration
flexible dotlx profiles
Blacklisting and reinstating of devices
As networks started implementing wireless in their organizations, a unique wireless network name, which is.
also known ali an §SfD. was needed, along with a username and password. Digital certificates and £WO·
factor authentication provide a more secure method to access the nern·ork. The end~user typically must
download client software to request a certificate or provide a secure token for access.
5.00 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Deploying digital certificates on non·PC·based devices requires a different process because many of these
devices do not natively support all the features and functionality that are needed to create or download and
instaJl digital client certificates.

Single and Dual SSID Design
'lllis topic describes the two BYOD designs.
Single and Dual SSID Design

Single SSID:
Provisioning. and network a<X::$SS on a s ingle SSIO
uses SGO.Jr&d SSID
ooos not work for guests
Less common
Dual SSID:
Separates provisioning and network ae:cass
Similar to traditiOnal approach:
Protected SSID for employees
Open SSIO for gl.'(!Sts
Uses open SSID for provisiOning
Works for guests and e-mp!oyoos
More common
When designing WLAN networks, these three aspects should be taken into consideration:
Tine role of the WLAN
The authentication mechanism for the WLAN
The number of WLANs present in a network
This design guideline logically separates the WLAN into [WO distinct logical functions-provisioning and
network access. These ~·o functions can be provided by l!wo different WLANs, which is known as dual
SSID, or WLANs combined into one, which is known as sing.le SSID. The following examples cover both
single and dual SSID deployment models.
When deciding whether to implement a single or dual SSlD configuration, consider the following:
Some organizations prefer to have a dedicated SSID for onboarding of devices. This keeps the traffic
segregated and enhances security on the network.
Other organizations see dual S-SlD as an extra management burden because they will have to manage
two SSJDs.
The single SSlD solution does not work for guests and is therefore not common.
T111e dual SSID approach works both for guests and employees, and is the preferred method.
The uruique requirements 3Jld preferences of an organ.izatfon will dictate which model to deploy. The Cisco
Identity Services Engine and Cisco Wireless LAN Controller configurations may easily be changed to
suppon either option.
5.02 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems.lnc.

Dual SSID Flow
This topic describes the BYOO flow in the dual SSlD design.
Dual SSID Flow

1 User connects to open SSIO
~
-
.---
-
Redirected to WebAuth portal
2.
3. User enters employee or guest credentials
. ._ = ~
4. Guest signs AUP and gets guest access

5. Employee registers device
Downloads CG.rtificatG.
Downloads supplicant conliguration
6. Employee reconnects using EAP·· TLS
....... _. C~ ISE AQtDNt
[n this design, there are lWO SSIDs. One provides enrollment and provisioning, and the other provides
secure network access. After connecting to the BYOD_Provisioning SSID and completing the enrollment
and provisioning steps. the user connects to the BY~OD_Secure SSfD, which provides the network access.
When implementing dual SSID, the provisioning SSIO can be either open or password-protected. When the
provisioning SSID is open, any user can coMect to the SSfD; however, if it is password-protected, then
only users that have Active Directory group membership are allowed to connect [0 the SSID. After the user
is provisioned, it is assumed that the user will switch to the second SSfD for regular network access. To
prevent the user from staying connected to the provisioning SSID, an access list must be created that
provides access to only the Cisco Identity Services Engine, DHCP, and Ot-JS.
[n this example, there are two SSlDs, one that is open for guests and their devices, and one used for
employee authentication:
I . A user associates to the guest provisioning SSrD.
2. The user opens a browser and is redirected to the Ci..lico ISE Central WebAuth ponaL
3. The user enters an employee usemame and password in the guest portal.
4. The Cisco JSE authenticates the user, and based on the fact that the user is an employee and not a guest,
the user is directed to dle Employee Device Registration guest page.
5. The MAC address of the user is prepopulated in the Employee Device Registration guest page for
Devic.elD and the user enters a description and. accepts an AUl, (if required).
6. The user chooses Accept and begins downloading and installing the supplicant.
7. The user device supplicant is provisioned and any certificates are provisioned.
8. The user can then manually associate to the hidden SSID and authenticate via EAP·TLS.

Authorization Policy in Dual SSID Design
'J'bis topic describes the authorization policy rules in the dual SSlD design.
Authorization Policy In Dual SSID Design

For connection via open SSIO, send to WebAuth
For guests, provide limited privileges
For employees, send to native supplicant provisioning
For employees with provisioned endpoints, provide appropriate access
Rule Name Conditions PermJaslons
Op~Gn Rule ~ Wi:re!GSS_MAS then WebAuth

Guest w Guost tMn Guest
EmplOyee ~ EmplOy&e then Supp-PrOViSiOn.
ProviSioned w Emptoyoo & EAP-TlS & calf.lng- then Employee

Employoo StatiOn-10 = CERTIFICAT E:SAN
Default w Anything 61se then OenyACCG$$
·-~
Tbe figure swnmarizes the key rules in the Cisco ldentity Services Engine authorization policy. Users who
connect via the open SSID aresem to WebAuth. The Wireless_MAB rule is configured to ''Continue" if the
user is not found. Once a user is authenticated as a guest, the system provides limited privileges. When
employees connect to the netv.·ork via the open SSID, they are sent to the native supplicant provisioning.
Tbe employees who connect using provisioned endpoints are granted appropriate network access.
Tbe Cisco lSE enables seJf.provisioning, which allows employees to register their personal wireless
devices. The Cisco ISE provisions the device with its native supplicant during device registration. The
BYOD system leads the employee through a series of provisioning steps the first time the personal device is
brought to work and registered. The user can use existing Active Directory or guest credential~. The BYOD
authentication type will then detennine the type of secure policy that the user ·will receive. Certificates can
be provisioned while registering the device.

Connecting to the Network
This topic describes the process of connecting to the network using the single SSID.
Connecting to the Network

Guests always connect to network via open SSID
-
Employees connect via open SSIO until their endpoints are provisioned
I OPEN SSIO ,~
~
I lc*~l• urt.f't(lir~I10A.Q£NT~EDIRECJ
k"t~~ I lii'Widil+(:tl
IIG~I4&3<~~~~.a
....... _.
The open SSID allows guests and employees to connect to the network. Guests always connect to the
network via open SSID. '11te employees connect via open SSID in the initial phase, when their endpoints
have not yet been provisioned.

Guest Access
'J'bis topic describes the guest access process.
Guest Access
Guest endpoints are not provisioned
-
Guests are permitted appropriate access
§j. ~
--
-- ---
-
CJw.,.otoWo'
-
- _...~
- -·- -
I So\'•• OOO.MffMO& J
I
- I
--
Guests are redirected to the guest portal. Their endpoints are not provisioned because the Enable Self..
Provisioning t"low option in the Multi· Portal page is not set. After successful authentication, guests
continue using the open SS!D to access the allowed resoarces. Commonly, the guest policy allows access
only to Internet resources.
5.00 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Employee Access Before Endpoint Provisioning
This topic describes the acce.c;s of the employees before their endpoints are provisioned.
Employee Access Before Endpoint

Provisioning
Employees initially connect via open SSIO
They are redirected to client provisioning
Certificate obtained via SCEP
Native supplicant
Wi-Fi profile
1-£ ----·-
---
-
----·~---
1
I
•
_.
~~&rJ• ... cdio
WPY1 • .....~ ·
fiiiDe.:o'liw\1 oelll ........ ,
.......
net-· o.....sp..AQ.
•1? ~S.·: .,.,,_. .. ,

·--
~~o =.,"':.:::,.":..,.
----
I ~1....:-===·="'·=.-=---'
Employees initially connect via open SSlD and are then redirected to client provisioning.. The employee
endpoints obtain certificates, which are provisioned via SCHP, obtain a native supplicant, and obtain a Wi-
fi profile.
C 2014 Clsoo Sys1ems. Inc. Student Guide 5-67'

Native Supplicant Provisioning for Employees
'J'bis topic describes the native supplicant provisioning process for iOS endpoints.
Native Supplicant Provisioning for Employees
-
I
·--
Supplicants can be automatically provisioned v.ith a certificate. When an employee accesses the network
with a personal device, the user will open a web page and! receive a redirect. The Cisco ldentity Services
Engine will return a CA certificate for trust purposes. The user will be offered the opportunity to register the
device. The Cisco ISE will then add the user to the registered devices List as an identity group and begin
device enrollment. For example, it might ask the user to create a CSR based on user information like tbe
Y..Q!.. the MAC address, and some other attributes. That information is sent to the Cisco ISE, where, because
it is a SCEP proxy, it will forward the request to theCA s:erver. The certificate will then be issued. The
Cisco nSE can now push the profile that the user is going to use for the final connection. It will then create a
new CSR, which is pushed back. A key point to note here is that the common name vaJue is now dle
employee nan1e that the user used when logging in, and the~ value is the MAC address of that endpoint.
5-0a lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Provisioning for Employees: Wi-Fi Profile
This topic describes the configuration of the supplicant profile that is provisioned on the employee
endpoints.
.--------------------------------,
Provisioning for Employees: Wi-Fi Profile
--- - -·........... - ~ .
----
.... .,.._ ,
lit - 15. - ~ ... 1!;. - .,.o.t-. ---~ -- -
p
--~·
--~-~
---
··-
~· '!:;•
·- j.,_
.··-··-............-__
.,...
- r-
The Wi·f i profile, configured by navigating to Policy> Policy Elements> Results> Client Provisioning
> Resources, defines the wired or wireless connectivity settings for employees. lhe.lie settings are used by
the native supplicant after the provisioning phase. They define the connection type (wireless or wired) ,
SSID, security~ or WPA2), allowed protocol {TLS or I'EAI'), and the key size.

Client Provisioning Policy for Employees
'J'bis topic describes bow to configure the client provisioning policy for employees.
Client Provisioning Policy for Employees

Client provisioning selects the appropriate profile based on:
Identity groop
Operating system
---
Other cond rtions
-· --·---·----- -
----·--------
--------
.....
~-~-~~ -- --- -- -
....---
I •Ia '~•~!!!.~.,., . • t n [ - -.... !1
• ·IS: ~~·- - · - ~-- •J
.... - --
t '""' - - -
~. ----- -
...---- - -
-·--~-
..... --..,.._
The client provisioning policy defines the profiles that are provisioned on endpoints, depending on the user
identity group, the endpoint operating system, and other conditions.
Employee Access After Endpoint Provisioning
This topic describes employee access after endpoints have been provisioned.
Employee Access After Endpoint Provisioning

After provisioning, an endpoint has:
Certifica to
Nativo supplicant
Wi-Fi prOfile
Connections are made via the SSID that is obtained in the profile
,._
CTS-CORP SSID
'%\1
....... _.
After rne successful provisioning of employee endpoints, the employees connect using the specified SS(D
and security parameters.

Verify BYOD: Device Registration
'J'bis topic describes the user experience when going through the BYOD device registration phase.
Verify BYOD: Device Registration

1. User redirected to guest portal
2. CA certificate is installed
3. User enters a description for the registered device
4. ISE learns MAC address of the endpoint
5.
--
Profile installation drtfers between operating systems
.......... ..-..-------
--
C:tKO .........._~.
---
,.,_.__,.... , _
---·-
.........
:;~-----------
--·~
l=-·
--
ln this scenario, the employee connects with a mobile device to the provisioning SSID and is redirected to
the gues[ portal for registration after opening a browser. The employee logs in using Active Directory
credentials.
After theCA certificate is installed, the user enters a description for the device being registered. Tbe Cisco
Identity Services Engine learns the MAC address of the endpoint and the profile installation begins.
If profiling is being used, additional attributes will be sent to the Cisco ISE mat will determine the type of
Apple device and add it to the nominated endpoint group.. This group will then determine the authorization
profile that the user will receive.
Tbis scenario sho\\'S the procedure on an Apple iOS device-an iPhone, iPad. or il'od. It differs slightly
from the user experience on Android devices.
Verify BYOD: Client Provisioning
This topic describes the user experience when going through the client provisioning phase on an Apple iOS
device.
Verify BYOD: Client Provisioning

The supplicant is downloaded and installed directly from the Cisco ISE
--
·-
- --
·-
---
Keys are generated and the mobile profile is installed
----
-----
----- -----
----
--- ~---
......,...
-- -""' ....
-- ==--
The supplicant profile is downloaded and installed on the endpoint. Keys are then generated and the
certificate is enrolled. The Wi-Fi profile that is required to connect to !he BYOD_Employee SS!D is
installed.

Verify BYOD: Connect to the SSID
'J'bis topic describes the user experience when connecting; to the SSID on Apple iOS.
Verify BYOD: Connect to the SSID

. Mobile profile indudes WJ.. f i configuratioo
. Connection to BYOD_Employee 5510
Apple iOS: Manual
Android: Avtomaticaly as part of the prOvisiOning
. Example: Manual connection on Appla iOS
·- '
-
...==-.-- -•-
ISEsolf... O'Oisioooltog-
•PMIU be 1l.d to c:annc!!CI 10 N
BYOO_~ ~ 8fter
suecessiuty iM:tMiinQ tho PfQfie.
..--
t.-- .-
•
e::-- .--- "
-·- - -
-
·-~
The Wi-Fi profile that is required to connect to the BYOD_Employee SSlD is installed. On Apple iOS
devices, the employee is required to manually connect to ·the BYOD_Employee SSID. On Android
endpoims, d>econnection to the BYOD_Employee SS!D is performed automatically as pan of the
provisioning process.
·The example in the figure illustrates the manual connection on Apple iOS.
5-N lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Summary
Summary
The BYOD solution typically includes Cisco ISE, back..and servers.
WLCs, and wireless APs.
The BYOD solution is typically bUiilt based on dual SSIO access.
Employee endpoints are provisioned with a native supplicant. a
certificate, and Wi·Fi settings.
The Cisco ISE uses SCEP to request certificates for employees.
Users are guided through the device onboarding process.
. ...... _

Module Summary
Module Summary
Posture service ascertains the compliance state of the connecting
endpoints.
ProfUer service classifies the end points into the endpoint identity
groups.
The BYOD solution is typically implemented in the dual SSID
approach.
0,.,.__.._
References
Module Self-Check
Questions
I. On which nodes does the posture service run? (Source: Deploying Posture Service)
A. on all nodes in the Cisco IS£ deployment
B. by default, on all nodes in the Cisco IS£ deployment
C. on all nodes in the Cisco lSE deployment with the session services enabled
D. on all nodes in tl1e Cisco IS£ deployment with the profiler service enabled
E. on all policy service nodes in the Cisco JSE deployment
F. by default, on all policy service nodes in the Cisco ISE deployment
G. on all policy service nodes in the Cisco JSE deployment with the session services enabled
H. on all policy service nodes in the Cisco JSE deployment with the profiler service enabled
2. What are the two building blocks of the Cisoo ISE posture policy? (Choose two.) (Source:
Deploying Posture Service)
A. requirements
B. authorization policy J\lle
C. client provisioning
n. remediation
E. dictionary attributes
3. Posture updates can be scheduled automatically. (Source: Deploying Posture Service)

A. true
B. fal<e
4. \\'hat is the basic unique representation of an endpoint by the profiler service? (Source: Deploying
l,rofiler Service)
A. endpoint profile
B. endpoint ID
C. MAC address
D. fp address
5. On which two nodes does the analyzer run? (Choose two.) (Source: Deploying l'rofiler Service)
A. admin nodes with the profiler service enabled
B. admin nodes with the analyzer service enabled
C. admln nodes also acting as the sensors
V. policy service nodes with the profiler service enabled
E. policy service nodes with the anaJyzer service enabled
f. policy service nodes also acting as the sensors
6. CoA support is required to run the protiler service. (Source: Deploying Pro tiler Service)
A. true
B. false
7. \Vhich software is provisioned as a result of device onboarding? (Source: Implementing BYOD)

A. WebAgent
B. native supplicant for Windows
C. NAC Agent for Macintosh
D. NAC Agent for Windows
8. Open SSCD is used for provisioning in both single and dual SSID scenarios. (Source: Implementing
BYOD)
A. true
B. false
9. Which approach is most common when deploying l!YOD? (Source: Implementing l!YOD)
A. mixed
B. single SS!D
c. dual ssro
D. fixed SS!D
Answer Key
I. G
2. A,D
3. A
4. c
5. C,F
6. B
7. B
8. A
9. c

Module 61
Access Control
Troubleshooting
The Cisco Identity Services Engine offers a a number of troubleshooting tools. The general tools include
RADIUS Authentication Troubleshooting. Execute Network Device Command, Evaluate Configuration
Validator, Posture Troubleshooting, and TCP Dump. You will learn about the most efficient strategies when
troubleshooting Cisco network access control.
Upon completing tills module, you will be able to:
.. Troubleshoot Cisco network access controls.
6-2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, l nc.
Lesson 11
Troubleshooting Network
Access Controls
Overview
Network access control mechanisms restrict access to the network based on identity or security posture. The
network access devices force user or machine authentication prior to granting access to the network. In
addition, guest access can be granted to a quarantine area for remediation of any problems that may have
caused authentication failure. This quarantine is enforced through an inline network device, or through
c hanges to an existing access device. Network access control encompasses various components that
interoperate. To effectively troubleshoot the solution, you need to understand the operation of AAA,
802.1X, MA~ and know the troubleshooting tools available on the Cisco Identity Services Engine antd the
oetv.·ork access devices.
Upon completing this lesson, you will be able to identify and O'Oubleshoot problems when implementtng
and operating Cisco access control solutions. You will be able to meet these objectives:
• Describe how to troubleshoot the pro filer service
• Describe the troubleshooting tools available on Cisco ISE
• Describe the RADfUS Authentication 1'roubleshooting tool
Describe the Execute Network Device Command tool
• Describe the Evaluate Configuration VaHdator tool
• Describe the Posture Troubleshooting tool
• Describe the TCP Dump tool
• Describe troubleshooting of 802.1x authentication
• Describe how to troubleshoot the 802.1X operation on an access switch
• Describe how to troubleshoot RADIUS peering
• Describe how to U'Oubleshoot peering with the backwend user database
Describe how to troubleshoot identity source sequenc:ing
• Describe how to troubleshoot client·side certificate issues
Describe how to troubleshoot disallowed authentication protocol issues
Describe how to troubleshoot machine authentication
Describe how to troubleshoot Central WebAutb
• Describe the ISE authentication policy settings tllat are required for Cenrral W'ebAuth
Describe the Cisco ISE authorization policy settings that are required for WebAuth
Describe the ISE authorization profile that is used for rraffic redirection
Describe how to troubleshoot a mismatch of the ACL name
Describe how to troubleshoot the posture service
Describe the use of the client provisioning policy in the posture service
Describe the Cisco ISE p<>Sture policy
Describe tlle Cisco lSE posture requirements
Describe how to troubleshoot a posture service problem
Describe how to troubleshoot the profiler service
Troubleshooting Procedure
'This topic describes general troubleshooting procedure.
Troubleshooting Procedure
j_

Effective tt'Oubleshooting requires a structured approach. This flow has proven very successful when
troubleshooting problems:
I . Define the problem: Look for symptoms and lhen determine lhe problems <hat could result in the
symptoms you found. An example of such a symptom is a host that is not responding to the requests
from the clients. One possible cause of this can be a misconfiguration of the host.
2. Gather det-ailed information: Collect ali much information ali you can about the reported issue. Ask
the affected users for information, and look for information in different sources such as the NM~
debug and show commands, and so on.
3. Consider a probable solution: With all the inf ormation you collected, try to determine the elements
that might not be causing the problem. An example could be cbe hardware. If you can eliminate lhe
hardware as a cause, you can concentrate on the software.
4. Devise a plan to soh•e the proble-m: Determine the most likely cause of the problem and devise ithe
plan.
S. Implement the plan: Start implementing cbe action plan step by step and see if any of the symptoms
start disappearing. Carefully keep track of any change.li so you can revert any counter effective or
ineffective changes.
6. Obsen·e the results of implementation: Whenever a change is made, look at the results or impact of
the change. You can always use dte diagnostic tools for additional help or information.
7. Re.peat the process if the proble-m is- not solved: If the problem has not been resolved, follow che
process again until there is no problem in the netv..-ork.
8. Document the solution: This step is one of the most important steps. Any change in the device
configuration should be documented and communicated to the technical staff. It is always easier to
troubleshoot a well-documented network.

Cis.co ISE Troubleshooting Tools
'J'bis topic describes the troubleshooting tools that are available on Cisco Identity Services Engine.
Cisco ISE Troubleshooting Tools

Troubleshooting is often triggered by a problem indication from:
Monitoring dashbOard
A!anns
Other tools
Failuro Reason Editor
Diagnostic toolS
General
Soourity Group ACCOSS
Additional repositories:
Debug lOgS
Support bundles for Cisco TAC
Cisco nSl~ offers several tools that assist you in the troubleshooting process and provide you with a problem
description upon which you can act. You can receive a pr.oblem indication from the Monitoring dashboard
and from !he Alanns pages.
Useful troubleshooting tools include the 'failure Reason Editor and dle General and Security Group Access
diagnostic tools. The debug logs may be useful when troubleshooting system faults that are not easily
solved using first·level methods. Jfyou escalate a problem and report it to Cisco Technical Assistance
Center,. you will need to package the system infonnation into support bundles.
'J'he Execute Network Device Command diagnostic tool allows you to run me show command on any
network device from the centralized Cisco ISE dashboard. The results are exactly what you would see on a
console, and can be used to identifY problems in the configuration of the device.
'J1le TCP Dump utility monitors the contents of packets on a network interface that match a given Boolean
expression. You can use the TCI' Dump utility to troubleshoot problems on your network. Cisco (Sil
troubleshooting diagnostic tools provide an intuitive user interface for this utility.
6.0 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

RADIUS Authentication Troubleshooting
This topic describes the .&\.Q!!l.~ Authentication Troubleshooting tool.
RADIUS Authentication Troubleshooting

Provides information about failed access attempts
Details about the user and endpoint
--
·- --'o-:==
--
.·--
·--·
·--
---
..
- -·
, _ - ·- ·
.,....----
-_ --·- 1--~~~
'
·--
·-
··-- -- ::;. - - - -:=...=::.:-.:=""'"_________
·-- - ...,..._ ·-----

~-
·=--· -- ............. .
--
- ...._ .
- --- .........
·-
-· --·---
......
---~-
-
....... _.
The RADIUS Authentication Troubleshooting tool examines different aspects of a session and provides
some details which may not have been available in the detailed authentication report. lt also provides some
advice on resolution for issues found in the diagnosed session. The tool provides the ability to search and
select an individual authentication session based on criteria such as usemame, ~ address, ~ 11', and
date/time ranges. 1t even allo\\'S you to search on an individual common session lD.
l.n the simple example shO\\'D in the figure, the problem was that the subject was not found in the applicable
identity stores. This could indicate an issue with the identity source sequence configuration. It could also
mean. as suggested, that the identity source may not be compatible with the EA..f protocol used by 802.1X.

Execute Network Device Command
'J'bis topic describes the Execute Network Device Command tool.
Execute Network Device Command

Passes the command to the device
Requests credentials for the Telnet or SSHv2 connections
·-
-- -·-- -
- - - -;;;;;;;;;;-:;-;;.;~=·~-::-:.·..::=::.;·:______
-- ..
··--
·---
·--- ----
---
·-
··-
··----
.,_ --·;==-=-- ==-::·==::·====--.,
· - - · -.. u
--=-----
--
-
-: ____
-·-- -n
··=--~-~-~-==-
--
------
--
----
----
__
---- ... _
--
___
·-~
...
-~
Tbe Execute Network Device Command tool does what its name suggests. It is designed to allow you to ruru
a show command against a network device from within Cisco Identity Service." Engine. t o initialize the
tool. you must specify a device by W address or ON~ hos:tname and you must specify the command to
execute. Tbe tool does not parse the command. It simply p asses the command to the device. This means
there is no syntax validation, but it does allow acceptable command Line abbreviations. Once the tool is
initiali2ed, it will also request credentials for the device and allow you to select to connect via Telnet or
SSHv2. After command execution, the results are display.ed.. The example depicted in the figure shows the
execution of an abbreviated form of the show authentication sessi on interfac.e GigabitEtbernet 0/ 1
command.
&-a lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Evaluate Configuration Validator
This topic describes the RADIUS Authentication Troubleshooting tool.
Evaluate Configuration Validator

Evaluates the configuration of the NAO
Results grouped in categories
-·- --
·--
·--
·- --- -- - '
- -
...,
·- ::--------·----r,__~~--~--------------~1
··-- - ---
--
-• ·--
··---
---
•
EJ----,_
:: ~-= -
0 ...... _ .
The Evaluate Configuration Validator tool is very useful, but its output should be considered
recommendations, not requirements. To initiate the tool, you specify the NAD by fp address or hostname
and you specify the sections of the configuration th:at it should validate. The tool examines the configuration
and compares it to a template and reports on any differences it finds; between the two. The administrator
should consider the report and determine if the configuration should be modified to coincide with the
template or not. It is quite possible that there are more than one way to configure equivalent behavior. It is
also possible that you are intentionally not implementing all features between the NAD and Cisco Identity
Services Engine.
The tool allows you to specify the NAD and to select the aspects of the configuration that it will evaluate.
\Vhen the tool is executed, it will ask you choose between Telnet and SSHv2 and to provide administrative
login credentials. When the tool finishes, it provides a hierarchical report, allowing you to expand and!
collapse details on a per section basis.
[n the example depicted, the toolis showing that DHCI~ snooping features have not been configured
globally on the NAD. This can impact profiling. Note that the U' device tracking feature is enabled. This
can provide a MAC to fp address mapping which is made available with the standard RADfUS profiling
probe. But, DHCP snooping can support more accurate lP tracking resuJts. Also, if the NAD supports the
LOS device sensor feature, then other DHCP data can be provided for profiling, such as the contents oftlle
OHCP client-identifier field.

Posture Troubleshooting
'Jllis topic describes the Posture Troubleshooting tool.
Posture Troubleshooting
Displays steps passed/failed in the pos~u re process
Describes remediation
---
·-- --- ·--- ~--
==~~-~
~-
--~-~==~----------------
--
·---
··--
·---- ----
_..._________
-----·--
-- -- - -
---___
·--
·-- ·--~-
··-
··----
·--- ----- _____- _·--
----
,........
---
.......
- '=
·-·- -- _ __ _ - ---
;;..
··--
·-- - -.:... ..
------
The Posture Troubleshooting tool helps you find the caus.e of a posture check failwe. You can easily
identify which endpoints were successful in posture and which were not. If an endpoint failed in pooture,
the too I lists the steps failed. in the posture process. Jt describes which mandatory and optional checks
passed and failed. You can determine this infonnation by filtering requests based on parameters, such as
usemame, MAC address, posture status, and so on.
6·10 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
TCP Dump
This topic describes the TCP Dump tool.
TCP Dump
Packei capture tool
Captures packets on any ISE in terface in deployment
~----
--·- - _...__ _ ,_
•- - ..::-
===- =-~.'i!::i:!i~-==::..;._
- - - - · 0 - ·
. ·-- ,.,. .. ...... ... _........

·---
·-
·--
·-
··----
-· ---
-----..... -
·-'~- "-~1"-· ·-
....... _. --
---·
--..
Packet captures are an extremely valuable troubleshooting tool. They aiJow you to dive deeper than you can
with the .Q.lli, CL[ debu~< and various logging technologies. Generally, to accomplish a packet capture, you
must configure SPAN on a switch and set up a packet capture tool on the SPAN destination port. To make
this much easier from Cisco Identity Services Engine's perspective, TCP dump has been built directly into
[SE. You can use TCP dump to capture the packets that are sent by and received on any particular interface
on any ISE node in the deployment. You can choose for the dump to be fonnatted as raw packet data, which
can be downloaded as a Pcap file which can be downloaded and read by a packet analyzer on your
workstation. You can also choose for the dump to be formatted as human readable, in which case it is
fonnatted as a text file that can be loaded into a text processor on your workstation.

Troubleshooting Authentication Overview
'Jllis to pic describes the troubleshooting of!!?£§ 802.IX authentication.
Troubleshooting Authentication Overview

Potential authentication problems mi ght be related to:
1. 802.1X and AAA s ettings oo the switcll
2. RADIUS peering
3. Peering w ith back-end authentication servers
4. Certifica tes in EAP authentication
5. ISE authentication settings:
AuthenticatiOn poli¢y
A!bwed prOioools
Identity sources and identity sou~ SGquonces
Gertifi<;.ato authenticatiOn profiles
CGrtificato stOre settings
802. 1X authentication failures can occur as a result of various reasons. Tbe list in the figure summarizes the
most common problems, which are dl(icussed in lhe several next topics.
Troubleshoot 802.1X on Switch
This topic describes the troubleshooting of fEE£ 802.1X operation on an access switch..
Troubleshoot 802.1X on Switch

. If !here is an lnootreCI or Incomplete s-Mleh .conflgursticn. you may see Incomplete Of no
802.1)( debugging:
~vitc:M d~ c!Qth ev~W~t•

dot • ~-evtsi0/ 1 1 : ~~lved p~t e~d~: ~Q36.9i1~ . 3b~l • daddx • 0180 .c200.0COJ.
p;ut-othflr-t yPQ • &"IISt:t.OlOl . OCOO
dl'>l.tl<•CioVlC10/lJ : ~ ... <:lhU~t ®t~<:UI:d, L~sutr.9 St~rt ~quo't to A~th~c
dot i ~·evlSi0/ 1 1: Rol e deter"i~~t lon noe req~ired
dotlx--ev:&l'lqueued tbe INI;>ol f.-4C:ket to cue 91~111 •'.ltner..ue•t-er <II.X''Je
F.AI'Ol. p~.k dl.:4'4" l:>(
EAI'OL Votll.ton : ext type: Cxl lC1n9!.1l: !lxC,CO
dot t ~-ev: dot l x_•~tb_que'.le_eve~t: l~t Gi0/ 1 ~at· 0,7Y?t• O .LE~· 0
Mlssfng authen6ca:lon results:
svtt~l •bov
~o A~tb M~~•~er
•uth.nti<:ati~
eontex:e
•• aalGn tne.rfac. gt9ablt 0/l
~teb eupplie~ erltert~ I
...... _.
The 802.1X authentication can fail due to an incorrect 802.1X configuration on the access switch. You can
monitor the 802. 1X operation using the debug dotlx command This command provides several optio.ns for
differentiated ourput granularity. Depending on the 802.1X misconfiguration, you may not see any
debugging output at all or you may see that the 802.lx never complete.(i.
ln this example, the 802.1X procedure never reaches the expected phase "Starting 'dotlx' for client MAC
addres~," and therefore me port is never authenticated.

Troubleshoot 802.1X on Switch (Cont.)
. 802.1X may never reach "Swtlng 'dot1X' for dlent NAC addresS"
l\VltCl:l ~9 clo'!l.ll • .,.1110:..

®~b-CIV(C:lO/U : Sfl:ncun; c~etlltct fl4'lt cenuxt O'VQflt to £.\P rcr Cx2COOOC!l8
(Oc>OO , 0000. OOCOI
~t-lx·e..,.(GiO/U; Cte•ted • ctier, t ~n~:y (Ox.tcOOOOctn
®t.lX•CIV(C:tO/lt : OOt:x ll':lt.hCU1:t.ic.at1on. JIUttCid ror CxlCOC~t:OS (OCOO . OCOO. OCOO)
~~lx -cv : not:x S~ppl tc•n.t no~ etrAbletd or. Ctq~t~~~t.het~Qt0/1
dct.lX •CI'/(C:H)/11 : lllll'ol Clt.H'\t n.~tH'!CA':-1011. r..-cm .\uti'>.~·! !'l>r Cx2COOl~!l8 -
•01H i.9fl•.3Qbl
\AQlSMGR·$·$~AR~: :> t.ac-tin') ' dQt.t • • toe eli•;.~ t•036.9H.• .Mt) Q::l J:"i;.~tt'(•c.
010/1 ~tS.IIJ1o~IO OACA020200GOOOASOS20001C

dct.lX•IW(Cl.O/lt : Sflndinq £APO~ pltCkC t to llC36 . 9! ••. 3bbt
~tlx·ev(Gi0/1t: R~le d e te:run.•tio:. Mlt. :e;;..u. :e-:i
dot lx·e•r (Gi0/1>; sendi:o!i out U.i'Ol. i'K~et
~tlX •C'/(C:t 0/ 11 : Rtllettt1n9 t~l cl1*11t. Ox2COlCO~$ lll03ii . S!lll . 3llbl ~
®~b-CIV(C:lO/ lt : Sfl:ndtnq C~CIIltct fl4'lt CC:fiU:Xt O'VQflt to £.\P rcr Cx2COOOC!l8
(•036, 9fl.a. 3boll
®t.lx·e..,.(G~O/H; Role d~tetl1ill4tion Mit :e;;..u. :~
®':.ll(·9v:::r.qi:II'J8'.1 ~:to 9ilpol piiO:iU'It to t~~ ~1~~1 ~~t~tnt 1~to: ~o~o
~~lX •CIV(C:t 0/lt : Sor.d1~~ tAPO~ p&cket to ~036 . 9!l~t . 3bb:
<out put <:!U t t \"d>
___
tOOTlX·S·SQOC&$$;
,
A:.lthet~ti<:•U.Oo!! '""cc•.. t~.~-1 to~ c l ilf.1lt (•034. ff1• ,31»l)
When the switch configuration is complete, the 802. 1X procedure goes through the "Starting 'dotlx' for
client MAC address" phase and the port is authenticated. Complete debugging output and port
authentication status verification are shown in the following output:
switch' debug dot .lx eventa
sep S 09 : 21 : 38 . 611 : dotlx• e\'(Gi0/1) : Ine er!ace state changed c.o UP
Sep S 09 : 21 : 38 . 6 5 ~ : dotlx .. ev(Gi0/1) : Sendi.ng create ~e~o.• context event to~.? !.or
Ox 2C0000 ~B (0000 . 0000 . 0000)
Sep S 09 : 21 : 38 . 6 5 ~ : dotlx .. ev (Gi0/1) : Created a client entry (0x.2C0000D!H
Sep S 09 : 21 : 38 . 6 5~ : dotlx• e\' (Gi0/1) : Dotlx aut..hentication st:aned tor Ox2C00000B
i0000 . 0000 . 0000)
sep S 09 : 21 : 38 . 65~ : dotlx- ev : DC'r1X supplicant. not enabled on GigahitEthernet:0/1
Sep S 09 : 2 ·~ : 38 . 661 : dotlx ~ ev(Gi0/ 1) : New clie nt noti.fi.cati.on fr-o!'ll. Au thMgr !or
Ox 2cOOOO ~B - a0~6 . 9!1a . 3bbl
Sep S 09 : 2 ·~ : 38 . 661 : \J..UTf~R -5- STA..~T : St:arti ng ' dot1x' !or c lient {a 036 . 9fla . 3hbl.)
on Intertace Gi0/1 AuditSessicniD 0AOA0202000000A50520D01C
Sep S 09 : 2 ·~ : 38 . 661 : dotlx- ev (Gi0/1) : Sendi.ng EAPOL packet to a0~6. 9!'1a . 3bbl
Sep S 09 : 21 : 38 . 661 : dotlx.. ev(G10/1) : Role det ermination not r ·equired
Sep S 09 : 2 ·~ : 38 . 661 : dotlx- ev(Gi0/ 1) : Sending out EAPOL packet
Sep S 09 : 24 : 38 . 661 : dot1x• ev(Gi0/ 1) : Resetting the client Ox2C000003 (a036 . 9!la . 3bh1)
Sep S 09 : 2·'1 : 38 . 661 : dotlx .. ev(G10/l) : Sendi.ng create :'le·... context event to~.? t.or
Ox 2C0000DB (a0~6 . 9f1a . 3bb1)
Sep S 09 : 2·'1 : 38 . 661 : dotlx• ev(G10/1) : Role del!:erm.inatton not r-e.quired
Sep S 09 : 24 : 38 . 661 : dotlx• e •.. : Enqueued the eapol packet to the <;;lohal a uthent:S.cator
queue
Sep S 09 : 24 : 38 . 661 : dotlx• ev(Gi0/ 1) : Sending ~~POL packet to a0~6 . 9!1a . 3bbl
sep S 09 : 2·'1 : 38 . 661 : dotlx .. ev(G10/ 1) : Role det ermination not r-e.quired
Sep S 09 : 2 ·~ : 38 . 661 : dotlx- ev (Gi0/1) : Sending out EAPOL packet:
Sep S 09 : 2·'1 : 38 . 661 : EA?OL p.ak dU!II.p r:x
Sep S 09 : 2 ·~ : 38 . 661 : Y..POL Version : Ox 1 type : Ox 1 length : OxOOOO
Sep S 09 : 2·'1 : 38 . 661 : dotlx .. ev : dot.1x_auth_queue_event : tnt Gi0/1 CODE- O, TYPe.. O,LEN• 0
Sep 5 09 : 2 ·~ : 38 . 661 : dotlx.. ev (Gi0/1) : Received p kt saddr • a036 . 9tla . 3bb1 , dadd't' -
0180 . c200 . 0003, pae• ethertype - 888e . OlCl . OOOO
Sep S 09 : 2 ·~ : 38 . 661 : dotlx.. ev(Gi0/1) : Resett;! n9 the client. Cx2C0000D3 (aG36 . 9fla . 3~hl)
Sep S 09 : 2·'1 : 38 . 661 : dotlx .. ev(Gt0/1) : sendi n9 create ~ew eont:exc event to Bl'.? t.or
Ox 2C00000B (a0~6 . 9f1a . 3bbll
Sep S 09 : 21 : 38 . 661 : dot1x• ev (Gi0/ 1) : Sendi ng ~~POL pack.et. to a0~6 . 9fla . 3bb1
sep S 09 : 21 : 38 . 6.10 : dot.lx .. ev(Gi0/1) : Role det erm.inati.on not required
Sep S 09 : 21 : 38 . 6?0 : dot1x• ev(Gi0/ 1) : Sendi ng out EAPOL packet
sep S 09 : 21 : 38 . 670 : dot1x .. ev(Gi0/l) : Role det erm.inati.on not required
Sep S 09 : 21 : 38 . 6?0 : dot1x• ev: Enqueued the eapcl packet to the 9lobal authen~ ! eat:or
queue
Sep S 09 : 21 : 38 . 6?0 : ~. ?OL pak dump r:x
Sep S 09 : 21 : 38 . 670 : EAPOL Ver·s ion : Ox 1 type : OxO le:'IQ.th : Ox000C
Sep S 09 : 21 : 38 . 670 : dot:lX.. ev : dotlx_auth_queue_event : lnt GiO/l CODE• 2 , TY?E- l ,LE ~i
lZ
Sep S 09 : 21 : 38 . 670 : dot:lX.. ev(Gi0/1) : Received pkt saddr • a036 . 9tla . Sbb1 , dadd:r -
0 180 . c200 . 0003, pae• ether•type .. 88Se . 0 1C0 . 000e
Sep S 09 : 21 : 38 . 670 : dot:lx.. ev (Gi0/1) : dotlx_ s.endRespToSetver: Response sent co t:he
server (r~ Ox.2C0000D3 (a036 . 9!la . ~bb1)
Sep S 09 : 21 : 38 . 670 : dotlX- ev (Gi0/1) : Role de t e~m.i nation not r ·equired
Sep S 09 : 2 ·~ : 38 . 670 : dotlX- ev : Enqueued the eapol packet to the <;;loha1 authent:!eator
Q'jeue
Sep S 09 : 2·'1 : 38 . 610 : Y..?OL pak duta.p r:x
Sep S 09 : 24 : 38 . 670 : Y..POL Version : Ox 1 type : OxO length : OxOOOC
Sep S 09 : 2·'1 : 38 . 610 : dotlX .. e\' :dot1x_auth_queue_event : Int. Gi0/1 CODE- 2 , TY?E- l,LEN•
lZ
Sep S 09 : 2·'1 : 38 . 610 : dotlx .. ev(G10/1) : Received pkt saddr: - a036 . 9!la . 3bb1 , daddr-
0180 . c200 . 0003, pae- ether-t:ype - 88Se . OlCO . OOOe
Sep S 09 : 2·'1 : 38 . 610 : dotlx .. ev(G10/ 1) : Role del!:erm.inatton not re.quired
Sep S 09 : 21 : 38 . 610 : dot1x.. ev : Enqueued the ea-r-ol packet to the <;;lol::a1 a uthentic.ator
q•je ue
sep S 09 : 21 : 38 . 670 : Y..?OL -pak dum.p r:x
Sep S 09 : 2·'1 : 38 . 610 : EA?OL Version : Ox 1 type : OxO length : OxOOOC
Sep S 09 : 21 : 38 . 670 : dotlx.. ev : dotlx_auth_queue_event : Int Gi0/1 CODE- 2 , TYPE.. l ,LEN•
lZ

Sep 5 09 : 24:38 . 678 : dotlx • ev(Gi0/1) : Received pkc sadd~ -a036 . 9fla . 3hbl , da6dr ~
0180 . c200 . 0003, pae ..ether· type - 888e . Ol00 . 000e
Sep 5 09 : 24 : 38 . 618 : dotl:x• ev(Gi0/1) : Sending ~.?OL packet to a036 . 9fla: . 3bbl
Sep S 0~ : 24 : 38 . 6 '18 : doth.• ev(Gi0/1) : Role det.er.':'li nation not requ i ~ed
Sep 5 09 : 24 : 38 . 6/8 : dotlx• ev(Gi0/1) : Se~ding out EAPOL packet
Sep S 09 : 24 : 38 . 686 : dotlx- ev(-Gl0/1) : Role det.em1nat.1on not requi :red
sep 5 09 : 24 : 38 . 686 : dotlx• ev : Enqueued the eapol packet t.o the globa l authenticator
.queue
Sep 5 09 : 24 : 38 . 686 : E:\POL pak du~:p rx
Sep S 09 : 24 : 38 . 686 : E.~OL Version : Oxl type : OxO length : Ox0006
Sep S 09 : 24 : 38 . 686 : dotl x• ev : dot1x_auth_queue_event : tnt Gi0/1 OODE• 2, TYPE- 3,L£N• 6
Sep 5 09 : 24 : 38 . 686 : dotlx- ev(-Gl0/1) : Received pkt s add.:r ..a 0 3£ . 9f1a . 3hbl , daddr -
0180 . c200 . 0003, pae ~ether • type - 888e . Ol00 . 0006
Sep S 0 ~ : 2Jl : 38 . 69S : dotlx • ev(GiO/l) : dotl x sendRespToServer : Response sent to the
se:'Ver !ro:n Ox2C0000DB (a036.9na . 3bbl) -
sep S 0 ~ : 2Jl : 38 . 703 : dotlx • ev(GiO/l) : sendi~g ET~ ?OL packet to a036 . 9na . 3bbl
Sep S 0 9 : 24 : 38 . 703 : dotlx - ev (Gi0/1) : Role det:er.':'li nation not requ i ~ed
Sep S 0 ~ : 2Jl : 38 . 703 : dotlx • ev(Gi0/1) : Sendi~g out EAPOL packet
Sep S 09 : 24 : 38 . 703 : dotlx - ev(Gi0/1) : Role det:er:':'li nation not requ i ~ed
Sep S 0 ~ : 2Jl : 38 . 70 3 : dotlx • ev : Enqueued the eapol packet. to the globa l authenticator
q·ueue
Sep 5 09 : 2Jl : 38 . 103 : E.~OL pak du."!':p r x
S.ep 5 0 9 : 2<11 : 38 . 703 : E.~OL Version : Oxl type : OxO length : OxC089
Sep 5 09 : 2Jl : 38 . 103 : dotlx• ev : COtlx_auth_queue_event : tnt Gi0/ 1 OODE- 2,TYPE- 2S ,!.EN•
13?
Sep 5 09 : 2Jl : 38 . 103 : dotl x• ev(G10/l) : Received pkt sadd.r •a036 . 9fla . 3hbl , daddr -
0180 . c200 . C003, pae• ether• type - 888e . Ol00 . 0089
Sep 5 09 : 2Jl : 38 .'i03 : dotlx• ev(G10/l) : dotlx_send:RespToServer : Response sent to the
ser'ler tro.-n Cx2C0000DB (a0 36 . 9f1a . 3hbl)
Sep S 09 : 24 : 38 . 712 : dotl:x• ev(Gi0/1) : Sending ~.?OL packet to a036 . 9fla: . 3bbl
Sep S 0~ : 2Jl : 38 . "112 : dotlx • ev (G10/1) : Role det.er.':'li nat.ion not requi ~ed
Sep 5 09 : 24 : 38 . '/12 : dotlx- ev(Gi0/1) : Sending out £..\POL packet
Sep S 0~ : 24 : 38 . ''112 : dotlx • ev(Gi0/1) : Role det.emi nat.ion not requi ;r.ed
Sep 5 09 : 24 : 38 . '/12 : dotlx- ev : E:nq\leued the eapol packet. to the qloba ! authe:'ltieator
queue
Sep 5 09 : 24 : 38 . '112 : EAPOL pak du!!:p rx
Sep S 0 ~ : 24 : 38 . 712 : E.~OL Version : Oxl type : Ox O len9th : Ox0006
Sep 5 09 : 24 : 38 . 112 : dot1x • ev : dot.1x_auth_queue_event : tnt Gi0/ 1 OODE• 2, TYPE- 2 S,LEN•
6
Sep 5 09 : 24 : 38 . 712 : dotlx• ev(Gi0/ 1) : Received pkt. sadd.r -a036 . 9tla . 3bbl , dat!dr -
0180 . c200 . 0003, pae- et.her• type - 888e . Ol00 . 0006
Sep S 09 : 24 : 38 . 'H2 : dotlx• ev(Gi0/ 1) : dotlx_senc!Res-p.ToServer : Res-ponse se!lt to the
server tr~-n Ox2C0000DB (a0 36 . 9fla . 3bbl)
Sep 5 09 : 24 : 38 . '1'28 : dotlx • ev(G10/l) : Se~ding EJI..?OL packet. to a036 . 9tla . 3bbl
Sep S 09 : 24 : 38 . 128 : dotlx- ev(-G!0/1) : Role det:en':'!i nat.ion not requi red
sep 5 09 :21; 3a . ?26: dotlx· ev(G10/ l ); sending out EAPOL packet
Sep S 0~ : 2Jl : 38 . 7 28 : dotlx • ev(Gi0/1) : Role dete~ i nat ion not requi red
Sep S 0 9 : 24 : 38 . "128 : dotlx - ev : Enqueued the eapol packet. to the global authe:'ltieator
queue
Sep S 09 : 24 : 38 . 728 : EAPOL pak du~p rx
Sep S 0 ~ : 2Jl : 38 . 73'1: E.~OL Versi o n: Oxl type : OxO ten9th : Ox0006
Sep S 0 9 : 24 : 38 . "137 : dot1x - ev : d:ot.lx_aut.h_queue_event: : tnt Gi0/ 1 OODE.• 2,TYPE- 2 S, LEN•
6
Sep S 09 : 24 : 38 . "137 : dotlx - ev(Gi0/1) : Received p~t. saddr -a036 . 9f1a . 3hbl , dat!dr -
0180 . c200 . CC03, pae• ethertype- 888e . Ol00 . 0006
s.ep S 0 9 : 24 : 38 . '13'1 : dotlx- ev (Gi0/1) : dotlx send:Resprroserver : Res-ponse sent to the
server f ro.~ Ox2C0000DB (a0 36 . 9f1a . 3bhl) -
sep 5 0 9 : 24 : 38 . '13'/ : dotlx- ev(Gi0/1) : sending El'.?OL packet to a036 . 9tla . 3bbl
Sep 5 09 : 24 : 38 . '/3'1 : dotlx• ev(G10/l) : Role detet"!tli nation :'lOt. requi red
S.ep S 0 9 : 24 : 38 . '13'1 : dotlx- ev (Gi0/1) : Sending out £.\POL packet
Sep 5 09 : 2Jl : 38 . '/1S : dotlx• ev(G10/l) : Role detet"!tli nation :'lOt. requi red
s.ep 5 0 9 : 24 : 38 . 'lr;S : dottx- ev : Enqueued t.he eapol packet to the 9loba ! authenticator
q;ueue
0.16 lmplemen~ng Clsoo Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

sep S 09 : 21 : 38 . 1 45 : Eh?OL pak dump r x:
Sep S 09 : 21 : 38 . 715 : Y..?OL Version : Oxl type : OxO le-~gth : Ox0150
Sep S 09 : 21 : 38 . ? 45 : dotlx .. ev : dotlx_auth_queue_event : Int Gi0/1 CODE- ~ , TY PE.. 25,LEN ...
n6
Sep S 09 : 2 ·~ : 38 . 745 : dotl x ~ ev (Gi0/ 1) : Received pkt saddr • a036 . 9fla . 3bbl , C!addr -
0180 . c200 . 0003, pae• ether· type - 88Se . OlCO . OlSO
Sep S 09 : 2 ·~ : 38 . 7 4 5 : dotlx- ev(Gi0/ 1) : dot:lx s e ndRespToServer : RespO!lSe sent to t he
server rr~ Ox2C0000DB (a036 . 9fla . 3bbl) -
sep S 09 : 2 ·~ : 38 . i 87 : dotlx- ev (G10/ 1) : sending EAPOL packet to a036. 9tl a . 3bbl
Sep S 09 : 21 : 38 . 187 : dotlx .. ev(Gi0/ 1) : Role de t e~m.i nation not r ·equired
Sep S 09 : 2 ·~ : 38 . 'i8 7 : dotlx- ev(Gi0/ 1) : Sending out EAPOL packet
Sep S 09 : 21 : 38 . 187 : dotlx• ev(GiO/ l) : Role dete~m.i nation not r ·equired
Sep S 09 : 2'1: 38 . 187 : dotlx • ev : Enqueued the eapol p acket to t he .global a u t.hent:ic.ator
queue
Sep S 09 : 2·'1 : 38 . 187 : Ei'. ?OL pak dump r x
Sep S 09 : 21 : 38 . 187 : Y..POL Version : Oxl type : OxO le~gth : Ox0006
Sep S 09 : 2·'1 : 38 . 187 : dotlx .. ev :dot1x_auth_queue_event : I :'lt Gi0/1 CODE- ~ , TY ?E.. 2 5 , LE ~i ..
6
Sep S 09 : 2·'1 : 38 . 19S : dotlx .. ev(Gi0/1) : Received p kt saddr - a036 . 9!la . 3bbl , dadd:r-
0 180 . c20C . 0003, pae· ethertype - 88Se . OlCC . 0006
sep S. 0~ : 2 ·f ; 3S . i9S : dotlx.· ev(G10/ l) : dotlx sendRespToSet\'er : Response sent t.o t he
server ! 'roet Ox.2:C0000DB (a036 . 9tla . 3bbl ) -
Sep S 09 : 2·'1 : 38 . 195 : dotlx .. ev (Gi0/1) : Sendi ng E.~ POL packet to a036 . 9f la . 3bbl
Sep S 09 : 2'io : 38 . 795 : dotlx.. ev (Gi0/1) : Role determination not required
Sep S 09 : 2·'1 : 38 . 195 : dotlx• ev (Gi0/1) : Sendi ng out EAPOL packet
Sep S 09 : 2'io : 38 . 804 : dotlx.. ev (Gi0/1) : Role determination not required
Sep S 09 : 2·'1 : 38 . 80<1 : dotlx • ev : Enqueued the eapol packet to t he .global a u thenticat or
que~e
Sep S 09 : 2·'1 : 38 . 80•1 : EAPOL p.ak dU!II.p rx

Sep S 09 : 21 : 38 . 804 : Eh?OL Version : Oxl type : OxO le:'lgth : Ox002B
Sep S 09 : 21 : 38 . 804 : dotlx• ev: dotl x a u th_queue_event : I nt Gi0/ 1 CODE- Z, TY?E.. 2S ,LEN...
4S
Sep S 09 : 21 : 38 . 804 : dotlx• ev(Gi0/ 1) : Received pkt saddr • a036 . 9t1a: . 3bbl , dadd:r-
0 180 . c2C0 . 0003, pae- ether•type - 88Se . 0 100 . 002b
Sep S 09 : 21 : 38 . 812 : dotlx• ev(Gi0/ 1) : dotlx s e ndRespToServer: Response sent to t he
server ! roe'! Ox2C{)000DB (a036 . 9!1a . 3bbl) -
Sep S 09 : 21 : 38 . 81:? : dotlx• ev (Gi0/ 1) : sendi n9 E.~POL packet to a036 . 9fl a . 3bbl
Sep S 09 : 2 ·~ : 38 . 81:? : dotl x ~ ev (G10/1) : Role det ermination not required
Sep S 09 : 21 : 38 . 812 : dotlX• ev(Gi0/1) : Sending out EAPOL packet
Sep S 09 : 2 ·~ : 38 . 82 1 : dotlx- ev(Gi0/1) : Role det ermination not required
Sep S 09 : 21 : 38 . 821 : dotlx .. ev : Enqueued the eapol packet to t he .global authenticat or
queue
Sep S 09 : 21 : 38 . 821 : EP.POL pak d UIII.p r x
sep S 09 : 2 ·~ : 38 . 82 1 : EF~ ?OL version : Ox:l type : OxO le:\9th : Ox006B
Sep S 09 : 21 : 38 . 821 : doth .. ev : dotlx_auth_queue_event. : lnt Gi0/ 1 CODE• :?, TYPE- 25, t.E ~I -
107
Sep S 09 : 21 : 38 . 821 : dotlx• ev(Gi0/1) : Received p kt saddr - a036 . 9!1a . 3bbl , dadd ~
Oi 80 . c200 . 0003, pae· ether• type ~ 88Se . Ol00 . 006b
Sep S 09 : 21 : 38 . 821 : dotlx• ev(Gi0/ 1) : dotlx sendRespToServer: Response sent ~o t he
server ! roe'! Ox.2C0000DB (a036 . 9tla . 3bbl) -
Sep S 09 : 21 : 38 . 837 : dotlx• ev(Gi0/ 1) : sendin9 E.~ POL packet to a036 . 9tl a . 3bbl
sep S 09 : 2·'1 : 38 . 837 : dotlx .. ev(Gi0/ 1) : Role det erm.inatio:'l not required
Sep S 09 : 21 : 38 . 837 : dotlx• ev(Gi0/ 1) : sendi.n9 out EAPOL packet
sep S 09 : 2·'1 : 38 . 8-16 : dotlx .. ev(Gi0/ 1) : Role det erm.inatio:'l not required
Sep S 09 : 21 : 38 . 8·1 6 : dotlx .. ev : Enqueued the ea-pol packet to t he .global a uthent:ic.ator
q•.!e ue
sep S 09 : 21 : 38 . 8·1 6 : Y..POL -p ak dump r x:
Sep S 09 : 2·'1 : 38 . 8-16 : EA?OL Version : Ox 1 type : OxO length : Ox002B
Sep S 09 : 21 : 38 . 8·i 6 : dotlx.. ev : dotlx_au th_queue_event : I nt Gi0/1 CODE- ~ . TY?E.. 25, LEN•
H
Sep S 09 : 21 : 38 . 854 : dotlx.. ev (Gi0/1) : Received p kt saddr • a036 . 9fla . 3bbl , dadd't' -
0180 . c200 . 0003, pae• ether-type - 888e . OlC0 . 002h

Sep 5 09 : 2.<1 : 38 . 85 ,~ : dotlx - ev(Gi0/1) : dotlx: sen::!RespToServer : Resp.onse sent to the
server tr~~ Ox2C0000DB (a036.9fl a . 3bbl) -
Sep 5 09 : 2.<1 : 38 . 8 5 ,~ : dotl:x- ev(Gi0/1) : Sending El'.?OL packet to a036 . 9fla: . 3bbl
Sep S 0~ : 2-'l : 38 . 851 : dotlx - ev (Gi0/l) : Role det.er.':'li nation not requ1~ed
Sep 5 09 : 24 : 38 . 851 : dotlx• ev(Gi 0/1) : Sending out EAPOL packet
Sep S 09 : 24 : 38 . 863 : dotlx- ev(-Gl0/1) : Role det.em1nation not requi red
sep 5 09 : 24 : 38 . 863 : dotlx• ev : Enqueued the eapol packet to the globa l authenticator
.queue
Sep 5 09 : 24 : 38 . 863 : E:\POL pak du~:p rx
Sep S 09 : 24 : 38 . 863 : E.~OL Version : Oxi type : OxO length : OxOC2B
Sep 5 09 : 24 : 38 . 863 : dotl x• ev : dotlx_auth_queue_event : tnt Gi0/1 CODE• 2, TYPE-
2S, LEN- •1.3
Sep 5 0~ : 24 : 38 . 863 : dotlx - ev(G10/l) : Received p~t. saddr -a036 . 9fla . 3bbl , dactdr -
0180 . c200 . 0003, p.ae ... ethertype .. 888e . 0100 . 002b
Sep S 0 9 : 24 : 38 . 863 : dotlx - ev(G10/l) : dotlx_sendRespToServer : Response sent to the
server !r~~ Ox2C0000DB (a036 . 9!la . 3bbl)
sep S 09 : 24 : 38 . 896 : \ OOTix ... s .. success : .~uthentieaticn success!ul for client
(a036 . ~fla . 3bbll on Interr ace Gi0/1 Aud.itSessioniD 0AOA020200000CAS0520DOIC
s wicchl shov authentic&tion sessions interf&oe gigabit 0/1
lntertace : GiqabitE~hernet0/1
w,c f.~~ress: aOS6.9na . 3bbl
I? P.ddress : l O.to- . 9 . 16
user- Nat:e : student
St:at.us : Auth2 Success
Doet'la 1n : DATJ..
security ?olicy : Should Secure
sec ~ rity scat~s : Unsecure
oper host !!!':ode : multi- auth
cper control dir : both
.1\uthorized By: Authentication server
Vlan. ?ol1cy : N/A
Jo.CS ACt : xACSJ..CLx- 1 ? - EmpLoyee t~CL• S l959f !a
session t ! eeout : N/A -
Idle ti!'!'.eout : N/!'.
co~~o~ session ID: 0A0A02C2000000B005~FOESE
Acct session ID: OxOOOOCOED
H.andle : Ox .3.tlOOCOBl
Runnable methods H st :
Method St:ate
dotlx Aut:hc Success
6·1& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems.lnc.

Troubleshoot RADIUS Peering
This topic describes how to troubleshoot RADIUS peering.
Troubleshoot RADIUS Peering

. If ltlere is an lnootred key or IP/UO? problem. RADIUS session times out:
s~ltcht ~ ~adiu• bri • t

RA~!US/~~000£(00~00 t 09) : C~19 . ccnpoe•~~ typ4 • DotlX
Rt\!>.t uS IO ~C~0109) : <.:onfi9 1:.'>$ l ? : o.o.o~o
AA!>iYS 100t>C0109o): <.:onti9 W.S l?v-6: ..
AAC: OS/£.~000£: 1!4't. t.o~l !i'·Add.tf!U lG. :O.:.i . 2 !or R:ldi i.IS·SO.rYfllr 10. 10. 2 . 20
AA~!OS IC-l000109) ; SClnd 1.nq A IPV' R&d1U~ ?~C~At
AA!>HI~ 104000109): Send Jt(;Qt'$5-R.eque$t eo 10.10.2.20: li12 i d l64S/l31).1o:n 23l
AA!>iOO IO OM0109o): SUI.t"ted S 5ee tirr.eQt.J::.
AA!>i:IJS IO COC0109o) : ~~n f.ur-a. ou~ ::l
!U.D!OS: ~At't~l'l*'l'l1t to no. 10. 2 . zo, 1s12, 1S13) tor i d lS45/130
..
10:)3; H ,9SO; \RAV1~S-i-RAD1VS ~AP: M!ffil"
Sey
'
~.-:'r.>O ,
\IXY."l.X-!i-!'A! t.: A'.l!llon t 1~•~
•ton-..1!1!011
!.t~lfld tor cltfln~
~
•
''r"AA-
1~03E.9t:~.~blt «1 llltO'!!'.tC*
Ct0(1 AlldltSOs,tonlO OAnA02020GOOQ0830SS~!i6S8
\AV~~~R-,·RtSV~7 : Aut~~ntie4t~OQ fetuLt
·~
·~o:rv~r ~ew• ' ®tlx ' !o::
elier.t <o()36, 9f 1~. 3WJJ or. ~ nt~:!oe~ GL0/1 Aud~l~3~ioniD
OMAC.202UeOOCOSlOS!!S'56SB
.,
\Allt'f!HC..~-s-F'At:.: mthortut.ton t .:a ttlld or '-'n~,?PHAd !or cUAc('l!. l~C36 . Hl.:a.
_
)~.l.) tntnfoe~ GiOJl Audi l se~o ionl o OAOM~I>2000C00&30SS!'SW8
. ...... .
You can troubleshoot RADfUS peering problems on the switch or on the Cisco Identity Services Engi:ne.
The output of the debug radius brief command. shown in the figure, indicates that the RADIUS server is
not responding to the switch. There are several possible reasons fo r this. The switch configuration must
p roperly define the RADIUS server and the RADIUS server must be configured to recognize the switeh. If
either side specifies the wrong lP address or wrong RADIUS key, they will not peer properly. There can
also be problems with network connectivity between the two devices, including the possibility of a firewall
blocking the required UDP ports. The output of the debug radius authentication command, shown in the
following output, includes the attributes that are sent to the RADIUS host:

s ~ 1tch ' debug radius authentication
Sep 5 10 : 41 : 42 . •r i 9 : RADIUS/ Et>'OODE(0000010B) :Oriq . compo nent type - DotlX
Sep 5 10 : 41 : 42 . 119 : RADIUS(00000 10B) : Con!ig Nl-.S 1 ? : 0 . 0 . 0 . 0
Sep 5 10 : 41 : 42 . '719 : R.l\DIUS(00000 10B) : Con fig NP.S l?v6 : ::
sep 5 10 : 41 : 42 . 1 8 / : R.~IUS/ ENOODE( 00000 1 0B) : ace ~ session id : 242
sep S 10 : 41 : 42 . 787 : R.~IUS( 00000 10B) : sending - -
sep S 10 : 41 : 42 . '18.1: R.~IUS/ ENOODE : nest Local 1?- Address 10 . 10 . 2 . 2 tor Radius .. server
10 . UL2 . 20
Sep S 10 : 41 : 42 ..'187 : R.~IUS( 00000 i.0 B) : Setlding a l ?v'i Radiu s ?acket:
sep 5 10 : 41 : 42 . / 8.1 : R.~IUS(00000i.O B) : se~d 1-.cc ess- Request to 10 . 10 . 2 . 20 : 1812 i d
16-t5/132,1en. 233
Sep S 10 : 41 : 42 . / 8.1 : R.~IUS : au t henticato~ 6 3 01 20 SF 59 7 3 E6 A9 ... 37 BE BC 6E F9
o·; 9E 8 5
sep S 10 : 41 : 42 . / 8.1: R.~IUS : user- Name Ill
sep 5 10 : 41 : 412 . '18.1 : R.~IUS : se-rvi ce-
i'~e 16) 6 Framed 121
sep s 10 : 411 : 42 . 781 : R.~1US : vendor, Cisco 1261 2 1
sep s 10 : 41 : 42 . 78.1 : R.~IUS : C i sco AVpair Ill 21 "se rvi ce- t ype ... Fra...'!'led"
sep s 10 : 411 : 42 . 781 : R.~IUS : :ra ~~d - IP ~Address 18 I 6 10 . 1 0 . 9 . 16
sep s 10 : 41 : 42 . 78.1 : R.~IUS : :ra ~ed ·MTU 0 21 6 1 500
sep s 10 : 41 : 42 . ~~ a ·t : R.~IUS : Ca lled- Station - Yd 1301 "l'.C- F2- CS- 5B.. FC· Ol "
sep s 10 : 41 : 42 . 78.1 : R.~IUS : Ca llinq• Station• 1d t 3l l " AC - 36 - 9F- l.~.. 3B- Bl "
sep s 10 : 41 : 42 . ~, 8 ., : R.~IUS : EA?· Xessaqe !'19 I 1<
sep s 10 : 41 : 42 . 787 : R.~IUS: 02 01 00 oc 0 1 7 3 l ·'i iS 64 65 6E
71 I s t udent.!
sep s 10 : 41 : 42 . 781 : R.~IUS: Message• Authen tic a t o i 80 1 18
S.ep s 10 : 41 : 42 . 78 / : R.~IUS: 7E 03 F8 51! 17 02 9£ 66 36 6F 0 3 1'.1 09 66 51
co I .. " t 6ofOI
S.ep 5 10 : 41 : 42 . 78'/ : R.~IUS: EA?- Key- }iame U02i 2 *
Sep 5 10 : 41 : 42 . 787 : R.~IUS: vendor, Cisco 1261 <9
Sep 5 10 : 41 : 42 . '18 .1: R.~IUS : c !sco AV'pair HI •1.3 "audit - sessiotl-
i d ...OAOA0202000000B5056iSF78 "
Sep 5 10 : 41 : 42 . 78.1: R.l\DIUS : W..S• ?ort- Type
i 611 6 Ethernet [ 15 1
Sep 5 10 : 41 : 42 . 78 / : R.l\DIUS : W..S• ?ort 151 6 5000 1
Sep 5 10 : 41 : 412 . '18.1: R.~IUS : t>AS • ?o rt• Id 187 1 2 0 "Giga.bit:Ether:'!et0/ 1"
Sep 5 10 : 41 : 42 . 787 : R.l\DIUS : N.AS• !P ...;dd.ress {'tl 6 10.10 . 2 . 2
sep 5 10 : 41 : 412 . '18.1: R.~IUS(000 0 0 10 B) : Started S se-c timeou t
sep S 10 : 41 : 4'1 . 820 : R.l\DIUS (00000 10B) : Reque st titeed out !
Sep 5 10 : 41 :4'1.820 : \ RAD1US• 4 • RAOIUS DEAD: R!~CllUS server: 10 . 10 . 2 . 20 :1812, 1813 1S n o~
r·espondi :-~g .
sep S 10 : 42 : 20 . 9!;6 : \ DOT1X.. :,• FAIL : .~uthe:-~tica t icn ra iled t or client ( a 0 36 . ~tla . 3bb l )
o n I~ter tace Gi0/1 AuditSession! D 0A0A0202000000BS05675F18
Sep 5 10 : 42 : 20 . 9t;6 : %AUTll.MGR- ·I- REStJLT : Au thent icat:ion result ' server dead ' ! ro:n
•dotlx ' t or c lient Ja 036.9f la . 3bbl) on I n terf a c e Gi0/1 AuditSessicn ! D
O AOA~ 202000000BS O S 6 75 F7S
Sep 5 10 : 42 : 20 . 916 : \ AUTll.MGR- 5- FA! L: Authori2a t1cn failed or unapplied t or cl i ent.
(a 0 3~ . 9 f la.3bbl) e n Interl a c e G10/ l Aud1tSession! D 0AOA0202000000BSOS67SF18
6-20 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems.lnc.

Troubleshoot RADIUS Peering (Cont.)
ISE reports Invalid RADIUS message au!tlenblcetcf
.
---
·--- -· ----·
•
- --
- •- - -·
•
,-
---· • •
·~
·-·---··- ·- --= ·- - - -- - -
""!U_~___;. - ~ ""~
-
-
---··
~
--..---·
_.......... . ~ ---
_..1»_-.l' .
•
• -
---
...-----,
~
••••
-·~-""' .
--
--
-- --······- ....______
-
...........,.tl,
---- ----
_____
_______
-·-
-...-·-___ t!t!IIOI
--··-----
---~----·----·
..------·---·
,..
.... --
On the RADIUS server side, you may or may not see any authentication attempt.1:i. In this example, Cisco
(SE acts as the RADIUS server. !SE has the NAD defined in its configuration, but the shared key is
incorrect. The Cisco IS£ is receiving authentication attempts from a valid NAD and you can see the
authentication failures in the live authentications displayed in the Operations> Authentications- page. If
the NAO wa1:i not defined on the ISE, or U, oonnectivity failed. you would not see any failures on this page.
for each authentication event, you can click the Details icon to generate a details report. From this you can
examine additional detailed information. When the event is a failure, it provide a failure reason as well as
resolution guidance.

Troubleshoot Peering with User Database
'J'bis topic describes bow to troubleshoot peering with the back·end wer database.
Troubleshoot Peering with User Database

• Sroken oonnectlon >Mm an external Identity source
··- -
·- -·· -·
- ·-----·
- 'j
~----
··- -~
• -- -- -
• 1.U
•
o---·-·-·
. ----
•-
-. --·
"'- --·-- - ---· : .
--·· ·
- ··.
~
I
-·--·
....Q.MM .
L ·-- -·-
•
-- -
-
-· ---·-
• -
- ··~~~·
~
-·~
--- ---·
-- -----
--------
--- -- - ---
· -~
Authentication failures can result from peering problems ibetween the Cisco Identity Sen~ces Engine and
the back-end user database. When you see failed authentication attempts in the Cisco ISS authentication
page. you can click the Details icon and investigate the reason. 1n this case, you see that the Active
Directory operation has failed because of an unspecified error in the Cisco lSE. You should check the status
of tlle Active Directol)' integration.
Troubleshoot Peering with Database (Cont.)

Two tests for truegratlon Yt\'lh Acltve Olrec:tJOty
--- - ·---
-· - ---
·--
~:-
.. ·--
-- ----- - ...
·---
--
~·
_, --
______ - -
...::=::\::-
·-
·-- ----
·-·-.._-::--- --- - - --·-L..... . __. •
..
·--~-·-·---
---
-----__
-.,____
_____ ---
______
_____
------- _ _ ... ...
-·
-·
You can check the status of the Active Directory integration by choosing Administration> ldentity
Manage-ment > E-xtemallde.ntity Sources-> Acti'Ve Di rectory. In this case it is immediately apparent that
the status is incorrect. Instead of "Connected,'" Cisc-o Identity Services Engine repons ..Joined to Domain
but Disconnected." From here you can test the connection to Active Directory. JSE offers two test mel!bods:
Basic and Detailed. Running the detailed te.(!t ·will provide the most infonnation. In this case, the connection
failure is caused by a time skew between lSE and Active Directory. ln an Active Directory integration, the
time skew must not be larger than a few minute.(!. You should make sure that NTP is used and is operational
to avoid time synchronization issues.

Troubleshoot Identity Source Sequencing
'J'bis topic describes bow to troubleshoot identity source sequencing.
Troubleshoot Identity Source Sequencing
- --- -- ~o.--
·---·-- ""---
·- ..--
_
-- ....-=-.--..·-·---.::;
_. ... ..
--
~-
ldefayMUtt!thlmt)'tlellliCIOn"ICI 1
_-..____
.......
0.•---·-----
____ .. . .
__________- · - J --··~
,, ._ __
__,.
-- . .,. )
·~-====----'
Cisco ndentity Services Engine uses identity source seque:nces to allow multiple authentication sources to be
queried in sequential order. lt is possible for there to be configuration eiTOrs a~sociated with a single source,
such as an incorrect certificate authentication profile. There can also be issues with the sequence such as
improper identity source order, or an undesired failover setting defining what to do in case a given source in
the Se<tuence is unavailable.
6-2<~~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Troubleshoot Client-Side Certificate Issues
This topic describes how to troubleshoot cl ient~side certificate issues.
Troubleshoot Client-Side Certificate Issues

ISE system time outside the validity range of the client certificate
CA root certificate on Cisco ISE is not enab led f()( EAP authentications
Client certificate and signature no t verifiable with CA root certificate
Client certificate has been revoked
--- •
·· -- · · - ·
·---- ·---- --· .. •
.....
---·
•
l-1:._ _ ____ ...

............ ...__
--- " '
....... _.
Authentication failures can be caused by problems related to client~side certificate authentication. A client
certificate is used in .§t'-l'·Th§ authentication and other types of authentication. Potential issues include the
following:
.. ·The current system time on the Cisco Identity Services Engine may be outside the valid icy range of the
client certificate.
·ne CA root certificate in the Cisoo lSE cenifi cate store may not be enabled for EAP autbenticartons.
.. ·The client certificate and signature may not be verifiable using theCA root certificates.
The client certificate may have been revoked.
l.n this example, you see a failed authentication attempt. 1·be EAJ, TLS handshake failed because of an
4
unknown CA in the client certificates chain. You can view more detailed information if you click the
IDetaib icon.

Troubleshoot Disallowed Authentication Protocol
'J'bis topic describes bow to troubleshoot disallowed authentication protocol issues.
Troubleshoot Disallowed Authentication

Protocol
ISE authentication policy defines allowed protocols
If no match is found, authentication will fall
Failure reason: 12503 failed to negotiate EAP because EAP type not
enabled in Allowed Protocols
·--
---
•
-----
- - - ===::-:::-:.=":'·::-:=-·:...:=:.;·:____
• - ..·-
-- --- w•
o ........._ _... . . ...
--..-""''" . . -
-~~ IJP~•"'
-··"~·- . _.
•
-
- ------
' ___
..... -·-·--- -· __ __
·~ ·~
--- -·---.. ·----

•
- ....- ---·- ..,
.
·..-~:-:::-:-:~:::::::::::::::::!
..........
-·"-"'
......
-•aa&•" . ' . . -----
.,....
"
~... .
--------
---- --
•
_..,
- ·-·-
- - - .... ·-· ::::._~==-----==-
- =-=-..::-~...:....-=::. -
....
lE.EE 802.lx authentication will fail if the client authentication protocol is not allowed by the Cisco Identity
Services Engine. The IS£ defines the allowed authentication protocols in each authentication ruJe. The
authentication will fail in case of a mismatch. Authentication policy rules are defined under Policy >
Authe.nticatioo.
6-26 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems,lnc.

Troubleshoot Machine Authentication
This topic describes the troubleshooting of machine authentication.
Troubleshoot Machine A uthentication

Potential issues similar to user authentication problems
Active OirectOfY integration can disallow machine authentication
Failure reason: 24416 Machine authentication against Active Directory
__•-- -· ..... - ·
faUed since it is disabled in configuration
----·---
·----· •
..._ .
"~
... __ •
a----·----·•-.-.. .= E:;::::::J~~~-~;;========,.;::;;j
----...
. . . . . . ... :==
__-·---. - .._
-
- -·-------- -
"""'·-----~---··-·..,..._
tao•------··-·- ,..._
-·-. . --- ....__ ----- -
··-···-- . lo - --
-
~----. ..... ....-
...... _.
Machine authentication problems are similar to use:r authentication issues and can have various causes. A
special case for failing machine authentication can be related to an integration setting with external identity
databases. You can disallow external machine authentication. In the example that is shown in the figure, the
Cisco Identity Services Engine has been configured to block machine authentication attempts against the
Active Directory.

Web Authentication Troubleshooting Overview
'J'bis topic describes the troubleshooting of central~~·
Web Authentication Troubleshooting Overview

Potential WebAuth problems may be related to the following:
1. AAA settings on the network access device
2. RADIUS peering
3. Incorrect logic in the Cisco ISE authentication policy
4. Misma tched ACL name for traffic redirection
5. Incorrect logic o f the local redirect ACL
6. Incorrect authorization settings
7. Incorrect logic of the Cisco ISE authorization policy
B. Peering with user database
Central WebAuth depends on the MAB functionality. It will fail with incorrect AAA settings on the NAD
or broken RADIUS peering. It reHes on the authentication policy to continue if the MAB rule fails. A
pmenti.a l problem of the Central WebAutb is that the redirect ACL is configured on the NAD, and it is
referenced by the authorization profile on the Cisco Identity Services Engine. A potential name mismatch,
an erro-r in the redirect ACL, or a mi.c;oonfiguration of the authorization profile will cause the WebAut:h
redirection to fail. Other problems can be related to the 10\g:ic of the Cisco lSE authorization policy, where
the autllorization rules for unauthenticated and authentica·ted users and guests must be defined in the correct
order. Central WebAuth can be used for employee access and therefore depends on the peering with the
back-end user database.
6-2& lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems. lnc.
Review ISE Authentication Policy for WebAuth
This topic describes the Cisco Identity Services Engine authentication policy settings that are required for
WebAuth.
Review ISE Authentication Policy for WebAuth

WebAuth uses by defauft the MAB authentication rule
ISE must continue when user no~ found
----· ,_--- . - ".... ··-· - .......

....... --- \. . . . -,. _- -
_...___ .._______. _____ ....... ......... _. __
a.--
-- -·-
0
---
• ---
- _ _ .._,.,....., J
·--
·-. . .
Central WebAuth requires that the MAS authentication rule on Cisco ISE is configured for faH·open
operation if the endpoint MAC address is not found in the endpoint database. This approach effectively
allows the authorization policy to take over the decis ion ~ making process for this endpoint. The Cisco ISE
authorization must have several rules.

Review ISE Authorization Pol icy for WebAuth
'J'b.is topic describes the Cisco Identity Services Engine authentication policy settings that are required for
WebAuth.
Review ISE Authorization Policy for W ebAuth
-..- _________
.......
-- -l<oo---· ...----
Iii.- t; ....
- · ___#---
___-~ ·
-~--
------~:~::~~~·~~;~~~~~-----
~ ~~~~~ ~·~·-=~~~~·~'·n·.;:·~~~-~~~~·Md:-JI
.----~
-
.. -- -
-- - =*- . --·
.... -
..--. -
--
--
~
..-
.. ---- ___ __ ---
.=..
~K!flowUMaW:
...,
~-
-
-
Tbis figure illustrates a basic authorization policy that is required for Central WebAuth and guest access. It
does not show the authorization rules at the top of the authorization policy. The rules at the top are used to
define permissions for the various users and endpoints that access via 802.1X and are profiled. The two
rules required for <he WebAuth operation are Employee WebAu<h, shown at d>e top, and WebAuth, the
second last.
Tbe Employee WebAuth rule defmes the authorization profile used for me employees who authenticate
using WebAuth. The condition for the rule is the appropriate group membership and Network Access: Use
Case equals Host Lookup. The Network Access Use Case Host Lookup is the me<hod used for MAB.
The second to last rule, WebAuth, matches the network ac.cess use case (Host Lookup) and pushes the
au<horization profile (WEBAUTH) to redirect traffic for WebAu<h. This rule is only effective if <he MAB
authentication rule is configured to continue if the user is not foWl<!.
Review Authorization Profile for WebAuth
This topic describes the Cisco Identity Services Engine authorization profile that is used for traffic
redirection.
Review Authorization Profile for WebAuth
--- .-
---
~... -
-.....
,._- - -
- ----
--
- -.., _. _
-· .j;_
..:;;:;;;;;
_ _·_ :::"':<:''=---->!
• -
··- -
·•-•
::::
··-
··---
-- ·-- &=•• ..
• Recirect ACL name must maleh ACL on w-.0 {permits lr8fflc to be redlree1ed):
,_ _ ..._oo-.- -.-
., ---
~"""- ..... [S_~ - Oliol' •
Central WebAuth requires an authorization profile on Cisco lSE that is used to redirect HTI'P and H·rrPS
traffic to WebAuth. An example of this profile is shown in the figure. The profile references an ACL cllat
must be configured on the NAD. The ACL defines the ITllffic that will be redirected to the central WebAuth
portal. Jfthe NAD is a Cisco switch, the local ACL must pennit H-rn> and HrrPS traffic, which will be
redirected to WebAuth.
Potential pitfalls include a mismatch in the ACL name, and incorrect permit and deny definitions in the
local ACL.

Troubleshoot Mismatch of ACL Name
'J'bis topic describes bow to troubleshoot a mismatch oftbe ACL name.
Troubleshoot Mismatch of A CL Name
...,..., .,.,...
lt)~• . . . . .
....1111
r-...
~~- 11..... 11
~u•
Ill I ""'I 1...e.l-o • I

loAtWU Ch•• &..,..if
•·l<>••ll•4UI~,.,If-•hl,..•-r
kU-l•! C:lf- •¥1•10
.,...,., 1,1.1, fto\1'11
. . . .lft<"
II
Ill II
-••1
•,.ol -JH<\•'If* , _
14 N. "·'I'N_I_"_ ...,.,
I t ""'-t h• .......o• !lllof ..... .._ I -·
,....,
011111
...
Nl'f...M I ~~ bUo ...., _ h • t l •
"'~'
WJ... ll '1-ll.i """"" •II .......
•-II ·- "'"' If- · - · ,,.
! ......, , . . I 1 J
- to< M Mu 11M- I •
loJ Ill! ..... <001\loooflutoo.U• - ·- 1111...-f- . . . . . ~ Wt

llll• , . . . .
~\~>(...... . ........ ....
• ............., _ '
;• ..~~" :!:~-::
"»4••
....... _...·····~
..... -
I I otl
"
....
1 , ., • •
-
......... ~-~,tQ.- . . . . . I.
-j.Oh
...., ll••~
htl . .
.. lloo\lo ••
~ . . ....... ~~~ - ·,•t·"

(o·~ " . .
·-~
•• 1-1 at ..
I t•t•n I 1 ·•t ..,., .. -
, _., ,, t f ..,, ..,, ... IU
··--
A potential pitfall with central WebAuth is a mismatch between the name of the redirect ACL on the
network access device and in the authorization profile on Cisco Identity Service.~ Engine. You can
(J'OUbleshoot such a problem by debugging the RADIUS authentication on the network access device and
verifying the authentication results on the port. The following output displays the full output of the debug
radius authenticAtion command in a scenario where the names have inconsistent lower· and uppercase
leners.
HQ- SWt de.bUq radiua au~e.ntication
Sep 9 13 : 35 : ·'l.O. 969 : \DOT1X• S· F'Ail : Authentication !ailed for client (a036 . 9!la . 3t:!l2)
on Interface Gi~/2 AuditSessioniD 0A0A020200000i7DtA9F3DO S
sep 9 13 : 35 : ·~ 0 . 969 : '\JI.UTf~GR .. 7-RESULT : F>.uthentication result. • no .. respo:"lse ' rro=:'l
' dotlx ' for client (a036 . 9tla . 3h~2) on Intertace GiO/Z AuditSessioniD
0A0A02020000011 DlA9F3DOS
sep 9 13 : 35 : 10 . 969 : '\JI.UTf~R · 7 • FAILOVER : Failing over rro-:n •aot tx ' !or client.
ta0~ 6 . 9f1a . 3bb2) on I nterfac e Gi0/2 !\ udi t:SessioniD 0AOA0202000001 7DlA9F300S
sep 9 13 : 35 : 10 . 969 : \P.UTf!MGR- 5- sv..~T : St:art:1nq ' !II.Cb ' !or client {a036 . 9!la . 3bb2) on
Intertace Gi0/2 AuditSession iD M.O.o\0£020COOOl.iDtA9F'3D05
Sep 9 13 : 35 : 10 . 969 : Rl~01US/ENCODE100000108) : Or1<; . component t:ype .. DotlX
Sep 9 13 : 35 :!;0 . 969 : Rlo.OIUS(000001DS) : Contiq !i.~S IP : 0 . 0 . 0 . 0
Sep 9 13 : 35 : 10 . 969 : Rl~DlUS (00000108) : Con!iq HAS !Pv6 : : :
sep 9 13 : 35 :!;0 . 969 : Rlo.DlUS/EUCODEt00000ID9) : acct session id: 10
sep 9 13 : 35 : 10 . 969 : Rl~D1US(00000108) : send1n<; - -
sep 9 13 : 35 :·~ 0 . 96-9 : Rl-.JltiS/E,UCOCE: Best Local IP ·.~ddress 10 . 10 . 2 . 2 !or Radi\: s - se::ver
10 . 10 . 2 . 20
Sep 9 13 : 35 : ·~ 0 . 96-9 : Rlo.OlUS (00000108) : Sendin<; a !Pv11 Radius ?acket
sep 9 13 : 35 : ·'l.0 . 969 : AAD1US(000001DS) : send Access- Request to 10 . 10 . 2 . 20 : 1912 i d
l6•1S/94,len 2 ·~6
sep 9 13 : 35 : !;0 . 917 : RI'.D1US : user- Name

sep 9 13 : 35 : !;0 . 91'7 : AAOlUS : user- Password
Sep 9 13 : 35 : ·'l.0 . 917 : Rlo.OlUS : service-Type
Ill
(21
( 61
19
6
..
sep 9 13 : 35 : !;0 . 969 : RI'.D1US : authenticat:or 56 B6 96 S•l '10 sa ·;o 16 - 58 19 FA 52 2B
sc ao 3r
"'a0369fla3bb2 "
Cal! Check
(10]
sep 9 13 : 35 : ·'l.O. 977 : Rlo.OlUS : vendor, Cisco (261 31
sep 9 13 : 35 : !;0 . 97'7 : AAOlUS : Cisco AVpair I ll n Mservice- type-call Check"
sep 9 13 : 35 : !;0 . 917 : Rlo.OlUS : ~ramed • lP · Addre ss (81 6 10 . 10 . 9 . 19
sep 9 13 : 35 : 40 . 97'7 : AAOlUS : F"ra!'Ced ...MTU [12J 6 1500
sep 9 13 : 35 : !;0 . 977 : Rlo.OlUS : Called- Stacion · I d (30 1 19 ~ AC• F2 •C5 · 5B • FC• 02-
sep 9 13 : 35 :10 . 977 : Rl'.OlUS : Calling- sta tion• I d [ 311 19 MA0• 36- 9F- l A- 3B• S2M
sep 9 13 : 3S : ·'l.0 . 971 : W..OlUS : Hessage ..Au t:he.n ~! cator 180 I 18
sep 9 13 : 35 :10 . 971 : Y..OlUS : 6< 27 Dl A3 DO CC lB 62 36 ;..3 DE 70 D6 2F JI S
0 11 f d'b; p/ E)
Sep 9 13 : 35 :10 . 977 : RP.OlUS : EAP• Key- Na.'r'le [1021 2
Sep 9 13 : 3S : ·'l.0 . 971 : W..OlUS : vendor, Cisco (261 49
Sep 9 13 : 35 :10 . 971 : Y..OlUS : Cisco AVpair (1I 43
id•OA0A0 202 00000 1 1 D1A9FB~0Sw
Sep 9 13 : 35 : ·'l.O. 971 : Rl'.OlUS : NAS- Port..Type
[ 611 6 Et:hetnet 1151
Sep 9 13 : 35 : 10 . 917 : ru'~OlUS : NAS• Port (5) 6 50002
Sep 9 13 : 35 :!;0 . 971 : Rlo.OIUS : N.~S · Port .. ld [87 1 20 •Gi qaMt!:thernet0/2'"
Sep 9 13 : 35 : 10 . 971 : Rl~DlUS : NAS- IP• Address ( 41 6 10 . 10 . 2 . 2
sep 9 13 : 35 :!;0 . 971 : RF-.DlUS(0000010S) : S t:arted S sec timeout
Sep 9 13 : 35 : (;1.019 : Rl~DlUS : Received ! ro:n i d 1645/94 10 . 10 . 2 . 20 : 1812,
len 391
Sep 9 13 : 35 : (;1.019 : Rl~DlUS : authe~ttcat:or AS 1A OC 60 09 OF 08 63 - 24 38 02 F9 06
DO 2F 1/o.
Sep 9 13 : 35 : ·H . \H9 : AADlUS : user- Name 19 •A0 .. 36- 9F- 1A• 3B• B2-
Ill
Sep 9 13 : 35 : !;1. 019 : Rlo.JlUS : State (2•11
40
Sep 9 13 : 35 : ·H . 019 : RI'.DlUS : S2 6S 61 7S 1·• 68 53 65 13 73 69 6F' 6:: 3A 30
fo l JReaut hSession : OAJ
Sep 9 13 : 35 : ·H . (H9 : Y..DlUS : 30 11 30 32 30 32 30 30 30 30 30 31 37 •1•1 31
fo l (0A02020000011 D1Al
Sep 9 13 : 35 : ·H . (H9 : Y..DlUS :
Sep 9 13 : 3S : •H.Ol9 : AAOltiS :
39 16 •12
class
••
30 3S
!2 SJ 49
t 9FBD05 J
Sep 9 13 : 35 : 11.0 28 : Rlo.OlUS : 43 -11 43 53 3;, 30 H 30 •11 30 32 30 32 30 30 30 fCAC-5 :

O.:..OA0202000 i
Sep 9 13 : 35 : 11.0 28 : Rlo.OlUS : 30 30 31 :3.1 ·H 31 oil 39 <1 6 42 11 30 35 31'. 69
73 (00l1~1A9FDDOS : isl

Sep 9 13 : 35 : 41 . 028 : R~IUS : 65 2F 31 36 3? 3·~ 38 32 32 .3? 38 2F 36 31 SO I e/
161782278 / 610)
Sep 9 13 : 35 : 41.028 : R~IUS : Te -r~i natio:'l -.'\ction 1291 6 1
Sep 9 13 : 3 5 : 41 . 028 : R~IUS : Message• Authe:'lticacot 80J 18
Sep 9 l.l : 3S. : 41.028 : RADIUS : 13 FB SS 86 ?5 1'.8 3C 13 B3 E? ? 3 23 02 5.~ EC
6C I UU<sHll
Sep 9 l.l : 3S : 41.028 : R~IUS : vendor, Cisco 126( 46
Sep 9 l.S : 35 : 41.028 : R~IUS : cisco :Wpai r Il l •10 "ur1 redi _r ec t•a.c lllltACL-
w
WebA~ th -Red.irect..
Sep 9 13 : 35 : 41.028 : R~IUS : vendor, Cisco 126( ll8

Sep 9 13 : 35. : 41.028 : R~IUS : Ci sco AV'pai-r I ll ll2 "url - re<11recc...~ttps : / /
1se . secure .. x . loca l : 844 3/guestpona l/gateway?
sessionld •OAOA0202000 00 1 7 DlA9!BDO S &acc.io:'I •Cwa~
sep 9 13 : .35 : 41 . 028 :
R~IUS : vender, Cisco 126( 7S
Sep 9 13 : .35 : 41.028 : R~IUS : Ci sco AVpair U l 69 ",..cs :C i scosecu re• Oe l i ned-
ACL- !4.~SACLf - I?.. ?ERMIT .~ LL TR!o.!FIC .. ·1 e4d854b"
sep 9 13 : :35 : 41.028 : R~IU5(000001 DS) : Received !r~ id 164 5/94
sep 9 1-l : .35 : 41 . 028 : %HAB .. s .. suocESS : Aut~e:'ltica t 1on successfu l f or c l ient (a 0 36 . 9!1a .
3bb2) on Interlace Gi0/ 2- .~uditSess !oniD 0AOA02020000017DB9FB:IO S
Sep 9 13 : .35 : 41 . 028 : %.~UT!!.MGR .. 1•RESULT : Au thentica tion resu lt ' success' !rom ' :nab•
tor ~lieot (a036 .9tla . 3bb2) on i nterface Gi0/2 hua l tSessloot~ Ch0h020200000170lh9rBD05
Sep 9 1.3 : 3 5- : 41 . 053 : %AUT!~MGR ·S- FAIL : Authori2ati on tailed or unapplied tor client:
(a036 . 9fla . 3bb2) on Int erface Gi 0/2 Aud.itSessioniD 0AOA020200000li Dl A9fD005
sep 9 1.3 : 3 5- : 41 . 992 : %AUT!~MGR ·S- SUCCESS : Au t.horhat!on s ucceeded !or client
(a036 . 9fla.3bb2) on Int erf ace Gi 0/2 Aud.itSessioniD 0AOA020200000li Dl A9FD005
se:p 9 1.3 : 3S : Si . 127 : \ OOTlX·S•!AIL: Authe~tication !'ailed ! or client; !a036 . 9tla . 3bbl)
on I~t.ertace Gi0/1 AuditSessioniD OAOA0202000C012~0c8A999D
sep 9 1.3 : 3S. : Si . 127 : %AUT!~MGR ~1• REStJLT : J\u thentic.ati on resu lt •no• r-esponse ' ! ro:n
•aotlx ' t or clie n ~ fa036.9fla . 3bbl ) on I n te~tace Gi 0/ 1 AuditSession i D
0~0A02020000012A0C8A999D
Sep 9 13 : :35 : S'I . ,t2/ : ,.~UTHMGR -1- FAitOVER : Failin9 over from ' d:ot1x • tor client
(a036 . 9! la . 3bb1l on Int erf ace Gi 0/ 1 Aud.itSessioniD 0AOA02020000012AOC8A999D
Sep 9 13 : 3 5 : S'I .'t2'1: ' .'\UT!!MGR·1·NOY.OREMETliODS : Exhausted all authenticat.iO."'I methods
!or client (a036 . 9 t la . 3bb1) on In t erface Gi0/ 1 Aud1tSessioniD 0AOA020200000 12ACCSA999D
Sep 9 13 : :35 : S'I . ,t2/ : ,.~UTHMGR ·.5• FAit : Authorh:a tion fa1led or unapplied for client.
(a036 . 9! la . 3bb1l on Int erf ace G! 0/1 Aud.itSessioniD OAOA02020000012AOC8A999D
'The authentication results on the access interface are as follows:
no..sw~ show a.uthe.ntica.tion aesaiona inte r f ace gi ga.bi tEthernet 0/2

lntertace : Gi9abitEt hernet0/2
Ml'.C A~dress : a 0 36 . 9fla . 3bb2
I? Address : 10 .10 . 9 . 19
user.. Natne : A0·36• 9F-1A• 3B• B2
Stat us : Au t.h?: :a iled
Dc:Min : DATJI..
security ?olicy : S~ould Secu.re
security St atus : U~secure
oper host e.cde : multi- aut h
Oper control dir : both
Au thor1%ed By : Au thenti cat ion Server
Vlan ?olicy : N/t-.
session t ieeout : N/A
Idle ti!'!':eout : N/ t-.
co~~o~ session ID: 0A0A02C20000017DlA9FB00S
Acct sessi on ID: OxOOOOCl BF
Handle : OxcoOOOl·) E
Runnable methods list :
Metho6 State
dotlx Fai led over
mab Au~hc s uccess
$.3.4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems. lnc.
[fyou check tlle ACL names on the switch. you will find a mismatch:
liQ... swr a.how ip access ~Hats
Ex te:\ded l? access list JI..CL..WE.BAUTH• REDlREC7

lC pem1t: tcp a!'\y any eq v"""W
20 pem1t: tcp any any eq ·H3
\Vhen you correct the ACL name, you will find that the authorization profile is applied as expected:
HQ- SWf a.how autheatieation aeaaion inter~aoe gigabit 0/2

I nterrace : GiqabitEthecnet0/2
Y~C Address : a036 . 9tla . 3bb2
I? .~ddress : 10 . 10 . 9 . 19
user ..~iame : M · 36 ... 9F• l A- 3B ..a2
Status : Aut:h2 success
Do!nai:\ : OF-.!'A
Security Policy : Shou l d Secure
Securi t:y Status : unsecure
ope:t host mo<!e : !1\Ulti•.lUth
oper control dir : bot:h
F-.ut.hcrhed 3y : Auc h e n ticatio~ Server
Vl a.n Policy : N/ A
ACS ACL : xACSAClx• IP• PERMIT ALL TR~FFlC • 4e4d8 5 t;b
URL Redi rect .'\CL : l'.CL-WE B.~ UTH -R!:DlRECT
t~RL Redirect : htt ps : /lise . secure• x . locaL : 8•14 3/g·uest:portal/gateway'?
session 1ct...o;..o;.020200000 1 'I El: ;.cs 3B 8£ 'act ion...cwa
session timeout : N/A
Idl e ti!lteout : N/A
co~~on session I D: 0A0A02020000011 ElAC53B8E
Acct ses sion I D: OxOOOOOlCO
l!andle : Ox6800011 F
Run~able ~et:hods list :
Method State
doth: £'ailed over
~a.b Authc Succes s
The user is then redirected to WebAuth, and when authenticated successfully and all other settings are
correct, the port "ill be authorized with the user or guest profile.

Posture Troubleshooting Overview
'J'bis topic describes bow to troubleshoot the posture servi ce.
Posture Troubleshooting Overview

Potential posture problems may be related to the following:
Insufficient privileges to install or update persistent~ agents
Blocked SWISS communicatioo (UOP 8906 in a Layer 3 deployment)
Inaccessibility of the remediation servers
Possibly caused by dACLs
Example:
C lamWin Antivirus uses a djstribubed rom edialion cloud
Every DNS resolution roquGSt retu ms a dltferont !'$mediatiOn IP
address
Tbe posture service relies on persistent or nonpersistent NAC agents. Persistent NAC agents, which are
available for Windows and Mac computers, are typically used on managed devices. Persistent agents can be
instatled from the Web browser or using the MSI package. You must have administrator rights to install or
update a persistent agent.
'The SWISS protocol is a stateless request~response protocol that allows NAC agents that are running on
managed clients, to rerrieve configuration and operational infonnation from the Cisco Identity Services
Engine. The NAC agent connects to the Cisco ISE server by sending out SWISS unicast packets on UDP
port 8905 in a Layer2deployment and on UDI' port 8906 in a Layer 3 deployment.lfthe SWISS
communication is filtered, the posture service will not function properly.
Another potential pitfall is when clients cannot access the remediation servers. This may be caused by an
overly strict dACL defined for client provisioning on ISE. Some antisypware and antivirus programs, such
as ~1e ClamWin antiviNs, use a a distributed remediation cloud. The cloud consists of numerous hosts that
serve the software and definition updates. Every time the ClamWin agent resolves the hostname of the
remediation server, it gets a different lP address. This situation is very difficult to handle with static d.ACL..s
for non ~compllant endpoints.

Review Posture: Client Provisioning Policy
This topic describes the use of the client provisioning policy in the posture service.
Review Posture: Client Provisioning Policy

Matches identity groups, OS, and additional conditions
Applies results: agent, profile, module, customizatioo package
Consists of rules that can be reon::Jered. duplicated, and edited
--- --- . -a- -··. . ._..... !..""""''-

.
,
.. -
··-
·--'
. _==--------.. --·-.
··- -- --- ---
. -
:-...:--:::.::..-=:..~""..:.-..:r::..-:...=:.-
- ....
..---- - ..
....... _.
The Client l'rovisioning Policy is an essential component of the posture service. It defines the agent
software that is used to obtain the posture infonnati:on for the given endpoint type. In this example, a
persistent !'JA£.agent should be provisioned on Windows endpoints that authenticate using 1EEE802..1x,
and a web agent should be provisioned on WindoW'S endpoints that tLiie WebAuth.

Review Posture Policy
'J'bis topic describes the Cisco Identity Services Engine posture poJjcy.
Review Posture Policy

Describes compliant status
Matches condrtions and specifies requirements.
_____..
--·- _______
. ·-- -· --
-- -- -
~-
--- -· :v--..
A posture policy defines the technical requirements that define compliant status. f"or example, the posture
policy may define a compliant endpoint as a client machine with up-to~date antivirus software. A posture
policy consists of one or more rules, and each rule is iden·tified by a name and configured to match one or
more conditions.
'The poosture policy is differentiated from other policy types by the requirement.~ definition. The
requirements are written as an expression: "Requirement for OS met if posture condition, else remediation'"
11le posture condition c.an be specified as a single or compound condition. Several types of posture
attributes may be evaluated: file, registry, service, application, regular compound condition, antivirus, and
antispyware.
Tbe posture policy rules match conditions and specify the posture requirements.
Review Posture Requirements
This topic describes the Cisco Identity Services Engine posture requirements.
Review Posture Requirements

Referenced by posture policy
Match conditions and specify remediations
.- -- ----
·.... ----·
~- ... ~.-.-
-...... = --, __ - - -
I
.... -·-
··-
··- -· .........
-· --~
.
··-
··- -- -·
--~
-·
-.,~-..-
,.
--"
··---
. • .!:=..
-- -- ---
--
-~-_,...
-~~
.--"
---
-- -- -- --~
-~-
-~
---
--"
. . .. _.
The posture policy rules match conditions and specify the posture requirements. The posture requirements
specify the attributes of a "heatthyt' state for an end:poinL Eight built-in conditions check for the presence of
any antivirus and antispyware software on Windows or OS-X endpoints, respectively. They provide a good
starting point for defining a policy that requires antivirus and antispyware software to be instaUed on the
client computers without having to specify the detai ls of the software vendor and signature database. The
requirements match the conditions and define the remediations to be taken when the conditions are no:t met.
The remediation defines the action that must be perfomted if the posture condition is not met. The goal is to
aiJow the endpoint to achieve compliant status. The remediation actions can be of different types:
antispyware remediation, antivirus remediation, file remediation, launch program remediation, link
remediation, Windows Server Update Services remediation, Windows Update remediation.
To effectively D'Oublesboot the posture service, you should understand bow the posture policy,
requirement$, and remediation actions interoperate.

Troubleshoot Posture
'J'bis topic describes bow to troubleshoot posture.
Troubleshoot Posture
Remediations require client connectivity to remediation servers.
dACls and other firewalls may block the remediation access.
ClamWin example: Each name resolution returns another IP address
from the remediation d oud.
-__..___________ .._ ,__
_-......._. . __- ...._--'f~~~i§i5~~~s:S:ii~5

... ___.. _
·~--
.......
- .C~ooo~Voo
.-
=--·-
. ., .·.-
. . ,- . _,_ ._;J CIMd- ..,.,........
- J - I
--......,_ _---·-----
- - ..... ...._.___..
... Jii,__,_
-- -~- .... ........ _
·- -- _,_ .........
--< - - _...
a...a. .. a.s ........ .,..,.,_, ......
-_. . . . _ . ._- ---c:--.. .-

"""~::::!:::~~
.. - ·=
- ~-:,;=
-~-~-----
- -- ~--< --
-- ,_~
...._
......
·--
---
-
.--..- -~- ·--
- ----
- --·------
Ch<M;iolooAS ............ ~ . . ......... I
When you experience problems with the posture service, y ou should validate the overall posture design. In
this scenario, the antivirus installation remediation has been modified to install ClamWin antivirus. Despite
correct settings, when the NAC agent is installed on the e:ndpoint, it reports noncompliant status.
ln this situation, the reason for the failure is not related to a problem with the posture configuration, but
with the reac-habillity to the remediation resources. The endpoints require connectivity to the remediation
servers. lf dACLs and other firewalls block access to remediation, the remediation is bound to fail. The
ClamWin antivirus;, for example uses a distributed cloud of remediation resources. Every time a client
resolves the name of the remediation server, it gets a different fp address. This situation is difficult to
handJe with an dACL or any other network ACL.
6-40 lmplemen~ng Cisco Security Access Sot\Jtlons -0 2014 asco Sy&ems, l nc.
Case Study: Troubleshoot Profiling
This topic describes how to troubleshoot the profiler service.
Profiler Troubleshooting Overview

Potential profiling problems may be related to the following:
1. Incorrect or mismatched settings of network probes and the ISE
2. Lack of visibility to probed traffic on the PSN
3. Lad< of support for CoA oo NAD
4. Missing MAC~to~IP address binding
5. Performance issues with resource~i ntensive probes, such as the
NetAow probe
....... _.
The profiler service collects an attribute or a set of attributes of all the endpoints on your network and
classifies them according to their profiles. The Cisco Identity Services Engine uses profiler probes to collect
an attribute or a set of artributes from an endpoint on your network. Tbe probe allows you to create or
update endpoints with their matched profile in the database. Some probes intemperate with agents in the
network devices, and if they are misconfigured, lhe profiler cannot obtain the endpoint attributes. Similarly,
probes which interrogate particular network traffic won't function if they are not exposed to that traffic. For
example, the OHCJ> probe requires the use of ip helper fearures on routing devices to forward DHCJ>
requests to the I'SN running the OHCP probe.
CoA is not absolutely necessary for profiler service operation. If you have some -iN ADs in your network that
do not support CoA, you may still deploy the profiler service for endpoint monitoring. In this case, the
profiler service can be used to establilib a learned inventory. When CoA is supported on the NADs, you can
use the profiler service to push tailored authorization policies to the endpoints. When the endpoint
authencicates, it recelves a restriccive authorization policy that enables the proti.ling process to comple«e.
Once the endpoint profile is ascertained, an authoriution policy that considers the endpoint profile man be
assigned. ISE then sends a CoA to cbe NAO, instructing cbe NAO to apply an adjusted policy. Clearly, if
you expect the authorization policy to reflect the endpoint profile, a lack ofCoA support will cause an
inadequate authorization policy to be enforced on tlile endpoints.
Endpoint profiling in Cisco IS£ identifies each endpoint on your network, and groups the identified
endpoints according to their profiles. The MAC address is used for the unique identifier of each endpoint.
Some probes work only at the lP layer. Data collected from those probes can only be incorporated into the
endpoint's collected attributes if the MAC to lP address binding already exists.
finally, you may experience performance issues when deploying resource· intensive probes. The probes
consume different amounts of resources depending on their type. For example, the NetFlow probe is more
resource-intensive than a ONS probe.

Summary
Summary
Troubleshooting should be performed in an ordered fashion.
Cisco ISE offers several troubleshooting tools: Failure Reason Editor,
Evaluate Configuration Validator, TCP Dump, Posture
Troubleshooting, and other diagnostic tools.
802.1x authentication can be related to 802. 1x and AAA settings on
the switch, RADIUS peering, peering with back-end authentication
servers, certificate issues, and authentication settings on Cisco ISE.
MAS problems can be caused by missing MAC addresses in the
endpoint identity database or identity source sequence issues in the
MAS authentication rule.
WebAuth failures can occur due to a configuration mismatch between
the NAD and the Cisco ISE.
The posture service can fail if the reme<Jiation servers are inaccessible.
Profiler operation will fail if the network probes do not correspond with
the Cisco ISE probes.
Module Summary
Module Summary
Cisco ISE provides a number of troubleshooting tools, such as
RADIUS Authentication Troubleshooting, Exea.~te Network Device
Command, Evaluate Configuration Validator, Posture Troubleshooting,
and TCP Dump.
0,.,.__.._
References
6~<11 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Module Self-Check
Questions
I. Which tool can you help identifY the reason why an endpoint lP address does not show in the ISS
authentication page? (Source: Troublesbooti:ng Network Access Controls)
A. RADIUS Authentication Troubleshooting
B. Posture Troubleshooting
C. Evaluate Configuration Validator
D. TCI' Dump
B. Execute Network Device Command
2. Which two ISE configuration elements should you check when D'Oubleshooting client certificate
authentication problems? (Choose two.) (Source: Troubleshooting Network Access Controls)
A. Settings of theCA root certifica[e
B. Settings of the client certificate
C. Identity source sequence
D. Certificate identity store
3. Which two statements corre<:uy describe the use of ACLs in Conual WebAuth? (Choose two.)
(Source: Troubleshooting Network Access Controls)
A. Two dACLs are pushed to the NAD
B. Two ACL names are pushed to ll>e NAD
C. One dACL and one ACL name are push-ed to the NAD
D. The JSE pushes the redirect ACL name instead of the redirect ACL to accommodate varying
redirect logic on different NAD types
E. Tbe dACL used in the Central WebAuth authorization profile permits rraffic to be redirected
Answer Key
I. c
2. A,C
3. C, 0
Glossary
Term Definition
AAA authentication , authorization, and accounting. Pronounced "triple a."
ACE access control entry.
ACL access control list. A list kept by routers to control access to or from
the router for a number of services (for example, to prevent packets
with a certain IP address from leaving a particular interface on tne
router).
AD Active Directory
AD advertised distance.
AES Advanced Enc ryption Standard.
AP aeeess !)Oinl A node on a wireless networl< that allows other wireless

devices to connei:t to a wired network.
AS Anti·Spyware
ASA adaptive security appliance
ASDM Cisco Adaptive Sea .Hity Device Manager. Delivers sea..rity

management and monitoring through an inturtive. easy-to--use, w.eb·
based management interface.
ASIC application-specific integrated circuit.
AUP acceptable use policy. Many transit networks ha ve policies that

restrict the use to which the network can be put. The enforoemen t of
AUPs varies with the network.
AV attribute-value
AV attribute values
AV anti~vi rus
BYOD bring your own device
CA certification authority. Entity that issues di9ital certificates (espec:iaUy

X.509 certificates) and vouches for the binding between the data
items in a certificate.
COP CRL distribution poinl
CHAP Challenge Handshake Authentication Protocol. Security feature

supported on lines using PPP encapsulation that prevents
unauthorized access. CHAP does not itself prevent unauthorized
access, but merely identifies the remote end. The router or access
server then de termines whether that user is allowed access.
CISP Client I nformation Signaling Protocol
CLI command·line in terface. An interface tha t allows the user to interact

with the operating system by entering commands and optional
arguments. The UNIX operating system and DOS provide Clls.
C 2014 Clsoo Sys1ems. Inc. Student Guide G-1

Term Deflnltlon I
CoA Change of Authorization.
CPP Client Provisioning Portal
CPU central processing unit. The hardware within a computer system or

smartphone that carries out the instructions of a computer program by
perfOffl'ling the basic arithmetical. logical, and input..output operations
of the system.
CSR certificate signing req uest
csv comma separated values. Commonly used no4rills text file f0011at
used for import from and import to spreadsheets and SQL databases.
CTL Certificate Trust List
dACL downloadable access controllisl
DGT destination group tag
DHCP Dynamic Host Configuration Protocol. Provides a mechanism for

allocating IP addresses dynamically so that addresses can be reused
wflen hosts no longer need them.
DNS Domain Name System. System used on the Internet for translating
names o f network nodes into addresses.
DoS denial of service. An intentional or unintentional attack on a device

that makes the resource unavailable to perfom1 its nonnal function.
EAP Extensible Authentication Protocol. Framework that supports multiple,

optional authentication mechanisms fOf PPP. including cleartext
passwords, challenge-response. and arbitrary dialog sequences.
EAP·FAST Extensible Authentication Protocoi·FiexibSe Authentication via Secure

Tunneling.
EAP-GTC Protected Extensible Authentication Protocoi·Generic Token Card.
EAP·MD5 Extensible Authentication Protocol-Message Digest 5.
EAP·MSCHAPv2 Microsoft CHAP version 2 EAP
EAPOL Extensible Authentication Protocol over LAN
EAP· TLS Extensible Authentication Protocol ~Tran sport Layer Security
Ethemet Baseband LAN specification invented by Xerox Corporation and

developed jointly by Xerox, Intel, and Digital Equipment COl'pomtion.
Ethernet networks use CSMA/CD and run over a variety of cable
types at 10 Mbls. Ethernet is similar to the IEEE 802.3 series of
standards.
FODN fully qualified domain name. FQDN is the full n ame of a system.
rather than just its host name. For example, aldebaran is a host
name, and aldebaran.interop.com is an FQDN.
G-2 lmplemen~ng Cisco Security Access Sei\Jtlons ·0 2014 asco Sy&ems, lnc.
Term Definition I
FTP File Transfer Protocol. Application protocol, part of the TCP/IP

protocol stack. used for transferring files between network nodes..
FTP is defined ir1 RFC 959.
GCM Galois Counter Mode.
GUI graphical user interface. A user environment that uses pictorial a:s
well as textual representations of the input and the output of
applications and the hierarchical or other data structure in which
information is stored. Such conventions as buttons, icons, and
windows are typical. and many actions are performed using a po'inting
device (such as a mouse). Microsoft Windows and the Apple
Macintosh are· prominent examples of platfonns using a GUL
HTTPS Hypertext Transfer Protocol Secure
ICMP Internet ContrQf Message Protocol. Network layer Internet protocol

that reports errors and provides other infom1ation relevant to IP
packet processing. DoaJmented in RFC 792.
ICV integrity check value.
IEEE Institute of Electrical and Electronics Engineers. Professional

organization whose activities include the development of
communications and network standards. IEEE LAN standards are the
predominant LAN standards today.
IETF Internet Engineering Task Force. Task force consisting of over 80
working groups responsible for developing Internet standards. The
IETF operates under the auspices of ISOC.
IP address 32·bit address assigned to hosts using TCP/IP. An IP address
belongs to one of five classes (A, B. C, 0 , or E) and is written as 4
octets separated by periods (dotted decimal format). Each address
consists of a netwoli< number, an optional subnetwork number, and a
host number. The network and subnetwork numbers together are
used for routing, and the host number is used to address an individual
host within the network or subnetwork. A subnet mask is used to
extract netwon< and subnetwork information from the IP address..
CIOR provides a new way of representing IP addresses and subrlet
masks. Also called an Internet address.
IPS intrusion prevention system.
1Pv4 JP version 4.1ntemet Protocol version 4 is the fourth version in the
development of the IP and the first version of the protocol to be widely
deployed. Along with 1Pv6, 1Pv4 is at the core of standards~based
intemetworking methods of the Internet. 1Pv4 is still used to route
most traffic across the Internet. 1Pv4 is a connection less protocol for
use on packet-switched link layer networks (for example, Ethernet). It
operates on a best·effort delivery model in that it does not guarantee
delivery and does not assure proper sequencing or avoidance of
duplicate delivery.
C 2014 Clsoo Sys1ems. Inc. Student Guide G·3

Term Definition
1Pv6 IP version 6. Replacement for the current version of IP (version 4).

1Pv6 includes support for flow 10 in the packet header, which can be
used to identify flows. Foonerly called IPng (next genemtion).
KDC key distribution center
LAN local-area network. High-speed, low -error data network covering a

relatively small geographic area (up to a few thousand metets). lANs
connect workstations. peripherals, terminals, and other devices in a
single building or other geographically limited area. LAN standards
specify cabling and signaling at the physical and data link layers of
the 051 model. Ethernet, FOOl, and Token Ring are widely used LAN
technologies.
LDAP U ghtweight Directory Access Protocol. Protocol that provides access

for management and browser appUcations that provide read/write
interactive access to the X.500 Directory.
LOAPS lightweight Directory Access Protocol over Sea..re Sockets Layer/

Transport l ayer Security
LEAP Lightweight Extensible Authentication Protocol.
LLOP Unk layer Discovery Protocol
MAB MAC authentication bypass.
MAC Media Access Contr,ol. l ower of the two sublayers of the data link
layer defined by the IEEE. The MAC sublayer handles access to
shared media, such as whether token passing or contention will be
used.
MAC address Standardized data link layer address that is required for every port or
device that connects to a LAN. Other devices in the networ1< use
these addresses to l ocate specific ports in the network and to create
and update routing tables and data structures. i\tAC addresses are 6
bytes long and are controlled by the IEEE. Also known as a hardware
address, MAC layer address. and physical address.
MACsec Media Access Contr•ol Sea..rity. MACsec encryption provides MAC.

layer encryption over wired networks using 008 methods for
encryption keying.
MA·L MAC Address Block • Large
MDA multidomain authentication.
MOM Mobile Device Management
MKA MACsec Key Agreement.

MMC M icrosoft Management Console
MS· CHAP Microsoft Challenge Handshake Authentication Protocol.
MSCHAPv2 M icrosoft CHAP version 2
MSI Macintosh Installer.

Term Definition
MTU maximum transmission unit. Maximum packet size. in bytes, that a

particular interface can handle.
NAC Network Admission Control.
NAD network access device.
NAM Network Access Manager

NAM Network Analysis Module
NAS network access server. Cisco platform (or collection of platforms. such
as an AccessPath system) that interfaces between the packet world
(for example, the Internet) and the circuit world (for example, the
PSTN).
NAS network-attached storage
NAT Network Address Translation. Mechanism for reducing the need 1or
globally unique IP addresses. NAT allows an organization with
addresses tha t are not globally unique to connect to the Internet by
translating those addresses into globally routable address space ~ Also
known as Networ1< Address Translator.
NDAC Network Device Admission Control
NEAT Network Edge, Acoess Topology
Netflow A feature of some routers that allows them to categorize incoming

packets in to flows. Because packets in a flow often can be treated in
the same way. this classification can be used to bypass some of the
work of the router and accelerate its switching operation.
NGFW Next-Generation Firewall
NIC network interface card. Board that provides network communication

capabilities to and from a computer system. Also called an adapter.
NMS network management system. System responsible for managing at

least part of a network. An NMS is generally a reasonably powerful
and well-equipped computer, such as an engineering workstation.
NMSs communicate with agents to h elp keep track of network
statistics and resources.
NTP Network Time Protocol. Protocol built on top of TCP that ensures
accurate local timekeeping with reference to radio and atomic clocks
located on the lntemet. This protocol is capable of synchronizing
distributed d ocks within milliseconds over long time periods.
OTP one-time password
QUI Organizations I Unique Identifier . Three octets that are assigned b y

the IEEE in a block of 48-bfi LAN addresses.
PAC Protected Access Credentials.

Term Definition
PAP Password Authentication Protocol. Authentication protocol that allows

PPP peers to authenticate one another. The remote router attempting
to connect to the local router is required to send an authentication
request. Unlike CHAP, PAP passes the password and the host name
or username in the c lear (unencrypted). PAP does not itself prevent
unauthorized access but merely identifies the remote end. The router
or access server thoo determines whether that user is allowed
access. PAP is supported only on PPP tines.
PEAP Protected Extensible Authentication Protocol
PIN places in the network

PKI public-key infrastructure. System of CAs (and, optionally, RAs and
other supporting servers and agents) that perform some set of
certificate management. archive management. key management. and
token management functions for a community of users in an
application of asymmetric cryptography.
PSN Policy Service Node
PSN packet-switched networ1c
OoS quality of service. Measure of perfonnance for a transmission system

that re flects its transmission quality and service availability.
RADIUS Remote Authentication Dial- In User Service. Database for

authenticating mode111 and ISDN connections and for tracking
connection time.
RBACL Role Based ACL
RFC Request for Comments. Document series that is used as the primary
means for communicating information about the Internet Some RFCs
are designated by the lAB as Internet standards. Most RFCs
document protocol specifications, such as Telnet and FTP. but some
RFCs are humorous. or historical. RFCs are available onlin e from
numerous sources.
RSA Acronym stands for Rivest, Shamir, and Ad Ieman, the inventors of the
technique. Public-key cryptographic system that can be used for
encryption and authentication.
SAN Subj ect Atternative N ame.
SAP Seauity Association Protocol
SCEP Simple Certificate Enrollment Protocol.
SGA Security Group Access.
SGACL seaJrity group access control list.
SGFW SectJrity Groop Firewall

SGT seaJrity group tag.
G-6 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Term Definition
SHA·1 Secure Hash Algorithm 1. Algorithm that takes a message of less
than 264 bits i n length and produces a 160-bit message digest. The
large message digest provides security against brute..force collisi on
and inversion attacks. SHA·1 [NIS94c) is a revision to SHA that was
pubUshed in 1994.
SHA·256 Secure Hash Algorithm. SHA·256 is part of the SHA·2 set of
cryptographic hash functions.
SMB Server Message Block Protocol
SMS short message service

SNMP Simple Network Management Protocol. Network management
protocol used almost exclusively in TCP/IP networks. SNMP provides
a means to monitor and control network devices, and to manage
oonfigurations, statiStiC$ CQII~ion, performance, an~ security.
SPAN Switched Port Analyzer. SPAN is a feature that is available on
switches based on Cisco lOS and NX..QS Software that allows traffic
received on a port or VlAN to be copied to another port for analysis.
It is also referred to as "port mirroring."
SSH Secure Shell Protocol. Protocol that provides a secure remote

connection to a router through a TCP application.
SSIO Setvice Set Identifier.
SSIO Service Set Identifier.
SSL Secure Socket Layer. Encryption technology for the Web used to
provide secure transactions, such as the transmission of credrt card
numbers fore-commerce.
sso single sign-on.
STP Spanning Tree Protocol. Bridge protocol that uses the spanning~tree
algorithm, enabling a learning bridge to dynamically work around
loops in a network topology by creating a spanning tree. Bridges
exchange BPOU messages with other bridges to detect loops, and
then remove the loops by shutting dOWTI selected bridge interfaces.
Refers to both the IEEE 802.1 Spanning Tree Protocol standard and
the eartier Digital Equipment Corporation Spanning Tree Protocol
upoo which it is based. The IEEE version supports bridge domains
and allows the bridge to construct a loop..free topology across an
extended LAN!. The IEEE version generally is preferred over the
Digital version .
SXP Security Exchange ProtocoL
syslog system logging.
TACACS+ Terminal Access Controller Access Control System Plus. Proprietary
Cisco enhancement to TACACS. Provides additional support for
authentication, authorization, and accounting.
TCAM ternary content addressable memory

Term Definition
TCP Transmission Control Protocol. Connection-oriented transport layer
protocol that provides reliable full ~duplex data transmission. TCP is
part of the TCP/IP protocol stack.
TCPnP Transmission Control Protocol/Internet Protocol. Common name for

the sutte of protocols develope<l by the U.S. DoD in the 1970s to
support the construction of worldwide intemetworks. TCP and IP are
the two best..known protocols in the suite.
TEAP Tunneled EAP
Telnet Standard terminal emulation protocol in the TCP/lP protocol stack.
Telnet is used for remote terminal connection, enabling users to log
into remote systems and use resources as if they were connected to
a local system. Telnet is defined in RFC 854.
TFTP Trivial File Transfer Protocol. A simplified version of FTP that is

generally used for automated transfer of configuration or boot files
from one computer to another CNer a network, usually without the use
of client authentication.
TLS Transport Layer Security. A future IETF protocol to replace SSL.
TLV type, length, value.
UDI unique device identifier.
UDP User Datagram Protocol. Connectionless transport layer protocol in
the TCP/IP protocol stack. UOP is a simple protocol that exchanges
datagrams without acknowledgments or guaranteed delivery,
requiring that error processing and retransmission be handled by
other protocols. UDP is defined in RFC 768.
URL uniform resource locator. Type of formatted identifier that describes
the access method and the location of an information resource object
oo the Internet. (RFC 1738]
VLAN virtual LAN. Group of devices on one or more LANs that are
configured (using management software) so that they can
communicate as if they were attached to the same wire. when in fact
they are located on a number of different LAN segments. Because
VLANs are based on logical instead of physical connections, they are
extremely flexible.
VM virtual machine.
VoiP Voice over IP. The capability to carry normal telephony·style voice
over an IP·based internet with POTS~I ike functionality, reliability, and
voice quality. VoiP enables a router to carry voice traffic (for example,
telephone calls and faxes) over an IP network. In VoiP, the DSP
segments the voice signal into frames, which then are coupled in
groups of two and stored in voice packets. These voice packets are
transported using IP in compliance with I TU ~T specification H.323.
G..a lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.
Term Definition
VPN virtual private 1network. En ables IP traffic to travel securely over a
pu~ic TCP/IP network by encrypting all traffic from one network to
another. A VP1N uses tunneling to enccypt all information at the IP
level.
VSA vendor~specifhc attribute. An attribute that has been implemented by a

particular vendor. It uses tile attribute VendOf· Specific to encapsulate
the resulting AV pair: essentially, VendOf..Specific = protocol: attribute
=value.
WAN wide-area n etwor1<. Data communications network that serves users

across a broad geographic area and often uses tran smission devices
provided by common carriers. Frame Relay, SM OS, and X.25 are
examples of WANs.
WebAuth web authentication.
WLAN wireless LAN. A LAN is a high-speed, low·error data network covering

a relatively small geographic area (up to a few thousand meters) ~
LANs connect wor1<stations, peripherals, terminals, and other devices
in a single building or other geographically limited area. LAN
standards specify ca~i ng and signaling at the physical and data !link
layers of the OSI model. Ethernet, FOOl, and Token Ring are widely
used LAN technologies.
WLC wireless LAN controller. A centralized networ1< device that is used to

control lightweight wireless APs.
WPA WiFi Protected Access
WPA2 Wifi Protected Access 2


SISAS Student Guide Vol 1

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

SISAS Student Guide Vol 1

Uploaded by

Copyright:

Available Formats

SISASI

C 2014 Cisoo Systems. Inc.

lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.

C 2014 Clsoo Sys1ems. Inc. Student Guide Ill

W lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

C 2014 Clsoo Sys1ems. Inc. Student Guide v

C 2014 Clsoo Sys1ems. Inc. Student Guide vii

Leamer Skills and Knowledge

Upon completing this

Course Goal • Deploy SeC<Jrity Group Access

lmpleme<lt WebAuth and guest

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-3

Threat Mitigation ThrOugh Identity

Advanced Ac:te:ss Control (Cont.) Web AuthenticatiOn and Guest

Cisco Career Certifications

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·5

Cisco Career Certifications

Cllat s-e,.t.ae.. SeM1M1

For more information on certifications, visit http://www.cisco.com/go/certifications.

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-7

Cisco Icons and Symbols

Threat Mitigatiion Through

Cisco Modular Network Architecture

1-4 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Cisco Modular Network Architecture Example

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-S

1-6 lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems,lnc.

Secure Access Control

~ UWM! Poticy Eng nc

C 2014 Clsoo Sys1ems. Inc. Student Guide

Secure Access Solution Portfolio

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-9

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-11

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-13

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-15

IEEE 802.1X Overview

\Vith 802.1 X port~ba~ed authentication, network devices have these roles:

C 2014 Clsoo Sys1ems. Inc. Student Guide 1-19

802.1X Message Flow

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·2 1

802.1X VLAN Assignment

Assigned VlAN DynamicallY assigned by the authenticatiOn server.

Guest YLAN Assigned if oo supplicant dotoot&d and~ does not apply.

Asslg ned VLAN

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·23

802.1X Downloadable ACLs

802.1X Host Modes

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·25

802.1X Phased Deploym ent

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·2 7

802.1X Monitor Mode

802.1X Low Impact Mode

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·29

802.1X Closed Mode

d ~t• ~ P5C outht'~tic«tor

1~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems, lnc.

802.1X Deployment Mode Comparison

IEEE 802.1X Wired Modes

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·31

802.1X Phased Deployment Guidelines

C 2014 Clsoo Sys1ems. Inc. Student Guide 1·33

MAC Authentication Bypass

1~ lmplemen~ng Cisco Security Access Sot\Jtlons ·0 2014 asco Sy&ems.lnc.

Extensible Authentication Protocol