TrustSec in Cisco ISE

Enterprise and Security

Secure Access
ISE and VPN
 ISE Configurations and Monitoring 10
TrustSec Security Groups 11
Network Device 12
Policy Sets 14
ASA Monitoring on VPN Sessions 16
TrustSec SXP Propagation 18
ISE SXP Service 18 SXP on ASA 21 SXP on
CSR1Kv 24
ASA SGFW Enforcement 25 SGFW Access-list 25

Monitoring SGFW Rules 26

TrustSec SGACL Enforcement 28
TrustSec Matrix 28
Custom View 29 SGACLs in Matrix 31 SGACLs
components 32
Disable SGFW rules in ASA 33 Verify SGACLs in
Production 34 Multiple Matrices 36
Verify SGACLs in Monitor-All 38
Rapid Threat Containment (RTC) 44
Assign CSR-Portals back to Production Matrix 46
Re-enable SGFW rules in ASA (Cleanup) 47
Disconnect VPN Client(s) 47
 Topology
see the IP address and user account credentials to use to access a component by
clicking the component icon in the Topology menu of your active session and in
the scenario steps that require their use.
dCloud Topology
 EquipmentDetails

Device IP Address Access Method Username Password Description

C9800-CL Private: WKST1-JUMP Session Owner Session ID wlc1.dcloud.cisco.com

198.19.11.10 Browser Local
Browser
Public: See
Session Details

WKST1-JUMP 198.18.133.36 WebRDP or admin C1sco12345 WKST1-JUMP

AnyConnect (RDP access)

OWA 198.18.133.2 WebRDP or administrator C1sco12345 mail1.dcloud.cisco.com/owa

AnyConnect

AD1 198.18.133.1 WebRDP or administrator C1sco12345 AD1 (RDP

AnyConnect access)

Portals 198.18.133.110 MTPuTTY linuxuser C1sco12345 See Portal

Tables

Traffic_Simulator 198.18.134.150 MTPuTTY root C1sco@123 N/A

Device IP Address Access Method Username Password Description

ISE 198.18.133.27 WKST1-JUMP admin C1sco12345 https://ise.securitydemo.net

Browser
VPN https://198.18.133.27
Local Browser

Splunk 198.18.133.42 WKST1-JUMP admin C1sco12345 splunk.securitydemo.net:8000

Browser
VPN
Local Browser

SOAR 198.18.133.55 WKST1-JUMP admin C1sco12345 splunk-soar.secuirtydemo.com

Browser

linux-sandbox-tools 198.18.134.28 MTPuTTY root C1sco12345 Docker running on

Local PuTTY Ubuntu
VPN
Tool

wkst1-CESA-VPN 198.19.10.37 Console admin C1sco12345 wkst1-CESA-VPN

(Console access)

wkst2-CESA 198.18.133.37 WebRDP or admin C1sco12345 wkst2-CESA

AnyConnect (RDP access)

wkst3-CESA 198.18.133.38 WebRDP or admin C1sco12345 wkst3-CESA

AnyConnect (RDP access)

wkst4-CESA 198.18.133.39 WebRDP or admin C1sco12345 wkst4-CESA

AnyConnect (RDP access)

CSR1kv 198.18.133.254 MTPuTTY admin C1sco12345 CSR-Portals

/ 198.19.11.11

SNA 198.18.128.136 WKST1-JUMP admin C1sco12345 https://smc.dcloud.cisco.com

Browser Local
VPN https://198.18.133.36
Browser

FCNF 198.18.128.138 WKST1-JUMP admin C1sco12345 https://fcnf.dcloud.cisco.com

Browser Local
VPN https://198.18.133.37
Browser

QRadar 198.18.133.50 WKST1-JUMP admin C1sco12345 https://198.18.133.50

Browser

ASAv 198.18.133.100 MTPuTTY admin C1sco12345 Virtual ASA

/ 198.19.10.100 Local Browser
(AnyConnect
Public: See Session
download only)
Details

MDM 198.18.133.40 WKST1-JUMP administrator C1sco12345 https:/mobileiron.securitydemo.net

Browser Local
VPN https://198.18.133.40
Browser
 Device IP Address Access Username Password Description
Method
Tenable 198.18.128.123 WKST1-JUMP admin C1sco12345 https:/tenable.securitydemo.net
Browser Local
VPN https://198.18.133.40
Browser

CredentialsandAccess Levels
Scenario / Vertical Username Password Access Level
Healthcare doctor C1sco12345 Tier 1 – Full Access

Healthcare nurse C1sco12345 Tier 2 – Limited Access

Education dean C1sco12345 Tier 1 – Full Access

Education professor C1sco12345 Tier 2 – Limited Access

Federal captain C1sco12345 Tier 1 – Full Access

Federal officer C1sco12345 Tier 2 – Limited Access

Corporate manager C1sco12345 Tier 1 – Full Access

Corporate employee C1sco12345 Tier 2 – Limited Access

Before YouPresent
Cisco dCloud strongly recommends that you perform the tasks in this document before presenting in front of
a live audience. This will allow you to become familiar with the structure of the document and content.
dCloud recommends using the Chrome browser for all demos.

PREPARATIONISKEYTOA SUCCESSFUL PRESENTATION.

GetStarted
hFollow the steps to schedule a session of the content and configure your presentation environment.

Procedure

Step 1 Browse to dcloud.cisco.com, select the location closest to you, and log in with your Cisco.com credentials.
Step 2 (Optional) Register and configure your router if this is the first time you will use the router with dCloud.
[Show Me How]
Step 3 Schedule a session. [Show Me How]
Step 4 Test your connection. [Show Me How]
 CHAPTER 2
Scenarios
• TrustSec Classification for Remote Access VPN with ASA, on page 7
• TrustSec SXP Propagation, on page 18
• ASA SGFW Enforcement , on page 25
• TrustSec SGACL Enforcement , on page 28
• Rapid Threat Containment (RTC), on page 44

TrustSecClassification for RemoteAccess VPN withASA

This section will demonstrate a tier-2 user using Cisco AnyConnect VPN client to remotely connect to a Cisco
Adaptive Security Appliance (ASA) to an enterprise network. The ASA is configured to authenticate VPN
users against ISE. ISE is shown to accept authentication requests from the ASA and assign a security group
of TIER2Users to the user.
We have options to either use the dCloud-hosted client wkst1-CESA or to use a BYOD CLIENT -- one of
our own client devices.
wkst1-CESA: This is to use the dCloud-hosted client.
1. In the demo topology, locate wkst1-CESA, which connected to the network device ASAv-VPN, click on
the down-arrow icon next to its text label, and then select VM Console to connect to it.

2. If asked for credentials, login with the username admin and password: C1sco12345:
3. Once logged in, click on the AnyConnect icon in the windows taskbar.

4. The VPN tile will show that Ready to connect.; i.e. the user is not currently connected to VPN

5. Select Connect to connect the PC to the enterprise network through a VPN connection to the ASA.

6. Select Connect Anyway when prompted with a Security Warning: Untrusted Server Certificate!

Note The ASA VPN gateway is using a self-signed certificate and the certificate does not contain the IP address
(As the public IP address is dynamically allocated by dCloud and in a wild range, we are unable to include
them in the certificate) in the certificate subject or the subject alternative name, so we are getting this
warning.
 7. When prompted for the credentials, login with a tier-2 user info (e.g. usernameemployee and password
C1sco12345 based one the chart Credentials and Access Levels) and then click OK.

8. Note that the AnyConnect icon in the system tray now has a padlock added to notify that we are now
securely logged into the corporate network:

BYODCLIENT
Alternative to wkst1-CESA, which hosted in dCloud, we have an option to use one of our own devices. Below
shows an Apple iPad touch.
 Procedure

Step 1 In the demo session, click on Details to view the session details and then scroll down to the last section Public
IP Addresses. Locate the public address entry for ASAv
Step 2 On one of our own devices, open the Cisco AnyConnect client app, available in Apple App Store or in Google
Pay Store.
Step 3 Click on Connections.
Step 4 If an entry exists for dCloud, click on the info icon, update the server address with the public address of the
asav, and Save. If no entry exists, scroll down, if needed, select Add VPN Connection..., enter dCloud in the
description, enter the public address of the asav in the server address, and Save.

Step 5 Make sure the client device is connected to Home/Office Wi-Fi or Mobile for Internet.
Note Client should not use one of the Wi-Fi networks in the dCloud demo sessions.

Step 6 Toggle AnyConnect VPN to ON. When prompted for Untrusted Server, select Continue.
Step 7 When prompted for Authentication, input a tier-2 user credentials (e.g. Username: officer and Password:
C1sco12345) and click Connect. The connection details should turn to Connected.

ISE Configurations and Monitoring

While a person is working remotely, TrustSec mechanisms are working behind the scenes to protect the
user’s session and the network services in the enterprise. Let’s have a look at ISE and see how this is
accomplished.

Procedure

Step 1 In the demo topology, locate WKST1-JUMP, click on the down-arrow icon q next to its text label, and then
select Remote Desktop to connect to it:
 Step 2 From the WKST1-JUMP, click the Firefox shortcut in the quick launch section of the Windows taskbar to
open the Firefox web browser.
Step 3 The second entry on the left of the Firefox Bookmark Toolbar is ‘ISE’. Select this bookmark to navigate to
the ISE GUI. Login with username admin and password C1sco12345.

TrustSec Security Groups

Firstly, we can look at the security groups that are present in ISE.

Procedure

Navigate using the top menu to Work Centers > TrustSec > Components. In the left-hand menu that appears,
select Security Groups:
 From the list of above, you can see that the ‘TIER2Users’ security group is present, defined with Security
Group Tag (SGT) 17.

NetworkDevice
When a RADIUS request is received by ISE, a network device entry must be present for that request to be
processed successfully.

Procedure

Step 1 From the figure above, the ‘Network Devices’ selection can be seen in the left-handmenu. Select that ‘Network
Devices’ entry.
Step 2 ASAv-vpn is an entry in the table:

Step 3 If you click on ‘ASAv-vpn’ or select the ASAv-vpn row and click on ‘Edit’, then the details will be displayed.
Policy Sets
After ISE successfully determines a Network Device entry exists for the RADIUS request, the Authentication
and Authorization tables are assessed to determine what access to provide for that user. Multiple Authentication
and Authorization tables are provided by ISE through the use of Policy Sets

Procedure

Step 1 Navigate to Policy Sets using Work Centers > TrustSec > Policy Sets:
ISE Authentication and Authorization policies of the policy set Remote Access VPN

In this demo, the Authorization entry for Tier2 Users uses a condition AD1:ExternalGroups EQUALS
dcloud.cisco.com/Builtin/TIER2_USERS and assigns the TIER2Users security group. So, a tier-2 user has
used AnyConnect to connect to the ASA, the ASA has made a RADIUS request to ISE and ISE has assigned
the TIER2_USERS security group through the Authorization table. The assignment has sent back to the ASA
via the RADIUS Authorization Accept message.

Step 2 In ISE, we can check the live logs and live sessions:
 Step 3 The TIER2_USERS security group assignment for the user in the ASA is used to enforce traffic flows from/to
that user, in a later section.

ASA Monitoring onVPN Sessions

Procedure

Step 1 On WKST1-JUMP, double click the desktop shortcut Cisco ASDM-IDM Launcher to open ASDM:
Step 2 Log into the ASA at 198.18.133.100 with username admin and password C1sco12345, select Continue
at the security warning:

We will check the VPN session which has been created by the user connecting to the enterprise network.

Step 3 Near the top of the ASDM GUI, select ‘Monitoring’ and from the bottom left hand menu that appears, select
‘VPN’. From the middle left hand menu, select Sessions under VPN Statistics.
Step 4 To the right of the ‘VPN Statistics’ menu, the right-hand pane has a drop-down menu entitled ‘Filter By:’
with IPsec Site-to-Site selected by default. Drop this menu down and select ‘All Remote Access’ instead.
The user VPN session will be displayed.
In the session details above, you can see the user ‘employee’ has connected to the network. On the right-hand side you will see
the Security Group Tag TIER2Users has been assigned (SGT 17), which is done by ISE. When a user attempts a remote VPN
session to the ASA, the ASA communicates to ISE via RADIUS and
ISE has used the context information to authorize that user with the TIER2Users security group.

TrustSec SXPPropagation
TrustSec propagation is used to transfer securitygroup mappings from one location to another. Several methods
exist and they include inline tagging, Security Group Tag Exchange Protocol (SXP), ISE pxGrid, and in the
header of protocols like VXLAN, IPSec, GRE, DMVPN and GETVPN. This section will demonstrate how
TrustSec security groups can be propagated from ISE to ASA and to CSR1Kv using SXP.

ISE SXP Service

Starting Release 2.0, an ISE node may act as an SXP peer (speaker/listener/both) by enabling SXP service
on one of its interfaces. For user accesses, ISE learns the IP address of the user from the RADIUS request,
assigns an SGT via the authorization table and sends the associated IP:SGT mapping out via SXP. For server
resources, we may configure static IP-to-SGT mappings in ISE and then propagate them out via SXP.
When a deployment requires many SXP connections from wired/wireless/VPN access devices, it may be best
to use SXP from ISE.
 Procedure

Step 1 On the WKST1-JUMP, use the Firefox web browser to navigate to ISE. Go to Administration > System >
Deployment. Select the ISE instance in the right-hand pane. By scrolling down, SXP can be seen to already
be enabled at the bottom of the following figure:

Step 2 In ISE, navigate to Work Centers > TrustSec > SXP. The SXP Devices table has three entries – one for
ASAv-vpn and one for csr1kv.

Step 3 This demo has no ACI or Nexus 1000v to assign IP-to-SGT mappings for server resources, so we have
pre-configured static entries in ISE. In ISE, navigate to Work Centers > TrustSec > Components > IP SGT
Static Mapping.
Step 4 When ISE RADIUS session services authenticate and authorize a user or computer, ISE assigns an SGT and
creates an IP:SGT mapping. That mapping can be seen in ISE by navigating to Work Centers > TrustSec
> SXP > All SXP Mappings:

Note TIER2 Users mapping is learned from both ISE (198.18.133.27) and ASAv-VPN (198.18.133.100)
because ASAv-VPN is the NAD that the user connected to, because ASAv-VPN uses ISE as the
AAA server, and because both of them are SXP peers.
SXP onASA
Procedure

Step 1 On ASDM, navigate to Monitoring (at the top), Properties (bottom left) and ‘Identity by TrustSec’ in the
middle left pane (click on the + to the left of the entry to open up the menu). Four options exist under there.
The figures below show them in turn.
Note The PAC is used for secure communications between the ASA and ISE. The ASA does not download
the PAC inline from ISE like other devices do. The PAC is installed on the ASA by exporting it
from ISE under the Network Devices entry and importing it into the ASA. The PAC has already
been imported into the ASA in this demo.
Step 2 When securely connected, the ASA downloads what is called environment data from ISE including timers
and all available security groups. Once the groups are downloaded then group based access rules can be
provisioned.

ASA has been pre-configured with an SXP connection with ISE.

Step 3 Using ASDM, navigate to Monitoring > Properties > Identity by TrustSec > SXP Connections to see the
state of the current ASA SXP Connections. For the single entry in the table, see the peer IP address
198.18.133.27(which is the ISE) and the Status is ‘On’ meaningthis SXP TCP connection is up and operational.
The Role is ‘listener’ meaning that ASA will learn mappings from ISE via this SXP connection:
 Note If you would like to see the configuration of SXP in ASDM then you can navigate toConfiguration
> Firewall > Identity by TrustSec. Here you configure SXP, import the PAC from ISE and manage
the RADIUS server settings.

Step 4 The IP Mappings table shows the IP to Security Group mappings resident. The last entry shown in the current
table is the tier-2 user’s remote access mapping of its IP address from the VPN pool to the assigned TIER2Users
SGT.
SXP onCSR1Kv
Procedure

Step 1 On the Jumper PC, use MTPuTTY (Multi-Tabbed PuTTY) to open an SSH session for the CSR-Portals
(198.18.133.254). After logging on (with admin and C1sco12345), enter the command ?show cts sxp
connection?.
CSR-Portals#show cts sxp connections
SXP : Enabled
Highest Version Supported: 4
Default Password : Not Set
Default Source IP: Not Set
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
Peer-Sequence traverse limit for export: Not Set
Peer-Sequence traverse limit for import: Not Set

Peer IP : 198.18.133.27
Source IP : 198.18.133.254
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 1
TCP conn password: none
 Hold timer is running
Duration since last state change: 1:10:46:12 (dd:hr:mm:sec)

Total num of SXP Connections = 1

Step 2 Use the following command to see the SXP mappings received: ?show cts role-based sgt-map all?.
CSR-Portals#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information

IP Address SGT Source

============================================
198.18.133.254 2 INTERNAL
198.18.140.100 17 SXP
198.20.11.48 21 SXP
198.20.11.49 22 SXP
198.20.11.50 20 SXP
198.20.11.51 21 SXP
198.20.11.52 22 SXP
198.20.11.53 20 SXP
198.20.11.54 21 SXP
198.20.11.55 22 SXP
198.20.11.56 20 SXP
198.20.11.57 21 SXP
198.20.11.58 22 SXP
198.20.11.59 20 SXP
198.20.11.99 18 SXP
198.20.11.200 20 SXP
198.20.11.253 2 INTERNAL

IP-SGT Active Bindings Summary

============================================
Total number of SXP bindings = 15
Total number of INTERNAL bindings = 2
Total number of active bindings = 17

ASA SGFWEnforcement
This section will demonstrate how TrustSec security groups can be used in the ASA to enforce policy. When
group based polices are used in the ASA, the term used is Security Group Firewall or SGFW.

SGFWAccess-list
The ASA can enforce traffic from/to security groups; hence, from/to users as a member of the TIER2 Users
group.

Procedure

Step 1 On the Jumper PC WKST1(-JUMP), bring up ASDM again.

Step 2 To check what access rules are initially configured in the ASA, use ASDM and navigate to Configuration >
Firewall > Access Rules.
 Note We are using a global access-list. This is to allow VPN access and enforcement at both of the ASA
interfaces, due to the topology used in this demo.
The ASA, by default, bypass interfaces access lists for VPN sessions. This has been disabled for
this demo. You may see the option to Bypass interface access lists for inbound VPN sessions in
Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection
Profiles.

Monitoring SGFW Rules

Procedure

Step 1 In ASDM, select the line-1 rule, which is for TIER2Users, and click on Show Log. This will pop up the
Real-Time Log Viewer filtered by this particular rule:
Step 2 Now, go back to the client device (e.g., wkst1-CESA) and use a web browser (e.g. Mozilla Firefox) to
navigate to the Cisco ISE Demo Topology (http://topo.dcloud.cisco.com) using the bookmark toolbar. Pick
and click a vertical portal (e.g., Corporate Portal). This portal should work, because it is a public site.
Step 3 Next click on the link for the EMPLOYEES internal resources. This should work, because it is a tier-2 site.
Step 4 Finally, locate and click on the link for records in the “Corporate Financial Records” site. This access should
NOT work, because it is a tier-1 site, and should result in “The connection has timed out” or similar:
Note If accessed previously or un-expected results, please make sure to clear the cache in the browser
and try again

TIER2Users has no access to the records site.

Step 5 Switch back to the WKST1-JUMP, ASDM should show new entries in the real-time log viewer.
 This has demonstrated how TrustSec Security Groups can be used on the ASA to enforce policy. The ASA
is very flexible in that access rules can be added with security groups in just the source criteria, in just the
destination criteria or in both source and destination criteria. Touse securitygroup information in the destination
criteria, the destination group information can be sent to the ASA via the use of SXP for example. SXP
operation on the ASA is explained later in this document.

TrustSec SGACLEnforcement
Besides SGFW used by ASA and FTD, many Cisco network devices, such as Cisco CSR 1000v, may enforce
based on Cisco TrustSec Security Group Access Control Lists (SGACLs), which can be created in ISE and
entered into cells in TrustSec matrices. As soon as a NAD learns of a new IP-SGT mapping (statically assigned
or dynamically learned), it will send a request to ISE to download any provisioned policy that is defined to
protect those resources. By protect, we mean policies where these SGT?s are the destinations in the ISE
TrustSec Policy Matrix.

TrustSec Matrix
Let’s have a look at the TrustSec Policy Matrix in ISE.

Procedure

Step 1 On the Jump PC WKST1, use the Firefox browser to navigate to ISE as before and login using a username
of admin and password of C1sco12345. Navigate to Work Centers > TrustSec > TrustSec Policy. By
default, it shows the Production Matrix with All Cells with SGACL names. If needed, select View > All Cells
with SGACL names and, next to it on the right, select Show > All:
 Step 2 At the top of the matrix you can see options to add more policies in the matrix, clear existing policies and to
deploy changes made to network devices. The Deploy function utilizes RADIUS Change of Authorization
(CoA) to signal to the devices that a change has been made and to request an update.

Custom View
The more security groups (SGTs) that have been added into ISE the bigger the matrix will be. Every SGT
will be listed down the left-hand side of the matrix (the source group) and across the top (the destination
group). There are some functions in the matrix to help zoom into the groups of interest. For example, you can
click on the arrows just to the right of Destination and Source at the top-left of the matrix to sort the rows in
the opposite order. You can drop the ‘View’ option down at the top of the matrix and select condensed views
so that blank rows and columns are omitted. Custom views can also be created and used.

Procedure

Step 1 For this demo, we have pre-created a custom view dcloud. Let’s check it out by clicking on the Show box at
the top of the matrix (with ‘All’ currently displayed) and select the pencil next to ‘dcloud’:

Step 2 The pop-up window shows dcloud as the view name. For the source groups, TIER1Users, TIER2Users, Guests,
Quarantined_Systems, and RemedyWebServers are selected to show; for the destination groups, Tier1WebSites,
Tier2WebSites, PublicWebServers, RemedyWebServer, and Quarantined_Systems are selected to show.
Select Cancel when done:
Step 3 Once selected, the matrix shown will only have the entries that were selected in the custom view:
SGACLs in Matrix
The intersection of a particular source and destination pair is a cell that contains what we call SGACLs. Each
SGACL is a list of Access Control Entries (ACEs) that enforces traffic when downloaded to the network
devices.

Procedure

Step 1 To quickly view an SGACL in the matrix, move the mouse to the cell from TIER1Users to Tier2WbSites or
PublicWebServer, and hover the mouse over the plus sign (the crosshairs icon) that appears in the top left-hand
corner of the cell. The associated SGACL appears in a pop-up box.

Step 2 Additionally, you can double click on a cell to view or edit the SGACL assigned to the cell. Double click on
the TIER1Users to PublicWebServer cell now. The status drop-down allows to toggle among Enabled, Disabled,
and Monitor. We will not be making any edits for this demo so click on cancel when you are ready.
SGACLs components
he previous steps show methods of selecting existing SGACLs. We will now go over how to add SGACLs
into ISE.

Procedure

Step 1 Navigate to Work Centers > TrustSec > Components > Security Group ACLs. Drag the right-hand edge
of the ‘Name’ heading box to the right to expose the full names of the entries:
Note Two SGACLs exist by default, Permit IP (which contains the ‘permit ip’ ACE) and Deny IP (which
contains the ‘deny ip’ ACE). These permit all IP traffic or deny all IP traffic, respectively.

Step 2 From here, you can add further entries, delete entries and edit the existing entries. Click on the
WEB_PORTALS entry (or check the box next to it and click Edit). You will see the contents of the SGACL.
Check out the contents of the other entries but don’t change any of them:
Disable SGFWrules in ASA
Earlier we used SGFW to block TIER2Users from accessing Tier1WebSites. In order to demo the enforcements
by SGACL, we will now disable these rules.
 Procedure

Step 1 On the Jumper PC WKST1(-JUMP), bring up ASDM again. Navigate to Configuration > Firewall > Access
Rules
Step 2 Disable the first two rules using security groups: First, clear the enabled □ checkmarks for TIER2Users and
for Guests and Investigate. Then, click Apply:

Step 3 Click Send when the Preview CLI Commands showing the two access entries to be updated with inactive.
Below shows the content of the two lines sending to the ASA:
access-list global_access line 1 extended deny ip security-group name TIER2Users any
security-group name Tier1WebSites any inactive
access-list global_access line 2 extended deny ip security-group name Guests any
object-group-security DM_INLINE_SECURITY_1 any inactive

Verify SGACLs in Production

As soon as the CSR1Kv learns of a new IP-SGT mapping, it will send a request to ISE to download any
provisioned policy that is defined to protect that resource. It can be seen from the matrix information above
that ISE does have policies configured for source TIER2Users group (SGT 17) to three destination groups.
Those destination groups are Tier1WebSites group (SGT 21), Tier2WebSites group (SGT 22), and
PublicWebServers group (SGT 20).

Procedure

Step 1 Go back to the remote-access VPN client (e.g. wkst1-CESA). Refresh the web browser that accessed to a
Tier-1 site (e.g. corporate-records.dcloud.cisco.com), while connected as a Tier-2 user (e.g. employee). It
should time out after one or two minutes.
 Note This depends on Disable SGFW rules in ASA. Please ensure completing that section and use ASDM
to verify the SGFW rules are disabled.

Step 2 Go to the Jump PC WKST1 and the PuTTY SSH session to CSR-Portals. To check the policies, the SGACL,
and monitor the hits on the SGACLs, use the following CLI commands ‘show cts role-based permissions
from 17 to 21’, ‘show cts rbacl’ and ‘show cts role-based counters from 17 to 21’.
CSR-Portals#show cts role-based permissions from 17 to 21
IPv4 Role-based permissions from group 17:TIER2Users to group 21:Tier1WebSites:
Deny IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE

CSR-Portals#show cts rbacl

CTS RBACL Policy
================
RBACL IP Version Supported: IPv4
name = Deny IP-00
IP protocol version = IPV4
refcnt = 5
flag = 0x41000000
stale = FALSE
RBACL ACEs:
deny ip

name = WEB_PORTALS-30
IP protocol version = IPV4
refcnt = 9
flag = 0x41000000
stale = FALSE
RBACL ACEs:
permit tcp dst eq 80 log
permit icmp log
 name = Permit IP-00
IP protocol version = IPV4
refcnt = 2
flag = 0x41000000
stale = FALSE
RBACL ACEs:
permit ip
CSR-Portals#show cts role-based counters from 17 to 21
Role-based IPv4 counters
From To SW-Denied HW-Denied SW-Permitt HW-Permitt SW-Monitor HW-Monitor
17 21 0 27 0 0 0 0

Note Since the production matrix is using the default Deny IP, which does no logging, we will not see
any deny log entries from this test.

Multiple Matrices
ISE Release 2.2 adds Support for Multiple TrustSec Matrices, which allows creating multiple matrices for
different scenarios and deploying different policies to different sets of network devices.
In this demo, we will show a second matrix – Monitor, aside from the built-in default matrix – Production.
The Monitor matrix has Monitor All enabled, so nothing enforced with logging enabled at the ACE level. We
will then move CSR-Portals to this monitor matrix and observe the behavior.

Procedure

Step 1 On the WKST1-JUMP, use the Firefox browser to navigate to ISE as before and login using a username of
admin and password of C1sco12345. Navigate to Work Centers > TrustSec > Settings:
Step 2 Multiple matrices are not enabled by default, although this demo has it enabled. In case trying it in your own
ISE deployment, select the submenu Settings and pick Work Process Settings in the left-hand pane. Below
shows ‘Multiple Matrices’ selected:

Step 3 Select the submenu TrustSec Policy, then, from the left-hand pane, select Egress Policy > Matrices List.
 This will show two matrices – Production and Monitoring.

Step 4 We have been looking at the Production Matrix previously. Let’s look at the Monitoring matrix by clicking
on the hyper-link for Monitoring under the Matrix section:

Note Monitor All – On indicates that the entire matrix is in monitoring. If it not shown in this mode, use
View to toggle to All Cells with/without SGACL names and then back to Populated Cells with
SGACL names.
All the cells are in blue, because they are all custom. For example, DENY_IPv4_with_Log is to
deny and log all IPv4 access.
VerifySGACLs in Monitor-All
Procedure

Step 1 Now we are ready to move CSR-Portals to monitor the CoA activities due to SGACL updates on CSR-Portals,
go to the Jump PC WKST1 and the PuTTY SSH session to CSR-Portals, issue the commands ‘terminal
monitor’ and ‘debug aaa coa’:
CSR-Portals#terminal monitor
CSR-Portals#debug aaa coa
AAA CoA packet processing debugging is on

Step 2 On the WKST1-JUMP, use the Firefox browser to navigate to ISE as before and login using a username of
admin and password of C1sco12345. Navigate to Work Centers > TrustSec > TrustSec Policy. Select
Assign NADs from the tool bar.

Step 3 In the pop-up Assign Network Devices, select CSR-Portals, assign it to a matrix Monitoring, click Assign,
and then Close & Send. Answer Yes when prompted Assign NADs process may take several minutes to
complete, are you sure you want to continue?

Assign Network Devices pop-up

 Close & Send

Step 4 This change of policy is updated on network devices upon timer refresh or by using RADIUS Change of
Authorization (CoA) on ISE to push the change immediately. There are two ways to instigate CoA, one way
is to use the Deploy option shown at the top of the matrix, the other way is to use the blue notification icon
that will shortly appear in the ISE toolbar
Step 5 Wait for the notification counter in the upper right corner to turn to 1 or greater. Move the pointer to the blue
notification icon and you’ll see that the change of policy has been registered and an option is given to Push
that change to network devices. Click on the Push button. When a feedback is provided via a pop-up box,
select OK:

Pushing policy change using the blue notification icon

Policy push feedback

Step 6 ISE Live Logs will have events for Dynamic Authorization (aka CoA) and TrustSec Data Download.
Navigate to Operations > RADIUS > Live Logs:
Step 7 Switch the window to the PuTTY SSH session to CSR-Portals and review the coa debug entries in the terminal.
Below shows a sample output:
*Oct 18 02:23:18.935: COA: 198.18.133.27 request queued
RADIUS: authenticator FC 48 C3 68 78 11 09 71 - E6 B3 2B 35 D7 CB 75 70
*Oct 18 02:23:18.937: RADIUS: User-Name [1] 14 "#CTSREQUEST#"
*Oct 18 02:23:18.937: RADIUS: NAS-IP-Address [4] 6 198.18.133.254
*Oct 18 02:23:18.938: RADIUS: Event-Timestamp [55] 6 1602987802
*Oct 18 02:23:18.939: RADIUS: Message-Authenticato[80] 18
RADIUS: C3 A8 F0 4D 31 F4 B6 B3 D3 F6 9B A4 55 62 3D 50 [ M1Ub=P]
*Oct 18 02:23:18.940: RADIUS: Vendor, Cisco [26] 33
*Oct 18 02:23:18.940: RADIUS: Cisco AVpair [1] 27 "policy:command=update-sgt"
*Oct 18 02:23:18.941: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.941: RADIUS: Cisco AVpair [1] 32 "ct s:security-group-tag=16-001b"
*Oct 18 02:23:18.942: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.942: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=14-001d"
*Oct 18 02:23:18.942: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.943: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=12-0001"
*Oct 18 02:23:18.943: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.943: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=10-0015"
*Oct 18 02:23:18.943: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.943: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=11-0016"
*Oct 18 02:23:18.944: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.944: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=15-0019"
*Oct 18 02:23:18.944: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.944: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=0-000c"
*Oct 18 02:23:18.945: RADIUS: Vendor, Cisco [26] 40
*Oct 18 02:23:18.945: RADIUS: Cisco AVpair [1] 34
"cts:security-group-tag=ffff-00 0d"
*Oct 18 02:23:18.945: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.945: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=9-000c"
*Oct 18 02:23:18.945: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.946: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=f-000c"
*Oct 18 02:23:18.946: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.946: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=5-000c"
*Oct 18 02:23:18.946: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.946: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=8-000c"
*Oct 18 02:23:18.947: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.947: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=c-000c"
*Oct 18 02:23:18.947: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.947: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=4-000c"
*Oct 18 02:23:18.947: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.948: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=6-0015"
*Oct 18 02:23:18.948: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.948: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=3-000c"
*Oct 18 02:23:18.948: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.948: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=e-000c"
*Oct 18 02:23:18.949: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.949: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=a-000c"
*Oct 18 02:23:18.949: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.949: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=b-000c"
*Oct 18 02:23:18.950: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.950: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=7-000c"
*Oct 18 02:23:18.950: RADIUS: Vendor, Cisco [26] 38
*Oct 18 02:23:18.950: RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=ff-000c"
*Oct 18 02:23:18.950: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.950: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=d-000c"
*Oct 18 02:23:18.951: RADIUS: Vendor, Cisco [26] 37
*Oct 18 02:23:18.951: RADIUS: Cisco AVpair [1] 31 "cts:security-group-tag=2-000c"
*Oct 18 02:23:18.951: COA: Message Authenticator decode passed

*Oct 18 02:23:18.952: ++++++ CoA Attribute List ++++++

*Oct 18 02:23:18.952: 7EFD40C8FF28 0 00000081 username(450) 12 #CTSREQUEST#
*Oct 18 02:23:18.952: 7EFD40C8FDD0 0 00000001 nas-ip-address(600) 4 198.18.133.254
*Oct 18 02:23:18.952: 7EFD40C8FE10 0 00000001 Event-Timestamp(445) 4 1602987802(5F8BA71A)
*Oct 18 02:23:18.953: 7EFD40C8FE50 0 00000081 security-group-tag(893) 7 16-001b
*Oct 18 02:23:18.953: 7EFD40C8FE90 0 00000081 security-group-tag(893) 7 14-001d
*Oct 18 02:23:18.953: 7EFD40C8FED0 0 00000081 security-group-tag(893) 7 12-0001
*Oct 18 02:23:18.953: 7EFD40C8FC78 0 00000081 security-group-tag(893) 7 10-0015
*Oct 18 02:23:18.954: 7EFD40C8FCB8 0 00000081 security-group-tag(893) 7 11-0016
*Oct 18 02:23:18.954: 7EFD40C8FCF8 0 00000081 security-group-tag(893) 7 15-0019
*Oct 18 02:23:18.954: 7EFD40C8FD38 0 00000081 security-group-tag(893) 6 0-000c
*Oct 18 02:23:18.954: 7EFD40C8FD78 0 00000081 security-group-tag(893) 9 ffff-000d
*Oct 18 02:23:18.955: 7EFD40C8FB20 0 00000081 security-group-tag(893) 6 9-000c
*Oct 18 02:23:18.955: 7EFD40C8FB60 0 00000081 security-group-tag(893) 6 f-000c
*Oct 18 02:23:18.955: 7EFD40C8FBA0 0 00000081 security-group-tag(893) 6 5-000c
*Oct 18 02:23:18.956: 7EFD40C8FBE0 0 00000081 security-group-tag(893) 6 8-000c
*Oct 18 02:23:18.956: 7EFD40C8FC20 0 00000081 security-group-tag(893) 6 c-000c
*Oct 18 02:23:18.956: 7EFD40C8F9C8 0 00000081 security-group-tag(893) 6 4-000c
*Oct 18 02:23:18.956: 7EFD40C8FA08 0 00000081 security-group-tag(893) 6 6-0015
*Oct 18 02:23:18.957: 7EFD40C8FA48 0 00000081 security-group-tag(893) 6 3-000c
*Oct 18 02:23:18.957: 7EFD40C8FA88 0 00000081 security-group-tag(893) 6 e-000c
*Oct 18 02:23:18.957: 7EFD40C8FAC8 0 00000081 security-group-tag(893) 6 a-000c
*Oct 18 02:23:18.957: 7EFD40C8F870 0 00000081 security-group-tag(893) 6 b-000c
*Oct 18 02:23:18.958: 7EFD40C8F8B0 0 00000081 security-group-tag(893) 6 7-000c
*Oct 18 02:23:18.958: 7EFD40C8F8F0 0 00000081 security-group-tag(893) 7 ff-000c
*Oct 18 02:23:18.958: 7EFD40C8F930 0 00000081 security-group-tag(893) 6 d-000c
*Oct 18 02:23:18.958: 7EFD40C8F970 0 00000081 security-group-tag(893) 6 2-000c
*Oct 18 02:23:18.959: 7EFD40C8F718 0 00000081 ssg-command-code(490) 1 36
*Oct 18 02:23:18.959:
*Oct 18 02:23:18.961: ++++++ Received CoA response Attribute List ++++++
*Oct 18 02:23:18.961: 7EFD40C8FF28 0 00000081 username(450) 12 #CTSREQUEST#
*Oct 18 02:23:18.961: 7EFD40C8FDD0 0 00000001 nas-ip-address(600) 4 198.18.133.254
*Oct 18 02:23:18.961: 7EFD40C8FE10 0 00000001 Event-Timestamp(445) 4 1602987802(5F8BA71A)
*Oct 18 02:23:18.962: 7EFD40C8FE50 0 00000081 security-group-tag(893) 7 16-001b
*Oct 18 02:23:18.962: 7EFD40C8FE90 0 00000081 security-group-tag(893) 7 14-001d
*Oct 18 02:23:18.962: 7EFD40C8FED0 0 00000081 security-group-tag(893) 7 12-0001
*Oct 18 02:23:18.963: 7EFD40C8FC78 0 00000081 security-group-tag(893) 7 10-0015
*Oct 18 02:23:18.963: 7EFD40C8FCB8 0 00000081 security-group-tag(893) 7 11-0016
 *Oct 18 02:23:18.963: 7EFD40C8FCF8 0 00000081 security-group-tag(893) 7 15-0019
*Oct 18 02:23:18.963: 7EFD40C8FD38 0 00000081 security-group-tag(893) 6 0-000c
*Oct 18 02:23:18.964: 7EFD40C8FD78 0 00000081 security-group-tag(893) 9 ffff-000d
*Oct 18 02:23:18.965: 7EFD40C8FB20 0 00000081 security-group-tag(893) 6 9-000c
*Oct 18 02:23:18.965: 7EFD40C8FB60 0 00000081 security-group-tag(893) 6 f-000c
*Oct 18 02:23:18.965: 7EFD40C8FBA0 0 00000081 security-group-tag(893) 6 5-000c
*Oct 18 02:23:18.965: 7EFD40C8FBE0 0 00000081 security-group-tag(893) 6 8-000c
*Oct 18 02:23:18.966: 7EFD40C8FC20 0 00000081 security-group-tag(893) 6 c-000c
*Oct 18 02:23:18.966: 7EFD40C8F9C8 0 00000081 security-group-tag(893) 6 4-000c
*Oct 18 02:23:18.966: 7EFD40C8FA08 0 00000081 security-group-tag(893) 6 6-0015
*Oct 18 02:23:18.966: 7EFD40C8FA48 0 00000081 security-group-tag(893) 6 3-000c
*Oct 18 02:23:18.967: 7EFD40C8FA88 0 00000081 security-group-tag(893) 6 e-000c
*Oct 18 02:23:18.967: 7EFD40C8FAC8 0 00000081 security-group-tag(893) 6 a-000c
*Oct 18 02:23:18.967: 7EFD40C8F870 0 00000081 security-group-tag(893) 6 b-000c
*Oct 18 02:23:18.968: 7EFD40C8F8B0 0 00000081 security-group-tag(893) 6 7-000c
*Oct 18 02:23:18.968:
CSR-Portals#7EFD40C8F8F0 0 00000081 security-group-tag(893) 7 ff-000c
*Oct 18 02:23:18.968: 7EFD40C8F930 0 00000081 security-group-tag(893) 6 d-000c
*Oct 18 02:23:18.968: 7EFD40C8F970 0 00000081 security-group-tag(893) 6 2-000c
*Oct 18 02:23:18.969: 7EFD40C8F718 0 00000081 ssg-command-code(490) 1 36

Step 8 To view the policy that the CSR-Portals has downloaded from ISE for TIER2Users (SGT 17), use the following
CLI command ‘show cts role-based permissions from 17’:
CSR-Portals#show cts role-based permissions from 17
IPv4 Role-based permissions from group 17:TIER2Users to group 20:PublicWebServers (monitored):

WEB_PORTALS-30
IPv4 Role-based permissions from group 17:TIER2Users to group 21:Tier1WebSites (monitored):

DENY_IPv4_with_Log-10
IPv4 Role-based permissions from group 17:TIER2Users to group 22:Tier2WebSites (monitored):

WEB_PORTALS-30
RBACL Monitor All for Dynamic Policies : TRUE
RBACL Monitor All for Configured Policies : FALSE

Step 9 The actual SGACL is displayed per policy within the above output. To display a list of the SGACLs and the
ACEs in each SGACL, use the following CLI command ‘show cts rbacl’:
CSR-Portals#show cts rbacl
CTS RBACL Policy
================
RBACL IP Version Supported: IPv4
name = WEB_PORTALS-30
IP protocol version = IPV4
refcnt = 9
flag = 0x41000000
stale = FALSE
RBACL ACEs:
permit tcp dst eq 80 log
permit icmp log

name = Permit IP-00

IP protocol version = IPV4
refcnt = 2
flag = 0x41000000
stale = FALSE
RBACL ACEs:
permit ip

name = DENY_IPv4_with_Log-10
IP protocol version = IPV4
refcnt = 5
 flag = 0x41000000
stale = FALSE
RBACL ACEs:
deny ip log

Step 10 Verify the remote-access VPN client (e.g. wkst1-CESA) now has the access to a Tier-1 site (e.g.
corporate-records.dcloud.cisco.com) by refreshing the web browser, when connected as a Tier-2 user (e.g.
employee).
Note This depends on Disable SGFW rules in ASA. Please ensure completing that section and use ASDM
to verify the SGFW rules are disabled.

TIER2Users has access to a records site (Tier-1).

Step 11 Go back to the WKST1-JUMP and the PuTTY window for CSR-Portals. Because of ‘terminal monitor’ and
because of the keyword log in SGACLs DENY_IPv4_with_Log and WEB_PORTALS, we should see acl
logging in the SSH session to CSR-Portal. Or we may check using the CLI command ‘show logging’. Below
shows some sample outputs:
CSR-Portals#show logging
Syslog logging: enabled (0 messages dropped, 3 messages rate-limited, 0 flushes, 0 overruns,
xml disabled, filtering disabled)
...
Log Buffer (4096 bytes):
*Aug 25 21:19:38.633: %FMANFP-6-IPACCESSLOGSGP: F0: fman_fp_image:
ingress_interface='GigabitEthernet1' sgacl_name='WEB_PORTALS-30' action='Permit'
protocol='tcp' src-ip='198.19.255.100' src-port='49747' dest-ip='198.20.11.56' dest-port='80'
sgt='17' dgt='20' logging_interval_hits='1'
*Aug 25 21:19:44.106: %FMANFP-6-IPACCESSLOGSGP: F0: fman_fp_image:
ingress_interface='GigabitEthernet1' sgacl_name='WEB_PORTALS-30' action='Permit'
protocol='tcp' src-ip='198.19.255.100' src-port='49758' dest-ip='198.20.11.55' dest-port='80'
sgt='17' dgt='22' logging_interval_hits='1'
*Aug 25 21:38:46.932: %FMANFP-6-IPACCESSLOGSGP: F0: fman_fp_image:
ingress_interface='GigabitEthernet1' sgacl_name='DENY_IPv4_with_Log-10' action='Deny'
protocol='tcp' src-ip='198.19.255.100' src-port='50284' dest-ip='198.20.11.54' dest-port='80'
sgt='17' dgt='21' logging_interval_hits='1'

Step 12 To monitor the hit on the SGACLs, use the following CLI command ‘show cts role-based counters from 17
to 21’:
monitor the hit on the SGACLs, use the following CLI command ‘show cts role-based counters
from 17 to 21’:
Secure Access
Secure Access 802.1x Differentiated Access 7
Network Security Policy Enforcement for Tier 2 Users 10
Network Security Policy Enforcement for Tier 1 Users 13
Demonstrating Tier Differentiated Access in ISE 15
Secure Access 802.1xDifferentiatedAccess
Value Proposition: Personal mobile devices such as smartphones and tablets have changed the way people work.
The user demand for Bring Your Own Device (BYOD) in the workplace has presented traditional network
deployments with quite a challenge. Personal mobile devices must be allowed to connect to the network securely.
Additionally, these mobile devices should only receive the appropriate level of network access. Cisco ISE has the
flexibility to offer many different solutions to the BYOD challenge, ranging from very simple to extremely complex,
depending on customer needs.
In this scenario, employees bring their own personal and mobile devices into the workplace to connect them to the
network:
• First connect the device to the open dCloud-Guest SSID and go through an onboarding process. The
onboarding process allows the user to register their device automatically with the ISE system.
• Once registered, the user will later be able to manage their personal devices through the ISE My Devices portal.
Additionally, during the onboarding process ISE will generate a digital certificate for the device using a built-in
certificate authority and issue the certificate to the user device along with a profile that instructs the device to
connect to the secured dCloud-Registered SSID.
• After onboarding, the user safely and securely connects to the secured wireless network using a digital
certificate for authentication.

• Upon joining the secured network, ISE dynamically assigns authorization policies for the user based on their
role, giving the user only the network access required.

Procedure

Step 1 Clear settings for each personal User BYOD Device used in the demonstration. If device settings are not
cleared, you may not be redirected to the guest portal or other pages when needed.
a) Clear Web Cache. [Show Me How]
b) Clear Personal Device Settings. [Show Me How]
 Note Perform Steps Step 2, on page 8 - Step 11, on page 10 if you have already completed the Device
Onboarding or Cisco ISE Guest Access Management demonstration. If you have not already
completed those guides, skip to Step 13, on page 10.

Step 2 FromWKST1-JUMP open Firefox, and log in to ISE at https://ise.securitydemo.netusing one of the following
methods:
• Manually typing the URL into the address bar.
• Click the ISE bookmark in the bookmark toolbar.
• Clicking the home button and clicking the ISE icon from the topology homepage.

Note Once you log into the CL-9800 GUI, it may take up to 2 minutes to fully load the main dashboard.
After the initial load, navigation to other screens should load quickly. Preload the dashboard prior
to customer presentations to avoid wait times during your demo. This performance behavior is being
investigated further for the next release.

Step 3 Login as admin/C1sco12345.

Example:

Step 4 Navigate to Context Visibility > Endpoints.

Step 5 Check off all endpoints and delete them.
Note If you encounter a problem deleting the endpoints, clear your browser cache and try again.
Example:
 Deleting Endpoints from ISE

Step 6 From WKST1-JUMP or your VPN connected management device connect to http://wlc1.dcloud.cisco.com
using one of the following methods:
• Manually typing the URL into the address bar.
• Clicking the bookmark for WLC1 in the bookmark?s toolbar.
• Clicking the home button in the browser to be brought back to the Topology diagram and clicking on
the vWLC.

Step 7 Log in to the vWLC using the same device specific credentials used to provision endpoints during demonstration
preparation.
Step 8 Click Monitoring > Wireless > Clients in the top menu bar.
Any clients that previously joined the demo network are listed.
Step 9 Check the box for the associated client and then click Delete.
Example:
Deleting a client from the C9800-CL

Step 10 FromWKST1-JUMP or your VPN connected management device and access the ISE login page at
http://ise.securitydemo.net using one of the following methods:
• Manually typing the URL into the address bar.
• Clicking the bookmark for ISE in the bookmark?s toolbar.
 • Clicking the home button in the browser to be brought back to the Topology diagram and clicking on
ISE.
Step Login to ISE using admin/C1sco12345 used to provision endpoints during demonstration preparation.
11 Connect the personal User Device to the secure network SSID: dCloud-Internal.
Step Enter the username and password for the selected Tier 2 user in the device supplicant (refer toTable 3:
12 Credentials and Access Levels, on page 4).
Step 14
13 When prompted, accept installation for certificates.
Notes For devices like Apple iOS its required to accept the certificates. We have installed a well-known
certificate, but Apple requires manual acceptance when first connecting. It is not something that we
have control over.
For more information on the client behaviors please check our Cisco ISE BYOD Prescriptive
Deployment Guide.

Step 15 Open the supported, built-in web browser on the personal User Device and browse to the Main Portal URL
(shown in Table 2: Available Portals, on page 4) for the selected scenario. Click Continue if you encounter
a security warning.

Network Security Policy Enforcement for Tier 2Users

The user device has been successfully connected to the network and should now have the appropriate levelof
access. Since the user is a Tier 2 user, they should have access to the Internet, the main portal URL for their
scenario as listed in Table 2: Available Portals, on page 4, and to internal resources for that portal. However,
they should not have access to the internal records of the portal.

Procedure

Step 1 Open the native browser on the user device and navigate to http://www.cisco.comto demonstrate that the user
has Internet access.
Step 2 Navigate back to the Main Portal URL associated with the selected scenario shown in Table 2: Available
Portals, on page 4 (i.e. health.dcloud.cisco.com).
a) Click the General Resources link in the upper left.
The user should have access to the general resources. Click the Home link to return to the Main Portal
URL

b) Click the Internal Resources link in the middle-left box.

The user should have access to the internal resources section of the portal.
c) From within the internal resources section, click the link for Internal Records.
Depending on the portal, this link may be named slightly different, for example, Corporate Financial
Records. The user should not have access. Click the home link to return to the Main Portal URL.
 Note The main portal pages for the four scenarios listed in Table 2: Available Portals, on page 4
differ only slightly. Each portal has the same basic layout: each has a General Resources link
accessible to all users, and an Internal Resources link for Tier 1 and Tier 2 users only. Once
inside the internal resources section, each portal has two links that are restricted to Tier 1 users
only. The Tier 1 onlyinternal recordslinks are listed below in Table 4: General/internal Resources
and Records per Portal, on page 11.
For purposes of this demonstration, do not explore the My Registered Devices link on the main
page at this time. That link will be covered later in this demonstration.

The main portal URL for healthcare at http://health.dcloud.cisco.com

Table 4: General/internal Resources and Records per Portal

Scenario General Internal Resources Internal Records (Tier 1

/Vertical Resources (All) (Tier1 & 2 Only) Only)
Healthcare For Patients and For Healthcare Medical Records / Insurance Server
Families Professionals
Education For Students and For Faculty/Educators Student Records / Student Contacts
Guests
Federal For Visitors For Federal Agents Background Records / Human
Resource Server
Corporate For Customers and For Corporate Employees Corporate Financial Records / HR
Guests Records

The next step will be to onboard a Tier 1 user device. If you plan to use the same device that you did for
Tier 2, you must go through the cleanup process below. If you use a separate device to onboard for Tier
1, the cleanup process is not necessary, and you can continue to the network security policy enforcement
for Tier 1 users section.
Note It is imperative that you follow the instructions below carefully. Because we have already gone
through another flow, ISE has already profiled the device, authenticated it, and authorized it.
In order to be successful with the next scenario, it is important that we remove the device
completely from ISE and the WLC as well as clear local device settings.

Step 3 Clear settings for each personal User Device used in the demonstration.
a) Clear Web Cache. [ShowMe How]
b) Clear Personal Device Settings. [ShowMe How]
Step 4 From WKST1-JUMP open Firefox, and log in to ISE at https://ise.securitydemo.netusing one of the following
methods:
• Manually typing the URL into the address bar.
• Click the ISE bookmark in the bookmark toolbar.
• Clicking the home button and clicking the ISE icon from the topology homepage.
Note Log in using the userid/password combination of admin/C1sco12345.

Step 5 Navigate to Context Visibility > Endpoints.

Step 6 Delete all Endpoints.
Note If you encounter a problem deleting the endpoints, clear your browser cache and try again.
Example:

Step 7 From WKST1-JUMP access the WLC login page at http://wlc1.dcloud.cisco.comusing one of the following
methods:
• Manually typing the URL into the address bar.
• Click the bookmark for C9800-CL in the bookmark toolbar.
• Clicking the home button in the browser to be brought back to the Topology diagram, and clicking on
the C9800-CL.

Step 8 Log intothe vWLC using the same device specific credentials used to provision endpointsduringdemonstration
preparation.
Step 9 Click Advanced in the upper right.
Example:

Step 10 Click Monitoring > Wireless > Clients in the top menu bar. Any clients that previously joined the demo
network are listed.
Step 11 Check the box for the associated client and then click Delete.
Example:
 Deleting a client from the C9800-CL

Network Security Policy Enforcement for Tier 1Users

We have seen how ISE dynamically provided access for a Tier 2 level user. Next, we will demonstrate how
ISE offers a different policy for Tier 1 users that includes access to the internal records.

Procedure

Step 1 Connect to the dCloud-Internal network again logging in as a Tier 1 user (refer to Table 3: Credentials
and Access Levels, on page 4).
For example, dean\C1sco12345. Accept and Trust Certificates if displayed.
Note Throughout the demonstration, you will be connecting to specific dCloud WiFi signals. While we
refer to them generically, they will all be appended with the unique session ID, for example,
dCloud-Internal-123456.

Step 2 Open the native browser on the user device and navigate to http://www.cisco.comto demonstrate that the user
has Internet access.
Step 3 Navigateback to the Main Portal URL associated with the selected scenario shown in Table 2: Available
Portals, on page 4 (i.e. health.dcloud.cisco.com).
Step 4 Click the General Resources link in the upper left box.
The user should have access to the general resources. Click the home link to be brought back to the Main
Portal URL.
Step 5 Click the Internal Resources link in the middle-left box.
The user should have access to the internal resources section of the portal.
Step 6 From within the internal resources section, click the link for Internal Records whereas a Tier 1 user, the
device should now have access to the internal records.
Example:
Internal Records for Education Portal
Internal Records Accessed
 Note For the name of the Internal Records page for each portal, see Table 4: General/internal Resources
and Records per Portal, on page 11.

Step 7 Click the Home link to return to the Main Portal URL.

Demonstrating Tier DifferentiatedAccess in ISE

You have demonstrated differentiated access with dot1x using both Tier 1 and Tier 2 access level
credentials. Next, you will look briefly at the ISE UI, to demonstrate the basics of how ISE dynamically
profiled the device, and dynamically allowed the proper level of access

Procedure

Step 1 On WKST1-JUMP, launch Firefox.

Step 2 In the Demo Devices section of the topology map, click ISE.
This will bring you to the ISE login page at https://ise.securitydemo.net.
Step 3 Log in with the username admin and the password C1sco12345.
Step 4 Select Operations > RADIUS > Live Logs. This screen displays the most recent authentications and
authorization attempts in ISE.
Example:
Operations > RADIUS Live Log
1. In ISE, we can see the history as our Tier 2 and Tier 1 users connected.
• Initially, the Tier 2 user connected and logged in as professor (Tier 2 user) in to the dCloud-Internal
and was authenticated/authorized using 802.1x secure access and was correctly profiled as an Apple
Device. ISE dynamically assigned the user the TIER2_WIRELESS_ACCESS authorization profile.
• The TIER2_WIRELESS_ACCESS profile returns the name of an ACL that is already preconfigured
on the WLC. This ACL allows the Tier 2 users to get to the main portal and internal portal, but not
internal records.

2. Similarly, we see exactly what happened as the Tier 1 user connected (consistency).
• We can see that this time the user logged in with the Tier 1 user dean.
• Because the professor is a Tier 1 user, ISE assigns the TIER1_WIRELESS_ACCESS policy.
• Similar to the TIER2_WIRELESS_ACCESS policy,this returns to the WLC the name of an ACL.
The Tier1ACL allows the user to access all portal resources, including internal records.
ISE and VPN
Remote-Access VPN with Differentiated Access 7
Network Security Policy Enforcement for Tier 2 Users 9
Network Security Policy Enforcement for Tier 1 Users 13
Demonstrating Tier-Differentiated Access in ISE 19
CredentialsandAccess Levels
Scenario / Vertical Username Password Access Level
Healthcare doctor C1sco12345 Tier 1 - Full Access
Healthcare nurse C1sco12345 Tier 2 ? Limited Access
Education dean C1sco12345 Tier 1 ? Full Access
Education professor C1sco12345 Tier 2 ? Limited Access
Federal captain C1sco12345 Tier 1 ? Full Access
Federal officer C1sco12345 Tier 2 ? Limited Access
Corporate manager C1sco12345 Tier 1 ? Full Access

Scenario / Vertical Username Password Access Level

Corporate employee C1sco12345 Tier 2 ? Limited Access
 • Remote-Access VPN with Differentiated Access, on page 7
• Network Security Policy Enforcement for Tier 2 Users, on page 9
• Network Security Policy Enforcement for Tier 1 Users, on page 13
• Demonstrating Tier-Differentiated Access in ISE, on page 19

Remote-Access VPN withDifferentiatedAccess

Procedure

Step 1 In the main dCloud topology, click the WKST1-JUMP image.

A context window opens showing you details of the VM, with a link to access using Remote Desktop (RDP).

Step2 Click the Remote Desktop link to open another browser tab into which the RDP session starts.
Step3 In the desktop on WKST1-JUMP, click either Chrome or Firefox.
Step 4 Click the ISE bookmark and click Sign In to log into the ISE server.
(The credentials Admin / C1sco12345 are already saved, so just click Sign In).
Example:
Step 5 Navigate to Operations > Radius > Live Logs and refresh the output.
Step 6 Log into wkst1-CESA over Console.
a) Return to the topology and click the wkst1-CESA image.
A context window opens showing you details of the VM, with a link to access using console.
b) To access wkst1-CESA click the screen, press the key enter and then, type the password C1sco12345
when prompted.
Example:

Step 7 Once on workstation desktop, click AnyConnect to initiate the VPN connection and then, when prompted,
click Connect Anyway.
Example:
 a) Enter the credentials of the table located at the beginning of the guide to log in to the VPN and set the
connection to a trusted network.
Any of the users in the table will work fine.

Step 8 Return to ISE after logging in through the AnyConnect and find information about the endpoint in ISE.

Step 9 Go to Operations > Radius > Live Logsand check the details of the endpoint.

Network Security Policy Enforcementfor Tier 2Users

The user device has been successfully connected to the network and should now have the appropriate level
of access. Since the user is a Tier 2 user, they should have access to the Internet, the main portal URL for
their scenario as listed in Available Portals, on page 4, and to internal resources for that portal. However,
they should not have access to the internal records of the portal.

Procedure

Step 1 To stop the python script, click the X in the left corner of the CMD windown to close it, if it is still running.

ISE andVPN
9
 a) On wkst1-CESA, open the native browser (either Chromeor Firefox) and navigate to http://www.cisco.com
or any other web page to demonstrate that the machine has Internet access.
Step 2 Open Chrome and navigate to the Main Portal URL associated with the selected scenario shown in Available
Portals, on page 4 (for example, federal.dcloud.cisco.com).
Vertical sites are bookmarked already within the wkst1-CESA.
a) In the left box, click the General Resources link.
Example:

You should have access to the general resources.

b) Click the HOME link to return to the Main Portal URL.

Example:

c) In the middle box, click the Internal Resources link.

Example:

You should have access to the internal resources section of the portal.
 d) In the internal resources section, click the link for Internal Records.
Depending on the portal, this link may be named slightly different, for example, Corporate Financial
Records or in this case Background Records. You should not have access.

e) Click the HOME link to return to the Main Portal URL.

Note The main portal pages for the four scenarios listed in Available Portals, on page 4 differ only
slightly. Each portal has the same basic layout: each has a General Resources link accessible to all
users, and an Internal Resources link for Tier 1 and Tier 2 users only. Once inside the internal
resources section, each portal has two links that are restricted to Tier 1 users only. The Tier 1 only
internal records links are listed in the following table. For purposes of this demonstration, do not
explore the My Registered Devices link on the main page at this time. That link will be covered
later in this demonstration.

Scenario General Resources (All) Internal Resources (Tier Internal Records (Tier 1
or 1 and 2 only) only)
Vertical
Healthcare For Patients and Families For Healthcare Professionals Medical Records or Insurance
Server
Education For Students and Guests For Faculty or Education Student Records or Student
Contacts
Federal For Visitors For Federal Agents Background Records or
Human Resource Server
Corporate For Customers and Guests For Corporate Employees Corporate Financial Records
or HR Records
The next step onboards a Tier 1 user device. You can use a different web browser than the one you did for Tier 2, or clean up
the history on the current browser.
Step 3 Log into ISE.
a) In WKST1-JUMP, click the ISE bookmark.
b) To log into the ISE server, click on Sign In.
The credentials admin / C1sco12345 are already saved.
Example:
Step 4 Delete the endpoints
a) In the top left of the dashboard, click the three lines.
Example:

b) Navigate to Context Visibility > Endpoints.

Example:
 c) To delete all endpoints, scrolling down and click the following options.
Example:
Note If you encounter a problem deleting the endpoints, clear your browser cache and try again.

Network Security Policy Enforcementfor Tier 1Users

We have seen how ISE dynamically provided access for a Tier 2 level user. Next, we demonstrate how ISE
offers a different policy for Tier 1 users that includes access to the internal records.

Note Make sure not to use your Cisco-provided laptop. Instead use a customer laptop or one of your lab machines.
 Procedure

Step 1 Connect to the ASAV.

a) In the session topology, go to Details > Session > Details > Public IP Addresses and locate the ASAV
entry.
Example:

b) Copy the public IP address of the ASAV and paste it in the search bar of the browser (in this case, Chrome)
then, click Advanced and then, click Proceed to 64.100.10.221 (unsafe).
Example:
 c) In the following screen, enter any of the Tier 1 or Tier 2 credentials from Credentials and Access Levels,
on page 4.
Example:

Step 2 Install and run Cisco AnyConnect.

a) To download Cisco AnyConnect to the local machine, click the blue option under Download & Install.
Note The installer autodetects the operating system of the machine, in this case, Windows.
Example:
 b) Follow the steps to install Cisco AnyConnect.
Step 3 After Cisco AnyConnect installs, run the program to connect to ASAV.
a) In the session topology, go to Details > Session > Details > Public IP Addresses and locate the ASAV
entry.
Example:

b) Paste the IP address into Cisco AnyConnect.

Example:
 c) Accept any security warnings.
Example:

Step 4 On your machine, open a browser and navigate to http://youtube.com.

This tests the connection and gives a good result.

Step 5 Navigate back to the Main Portal URL associated with the selected scenario shown in the table Available
Portals, on page 4.
For example, health.dcloud.cisco.com.
Example:
a) In the left box, click the General Resources link.
Example:

You have access to the general resources.

b) Click the HOME link to return to the Main Portal URL.
Example:
 c) In the internal resources section, click the link for Internal Records.
You have access to the internal resources section of the portal.
d) In the Internal Resources section, click the Medical Resources link.
As a Tier 1 user, the device now has access to the internal records.

Demonstrating Tier-DifferentiatedAccess in ISE

You demonstrated differentiated access with remote-access VPN using both Tier 1 and Tier 2 access level
credentials.
 Next, you briefly at the ISE UI to demonstrate the basics of how ISE dynamically profiled the device,and
dynamically allowed the proper level of access.

Procedure

Step 1 Return to WKST1-JUMP and then, on the desktop, click either Chrome or Firefox.
Step 2 Log into ISE.
a) Click the ISE bookmark.
b) Click Sign In.
The credentials admin / C1sco12345 are already saved.

Step 3 Select Operations > RADIUS > Live Logs.

This screen displays the most recent authentications and authorization attempts in ISE.
a. In ISE, we see the history as our Tier 2 and Tier 1 users connected.
• Initially, the Tier 2 user connected and logged in as officer (Tier 2 user) and was
authenticated/authorized using remote-access VPN. ISE dynamically assigned the TIER2Users
TrustSec Security Group.

• The TIER 2 User is allowed to access the main portal and internal portal, but not internal records.

b. Similarly, we see exactly what happened as the Tier 1 user connected.

• We see that this time the user logged in with the Tier 1 user (doctor).
• Because the doctor is a Tier 1 user, ISE assigns the TIER1Users TrustSec security group.

• The TIER 1 User is allowed to access all portal resources, including internal records.

Tiered Differentiated Access Tier 2

Tiered Differentiated Access Tier 1