Wireless attitude with ISE 3.0 and AnyConnect 4.9 (2023)

The traffic flow shown in the diagram above includes the wireless connectivity use case. For this use case, an SSID used only for our corporate users will be enabled for maintenance. There are no other use cases such as BYOD, Guest or others on this SSID. This document describes three separate use cases for proof of concept and documentation, including a client that already has the Posture and Compliance module installed, a device that does not have the Posture and Compliance module installed but AnyConnect VPN is installed, and a client that yes it has. It does not have attitude and compliance or AnyConnect.

AnyConnect module and Posture and Compliance installed

When a wireless terminal connects with the SSID palloyd-ISE30-Posture, the device is authenticated, first quarantined, and a redirect ACL is applied to the terminal session. The redirect ACL allows limited connectivity, including DNS, DHCP, traffic going to the ISE for tunneling and provisioning requests, and denies any additional traffic, forcing all web page visits to redirect to the ISE until complete the tunnel. The posture check included in this tutorial looks for a file named watermark.txt in the C:\Temp folder on the target PC. If the file is not found, it is downloaded and can be saved by the ISE user, after which the posture check succeeds. The posture test varies in how long it takes and then resolves, but is typically 60 seconds each.

used components

Wireless authentication servers

The authentication and accounting servers configured on the WLC point to the ISE to ensure that authentication and accounting requests are sent specifically to the server that should authorize the endpoint and apply restrictions to the endpoint's session.

Note that "CoA Support", known as "RFC 3576 Support" in other releases, is enabled in this demo and is required for Posture. This configuration ensures that the endpoint can have initial authorization, quarantine authorization, and that the authorization result can be changed if the device passes a successful health check with a compatible authorization to be applied to the endpoint session. final. Without this check box, there may be issues with the ability to change from Session State: Unknown to Session State: Supported.

WLAN-SSID

The wireless SSID is configured as a default wireless SSID for 802.1x authentication in addition to a WPA+WPA2 Layer 2 security mechanism. It specifically uses a WPA2 policy with AES encryption:

In addition to the WPA2 policy, 802.1x is enabled for the WiFi SSID and AAA servers configured in the corresponding tab.

The AAA servers are configured to point to an authentication and accounting server at 10.87.2.181 and we use RADIUS first in the order of authentication.

The Advanced tab on the SSID is used to configure the SSID to trust the information from the ISE and apply that information to individual sessions by applying the authorization result obtained from the ISE.

Since the SSID has been "trained" to use the information received from Cisco ISE as part of network access control, it must also ensure that traffic is routed as expected, which means that the FlexConnect local switch option it should be disabled. When session posture occurs, we want the traffic to be redirected to the ISE node via the wireless LAN controller and the session to be limited to sending only the traffic that we have included in the ACL pointing to the session.

Additionally, we would like to use the information we collect from the WLC to try to identify or profile the device and determine what the device is so that ISE can provide differentiated policies based on the "what" as part of the contextual identity.

For those unfamiliar with the concept of "contextual identity", ISE's ability to enforce detailed authorization results is based on:

• WE AREconnected to the network with a device
• ERAThe device is identified in the profiling process trying to gain access
• operating systemThis device is designed to ensure that we can differentiate access when location-based policies are enforced.
• SEA device joined the network and allowed access during certain hours or warned about access outside of business hours
• ASa device joined the network, that is, what means in wired, wireless, VPN or virtual context.

When the SSID is configured, an access control list referenced by the Identity Services Engine is required so that it can be applied to single sessions when terminating on the wireless LAN controller. This ACL, referred to in the previous paragraphs, includes DNS, DHCP, provisioning traffic, and allowed traffic to the ISE, while all other traffic is denied and redirected to the ISE PSN.

While this ACL can be shortened to apply directional permissions on every statement, since this is a test lab installation, only client deployment permissions are directional for now.

In addition to configuring the WebAuth redirect ACL, a supported and non-compliant ACL must also be configured. This depends on the organization and the permissions required by policy for compliant and non-compliant endpoints, which is typically just "any permission" for compliance and Internet only for non-compliant.

Specifically, in this demo, the default enforces WebAuth redirection to allow access to ISE servers and critical services, and nothing else.

ISE components

Once the WLC is configured for the servers, WLANs, authentication policies, and authorization results, it is necessary to configure the ISE, which is possibly the most time-consuming part of the posture deployment.

Within ISE, the first configuration is usually customizing the portal for deployment if the endpoint does not have the AnyConnect client or Posture and Compliance module installed. There is a default portal, but a new portal can be configured or customized. In this case, minor adjustments to adding a logo to the page are carried out through the portal settings area, which is somewhat hidden in the "Client Deployment" area.Pancake Menu > Work Centers > Posture > Customer Provisioning > Customer Procurement Portal

Minor changes were made to the logos and banner images, but the portal behavior and flow settings remained the same:

The next area to configure, considering the order of operations, is the authorization results, which are related to the configuration applied to the WLC. Three authorization results must be configured, one each for the Compliant, Non-Compatible, and Unknown states, each with a separate authorization applied to the terminal session on the wireless LAN controller. For the Unknown compliance state, a redirect is applied from the endpoint to the posture assessment portal, pointing to the WebAuth redirect URL. In the screenshots below, there is a reference to direct the client to the ISE node used during testing, which can be used when devices need to switch to a specific PSN used for Posture or Guest.

The result of this raw attribute policy is a redirect to the ISE node at 10.87.2.181 using the port configured in the portal configuration panel, the session ID associated with RADIUS, and the portal unique identifier assigned by ISE.

Policing for compliant and non-compliant policies is easy with either a downloadable ACL or an Airespace ACL applied to the endpoint session, depending on the WLC software version used. In 8.3, the Airespace ACL needs to be configured and the ACL exists on the WLC itself.

Anything beyond the basic guidelines and testing an endpoint for your posture compliance requires several resources, including the AnyConnect package to deploy, the posture and compliance module, and a shared configuration file between the two. Although some may find it contradictory, AnyConnect must be downloaded from the Cisco website in its header package format and uploaded to ISE usingClient Deployment > Add > Local Disk Agent FeaturesPossibility. Once the AnyConnect package is installed, a second agent feature addition from the Cisco website provides the ability to download the AnyConnect compliance module for the specific operating system, the temporary agent (if desired), and the setup wizard. requester's implementation. Both files are required to configure posture policies in later steps.

AnyConnect posture profile

Since the purpose of the configuration is to configure the state of the endpoints, it makes sense that a definition of what state should be checked and how the state module should be configured be configured natively in Identity Services Engine. The pipeline profile defines how the pipeline module should be configured on the endpoint and whether any special considerations should be made for the endpoint, for example, B. debugging enabled during deployment, which server the endpoint should use for posture policy if multiple ISE servers are set up or used. necessary B. how much time the user needs to correct an unsupported posture state, etc. default values ​​for the settings used, which include keeping debugging disabled, DHCP release and renew the same, and retransmission time the same. When using customizations, there is a change in recovery time to 20 minutes instead of the default of 4 on the detection host to directly point to the PSN that should be used for situation assessment, and server naming rules are defined for * then all servers respond to the posture request.

One consideration that will play a role in this production process is ensuring that all PSNs are behind a single VIP within a node pool when using a VIP. This allows session state to be replicated directly between PSNs, instead of having to send all the information over the PAN, which slows down this replication.

AnyConnect configuration file

After uploading, an AnyConnect configuration must be added by selecting the uploaded AnyConnect package and setting the options for the AnyConnect behavior. This will also refer to which modules should be implemented, as well as the compliance module to use in AnyConnect if the ISE posture is used. Also in this configuration, the posture profile created previously in the posture configuration is sent to the AnyConnect posture module. Remember that the AnyConnect package and posture profile must be present before this AnyConnect configuration can be configured; otherwise, many of the required dropdown boxes will be empty and unconfigurable.

For flexibility, both the ISE Posture module and the VPN module are selected by default during configuration in the module selection if one of them is not present. We will test these two use cases in the testing section of this document. An XML VPN profile created in the VPN profile editor is uploaded to ISE as an AnyConnect configuration file, allowing configuration by pressing AnyConnect from ISE if AnyConnect is not already configured. This file can no longer be edited once it has been uploaded to ISE.

No other changes were made to this setting other than what can be seen in the screenshots.

The next decision and configuration to make is what to check for an endpoint to indicate containment policy compliance. There is a wide range of possibilities that can be used, and each of these conditions can be combined with an "AND" or "OR" statement to create a combination of tests for the endpoints. A note on this is not to configure a large number of policies that need to be verified to use the non-conformity standard status, because the terminal will have to wait for the completion of the verifications (20 to 30 seconds based on the tests in this environment) before accessing network.

This test looks for a watermark file called watermark.txt located in the C:\Temp folder on the terminal's hard drive. The focus is on the existence of the file, not a hash or date of the file. As a result, the following condition is created:

This file can be easily renamed to fail the exam or move, making it easy to prove that the posture check works. The solution for this missing file is to copy the file to the endpoint and place it in the correct directory. After the agent rescans the endpoint, it is considered OK with the existing file.

The requirements can then be used to access both the status and the amendment. An important note is to make sure that the operating system and compliance module used are correct (seehttps://www.cisco.com/c/en/us/td/docs/security/ise/ac_compliance_module/cisco_anyconnect_ise_posture_win_support_charts_for_compliance_module_4_3_1416_6145.htmlfor compatibility reasons) and about adding to ISEClient Implementation > ResourcesArea. For most modern Posture implementations, compliance engine 4.x or later is the clear choice.

The requirements determine whether a certain condition should be checked for a certain operating system using a certain enforcement mechanism, and what the remedy should be if the condition is not met. This can be automatic or manual, including a text box that can be modified to tell the user who to contact or what action to take.

References to the condition name and remediation action align directly with the previously configured conditions and remediation.

The concept of a default state of an endpoint was mentioned earlier, with the advice not to set too many state conditions to ensure that an endpoint marked "uncompliant" doesn't prevent it from taking too long to join the network. This can be configured in the settings area of ​​the pose workspace, as well as whether or not the previous pose result is cached.

Policy

Once the posture configuration of features, requirements, fixes, and default posture status is configured, a policy can be configured to assess the status of the endpoint and authorize, redirect, and change authorization based on the configured policies. In ISE 3.0 this is slightly different as an active policy is indicated by a check mark instead of an "enabled" or "disabled" status inWorkplaces > Animal husbandry policy.However, once configured, all previously configured parts of the pipeline workflow are directly or indirectly referenced.

In this case, the policy options are configured to give the user 20 minutes to correct (Posture Profile), the Windows operating system uses the 4.x enforcement mechanism (Provide Resources), which requires the watermark to be present (Requirements) and the requirement dictates the solution.

Once the request and posture policies are configured and enabled, an authorization policy can be configured to point to the posture policy portal, enforce the redirect URL, and allow the posture engine to perform the necessary checks. This is configured as the default policy, which uses the Initial Posture Compliant DACL (allow any IP), Posture Violation Policy (redirect to Posture Portal), and Unknown Posture Policy (redirect to Posture Portal). the posture) . There is a link within the ISE Job Centers to "Policy Sets" or this can be done in the same way via the "Policy" heading. For this configuration, a network device group is configured on the wireless LAN controller network access device called WLC to allow future testing of wired and VPN media to distinguish the media. Another setting that can be used is the Called Station ID attribute, which is used to distinguish the wireless SSID you are connected to compared to other media connections.

The actual guidelines are relatively simple and relate to permission profiles based on session state.

Proof

As part of the test, three tests will be performed to demonstrate the ability to use the ISE for posture care and recovery. The first test will be a test of the AnyConnect application installed and the Containment and Compliance module also installed, which will require a connection to the ISE, the endpoint, to download and evaluate the Containment Policy. Note that the VPN module does not reference the same IP as the PSN doing the health check, as this is a separate ASA from the WLC or the PSN in general.

When the wireless medium is connected, system scanning should be automatically triggered based on the need for SSID authentication and authorization through ISE, enforcing posture-based authorization.

First authentication:

So authorization:

And finally, a compliance check based on the watermark.txt file present in the C:\Temp directory

The next test to run is to rename watermark.txt to watermark2.txt and ensure that when the endpoint disconnects and reconnects it is considered non-compliant.

This causes the file state to fail, which requires the file to be downloaded and then connected and supported. This is reflected in the Radius live logs as an unknown posture, with the breach only coming from a user who chose not to resolve the finding in the time allowed. The time for this test has been reset to 4 minutes with a 20 minute grace period for illustrative purposes. This grace period can be entered by clicking cancel or simply waiting for the 4 minute fix timer. In case of non-compliance, it was necessary to wait for the tolerance of 20 minutes:

If the policy is in effect, after the 20-minute grace period expires, the error message to fix it will look like this:

Test without posture module

After uninstalling the Posture module from the terminal via the control panel, attempting to join the wireless network without it will result in a redirection and a notification to the user that additional security software must be installed before gaining access to the network.

When you click Start, the Posture module will be installed, starting with a countdown to see if the endpoint still has AnyConnect already installed.

This asks the user to determine if they have visited this page before or if further action is required.

This will download the network setup wizard and the necessary software. This network setup wizard is hosted on the ISE server and downloaded to the client, so the client does not need Internet access.

For an unsupported device, this installs the posture module and prompts the user to fix any endpoint violations.

The same result occurs when AnyConnect is not installed:

In this test scenario, it was necessary to reboot the machine. Upon reboot, the same assessment is performed and access is provided based on previous compliance.