Implementing ISE Redirectionless Posture

Introduction

This document describes the use and configuration of redirectionless posture flow and troubleshooting tips.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Posture flow on ISE
• Configuration of posture components on ISE
• Redirection to ISE portals

For a better understanding of the concepts described later, it's recommended to go through:

Compare Earlier ISE Versions to ISE Posture Flow in ISE 2.2
ISE Session Management and Posture

Components Used

The information in this document is based on these software and hardware versions:

• Cisco ISE version 3.1
• Cisco Secure Client 5.0.01242

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background information

ISE Posture flow consists of the following steps:

0. Authentication/Authorization. Generally performed right before posture flow is initiated but it can be bypassed for certain use cases such as Posture Reassessment (PRA). As authentication itself does not trigger posture discovery this is not considered essential for every posture flow.

1. Discovery. Process performed by the Secure Client ISE Posture module to find the PSN owner of the current active session.
2. Client Provisioning. Process performed by ISE to provision the client with the corresponding Cisco Secure Client (formerly AnyConnect) ISE Posture module and Compliance Module versions. In this step, the local copy of the posture profile contained in and signed by the particular PSN is also pushed to the client.
3. System Scan. Posture policies configured on ISE are evaluated by the Compliance Module.
4. Remediation (Optional). Performed in the case of any posture policies being not compliant.
5. CoA. Reauthorization is necessary to grant final (Compliant or Not Compliant) network access.

This document focuses on the Discovery process of ISE Posture flow.

Cisco recommends to use redirection for the discovery process, however, there are certain cases where redirection is not possible to implement such as the use of third party Network Devices where redirection is not supported. This document aims to provide a general guidance and best practices to implement and troubleshoot redirectionless posture in such environments.

Full description of redirectionless flow is described in Compare Earlier ISE Versions to ISE Posture Flow in ISE 2.2.

There are two types of posture discovery probes that do not use redirection:

1. Connectiondata.xml
2. Call Home List

Connectiondata.xml

Connectiondata.xml is a file created and maintained automatically by Cisco Secure Client. It consists of a list of PSNs that the client has previously successfully connected to for posture, hence, this is only a local file and its content is not persistent across all endpoints.

The main purpose of connectiondata.xml is to work as a backup mechanism for both Stage 1 and Stage 2 discovery probes. In case that redirection or Call Home List probes are unable to find a PSN with an active session, Cisco Secure Client sends a direct request to each of the servers listed in connectiondata.xml.

Stage 1 discovery probes

Stage 2 discovery probes

A common problem caused by the use of connectiondata.xml probes is an overload of the ISE deployment due to a large number of HTTPS requests sent by the endpoints. It is important to consider that while connectiondata.xml is effective as a backup mechanism to avoid full outages for both redirection and redirectionless posture mechanisms, it is not a sustainable solution for a posture environment, therefore, it is necessary to diagnose and resolve the design and configuration problems that cause the failure of the main discovery probes and that result in discovery issues.

Call Home List

Call Home List is a section of the posture profile where a list of PSNs is specified to be used for posture. Unlike connectiondata.xml, this is created and maintained by an ISE administrator and might require a design phase for optimal configuration. The list of PSNs in Call Home List should match the list of authentication and accounting servers that is configured in the network device or load balancer for RADIUS.

Call Home List probes enable the use of an MnT lookup during active session search in case of a local lookup failure in a PSN. The same functionality extends to connectiondata.xml probes only when they are used during Stage 2 discovery. For this reason, all Stage 2 probes are also referred to as New Generation probes.

MnT lookup flow

Design

As a redirectionless discovery process often entails a more complex flow and a larger amount of processing on PSNs and MnT compared to a redirection flow, there are two common challenges that can arise during implementation:

1. Effective discovery
2. Performance of ISE deployment

In order to cope with these challenges, it is recommended to design the Call Home List to limit the number of PSNs that a given endpoint can use for posture. For medium and large deployments, it is necessary to distribute the deployment in order to create multiple Call Home Lists with reduced number of PSNs, in consequence the list of PSNs that are used for RADIUS authentication for a given Network Device should be limited in the same way to match the corresponding Call Home List.

The following aspects can be taken into consideration while developing the PSN distribution strategy to determine the maximum number of PSNs in each Call Home List:

• Number of PSNs in the deployment
• Hardware specs of PSNs and MnT nodes
• Maximum number of concurrent posture sessions in the deployment
• Number of network devices
• Hybrid environments (simultaneous redirection and redirectionless posture implementation)
• Number of adapters used by the endpoints
• Location of network devices and PSNs
• Network connection types used for posture (wired, wireless, VPN)

Example. PSN distribution for redirectionless posture

Tip: Use Network Device Groups to classify the network devices according to the design.

Configure

Network Device Groups (Optional)

Network Device Groups can be used to identify and match network devices with their corresponding RADIUS server list and Call Home List. In the case of hybrid environments, they can also be used to identify devices that support redirection from devices that don’t.

If the distribution strategy developed during design phase relies on Network Device Groups, follow the next steps to configure them on ISE:

1. Navigate to Administration > Network Resources Network Resource Groups.
2. Click Add to add a new group, provide a name and select the parent group if applicable.
3. Repeat step 2 to create all the necessary groups.

In the examples used throughout this guide, Location Device Group is used to identify the RADIUS servers list and Call Home List, and a custom Posture Device Group is used to identify Redirection from Redirectionless posture devices.

Network Device Groups

Network Device

1. The network device should be configured for RADIUS authentication, authorization and accounting, refer to each vendor documentation for configuration steps. Configure the RADIUS servers list according to the corresponding Call Home List.
2. On ISE, navigate to Administation > Network Resources > Network Devices and click Add. Configure the Network Device Groups according to the design and enable RADIUS Authentication Settings to configure the Shared Secret.

Network Device configuration

Client Provisioning

There are two ways to provision the client with the right software and profile to perform posture in a redirectionless environment:

1. Manual provisioning (pre-deploy)
2. Client Provisioning Portal (web deploy)

Manual Provisioning (pre-deploy)

• Download and install Cisco Secure Client Profile Editor from Cisco Software Download.Profile Editor package
• Open ISE Posture profile editor:
• Make sure that Enable Posture Non-Redirection Flow is enabled.
• Configure the Server name rules separated by commas. Use use a single asterisk * to allow connection to any PSN, wildcard values to allow connection to any PSN in a specific domain or the PSN FQDNs to restrict the connection to specific PSNs.
• Configure Call Home List to specify the comma-separated list of PSNs. Make sure to add the Client Provisioning Portal port with the format FQDN:port or IP:port.
  Posture profile configuraiton with Profile Editor
  
  

  Note: Refer to step 4 of the Client provisioning policy section for instructions on how to verify the Client Provisioning Portal port if necessary.

• Repeat step 2 for each Call Home List in Use.
• Download the Cisco Secure Client pre-deploy package from Cisco Software Download.
  Cisco Secure Client pre-deploy package
• Save the profile as ISEPostureCFG.xml.
• Distribute the profile and installation files in an archive file, or copy the files to the clients.

  Warning: Make sure that the same Cisco Secure Client files are also on the headends you plan to connect to: Secure Firewall ASA, ISE, and so on. Even when manual provisioning is used, ISE must be configured for client provisioning with the corresponding software version. Refer to the Client provisioning policy configuration section for detailed instructions.

• On the client, open the zip file in and run the Setup to install the Core and ISE Posture modules. Alternatively the individual msi files can be used to install each module, in this case, you must make sure that core-vpn module is installed first.

  Cisco Secure Client pre-deploy package contents

  
  

  Cisco Secure Client installer

  Tip: Install the Diagnostic and Reporting Tool to be used for troubleshooting purposes. 

• Once installation is complete copy the posture profile xml to the following locations:
  • Windows: %ProgramData%\Cisco\Cisco Secure Client\ISE Posture
  • MacOS: /opt/cisco/secureclient/iseposture/

Client provisioning portal (web deploy)

ISE Client Provisioning Portal can be used to install Cisco Secure Client ISE Posture module and the posture profile from ISE, it can also be used to push the posture profile alone if ISE Posture module is already installed on the client.

1. Navigate to Work Centers > Posture > Client Provisioning > Client Provisioning Portal to open the portal configuration. Expand Portal Settings section and locate the Authentication method field, select the Identity Source Sequence to be used for authentication in the portal.
2. Configure internal and external identity groups that are authorized to use the Client Provisioning Portal.
   Authentication method and authorized groups in portal settings
3. In the Fully qualified domain name (FQDN) field configure the URL that is used by the clients to access the portal. To configure multiple FQDNs, enter the values separated by commas.
   
4. Configure the DNS server(s) to resolve the portal URL to the PSNs of the corresponding Call Home List.
5. Provide the FQDN to the end users to access the portal in order to install the ISE Posture software.

Note: To make use of the portal FQDN, clients must have the PSN Admin certificate chain as well as the Portal certificate chain installed in the trusted store, and the Admin certificate must contain the portal FQDN in the SAN field.

Client provisioning policy

Client provisioning must be configured on ISE regardless of the type of provisioning (pre-deploy or web deploy) that is used to install Cisco Secure Client on the endpoints.

1. Download the Cisco Secure Client webdeploy package from Cisco Software Download.Cisco Secure Client webdeploy package
2. Download the latest Compliance Module webdeploy package from Cisco Software Download.
   ISE Compliance Module webdeploy package
3. On ISE, navigate to Work Centers > Posture > Client Provisioning > Resources and click Add > Agent resources from local disk. Select Cisco Provided Packages from the Category drop down menu and upload the Cisco Secure Client webdeploy package previously downloaded. Repeat the same process to upload the Compliance Module.Upload Cisco Provided Packages to ISE
4. Back in the Resources tab, click Add > AnyConnect Posture Profile. On the profile:
   • Configure a name that can be used to identify the profile within ISE.
   • Configure the Server name rules separated by commas. Use use a single asterisk * to allow connection to any PSN, wildcard values to allow connection to any PSN in a specific domain or the PSN FQDNs to restrict the connection to specific PSNs.
   • Configure Call Home List to specify the comma-separated list of PSNs. Make sure to add the Client Provisioning Portal port using the format FQDN:port or IP:port.ISE Posture profile configuration I
     ISE Posture Profile configuration II

   
   To find the port that should be used in Call Home List, navigate to Work Centers > Posture > Client Provisioning > Client Provisioning Portal, select the portal in use and expand Portal Settings.

   Client Provisioning Portal port

5. Back in the Resources tab, click Add > AnyConnect Configuration. Select the Cisco Secure Client package and Compliance Module to be used.

   Warning: If Cisco Secure Client has been pre deployed to the clients, make sure that the version on ISE matches the version on the endpoints. If ASA or FTD is used for web deploy, the version on this device should match as well.

6. Scroll down to the Posture Selection section and select the profile that was created on step 1. Click Submit at the bottom of the page to save the configuration.AnyConnect Configuration
   Profile selection
7. Navigate to Work Centers > Posture > Client Provisioning > Client provisioning policy. Locate the policy that is used for the required Operating System and click Edit. Click the + sign on the Results column and select the AnyConnect configuration from step 5 under the Agent Configuration section.
   
   

   Note: In the case of multiple Call Home Lists, use the Other Conditions field to push the right profile to the corresponding clients. In the example, Device Location Group is used to identify the posture profile that is pushed in the policy.

   Tip: If multiple client provisioning policies are configured for the same OS, it is recommended to make them mutually exclusive, that is, a given client should only be able to hit one policy at a time. RADIUS attributes can be used under Other Conditions column to differentiate one policy from another.

   
   Client Provisioning Policy Agent ConfigurationClient Provisioning Policy
8. Repeat steps 4 to 7 for each Call Home List and corresponding posture profile in use. For hybrid environments, the same profiles can be used for redirection clients.

Authorization

Authorization profile

1. Navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs and click Add.
2. Create a DACL to allow traffic to DNS, DHCP (if used), ISE PSNs and block other traffic. Make sure to allow any other traffic that is necessary to access before final compliant access.

   DACL configuration

   permit udp any any eq domain
   permit udp any any eq bootps
   permit ip any host <PSN 1>
   permit ip any host <PSN 2>
   deny ip any any

   Caution: Some third party devices might not support DACLs, in such cases it is necessary to use a Filter-ID or other vendor specific attributes. Refer to the vendor documentation for more information. If DACLs are not used, make sure to configure the corresponding ACL in the network device.

3. Navigate to Policy > Policy Elements > Results > Authorization >Authorization profiles and click Add. Give a name to the authorization profile and select DACL name from Common Tasks. From the drop down menu, select the DACL created in step 2.Authorization profile

   Note: If DACLs are not used, use Filter-ID from Common Tasks or the Advanced Attribute Settings to push the corresponding ACL name.

4. Repeat steps 1 to 3 for each Call Home List in use. For hybrid environments, only a single authorization profile for redirection is necessary. The configuration of the authorization profile for redirection is out of the scope of this document.

Authorization Policy

1. Navigate to Policy > Policy Sets and open the policy set in use or create a new one.
2. Scroll down to Authorization Policy section. Create an authorization policy using Session PostureStatus NOT_EQUALS Compliant and select the authorization profile created in the previous section.
   Authorization policies
3. Repeat step 2 for each Authorization Profile with their corresponding Call Home List in use. For hybrid environments, only a single authorization policy for redirection is necessary.

Troubleshoot

Compliant on Cisco Secure Client and posture Not Applicable (Pending) on ISE

Stale/phantom sessions

The presence of stale or phantom sessions in the deployment can generate intermittent and apparently random failures with redirectionless posture discovery which result in users being stuck in a posture unknown/not applicable access on ISE while Cisco Secure Client UI shows Compliant access.

Stale sessions are old sessions that are no longer active. They are created by an authentication request and accounting start but no accounting stop is received on the PSN to clear the session.

Phantom sessions are sessions that was never actually active in a particular PSN. They are created by an accounting interim update but no accounting stop is received on the PSN to clear the session.

Identify

To identify a stale/phantom session issue, verify the PSN used in system scan on the client and compare with the PSN performing the authentication:

1. In Cisco Secure Client UI, click on the gear icon at the bottom left corner. From the left menu, open ISE Posture section and navigate to Statistics tab. Take note of the Policy Server in Connection Information.
   Policy Server for ISE Posture in Cisco Secure Client
2. In ISE RADIUS live logs take note of the following:
   • Change in Posture Status
   • Change in Server
   • No change in Authorization Policy and Authorization Profile
   • No CoA live log
   Live logs for stale/phantom session
3. Open the live session or the last authentication live log details. Take note of the Policy Server, if it differs from the server observed on step 1, this indicates an issue with stale/phantom sessions.
   Policy server in live log details

Solution

ISE versions above ISE 2.6 patch 6 and 2.7 patch 3 implement RADIUS Session Directory as a solution for stale/phantom session scenario in re-directionless posture flow.

1. Navigate to Administration > System > Settings > Light Data Distribution and verify that Enable RADIUS Session Directory checkbox is enabled.
   Enable RADIUS Session Directory
   
   
2. From ISE CLI verify that ISE Messaging Service is running on all PSNs by running the command show applications status ise.
   ISE Messaging Service running
   

   Note: This service refers to the communication method that is used for RSD between PSNs and should be running regardless of the status of the ISE Messaging Service setting for syslog that can be set from ISE UI.

3. Navigate to ISE Dashboard and locate the Alarms dashlet. Verify if there are any Queue Link Error alarms. Click on the name of the alarm to see more details.
   Queue Link Error alarms
4. Verify if the alarms are generated between the PSNs used for posture.
   Queue Link Error alarm details
5. Hover over the alarm description to see the full details and take note of the Cause field. The two most common causes for queue link error are: 
   • Time out: indicates that the requests sent by a node to another node on port 8671 are not responded within threshold. To remediate, verify that TCP port 8671 is allowed between the nodes.
   • Unknown CA: indicates the certificate chain signing the ISE Messaging certificate is not valid or incomplete. To remediate this error:
   1. Navigate to Administration > System > Certificates > Certificate signing requests.
   2. Click on Generate Certificate Signing Requests (CSR).
   3. From the drop down menu select ISE Root CA and click Replace ISE Root CA Certificate chain.
      If ISE Root CA is not available, navigate to Certificate Authority > Internal CA settings and click Enable Certificate Authority, then go back to the CSR and regenerate the Root CA.
   4. Generate a new CSR and select ISE Messaging Service from the drop down menu.
   5. Select all the nodes from the deployment and regenerate the certificate.

   Note: It is expected to observe Queue Link Error alarms with cause Unknown CA or Econnrefused while the certificates are regenerated, monitor the alarms after certificate generation to confirm that the issue is resolved.

Performance

Identify

Performance issues such as high CPU utilization and high load average related to redirectionless posture can impact PSN as well as MnT nodes and are often accompanied or preceded by the following events:

• Random or intermittent No policy server detected errors in Cisco Secure Client
• Maximum resource limit reached reports for Portal service thread pool reached threshold value events. Navigate to Operations > Reports > Reports > Audit > Operations Audit to see the reports.
• Posture Query to MNT lookup is high alarms. These alarms are only generated on ISE 3.1 and above versions.

Solution

If performance of the deployment is impacted by redirectionless posture, this is often indicative of an ineffective implementation. It is recommended to revise the following aspects:

• Number of PSNs used per Call Home List. Consider reducing the number of PSNs that can be used for posture per endpoint or network device according to the design.
• Client provisioning portal port in Call Home List. Make sure that the portal port number is included after the IP or FQDN of each node.

To mitigate the impact:

1. Clear connectiondata.xml from the endpoints by removing the file from the Cisco Secure Client folder and restart the ISE Posture service or Cisco Secure Client. If the services are not restarted, the old file is regenerated and the changes don't take effect. This action should also be performed after revising and modifying the Call Home lists.
2. Use DACLs or other ACLs to block traffic to ISE PSNs for network connections where it is not relevant:

• For connections where posture is not enforced in the authorization policies but that apply to endpoints with Cisco Secure Client ISE Posture module installed, block traffic from the clients to all ISE PSNs for TCP ports 8905 and Client Provisioning Portal port. This action is recommended for posture with redirection implementation as well.
• For connections where posture is enforced in the authorization policies, allow traffic from the clients to the authenticating PSN and block traffic to other PSNs in the deployment. This action can be implemented temporarily while the design is revised.
  Authorization profile with DACL for single PSN
  Authorization policies per PSN

Accounting

RADIUS accounting is essential for session management on ISE. Since posture relies on an active session to be performed, incorrect or lack of accounting configuration can also impact posture discovery and ISE performance. It is important to verify that accounting is correctly configured on the network device to send authentications requests, accounting start, accounting stop and accouting updates to a single PSN for each session.

To verify accounting packets received on ISE, navigate to Operations > Reports > Reports > Endpoints and Users > RADIUS Accounting.

Related Information

• Cisco Technical Support & Downloads