ISE basic training

Posture

[email protected]
What is NAC
Network Admission Control (NAC) refers to Cisco's version of Network Access Control, which restricts access
to the network based on identity or security posture. When a network device (switch, router,
wireless access point, DHCPserver, etc.) is configured for NAC, it can 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 is enforced through an inline custom network
device, changes to an existing switch or router, or a restricted DHCP class. A typical (non-free) WiFi connection is
a form of NAC. The user must present some sort of credentials (or a credit card) before being granted access to
the network.
NAC components
cisco.com

High-level overview
Resources Download,
for example Posture updates,
AnyConnect pkg files Cisco cloud

Posture updates
Posture Configuration, download
Authentication/Authorization
configuration, Resources Upload

PAN
MNT

switches
Security Software
installed, Up to
Dot1X
date? MAB Configuration
Replication

USB stick is
connected?
WLCs Radius
Windows updates are
enabled? System is
up to date?
SSL ASAs

Disc encryption is IPSec

enabled?
Thick/Thin Routers
Agent Agent needs to contact PSN to get list of posture HTTPS
requirements. After evaluation of them agent needs to
report PSN about status for each requirement Ports 8443, 8905
Endpoints/Agents Policy Enforcement Point Decision Making Point
How Agent Can locate PSN?
1. Rely on Redirect* – similar to what we have with Guest access. At the moment when initial
authentication/authorization is done PSN can send access-accept with ‘redirect-url’ and ‘redirect-acl’ attributes
which would instruct NAD to intercept https/https packets originated by PC/Agent and redirect connection attempts
to the PSN
Access-Request

Dot1X/MAB Radius

Access-Accept
HTTP GET: google url-redirect=psn1…
redirect-acl=Posture
HTTP REDIRECT:
psn1…

TCP intercept

2. Rely on list of PSNs stored in Agent** – agent can have a special file which will have addresses of All PSNs in the
deployment so it should be possible to find the correct PSN even if redirection is not in place on NAD

* - would be covered in much more details on next slides,

** - question here always how to get this server list?
Posture process Key Milestones
1. Manual Agent installation – for thick agent it is possible to install Agent before device would be connected to the
network,

2. Initial authentication – result is normally restricted access, goal is to provision agent to the client and collect
posture data. Classically initial authentication should include redirect.

3. Client provisioning – agent suitable to client OS is selected and pushed back to the user. ISE is able to discover
device OS at time of redirect,

4. Actual posture – direct communication between agent and ISE to establish device compliance status,

5. Remediation – this step is executed only if device has been marked as ‘non-compliant’. As part of remediation
Agent can execute remediation actions defined on ISE,

6. COA – required to enforce new level of access,

7. After COA authentication – at this stage full access is normally provided.

Agents Characteristics
Anyconnect ISE posture Temporary Agent
Thick Agent – Installation required Thin agent – no installation needed, software is removed after posture process
finished

How to get agent: How to get agent:

- Provisioning from ISE when user is redirected for the first time - Provisioning from ISE when user is redirected
- Install manually using AC iso from cisco.com
- Centralized installation using Microsoft GPO or Microsoft SCCM or using any
other Enterprise software installation system

Required rights: Required rights:

- Installation from ISE and manual installation will require user to have Admin - EXE file which is downloaded from ISE each time when posture needs to
rights, happen. User does not need to have admin rights. Agent is executed in user
- From software distribution system agent can be installed with System Rights space
and later it will be executed with those rights. End user in such case may not
have Admin rights,
Compliance module support: Compliance module support:
- 3.x versions - 4.x versions
- 4.x versions Temp agent has Compliance module built in, if compliance module needs to be
updated then Temp agent version needs to be changed
Remediation support: Remediation support:
- Full remediation support (Antivirus Update, Windows Update and so one) - Remediation is extremely limited (File, URL, …) since program is executed in
user space

Note: There are two other agents available currently:

- Cisco NAC agent (Thick)
- Cisco Web Agent (Thin, Java/ActiveX based)
Those agents were announced for End-Of-Support on July 31, 2018 due to this they are out of scope of this training.
What is compliance module and Posture updates?
 Compliance Module is a database of Application (like Antiviruses, AntiSpyWare, Disk encryption + regular application like browsers, players and so one)
with corresponding list of actions that can be executed against them (for example AV update can be triggered, Browser can be closed and so one).
Compliance Module is used on the Agent side to dect what PC has installed/running. Corresponding actions are executed if remediation is needed.

Cisco Compliance module is using OESIS framework from OPSWAT for detection and remediation

https://www.slideshare.net/OPSWAT/introduction-to-oesis-framework

 Posture Updates – define on ISE side what can be configured as a posture policy. New updates brings to ISE knowledge about new AV products for
example along with latest definition versions* Define posture policy:
New Compliance
Module
Conditions -
OS=Windows, AND User from
AD group = IT New AV
New AV
Requirements - info
info
Symantec 15 INSTALLED Posture updates,
Compliance Module DB AND Cisco cloud
Symantec 15 UP_TO_DATE New
OESIS
version
New Compliance
Module
Symantec 15.x

New AV has been

released
Symantec 15 INSTALLED?
Symantec v15 Symantec 15 UP+TO_DATE

* - Definition Version – Version of Viruses/Malware/Spyware database in security products

AC Posture module architecture (Windows)
 AC posture module cannot be installed without VPN module. If needed VPN module UI can be hidden,
 AC posture uses VPN acvpndownloader to run an updates (install new compliance module, install new version of posture profile, and so one).
 IPC (Inter-process communication) is used for communication between different components. Commutation is done over loopback 127.0.0.1

Permanent IPC connections aciseposture.exe acvpndownloader.exe

On-demand IPC connections
Actual posture process Download of required
WinHTTP API calls Compliance including detection and updates when requested by
Module DB remediation other modules
:60014 Ports on which Services
accept connections from
other services :62523
IP of
psn1.example:com? Native
Windows internal calls
Windows
User login DNS
WinHTTP library client
:60012 http GET
:60014 psn1.example:com:8443
Standard Windows HTTP
Native
client library used by AC to
Windows
run actual communication
TCP/IP
stack
Actual Packet

aciseagent.exe vpnui.exe
acise.exe
Monitoring of events which GUI of Anyconnect
ISE discovery process
are leading to starting Interact with End User
Communication to ISE
discovery process Interact with other AC modules

:60014 :60010
End User
AC Discover relationship between modules
To see how AC modules are connected to each other we can use MS Process Explorer utility.

a. Lunch process explorer,

b. Find service which you would like to check and right-click on it,
c. Chose properties,
d. Navigate to TCP/IP tab
What does ‘Discovery’ mean and how to start it?
Discovery* is a process executed by AC posture to locate PSN where user/device has been authenticated. After correct PSN is located agent
will check for client provisioning policy on PSN (to see if any updates are needed) and will request posture requirements which needs to be
validated.

Discovery starts on:

 Initial AC posture module installation

 User login,
 Power events,
 Interface is going up,
 Return device from sleep,
 IP address change,
 Default Gateway change

Note: Dot1x authentication and PC lock/unlock are not triggering Discovery process.

* – Discovery process will be discussed in much more details on upcoming slides

Temporary agent does not need discovery.
Temp agent contacts PSN from which it was downloaded immediately after start
Session VS Endpoint attributes
During this training terms Session attributes and Endpoint attributes will be mentioned multiple times. This slide is to define meaning of this
terms and as well give an examples of them.

Session attributes – attributes which are collected by PSN during session life-cycle (authentication/authorization processes/COA). Attributes
can be collected from both external (AD, LDAP, Radius packet attributes, and so one) and internal sources (UseCase=GuestFlow, ISE Host
name/Device Type/Device Location and so one).

Session Attributes are available for making Authentication/Authorization/Client Provisioning/Posture decisions while session is ‘alive’ which
means that no Accounting-Stop has been received for the session yet.

Endpoint Attributes – attributes which are associated with specific endpoint (AKA MAC address) in the ISE database. Those attributes are
available to all PSN nodes for making an Authentication/Authorization/Client Provisioning/Posture decisions till the endpoint is presented in
the DB.

Examples of endpoint attributes: Device Identity Group, BYOD registration flag, MDM server name and so one,
ISE posture configuration components
From the components perspective ISE configuration for posture can be divided in the following parts:

 Client provisioning – configuration of resources, portals and client provisioning policies,

 Actual posture – posture components, conditions and policies,

 Authorization – authorization profiles, and policies for processing authentication before and after
posture.
Client provisioning Configuration
From client provisioning perspective the following task are need to be done:

a. Run posture updates,

b. Direct resources download from cisco.com to ISE (Compliance Module), Temporary Agent

c. AC package upload (.pkg) from Admin PC to ISE. Package itself needs to be manually downloaded by admin from
cisco.com (AC posture only),

d. AC posture profile configuration (AC posture only),

e. AC configuration creation (AC posture only),

f. Portal settings adjustment,

g. Client provisioning policy configuration.

a. Run posture updates
For this step ISE needs to have internet Access.

Navigate to Administration > System > Settings > Posture > Updates
Update type. Web is typically used. In case of Offline update internet
access on ISE is not needed. Update file needs to be manually obtained
from the server

URL contains XML file form which ISE can learn actual update location

Proxy server info, if defined on

ISE

Enable and configure automatic updates

Save Changes/Update Now/Reset Changes

Current Posture update status:

Cisco Conditions – DB of posturee conditions created by Cisco, for

example Set of critical MS KBs for a given MS OS version

AV/AS version for Win/MAC – version of DB with AV/AS names and

definition versions,

Cisco OS version – version of DB with Browser User-Agents which are

used by client provisioning Sub-System to detect OS type/version on the
endpoint. This DB is independent from profiling Sub-System
a. Run posture updates – Define a proxy server
To define a proxy server Navigate to Administration > System > Settings > Proxy

Current example contains CALO Proxy Server IP/Port which needs to be used in CALO Brussels lab
b. Direct resources download from cisco.com to ISE
Following resources can be downloaded from cisco.com directly to ISE:

 Temporary Agent – normally ISE has pre-downloaded temp Agent, if needed newer version can be downloaded,
 Compliance modules for Windows/MAC – ISE does not have pre-downloaded compliance modules,

Currently two types of compliance modules are available:

3.x – older version of OESIS framework, still under development but in the future will be fully replaced by 4.x
4.x – newer version of OESIS framework which support advanced posture checks like: USB, Application visibility and so one,

Posture conditions, Posture requirements and Posture policies are compliance module aware in ISE

Go to Policies > Policy Elements > Results > Client Provisioning > Resources

Press Add > Agent Resources from Cisco site

Select in the list resources which needs to be downloaded and press Save
c. AC package upload (.pkg) from Admin PC to ISE

Below path can be followed on https://software.cisco.com/download/home do download latest version of AC

Downloads Home / Security/ VPN and Endpoint Security Clients / Cisco VPN Clients / AnyConnect Secure Mobility Client / AnyConnect Secure Mobility
Client v4.x /

Save file locally and then navigate on ISE to Policies > Policy Elements > Results > Client Provisioning > Resources

Press Add > Agent resources from local disk

Choose ‘Cisco Provided Package’ in the category

Press ‘Browse’ and navigate to PKG file on your machine

Press submit and confirm package hash when prompted

d. AC posture profile configuration
AC posture profile is an XML file which contains import posture agent settings. Profile is provisioned to the Agent at time of the first
connect (if Agent has been installed manually), or it is pushed along with AC if agent is provisioned from ISE directly.

Internally file has version ID (invisible to ISE admin) and in case of adding any changes to the file on ISE upon next connection attempt
agent will download new version of file.

To create AC posture profile go to Policies > Policy Elements > Results > Client Provisioning > Resources

Press Add > NAC Agent or AnyConnect Posture Profile

Select category ‘AnyConect’

d. AC posture profile configuration - continue
Profile minimum requirements:

 Profile name has to be defined,

 Server name rules has to be define,

Server name rules define to which servers (ISE PSNs) agent allowed to connect. Value here is normally FQDN wildcard. For example
*.example.com will cover psn1.example.com, psn2.example.com and so one, bout would not cover psn1.security.example.com

Validation is done against CN/SAN in PSN certificate during discovery process.

Profile best practice:

As a best practice it is better to disable IP address refresh if Dot1x is used for authentication (ip address change in such scenario
monitored by supplicant). If client authenticated by MAB and VLAN has to be changed after moving to ‘Compliant’ state for example then
we have to keep ‘IP address refresh’ enabled

Some other settings in profile will be discussed later

e. AC configuration creation
AC configuration define which modules would be pushed from ISE to machine.

Fro each module we can specify corresponds XML configuration file. For posture module
configuration can be created on ISE itself. For all other modules you can use corresponding
AnyConnect Profile Editor locally on your PC (for example ‘VPN profile Editor’ to create VPN XML
profile), then profiles can be uploaded to ISE using Add > Agent resources from local disk and
choose Customer Created Packages in category during upload:

To create new AC configuration navigate to Policies > Policy Elements > Results > Client
Provisioning > Resources

Press Add > AnyConnect Configuration

Choose AC package version

e. AC configuration creation - continue
Define configuration name

Choose compliance module version

Specify which modules have to be installed:

ISE posture cannot be ‘unchecked’
VPN can be unchecked but since it is a core
module would be installed any case

Specify which Profiles have to be used for modules

ISE posture profile has to be defined, other are
optional

Note:

In case of posture over VPN AC cannot be updated if ISE has higher AC

pkg version then ASA

Lower in the profile we can define update settings if needed

f. Portal settings adjustment
During posture two main type of portals can be used at time of user redirect:

 Client Provisioning Portal (CPP) – if user reaches this portal as a result of redirect no authentication required on the portal itself*. Main goal of the portal is
to decide which Client Provisioning policy needs to be applied to this specific User/Device by taking User-Agent attribute value from HTTP Request (to
detect OS of the device) and by taking session-id value from URL accessed by the user to get all required session attributes (for example AD groups)
Session ID value from URL. Browser getting it from the NAD at the moment of Redirect

Start Button to initiate Client Provisioning process. Flow itself is self-explanatory

ISE has built-in ‘Client Provisioning Portal (default)’, which you can
User-Agent Value which Browser place in HTTP request.
find by navigating to
To see value in Real-Time you can enable
Administration > Device Portal Management > Client Provisioning ‘Web Developer Mode’ in Firefox, navigate to HTML tab
and then investigate ‘Headers’ sub-tab
CPP is normally used with Dot1x based authentication since we do
not have authentication on this portal by default so we redirect user
to CPP when it has been already authenticated by Dot1x.

CPP very rare used with guest flow when guest user needs to get AC Posture as an agent

Normally if you do not wish to change color schema or logo on CPP we can leave portal unmodified.

* - Authentication on CPP will be discussed in section related to posture without redirect

f. Portal settings adjustment - continue
 Guest Portal – posture can be executed as part of the Guest-Flow. This can be done on ‘Self-Registered’ and
‘Sponsored’ guest portals. ‘Hot-Spot’ portal is not supported for posture.

Posture inside of the Guest-Flow facts:

 Only one check box needs to be enabled in portal settings,

 Only Temporary Agent is supported in client provisioning results when posture is triggered on the guest portal,
 AC posture can be used if two redirects are triggered: 1. Redirect to Guest portal, 2. Redirect to CPP portal after
COA,
 Do not use VLAN change in the authorization profiles for Guests (like authorization profile with redirect has VLAN
10, and compliant authorization profile has VLAN 20) since when MAB is used endpoint cannot detect VLAN change,

Enable posture on the guest portal

Navigate to Work Centers > Guest Access > Portal & Components > Guest Portals

Open portal on which you would like to enable posture and navigate to section ‘Guest Device Compliance Settings’

After posture is enabled two additional components are added to the portal ‘block diagram’ on the right
g. Client provisioning policy configuration.

To define client provisioning policies navigate to Policy > Client Provisioning

All modern ISE versions are having built-in client provisioning policies for all supported OSs. To adjust built-in policy according to your needs press ‘Edit’ near
policy which you would like to change

To create a new policy press on and choose where new policy needs to be placed

Main Client Provisioning policy configuration components:

User/Endpoint Identity Group Endpoint OS Conditions like: What needs to be pushed back to
Policy Name client
(Internal ISE groups) ISE filters available External AD group,
resources in ‘Result’ section For posture it would be:
based on OS selected here Wireless WLAN Number
Policy status Enabled/Disabled/Monitor Standard Radius attributes taken AC configuration name
from session OR
And so one Temporary Agent file
Client Provisioning policy example for AnyConnect

This policy would be applied to users which were authenticated using PEAP and belong to AD group ‘Domain Users’ when connection is made from Windows
Device
Posture Configuration
The following configuration tasks needs to be executed from posture perspective

a. Define posture conditions – In posture conditions we specifying what exactly Agent would be looking on the device
like AV vendor/version installed, AV definition versions, Patch Management Vendor, File, Registry Key and so one

b. Define remediation actions – remediation actions describes what Agent needs to do when specific requirement is
not met. For example redirect user to internal web-site when AV is not installed, Push AV to update if definition
version is to old, Push some file from ISE to the device and so one,

c. Define posture requirements – posture requirement is an interconnect between Condition and Remediation. In
requirement we need to choose specific condition and choose what exact remediation needs to be executed if
condition is not met

d. Define posture policy – policy defines which requirements should be evaluated when specific conditional are met.
Example of conditions – User belongs to certain AD group, User connected to specific WLAN and so one,
Condition
My_AV_Check Policy
Check for Symantec Requirment My_AV_Policy
15.x installation My_AV_Requirment Conditions:
Check for My_AV_Check AD Group=IT AND EapAuthentication=EAP TLS
Remediation If Failed run AV_not_installed Result
AV_not_installed My_AV_Requirment
Redirect user to
http://software.example.com
a. Define posture conditions
You can locate posture conditions by navigating to Policy > Policy Elements > Conditions > Posture
CM 4.x only. Section to define security (AV/AM/AS) software conditions. Starting from OESIS framework 4.x AV/AS/AM were placed in the same
category called Anti-Malware

CM 3.x only. Section to define Anti-Spyware software

CM 3.x only. Section to define Anti-Virus software

Application visibility conditions are available for CM 3.x/CM 4.x In case of 3.x administrator needs to manually specify a process name (ex:
firefox.exe). Condition can check if process is in Running state or not. For 4.x CM OESIS has list of popular application already. Condition
additionally can check if application is installed

Compound conditions can include following condition types: File/Registry/Service/Application with the logic like AMD/OR/NOT applied between
them
CM 3.x/4.x, List of supported disk encryption product depend on selected CM
version
CM 3.x/4.x, Check File properties like: FileExist, FileData/FileVersion and so
one

CM 3.x/4.x, Check of Firewall software presented/enabled

CM 3.x/4.x, Check Installation/If Enabled/If up to date for patch management products

CM 3.x/4.x, Windows only. Check presence/Value of specific Registry keys

CM 3.x/4.x, Check if specific service is running. For example Microsoft Windows defender has the following Service name - WinDefend

CM 4.x and Windows only. Built-in condition to check if endpoint has USB
device attached

CM 3.x/4.x, Built-in condition to collect hardware inventory

Conditions which can be used in posture policies itself. Analog of Authorization policy Simple and Compound conditions
a. Define posture conditions – AM condition example
Define an Anti-Malware condition. Same logic can be applied for AS and AV conditions

For user convenience we have a a following default conditions which become available after posture update:

 ANY_am_win_inst – check for ANY windows anyti-malware software installed

 ANY_am_win_def – check for ANY AM definition database presented in the endpoint. Definition check allows definition database to be maximum 5 days
older then current system time,
 ANY_am_mac_inst – same for MAC OS, installation
 ANY_am_mac_def – Same for MAC OS, definition

To create your own rule press on Add

Search can be used to find exact vendor
Define Condition name

Select OS. List of available products depend on selected OS

Choose vendor of the AM product

Select what needs to be validated: Definition or Installation

a. Define posture conditions – AM condition example continue
In case if Definition check is selected following options are available
If this option is selected Definition file version on the endpoint would be first compared with value in ‘Latest
Definition Version’ column. In case if this column is empty on ISE then definition file date on the endpoint would
be compared with value available in the ‘Latest Definition Date’ column.
Since ISE is not getting knowledge of new Definition Version/Dates immediately this approach can be used in
environments where AM updates are well controlled

Definition file on endpoint can be

Allows definition file on the
older then latest definition file
Allow definition version be older endpoint be older than system
date in column ’Latest Definition
data on the ISE
Date’
a. Define posture conditions – Registry Condition
Registry condition can validate: Presence of specific registry Key, Value of specific registry Key and Default value of specific registry key.

Registry conditions are extremely powerful instrument to check a lot of things inside of windows operation system. Below is example shows how to check if
windows PC is member of specific Active directory domain. Exact key value has bee taken from here:

https://arstechnica.com/civis/viewtopic.php?t=42713 How to get Key value in Windows:

Start > Run > regedit

Navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\Domain
a. Define posture conditions – Service Condition
One of the best conditions for the posture testing in the lab is Service condition.

As a test service we can user Windows Defender which can be easily stopped/started to recreate non-compliant scenario.

Service name for Windows defender is -

b. Define remediation actions
You can locate Remediation Actions by navigating to Policy > Policy Elements > Results > Posture > Remediation Actions
4.x CM Application visibility remediation. Can be used to ‘Uninstall’ or ‘Kill Process’ along with Application condition specific to
CM 4.x where ‘Application’ has been selected instead or ‘Process’

3.x/4.x CM remediation for corresponding Conditions. As a remediation action AV/AM/AS product can be pushed to install
updates. Important – Updates are downloaded by AV/AM/AS product itself from the corresponding update server not form ISE.
Those remediation type can be used with conditions where ‘Definition’ is validated. Important if AV/AS/AM product is not
installed we cannot ‘update’ it

3.x/4.x CM remediation to push any fine from ISE To the endpoint. Can be used to push installation file of anti-virus for example

4.x CM remediation to enable Firewall on the endpoint. Can be used as remediation with Firewall Conditions created for CM 4.x

3.x/4.x CM remediation to run specific program on the endpoint. Can be used for example with AV/AS/AM installation checks to
launch some enterprise software management program on endpoint

3.x/4.x CM remediation to redirect user to specific URL

3.x/4.x CM remediation for patch management products conditions. PM product can be Enabled or Updated. So those
remediation's can be used with conditions of corresponding type. Important If PM product is not installed we cannot Update it or
Enable it

4.x CM built-in remediation to disable USB

3.x/4.x CM remediation to update system when Microsoft WSUS is used in enterprise to distribute patches

3.x/4.x CM remediation to change Windows update agent settings – For example enable automatic
updates
c. Define posture requirements
Posture requirements can be created by navigating to

Policy > Policy Elements > Results > Posture > Requirments

In modern ISE version you would see bunch of popular requirements preconfigured for you already with corresponding remediation's. If user end goal is to
check AV/AS/AM installation definition then default Requirements can be used. As a remediation for failed installation checks ISE uses ‘Message Text Only’

To create new requirement press on near existing requirement and select ‘Insert new requirement’

Choose your posture type:

Anyconnect – standard approach when posture module is visible to end-user
Anyconnect Stealth – posture module is invisible to user and operates in background. This affects types of
remediation's which can be launched
Temporary – if Temp agent is used amount of remediation's is very limited

Choose
Choose Condition
Remediation

Define Remediation Name Select CM version

Select OS type
Only conditions/remediation for selected OS
would be available in corresponding columns
 d. Define posture Policy
To define posture policy navigate to

Policy > Posture

There are a lot of preconfigured popular policies which needs to be just enabled.

Posture policy match facts:

 When multiple policies are matching particular session (for example you have couple if policies which contain only OS Windows All and no other
conditions) then all policies are applied and endpoint has to be compliant with All mandatory requirements from All matched policies to become
compliant,
 When we have no match in posture policies for specific session ‘Compliant’ status is granted automatically,
Choose your posture type:
To add your policy press on. next to the existing policy and choose your action Anyconnect

OS type Anyconnect Stealth

Posture policy name
Temporary

User/Endpoint Identity Group Conditions like AD group and

CM version so one
(Internal ISE groups)
Mandatory – Condition has to be
evaluated to true otherwise session is
marked us ‘non-compliant’
Optional – user is notified but no Multiple posture
actions are needed, requirements can be
Audit – user is not notified, only ISE added. Logic between
reports would show that condition then is always AND
check failed
Authorization
On this stage Authorization profiles and Authorization policies have to be created:

a. Authorization profiles – in simple scenario only authorization profile for ‘Unknown’ posture status needs to be created. When this
authorization profile is applied user is either redirect to CPP (user authenticated by Dot1x or Guest Portal with CPP chaining) or to the
Guest portal with ‘Posture’ enabled,

b. Authorization policies – again in the simple scenario only two authorization polices are needed to get working posture flow:

 “Unknown” authorization policy – can contain whatever conditions you want plus “session-posture status”, the best way to cover all
scenarios is to use “session-posture status un-equal to Compliant”, this policy should contain “Unknown” authorization profile

 “Compliant” authorization policy – same conditions as in “Unknown” just session posture status is equal to “Compliant”

Unknown Authorization policy should be normally placed under the Compliant authorization policy

Endpoint is moving between policies after ISE can determine posture status
(This is happening after posture software on end user device reported
status to ISE). COA is used to force new authorization policy.
a. Authorization profiles
To create and authorization profile navigate to

Policy > Policy Elements > Results > Authorization > Authorization Profiles

Press Add to create a new profile

Profile with redirect facts:

 Access-Type has to be Access-Accept,

 DACL can be specified for scenarios when Wired Switch process Redirect ACL before Interface ACL (see further slides for details)
 Web-Redirection has to be enabled with type Client-Provisioning (Posture) for CPP redirect and type Central Web Auth for guest portal redirect,
 After Web-Redirection has been enabled you have to specify Redirect ACL name (needs to exist on NAD) and portal name

Profile with CPP redirect example:

Profile for Guest redirect example

b. Authorization policies - CPP
This slide is to give an example on how authorization policies can look like. Authorization policy configuration is outside of this
presentation scope.

2.3 Policies for CPP flow

b. Authorization policies - Guest
2.3 Policies for Guest posture flow
b. Authorization policies – Redirect chaining
Endpoint compliance status and ISE session processing
Posture status like ‘Compliant’/’Non Compliant’/’Pending’ is a session attribute so it is extremely important to understand how sessions are processed in
ISE deployment.

There are two ISE personas which are responsible for session processing -

PSN – this persona is responsible for:

 Decision making during authentication/ authorization (identity store selection/authorization policy selection),
 Logging of authentication result – Syslog message is transferred to Primary/Secondary MNT node upon Access-Accept or Access-Reject,
 Logging of accounting activates – Syslog message is transferred to Primary/Secondary MNT node upon receiving of Accounting-Start, Accounting-
Stop, Accounting-Update,
 Storing session along with all session attributes in the local session cache starting from Access-Accept till Accounting-Stop,
 Removal of the session from the session-cache after Accounting-Stop is received,
 Removal of the sessions from session cache if max.session.limit is reached (15k or 20k session depend on the ISE platform). In such scenario PSN use
special mechanism called similar to LRU (Least Recently Used) to locate sessions which can be removed to process new requests,

MNT – this persons is responsible for:

 Storing session with status ‘Authenticated’ in Live Sessions DB if only Syslog on Access-Accept has been received from PSN,
 Storing session with status ‘Started’ if PSN sent both Access-Accept and Accounting-Start syslog messages,

 Removal of ’Authenticated’ sessions from Live Sessions DB after 1 or 2 hours (depend on ISE version)
 Removal of ’Started’ session after Syslog for Accounting-Stop, or 5 days after last Accounting activity
ISE session processing how it works Live Sessions*
Username MAC Address Posture Status Status

Access-Request bob AA:AA:AA:AA:AA:AA Authenticated

Started
Authentication
Authorization
Access-Accept Syslog
Bob
Access-Accept
Bob AA:AA:AA:AA:AA:AA
Primary
Accounting-Start Syslog MNT
Accounting-Start
Accounting-Response Bob AA:AA:AA:AA:AA:AA
AA:AA:AA:AA:AA:AA
Sessions Cache*
Username MAC Address Posture Status
bob AA:AA:AA:AA:AA:AA

Accounting-Stop

In situation when Accounting-Stop for the session has not been delivered to the PSN where session was actually started we are getting a phenome of ‘Stale
Session’

‘Stale Session’ is a session which stuck in PSN session cache and can be removed only if PSN reach max. session limit (15K/20K) and this particular session will
be selected by LRU algorithm,

Common reasons to get a ‘Stale Session’ :

 Accounting-Stop message has not been delivered due to any kind of network issues,
 Customer has a wrongly configured Load Balancer in place and Accounting-Stop has been delivered to the wrong PSN.

* - Both Live Session and Session cache are having much more attributes associated with session (Authorization Policy/AD domain/…), in this example only
Username/MAC address/Posture status are mentioned for the slide simplicity
Cisco Redirect general logic

As a result of authentication ISE returning Access-Accept message with two specific

AV pairs if Authorization profile with redirect action being selected:
 url-redirect-acl – name of ACL that should exist locally on NAD, this ACL instruct
NAD which traffic should be redirected to ISE (only http/https can be redirected)
and what traffic should cross NAD without redirection
 url-redirect – normally PSN fqdn (client need to have possibility to resolve it) +
portal id + session id

When client initiate http session NAD is intercepting and returning

url-redirect as new page location
Redirect best practices Wired

 http server – enabled, default port 80 should be used except situation when proxy
is involved
 IPDT – enabled, IP device tracking is critical component for applying ACLs,
(required for multi-domain and maulti-auth)
 SVI in client subnet - otherwise traffic flow between client and switch need to be
planned very carefully
 DACL and redirect ACL – tricky question, will be covered on next slide separately
Switch interaction between different ACLs types
 Legacy Switches (3750/3560) On Legacy platforms first DACL
Redirect URL and Port ACL are validated, if
And http/https traffic permitted it will be
checked by redirect ACL.

And non http/https

DACL
Redirect ACL
Port ACL

 Modern Switches (3850/3650)

Redirect URL On modern switches Redirect
And http/https
ACL is taking precedence but all
packets which passed redirect
ACL should be checked by
DACL/Port ACL as well.
And non http/https
Redirect DACL
ACL Port ACL
Examples

Enable http server

Check if IPTD enabled and

IP been learned

SVI in client subnet to avoid issues

with asymmetric traffic
10.1.1.1/24
10.1.1.101/24
Redirect best practices Wireless

 AAA override enabled – this will allow WLC to apply Redirect ACL and Redirect URL
to client
 NAC=Radius NAC/ISE – without this option COA won’t be supported for WLAN,
and this will prevent applying of redirect attributes
 Redirect ACL/Airspace ACL – the same recommendation as for switches.
Protection provided by redirect ACL is enough
Posture flow with Cisco Redirect
In explanations below we assume that user has no posture agent installed so we are starting
from the initial client provisioning phase, if posture agent already installed this phase is skipped

NADs ISE PSN DNS

Client

Dot1x/MAB/VPN authentication Radius Authentication

1 2
Redirect ACL Example(WLC/SW/ASA):
(deny) permit tcp any any HTTP
Authorization policy selection.
(permit) deny udp any any DHCP Matched policy should contain posture condition (ex: Unequal to
(permit) deny udp any any DNS Compliant or equal to Unknown)
(permit) deny ip any host PSNs Authorization components:
(permit) deny ip any host Remediation servers Web Redirection (must) – type client provisioning (posture)*
DACL example (SW/ASA): ACL (must) – name of redirect ACL defined on NAD
permit tcp any any HTTP DACL (optional) – name of DACL defined on ISE
permit udp any any DHCP Access-Accept
permit udp any any DNS 3
permit ip any host PSNs
redirect-url=https://psn_fqdn:8443/session-id_cpp
permit ip any host Remediation servers
redirect-acl=acl_name
dacl=DACL_name
Redirect in action
NADs ISE PSN DNS
Client

Access-Request/Access-Accept for DACL

if needed
User opens any web 4
page NAD applies DACL and redirect ACL to session
For switches – endpoint IP address should be
presented in IPDT

DNS request ex: google.com

DNS traffic needs to be excluded from 5
DNS reply = IP
redirection and permitted in DACL

TCP SYN to google.com IP, des_port=80

6 HTTP intercept on port 80
TCP SYN-ACK from google.com IP, src_port=80 Web server must be enabled on port 80
7
TCP SYN –ACK to google.com IP, des_port=80
End of three way handshake
8
HTTP GET goggle.com
9
Destination goggle.com IP

HTTP Response code 302 redirect = redirect-url

10
OR
HTTP Response code 200 with location header=redirect-url
Redirect when switch has not IP in user VLAN
This scenario is potentially problematic as switch cannot send packets directly to the end user device,
instead switch will use underlying routing to route packet back to the client
SVI VLAN 10 SVI VLAN 10 SVI VLAN 100
10.1.10.10 Default route >>> 10.1.10.1 10.1.10.1 10.1.100.1

Access Port Trunk Vlans 10,100

Vlan 100

TCP SYN to google.com IP, des_port=80

6 HTTP intercept on port 80
Web server must be enabled on port 80

TCP SYN-ACK from google.com IP, src_port=80

7
VLAN 10 TAG Route the packet
TCP SYN-ACK from google.com IP, src_port=80 TCP SYN-ACK from google.com IP, src_port=80
7 7
VLAN 100 TAG

At the intercept stage here switch needs to decide how to route packet back to the client, as we have no direct reachability spoofed
packed will be sent to DG. This approach may have problem when next L3 device is doing state -full packet filtering as initial SYN packet is
not delivered to next hot so session state cannot be created.
Client provisioning and Network Setup Assistant download
NADs ISE PSN DNS
Client

11 DNS traffic needs to be excluded from

redirection and permitted in DACL

SSL connection to redirect URL over port 8443

12 13
Connection protected by Client Provisioning portal certificate

Client provisioning policy check:

Policy check is based on:
User Agent – retrieved from GET request, used for OS
type and Agent type selection
Session ID – retrieved from redirect URL, ISE uses this
value to get all session data (AD /LDAP groups, Network
Device Type/Location and so one)
Agent Download link presented to client. User
14 downloads Network Setup Assistant
Client provisioning Network Setup Assistant process
NADs ISE PSN DNS
Client

15
First NSP probe is an HTTP GET to default gateway IP. (Redirect URL expected as a result)
Note: In case of VPN connection with MAC OS this probe skipped as MAC-OS doesn’t support DG on VPN
16

HTTP GET Destination Default Gateway

Probe 1

Second NSP probe is an HTTP GET to enroll.cisco.com (Redirect URL expected as a result)
Note: enroll.cisco.com should be successfully resolvable over corporate DNS, in case of VPN connection
17 traffic to enroll.cisco.com should be routed through the tunnel

Probe 2 DNS request enroll.cisco.com

HTTP GET Destination enroll.cisco.com DNS reply = IP

AnyConnect SSL connection to redirect URL over port 8905

18
Installation Connection protected by ISE Admin certificate
Posture and ISE in .local

For a quite long time using of Generic top-level domains like .local, .lan, .corp, etc
was recommended. Now this domains are being sold by ICANN and using of them are
no longer recommended.
But –
Still a lot of companies are using such domains either because it historically
happened
Or
We’re still using old good “best practices”
.local continue
Everything looks fine for corporate users, all domain PC have corporate CA certificate in trusted
store, internal DNS can successfully resolve any .local FQDNs
But sooner or later guest will come, and guest cannot trust to .local certificate Corporate CA

CN=ca.xyz.local
Issuer – Corp CA

CN=pc1.xyz.local
Issuer – Corp CA Assign to
Guest Admin/Portal/EAP
CWA CN= psn1.xyz.local
Issuer – Corp CA

psn1.xyz.local
Domain PC Posture
G0

dot1x
Admin certificate, redirect and two interfaces (CPPuse case)

Portal Certificate Admin Certificate

CN= cpp.xyz.com CN= psn1.xyz.com
Issuer - VeriSign Issuer – ca.xyz.com
Connection to CPP Portal
Do I trust
VeriSign
Do CN/SAN psn1.xyz.com
match FQDN Access-Request G1 G0
guest1.xyz.com
Access-Accept
url=cpp.xyz.com

Connection 8905
CN from
Certificate
doesn’t match
FQDN

Recommendation – Add FQDN of second interface as SAN to Admin certificate

AC posture discovery process NADs ISE PSN
Client DNS

19
All probes are sent
simultaneously

AnyConnect
Posture module
starts
HTTP GET Destination Default Gateway
Probe 1
Redirect expected DNS request enroll.cisco.com
DNS reply = IP

HTTP GET Destination enroll.cisco.com

Probe 2 Redirect expected
20

HTTP GET Destination Discovery Host

Probe 3 Redirect expected
DNS request PSN FQDN
DNS reply = IP

SSL over port 8905 to previous PSN if any Session lookup based on
Probe 4 information in request
No redirect expected
IPs/MACs list

Note: Starting from AC 4.4 this stage has a 5 seconds timeout. Result from probe 4 would only be used if probes 1-3 failed
Stale sessions and posture Live Sessions*
Username MAC Address Posture Status Status
Probe Bob you are compliant
3 Access-Request bob AA:AA:AA:AA:AA:AA Compliant Authenticated
Started
Authentication
Authorization
Access-Accept Syslog
Bob
Access-Accept
Bob AA:AA:AA:AA:AA:AA
Primary
Accounting-Start Syslog MNT
Accounting-Start
Accounting-Response Bob AA:AA:AA:AA:AA:AA
AA:AA:AA:AA:AA:AA
Sessions Cache*
Username MAC Address Posture Status
bob AA:AA:AA:AA:AA:AA Compliant

Probe Accounting-Stop
1

Probe Access-Request
Authentication
2 Authorization
Access-Accept Result CPP redirect
Customer configured switch improperly
so All probes which relies on redirect are
Probe failing
3

Sessions Cache*
Username MAC Address Posture Status
bob AA:AA:AA:AA:AA:AA Pending
AC posture process NADs ISE PSN
Client DNS

SSL exchange on port 8905 Client Provisioning Policy

Connection protected by ISE Admin certificate
24 AC configuration Download
selection

SSL exchange on port 8905

25 Updates Download and Installation if needed
Connection protected by ISE Admin certificate

SSL exchange on port 8905

Posture module sends information about
OPSWAT Calls 26 Posture
Connection protected by ISE Admin certificate system. ISE providing posture requirements
Policy selection

SSL exchange on port 8905

Posture module sends report.
27 Status returned from ISE, PRA if time if Compliance status
Connection protected by ISE Admin certificate
OPSWAT Calls configured Check
Going to Full access NADs ISE PSN
Client DNS

Session status updated with new posture status

Posture lease value written to the endpoint if
configured
CAO Request
28
COA ACK
Dot1x/MAB/VPN authentication Radius Authentication
29 30

Authorization policy selection.

At this stage ISE can use new posture status “Compliant”
to apply full access policy
Access-Accept
31
Posture and Cisco COA types
For the Cisco NADs (Network Access Devices) two main COA types are in use after
successful posture:

 COA Reauth – this type of COA is used for Wired and Warless NADs, as a result of
successful COA NAD will initiate full authentication process. During this process
NAD keeps same audit-session id which allows ISE to apply new authorization
policy.
 COA Push – this type of COA are used by ASA for posture over VPN use-case. At
time of posture over VPN re-authentication is impossible as it will cause
disconnect for end user. Because of this COA Push
contain new authorization attributes. This allows NAD to apply
new access-level straight away without user disconnect.
Posture with Cisco Redirect Live Demo
Posture with Cisco Redirect LAB
LAB 1: Posture with redirect and Dot1x:

1. Configure proxy on your ISE Administration > System > Settings > Proxy value for BRU 64.103.36.133:8080
2. Update posture on ISE, Administration > System > Settings > Posture > Updates > Update Now
3. Download 4.x compliance module for Windows along with latest version of Temporary agent,
- Compliance module need to be downloaded directly from ISE – Policy > Policy Elements > Results > Client Provisioning > Resources, Add > Resources from

4. Download from cisco.com latest version of AC,

- AC you need to download directly from cisco.com, please use latest version. To download file ensure that you have proxy configured in browser and network 192.168.0.0/16 is
excluded

5. Upload AC pkg to the ISE, Policy > Policy Elements > Results > Client Provisioning > Resources, Add > Agent Resources from local disk
6. Create AC posture profile with minimum required configuration, Resources, Add > NAC Agent or Anyconnect Posture Profile
7. Create AC configuration which would push VPN, Posture and DART modules back to the user, Resources, Add > Anyconnect Configuration
8. Create client provisioning policies: Policy > Client Provisioning

User Alice which belongs to AD group Alice-Group should get an AC configuration as a result of posture,
User Bob which belongs to AD group Bob-Group should get a Temp agent,

8. Configure two posture conditions:

Service Conditions to check that Windows Defender Service is running, Policy > Policy Elements > Conditions > Posture Service Condition
Application conditions for CM 4.x with ‘Process’ check which needs to ensure that Firefox is running, Conditions > Application Condition

9. Create two posture requirements: Policy > Policy Elements > Results > Posture > Requirements
Firefox – to check Application Firefox condition, and run a message text as remediation “Please enable Firefox”
WinDefend – to check Windows defender condition and run a message text remediation ‘Please enable Windows Defender’

10. Create two posture policies: Policy > Posture

Policy with Firefox requirement which has to be applied to Alice when connection attempt is made from the switch with specific IP,
Policy with WinDefend as a requirement which has to be applied to Bob when connection attempt is made from the specific switch interface

11. Configure authorization profile with redirect to CPP portal, Policy > Policy Elements > Results > Authorization > Authorization Profiles
12. Create two authorization policies one for posture Un-equal compliant applied to the ‘Domain users’ group (result redirect to CPP), and second policy with posture equal to
Compliant applied to the ‘Domain users’ group (Result Permit Access). Use Wireless Dot1x and EAP method equal to EAP-PEAP as additional conditions in those policies
Policy > Policy Sets > Default
13. Run the tests using Wired
LAB 2: Posture for guests

1. Enable Self-Registered guest portal for posture, Work Centers > Guest Access > Portal and Components > Guest Portals > Self-Registered Guest Portal
(default)
2. Create client provisioning policy like below: Policy > Client Provisioning

When User Identity group is equal to ‘Daily Guest type’ push Temp agent back to the user,

3. Create new posture policy using Requirements from previous lab. Add both requirements to policy. Configure Windows defender requirement as
Mandatory, Configure Firefox requirement to be Optional, Policy > Posture
4. Create authorization profile for CWA redirect to the Self-Registered portal, Policy > Policy Elements > Results > Authorization > Authorization Profiles

5. Create two authorization policies: Policy > Policy Sets > Default

Policy which would be applied for Wired MAB with posture status Non-equal to compliant and and profile with redirect to guest portal.

Policy which would be applied for Wired, MAB, Specific guest user type, and posture status compliant. Result should be Permit Access.
2.2 Posture flow changes H-Level Overview
With ISE 2.2 couple of major changes has been introduced to completely remove redirection in
posture flow:

 CPP portal FQDN – starting from ISE 2.2 administrator can assign FQDN to the client
provision portal. End user can access this FQDN directly in browser and start client
provisioning process.

 CPP portal port for entire posture process – staring from ISE 2.2 posture flow is no
longer relaying on port 8905 (protected by admin certificate) and this mean that externally
signed certificate can be used for entire flow.

 MNT query for session owner lookup – as redirect is no longer

required for posture AC can contact any PSN during discovery phase,
but to finish process successfully posturing still needs to be done on
the PSN where authentication landed. First connected PSN now is able
to locate session owner using special Query to MNT nodes.
2.2 Posture flow components
In general posture components stays the same with some minor changes:

 Client provisioning portal FQDN – CPP portal now needs to be configured with FQDN, A
entry for which needs to be added to corporate DNS server:

 CPP portal authorized users – as now user can reach CPP portal directly we would like to
ensure that user is authorized for this.
This authorization can happen in two ways:
1. SSO – when user after opening portal reached the same
PSN where network authentication has been done
session can be located based on user IP and access to
portal will be granted
2. Portal authentication – if ISE node failed to locate
network authentication based on user IP user will need to
provide credentials
2.2 Posture flow components (cont)
 Client provisioning policies – as now user can reach portal directly you need to pay
special attention to CP policies configuration. In case of SSO failure only information from
the user to portal login can be used to locate correct policy (ex: AD group)

 “Unknown” authorization profile – should not contain redirect at all. To limit user access
before posture state is determined you can use:

1. DACL which will allow communication to PSN nodes, DNS, DHCP and access to
remediation servers,

2. Filter-ID – classical way to assign ACL over radius

3. VLAN – in this scenario traffic needs to be filtered on L3 device

2.2 Posture flow Authentication and
NADs
CP portal access
Client DNS

Dot1x/MAB/VPN authentication Radius Authentication

1 2
DACL example (SW/ASA):
permit udp any any DHCP Authorization policy selection.
permit udp any any DNS Matched policy should contain posture condition (Unequal to
permit ip any host PSNs Compliant or Unknown)
Authorization components :
permit ip any host Remediation servers DACL (highly recommended) – name of DACL defined on ISE

Access-Accept
dacl=DACL_name 3

Access-Request/Access-Accept for DACL

User is opening CPP if presented
portal 4
NAD applies DACL
For switches – endpoint IP address
should be presented in IPDT
DNS request ex: cpp.example.com
DNS reply = IP DNS traffic needs to permitted in DACL

6 ISE returning code 302 with full CPP URL

2.2 Posture flow CP portal SSO and NSA download

SSL connection to full CPP portal URL on port 8443

7 8
Connection protected by Client Provisioning portal certificate

Session lookup.
Session lookup needed for single-sign on.
ISE uses source IP for Radius session search. In case of failure user needs to
provide credentials
Client provisioning policy check:
Policy check is based on:
User Agent – retrieved from GET request, used for OS and Agent selection
Session ID – retrieved from session lookup, this value ISE uses to get all session
data (AD /LDAP group, Network Device Type/Location and so one)

Agent Download link displayed to client. User

9
downloads Network Setup Assistant, NSP file name
contains CPP portal FQDN
And CP portal SSO once again
10 Successful SSO
User connects to
9
portal
psn1 3 Session created
4 Accounting to PSN1 G0 user1 10.1.1.5
6 10.1.1.10
Session updated
5
2 Radius to PSN1 with user IP
User connects to
1
VPN

psn2

7 DNS request G0
8 DNS replay 10.1.1.10

DNS
A=cpp.example.com
10.1.1.10
10.1.1.20
This is an example of successful SSO scenario, at the same time as you can see DNS server may return IP of
PSN2 when session is authenticated on PSN1, in such case SSO will fail and user will be asked to provide
credentials
2.2 Posture flow NSA and agent download

HTTP GET Destination Default Gateway

Probe 1

DNS request enroll.cisco.com

DNS reply = IP

10 Probe 2 HTTP GET Destination enroll.cisco.com

DNS request PSN FQDN

DNS reply = IP
SSL connection to PSN FQDN (download URL) on port 8443
Probe 3 Connection protected by Client Provisioning portal certificate

SSL connection to CPP FQDN (download URL) on port 8443

11 Agent download and installation
Connection protected by Client Provisioning portal
certificate

Note: All old probes are supported for backward compatibility

 2.2 Posture flow PSN discovery (stage 1) PSN MNT

12
All probes are sent
simultaneously

AnyConnect
Posture module HTTP GET Destination Default Gateway
starts Probe 1
Redirect expected
DNS request enroll.cisco.com
DNS reply = IP
HTTP GET Destination enroll.cisco.com
Probe 2 Redirect expected

13
HTTP GET Destination Discovery Host
Probe 3 Redirect expected

SSL to first PSN in ConnectionData.xml on port 8443

Probe 4 Connection protected by Client Provisioning portal certificate

Stage 1 Discovery Session lookup based on information

Probes in request IPs/MACs list

Note: Stage 1 probes basically the same probes which has been used before the only difference is that in probe 4 connection
is done over CCP port and not over 8905
2.2 Posture flow PSN discovery (stage 2) PSN MNT

DNS request “Call home” FQDN

DNS reply = IP

Session owner
SSL connection to “Call home” FQDN on port 8443, Goal is to get session owner FQDN lookup on MNT
Probe 1
Connection protected by Client Provisioning portal certificate Information
about owner
14

DNS request PSNs FQDN from ConnectionData.xml

DNS reply = IP

Session owner
lookup on MNT
SSL connection to PSNs FQDN from ConnectionData.xml on port 8443, Goal is to get session owner FQDN
Probe 2 Information
Connection protected by Client Provisioning portal certificate
about owner
Stage 2 Discovery
Probes

15 Posture process
Steps are the same as for Pre 2.2 flow
Posture without redirect and posture over VPN demo
Posture without redirect and posture over VPN LAB
LAB 3: Posture over VPN
Access:
For this Lab you can create a tunnel-group and group-policy using your ID as names on 10.48.17.254 admin/Krakow123
ASA has following AC version installed - anyconnect-win-4.6.01098-webdeploy-k9.pkg
There is an address pool with the name POOL which can be used by everyone.

1. Configure your ISE as a radius server on ISE. For example:

aaa-server skuchere_21_2 protocol radius
authorize-only
interim-accounting-update
merge-dacl after-avpair
dynamic-authorization
aaa-server skuchere_21_2 (outside) host 10.48.30.44
key *****

2. Configure your group-policy. For example:

group-policy GP-SSL internal
group-policy GP-SSL attributes
dns-server value 192.168.16.5
default-domain value piborowi.com

3. Configure your tunnel-group. For example:

tunnel-group skuchere general-attributes
address-pool POOL
authentication-server-group skuchere_21_2
accounting-server-group skuchere_21_2
default-group-policy GP-SSL
tunnel-group skuchere webvpn-attributes
group-alias skuchere enable

4. Configure redirect ACL

5. Configure on ISE client provisioning policy which would be applied to the users which are connected to your tunnel-group and belong to the Domain Users
AD group. As a result of this policy AC same AC configuration which has been created lab1 should be used.

6. Create separate posture policy where both Firefox and Windows defender requirements would be mandatory. This posture policy needs to be applied only
to users which are connected to your tunnel group and which are belong to AD group domain users.

7. Configure two authorization policies:

VPN-Unknown – conditions: Tunnel-group name, AD group, Posture status. Result CPP redirect

VPN compliant - conditions: Tunnel-group name, AD group, Posture status. Result Permit Access
LAB 4: Posture without redirect

1. Login using RDP to 192.168.46.254 Administrator/Krakow123 and add A –record to DNS configuration like <your-id>-cpp.training.example.com which
should point to first ISE server in your POD. FQDN example skuchere-cpp.training.example.com

2. Configure DACL for ‘Posture pending’ scenario on ISE. ACL should allow: DNS, DHCP, traffic to ISE

3. Configure authorization profile for the ‘Posture pending’ (should include only DACL),

4. Configure default CPP portal to use your FQDN - <your-id>- training.example.com

5. Configure new authorization policy for the ‘Posture pending’

Conditions: Interface G0/7, Wired Dot1x, Domain Users, Posture pending. Result authorization profile from step 4

6. Configure new authorization policy for the Compliant state. Same conditions as in ‘Posture pending’, only posture status has to be compliant,

7. Uninstall AC form your endpoint along with removal of all AC posture files,

8. Connect endpoint to port G0/7 and provision AC from the CPP using portal FQDN,

9. Reconfigure switch to start sending authentication and accounting to the second ISE node, bounce the port, test posture again.
Windows updates Intro
On all windows machines we have special software responsible for updating the
system - Windows update agent.
Technically windows update agent can get information about required updates from
two sources:
 Internet (AKA Microsoft Server in ISE config) - updates are retrieved
directly from MS servers in the internet.

 Corporate WSUS (AKA Managed Server in ISE

config) – in this scenario Win Update agent
needs to be aware about WSUS location. This
approach is more common in enterprise as
corporate admins can decide which exact
updates needs to be installed
C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 77
So where ISE is here?
Historically from NAC times ISE can talk to the Win Update Agent over posture module to cheek
if required updates are installed and involve remediation if needed
There are two ways how this can happen:
1. Cisco Rules – MS releases hot patches lists from time to time. Within two those lists are
translated to Cisco Posture rules and can be downloaded to ISE over posture update. Later
end-device can be checked if those hot fixes are there and remediated if needed. Only
Severity Critical is supported here.
2. Severity - In this case ISE just instruct Posture module to check if Win
Update has all updates installed with particular severity. If something is
missing from Agent perspective remediation will be triggered.

Note 1: In both scenarios either Microsoft Server or Managed Server can be used

Note 2: OPSWAT is not used for Posture Agent to Windows Update agent communication in
this scenario instead MS API is queried directly.

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 78

WSUS remediation configuration tricks Cisco Rules
Cisco Hot Fix rules can be found in Policy > Policy Elements > Conditions > Posture >
Compound Conditions you can filter by “Hotfixes” in name column

If you would like to create requirement which is based on Cisco conditions you need to select
exact operation System in it (Windows All would not work).

Exact OS to
1
select

You can find HotFixes in Cisco Defined

2
Conditions > Regular Compound conditions
C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 79
WSUS remediation configuration tricks
When remediation action is created you need to select will it be based on Cisco Rules or on MS
severity. When Cisco rules are selected you can select severity as well but remember that only
“Critical” is supported with Cisco rules.
For MS rules Severity selected means FROM – ex for “ALL” everything should be installed
Choose how AC Posture should
1 decide which updates are
needed

Starting from which severity

2 updates needs to be installed

From where updates needs to be

taken. In case of “Managed
4 Server” client system needs to
be preconfigured for WSUS

If show UI selected here logged

in user needs to have Admin
4 rights
C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 80
WSUS remediation based on severity
When you selected Severity rules in your WSUS remediation you may be curious what Posture
Condition should be used tougher with it?

In general ISE has no conditions part for WSUS severity remediation.

Instead special Dummy condition “pr_WSUSRule” is used by ISE

Whenever requirement with this condition is selected remediation is started

straight away. This means that API call to Win Updater will be sent to check
If all updates with specific severity are installed

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 81

What Is SCCM
System Center Configuration Manager (SCCM) is a systems management software product
developed by Microsoft for managing large groups of computers running Windows
SCCM has a client-server architecture:
Server – central point of management, here administrator could see all endpoints registered in
SCCM, as well from here administrator can push different policies and requirements back to the
devices.
Client – software on the end device which is talking to the server. Presence of this software on
the end device side allows centralized policy distribution.

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 82

Where posture is on the picture?
Starting from ISE 1.4 support of patch management systems has been added,
SCCM is an example of a patch management system from Microsoft,
ISE can have different set of checks fro patch management systems:
 Is patch management software installed on the device?
 Is patch management software running on the device?
 Is system is up-to-date from patch management software perspective?

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 83

How does communications happens
1. Clients speaks to server over predefined intervals.
During this communication client can be instructed that
some updates are missing

2. ISE talks to AC during posture check. At time of this

communication AC can be instructed to check Patch
Management software status:

 Installed
1
 Running

 Up-to-date

3. AC compliance module uses OPSWAT to check if 3

everything fine with PM software.

Note: AC relays on replay from PM software. If PM software

is not aware that something is missing endpoint will be
marked as compliant. 2

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 84

ISE side recommendations
At time of Posture condition configuration for Installation/Running/Up-to-date checks always try to
select exact PM software version, this will make posture process faster

For the Up to date scenario remember that we use OPSWAT database to understand patch
severity. In case when compliance module has not been updated for some time information
about severity can be inaccurate. You van use “All” for this kind of scenario.

C97-736227-00 © 2017 Cisco and/or its affiliates. All rights reserved.. 85