Cisco Identity Services Engine Administrator Guide, Release 2.4

Personas in Distributed Cisco ISE Deployments

A Cisco ISE node can assume the Administration, Policy Service, or Monitoring personas.

A Cisco ISE node can provide various services based on the persona that it assumes. Each node in a deployment can assume the Administration, Policy Service, and Monitoring personas. In a distributed deployment, you can have the following combination of nodes in your network:

Primary Policy Administration Node (primary PAN) and secondary Policy Administration Node (secondary PAN) for high availability
Primary Monitoring Node (primary MnT node) and Secondary Monitoring Node (secondary MnT node) for high availability
A pair of health check nodes or a single health check node for the primary PAN automatic failover
One or more Policy Service Nodes (PSNs) for the session failover

Environment download is successful, with only the up-and-running Cisco ISE node present in the result.

Configure a Cisco ISE Node

After you install a Cisco ISE node, all the default services provided by the Administration, Policy Service, and Monitoring personas run on it. This node is in a standalone state. You must log in to the Admin portal of the Cisco ISE node to configure it. You cannot edit the personas or services of a standalone Cisco ISE node. You can, however, edit the personas and services of the primary and secondary Cisco ISE nodes. You must first configure a primary ISE node and then register secondary ISE nodes to the primary ISE node.

If you are logging in to the node for the first time, you must change the default administrator password and install a valid license.

We recommend that you do not change the host name and the domain name configured on Cisco ISE in production. If required, reimage the appliance, make changes, and configure the details during the initial deployment.

Before you begin

You should have a basic understanding of how distributed deployments are set up in Cisco ISE. See Guidelines for Setting Up a Distributed Deployment.

Procedure

Step 1	Choose Administration > System > Deployment.
Step 2	Check the check box next to the Cisco ISE node that you want to configure, and click Edit.
Step 3	Enter the values, as required, and click Save.

Configure a Primary Policy Administration Node (PAN)

To set up a distributed deployment, you must first configure a Cisco ISE node as your primary PAN.

Procedure

Step 1	Choose Administration > System > Deployment. The Register button is disabled initially. To enable this button, you must configure a primary PAN.
Step 2	Check the check box next to the current node, and click Edit.
Step 3	Click Make Primary to configure your primary PAN.
Step 4	Click Save to save the node configuration.

What to do next

Add secondary nodes to your deployment.
Enable the profiler service and configure the probes, if required.

Register a Secondary Cisco ISE Node

You can register Cisco ISE nodes to the primary PAN to form a multinode deployment. Nodes in a deployment other than the primary PAN are referred to as secondary nodes. While registering a node, you can select the personas and services that must be enabled on the node. Registered nodes can be managed from the primary PAN (for example, managing the node personas, services, certificates, licenses, applying patches, and so on).

When a node is registered, the primary PAN pushes the configuration data to the secondary node, and the application server on the secondary node restarts. After the complete data, further configuration changes done on the primary PAN are replicated to the secondary node. The time taken for the changes to be replicated on the secondary node depends on various factors, such as the network latency, load on the system, and so on.

Before you begin

Ensure that the primary PAN and the node being registered are DNS resolvable to each other. If the node that is being registered uses an untrusted self-signed certificate, you are prompted with a certificate warning along with details of the certificate. If you accept the certificate, it is added to the trusted certificate store of the primary PAN to enable TLS communication with the node.

If the node uses a certificate that is not self-signed (for example, signed by an external CA), you must manually import the relevant certificate chain of that node to the trusted certificate store of the primary PAN. When you import the secondary node's certificate to the trusted certificate store, check the Trust for Authentication within ISE check box in the Trusted Certificates window for the PAN to validate the secondary node's certificate.

While registering a node with session services enabled (such as Network Access, Guest, Posture, and so on), you can add it to a node group. See Create a Policy Service Node Group for more details.

Procedure

Step 1	Log in to the primary PAN.
Step 2	Choose Administration > System > Deployment.
Step 3	Click Register to initiate registration of a secondary node.
Step 4	Enter the DNS-resolvable fully qualified domain name (FQDN) of the standalone node that you are going to register (in the format hostname.domain-name, for example, abc.xyz.com). The FQDN of the primary PAN and the node being registered must be resolvable from each other.
Step 5	Enter the GUI-based administrator credentials for the secondary node in the Username and Password fields.
Step 6	Click Next. The primary PAN tries to establish TLS communication (for the first time) with the node being registered. If the node uses a certificate that is trusted, you can proceed to Step 7. If the node uses a self-signed certificate that is not trusted, a certificate warning message is displayed is displays with details about the certificate (such as, Issued-to, Issued-by, Serial number, and so on), which can be verified against the actual certificate on the node. You can select the Import Certificate and Proceed option to trust this certificate and proceed with registration. Cisco ISE imports the default self-signed certificate of that node to the trusted certificate store of the primary PAN. If you do not want to use the default self-signed certificate, click Cancel Registration and manually import the relevant certificate chain of that node to the trusted certificate store of the primary PAN. When you import the secondary node's certificate to the trusted certificate store, check the Trust for Authentication within ISE check box for the PAN to validate the secondary node's certificate. If the node uses a CA-signed certificate, an error message is displayed that the registration cannot proceed until certificate trust is set up.
Step 7	Select the personas and services to be enabled on the node, and then click Save.

When a node is registered, an alarm (which confirms that a node has been added to the deployment) is generated on the primary PAN. You can view this alarm in the Alarms dashlet in the Cisco ISE GUI Dashboard. After the registered node is synchronized and restarted, you can log in to the secondary node GUI using the same credentials used on the primary PAN.

What to do next

For time-sensitive tasks such as guest user access and authorization, logging, and so on, ensure that the system time on your nodes is synchronized.
If you registered a secondary PAN, and are using the internal Cisco ISE CA service, you must back up the Cisco ISE CA certificates and keys from the primary PAN and restore them on the secondary PAN.
See the Backup and Restore of Cisco ISE CA Certificates and Keys section in the Basic Setup Chapter.

Support for Multiple Deployment Scenarios

Cisco ISE can be deployed across an enterprise infrastructure, supporting 802.1X wired, wireless, and Virtual Private Networks (VPNs).

The Cisco ISE architecture supports both standalone and distributed (also known as high availability or redundancy) deployments, where one machine assumes the primary role, and another backup machine assumes the secondary role. Cisco ISE features distinct configurable personas, services, and roles, which allow you to create and apply Cisco ISE services where they are needed in the network. The result is a comprehensive Cisco ISE deployment that operates as a fully functional and integrated system.

Cisco ISE nodes can be deployed with one or more of the Administration, Monitoring, and Policy Service personas. Each persona performs a different vital part in your overall network policy management topology. Installing Cisco ISE with an administration persona allows you to configure and manage your network from a centralized portal to promote efficiency and ease of use.

Cisco ISE Distributed Deployment

A deployment that has more than one Cisco ISE node is called a distributed deployment. To support failover and to improve performance, you can set up your deployment with multiple Cisco ISE nodes in a distributed fashion. In a Cisco ISE distributed deployment, the administration and monitoring activities are centralized, and processing is distributed across the PSNs. Depending on your performance needs, you can scale your deployment. Each Cisco ISE node in a deployment can assume any of the following personas: Administration, Policy Service, and Monitoring.

Cisco ISE Deployment Setup

After you install Cisco ISE on all your nodes, as described in the Cisco Identity Services Engine Hardware Installation Guide, the nodes come up in a standalone state. You must then define one node as your primary PAN. While defining your primary PAN, you must enable the administration and monitoring personas on that node. You can optionally enable the policy service persona on the primary PAN. After you complete the task of defining personas on the primary PAN, you can register other secondary nodes to the primary PAN and define personas for the secondary nodes.

All Cisco ISE system and functionality-related configurations should be done only on the primary PAN. The configuration changes that you perform on the primary PAN are replicated to all the secondary nodes in your deployment.

There must be at least one MnT in a distributed deployment. At the time of configuring your primary PAN, you must enable the Monitoring persona. After you register an MnT node in your deployment, you can edit the primary PAN and disable the Monitoring persona, if required.

Data Replication from Primary to Secondary ISE Nodes

When you register a Cisco ISE node as a secondary node, Cisco ISE immediately creates a data replication channel from the primary to the secondary node and begins the process of replication. Replication is the process of sharing Cisco ISE configuration data from the primary to the secondary nodes. Replication ensures consistency among the configuration data available in all the Cisco ISE nodes that are part of your deployment.

A full replication typically occurs when you first register a Cisco ISE node as a secondary node. Incremental replication occurs after a full replication and ensures that any new changes, such as additions, modifications, or deletions to the configuration data in the PAN are reflected in the secondary nodes. The process of replication ensures that all the Cisco ISE nodes in a deployment are in sync. You can view the status of replication in the Node Status column in the Deployment window of the Cisco ISE Admin portal. When you register a Cisco ISE node as a secondary node or perform a manual synchronization with the PAN, the node status shows an orange icon, indicating that the requested action is in progress. After the synchronization is complete, the node status turns green, indicating that the secondary node is synchronized with the PAN.

Cisco ISE Node Deregistration

To remove a node from a deployment, you must deregister it. When you deregister a secondary node from the primary PAN, the status of the deregistered node changes to standalone, and the connection between the primary and the secondary node is lost. Replication updates are no longer sent to the deregistered standalone node.

When a PSN is deregistered, the endpoint data is lost. If you want the PSN to retain the endpoint data after it becomes a standalone node, you can do one of the following:

Obtain a backup from the primary PAN, and when the PSN becomes a standalone node, restore this data backup on it.
Change the persona of the PSN to administration (secondary PAN), synchronize the data from the Deployment window of the Admin portal, and then deregister the node. This node will now have all the data. You can then add a secondary PAN to the existing deployment.

Note

You cannot deregister a primary PAN.

Guidelines for Setting Up a Distributed Deployment

Read the following statements carefully before you set up Cisco ISE in a distributed environment:

Choose a node type for the Cisco ISE server. You must choose a Cisco ISE node for administration, policy service, and monitoring capabilities.
Choose the same Network Time Protocol (NTP) server for all the nodes. To avoid timezone issues among the nodes, you must provide the same NTP server name during the setup of each node. This setting ensures that the reports and logs from the various nodes in your deployment are always synchronized with timestamps.
Configure the Cisco ISE administrator password when you install Cisco ISE. The previous Cisco ISE administrator default login credentials (admin/cisco) are no longer valid. Use the username and password that was created during the initial setup or the current password if it was changed later.
Configure the DNS server. Enter the IP addresses and fully qualified domain names (FQDNs) of all the Cisco ISE nodes that are part of your distributed deployment in the DNS server. Otherwise, node registration fails.
Configure the forward and the reverse DNS lookup for all the Cisco ISE nodes in your distributed deployment in the DNS server. Otherwise, you may run into deployment-related issues when registering and restarting Cisco ISE nodes. Performance might be degraded if reverse DNS lookup is not configured for all the nodes.
(Optional) Deregister a secondary Cisco ISE node from the primary PAN to uninstall Cisco ISE from it.
Back up the primary MnT, and restore the data to the new secondary MnT. This ensures that the history of the primary MnT is in sync with the new MnT because the new changes are replicated.
Ensure that the primary PAN and the standalone node that you are about to register as a secondary node are running the same version of Cisco ISE.
Enable Internal CA Settings on your Cisco ISE primary PAN before you add another node to your deployment to ensure that the Cisco ISE certificate services function as expected. To enable Internal CA Settings, choose Administration > System > Certificates > Certificate Authority > Internal CA Settings. See Cisco ISE CA Service.
While adding a new node to the deployment, make sure that the issuer certificate chain of wildcard certificates is part of the trusted certificates of the new node. When the new node is added to the deployment, the wildcard certificates are then replicated to the new node.
When configuring your Cisco ISE deployment to support Cisco TrustSec, or when Cisco ISE is integrated with Cisco DNA Center, do not configure a PSN as SXP-only. SXP is an interface between Cisco TrustSec and non-Cisco TrustSec devices. SXP does not communicate with the Cisco TrustSec-enabled network devices.

Menu Options Available on Primary and Secondary Nodes

The menu options that are available in Cisco ISE nodes that are a part of a distributed deployment depend on the personas that are enabled on them. You must perform all administration and monitoring activities through the primary PAN. For other tasks, you must use the secondary nodes. Therefore, the user interface of the secondary nodes provides limited menu options based on the persona that is enabled on them.

If a node assumes more than one persona, for example, the Policy Service persona, and a Monitoring persona with a primary role, then the menu options listed for the PSNs and the primary MnT are available on that node.

The following table lists the menu options that are available on the Cisco ISE nodes that assume different personas.

Table 1. Cisco ISE Nodes and Available Menu Options

Cisco ISE Node

Available Menu Options

All Nodes

View and configure the system time and the NTP server settings

Install the server certificate and manage certificate signing request. You can perform server certificate operations for all the nodes in the deployment through the primary PAN that centrally manages all the server certificates

Note

The private keys are not stored in the local database and are not copied from the relevant node. The private keys are stored in the local file system.

Primary Policy Administration node (primary PAN)

All menus and submenus

Primary Monitoring node (primary MnT node)

Provides access to monitoring data

Note

The Operations menu can be viewed only from the primary PAN. The Operations menu does not appear in the monitoring nodes in Cisco ISE 2.1 and later.

PSNs (Policy Service nodes)

Options to join, leave, and test the Active Directory connection are available. Each PSN must be separately joined to the Active Directory domain. You must first define the domain information and join the PAN to the Active Directory domain. Then, join the other PSNs to the Active Directory domain individually.

Secondary Policy Administration node (secondary PAN)

Option to promote the secondary PAN to primary PAN.

Note

After you have registered the secondary nodes to the primary PAN, while logging in to the Admin portal of any of the secondary nodes, you must use the login credentials of the primary PAN.

Deployment and Node Settings

The Deployment Nodes window enables you to configure the Cisco ISE (PAN, PSN, and MnT) nodes and to set up a deployment.

Deployment Nodes List Window

Table 2. Deployment Nodes List
Field Name	Usage Guidelines
Hostname	Displays the hostname of the node.
Node Type	Displays the node type. It can be one of the following: Cisco ISE (PAN, PSN, Mnt) nodes
Personas	(Only appears if the node type is Cisco ISE) Lists the personas that a Cisco ISE node has assumed, for example, Administration, Policy Service, Monitoring, or pxGrid. For example, Administration, Policy Service, Monitoring, or pxGrid.
Role	Indicates the role (primary, secondary, or standalone) that the Administration and Monitoring personas have assumed, if these personas are enabled on this node. The role can be any one or more of the following: PRI(A): Refers to the primary PAN SEC(A): Refers to the secondary PAN PRI(M): Refers to the primary MnT SEC(M): Refers to the secondary MnT
Services	(Only appears if the Policy Service persona is enabled) Lists the services that run on this Cisco ISE node. Services can include any one of the following: Identity Mapping Session Profiling All
Node Status	Indicates the status of each Cisco ISE node in a deployment for data replication: Green (Connected): Indicates that a Cisco ISE node, which is already registered in the deployment, is in sync with the primary PAN. Red (Disconnected): Indicates that a Cisco ISE node is not reachable, is down, or data replication is not happening. Orange (In Progress): Indicates that a Cisco ISE node is newly registered with the primary PAN, you have performed a manual sync operation, or the Cisco ISE node is not in sync (out of sync) with the primary PAN. For more information, click the quick view icon for each Cisco ISE node in the Node Status column.

General Node Settings

The following table describes the fields on the General Settings window of a Cisco ISE node. In this window, you can assign a persona to a node and configure the services to be run on it. The navigation path for this window is: Administration > System > Deployment > Deployment Node > Edit > General Settings.

Table 3. General Node Settings
Field Name	Usage Guidelines
Hostname	Displays the hostname of the Cisco ISE node.
FQDN	Displays the fully qualified domain name of the Cisco ISE node, for example, ise1.cisco.com.
IP Address	Displays the IP address of the Cisco ISE node.
Node Type	Displays the node type.
Personas
Administration	Check this check box if you want a Cisco ISE node to assume the Administration persona. You can enable the Administration persona only on nodes that are licensed to provide the administrative services. Role: Displays the role that the Administration persona has assumed in the deployment. The persona can take any one of the following values: Standalone, Primary, or Secondary. Make Primary: Click this button to make this node your primary Cisco ISE node. You can have only one primary Cisco ISE node in a deployment. The other options in this window will become active only after you make this node primary. You can have only two Administration nodes in a deployment. If the node has a Standalone role, the Make Primary button appears next to it. If the node has a Secondary role, the Promote to Primary button appears next to it. If the node has a Primary role and there are no other nodes registered with it, the Make Standalone button appears next to it. You can click the Make Standalone button to make your primary node a standalone node.
Monitoring	Check this check box if you want a Cisco ISE node to assume the Monitoring persona and function as your log collector. There must be at least one Monitoring node in a distributed deployment. At the time of configuring your primary PAN, you must enable the Monitoring persona. After you register a secondary Monitoring node in your deployment, you can edit the primary PAN and disable the Monitoring persona, if required. To configure a Cisco ISE node on a VMware platform as your log collector, use the following guidelines to determine the minimum amount of disk space that you need: 180 KB per endpoint in your network, per day 2.5 MB per Cisco ISE node in your network, per day. You can calculate the maximum disk space that you need based on how many months of data you want to have in your Monitoring node. If there is only one Monitoring node in your deployment, it assumes the standalone role. If you have two Monitoring nodes in your deployment, Cisco ISE displays the name of the other Monitoring node for you to configure the primary-secondary roles. To configure these roles, choose one of the following: Primary: For the current node to be the primary Monitoring node. Secondary: For the current node to be the secondary Monitoring node. None: If you do not want the Monitoring nodes to assume the primary-secondary roles. If you configure one of your Monitoring nodes as primary or secondary, the other Monitoring node automatically becomes the secondary or primary node, respectively. Both the primary and secondary Monitoring nodes receive Administration and Policy Service logs. If you change the role for one Monitoring node to None, the role of the other Monitoring node also becomes None, thereby cancelling the high availability pair after you designate a node as a Monitoring node. You will find this node listed as a syslog target in the Remote Logging Targets window: Administration > System > Logging > Remote Logging Targets.
Policy Service	Check this check box to enable any one or all of the following services: Enable Session Services: Check this check box to enable network access, posture, guest, and client-provisioning services. Choose the group to which this Policy Service node belongs from the Include Node in Node Group drop-down list. Note that Certificate Authority (CA) and Enrollment over Secure Transport (EST) services can only run on a Policy Service node that has session services enabled on it. For Include Node in Node Group, choose None if you do not want this Policy Service node to be a part of any group. All the nodes within the same node group should be configured on the network access device (NAD) as RADIUS clients and authorized for CoA, because any one of them can issue a CoA request for the sessions that are established through any node in the node group. If you are not using a load balancer, the nodes in a node group should be the same as, or a subset of the RADIUS servers and clients configured on the NAD. These nodes would also be configured as RADIUS servers. While a single NAD can be configured with many Cisco ISE nodes as RADIUS servers and dynamic-authorization clients, it is not necessary for all the nodes to be in the same node group. The members of a node group should be connected to each other using high-speed LAN connection such as Gigabit Ethernet. The node group members need not be L2 adjacent, but L2 adjacency is highly recommended to ensure sufficient bandwidth and reachability. section for more details. Enable Profiling Service: Check this check box to enable the Profiling service. If you enable the Profiling service, you must click the Profiling Configuration tab and enter the details as required. When you enable or disable any of the services that run on the Policy Service node or make any changes to this node, you will be restarting the application server processes on which these services run. Expect a delay while these services restart. You can determine when the application server has restarted on a node by using the show application status ise command from the CLI. Enable Threat-Centric NAC Service: Check this check box to enable the Threat-Centric Network Access Control (TC-NAC) feature. This feature allows you to create authorization policies based on the threat and vulnerability attributes received from the threat and vulnerability adapters. Threat severity levels and vulnerability assessment results can be used to dynamically control the access level of an endpoint or a user. Enable SXP Service: Check this check box to enable SXP service on the node. You must also specify the interface to be used for SXP service. If you have configured NIC bonding or teaming, the bonded interfaces are also listed along with the physical interfaces in the Use Interface drop-down list. Enable Device Admin Service: Check this check box to create TACACS policy sets, policy results, and so on, to control and audit the configuration of network devices. Enable Passive Identity Service: Check this check box to enable the Identity Mapping feature. This feature enables you to monitor users who are authenticated by a Domain Controller and not by Cisco ISE. In networks where Cisco ISE does not actively authenticate users for network access, you can use the Identity Mapping feature to collect user authentication information from the Active Directory Domain Controller.
pxGrid	Check this check box to enable the pxGrid persona. Cisco pxGrid is used to share the context-sensitive information from the Cisco ISE session directory to other policy network systems such as Cisco Adaptive Security Appliance (ASA). The pxGrid framework can also be used to exchange policy and configuration data between nodes, for example, sharing tags and policy objects between Cisco ISE and third-party vendors, and for non-Cisco ISE-related information exchanges such as threat information.

Profiling Node Settings

The following table describes the fields in the Profiling Configuration window, that you can use to configure the probes for the profiler service. The navigation path for this window is: Administration > System > Deployment > ISE Node > Edit > Profiling Configuration.

Table 4. Profiling Node Settings

Field Name

Usage Guidelines

NetFlow

Check this check box to enable NetFlow for each Cisco ISE node that has assumed the Policy Service persona to receive NetFlow packets sent from the routers. Enter the required values for the following options:

Interface: Choose the interface on the Cisco ISE node.
Port: Enter the NetFlow listener port number on which NetFlow exports are received from the routers. The default port is 9996.

DHCP

Check this check box to enable DHCP for each Cisco ISE node that has assumed the Policy Service persona to listen for DHCP packets from the IP helper. Enter the required values for the following options:

Interface: Choose the interface on the Cisco ISE node.
Port: Enter the DHCP server UDP port number. The default port is 67.

DHCP SPAN

Check this check box to enable DHCP SPAN for each Cisco ISE node that has assumed the Policy Service persona to collect DHCP packets.

Interface: Choose the interface on the Cisco ISE node.

HTTP

Check this check box to enable HTTP per Cisco ISE node that has assumed the Policy Service persona to receive and parse HTTP packets.

Interface: Choose the interface on the Cisco ISE node.

RADIUS

Check this check box to enable RADIUS for each Cisco ISE node that has assumed the Policy Service persona to collect RADIUS session attributes as well as Cisco Device Protocol (CDP) and Link Layer Discovery Protocol (LLDP) attributes from the Cisco IOS Sensor-enabled devices.

Network Scan (NMAP)

Check this check box to enable the NMAP probe.

DNS

Check this check box to enable DNS for each Cisco ISE node that has assumed the Policy Service persona to perform a DNS lookup for the FQDN. Enter the Timeout period in seconds.

Note

For the DNS probe to work on a particular Cisco ISE node in a distributed deployment, you must enable one of the following probes: DHCP, DHCP SPAN, HTTP, RADIUS, or SNMP. For DNS lookup, one of these probes must be started along with the DNS probe.

SNMP Query

Check this check box to enable SNMP query for each Cisco ISE node that has assumed the Policy Service persona to poll network devices at specified intervals. Enter values in Retries, Timeout, Event Timeout(mandatory), and Description(optional).

Note

In addition to configuring the SNMP Query probe, you must also configure other SNMP settings in the following location: Administration > Network Resources > Network Devices. When you configure SNMP settings on the network devices, ensure that you enable CDP and LLDP globally on your network devices.

SNMP Trap

Check this check box to enable an SNMP Trap probe for each Cisco ISE node that has assumed the Policy Service Persona to receive linkUp, linkDown, and MAC notification traps from the network devices. Provide or enable the following information:

Link Trap Query: Check this check box to receive and interpret notifications received through the SNMP trap.
MAC Trap Query: Check this check box to receive and interpret MAC notifications received through the SNMP trap.
Interface: Choose an interface on the Cisco ISE node.
Port: Enter the UDP port of the host to use. The default port is 162.

Active Directory

Check this check box to scan the defined Active Directory servers for information about Windows users.

Days before rescan: Choose the days after which you want the scan to run again.

pxGrid

Check this check box to allow Cisco ISE to collect (profile) endpoint attributes over pxGrid.

Logging Settings

The following sections explain how to configure the severity of debug logs, create an external log target, and enable Cisco ISE to send log messages to these external log targets.

Remote Logging Target Settings

The following table describes the fields in the Remote Logging Targets window that you can use to create external locations (syslog servers) to store logging messages. The navigation path for this window is Administration > System > Logging > Remote Logging Targets. click Add.

Table 5. Remote Logging Target Settings
Field Name	Usage Guidelines
Name	Enter a name for the new syslog target.
Target Type	Select the target type from the drop-down list. The default value is UDP Syslog.
Description	Enter a brief description of the new target.
IP Address	Enter the IP address or hostname of the destination machine that will store the logs.
Port	Enter the port number of the destination machine.
Facility Code	Choose the syslog facility code that must be used for logging from the drop-down list. Valid options are Local0 through Local7.
Maximum Length	Enter the maximum length of the remote log target messages. Valid values are from 200 through 1024 bytes.
Buffer Message When Server Down	This check box is displayed when you choose TCP Syslog or Secure Syslog from the Target Type drop-down list. Check this check box to allow Cisco ISE to buffer the syslog messages when a TCP syslog target or secure syslog target is unavailable. Cisco ISE retries sending messages to the target when the connection to the target resumes. After the connection resumes, messages are sent sequentially, starting with the oldest and proceeding to the newest. Buffered messages are always sent before new messages. If the buffer is full, old messages are discarded.
Buffer Size (MB)	Set the buffer size for each target. By default, it is set to 100 MB. Changing the buffer size clears the buffer and all the existing buffered messages for the specific target are lost.
Reconnect Timeout (Sec)	Enter the time (in seconds) to configure how long the TCP and secure syslogs are stored for before being discarded when the server is down.
Select CA Certificate	This drop-down list is displayed when you choose Secure Syslog from the Target Type drop-down list. Choose a client certificate from the drop-down list.
Ignore Server Certificate Validation	This check box is displayed when you choose Secure Syslog from the Target Type drop-down list. Check this check box for Cisco ISE to ignore server certificate authentication and accept any syslog server. By default, this option is set to off unless the system is in FIPS mode when this is disabled.

Configure Logging Categories

The following table describes the fields that you can use to configure a logging category. Set a log severity level and choose the logging targets for the logs of a logging category. The navigation path for this window is Administration > System > Logging > Logging Categories.

Click the radio button next to the logging category that you want to view, and click Edit. The following table describes the fields that are displayed in the edit window of the logging categories.

Table 6. Logging Category Settings
Field Name	Usage Guidelines
Name	Displays the name of the logging category.
Log Severity Level	For some logging categories, this value is set by default, and you cannot edit it. For some logging categories, you can choose one of the following severity levels from a drop-down list: FATAL: Emergency level. This level means that you cannot use Cisco ISE and you must immediately take the necessary action. ERROR: This level indicates a critical error condition. WARN: This level indicates a normal but significant condition. This is the default level set for many logging categories. INFO: This level indicates an informational message. DEBUG: This level indicates a diagnostic bug message.
Local Logging	Check this check box to enable logging events for a category on the local node.
Targets	This area allows you to choose the targets for a logging category by transferring the targets between the Available and the Selected areas using the left and right arrow icons. The Available area contains the existing logging targets, both local (predefined) and external (user-defined). The Selected area, which is initially empty, then displays the targets that have been chosen for the category.

Admin Access Settings

These sections enable you to configure access settings for administrators.

Administrator Password Policy Settings

The following table describes the fields in the Password Policy tab that you can use to define a criteria that administrator passwords should meet. The navigation path for this window is: Administration > System > Admin Access > Authentication > Password Policy.

Table 7. Administrator Password Policy Settings
Field Name	Usage Guidelines
Minimum Length	Specify the minimum length of the password (in characters). The default is six characters.
Password must not contain	Admin name or its characters in reverse order: Check this check box to restrict the use of the administrator username or its characters in reverse order as the password.
	Cisco or its characters in reverse order: Check this check box to restrict the use of the word Cisco or its characters in the reverse order as the password.
	This word or its characters in reverse order: Check this check box to restrict the use of any word that you define or its characters in the reverse order as the password.
	Repeated characters four or more times consecutively: Check this check box to restrict the use of repeated characters four or more times consecutively as the password.
	Dictionary words, their characters in reverse order, or their letters replaced with other characters: Check this check box to restrict the use of dictionary words, their characters in reverse order, or their letters replaced with other characters, as the password. Substitution of $ for s, @ for a, 0 for o, 1 for l, ! for i, 3 for e, and so on, is not permitted. For example, Pa$$w0rd is not permitted. Default Dictionary: Choose this option to use the default Linux dictionary in Cisco ISE. The default dictionary contains approximately 480,000 English words. This option is selected by default. Custom Dictionary: Choose this option to use your customized dictionary. Click Choose File to select a custom dictionary file. The text file must be of newline-delimited words, .dic extension, and size less than 20 MB.
Password must contain at least one character of each of the selected types	Check the check box for the type of characters an administrator's password must contain. Choose one or more of the following options: Lowercase alphabetic characters Uppercase alphabetic characters Numeric characters Non-alphanumeric characters
Password History	Specify the number of previous passwords from which the new password must be different to prevent the repeated use of the same password. Check the Password must be different from the previous `n`versions check box, and enter the number in the corresponding field. Enter the number of days before which you cannot reuse a password. Check the Cannot reuse password within `n` days check box, and enter the number in the corresponding field.
Password Lifetime	Check the check boxes for the following options to force users to change passwords after a specified time period: Administrator passwords expire `n` days after creation or last change: Time (in days) before the administrator account is disabled if the password is not changed. The valid range is 1 to 3650 days. Send an email reminder to administrators `n` days prior to password expiration: Time (in days) before which the administrator is reminded that their password will expire. The valid range is 1 to 3650 days.
Display Network Device-Sensitive Data
Require Admin Password	Check this check box if you want the admin user to enter the login password to view network device-sensitive data such as shared secrets and passwords.
Password cached for `n` Minutes	The password that is entered by the admin user is cached for this time period. The admin user will not be prompted to enter the password again during this period to view the network device sensitive data. The valid range is from 1 to 60 minutes.

Session Timeout and Session Information Settings

The following table describes the fields in the Session window that you can use to define session timeout and terminate an active administrative session. The navigation path for this window is:Administration > System > Admin Access > Settings > Session.

Table 8. Session Timeout and Session Information Settings
Field Name	Usage Guidelines
Session Timeout
Session Idle Timeout	Enter the time, in minutes, that you want Cisco ISE to wait for it logs out the administrator if there is no activity. The default value is 60 minutes. The valid range is from 6 to 100 minutes.
Session Info
Invalidate	Check the check box adjacent to the session ID that you want to terminate and click Invalidate.

Administration Node

A Cisco ISE node with the Administration persona allows you to perform all administrative operations on Cisco ISE. It handles all the system-related configurations that are related to functionalities such as authentication, authorization, auditing, and so on. In a distributed environment, you can have a maximum of two nodes running the Administration persona. The Administration persona can take on of these following roles-Standalone, Primary, or Secondary.

High Availability for the Administrative Node

In a high-availability configuration, the primary Policy Administration Node (PAN) is in the active state. The secondary PAN is in the standby state, which means it receives all configuration updates from the primary PAN, but is not active in the Cisco ISE network.

Cisco ISE supports manual and automatic failover. With automatic failover, when the primary PAN goes down, an automatic promotion of the secondary PAN is initiated. Automatic failover requires a nonadministration secondary node, which is called a health check node. The health check node checks the health of the primary PAN. If the health check node detects that the primary PAN is down or unreachable, it initiates the promotion of the secondary PAN to take over the primary role.

To deploy the Automatic Failover feature, you must have at least three nodes, with two of them assuming the Administration persona, and one acting as the health check node. A health check node is a nonadministration node and can be a PSN, MnT, pxGrid node, or a combination of these. If the primary and secondary PANs are in different data centers, you must have a health check node for each PAN.

The following table lists the features that are affected when the primary PAN goes down and the secondary PAN is yet to take over.


Features Name	Available When Primary PAN is Down? (Yes/No)
Existing internal user RADIUS authentication	Yes
Existing or new AD user RADIUS authentication	Yes
Existing endpoint with no profile change	Yes
Existing endpoint with profile change	No
New endpoint learned through profiling.	No
Existing guest: Local Web Authentication (LWA)	Yes
Existing guest: Central Web Authentication (CWA)	Yes (apart from flows enabled for device registration, such as Hotspot, BYOD, and CWA with automatic device registration)
Guest change password	No
Guest: AUP	No
Guest: Max Failed Login Enforcement	No
New Guest (Sponsored or Self-registered)	No
Posture	Yes
BYOD with Internal CA	No
Existing Registered Devices	Yes
MDM on-boarding	No
pxGrid Service	No
Log in to GUI of secondary nodes	Yes (The login process is delayed because a blocking call to the PAN is attempted to update the last login details. The login proceeds after this call times out.)

To support certificate provisioning with the internal certificate authority, you must to import the root certificate of the original primary PAN and its key into the new primary node, after promotion. Certificate provisioning does not work after automatic failover for the PSN nodes that are added after the promotion of the secondary node to primary PAN.

High-Availability Health Check Nodes

The health check node for Primary PAN is called the active health check node. The health check node for Secondary PAN is called the passive health check node. The active health check node is responsible for checking the status of the Primary PAN, and managing the automatic failover of Administration nodes. We recommended that you use two nonadministrative ISE nodes as health check nodes, one for the Primary PAN and one for the Secondary PAN. If you use only one health check node, and that node goes down, automatic failover will not happen.

When both the PANs are in the same data center, you can use a single nonadministrative ISE node as the health check node for both the Primary PAN and the Secondary PAN. When a single health check node checks the health of both the Primary PAN and the Secondary PAN, it assumes both the active and passive roles.

A health check node is a nonadministration node, which means it can be a Policy Service, Monitoring, or pxGrid node, or a combination of those. We recommend that you designate PSN nodes as health check nodes in the same data center as the Administration nodes. However, in a small or a centralized deployment, where the two Administration nodes are not in the same location (LAN or data center), any node (PSN, pxGrid, or MnT) not having the Administration persona can be used as health check node.

Note

If you chose not to enable automatic failover, and rely on manually promoting the secondary node when the primary PAN fails, you do not need any check nodes.

Health Check Node for the Secondary PAN

The health check node for the Secondary PAN is a passive monitor. It does not take any action until the Secondary PAN has been promoted as the Primary PAN. When the Secondary PAN takes over the primary role, its associated health check node takes the active role for managing automatic failover of Administration nodes. The health check node of the previous Primary PAN becomes the health check node for the Secondary PAN now and monitors it passively.

Disabling and Restarting Health Check

When a node is removed from the health check role or auto-failover configuration is disabled, the health check service is stopped on that node. When the auto-failover configuration is enabled on the designated high-availability health check node, the node starts checking the health of Administration nodes again. Designating or removing the high-availability health check role on a node does not involve any application restart on that node; only the health check activities are started or stopped.

If the high-availability health check node is restarted, it ignores the previous downtimes of the Primary PAN and starts checking the health status afresh.

Health Check Nodes

The active health check node checks the health status of the primary PAN at a configured polling interval. It sends a request to the primary PAN, and if the response that it receives matches the configuration, the health check node considers the primary PAN to be in good health. If the health of the primary PAN is bad continuously for more than the configured failover period, the health check node initiates failover to the secondary PAN.

If, at any time during a health check, the health status is found to be good after being reported as bad previously within the failover period, the health check node marks the primary PAN status as good, and resets the health check cycle.

The response from the health check of the primary PAN is validated against the configuration values available on its health check node. If the response does not match, it raises an alarm. However, a promotion request is made to the secondary PAN.

Changing Health Nodes

You can change the Cisco ISE node that you are using for a health check, but there are some things to consider.

For example, assume that the health check node (H1) goes out-of-sync and some other node (H2) is made the health check node of the primary PAN. In such a case, after the primary PAN goes down, there is no way for H1 to know that another node (H2) is checking the same primary PAN. Later, if H2 goes down or out of the network, an actual failover is required. The secondary PAN, however, retains the right to reject the promotion request. So, after the secondary PAN is promoted to the primary role, a promotion request from H2 is rejected with an error. Even if a health check node for the primary PAN is out of sync, it continues to check the health of the primary PAN.

Automatic Failover to the Secondary PAN

You can configure Cisco ISE to automatically promote the secondary PAN when the primary PAN becomes unavailable. The configuration is done on the primary Policy Administration node (Primary PAN) in the Deployment window. The navigation path for this window is Administration > System > Deployment. The failover period is defined as the number of times configured in Number of Failure Polls Before Failover times the number of seconds configured in Polling Interval. In the default configuration, that time is 10 minutes. Promotion of the secondary PAN to primary PAN takes another 10 minutes. So, by default, the total time from primary PAN failure to secondary PAN working is 20 minutes.

When the secondary PAN receives the failover call, it carries out the following validations before proceeding with the actual failover:

The primary PAN is not available in the network.
The failover request came from a valid health check node.
The failover request is for the secondary PAN.

If all the validations pass, the secondary PAN promotes itself to the primary role.

The following are some sample (but not limited to) scenarios where automatic failover of the secondary PAN can be attempted:

Health of the primary PAN is consistently not good for the Number of failure polls before failover value during the polling period.
Cisco ISE services on the primary PAN are manually stopped, and remain stopped for the failover period.
The primary PAN is shut down using soft halt or reboot option, and remains shut down for the configured failover period.
The primary PAN goes down abruptly (power down), and remains down for the failover period.
The network interface of the primary PAN is down (network port shut or network service down), or it is not reachable by the health check node for any other reason, and remains down for the configured failover period.

Health Check Node Restarts

Upon restart, the high-availability health check node ignores the previous downtimes of the primary PAN and checks the health status afresh.

Bring Your Own Device in Case of Automatic Failover to Secondary PAN

When the primary PAN is down, authentication is not interrupted for the endpoints that already have certificates issued by the primary PAN root CA chain. This is because all the nodes in the deployment have the entire certificate chain for trust and validation purposes.

However, until the secondary PAN is promoted to primary, new BYOD devices will not be onboarded. BYOD onboarding requires an active primary PAN.

After the original primary PAN is brought back up or the secondary PAN is promoted, new BYOD endpoints are onboarded without any issues.

If the primary PAN that failed can not be rejoined as the primary PAN, regenerate the root CA certificate on the newly promoted primary PAN (the original secondary PAN).

For existing certificate chains, triggering a new root CA certificate results in the automatic generation of the subordinate CA certificates. Even when new subordinate certificates are generated, endpoint certificates that were generated by the previous chain continue to be valid.

Sample Scenarios when Automatic Failover is Avoided

The following are some sample scenarios that depict cases where automatic failover by the health check node might be avoided or promotion request to the secondary node rejected:

The node receiving the promotion request is not the secondary node.
The promotion request received by the secondary PAN does not have the correct primary PAN information.
The promotion request is received from an incorrect health check node.
The promotion request is received, but the primary PAN is up and in good health.
The node receiving the promotion request goes out-of-sync.

Functionalities Affected by the PAN Automatic Failover Feature

The following table lists the functionalities that are blocked or require additional configuration changes if the PAN automatic failover configuration is enabled in your deployment.


Functionality	Affected Details
Operations that are Blocked
Upgrade	Upgrade through the CLI is blocked. The PAN Automatic Failover feature is available for configuration after you upgrade from an earlier release to Cisco ISE, Release 1.4. By default, this feature is disabled. To deploy the Auto-Failover feature, you must have at least three nodes, where two of the nodes assume the Administration persona, and one node acts as the health check node. (A health check node is a nonadministration node and can be a PSN, MnT, pxGrid node, or a combination of these). If the PANs are in different data centers, you must have a health check node for each PAN.
Restore of Backup	Restore through the CLI and user interface is blocked. If the PAN automatic failover configuration was enabled prior to restore, you must reconfigure it after a successful restore.
Change Node Persona	Change of the following node personas through the GUI is blocked: Administration persona in both the primary and secondary PANs Persona of the PAN Deregistration of health check node after enabling the PAN Automatic Failover feature
Other CLI Operations	The following admin operations through the CLI is blocked: Patch installation and roll back DNS server change IP address change of eth1, eth2, and eth3 interfaces Host alias change of eth1, eth2, and eth3 interfaces Time zone change
Other Administration Portal Operations	The following administrative operations through the GUI is blocked: Patch installation and roll back Change of HTTPS certificate Change of admin authentication type from password-based authentication to certificate-based authentication and vice versa
Users with maximum connected devices cannot connect.	Some session data is stored on the failed PAN, and cannot be updated by the PSN.
Operations that Require PAN Automatic Failover to be Disabled
CLI Operations	The following administrative operations through the CLI display a warning message if the PAN automatic failover configuration is enabled. These operations may trigger automatic failover if service or system is not restarted within the failover window. Hence, while performing the following operations , we recommend that you to disable the PAN automatic failover configuration: Manual stopping the Cisco ISE service Soft reload (reboot) of Cisco ISE using the admin CLI

Configure Primary PAN for Automatic Failover

Before you begin

To deploy the Automatic Failover feature, you must have at least three nodes, where two of the nodes assume the Administration persona, and one node acts as the health check node. A health check node is a nonadministration node and can be a PSN, MnT, pxGrid node, or a combination of these. If the PANs are in different data centers, you must have a health check node for each PAN.

Procedure

Step 1

Log in to the primary PAN GUI.

Step 2

Choose Administration > System > Deployment > PAN Failover.

Step 3

Check the Enable PAN Auto Failover check box to enable automatic failover of the primary PAN.

Note

You can only promote a secondary PAN to become the Primary PAN. Cisco ISE nodes that assume only the PSN, MnT, pxGrid node, or a combination of these, cannot be promoted to become the Primary PAN.

Step 4

Choose the health check node for the primary PAN from the Primary Health Check Node drop-down list containing all the available secondary nodes.

We recommend that you have this node in the same location or data center as the primary PAN.

Step 5

Choose the health check node for the secondary PAN, from the Secondary Health Check Node drop-down list containing all the available secondary nodes.

We recommend that you have this node in the same location or data center as the secondary PAN.

Step 6

Provide the Polling Interval time after which the PAN status is checked. The valid range is 30 to 300 seconds.

Step 7

Provide the count for Number of Failure Polls before Failover.

Failover occurs if the status of the PAN is not good for the specified number of failure polls. The valid range is 2 to 60 counts.

Step 8

Click Save.

What to do next

After the promotion of the secondary PAN to the primary PAN, do the following:

Manually sync the old primary PAN to bring it back into the deployment.
Manually sync any other secondary node that is outof sync, to bring it back into the deployment.

Manually Promote Secondary PAN to Primary

If the primary PAN fails and you have not configured PAN automatic failover, you must manually promote the secondary PAN to become the new primary PAN.

Before you begin

Ensure that you have a second Cisco ISE node configured with the Administration persona to promote as your primary PAN.

Procedure

Step 1

Log in to the secondary PAN GUI.

Step 2

Step 3

In the Edit Node window, click Promote to Primary.

Note

You can only promote a secondary PAN to become the primary PAN. Cisco ISE nodes that assume only the Policy Service or Monitoring persona, or both, cannot be promoted to become the primary PAN.

Step 4

Click Save.

What to do next

If the node that was originally the primary PAN, comes back up, it will be demoted automatically and become the secondary PAN. You must perform a manual synchronization on this node (that was originally the primary PAN) to bring it back into the deployment.

In the Edit Node window of a secondary node, you cannot modify the personas or services because the options are disabled. You have to log in to the Admin portal to make changes.

Restoring Service to the Primary PAN

Cisco ISE does not support automatic fallback to the original primary PAN. After the automatic failover to the secondary PAN is initiated, if you bring the original primary PAN back into the network, you should configure it as the secondary PAN.

Support for Automatic Failover for the Administration Node

Cisco ISE supports Automatic Failover for the Administration persona. To enable the automatic failover feature, at least two nodes in your distributed setup should assume the Administration persona and one node should assume the nonadministration persona. If the primary PAN goes down, an automatic promotion of the secondary PAN is initiated. For this, a non-administration secondary node is designated as the health check node for each of the PANs. The health check node checks the health of the primary PAN at configured intervals. If the health check response received for the primary PAN is not good for reasons, such as the device being down or unreachable, the health check node initiates the promotion of the secondary PAN to take over the primary role after waiting for the configured threshold value. Some features are unavailable after automatic failover of the secondary PAN. Cisco ISE does not support fallback to the original primary PAN.See the High Availability for the Administration Nodes section for more information.

Policy Service Node

A Policy Service node (PSN) is a Cisco ISE node with the Policy Service persona, and provides network access, posture, guest access, client provisioning, and profiling services.

At least one node in your distributed setup should assume the Policy Service persona. This persona evaluates the policies and makes all the decisions. Typically, there is more than one PSN in a distributed deployment.

All the PSNs that reside in the same high-speed Local Area Network (LAN) or behind a load balancer can be grouped together to form a node group. If one of the nodes in a node group fails, the other nodes detect the failure and reset URL-redirected sessions, if any.

High Availability in Policy Service Nodes

To detect node failure and to reset all URL-redirected sessions on the failed node, two or more PSNs can be placed in the same node group. When a node that belongs to a node group fails, another node in the same node group issues a Change of Authorization (CoA) for all URL-redirected sessions on the failed node.

All the nodes within the same node group should be configured on the network access device (NAD) as RADIUS clients and authorized for CoA, because any one of them can issue a CoA request for the sessions that are established through any node in the node group. If you are not using a load balancer, the nodes in a node group should be the same as, or a subset of, the RADIUS servers and clients configured on the NAD. These nodes should also be configured as RADIUS servers.

Note

While a single NAD can be configured with many Cisco ISE nodes as RADIUS servers and dynamic-authorization clients, it is not necessary for all the nodes to be in the same node group.

The members of a node group should be connected to each other using high-speed LAN connection such as Gigabit Ethernet. The node group members need not be L2 adjacent, but L2 adjacency is highly recommended to ensure sufficient bandwidth and reachability. See Create a Policy Service Node Group section for more details.

Load Balancer to Distribute Requests Evenly Among PSNs

When you have multiple PSNs in the deployment, you can use a load balancer to distribute the requests evenly. The load balancer distributes the requests to the functional nodes behind it. See Cisco and F5 Deployment Guide: ISE Load Balancing using BIG-IP for information, and to know about best practices when deploying PSNs behind a load balancer.

Session Failover in Policy Service Nodes

PSNs in a node group share session information. The nodes exchange heartbeat messages to detect node failures. If a node fails, one of its peers from the node group knows which sessions were on the failed PSN, and issues a CoA to disconnect those sessions. Most clients automatically reconnect, and establish a new session.

Some clients don’t automatically reconnect. For example, if a client connects through a VPN, then that client may not see the CoA. Clients that are IP phones, multihost 802.1X ports, or virtual machines may also not see or be able to respond to a CoA. URL-redirected clients (webauth) also can’t connect automatically. Those clients must manually reconnect.

Timing issues can also prevent reconnection, for example, if the posture state is pending at the time of PSN failover.

Number of Nodes in a Policy Service Node Group

The number of nodes that you can have in a node group depends on your deployment requirements. Node groups ensure that node failures are detected and that a peer issues a CoA for sessions that are authorized, but not yet postured. The size of the node group does not have to be very large.

If the size of the node group increases, the number of messages and heartbeats that are exchanged between the nodes increases significantly. As a result, traffic also increases. Having fewer nodes in a node group helps reduce the traffic and at the same time provides sufficient redundancy to detect PSN failures.

There is no hard limit on the number of PSNs that you can have in a node group cluster.

Monitoring Node

A Cisco ISE node with the Monitoring persona functions as the log collector and stores log messages from the PANs and PSNs in your network. This persona provides advanced monitoring and troubleshooting tools that you can use to effectively manage your network and resources. A node with this persona aggregates and correlates the data that it collects to provide you with meaningful information in the form of reports.

Cisco ISE allows you to have a maximum of two nodes with this persona that can take on primary or secondary roles for high availability. Both the primary and secondary MnT nodes collect log messages. If the primary MnT goes down, the primary PAN points to the secondary node to gather monitoring data. But the secondary node will not be promoted to primary automatically. This should be done by following the procedure described in manually modifying the Monitoring and Troubleshooting (MnT) role.

At least one node in your distributed setup should assume the Monitoring persona. We recommend that you not have the Monitoring and Policy Service personas enabled on the same Cisco ISE node, and that the node be dedicated solely to monitoring, for optimum performance.

You can access the Monitoring menu from the PAN in your deployment.

Note

If you have enabled pxGrid, you must create a new certificate for the pxGrid node. Create the certificate template with digital signature usage and generate a new PxGrid certificate.

Manually Modify the MnT Role

You can manually modify MnT roles (both from primary to secondary and from secondary to primary) from the primary PAN.

Procedure

Step 1	Log in to the primary PAN GUI.
Step 2	Choose Administration > System > Deployment.
Step 3	From the list of nodes, check the check box next to the MnT node for which you want to change the role.
Step 4	Click Edit.
Step 5	In the Monitoring section, change the role to Primary or Secondary.
Step 6	Click Save.

Note

You can enable the option if you want to disable all the other personas and services enabled on that node. When this option is enabled, the configuration data replication process is stopped on that node. This helps to improve the performance of the MnT node. When you disable this option, manual synchronization is triggered.

Automatic Failover in MnT Nodes

MnT nodes do not offer high availablity, but do offer active standby. The PSN copies operational audit data to both the primary and secondary MnT nodes.

Automatic Failover Process

When a primary MnT node goes down, the secondary MnT node takes over all the monitoring and troubleshooting information.

To manually convert the secondary node to a primary node, see promote the secondary node to a primary role. If the primary node comes up again after the secondary node is promoted, it takes on the secondary role. If the secondary node is not promoted, the primary MnT node resumes the primary role after it comes up again.

Caution

When the primary node comes back up after a failover, obtain a backup of the secondary and restore the data to update the primary node.

Guidelines for Setting Up an Active Standby Pair of MnT Nodes

You can specify two MnT nodes on a Cisco ISE network, and configure then to be an active standby pair. We recommend that you back up the primary MnT node, and restore the data to the new secondary MnT node. This ensures that the history of the primary MnT node is synchronized with the new secondary node as the primary replicates new data. The following rules apply to an active standby pair:

All changes are logged to the primary MnT node. The secondary node is read-only.
Changes made to the primary node are automatically replicated on the secondary node
Both the primary and secondary nodes are listed as log collectors, to which all other nodes send logs.
The Cisco ISE dashboard is the main entry point for monitoring and troubleshooting. Monitoring information is displayed on the dashboard from the PAN . If the primary node goes down, monitoring information is available on the secondary node.
Backing up and purging MnT data is not a part of a standard Cisco ISE node backup process. You must configure repositories for backup and data purging on both the primary and secondary MnT nodes, and use the same repositories for each.

MnT Node Failover Scenarios

The following scenarios apply to the active-standby or single node configurations corresponding to the MnT nodes:

In an active-standby configuration of the MnT nodes, the primary PAN always points to the primary MnT node to collect the monitoring data. After the primary MnT node fails, the PAN points to the standby MnT node. The failover from the primary node to the secondary node takes place after it is down for more than five minutes.

However, after the primary node fails, the secondary node does not become the primary node. In case the primary node comes up, the PAN starts collecting the monitoring data again from the resumed primary node.
If the primary MnT node is down, and you want to promote the standby MnT node to active status, you can do so by manually modifying MnT role or by deregistering the existing primary MnT node. When you deregister the existing primary MnT node, the standby node becomes the primary MnT node, and the PAN automatically points to the newly promoted primary node.
In an active-standby pair, if you deregister the secondary MnT node or if the secondary MnT node goes down, the existing primary MnT node remains the current primary node.
If there is only one MnT node in the Cisco ISE deployment, then that node acts as the primary MnT node, and provides monitoring data to the PAN. However, when you register a new MnT node, and make it the primary node in the deployment, the existing primary MnT node automatically becomes the standby node. The PAN points to the newly registered primary MnT node to collect monitoring data.

Monitoring Database

The rate and amount of data that is utilized by the monitoring functions requires a separate database on a dedicated node that is used for these purposes.

Like PSN, the MnT node has a dedicated database that requires you to perform maintenance tasks, as described in the topics covered in this section.

Back Up and Restore the Monitoring Database

The Monitoring database handles large volumes of data. Over time, the performance and efficiency of the MnT node depends on how well you manage that data. To increase efficiency, we recommend that you back up the data and transfer it to a remote repository on a regular basis. You can automate this task by scheduling automatic backups.

Note

You should not perform a backup when a purge operation is in progress. If you start a backup during a purge operation, the purge operation stops or fails.

If you register a secondary MnT node, we recommend that you first back up the primary MnT node and then restore the data to the new secondary MnT node. This ensures that the history of the primary MnT node is in sync with the new secondary node when the new changes are replicated.

Monitoring Database Purge

The purging process allows you to manage the size of the Monitoring database by specifying the number of months to retain the data during a purge. The default is three months. This value is utilized when the disk space usage threshold for purging (80 percentage of the total disk space) is met. For this option, each month consists of 30 days. A default of three months equals 90 days.

Guidelines for Purging the Monitoring Database

Follow these guidelines for optimal relating to Monitoring database disk usage:

If the Monitoring database disk usage is greater than 80 percentage of the threshold setting, that is 60% of total disk space, a critical alarm is generated, indicating that the database size is about to exceed the maximum amount of allocated disk size. If the disk usage is greater than 90 percentage of the threshold setting, that is 70% of total disk space, another alarm is generated, indicating that the database size has exceeded the maximum amount of allocated disk size.

A purge process runs, creating a status history report that you can view in the Data Purging Audit window. The navigation path to this window is Operations > Reports > Reports > Audit > Data Purging Audit. An information (INFO) alarm is generated after the purge is completed.
Purging is also based on the percentage of consumed disk space for the database. When the consumed disk space for the Monitoring database is equal to or exceeds the threshold (the default is 80 percentage of the total disk space), the purge process starts. This process deletes only the oldest seven days' monitoring data, irrespective of what is configured in the Admin portal. It will continue this process in a loop until the disk space is below 80 percent. Purging always checks the Monitoring database disk space limit before proceeding.

Operational Data Purging

Cisco ISE Monitoring Operational database contains information that is generated as Cisco ISE reports. Recent Cisco ISE releases have options to purge the monitoring operational data and reset the monitoring database after running the application configure ise command.

The purge option is used to clean up the data and prompts you to enter the number of days for which to retain the data. The reset option is used to reset the database to the factory default, so that all the data that is backed up will be permanently deleted. Specify the database if the files are consuming too much file system space.

Note

The reset option will cause Cisco ISE services to be temporarily unavailable until it restarts.

The Operational Data Purging window contains the Database Utilization and Purge Data Now areas. The navigation path for this window is Administration > System > Maintenance > Operational Data Purging. You can view the total available database space and the RADIUS and TACACS data stored in the Database Utilization area. Hover the mouse over the status bar to display the available disk space and the number of days the existing data is stored in the database. Specify the period for which the RADIUS and TACACS data is supposed to be retained in the Data Retention Period area. Data is purged at 4 a.m. very day, and you can configure to export data to a repository before it is purged, by specifying the number of retention days. Check the Enable Export Repository check box to select and create a repository, and specify an Encryption Key.

In the Purge Data Now area, you can purge all the RADIUS and TACACS data or specify the number of days beyond which data is supposed to be purged.

Note

You must export RADIUS authentication and accounting, TACACS authorization and accounting, RADIUS errors, and misconfigured supplicants tables to a repository before purging.

Purge Older Operational Data

The operational data is collected in the server over a period of time. It can be purged either instantly or periodically. You can verify the success of the data purge by viewing the Data Purging Audit report.

Before you begin

To perform the following task, you must be a Super Admin or System Admin.

Procedure

Step 1

Choose Administration > System > Maintenance > Operational Data Purging.

Step 2

Do one of the following:

In the Data Retention Period area:

Specify the time period, in days, for which RADIUS and TACACS data should be retained. All the data prior to the specified time period is exported to a repository.
In the Repository area, check the Enable Export Repository check box to choose the repository to save data.
In the Encryption Key field, enter the required password.

Click Save.

Note

If the configured retention period is less than the existing retention thresholds corresponding to the diagnostics data, then the configured value overrides the existing threshold values. For example, if you configure the retention period as three day,s and this value is less than the existing thresholds in the diagnostics tables (for example, a default of five days), then the data is purged according to the value that you configure (three days) in this window.

In the Purge Data Now area:
1. Choose to purge all the data or to purge the data that is older than the specified number of days. Data is not saved in any repository.
2. Click Purge.

Configure MnT Nodes for Automatic Failover

If you have two MnT nodes in a deployment, you can configure a primary-secondary pair for automatic failover to avoid downtime in the Cisco ISE Monitoring service. A primary-secondary pair ensures that a secondary MnT node automatically provides monitoring should the primary node fail.

Before you begin

Before you can configure MnT nodes for automatic failover, they must be registered as Cisco ISE nodes.
Configure monitoring roles and services on both nodes and name them for their primary and secondary roles, as appropriate.

Configure repositories for backup and data purging on both the primary and secondary MnT nodes. For the backup and purging features to work properly, use the same repositories for both the nodes. Purging takes place on both the primary and secondary nodes of a redundant pair. For example, if the primary MnT node uses two repositories for backup and purging, you must specify the same repositories for the secondary node.

Configure a data repository for a MnT node using the repository command in the system CLI.

Caution

For scheduled backup and purge to work properly on the nodes of a monitoring redundant pair, configure the same repository, or repositories, on both the primary and secondary nodes using the CLI. The repositories are not automatically synced between the two nodes.

From the Cisco ISE dashboard, verify that the MnT nodes are ready. The System Summary dashlet shows the MnT nodes with a green check mark to the left when their services are ready.

Procedure

Step 1	Choose Administration > System > Deployment.
Step 2	In the Deployment Nodes window, check the check box next to the MnT node that you want to specify as primary, and click Edit .
Step 3	Click the General Settings tab and choose Primary from the Role drop-down list. When you choose an MnT node as primary, the other MnT node automatically becomes secondary. In the case of a standalone deployment, primary and secondary role configuration is disabled.
Step 4	Click Save . Both the primary and secondary nodes restart.

Cisco pxGrid Node

You can use Cisco pxGrid to share the context-sensitive information from Cisco ISE session directory with other network systems such as Cisco ISE ecosystem partner systems and other Cisco platforms. The pxGrid framework can also be used to exchange policy and configuration data between nodes, such as sharing tags and policy objects between Cisco ISE and third-party vendors, and for other information exchanges. Cisco pxGrid also allows third-party systems to invoke adaptive network control actions (EPS) to quarantine users or devices or both in response to a network or security event. The Cisco TrustSec information like tag definition, value, and description can be passed from Cisco ISE through the Cisco TrustSec topic to other networks. The endpoint profiles with Fully Qualified Names (FQNs) can be passed from Cisco ISE to other networks through an endpoint profile meta topic. Cisco pxGrid also supports bulk download of tags and endpoint profiles.

You can publish and subscribe to SXP bindings (IP-SGT mappings) through Cisco pxGrid. For more information about SXP bindings, see the "Security Group Tag Exchange Protocol" section in Cisco ISE Admin Guide: Segmentation .

In a high-availability configuration, Cisco pxGrid servers replicate information between the nodes through the PAN. When the PAN goes down, the Cisco pxGrid server stops handling the client registration and subscription. You need to manually promote the PAN for the Cisco pxGrid server to become active. You can check the Cisco pxGrid services window (Administration > pxGrid Services) to verify whether a Cisco pxGrid node is currently in active or standby state.

On the active Cisco node that has the pxGrid persona, these processes are displayed as Running. On the standby Cisco pxGrid node, they are displayed as Standby. If the active pxGrid node goes down, the standby pxGrid node detects this, and starts the four pxGrid processes. Within a few minutes, these processes show as Running, and the standby node becomes the active node. You can verify whether the Cisco pxGrid service is in standby on that node by running the CLI command show logging application pxgrid/pxgrid.state.

For Extensible Messaging and Presence Protocol clients, Cisco pxGrid nodes work in active-standby high availability mode which means that the Cisco pxGrid Service is in Running state on the active node and in Disabled state on the standby node.

Note

In a High Availability Cisco ISE deployment, the pxGrid persona nodes that work in an active-standby setup show that the pxGrid Service is in running state on the active node and in standby state on the standby node.

To verify the status of pxGrid services on a Cisco ISE node, use the following CLI command:

show logging application pxgrid/pxgrid.state

After the automatic failover to the secondary Cisco pxGrid node is initiated, if the original primary Cisco pxGrid node is brought back into the network, the original primary Cisco pxGrid node continues to have the secondary role and is not promoted back to the primary role unless the current primary node goes down.

Note

At times, the original primary Cisco pxGrid node might be automatically promoted back to the primary role.

In a high-availability deployment, when the primary Cisco pxGrid node goes down, it might take around three to five minutes to switchover to the secondary Cisco pxGrid node. We recommend that the client waits for the switchover to complete, before clearing the cache data just in case the primary Cisco pxGrid node fails.

The following logs are available for the Cisco pxGrid node:

pxgrid.log: State change notifications.
pxgrid-cm.log: Updates on publisher or subscriber or both and data exchange activity between the client and the server.
pxgrid-controller.log: Displays the details of client capabilities, groups, and client authorization.
pxgrid-jabberd.log: Displays all the logs related to system state and authentication.
pxgrid-pubsub.log: Displays all the information related to publisher and subscriber events.

Note

If Cisco pxGrid service is disabled on a node, port 5222 is down, but port 8910 (used by web clients) is functional and continues to respond to the requests.

Note

You can enable Cisco pxGrid with Base license, but you must have a Plus license to enable the Cisco pxGrid persona. In addition, certain extended Cisco pxGrid services may be available in your Base installation if you have recently installed an upgrade license for .

Note

Cisco pxGrid should be defined in order to work with the Passive ID Work Center. For more information, see the "PassiveID Work Center" section in Cisco ISE Admin Guide: Asset Visibility .

Cisco pxGrid Client and Capability Management

Clients connecting to Cisco ISE must register and receive account approval before using Cisco pxGrid services. Cisco pxGrid clients use the Cisco pxGrid client library available in the Cisco pxGrid SDK to become the clients. Cisco ISE supports both auto and manual approvals. A client can log in to Cisco pxGrid using a unique name and certificate-based mutual authentication. Similar to the AAA setting on a switch, clients can connect to either a configured Cisco pxGrid server hostname or an IP address.

Cisco pxGrid capabilities are information topics or channels on Cisco pxGrid for clients to publish and subscribe. In Cisco ISE, only capabilities such as Identity, Adaptive Network Control (ANC) , and Security Group Access (SGA) are supported. When a client creates a new capability, it appears in the View by Capabilities window. The navigation path for this window is Administration > pxGrid Services > View by Capabilities. You can enable or disable capabilities individually. Capability information is available from the publisher through publish, directed query, or bulk download query.

When a web client publisher uses REST APIs or WebSocket protocols, the topics added in the web client publisher are not immediately listed in the Administration > pxGrid Services > Web Clients tab in Cisco ISE. Such a web client topic appears in the Web Clients tab only after its first instance of publishing.

Note

Users that are assigned to Endpoint Protection service (EPS) user group can perform actions in session group, because Cisco pxGrid session group is part of EPS group. If a user is assigned to EPS group, the user will be able to subscribe to the session group on the Cisco pxGrid client.

Enable pxGrid Service

Before you begin

Enable the pxGrid persona on at least one node to view the requests from the Cisco pxGrid clients.

Procedure

Step 1	Choose Administration > pxGrid Services.
Step 2	Check the checkbox next to the client and click Approve.
Step 3	Click Refresh to view the latest status.
Step 4	Select the capability you want to enable and click Enable.
Step 5	Click Refresh to view the latest status.

Enable pxGrid Capabilities

Before you begin

Enable the pxGrid persona on at least one node to view the requests from the Cisco pxGrid clients.
Enable a pxGrid client.

Procedure

Step 1	Choose Administration > pxGrid Services.
Step 2	Click View by Capabilities at the top-right.
Step 3	Select the capability you want to enable and click Enable.
Step 4	Click Refresh to view the latest status.

Deploy Cisco pxGrid Node

You can enable Cisco pxGrid persona both on a standalone node and distributed deployment node.

Before you begin

You can enable the pxGrid with Base license, but you must have a Plus license to enable pxGrid persona. In addition, certain extended pxGrid services may be available in your Base installation if you have recently installed an upgrade license .
All nodes use the CA certificate for Cisco pxGrid service usage. If you used the default certificate for Cisco pxGrid service before upgrade, upgrade replaces that certificate with the internal CA certificate.
You must have port 8910 open for Websockets (pxGrid 2.0), and port 5222 open for XMPP (pxGrid V1.0). If the Cisco pxGrid service is disabled on a node, port 5222 goes down, but port 8910 remains functional, and continues to respond to the requests.

Procedure

Step 1	Choose Administration > System > Deployment.
Step 2	In the Deployment Nodes window, check the check box next to the node for which you want to enable the Cisco pxGrid services, and click Edit.
Step 3	Click the General Settings tab and check the pxGrid check box.
Step 4	Click Save. When you upgrade from the previous version, the Save option might be disabled. This happens when the browser cache refers to the old files from the previous version of Cisco ISE. Clear the browser cache to enable the Save option.

Cisco pxGrid Live Logs

The Live Logs window displays all the pxGrid management events. Event info includes the client and capability names along with the event type and timestamp.

The navigation path for this window is Administration > pxGrid Services > Live Log. You can also clear the logs and resynchronize or refresh the list.

Configure Cisco pxGrid Settings

Before you begin

To perform the following task, you must be a Super Admin or System Admin.

Procedure

Step 1

Choose Administration > pxGrid Services > Settings.

Step 2

Check one of the following check boxes based on your requirements:

Automatically approve new certificate-based accounts: Check this check box to automatically approve the connection requests from new Cisco pxGrid clients.
Allow password-based account creation: Check this check box to enable username or password-based authentication for Cisco pxGrid clients. When this option is enabled, Cisco pxGrid clients cannot be automatically approved.

Step 3

Click Save.

Use the Test option in the Cisco pxGrid Settings window to run a health check on the Cisco pxGrid node. View the details in the pxgrid or pxgrid-test.log file.

Generate Cisco pxGrid Certificate

Before you begin

Some versions of Cisco ISE have a certificate for Cisco pxGrid that uses NetscapeCertType. We recommend that you generate a new certificate.
To perform the following task, you must be a Super Admin or System Admin.
A Cisco pxGrid certificate must be generated from the primary PAN.
If the Cisco pxGrid certificate uses the subject alternative name (SAN) extension, be sure to include the FQDN of the subject identity as a DNS name entry.
Create a certificate template with digital signature usage and use that to generate a new Cisco pxGrid certificate.

Procedure

Step 1

Choose Administration > pxGrid Services > Certificates.

Step 2

From the I want to drop-down list, choose one of the following options:

Generate a single certificate (without a certificate signing request): You must enter the Common Name (CN) if you select this option.
Generate a single certificate (with a certificate signing request): You must enter the Certificate Signing Request details if you select this option.
Generate bulk certificates: You can upload a CSV file that contains the required details.
Download Root Certificate Chain: You can download the root certificates and add them to the trusted certificate store. You must specify the host name and the certificate download format.

Step 3

(Optional) Enter a description for this certificate.

Step 4

Click the pxGrid_Certificate_Template link to download and edit the certificate template based on your requirements.

Step 5

Enter the Subject Alternative Name (SAN). You can add multiple SANs. The following options are available:

IP address: Enter the IP address of the Cisco pxGrid client to be associated with the certificate.
FQDN: Enter the FQDN of the pxGrid client.

Note

This field is not displayed if you select the Generate Bulk Certificate option.

Step 6

From the Certificate Download Format drop-down list, choose one of the following options:

Certificate in Private Enhanced Electronic Mail (PEM) format, key in PKCS8 PEM format (including certificate chain): The root certificate, the intermediate CA certificates, and the end entity certificate are represented in the PEM format. PEM-formatted certificates are BASE64-encoded ASCII files. Each certificate starts with the "--------BEGIN CERTIFICATE-----" tag and ends with the "-------END CERTIFICATE----" tag. The end entity’s private key is stored using PKCS* PEM. It starts with the "-----BEGIN ENCRYPTED PRIVATE KEY----" tag and ends with the "-----END ENCRYPTED PRIVATE KEY----" tag.
PKCS12 format (including certificate chain; one file for both the certificate chain and key): A binary format to store the root CA certificate, the intermediate CA certificate, and the end entity's certificate and private key in one encrypted file.

Step 7

Enter the password for the certificate.

Step 8

Click Create.

You can view the certificate that you created in the Issued Certificates window. The navigation path for this window is Administration > System > Certificates > Certificate Authority > Issued Certificates.

You can view the certificate that you created in the Issued Certificates window. To view this window, click the Menu icon () and choose Administration > System > Certificates > Certificate Authority > Issued Certificates.

Note

From Cisco ISE 2.4 patch 13 onwards, the certificate requirements have become stricter for the pxGrid service. If you are using the Cisco ISE default self-signed certificate as the pxGrid certificate, Cisco ISE might reject that certificate after applying Cisco ISE 2.4 patch 13 or later. This is because the older versions of that certificate have the Netscape Cert Type extension specified as SSL Server, which now fails (a client certificate is also required now).

Any client with a noncompliant certificate fails to integrate with Cisco ISE. Use a certificate issued by the internal CA or generate a new certificate with proper usage extensions:

The Key Usage extension in the certificate must contain the Digital Signature and Key Encipherment fields.
The Extended Key Usage extension in the certificate must contain the Client Authentication and Server Authentication fields.
The Netscape Certificate Type extension is not required. If you like to include that extension, you must add both SSL Client and SSL Server in the extension.
If you are using a self-signed certificate, the Basic Constraints CA field must be set to True and the Key Usage extension must contain the Key Cert Sign field.

Control Permissions for Cisco pxGrid Clients

You can create Cisco pxGrid authorization rules for controlling the permissions for the Cisco pxGrid clients. Use these rules to control the services that are provided to the Cisco pxGrid clients.

You can create different types of groups and map the services provided to the Cisco pxGrid clients to these groups. Use the Manage Groups option in the Permissions window to add new groups. You can view the predefined authorization rules that use predefined groups (such as EPS and ANC) in the Permissions window. Note that you can update only the Operations field for the predefined rules.

To create an authorization rule for pxGrid clients:

Procedure

Step 1

Choose Administration > pxGrid Services > Permissions.

Step 2

From the Service drop-down list, choose one of the following options:

com.cisco.ise.pubsub
com.cisco.ise.config.anc
com.cisco.ise.config.profiler
com.cisco.ise.config.trustsec
com.cisco.ise.service
com.cisco.ise.system
com.cisco.ise.radius
com.cisco.ise.sxp
com.cisco.ise.trustsec
com.cisco.ise.mdm

Step 3

From the Operation drop-down list, choose one of the following options:

<ANY>
publish
publish /topic/com.cisco.ise.session
publish /topic/com.cisco.ise.session.group
publish /topic/com.cisco.ise.anc
<CUSTOM>: You can specify a custom operation if you select this option.

Step 4

From the Groups drop-down list, choose the groups that you want to map to this service.

Predefined groups (such as EPS and ANC) and manually added groups are listed in this drop-down list.

Note

Only the clients that belong to the groups included in the policy can subscribe to the service specified in that policy. For example, if you define a pxGrid policy for com.cisco.ise.pubsub service and assign ANC group to this policy, only the clients that belong to the ANC group can subscribe to the com.cisco.ise.pubsub service.

View Nodes in a Deployment

In the Deployment Nodes window, you can view all the Cisco ISE nodes, primary and secondary, that are part of your deployment.

Procedure

Step 1

Log in to the primary Cisco ISE Admin portal.

Step 2

Choose Administration > System > Deployment.

Step 3

Click Deployment from the navigation pane on the left.

All the Cisco ISE nodes that are part of your deployment are listed.

Download Endpoint Statistical Data from MnT Nodes

You can download statistical data about endpoints that connect to your network from the MnT nodes. Key Performance Metrics (KPM), which include the load, CPU usage, authentication traffic data are available. You can use to monitor and troubleshoot issues in your network. From the Cisco ISE CLI, use the application configure ise command and choose options 12 or 13 to download the daily KPM statistics or KPM statistics for the last eight weeks.

The output of this command provides the following data about endpoints:

Total endpoints on your network
Number of endpoints that established a successful connection
Number of endpoints that failed authentication
Total number of new endpoints that have connected each day
Total number of endpoints onboarded each day

The output also includes time stamp details, the total number of endpoints that connected through each of the Policy Service nodes (PSNs) in the deployment, total number of endpoints, active endpoints, load, and authentication traffic details.

See the Cisco Identity Services Engine CLI Reference Guide for more information on this command.

Database Crash or File Corruption Issues

Cisco ISE may crash if the oracle database files are corrupted due to power outage or other reasons resulting in data loss. Based on the incident, follow the instructions below to recover from data loss.

In case of PAN corruption in deployment, you should promote the Secondary PAN to Primary PAN.
If the secondary PAN's promotion is not possible due to a small deployment or any other reason, restore the most recent available backup as described in Cisco Identity Services Engine CLI Reference Guide.
In case of PSN corruption, follow the steps to de-register, reset config, and register as described in the Cisco Identity Services Engine CLI Reference Guide.

In case of a standalone device, restore the most recent available backup as described in Cisco Identity Services Engine CLI Reference Guide.

Note

Obtain the backup from the standalone device regularly to avoid loss in the latest configuration changes.

Device Configuration for Monitoring

The MnT node receives and uses data from the devices on a network to populate the dashboard display. To enable communication between the MnT node and the network devices, the switches and NADs must be configured properly.

Synchronize Primary and Secondary Cisco ISE Nodes

You can make configuration changes to Cisco ISE only through the primary PAN. The configuration changes get replicated to all the secondary nodes. If, for some reason, this replication does not occur properly, you can manually synchronize the secondary PAN with the primary PAN.

Procedure

Step 1	Log in to the primary PAN.
Step 2	Choose Administration > System > Deployment.
Step 3	Check the check box next to the node that you want to synchronize with the primary PAN, and click Syncup to force a full database replication.

Change Node Personas and Services

You can edit the Cisco ISE node configuration to change the personas and services that run on the node.

Before you begin

When you enable or disable any of the services that run on a PSN or make any changes to a PSN, you will be restarting the application server processes on which these services run. Expect a delay while these services restart.
Due to this delay in restart of services, automatic failover if enabled in your deployment, might get initiated. To avoid this, make sure that the automatic failover configuration is turned off.

Procedure

Step 1	Log in to the primary PAN.
Step 2	Choose Administration > System > Deployment.
Step 3	Check the check box next to the node whose personas or services you want to change, and then click Edit.
Step 4	Choose the personas and services that you want.
Step 5	Click Save.
Step 6	Verify receipt of an alarm on your primary PAN to confirm the persona or service change. If the persona or service change is not saved successfully, an alarm is not generated.

Effects of Modifying Nodes in Cisco ISE

When you make any of the following changes to a node in a Cisco ISE, that node restarts, which causes a delay:

Register a node (Standalone to Secondary)
Deregister a node (Secondary to Standalone)
Change a primary node to Standalone (if no other nodes are registered with it; Primary to Standalone)
Promote an Administration node (Secondary to Primary)
Change the personas (when you assign or remove the Policy Service or Monitoring persona from a node)
Modify the services in the Policy Service node (enable or disable the session and profiler services)
Restore a backup on the primary and a sync up operation is triggered to replicate data from primary to secondary nodes

Note

When you promote the secondary Administration node to the primary PAN position, the primary node will assume a secondary role. This causes both the primary and secondary nodes to restart, causing a delay.

Create a Policy Service Node Group

When two or more Policy Service nodes (PSNs) are connected to the same high-speed Local Area Network (LAN), we recommend that you place them in the same node group. This design optimizes the replication of endpoint profiling data by retaining less significant attributes that are local to the group and reducing the information that is replicated to the remote nodes in the network. Node group members also check on the availability of peer group members. If the group detects that a member has failed, it attempts to reset and recover all URL-redirected sessions on the failed node.

The node groups are used for the PSN failover in the sessions on which URL redirect (posture services, guest services and MDM) is imposed.

Note

We recommend that you make all the PSNs in the same local network and part of the same node group. PSNs need not be part of a load-balanced cluster to join the same node group. However, each local PSN in a load-balanced cluster should typically be part of the same node group.

Before you can add PSNs as members to a node group, you must create the node group. You can create, edit, and delete PSN groups from the Deployment window of the Admin portal.

Before you begin

Node group members can communicate over TCP/7800.

Procedure

Step 1

Choose Administration > System > Deployment.

Step 2

Click the Settings icon at the top of the left navigation pane.

Step 3

Click Create Node Group.

Step 4

Enter a unique name for your node group.

Note

We do not recommend configuring a node group with the name None, as it may cause undesirable issues in node registration.

Step 5

(Optional) Enter a description for your node group.

Step 6

(Optional) Check the Enable MAR Cache Distribution check box and fill in the other options. Ensure that the MAR is enabled in the Active Directory window before enabling this option.

Step 7

Click Submit to save the node group.

After you save the node group, it should appear in the left navigation pane. If you do not see the node group in the left pane, it may be hidden. Click the Expand button on the navigation pane to view the hidden objects.

What to do next

Add a node to a node group, or edit a node by choosing the corresponding node group from the Include node in node group drop-down list in the Policy Service area.

Remove a Node from Deployment

To remove a node from a deployment, you must deregister it. The deregistered node becomes a standalone Cisco ISE node.

It retains the last configuration that it received from the primary PAN and assumes the default personas of a standalone node, that is, Administration, Policy Service, and Monitoring. If you deregister an MnT node, this node will no longer be a syslog target.

When a Primary PSN is deregistered, the endpoint data is lost. If you want the PSN to retain the endpoint data after it becomes a standalone node, do one of the following:

Obtain a backup from the primary PAN, and when the PSN becomes a standalone node, restore this data backup on it.
Change the persona of the PSN to Administration (secondary PAN), synchronize the data in the Deployment window of the Admin portal, and then deregister the node. This node will now have all the data. You can then add a secondary PAN to the existing deployment.

You can view these changes in the Deployment window of the primary PAN. However, expect a delay of five minutes for the changes to take effect and appear in the Deployment window.

Before you begin

Before you remove a secondary node from a deployment, perform a backup of Cisco ISE configuration, which you can then restore later on, if needed.

Procedure

Step 1	Choose Administration > System > Deployment.
Step 2	Check the check box next to the secondary node that you want to remove, and then click Deregister.
Step 3	Click OK.
Step 4	Verify the receipt of an alarm on your primary PAN to confirm that the secondary node is deregistered successfully. If the secondary node fails to deregister from the primary PAN, the alarm is not generated.

Shut Down a Cisco ISE Node

Before you issue the halt command from the Cisco ISE CLI, we recommend that you stop the Cisco ISE application service and ensure that it is not performing a backup, restore, installation, upgrade, or remove operation. If you issue the halt command while the Cisco ISE is performing any of these operations, you will get one of the following warning messages:

WARNING: A backup or restore is currently in progress! Continue with halt?

WARNING: An install/upgrade/remove is currently in progress! Continue with halt?

If no processes are running when you use the halt command, or if you enter Yes in response to the warning message displayed, then you must respond to the following question:

Do you want to save the current configuration?

If you enter Yes to save the existing Cisco ISE configuration, the following message is displayed:

Saved the running configuration to startup successfully.

Note

We recommend that you stop the application process before rebooting the appliance.

This is also applicable to reboot Cisco ISE. For more information, see the Cisco Identity Services Engine CLI Reference Guide.

Sample Scenarios Where You Need to Reregister a Node

The following table summarizes some of the scenarios where you need to reregister a node when it is corrupted:

Scenarios

What needs to be done

If any of the nodes other than the Primary PAN is corrupted

Deregister the failed node from the deployment.
Reinstall Cisco ISE on the failed node.
Reregister the node to the existing deployment.

Note

You must import the old certificates to the node before or after the registration.

If the Primary PAN is corrupted

For example, if there are two nodes: N1 (Primary PAN) and N2 (Secondary PAN)

Promote secondary PAN (N2) to Primary PAN.
Remove the failed node (N1) from the deployment.
Reinstall Cisco ISE on the failed node (N1).
Register the node (N1) as Secondary PAN to deployment.
Import the old certificates to the node (N1) after the registration is completed.
Promote the node (N1) back to Primary PAN to have similar deployment as earlier.

If both Primary PAN and Secondary PAN are corrupted

For example, if there are two nodes: N1 (Primary PAN) and N2 (Secondary PAN)

Reinstall Cisco ISE on Primary PAN node (N1) and Secondary PAN node (N2).
Restore configuration backup on Primary PAN node (N1).
Import old certificates on Primary PAN node (N1).
Register the other node (N2) as Secondary PAN to the deployment.
Perform reset-config on other nodes and register the nodes to the deployment.
Import certificates to all the nodes.

Note

If the Primary PAN and Secondary PANs are VMs, reinstalling Cisco ISE might change the UDI. Hence, you must reinstall the licenses with the new UDIs.

Change the Hostname or IP Address of a Standalone Cisco ISE Node

You can change the hostname, IP address, or domain name of standalone Cisco ISE nodes. However, you cannot use localhost as the hostname for a node.

Before you begin

If a Cisco ISE node is a part of a distributed deployment, you must first remove it from the deployment and ensure that it is a standalone node.

Procedure

Step 1

Change the hostname or IP address of the Cisco ISE node using the hostname , ip address , or ip domain-name command from the Cisco ISE CLI.

Step 2

Reset the Cisco ISE application configuration using the application stop ise command from the Cisco ISE CLI to restart all the services.

Step 3

Register the Cisco ISE node to the primary PAN if it is a part of a distributed deployment.

Note

If you are using the hostname while registering the Cisco ISE node, the fully qualified domain name (FQDN) of the standalone node that you are going to register, for example, abc.xyz.com must be DNS-resolvable from the primary PAN. Otherwise, node registration fails. You must enter the IP addresses and FQDNs of the Cisco ISE nodes that are a part of your distributed deployment in the DNS server.

After you register the Cisco ISE node as a secondary node, the primary PAN replicates the change in the IP address, hostname, or domain name to the other Cisco ISE nodes in your deployment.

Bias-Free Language

Results

Chapter: Cisco ISE Deployment Terminology

Cisco ISE Deployment Terminology

Personas in Distributed Cisco ISE Deployments

Configure a Cisco ISE Node

Before you begin

Procedure

Configure a Primary Policy Administration Node (PAN)

Procedure

What to do next

Register a Secondary Cisco ISE Node

Before you begin

Procedure

What to do next

Support for Multiple Deployment Scenarios

Cisco ISE Distributed Deployment

Cisco ISE Deployment Setup

Data Replication from Primary to Secondary ISE Nodes

Cisco ISE Node Deregistration

Guidelines for Setting Up a Distributed Deployment

Menu Options Available on Primary and Secondary Nodes

Deployment and Node Settings

Deployment Nodes List Window

General Node Settings

Profiling Node Settings

Logging Settings

Remote Logging Target Settings

Configure Logging Categories

Admin Access Settings

Administrator Password Policy Settings

Session Timeout and Session Information Settings

Administration Node

High Availability for the Administrative Node

High-Availability Health Check Nodes

Health Check Node for the Secondary PAN

Disabling and Restarting Health Check

Health Check Nodes

Changing Health Nodes

Automatic Failover to the Secondary PAN

Health Check Node Restarts

Bring Your Own Device in Case of Automatic Failover to Secondary PAN

Sample Scenarios when Automatic Failover is Avoided

Functionalities Affected by the PAN Automatic Failover Feature

Configure Primary PAN for Automatic Failover

Before you begin

Procedure

What to do next

Manually Promote Secondary PAN to Primary

Before you begin

Procedure

What to do next

Restoring Service to the Primary PAN

Support for Automatic Failover for the Administration Node

Policy Service Node

High Availability in Policy Service Nodes

Load Balancer to Distribute Requests Evenly Among PSNs

Session Failover in Policy Service Nodes

Number of Nodes in a Policy Service Node Group

Monitoring Node

Manually Modify the MnT Role

Procedure

Automatic Failover in MnT Nodes

Automatic Failover Process

Guidelines for Setting Up an Active Standby Pair of MnT Nodes

MnT Node Failover Scenarios

Monitoring Database

Back Up and Restore the Monitoring Database

Monitoring Database Purge

Guidelines for Purging the Monitoring Database

Operational Data Purging

Purge Older Operational Data

Before you begin

Procedure

Configure MnT Nodes for Automatic Failover

Before you begin

Procedure

Cisco pxGrid Node

Cisco pxGrid Client and Capability Management