Cisco ISE Profiling Service

The profiling service in Cisco Identity Services Engine (ISE) identifies the devices that connect to your network
and their location. The endpoints are profiled based on the endpoint profiling policies configured in Cisco
ISE. Cisco ISE then grants permission to the endpoints to access the resources in your network based on the
result of the policy evaluation.
The profiling service:
• Facilitates anefficient and effective deployment and ongoing management of authentication by
using IEEE standard 802.1X port-based authentication access control, MAC Authentication
Bypass (MAB) authentication, and Network Admission Control (NAC) for any enterprise network
of varying scale and complexity.
• Identifies, locates, and determines the capabilities of all of the attached network endpoints
regardless of endpoint types.
• Protects against inadvertently denying access to some endpoints.

Profiler Work Center

The Profiler Work Center menu (Work Centers > Profiler) contains all the profiler pages, which acts as a
single start point for ISE administrators. The Profiler Work Center menu contains the following options:
Overview, Ext ID Stores, Network Devices, Endpoint Classification, Node Config, Feeds, Manual Scans,
Policy Elements, Profiling Policies, Authorization Policy, Troubleshoot, Reports, Settings, and Dictionaries.

Profiler Dashboard
The Profiler dashboard (Work Centers > Profiler > Endpoint Classification) is a centralized monitoring
tool for the profiles, endpoints, and assets in your network. The dashboard represents data in both
graphical and table formats. The Profiles dashlet displays the logical and endpoint profiles that are
currently active in the network. The Endpoints dashlet displays the identity group, PSNs, OS types of the
endpoints that connect to your network. The Assets dashlet displays flows such as Guest, BYOD, and
Corporate. The table displays the various endpoints that are connected and you can also add new
endpoints.

Endpoint Inventory Using Profiling Service

You can use the profiling service to discover, locate, and determine the capabilities of all the endpoints
connected to your network. You can ensure and maintain appropriate access of endpoints to the enterprise
network, regardless of their device types.
The profiling service collects attributes of endpoints from the network devices and the network, classifies
endpoints into a specific group according to their profiles, and stores endpoints with their matched profiles
in the Cisco ISE database. All the attributes that are handled by the profiling service need to be defined in the
profiler dictionaries.
The profiling service identifies each endpoint on your network, and groups those endpoints according to their
profiles to an existing endpoint identity group in the system, or to a new group that you can create in the
system. By grouping endpoints, and applying endpoint profiling policies to the endpoint identity group, you
can determine the mapping of endpoints to the corresponding endpoint profiling policies.

Cisco ISE Profiler Queue Limit Configuration

Cisco ISE profiler collects a significant amount of endpoint data from the network in a short period of time.
It causes Java Virtual Machine (JVM) memory utilization to go up due to accumulated backlog when some
of the slower Cisco ISE components process the data generated by the profiler, which results in performance
degradation and stability issues.
To ensure that the profiler does not increase the JVM memory utilization and prevent JVM to go out of memory
and restart, limits are applied to the following internal components of the profiler:
• Endpoint Cache: Internal cache is limited in size that has to be purged periodically (based on least
recently used strategy) when the size exceeds the limit.
• Forwarder: The main ingress queue of endpoint information collected by the profiler.
• EventHandler: An internal queue that disconnects a fast component, which feeds data to a slower
processing component (typically related to a database query).

Endpoint Cache
• maxEndPointsInLocalDb = 100000 (endpoint objects in cache)
• endPointsPurgeIntervalSec = 300 (endpoint cache purge thread interval in seconds)
• numberOfProfilingThreads = 8 (number of threads)

The limit is applicable to all profiler internal event handlers. A monitoring alarm is triggered when queue size
limit is reached.

Cisco ISE Profiler Queue Size Limits

• forwarderQueueSize = 5000 (endpoint collection events)
• eventHandlerQueueSize = 10000 (events)

Event Handlers
• NetworkDeviceEventHandler: For network device events, in addition to filtering duplicate
Network Access Device (NAD) IP addresses, which are already cached.
• ARPCacheEventHandler: For ARP Cache events.
Martian IP Addresses
Martian IP addresses are not displayed in Context Visibility > Endpoints and Work Centers > Profiler >
Endpoint Classification windows as the RADIUS parser removes such addresses before they reach the
profiling service. Martian IP addresses are a security concern as they are vulnerable to attacks. However,
martian IP addresses are displayed in MnT logs for auditing purposes. This behaviour stands true in the case
of multicast IP addresses as well.

Profiler Forwarder Persistence Queue

The Profiler Forwarder Persistence queue stores events before they are sent to the profiler module for further
processing. In addition, the queuing capacity has also been increased to support increased event handling.
This reduces the number events that are lost because of a sudden increase in the number of events. This in
turn reduces the alarms raised, when the queue reaches its maximum limit.
This feature is enabled by default. If required, you can disable this feature to fall back to the original mechanism,
where events are sent directly to the profiler module. To enable or disable this feature, choose Administration >
System > Settings > Profiling and check or uncheck the Enable Profiler Forwarder Persistence Queue
check box.

Configure Profiling Service in Cisco ISE Nodes

You can configure the profiling service that provides you a contextual inventory of all the endpoints that are
using your network resources in any Cisco ISE-enabled network.
You can configure the profiling service to run on a single Cisco ISE node that assumes all Administration,
Monitoring, and Policy Service personas by default.
In a distributed deployment, the profiling service runs only on Cisco ISE nodes that assume the Policy Service
persona and does not run on other Cisco ISE nodes that assume the Administration and Monitoring personas.

Network Probes Used by Profiling Service

Network probe is a method used to collect an attribute or a set of attributes from an endpoint on your network.
The probe allows you to create or update endpoints with their matched profile in the Cisco ISE database.
Cisco ISE can profile devices using a number of network probes that analyze the behavior of devices on the
network and determine the type of the device. Network probes help you to gain more network visibility.

IP Address and MAC Address Binding

You can create or update endpoints only by using their MAC addresses in an enterprise network. If you do
not find an entry in the ARP cache, then you can create or update endpoints by using the L2 MAC address of
an HTTP packet and the IN_SRC_MAC of a NetFlow packet in Cisco ISE. The profiling service is dependent
on L2 adjacency when endpoints are only a hop away. When endpoints are L2 adjacent, the IP addresses and
MAC addresses of endpoints are already mapped, and there is no need for IP-MAC cache mapping.
If endpoints are not L2 adjacent and are multiple hops away, mapping may not be reliable. Some of the known
attributes of NetFlow packets that you collect include PROTOCOL, L4_SRC_PORT, IPV4_SRC_ADDR,
L4_DST_PORT, IPV4_DST_ADDR, IN_SRC_MAC, OUT_DST_MAC, IN_SRC_MAC, and
 OUT_SRC_MAC. When endpoints are not L2 adjacent and are multiple L3 hops away, the IN_SRC_MAC
attributes carry only the MAC addresses of L3 network devices. When the HTTP probe is enabled in Cisco
ISE, you can create endpoints only by using the MAC addresses of HTTP packets, because the HTTP request
messages do not carry IP addresses and MAC addresses of endpoints in the payload data.
Cisco ISE implements an ARP cache in the profiling service, so that you can reliably map the IP addresses
and the MAC addresses of endpoints. For the ARP cache to function, you must enable either the DHCP probe
or the RADIUS probe. The DHCP and RADIUS probes carry the IP addresses and the MAC addresses of
endpoints in the payload data. The dhcp-requested address attribute in the DHCP probe and the
Framed-IP-address attribute in the RADIUS probe carry the IP addresses of endpoints, along with their MAC
addresses, which can be mapped and stored in the ARP cache.

NetFlow Probe
Cisco ISE profiler implements Cisco IOS NetFlow Version 9. We recommend using NetFlow Version 9,
which has additional functionality needed to enhance the profiler to support the Cisco ISE profiling service.
You can collect NetFlow Version 9 attributes from the NetFlow-enabled network access devices to create an
endpoint, or update an existing endpoint in the Cisco ISE database. You can configure NetFlow Version 9 to
attach the source and destination MAC addresses of endpoints and update them. You can also create a dictionary
of NetFlow attributes to support NetFlow-based profiling.
For more information on the NetFlow Version 9 Record Format, see Table 6, “NetFlow Version 9 Field
Type Definitions” of the NetFlow Version 9 Flow-Record Format document.
In addition, Cisco ISE supports NetFlow versions earlier than Version 5. If you use NetFlow Version 5
in your network, then you can use Version 5 only on the primary network access device (NAD) at the
access layer because it will not work anywhere else.
Cisco IOS NetFlow Version 5 packets do not contain MAC addresses of endpoints. The attributes that are
collected from NetFlow Version 5 cannot be directly added to the Cisco ISE database. You can discover
endpoints by using their IP addresses, and append the NetFlow Version 5 attributes to endpoints, which
can be done by combining IP addresses of the network access devices and IP addresses obtained from the
NetFlow Version 5 attributes. However, these endpoints must have been previously discovered with the
RADIUS or SNMP probe.
The MAC address is not a part of IP flows in earlier versions of NetFlow Version 5, which requires you to
profile endpoints with their IP addresses by correlating the attributes information collected from the
network access devices in the endpoints cache.
For more information on the NetFlow Version 5 Record Format, see Table 2, “Cisco IOS NetFlow Flow
Record and Export Format Content Information” of the NetFlow Services Solutions Guide.

DHCP Probe
The Dynamic Host Configuration Protocol probe in your Cisco ISE deployment allows the Cisco ISE profiling
service to reprofile endpoints based only on new requests of INIT-REBOOT and SELECTING message types.
Though other DHCP message types such as RENEWING and REBINDING are processed, they are not used
for profiling endpoints. Any attribute parsed out of DHCP packets is mapped to endpoint attributes.
 From Cisco ISE Release 3.3 onwards, IPv6 is supported in DHCP Probe.

DHCPREQUEST Message Generated During INIT-REBOOT State

If the DHCP client checks to verify a previously allocated and cached configuration, then the
client must not fill in the Server identifier (server-ip) option. Instead it should fill in the
Requested IP address (requested-ip) option with the previously assigned IP address, and fill
in the Client IP Address (ciaddr) field with zero in its DHCPREQUEST message. The
DHCP server will then send a DHCPNAK message to the client if the Requested IP address
is incorrect or the client is located in the wrong network.

DHCPREQUEST Message Generated During SELECTING State

The DHCP client inserts the IP address of the selected DHCP server in the Server identifier
(server-ip) option, fills in the Requested IP address (requested-ip) option with the value of
the Your IP Address (yiaddr) field from the chosen DHCPOFFER by the client, and fills in
the “ciaddr” field with zero.

Table 97: DHCP Client Messages from Different States

— INIT-REBOOT SELECTING RENEWING REBINDING

broadcast/unicast broadcast broadcast unicast broadcast
server-ip MUST NOT MUST MUST NOT MUST NOT
requested-ip MUST MUST MUST NOT MUST NOT
ciaddr zero zero IP address IP address

Wireless LAN Controller Configuration in DHCP Bridging Mode

We recommend that you configure wireless LAN controllers (WLCs) in Dynamic Host Configuration Protocol
(DHCP) bridging mode, where you can forward all the DHCP packets from the wireless clients to Cisco ISE.
You must uncheck the Enable DHCP Proxy check box available in the WLC web interface: Controller >
Advanced > DHCP Master Controller Mode > DHCP Parameters. You must also ensure that the DHCP
IP helper command points to the Cisco ISE Policy Service node.

DHCP SPAN Probe

The DHCP Switched Port Analyzer (SPAN) probe, when initialized in a Cisco ISE node, listens to network
traffic, which are coming from network access devices on a specific interface. You need to configure network
access devices to forward DHCP SPAN packets to the Cisco ISE profiler from the DHCP servers. The profiler
receives these DHCP SPAN packets and parses them to capture the attributes of an endpoint, which can be
used for profiling endpoints.
 HTTP Probe
In HTTP probe, the identification string is transmitted in an HTTP request-header field
User-Agent, which is an attribute that can be used to create a profiling condition of IP
type, and to check the web browser information. The profiler captures the web browser
information from the User-Agent attribute along with other HTTP attributes from the
request messages, and adds them to the list of endpoint attributes.
Cisco ISE listens to communication from the web browsers on both port 80 and port 8080.
Cisco ISE provides many default profiles, which are built in to the system to identify
endpoints based on the User-Agent attribute.
HTTP probe is enabled by default. Multiple ISE services such as CWA, Hotspot, BYOD,
MDM, and Posture rely on URL-redirection of the client's web browser. The redirected
traffic includes the RADIUS session ID of the connected endpoint. When a PSN terminates
these URL-redirected flows, it has visibility into the decrypted HTTPS data. Even when the
HTTP probe is disabled on the PSN, the node will parse the browser user agent string from
the web traffic and correlate the data to the endpoint based on its associated session ID.
When browser strings are collected through this method, the source of the data is listed as
Guest Portal or CP (Client Provisioning) rather than HTTP Probe.
From Cisco ISE Release 3.3 onwards, IPv6 is supported in HTTP Probe.

HTTP SPAN Probe

The HTTP probe in your Cisco ISE deployment, when enabled with the Switched Port Analyzer (SPAN)
probe, allows the profiler to capture HTTP packets from the specified interfaces. You can use the SPAN
capability on port 80, where the Cisco ISE server listens to communication from the web browsers.
HTTP SPAN collects HTTP attributes of an HTTP request-header message along with the IP addresses in the
IP header (L3 header), which can be associated to an endpoint based on the MAC address of an endpoint in
the L2 header. This information is useful for identifying different mobile and portable IP-enabled devices
such as Apple devices, and computers with different operating systems. Identifying different mobile and
portable IP-enabled devices is made more reliable because the Cisco ISE server redirects captures during a
guest login or client provisioning download. This allows the profiler to collect the User-Agent attribute and
other HTTP attributes, from the request messages and then identify devices such as Apple devices.

Unable to Collect HTTP Attributes in Cisco ISE Running on VMware

If you deploy Cisco ISE on an ESX server (VMware), the Cisco ISE profiler collects the Dynamic Host
Configuration Protocol traffic but does not collect the HTTP traffic due to configuration issues on the
vSphere client. To collect HTTP traffic on a VMware setup, configure the security settings by changing the
Promiscuous Mode to Accept from Reject (by default) of the virtual switch that you create for the Cisco ISE
profiler. When the Switched Port Analyzer (SPAN) probe for DHCP and HTTP is enabled, Cisco ISE
profiler collects both the DHCP and HTTP traffic.
pxGrid Probe

The pxGrid probe leverages Cisco pxGrid for receiving endpoint context from external
sources. Prior to Cisco ISE 2.4, Cisco ISE served only as a publisher and shared various
context information such as session identity and group information as well as
configuration elements to external subscribers. With the introduction of the pxGrid probe
in Cisco ISE 2.4, other solutions serve as the publishers and Cisco ISE Policy Service
nodes become the subscribers.
The pxGrid probe is based on pxGrid v2 specification using the Endpoint Asset topic
/topic/com.cisco.endpoint.asset with Service Name com.cisco.endpoint.asset. The
following table displays the topic attributes all of which are preceded by the prefix asset.

Attribute Name Type Description

assetId Long Asset ID

assetName String Asset name

assetIpAddress String IP address

assetMacAddress String MAC address

assetVendor String Manufacturer

assetProductId String Product Code

assetSerialNumber String Serial Number

assetDeviceType String Device Type

assetSwRevision String S/W Revision number

assetHwRevision String H/W Revision number

assetProtocol String Protocol

assetConnectedLinks Array Array of Network Link objects

assetCustomAttributes Array Array of Custom name-value pairs

In addition to the attributes commonly used to track networked assets such as device
MAC address (assetMacAddress) and IP address (assetIpAddress), the topic allows
vendors to publish unique endpoint information as Custom Attributes
(assetCustomAttributes). The use of Endpoint Custom Attributes in Cisco ISE makes the
topic extensible to a variety of use cases without requiring schema updates for each new
set of unique vendor attributes shared over pxGrid.
RADIUS Probe
You can configure Cisco ISE for authentication with RADIUS, where you can define a shared secret that you
can use in client-server transactions. With the RADIUS request and response messages that are received from
the RADIUS servers, the profiler can collect RADIUS attributes, which can be used for profiling endpoints.
Cisco ISE can function as a RADIUS server, and a RADIUS proxy client to other RADIUS servers. When it
acts as a proxy client, it uses external RADIUS servers to process RADIUS requests and response messages.
The RADIUS probe also collects attributes sent in RADIUS accounting packets by device sensors. The
RADIUS probe is running by default, even for systems not configured for Profiling Service to ensure ISE
can track endpoint authentication and authorization details for use in Context Visibility Services.
The RADIUS probe and Profiling Services are also used to track the creation and update times for registered
endpoints for purposes of purge operations.
From Cisco ISE Release 3.3 onwards, IPv6 is supported in RADIUS Probe.

User Name Calling Station ID Called Station ID Framed IP Address

NAS-IP-Address NAS-Port-Type NAS-Port-Id NAS-Identifier
Device Type (NAD) Location (NAD) Authentication Policy Authorization Policy

Network Scan (NMAP) Probe

Cisco ISE enables you to detect devices in a subnet by using the NMAP security scanner. You enable the
NMAP probe on the Policy Service node that is enabled to run the profiling service. You use the results from
that probe in an endpoint profiling policy.
The NMAP scan is performed automatically for any endpoint device that matches the Unknown profile and
has an IP address assigned, or matches the NMAP condition in the profiling policy. This automatic NMAP
scan is peformed only thrice, for both Unknown endpoints and matches of the Network Scan action. If further
scanning is required, you can perform a manual scan or remove the endpoint device from Context Visibility.
Each NMAP manual subnet scan has a unique numeric ID that is used to update an endpoint source information
with that scan ID. Upon detection of endpoints, the endpoint source information can also be updated to indicate
that it is discovered by the Network Scan probe.

The NMAP manual subnet scan is useful for detecting devices such as printers with a static IP address
assigned to them that are connected constantly to the Cisco ISE network, and therefore these devices cannot
be discovered by other probes.

NMAP Scan Limitations

Scanning a subnet is highly resource intensive. Scanning a subnet is lengthy process that depends on the
size and density of the subnet. Number of active scans is always restricted to one scan, which means that
you can scan only a single subnet at a time. You can cancel a subnet scan at any time while the subnet
scan is in progress. You can use the Click to see latest scan results link to view the most recent network
scan results that are stored in Work Centers > Profiler > Manual Scans > Manual NMAP Scan
Results.
Manual NMAP Scan
The following NMAP command scans a subnet and sends the output to nmapSubnet.log:

-O Enables OS detection
-sU UDP scan
-p <port ranges> Scans only specified ports. For example, U:161, 162

oN Normal output
oX XML output

SNMP Read Only Community Strings for NMAP Manual Subnet Scan
The NMAP manual subnet scan is augmented with an SNMP Query whenever the scan discovers that UDP
port 161 is open on an endpoint that results in more attributes being collected. During the NMAP manual
subnet scan, the Network Scan probe detects whether SNMP port 161 is open on the device. If the port is
open, an SNMP Query is triggered with a default community string (public) with SNMP version 2c.
If the device supports SNMP and the default Read Only community string is set to public, you can obtain the
MAC address of the device from the MIB value “ifPhysAddress”.
In addition, you can configure additional SNMP Read Only community strings separated by a comma for the
NMAP manual network scan in the Profiler Configuration window. You can also specify new Read Only
community strings for an SNMP MIB walk with SNMP versions 1 and 2c.

Manual NMAP Scan Results

The most recent network scan results are stored in Work Centers > Profiler > Manual Scans > Manual NMAP
Scan Results. The Manaul NMAP Scan Results page displays only the most recent endpoints that are detected,
along with their associated endpoint profiles, their MAC addresses, and their static assignment status as the
result of a manual network scan you perform on any subnet. This page allows you to edit points that are
detected from the endpoint subnet for better classification, if required.
Cisco ISE allows you to perform the manual network scan from the Policy Service nodes that are enabled to run
the profiling service. You must choose the Policy Service node from the primary Administration ISE node user
interface in your deployment to run the manual network scan from the Policy Service node. During the manual
network scan on any subnet, the Network Scan probe detects endpoints on the specified subnet, their operating
systems, and check UDP ports 161 and 162 for an SNMP service.
Given below is additional information related to the manual NMAP scan results:
• To detect unknown endpoints, NMAP should be able to learn the IP/MAC binding via NMAP or
a supporting SNMP scan.
• ISE learns IP/MAC binding of known endpoints via Radius authentication or DHCP profiling.
• The IP/MAC bindings are not replicated across PSN nodes in a deployment. Therefore, you must
trigger the manual scan from the PSN, which has the IP/MAC binding in its local database (for
example, the PSN against which a mac address was last authenticated with).
• The NMAP scan results do not display any information related to an endpoint that NMAP had
previously scanned, manually or automatically.
 DNS Probe
The Domain Name Service (DNS) probe in your Cisco ISE deployment allows the
profiler to lookup an endpoint and get the fully qualified domain name (FQDN). After an
endpoint is detected in your Cisco
ISE-enabled network, a list of endpoint attributes is collected from the NetFlow, DHCP, DHCP
SPAN, HTTP, RADIUS, or SNMP probes.
When you deploy Cisco ISE in a standalone or in a distributed environment for the first time,
you are prompted to run the setup utility to configure the Cisco ISE appliance. When you run
the setup utility, you will configure the Domain Name System (DNS) domain and the primary
nameserver (primary DNS server), where you can configure one or more nameservers during
setup. You can also change or add DNS nameservers later after deploying Cisco ISE using
the CLI commands.

DNS FQDN Lookup

Before a DNS lookup can be performed, one of the following probes must be started along with the DNS
probe: DHCP, DHCP SPAN, HTTP, RADIUS, or SNMP. This allows the DNS probe in the profiler to do a
reverse DNS lookup (FQDN lookup) against specified name servers that you define in your Cisco ISE
deployment. A new attribute is added to the attribute list for an endpoint, which can be used for an endpoint
profiling policy evaluation. The FQDN is the new attribute that exists in the system IP dictionary. You can
create an endpoint profiling condition to validate the FQDN attribute and its value for profiling. The following
are the specific endpoint attributes that are required for a DNS lookup and the probe that collects these
attributes:
• The dhcp-requested-address attribute—An attribute collected by the DHCP and DHCP SPAN probes.

• The SourceIP attribute—An attribute collected by the HTTP probe

• The Framed-IP-Address attribute—An attribute collected by the RADIUS probe
• The cdpCacheAddress attribute—An attribute collected by the SNMP probe

SNMP Query Probe

In addition to configuring the SNMP Query probe in the Edit Node page, you must configure other Simple
Management Protocol settings in the following location: Administration > Network Resources > Network
Devices.
You can configure SNMP settings in the new network access devices (NADs) in the Network Devices list
page. The polling interval that you specify in the SNMP query probe or in the SNMP settings in the network
access devices query NADs at regular intervals.
 You can turn on and turn off SNMP querying for specific NADs based on the following configurations:
• SNMP query on Link up and New MAC notification turned on or turned off
• SNMP query on Link up and New MAC notification turned on or turned off for Cisco Discovery
Protocol information
• SNMP query timer for once an hour for each switch by default

For an iDevice, and other mobile devices that do not support SNMP, the MAC address can be discovered by
the ARP table, which can be queried from the network access device by an SNMP Query probe.

Cisco Discovery Protocol Support with SNMP Query

When you configure SNMP settings on the network devices, you must ensure that the Cisco Discovery Protocol
is enabled (by default) on all the ports of the network devices. If you disable the Cisco Discovery Protocol on
any of the ports on the network devices, then you may not be able to profile properly because you will miss
the Cisco Discovery Protocol information of all the connected endpoints. You can enable the Cisco
Discovery Protocol globally by using the cdp run command on a network device, and enable the Cisco
Discovery Protocol by using the cdp enable command on any interface of the network access device. To disable
the Cisco Discovery Protocol on the network device and on the interface, use the no keyword at the beginning of
the commands.

Link Layer Discovery Protocol Support with SNMP Query

The Cisco ISE profiler uses an SNMP Query to collect LLDP attributes. You can also collect LLDP attributes
from a Cisco IOS sensor, which is embedded in the network device, by using the RADIUS probe. The following
are the default LLDP configuration settings that you can use to configure LLDP global configuration and
LLDP interface configuration commands on the network access devices.

Attribute Setting
LLDP global state Disabled
LLDP holdtime (before discarding) 120 seconds

LLDP timer (packet update frequency) 30 seconds

LLDP 2 seconds
reinitialization delay
LLDP tlv-select Enabled to send and receive all TLVs.
LLDP interface state Enabled
LLDP receive Enabled
LLDP transmit Enabled
LLDP Enabled to send all LLDP-MED TLVs
med-tlv-select

CDP and LLDP Capability Codes Displayed in a Single Character

The Attribute List of an endpoint displays a single character value for the lldpCacheCapabilities and
lldpCapabilitiesMapSupported attributes. The values are the Capability Codes that are displayed for the
network access device that runs CDP and LLDP.
SNMP Trap Probe
The SNMP Trap receives information from the specific network access devices that support MAC
notification, linkup, linkdown, and informs. The SNMP Trap probe receives information from the specific
network access devices when ports come up or go down and endpoints disconnect from or connect to
your network.
For SNMP Trap to be fully functional and create endpoints, you must enable SNMP Query so that the
SNMP Query probe triggers a poll event on the particular port of the network access device when a trap is
received. To make this feature fully functional, you should configure the network access device and
SNMP Trap.

Active Directory Probe

Active Directory (AD) probe:
• Improves the fidelity of OS information for Windows endpoints. Microsoft AD tracks detailed OS
information for AD-joined computers including version and service pack levels. The AD probe
retrieves this information directly using the AD Runtime connector to provide a highly reliable
source of client OS information.
• Helps distinguish between corporate and non-corporate assets. A basic but important attribute
available to the AD probe is whether an endpoint exists in AD. This information can be used to
classify an endpoint contained in the AD as a managed device or corporate asset.

You can enable the AD probe under Administration > System > Deployment > Profiling
Configuration. When this probe is enabled, Cisco ISE fetches the AD attributes for a new endpoint as
soon as it receives a hostname. The hostname is typically learned from the DHCP or DNS probes. Once
successfully retrieved, ISE does not attempt to query AD again for the same endpoint until a the rescan
timer expires. This is to limit the load on AD for attribute queries. The rescan timer is configurable in the
Days Before Rescan field (Administration > System > Deployment > Profiling Configuration >
Active Directory). If there is additional profiling activity on the endpoint, the AD is queried again.

The following AD probe attributes can be matched in the Policy > Policy Elements > Profiling using the
ACTIVEDIRECTORY condition. AD attributes collected using the AD Probe appear with the prefix “AD”
in the endpoint details on the Context Visibility > Endpoints window.
• AD-Host-Exists

• AD-Join-Point

• AD-Operating-System

• AD-OS-Version

• AD-Service-Pack
Global Configuration of Change of Authorization for Authenticated Endpoints
You can use the global configuration feature to disable change of authorization (CoA) by using the default
No CoA option or enable CoA by using port bounce and reauthentication options. If you have configured Port
Bounce for CoA in Cisco ISE, the profiling service may still issue other CoAs as described in the “CoA
Exemptions” section.
The global configuration chosen dictates the default CoA behavior only in the absense of more specific settings.
You can use the RADIUS probe or the Monitoring persona REST API to authenticate the endpoints. You can
enable the RADIUS probe, which allows faster performance. If you have enabled CoA, then we recommend
that you enable the RADIUS probe in conjunction with your CoA configuration in the Cisco ISE application
for faster performance. The profiling service can then issue an appropriate CoA for endpoints by using the
RADIUS attributes that are collected.
If you have disabled the RADIUS probe in the Cisco ISE application, then you can rely on the Monitoring
persona REST API to issue CoAs. This allows the profiling service to support a wider range of endpoints. In a
distributed deployment, your network must have at least one Cisco ISE node that assumes the Monitoring
persona to rely on the Monitoring persona REST API to issue a CoA.
Cisco ISE arbitrarily will designate either the primary or secondary Monitoring node as the default destination
for REST queries in your distributed deployment, because both the primary and secondary Monitoring nodes
have identical session directory information.

Use Cases for Issuing Change of Authorization

The profiling service issues the change of authorization in the following cases:
• Endpoint deleted: When an endpoint is deleted from the Endpoints page and the endpoint is
disconnected or removed from the network.
• An exception action is configured: If you have an exception action configured per profile that
leads to an unusual or an unacceptable event from that endpoint. The profiling service moves the
endpoint to the corresponding static profile by issuing a CoA.
• An endpoint is profiled for the first time: When an endpoint is not statically assigned and
profiled for the first time; for example, the profile changes from an unknown to a known profile.
• An endpoint identity group has changed: When an endpoint is added or removed from an endpoint
identity group that is used by an authorization policy.
The profiling service issues a CoA when there is any change in an endpoint identity group, and the endpoint
identity group is used in the authorization policy for the following:
• The endpoint identity group changes for endpoints when they are dynamically profiled
• The endpoint identity group changes when the static assignment flag is set to true for a dynamic
endpoint
• An endpoint profiling policy has changed and the policy is used in an authorization policy:
When an endpoint profiling policy changes, and the policy is included in a logical profile that
is used in an authorization policy. The endpoint profiling policy may change due to the profiling
policy match or when an endpoint is statically assigned to an endpoint profiling policy, which is
associated to a logical profile. In both the cases, the profiling service issues a CoA, only when
the endpoint profiling policy is used in an authorization policy.
Exemptions for Issuing a Change of Authorization
The profiling service does not issue a CoA when there is a change in an endpoint identity group and the
static assignment is already true.
Cisco ISE does not issue a CoA for the following reasons:
• An Endpoint disconnected from the network—When an endpoint disconnected from your network
is discovered.
• Authenticated wired (Extensible Authentication Protocol) EAP-capable endpoint—When an
authenticated wired EAP-capable endpoint is discovered.
• Multiple active sessions per port—When you have multiple active sessions on a single port, the
profiling service issues a CoA with the Reauth option even though you have configured CoA with the
Port Bounce option.
• Packet-of-Disconnect CoA (Terminate Session) when a wireless endpoint is detected—If an
endpoint is discovered as wireless, then a Packet-of-Disconnect CoA (Terminate-Session) is issued
instead of the Port Bounce CoA. The benefit of this change is to support the Wireless LAN
Controller (WLC) CoA.
• Profiler CoA is suppressed when the Suppress Profiler CoA for endpoints in Logical Profile
option is used for the configured logical profile in the Authorization Profile. Profiler CoA will be
triggered for all other endpoints by default.
• Global No CoA Setting overrides Policy CoA—Global No CoA overrides all configuration settings
in endpoint profiling policies as there is no CoA issued in Cisco ISE irrespective of CoA
configured per endpoint profiling policy.

Change of Authorization Issued for Each Type of CoA Configuration

Scenarios No CoA Port Bounce Reauth Additional Information

Configuration Configuration Configuration

Global CoA configuration in No CoA Port Bounce Reauthentication —

Cisco ISE (typical configuration)
An endpoint is No CoA No CoA No CoA Change of authorization is
disconnected on your determined by the RADIUS
network attribute Acct-Status -Type
value Stop.
Wired with multiple active No CoA Reauthentication Reauthentication Reauthentication avoids
sessions on the same switch port disconnecting other sessions.
Wireless endpoint No CoA Packet-of-Disconnect CoA Reauthentication Support to Wireless LAN
(Terminate Session) Controller.
Incomplete CoA data No CoA No CoA No CoA Due to missing RADIUS
attributes.
Attribute Filters for ISE Database Persistence and Performance
Cisco ISE implements filters for Dynamic Host Configuration Protocol (both DHCP Helper and DHCP SPAN),
HTTP, RADIUS, and Simple Network Management Protocol probes except for the NetFlow probe to address
performance degradation. Each probe filter contains the list of attributes that are temporal and irrelevant for
endpoint profiling and removes those attributes from the attributes collected by the probes.
The isebootstrap log (isebootstrap-yyyymmdd-xxxxxx.log) contains messages that handles the creation of
dictionaries and with filtering of attributes from the dictionaries. You can also configure to log a debug message
when endpoints go through the filtering phase to indicate that filtering has occurred.
The Cisco ISE profiler invokes the following endpoint attribute filters:
• A DHCP filter for both the DHCP Helper and DHCP SPAN contains all the attributes that are not
necessary and they are removed after parsing DHCP packets. The attributes after filtering are
merged with existing attributes in the endpoint cache for an endpoint.
• An HTTP filter is used for filtering attributes from HTTP packets, where there is no significant
change in the set of attributes after filtering.
• A RADIUS filter is used once the syslog parsing is complete and endpoint attributes are merged into
the endpoint cache for profiling.
• SNMP filter for SNMP Query includes separate CDP and LLDP filters, which are all
used for SNMP-Query probe.

Global Setting to Filter Endpoint Attributes

You can reduce the number of persistence events and replication events by reducing the number of endpoint
attributes that do not change frequently at the collection point. When you enable the EndPoint Attribute
Filter, the Cisco ISE profiler keeps only allowed attributes and discards all other attributes.
To enable the Endpoint Attribute Filter,
An allowed list is a set of attributes that are used in custom endpoint profiling policies for profiling endpoints,
and that are essential for Change of Authorization (CoA), Bring Your Own Device (BYOD), Device Registration
WebAuth (DRW), and so on to function in Cisco ISE as expected. The allowed list is always used as a criteria
when ownership changes for the endpoint (when attributes are collected by multiple Policy Service nodes)
even when disabled.
By default, the allowed list is disabled and the attributes are dropped only when the attribute filter is enabled.
The allowed list is dynamically updated when endpoint profiling policies change including from the feed to
include new attributes in the profiling policies. Any attribute that is not present in the allowed list is dropped
immediately at the time of collection, and the attribute is not used for profiling endpoints. When combined
with the buffering, the number of persistence events can be reduced.
You must ensure that the allowed list contains a set of attributes determined from the following two sources:
• A set of attributes that are used in the default profiles so that you can match endpoints to the profiles.
• A set of attributes that are essential for CoA, BYOD, DRW, and so on to function as expected.
AAA-Server BYODRegistration

Calling-Station-ID Certificate Expiration Date

Certificate Issue Date Certificate Issuer Name

Certificate Serial Number Description

DestinationIPAddress Device Identifier

Device Name DeviceRegistrationStatus

EndPointPolicy EndPointPolicyID

EndPointProfilerServer EndPointSource

FQDN FirstCollection

Framed-IP-Address IdentityGroup

IdentityGroupID IdentityStoreGUID

IdentityStoreName L4_DST_PORT

LastNmapScanTime MACAddress
MatchedPolicy MatchedPolicyID

NADAddress NAS-IP-Address

NAS-Port-Id NAS-Port-Type

NmapScanCount NmapSubnetScanID

OS Version OUI
PolicyVersion PortalUser

PostureApplicable Product

RegistrationTimeStamp —

StaticAssignment StaticGroupAssignment

TimeToProfile Total Certainty Factor

User-Agent cdpCacheAddress

cdpCacheCapabilities cdpCacheDeviceId

cdpCachePlatform cdpCacheVersion

ciaddr dhcp-class-identifier
dhcp-requested-address host-name

hrDeviceDescr ifIndex

ip lldpCacheCapabilities

lldpCapabilitiesMapSupported lldpSystemDescription

operating-system sysDescr

161-udp —
 Attributes Collection from Cisco IOS Sensor-Embedded Switches
An Cisco IOS sensor integration allows Cisco ISE run time and the Cisco ISE profiler to collect any or all of the
attributes that are sent from the switch. You can collect DHCP, CDP, and LLDP attributes directly from
the switch by using the RADIUS protocol. The attributes that are collected for DHCP, CDP, and LLDP are then
parsed and mapped to attributes in the profiler dictionaries in the following location: Policy > Policy Elements >
Dictionaries.

Cisco IOS Sensor-Embedded Network Access Devices

Integrating Cisco IOS sensor embedded network access devices with Cisco ISE involves the following components:
• A Cisco IOS sensor

• Data collector that is embedded in the network access device (switch) for gathering DHCP, CDP, and LLDP
data
• Analyzers for processing the data and determining the device-type of endpoints
There are two ways of deploying an analyzer, but they are not expected to be used in conjunction with each other:
• An analyzer can be deployed in Cisco ISE

• Analyzers can be embedded in the switch as the sensor

ConfigurationChecklistforCiscoIOSSensor-EnabledNetworkAccessDevices
This section summarizes a list of tasks that you must configure in the Cisco IOS sensor-enabled switches and Cisco
ISE to collect DHCP, CDP, and LLDP attributes directly from the switch:
• Ensure that the RADIUS probe is enabled in Cisco ISE.

• Ensure that network access devices support an IOS sensor for collecting DHCP, CDP, and LLDP
information.
• Ensure that network access devices run the following CDP and LLDP commands to capture CDP and
LLDP information from endpoints:
cdp enable
lldp run

• Ensure that session accounting is enabled separately by using the standard AAA and RADIUS commands. For
example, use the following commands:

aaa new-model
aaa accounting dot1x default start-stop group radius

radius-server host <ip> auth-port <port> acct-port <port> key <shared-secret>

radius-server vsa send accounting

• Ensure that you run IOS sensor-specific commands.

• Enabling Accounting Augmentation

You must enable the network access devices to add Cisco IOS sensor protocol data to the RADIUS accounting
messages and to generate additional accounting events when it detects new sensor protocol data. This means that any
RADIUS accounting message should include all CDP, LLDP, and DHCP attributes.
 Enter the following global command:
device-sensor accounting
• Disabling Accounting Augmentation
To disable (accounting) network access devices and add Cisco IOS sensor protocol data to the RADIUS accounting
messages for sessions that are hosted on a given port (if the accounting feature is globally enabled), enter the following
command at the appropriate port:
no device-sensor accounting
• TLV Change Tracking
By default, for each supported peer protocol, client notifications and accounting events are generated only when an
incoming packet includes a type, length, and value (TLV) that has not been received previously in the context of a
given session.
You must enable client notifications and accounting events for all TLV changes where there are either new TLVs, or
where previously received TLVs have different values. Enter the following command:
device-sensor notify all-changes

• Be sure that you disable the Cisco IOS Device Classifier (local analyzer) in the network access devices. Enter the
following command:

no macro auto monitor

Support for Cisco IND Controllers by ISE Profiler

Cisco ISE can profile and display the status of devices attached to a Cisco Industrial Network Device (IND). PxGrid
connects Cisco ISE and the Cisco Industrial Network Director to communicate endpoint (IoT) data. pxGrid on Cisco
ISE consumes Cisco IND events, and queries Cisco IND to update endpoint type.
Cisco ISE profiler has dictionary attributes for IoT devices. Choose Policy > Policy Elements > Dictionaries, and select
IOTASSET from the list of System Dictionaries to see the dictionary attributes.

Guidelines and Recommendations

If you have several ISE nodes configured for profiling, we recommend that you enable pxGrid for Cisco IND on only
one node.
Multiple Cisco IND devices can connect to a single ISE.

If the same endpoint is received from two or more publishers (Cisco IND), Cisco ISE only keeps the last publisher's
data for that endpoint.
Cisco ISE gets Cisco IND data from the service names com.cisco.endpoint.asset and
/topic/com.cisco.endpoint.assetin pxGrid.
Cisco IND Profiling Process Flow
Cisco IND Asset discovery finds an IoT device and publishes the endpoint data for that device to pxGrid. Cisco
ISE sees the event on pxGrid, and gets the endpoint data. Profiler policies in Cisco ISE assign the device data to
attributes in the ISE profiler dictionary, and applies those attributes to the endpoint in Cisco ISE.
IoT endpoint data which does not meet the existing attributes in Cisco ISE are not saved. But you can create more
attributes in Cisco ISE, and register them with Cisco IND.
Cisco ISE does a bulk download of endpoints when the connection to Cisco IND through pxGrid is first
established. If there is a network failure, Cisco ISE does another bulk download of accumulated endpoint changes.

Configure Cisco ISE and Cisco IND for IND Profiling

1. Choose Administration > Deployment. Edit the PSN that you plan to use as pxGrid consumer, and
enable pxGrid. This PSN is the one that creates endpoints from pxGrid data published by Cisco IND and
profiling.
2. Choose Administration > pxGrid Services to verify that pxGrid is running. Then click the
Certificates
tab, and fill in the certificate fields. Click Create to issue the certificate and download the certificate.
• For I want to, select “Generate a single certificate (without a certificate signing request),
Common Name, and enter a name for the Cisco IND you are connecting with.
• For Certificate Download Format, choose PKS12 format.
• For Certificate Password, create a password.

3. In Cisco IND, choose Settings > pxGrid, and click Download .pem IND certificate.
Keep this window open.
4. In Cisco ISE, choose Administration > pxGrid Services > All Clients. When you see the Cisco
IND pxGrid client, approve it.
5. In Cisco IND, move the slider to enable pxGrid. Another screen opens, where you define the
location of the ISE node, the name of the certificate that you entered for this pxGrid server in ISE,
and the password you provided. Click Upload Certificate, and locate the ISE pxGrid PEM file.
6. In ISE, choose Administration > Certificates > Trusted Certificates. Click Import and enter the path to
the certificate you got from Cisco IND.
7. In Cisco IND, click Activate.

8. In Cisco ISE, choose Adminstration > Deployment. Select the PSN you are using for the Cisco IND
connection, select the Profiling window, and enable the pxGrid probe.
9. The pxGrid connection between ISE and Cisco IND is now active. Verify that by displaying the IoT
endpoints that Cisco IND has found.
Add an Attribute for IND Profiling
Cisco IND may return attributes that are not in the ISE dictionary. You can add more attributes to Cisco ISE,
so you can more accurately profile that IoT device. To add a new attribute, you create a custom attribute in
Cisco ISE, and send that attribute to Cisco IND over pxGrid.
1. Choose Administration > Identity Management > Settings, and select Endpoint
Custom Attributes. Create an attribute endpoint attribute.
2. You can now use this attribute in a profiler policy to identify assets with the new
attribute. Choose Policy > Profiling, and create a new profiler policy. In the Rules
section, create a new rule. When you add an attribute/value, select the
CUSTOMATTRIBUTE folder, and the custom attribute you created.

Cisco ISE Support for MUD

Manufacturer Usage Descriptor (MUD) is an IETF standard, which defines a way to on-board IoT devices. It
provides seamless visibility and segmentation automation of IoT devices. MUD has been approved in IETF
process, and released as RFC8520.
Cisco ISE, Release 2.6 and later supports identification of IoT devices. Cisco ISE automatically creates
profiling policies and Endpoint Identity Groups. MUD supports profiling IoT devices, creating profiling
policies dynamically, and automating the entire process of creating policies and Endpoint Identity Groups.
Administrators can use these profiling policies to create manually Authorization Policies and Profiles. IoT
devices sending MUD URL in DHCP and LLDP packets are on board, using those profiles and policies.
Cisco ISE performs unsigned classification of IoT devices. Cisco ISE does not store the MUD attributes; the
attributes are only used in the current session. In the Context and Visibility > Endpoints window, you can
filter IoT devices by the Endpoint Profile field.
The following devices support sending MUD data to Cisco ISE:
• Cisco Catalyst 3850 Series Switches running Cisco IOS XE Version 16.9.1 & 16.9.2
• Cisco Catalyst Digital Building Series Switches running Cisco IOS Version 15.2(6)E2
• Cisco Industrial Ethernet 4000 Series Switches running Cisco IOS Version 15.2(6)E2

• Internet of Things (IoT) devices with embedded MUD functionality

Cisco ISE supports the following profiling protocols and profiling probes:
• LLDP and Radius - TLV 127
• DHCP - Option 161

Both fields can be sent to Cisco ISE by IOS Device Sensor.

 Configuring ISE for MUD
1. Choose Work Centers > Profiler > Profiler Settings , and check the Enable profiling for
MUD check box.
2. Add the Network Access Device that can send MUD URIs to ISE. To add network devices, choose
Administration > Network Resources > Network Devices.
3. Verify that the MUD-URL connection is working.
a. Choose Context Visibility > Endpoints, and find IoT endpoints that ISE successfully
classified. You can filter IoT devices by the Endpoint profile name, which starts with
IOT-MUD.
b. Click the endpoint MAC address of one of the IoT devices, and select the attribute tag.
Verify that there is a mud-url in the list of attributes.
c. Choose Policy > Profiling and filter the list by selecting IOT Created for System
Type.

4. Optionally configure debug logging for the new IoT devices.

a. Choose System > Logging > Debug Log Configuration, and select the ISE node that has
the MUD configuration.
b. Select Debug Log Configuration in the left menu, and then select profiler.

As more IoT devices are classified, all devices of the same category or group with same MUD-URL are
assigned to the same endpoint group. For example, if a Molex light connects, and is classified, a profiler
group is created for that Molex light. As more Molex lights of the same type (with the same MUD-URL) are
classified, they inherit the same classification or endpoint identity group.

Verify MUD Traffic Flow in ISE and the Switch

1. Before turning on the IoT device, either connect port or unshut the interface:
a. Start packet capture at ISE.
b. Start packet capture at switch ports.

2. View the following output on the switch:

a. show device-sensor cache all
b. show access-session
c. show radius statistics

3. Turn on the IoT devices.

4. Repeat the following every minute:
a. show device-sensor cache all
b. show access-session
 c. show radius statistics

5. Wait for 3 to 5 minutes for all the devices show up on ISE.

6. Stop both the ISE and switch packet captures.
7. Repeat the following every minute:
a. show device-sensor cache all
b. show access-session
c. show radius statistics

Multi-Factor Classification for Enhanced Endpoint Visibility

You can create nuanced authorization policies using four specific attributes from the endpoints connecting to
your network. The Multi-Factor Classification (MFC) profiler uses various profiling probes to fetch four new
endpoint attributes to the Cisco ISE authorization policy creation workflows:
• MFC Endpoint Type, for example, Workstation, Printer, Network Device

• MFC Hardware Manufacture, for example, Xerox Corporation, Google, Inc., TP-LINK
TECHNOLOGIES CO.,LTD
• MFC Hardware Mode, for example, Xerox-Printer-Phaser3250, TP-LINK-Device
• MFC Operating System, for example, Windows, Lexmark-OS

To receive multifactor classification endpoint attributes, we recommend that you enable the following probes:
• Active Directory
• DHCP

• DHCP SPAN

• DNS

• HTTP

• NetFlow

• Network Scan (NMAP)

• RADIUS

• SNMP Trap

• SNMP Query

Multifactor classification adds four new labels as endpoint attributes, enabling you to create effective
authorization policies that enhance endpoint visibility. The multifactor classification labels and the collected
data can be exported as reports.
To view and use multifactor classification attributes, you must have Advantage licenses in your Cisco ISE
deployment.
The multifactor classification profiler is enabled by default in Cisco ISE Release 3.3 and runs on Policy
Service Nodes (PSN) and the primary Policy Administration Node (PAN).
To disable multifactor classification, in the Cisco ISE administration portal, choose Work Centers > Profiler
> Settings > Profiler Settings. In the MFC Profiling area, uncheck the MFC Profiling and AI Rules
check box.
Disabling MFC Profiling stops the Multi-Factor Classification feature on all the Cisco ISE PSNs. Data
collection until the time of disablement is retained in Cisco ISE. You might continue to view the old data
in the Context Visibility > Endpoints > Authentication window.
Cisco AI-ML Rule Proposals for Endpoint Profiling does not work when you uncheck the MFC Profiling
and AI Rules check box.
The attribute data fetched by the Multi-Factor Classification feature is displayed in the Context Visibility
> Endpoints > Authentication window. Four new columns display the endpoint attribute data—MFC
Endpoint Type, MFC Hardware Manufacturer, MFC Hardware Model, MFC Operating System.
Figure 26: Multi-Factor Classification Endpoint Attributes in the Context Visibility > Endpoints Window

Rule Prioritization
Profiling rules have the following inalterable order of priority in multifactor classification, with the first
rule having the highest priority:
1. System Rules
a. Cisco-managed direct mapping attribute values. The dictionary lookup order is
MDM, Wi-Fi Device Analytics, IOT-Assets, Posture, and ACIDEX.
b. Cisco-managed MFC rules—Existing profiling policies in Cisco ISE that
generate multifactor classification labels.
2. AI-ML rules—These are user-accepted AI-ML profiling policies that generate
multifactor classification labels.
3. System library rules—Cisco-managed user agent and OUI rules.
If an MFC label is provided by a higher priority rule, the label is not overwritten by a lower priority rule.
Consider a scenario where a system rule provides an endpoint's Hardware Manufacturer label. If an AI-
ML rule exists for the endpoint containing all four labels, the Hardware Manufacturer value from the
system rule is retained. Only the other three labels are taken from the AI-ML rule.
Create Authorization Policy Sets Using Multifactor Classification Attributes
You can create authorization policy sets using multifactor classification attributes in the Policy > Policy Sets
> Default > Authorization Policy window.
Multifactor classification attributes are automatically added to the Endpoints Dictionary. When you create
a new policy or update an existing one, you can choose from the four MFC-prefixed attributes to leverage
these details and define a focused authorization policy.
The following image displays the four multifactor classification attributes available for use in the conditions
studio, along with an example of a complete policy set that uses multifactor classification endpoint attributes:
Figure 27: Authorization Policies with Conditions that Use Multifactor Classification Attributes

The ordering of the policy sets in the Authorization Policy area is important. An endpoint is profiled according
to the first policy set it matches. We recommend that you place your policy set with multifactor classification
attribute conditions ahead of other policy sets to effectively use this nuanced endpoint information.
To view the endpoints that have matched these policy sets, go to the Operations > RADIUS > Live Logs
window. If there are any changes to an endpoint’s profiling because of the newly defined policies, a CoA is
automatically triggered.

Troubleshooting Multifactor Classification

To view logs for troubleshooting the Multi-Factor Classification feature, download a support
bundle:
1. Choose Operations > Troubleshoot > Download Logs.
2. On the left pane, click the node for which you want to generate a support bundle.
3. In the Debug Logs tab, select the required logs from the pi-profiler and profiler sections.
4. In the Support Bundle tab, check the Include debug logs check box.
5. Click Create Support Bundle.
 You can configure the severity level for logs related to the Multi-Factor Classification feature in the Operations
> Troubleshoot > Debug Wizard > Debug Profile Configuration window:
1. Click Profiling.
2. For the component MFC Profiler choose the desired severity level from the Log Level drop-
down list.
3. Click Save.

Services Enabled by Cisco AI Analytics

Cisco AI-ML Rule Proposals for Endpoint Profiling
Cisco ISE now provides profiling suggestions based on continuous learning across networks, helping you to
enhance endpoint profiling and management. You can use these suggestions to reduce the number of unknown
or unprofiled endpoints in your network.
To receive machine learning-powered profiling proposals you must enable Cisco AI Analytics to allow
information sharing between Cisco ISE and the Cisco AI Analytics system.
The following prerequisites apply for Cisco AI Analytics:
• You must have Smart Licensing enabled with registered Advantage licenses.
• The licensing methods SSM On-Prem Server and Specific License Reservation (SLR) are not in use.
• You must have pxGrid services enabled on at least one Cisco ISE node.

To receive AI Proposals, the Multi-Factor Classification for Enhanced Endpoint Visibility feature must be
enabled in the Work Centers > Profiler > Settings > Profiler Settings window. This feature is enabled in
Cisco ISE by default.

If both Cisco AI Analytics and MFC Profiling features are enabled, you can expect AI proposals for
the endpoints that have at least two endpoint attribute values. We recommend that you enable the
following sources for the AI proposals engine:
• Active Directory
• DHCP

• DHCP SPAN

• DNS

• HTTP

• Netflow
• Network Scan (NMAP)
• RADIUS
• SNMP Trap
• SNMP Query
The AI proposals engine does not process unique endpoint identifiers like IP and MAC addresses.
You can view, review, and apply AI Proposals in the Context Visibility > Endpoints > Endpoint
Classification window.
Cisco ISE shares any new or modified endpoint information with the AI proposals engine every 12 hours.
Endpoint data collected over the last 7 days are analyzed every 24 hours for ML modeling and rule
proposal creation.

Use AI Proposals to Reduce Unknowns in Your Network

In the Context Visibility > Endpoints > Endpoint Classification window, in the AI Proposals dashlet, click
Review to view the AI proposals generated for your Cisco ISE.
Based on continuous learning across networks, the AI Proposals present classification rules and labels for
the unknown endpoints in your network. Each endpoint is part of only one proposal group.
Each proposal group contains endpoints that:
• May or may not have been profiled by system rules
• May or may not have a label suggestion for Multi-Factor Classification fields

When you apply an AI-proposed rule, only the unknown and unprofiled endpoints that are part of the
proposal group are impacted. Endpoints that are already profiled by existing system rules are not reprofiled
or impacted in any way.
The AI Proposals window displays endpoint attributes from the Multi-Factor Classification (MFC)
profiler. Each column displays the suggested label and the percentage of endpoints in the group that are
already profiled.
Click View Proposals for the endpoint group that you want to review.
Figure 28: AI Proposals for an Endpoint Group
 A slide-in pane displays the rule suggestion and allows you to name the profiling policies and update label
values as required. The Profile Rule and Attributes tab displays the number of unknown endpoints in the
group, and the attribute information that informed the AI proposal. The tab also displays the last known
network access devices for the endpoints.
The Endpoints tab displays the list of endpoints in the selected proposal group.
After you edit the labels as required and review the details of the AI proposal, you can choose to accept or
reject the proposal by clicking the relevant button at the end of the pane. You cannot modify the rule condition
for a proposal. Accepting the profiling rule applies the proposal to the unknown endpoints in the selected
endpoint group.
If you reject the grouping, the proposal is removed from your Cisco ISE and will not be presented again.

Certificate Renewal for Cisco AI Analytics Agent

The communication between the Cisco AI Analytics agent and the cloud is secured using TLS 1.2 with strong
encryption. Mutual authentication between the agent and the cloud services is ensured using X.509 certificates.
The client certificate used by the agent is issued during the tenant registration process.
This certificate is automatically renewed before the expiration date. At the time of auto-renewal, Cisco ISE
must be running, and the agent must be able to reach the cloud endpoint.
If this certificate is not renewed before the expiration date, the agent can no longer communicate with the
cloud and the Cisco AI Analytics feature will cease to function.
If the agent client certificate has expired on your system, the certificate must be renewed to restore cloud
connectivity. Contact the Cisco Technical Assistance Center (TAC) for assistance with the certificate renewal.
Cisco TAC will provide the required OTP (onboarding key) for the certificate renewal.

Profiler Conditions
Profiling conditions are policy elements and are similar to other conditions. However unlike authentication,
authorization, and guest conditions, the profiling conditions can be based on a limited number of attributes.
The Profiler Conditions page lists the attributes that are available in Cisco ISE and their description.
Profiler conditions can be one of the following:
• Cisco Provided: Cisco ISE includes predefined profiling conditions when deployed and they are
identified as Cisco Provided in the Profiler Conditions window. You cannot delete Cisco Provided
profiling conditions.
You can also find Cisco Provided conditions in the System profiler dictionaries in the following location:
Policy > Policy Elements > Dictionaries > System.
For example, MAC dictionary. For some products, the OUI (Organizationally Unique Identifier) is an
unique attribute that you can use it first for identifying the manufacturing organization of devices. It is a
component of the device MAC address. The MAC dictionary contains the MACAddress and OUI
attributes.
 • Administrator Created: Profiler conditions that you create as an administrator of Cisco ISE or
predefined profiling conditions that are duplicated are identified as Administrator Created. You can
create a profiler condition of DHCP, MAC, SNMP, IP, RADIUS, NetFlow, CDP, LLDP, and
NMAP types using the profiler dictionaries in the Profiler Conditions window.

Although, the recommended upper limit for the number of profiling policies is 1000, you can stretch up to
2000 profiling policies.

Profiling Network Scan Actions

An endpoint scan action is a configurable action that can be referred to in an endpoint profiling policy,
and that is triggered when the conditions that are associated with the network scan action are met.
An endpoint scan is used to scan endpoints in order to limit resources usage in the Cisco ISE system. A
network scan action scans a single endpoint, unlike resource-intensive network scans. It improves the
overall classification of endpoints, and redefines an endpoint profile for an endpoint. Endpoint scans can be
processed only one at a time.
You can associate a single network scan action to an endpoint profiling policy. Cisco ISE predefines
three scanning types for a network scan action, which can include one or all three scanning types: for
instance, an OS-scan, an SNMPPortsAndOS-scan, and a CommonPortsAndOS-scan. You cannot edit or
delete OS-scan, SNMPPortsAndOS-scan, and CommonPortsAndOS-scans, which are predefined
network scan actions in Cisco ISE. You can also create a new network scan action of your own.
Once an endpoint is appropriately profiled, the configured network scan action cannot be used against
that endpoint. For example, scanning an Apple-Device allows you to classify the scanned endpoint to an
Apple device. Once an OS-scan determines the operating system that an endpoint is running, it is no longer
matched to an Apple-Device profile, but it is matched to an appropriate profile for an Apple device.

NMAP Operating System Scan

The operating system scan (OS-scan) type scans for an operating system (and OS version) that an endpoint
is running. This is a resource intensive scan.
The NMAP tool has limitations on OS-scan which may cause unreliable results. For example, when scanning
an operating system of network devices such as switches and routers, the NMAP OS-scan may provide an

incorrect operating-system attribute for those devices. Cisco ISE displays the operating-system attribute,
even if the accuracy is not 100%.
You should configure endpoint profiling policies that use the NMAP operating-system attribute in their
rules to have low certainty value conditions (Certainty Factor values). We recommend that whenever you
create an endpoint profiling policy based on the NMAP:operating-system attribute, include an AND
condition to help filter out false results from NMAP.
 The following NMAP command scans the operating system when you associate Scan OS with an endpoint profiling
policy:
nmap -sS -O -F -oN /opt/CSCOcpm/logs/nmap.log -append-output -oX - <IP-address>

The following NMAP command scans a subnet and sends the output to nmapSubnet.log:
nmap -O -sU -p U:161,162 -oN /opt/CSCOcpm/logs/nmapSubnet.log
--append-output -oX - <subnet>

Table 104: NMAP Commands for a Manual Subnet Scan

-O Enables OS detection
-sU UDP scan
-p <port ranges> Scans only specified ports. For example, U:161, 162

oN Normal output
oX XML output

Operating System Ports

The following table lists the TCP ports that NMAP uses for OS scanning. In addition, NMAP uses ICMP and UDP port 51824.

1 3 4 6 7 9 13 17 19
20 21 22 23 24 25 26 30 32
33 37 42 43 49 53 70 79 80
81 82 83 84 85 88 89 90 99
100 106 109 110 111 113 119 125 135
139 143 144 146 161 163 179 199 211
212 222 254 255 256 259 264 280 301
306 311 340 366 389 406 407 416 417
425 427 443 444 445 458 464 465 481
497 500 512 513 514 515 524 541 543
544 545 548 554 555 563 587 593 616
617 625 631 636 646 648 666 667 668
683 687 691 700 705 711 714 720 722
726 749 765 777 783 787 800 801 808
843 873 880 888 898 900 901 902 903
911 912 981 987 990 992 993 995 999
1000 1001 1002 1007 1009 1010 1011 1021 1022
1023 1024 1025 1026 1027 1028 1029 1030 1031
1032 1033 1034 1035 1036 1037 1038 1039 1040-1100
1102 1104 1105 1106 1107 1108 1110 1111 1112
1113 1114 1117 1119 1121 1122 1123 1124 1126
1130 1131 1132 1137 1138 1141 1145 1147 1148
1149 1151 1152 1154 1163 1164 1165 1166 1169
1174 1175 1183 1185 1186 1187 1192 1198 1199
1201 1213 1216 1217 1218 1233 1234 1236 1244
1247 1248 1259 1271 1272 1277 1287 1296 1300
1301 1309 1310 1311 1322 1328 1334 1352 1417
1433 1434 1443 1455 1461 1494 1500 1501 1503
1521 1524 1533 1556 1580 1583 1594 1600 1641
1658 1666 1687 1688 1700 1717 1718 1719 1720
1721 1723 1755 1761 1782 1783 1801 1805 1812
1839 1840 1862 1863 1864 1875 1900 1914 1935
1947 1971 1972 1974 1984 1998-2010 2013 2020 2021
2022 2030 2033 2034 2035 2038 2040-2043 2045-2049 2065
2068 2099 2100 2103 2105-2107 2111 2119 2121 2126
2135 2144 2160 2161 2170 2179 2190 2191 2196
2200 2222 2251 2260 2288 2301 2323 2366 2381-2383
2393 2394 2399 2401 2492 2500 2522 2525 2557
2601 2602 2604 2605 2607 2608 2638 2701 2702
2710 2717 2718 2725 2800 2809 2811 2869 2875
2909 2910 2920 2967 2968 2998 3000 3001 3003
3005 3006 3007 3011 3013 3017 3030 3031 3052
3071 3077 3128 3168 3211 3221 3260 3261 3268
3269 3283 3300 3301 3306 3322 3323 3324 3325
3333 3351 3367 3369 3370 3371 3372 3389 3390
3404 3476 3493 3517 3527 3546 3551 3580 3659
3689 3690 3703 3737 3766 3784 3800 3801 3809
3814 3826 3827 3828 3851 3869 3871 3878 3880
3889 3905 3914 3918 3920 3945 3971 3986 3995
3998 4000-4006 4045 4111 4125 4126 4129 4224 4242
4279 4321 4343 4443 4444 4445 4446 4449 4550
4567 4662 4848 4899 4900 4998 5000-5004 5009 5030
5033 5050 5051 5054 5060 5061 5080 5087 5100
5101 5102 5120 5190 5200 5214 5221 5222 5225
5226 5269 5280 5298 5357 5405 5414 5431 5432
5440 5500 5510 5544 5550 5555 5560 5566 5631
5633 5666 5678 5679 5718 5730 5800 5801 5802
5810 5811 5815 5822 5825 5850 5859 5862 5877
5900-5907 5910 5911 5915 5922 5925 5950 5952 5959
5960-5963 5987-5989 5998-6007 6009 6025 6059 6100 6101 6106
6112 6123 6129 6156 6346 6389 6502 6510 6543
6547 6565-6567 6580 6646 6666 6667 6668 6669 6689
6692 6699 6779 6788 6789 6792 6839 6881 6901
6969 7000 7001 7002 7004 7007 7019 7025 7070
7100 7103 7106 7200 7201 7402 7435 7443 7496
7512 7625 7627 7676 7741 7777 7778 7800 7911
7920 7921 7937 7938 7999 8000 8001 8002 8007
8008 8009 8010 8011 8021 8022 8031 8042 8045
8080-8090 8093 8099 8100 8180 8181 8192 8193 8194
8200 8222 8254 8290 8291 8292 8300 8333 8383
8400 8402 8443 8500 8600 8649 8651 8652 8654
8701 8800 8873 8888 8899 8994 9000 9001 9002
9003 9009 9010 9011 9040 9050 9071 9080 9081
9090 9091 9099 9100 9101 9102 9103 9110 9111
9200 9207 9220 9290 9415 9418 9485 9500 9502
9503 9535 9575 9593 9594 9595 9618 9666 9876
9877 9878 9898 9900 9917 9929 9943 9944 9968
9998 9999 10000 10001 10002 10003 10004 10009 10010
10012 10024 10025 10082 10180 10215 10243 10566 10616
10617 10621 10626 10628 10629 10778 11110 11111 11967
12000 12174 12265 12345 13456 13722 13782 13783 14000
14238 14441 14442 15000 15002 15003 15004 15660 15742
16000 16001 16012 16016 16018 16080 16113 16992 16993
17877 17988 18040 18101 18988 19101 19283 19315 19350
19780 19801 19842 20000 20005 20031 20221 20222 20828
21571 22939 23502 24444 24800 25734 25735 26214 27000
27352 27353 27355 27356 27715 28201 30000 30718 30951
31038 31337 32768 32769 32770 32771 32772 32773 32774
32775 32776 32777 32778 32779 32780 32781 32782 32783
32784 32785 33354 33899 34571 34572 34573 34601 35500
36869 38292 40193 40911 41511 42510 44176 44442 44443
44501 45100 48080 49152 49153 49154 49155 49156 49157
49158 49159 49160 49161 49163 49165 49167 49175 49176
49400 49999 50000 50001 50002 50003 50006 50300 50389
50500 50636 50800 51103 51493 52673 52822 52848 52869
54045 54328 55055 55056 55555 55600 56737 56738 57294
57797 58080 60020 60443 61532 61900 62078 63331 64623
64680 65000 65129 65389

NMAP SNMP Port Scan

The SNMPPortsAndOS-scan type scans an operating system (and OS version) that an endpoint is running
and triggers an SNMP Query when SNMP ports (161 and 162) are open. It can be used for endpoints that are
identified and matched initially with an Unknown profile for better classification.
The following NMAP command scans SNMP ports (UDP 161 and 162) when you associate the Scan SNMP
Port with an endpoint profiling policy:
nmap -sU -p U:161,162 -oN /opt/CSCOcpm/logs/nmap.log --append-output -oX - <IP-address>

Table 105: NMAP Commands for an Endpoint SNMP Port Scan

-sU UDP scan.

-p <port-ranges> Scans only specified ports. For example, scans UDP ports 161 and 16.2
oN Normal output.
oX XML output.
IP-address IP-address of an endpoint that is scanned.
 NMAP Common Ports Scan
The CommonPortsAndOS-scan type scans an operating system (and OS version) that an endpoint is running and common ports
(TCP and UDP), but not SNMP ports. The following NMAP command scans common ports when you associate Scan Common
Port with an endpoint profiling policy:nmap -sTU -p
T:21,22,23,25,53,80,110,135,139,143,443,445,3306,3389,8080,U:53,67,68,123,135,137,138,139,161,445,500,520,631,1434,1900-oN
/opt/CSCOcpm/logs/nmap.log --append-output -oX - <IP address>

Table 106: NMAP Commands for an Endpoint Common Ports Scan

-sTU Both TCP connect scan and UDP scan.

-p <port ranges> Scans TCP ports: 21,22,23,25,53,80,110,135,139,143, 443,445,3306,3389,8080 and
UDP ports: 53,67,68,123,135,137, 138,139,161,445,500,520,631,1434,1900
oN Normal output.
oX XML output.
IP address IP address of an endpoint that is scanned.

Common Ports

The following table lists the common ports that NMAP uses for scanning.
Table 107: Common Ports

TCP Ports UDP Ports

Ports Service Ports Service
21/tcp ftp 53/udp domain
22/tcp ssh 67/udp dhcps
23/tcp telnet 68/udp dhcpc
25/tcp smtp 123/udp ntp
53/tcp domain 135/udp msrpc
80/tcp http 137/udp netbios-ns
110/tcp pop3 138/udp netbios-dgm
135/tcp msrpc 139/udp netbios-ssn
139/tcp netbios-ssn 161/udp snmp
143/tcp imap 445/udp microsoft-ds
443/tcp https 500/udp isakmp
445/tcp microsoft-ds 520/udp route
3389/tcp ms-term-serv 1434/udp ms-sql-m
8080/tcp http-proxy 1900/udp upnp

NMAP Custom Ports Scan

In addition to the common ports, you can use custom ports (Work Centers > Profiler > Policy Elements >
NMAP Scan Actions or Policy > Policy Elements > Results > Profiling > Network Scan (NMAP) Actions) to
specify automatic and manual NMAP scan actions. NMAP probes collect the attributes from endpoints via the
specified custom ports that are open. These attributes are updated in the endpoint's attribute list in the ISE Identities
page (Work Centers > Network Access > Identities > Endpoints). You can specify up to 10 UDP and 10 TCP
ports for each scan action. You cannot use the same port numbers that you have specified as common ports
NMAP Include Service Version Information Scan
The Include Service Version Information NMAP probe automatically scans the endpoints to better classify
them, by collecting information about services running on the device. The service version option can be
combined with common ports or custom ports.
Example: CLI Command: nmap -sV -p T:8083 172.21.75.217 Output:

Port State Service Version

8083/tcp open http McAfee ePolicy Orchestrator Agent 4.8.0.1500
(ePOServerName: WIN2008EPO,

NMAP SMB Discovery Scan

NMAP SMB Discovery scan helps differentiate the Windows versions, and results in a better endpoint profiling.
You can configure the NMAP scan action to run the SMB discovery script that is provided by NMAP.
The NMAP scan action is incorporated within the windows default policies and when the endpoint matches
the policy and the scanning rule, the endpoint is scanned and the result helps to determine the exact windows
version. The policy will be then configured on the feed service and new pre-defined NMAP scan is created
with the SMB discovery option.
The NMAP scan action is invoked by the Microsoft-Workstation policies and the result of the scan is saved
on the endpoint under the operating system attribute and leveraged to the Windows policies. You can also
find the SMB Discovery script option in the manual scan on the subnet.

SMB Discovery Attributes

When the SMB discovery script is executed on the endpoint, new SMB discovery attributes, such as
SMB.Operating-system, are added to the endpoint. These attributes are considered for updating the Windows
endpoint profiling policies on the feed service. When a SMB discovery script is run, the SMB discovery
attribute is prefixed with SMB, such as SMB.operating-system, SMB.lanmanager, SMB.server, SMB.fqdn,
SMB.domain, SMB.workgroup, and SMB.cpe.

Skip NMAP Host Discovery

Scanning every port of every single IP address is a time-consuming process. Depending on the purpose of the
scan, you can skip the NMAP host discovery of active endpoints.
If a NMAP scan is triggered after the classification of an endpoint, the profiler always skips the host discovery
of the endpoint. However, if a manual scan action is triggered after enabling the Skip NMAP Host Discovery
Scan, then host discovery is skipped.

Exclude Subnets from NMAP Scan

You can perform an NMAP scan to identify an endpoint's OS or SNMP port.
When performing the NMAP scan, you can exclude a whole subnet or IP range that should not be scanned by
NMAP. You can configure the subnet or IP range in the NMAP Scan Subnet Exclusions window (Work
Centers > Profiler > Settings > NMAP Scan Subnet Exclusions). This helps limit the load on your network
and saves a considerable amount of time.
For Manual NMAP scan, you can use the Run Manual NMAP Scan window (Work Centers > Profiler >
Manual Scans > Manual NMAP Scan > Configure NMAP Scan Subnet Exclusions At) to specify the
subnet or IP range.

Manual NMAP Scan Settings

You can perform a manual NMAP scan (Work Centers > Profiler > Manual Scans > Manual NMAP Scan) using the scan options
that are available for automatic NMAP scan. You can choose either the scan options or the predefined ones.

Field Name Usage Guidelines

Node Choose the ISE node from which the NMAP scan is run.

Manual Scan Enter the range of subnet IP addresses of endpoints for which you want to run the
Subnet NMAP scan.

Configure NMAP Scan You will be directed to the Work Centers > Profiler > Settings > NMAP Scan
Subnet Exclusions At Subnet Exclusions window. Specify the IP address and subnet mask that should be
excluded. If there is a match, the NMAP scan is not run.

NMAP Scan You can do one of the following:

Subnet
• Specify Scan Options
• Select an Existing NMAP Scan
Specify Scan Select the required scan options: OS, SNMP Port, Common Ports, Custom Ports,
Options Include Service Version Information, Run SMB Discovery Script, Skip NMAP Host
Discovery.

Select an Existing NMAP Displays the Existing NMAP Scan Actions drop-down list that displays the default
Scan profiler NMAP scan actions.

Reset to Default Scan Click this option to restore default settings (all scan options are checked).
Options

Save as NMAP Scan Enter an action name and a description.

Action

Profiler Endpoint Custom Attributes

Choose Administration > Identity Management > Settings > Endpoint Custom Attributes to assign
attributes to endpoints, besides the attributes that the endpoint gathers from the probe. The endpoint custom
attributes can be used in authorization policies to profile endpoints.
You can create a maximum of 100 endpoint custom attributes. The types of endpoint custom attributes
supported are: Int, String, Long, Boolean, and Float.
You can add values for the endpoint custom attributes in the Context Directory > Endpoints > Endpoint
Classification window.
Use cases for endpoint custom attributes include, to allow or block devices based on certain attributes or to
assign certain privileges based on the authorization.
Endpoint Profiling Policy Rules
You can define a rule that allows you to choose one or more profiling conditions from the library that are
previously created and saved in the policy elements library, and to associate an integer value for the certainty
factor for each condition, or associate either an exception action or a network scan action for that condition.
The exception action or the network scan action is used to trigger the configurable action while Cisco ISE is
evaluating the profiling policies with respect to the overall classification of endpoints.
When the rules in a given policy are evaluated separately with an OR operator, the certainty metric for each
rule contributes to the overall matching of the endpoint profiles into a specific category of endpoints. If the
rules of an endpoint profiling policy match, then the profiling policy and the matched policy are the same for
that endpoint when they are dynamically discovered on your network.

Profiling Policy Classification Priority

Cisco ISE classifies the devices in your network based on profiling policies that are either Cisco-provided or
created by administrators. From Cisco ISE Release 3.3, you can set a priority for which category of profiling
policies is used to classify the devices.
The Work Centers > Profiler > Profiling Policies page lists both Cisco-provided and administrator-created
profiling policies.
To prioritize a profiling policy type, go to Work Centers > Profiler > Settings > Profiler Settings. From
the Overlapping Classification Priority drop-down menu, choose Admin First or Cisco First. The default
value for this setting is admin-created policies first.
If there are both Cisco-provided and admin-created profiling policies that match for an endpoint, this
priority setting determines which profile is enforced through profiling workflows. The value of the
priority setting alone determines the policy that is matched with an endpoint, regardless of the certainty
factors of the overlapping policies.
For example, if Cisco Policy A with certainty factor 10 and Admin Policy B with certainty factor 5 are
available for an endpoint, if Admin First is the chosen priority, Admin Policy B is assigned to the
endpoint.
The configured priority also influences endpoint authorization based on the AuthZ conditions used such as
Endpoints:EndpointPolicy or Endpoints:LogicalProfile.

Logically Grouped Conditions in Rules

An endpoint profiling policy (profile) contains a single condition or a combination of multiple single
conditions that are logically combined using an AND or OR operator, against which you can check,
categorize, and group endpoints for a given rule in a policy.
A condition is used to check the collected endpoint attribute value against the value specified in the
condition for an endpoint. If you map more than one attribute, you can logically group the conditions,
which helps you to categorize endpoints on your network. You can check endpoints against one or more
such conditions with a corresponding certainty metric (an integer value that you define) associated with it
in a rule or trigger an exception action that is associated to the condition or a network scan action that is
associated to the condition.
 Certainty Factor
The minimum certainty metric in the profiling policy evaluates the matching profile for an endpoint. Each
rule in an endpoint profiling policy has a minimum certainty metric (an integer value) associated to the
profiling conditions. The certainty metric is a measure that is added for all the valid rules in an endpoint
profiling policy, which measures how each condition in an endpoint profiling policy contributes to
improve the overall classification of endpoints.
The certainty metric for each rule contributes to the overall matching of the endpoint profiles into a
specific category of endpoints. The certainty metric for all the valid rules are added together to form the
matching certainty. It must exceed the minimum certainty factor that is defined in an endpoint profiling
policy. By default, the minimum certainty factor for all new profiling policy rules and predefined
profiling policies is 10.

Endpoint Profiling Policies Settings

The following table describes the fields in the Endpoint Policies window. To view this window, click the
Menu icon ( ) and choose Policy > Profiling > Profiling Policies.

Table 109: Endpoint Profiling Policies Settings

Field Name Usage Guidelines

Name Enter the name of the endpoint profiling policy that you want to create.
Description Enter the description of the endpoint profiling policy that you want to create.
Policy Enabled By default, the Policy Enabled check box is checked to associate a matching profiling
policy when you profile an endpoint.
When unchecked, the endpoint profiling policy is excluded when you profile an
endpoint.
Minimum Certainty Enter the minimum value that you want to associate with the profiling policy. The default
Factor value is 10.
Exception Action Choose an exception action, which you want to associate with the conditions when
defining a rule in the profiling policy.
The default is NONE. The exception actions are defined in the following location:
Policy > Policy Elements > Results > Profiling > Exception Actions.
Network Scan (NMAP) Choose a network scan action from the list, which you want to associate with the
Action conditions when defining a rule in the profiling policy, if required.
The default is NONE. The exception actions are defined in the following location:
Policy > Policy Elements > Results > Profiling > Network Scan (NMAP) Actions.
Create an Identity Group Check one of the following options to create an endpoint identity group:
for the policy
• Yes, create matching Identity Group
• No, use existing Identity Group hierarchy
Yes, create matching Choose this option to use an existing profiling policy.
Identity Group
This option creates a matching identity group for those endpoints and the identity group will
be the child of the Profiled endpoint identity group when an endpoint profile matches an
existing profiling policy.
For example, the Xerox-Device endpoint identity group is created in the Endpoints
Identity Groups page when endpoints discovered on your network match the Xerox-
Device profile.
Field Name Usage Guidelines

No, use existing Check this check box to assign endpoints to the matching parent endpoint identity group using
Identity Group hierarchical construction of profiling policies and identity groups.
hierarchy
This option allows you to make use of the endpoint profiling policies hierarchy to assign endpoints to
one of the matching parent endpoint identity groups, as well as to the associated endpoint identity
groups to the parent identity group.
For example, endpoints that match an existing profile are grouped under the appropriate parent endpoint
identity group. Here, endpoints that match the Unknown profile are grouped under Unknown, and
endpoints that match an existing profile are grouped under the Profiled endpoint identity group. For
example,
• If endpoints match the Cisco-IP-Phone profile, then they are grouped under the Cisco-IP-Phone
endpoint identity group.
• If endpoints match the Workstation profile, then they are grouped under the Workstation
endpoint identity group.
The Cisco-IP-Phone and Workstation endpoint identity groups are associated to the Profiled
endpoint identity group in the system.
Parent Policy Choose a parent profiling policy that are defined in the system to which you want to associate the new
endpoint profiling policy.You can choose a parent profiling policy from which you can inherit rules and
conditions to its child.
Associated Choose one of the following CoA types that you want to associate with the endpoint profiling policy:
CoA Type
• No CoA
• Port Bounce
• Reauth
• Global Settings that is applied from the profiler configuration set in Administration
> System > Settings > Profiling
Rules One or more rules that are defined in endpoint profiling policies determine the matching profiling policy
for endpoints, which allows you to group endpoints according to their profiles. One or more profiling
conditions from the policy elements library are used in rules for validating endpoint attributes and their
values for the overall classification.
Conditions Click the plus [+] sign to expand the Conditions anchored overlay, and click the minus [-] sign, or click
outside the anchored overlay to close it.
Click Select Existing Condition from Library or Create New Condition (Advanced Option) .
Select Existing Condition from Library: You can define an expression by selecting Cisco predefined
conditions from the policy elements library.
Create New Condition (Advanced Option): You can define an expression by selecting attributes from
various system or user-defined dictionaries.
You can associate one of the following with the profiling conditions:
• An integer value for the certainty factor for each condition
• Either an exception action or a network scan action for that condition

Choose one of the following predefined settings to associate with the profiling condition:
• Certainty Factor Increases: Enter the certainty value for each rule, which can be added for all the
matching rules with respect to the overall classification.
• Take Exception Action: Triggers an exception action that is configured in the Exception Action
field for this endpoint profiling policy.
• Take Network Scan Action: Triggers a network scan action that is configured in the Network Scan
(NMAP) Action field for this endpoint profiling policy.
Select Existing You can do the following:
Condition from
• You can choose Cisco predefined conditions that are available in the policy elements library, and
Library
then use an AND or OR operator to add multiple conditions.
• Click the Action icon to do the following in the subsequent steps:
• Add Attribute or Value: You can add ad-hoc attribute or value pairs
• Add Condition from Library: You can add Cisco predefined conditions
• Duplicate: Create a copy of the selected condition
• Add Condition to Library: You can save ad-hoc attribute/value pairs that you create to the
policy elements library
• Delete: Delete the selected condition.
Create New You can do the following:
Condition
• You can add ad-hoc attribute/value pairs to your expression, and then use an AND or OR operator to
(Advance Option)
add multiple conditions.
• Click the Action icon to do the following in the subsequent steps:
• Add Attribute or Value: You can add ad-hoc attribute or value pairs
• Add Condition from Library: You can add Cisco predefined conditions
• Duplicate: Create a copy of the selected condition
• Add Condition to Library: You can save ad-hoc attribute/value pairs that you create to the
policy elements library
• Delete: Delete the selected condition. You can use the AND or OR operator