- Introduction
- Requirements
- Components Used
- Background Information
- AnyConnect and Posture and Compliance Module Installed
- Components Used
- Wireless Auth Servers
- Wireless SSID
- ISE Components
- AnyConnect Posture Profile
- AnyConnect Configuration File
- Policy
- Testing
- Testing without the Posture Module
Introduction
This document describes methods and procedures to configure posture in ISE 3.0 across multiple network device types and methodologies. This document will describe how configure posture on wireless, wired, and VPN based endpoints and network access devices, will cover endpoints with the posture and compliance module already deployed, and will document the installation or update of the posture and compliance module should it not exist on the expected version.
Requirements
Cisco Recommends that you have knowledge of the following topics:
- Basic knowledge of Identity Services Engine
- Understanding of the need for posture and compliance
- Basic knowledge of AnyConnect and the posture an compliance module within AnyConnect
- Basic knowledge on the redirection of endpoints to ISE to a captive portal
- Basic knowledge of wireless SSID configurations
- Basic knowledge of ASAS CLI configuration and SSL VPN configuration
- Basic knowledge of RADIUS configurations on wired network access devices.
Components Used
The following components are utilized throughout this document, many being cutting edge or pre-release to ensure the most value for customers:
- Cisco Identity Services Engine version 3.0
- AnyConnect version 4.9.00086
- A Virtual Wireless LAN Controller running version 8.3.150.0
- An AP connected to the Virtual Wireless LAN controller over REAP
- VMWare Workstation version 15.5.6
- VMWare Vsphere version 5.5
- A Linksys AE 3000 external wireless network adapter
Additional scenarios and hardware may be added in future revisions. Check back for wired and VPN use cases.
Background Information
ISE 3.0 introduces a new look and feel to ISE, however, keeps the same features and functionality of ISE 2.x related to the ability to scan an endpoint for posture compliance. Posture compliance typically consists of checking a device for a set of conditions which would yield “compliance”, consisting in many cases of:
- Anti-virus/Anti-Spyware/Anti-Malware installed, up to date, up to date within a given number of releases or days
- A file in existence or matching a hash
- A registry key which exists
- A service or application installed and/or running
- A host-based firewall installed and running
- Validation from SCCM that a device is patched and up to date
- Disk seen as encrypted on the endpoint
- A USB drive not being inserted into the device’s onboard USB ports
For any of these conditions, the validation of the conditions will be performed with the AnyConnect Posture and Compliance module as part of the authorization of the endpoint, and the device quarantined during the check, and potentially after the check dependent upon results. Once a result is returned from the posture and compliance module to Identity Services Engine, ISE can send a change of authorization to the network access device to apply the result as configured in the authorization profiles for compliant access, non-compliant access, and unknown access. Unknown access in this scenario is a designation of ISE not being able to get a result, typically during scanning or when the device does not have the posture and compliance module installed, resulting in a redirection to a provisioning page.
The flow of traffic depicted in the above diagram encompasses the wireless connectivity use case. For this use case, an SSID which is only used for our corporate users will be enabled for posture. No other use cases, such as BYOD, Guest, or any others exist on this SSID. Three separate use cases are outline within this document for proof of concept and documentation, including a client which already has the posture and compliance module installed, a device which does not have the posture and compliance module installed, but has AnyConnect VPN installed, and a client which has neither posture and compliance nor AnyConnect.
AnyConnect and Posture and Compliance Module Installed
When a wireless endpoint connects to SSID “palloyd-ISE30-Posture” the device will be authenticated, initially quarantined, and a redirection ACL applied to the endpoint’s session. The redirection ACL allows for limited connectivity, including DNS, DHCP, traffic going to ISE for posture and provisioning needs, and denies all additional traffic, forcing all web page visits to redirect to ISE until posture has completed. The posture check contained within this walkthrough is looking for the existence of a file, called “watermark.txt” in the C:\Temp folder of the PC in question. If the file is not found it is downloaded and can be saved by the user from ISE, after which point the posture check will succeed. Posture evaluation varies in time to run and then remediate, but typically is within 60 seconds for each.
Components Used
Wireless Auth Servers
The Authentication and accounting servers configured on the WLC point to ISE to ensure that authentication and accounting requests are sent specifically to the server which is expected to authorize the endpoint and apply restrictions to the endpoint’s session.
One thing to notice is that “Support for CoA”, known in other versions as “Support for RFC 3576”, is enabled in this demo and is required for Posture. This setting ensures that the endpoint is able to have an initial authorization, the quarantine authorization, and that authorization result can be changed when the device goes through a successful posture check with a compliant authorization that should be applied to the endpoint’s session. Without this checkbox, challenges may be seen around the ability to transition from Session-status:Unknown to Session-status:Compliant.
Wireless SSID
The wireless SSID is configured as a standard wireless SSID for 802.1x authentication on top of a WPA+WPA2 Layer 2 Security mechanism. It specifically uses a WPA2 policy with AES encryption:
On top of the WPA2 Policy 802.1x is enabled for the wireless SSID, and AAA servers are configured in the appropriate tab.
AAA servers are configured to point to an Authentication and Accounting server at 10.87.2.181, and we use RADIUS as first in order of authentication.
The Advanced tab within the SSID is then used to configure the SSID to trust information coming from ISE, and apply that information to individual sessions which will apply the authorization result received from ISE.
Once the SSID is “instructed” to use the information it receives from Cisco ISE as part of the network access control, there’s also a need to ensure the routing of traffic is occurring as expected, meaning the FlexConnect Local Switching option needs to be turned off. When the posture session occurs, we want the traffic to be redirected through the wireless LAN controller to the ISE node, and want the session to be restricted to only sending the traffic we’ve included in the ACL that will be applied to the session.
In addition, we’ll want to use information that we gather from the WLC to try to identify, or profile the device and determine what the device is, so that ISE can apply differentiated policies based on “what” as part of the contextual identity.
For those unfamiliar with the concept of “contextual identity”, this is the ability for ISE to apply differentiated authorization results based on:
- WHO has logged onto the network with some device
- WHAT device is identified within the profiling process attempting to gain access
- WHERE that device is to ensure when locational based policies are put into place we can differentiate access
- WHEN a device came onto the network, providing for access during certain hours, or alerting on off-hours access
- HOW a device came onto the network, i.e. which medium within the wired, wireless, VPN or virtual context.
With the SSID configured, an access control list which will be referenced by Identity Services Engine will be needed so it can be applied to unique sessions as they terminate on the Wireless LAN controller. This ACL, as referenced in the preceding paragraphs contains DNS, DHCP, provisioning traffic, and traffic to ISE allowed, with all other traffic denied and redirected to the ISE PSN.
While this ACL could be narrowed down to apply directional allowances into each statement, due to this being a test lab setup, only the permits for client provisioning will be directional for the time being.
In additional to the WebAuth Redirection ACL that will need to be configured, a compliant and non-compliant ACL should also be configured. This will differ depending on the organization and what permissions are dictated by policy for both compliant and non-compliant endpoints, many times just being a “permit any” for compliant and internet only for non-compliant.
In this demo specifically, non-compliance will have the WebAuth Redirect applied to allow for access to ISE servers and critical services, and nothing else.
ISE Components
Once the WLC is configured for servers, WLAN’s, Authentication policies, and authorization results, ISE needs to be configured, which is arguably the most time consuming portion of the posture deployment.
Within ISE, the first configuration will typically be to customize the portal for provisioning, should the endpoint not have the AnyConnect client or Posture and Compliance module installed. A default portal does exist, however a new portal can be configured, or customizations made. In this case, minor customizations to add a logo to the page are done through the portal configuration area, slightly hidden in the “Client Provisioning” area of Pancake Menu > Work Centers > Posture > Client Provisioning > Client Provisioning Portal
Minor tweaks were made to logos and banner images, however portal behavior and flow settings all remained the same:
The next area to configure, considering order of operations, is the authorization results, referring back to the configuration that was applied to the WLC. Three authorization results will need to be configured, one for each of the “Compliant”, “Non-Compliant”, and “Unknown” statuses, each with a separate authorization that is applied to the endpoint’s session on the Wireless LAN controller. In the case of the Unknown compliance status, a redirection of the endpoint to the Posture Evaluation portal will be applied, referencing the WebAuth Redirect URL. In the following screenshots, there is a reference to directly forward the client to the ISE node used during testing, which could be used in the case of needing devices to go to a specific PSN which is used for Posture or Guest.
The result of this policy for raw attributes is a redirection to the ISE node at 10.87.2.181, utilizing the port configured in the portal configuration area, session id associated with RADIUS, and unique portal identifier allocated from ISE.
Compliant and Non-Compliant policies are straight forward with a Downloadable ACL or Airespace ACL applied to the endpoint’s session, depending upon the version of WLC software being utilized. In 8.3, Airespace ACL is required to be configured, and the ACL exist on the WLC itself.
For anything beyond the basic policies, and to evaluate an endpoint for it’s posture compliance, a number of resources are required, including the AnyConnect package to deploy, the Posture and Compliance module, and a configuration file that will be pushed down to both. While some may find it counter intuitive, AnyConnect must be downloaded from the Cisco website, in it’s head end package format, and uploaded into ISE utilizing the Client Provisioning > Add > Agent resources from local disk option. Once the AnyConnect package is present, a second addition from agent resources from the Cisco site will provide for the ability to download the AnyConnect compliance module for the respective operating system, temporal agent (if desired), and the supplicant provisioning wizard. Both of these files will be required to configure posture policies in later steps.
AnyConnect Posture Profile
Given that the goal of the configuration is to configure posture for endpoints, it makes sense that a definition of what to check for posture and how the posture module should be configured is natively configured within Identity Services Engine. The Posture profile defines how the posture module on the endpoint should be configured and whether the endpoint should have any special considerations, such as debug turned on during provisioning, what server the endpoint should use for posture policy in case pinning or multiple ISE servers are required, how long the user has to remediate a non-compliant posture status, etc. In this configuration, most of the defaults are used for the configuration, including keeping debugging turned off, DHCP release and renew the same, and retransmission time the same. Where customizations will be used will be in the discovery host, to point directly to the PSN that should be used for posture evaluation, a change in the remediation time to 20 minutes as opposed to the default of 4, and the server name rules set to * to allow for any servers to respond back to the posture request.
One consideration that will play a part in this process in production is ensuring that if a VIP is used, the PSN’s all behind a single VIP are within a node group. This allows for replication of session state directly between the PSN’s, as opposed to needing to send all information through the PAN instead, delaying that replication.
AnyConnect Configuration File
Once uploaded, an Anyconnect configuration will need to be added, within which the AnyConnect package that was uploaded is selected and options configured for the behavior of AnyConnect. This will also make reference to which modules should be deployed as well as the compliance module that should be used within AnyConnect if ISE posture is to be used. The posture profile that was previously created is pushed down in the posture configuration to the AnyConnect posture module with this configuration as well. Keep in mind that the AnyConnect package and Posture profile need to both exist before this AnyConnect configuration can be configured, otherwise many of the required dropdown boxes will be unpopulated and unable to be configured.
For the sake of flexibility, the configuration within the module selection will have both the ISE Posture module selected by default, and the VPN module, in case either does not exist. We’ll test both of these use cases in the testing area of this document. A VPN XML profile created in the VPN Profile Editor is uploaded to ISE as an AnyConnect configuration file, allowing for configuration by the push of AnyConnect from ISE should AnyConnect not be configured already. This file will no longer be editable when uploaded into ISE.
No additional modifications were made to this configuration beyond what is seen in the screen shots.
The next decision and configuration that needs to be made is what to check for an endpoint to denote compliance with the posture policy. There is a wide range of what can be used, and any of these conditions can be combined with an “AND” or “OR” statement to create a combination of checks for the endpoints. One note regarding this is not to configure a large number of policies that all must be checked, while using the default status of “non-compliant” as the endpoint will need to wait until checks finish (20-30 seconds based on testing in this environment) before getting onto the network.
For this test, a watermark file will be searched for on the endpoint’s hard drive, specifically called “watermark.txt”, existing in the C:\Temp folder. The focus is the file’s existence, not a hash or date of the file. As a result, the following condition is created:
This file can easily be renamed to fail the check, or moved, so that demonstration that posture checking works is straight forward. The remediation for this file not existing is to copy the file to the endpoint and place it in the proper directory. Once the agent rescans the endpoint, it will be deemed successful with the file present.
The requirements can then be used to refer back to the condition as well as the remediation. One important note is to ensure the operating system and compliance module that is being used are both accurate (see https://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.html for compatibility), and added to ISE via the Client Provisioning > Resources area. For most modern posture deployments, compliance module 4.x or later is going to be the correct choice.
The requirements will determine whether a given condition should be checked for a given operating system, using a specific compliance module, and then what the remediation should the condition not be met should be. This can be automated, or manual, including a text box which can be modified to let the user know who to contact or what actions to take.
References to the condition name and remediation action are directly aligned with the configured conditions and remediations configured previously.
The concept of the default state of an endpoint was previously referred to, with the advisement of not setting too many posture conditions to ensure that an endpoint marked as “non-compliant” would not hinder it from taking too long from getting on the network. In the settings area of the Posture work center, this can be set, as can whether the previous result of posture is cached or not.
Policy
Once the Posture configuration of resources, requirements, remediations, and default state of posture are all configured, a policy can be configured to evaluate the endpoint’s posture, authorize, redirect, and change authorization based on policies configured. In ISE 3.0 this is slightly different in that an active policy is denoted by a check mark, as opposed to an “enabled” or “disabled” status in Work Centers > Posture Policy. However, once configured, all of the previously configured pieces of the posture workflow are referred to, either directly or indirectly.
In this case, policy options are configured to give a user 20 minutes to remediate (Posture Profile), the operating system of Windows is using the 4.x Compliance Module (Provisioning Resources), are requiring the Watermark to be present (Requirements), and the requirement will determine the remediation.
Once the requirement and posture policy are configured and enabled, an authorization policy can be configured to refer back to the posture policy portal, applying the redirection URL and allowing the posture module to undertake the checks required. This is configured as a standard policy, referring back to the initial Posture Compliant DACL (permit ip any any), Posture Non-Compliant Policy (redirection to posture portal), and Posture Unknown Policy (redirect to the posture portal). There is a linkage inside of the Work Centers of ISE to the “Policy Sets” or this can be done the same way through the “Policy” header. For this configuration, to allow for future testing of wired and VPN mediums, a Network Device Group is configured on the Wireless LAN Controller network access device, called WLC, to differentiate the mediums. Another configuration that could be used is the called-station-ID attribute which is used to differentiated the wireless SSID being connected to, as opposed to the other medium connections.
The actual policies are relatively straight forward, referring to the authorization profiles based on the session posture status.
Testing
As part of the testing, three tests are going to be carried out to demonstrate the ability to use ISE for provisioning as well as posture remediation. The first test will be a test of the AnyConnect application installed, and the Posture and Compliance Module also installed, with a need to connect to ISE, the endpoint to download the posture policy, and evaluate. Note that the VPN module is not referring to the same IP as the PSN that will be doing the posture check, as this is a separate ASA from the WLC or PSN altogether.
When the wireless medium is connected, the system scan should automatically trigger based on a need to authenticate and authorize against the SSID through ISE, which will force the posture based authorization.
First Authentication:
Then authorization:
And finally, a compliance posture check based on watermark.txt being present in the directory C:\Temp
The next test to run is to rename watermark.txt to watermark2.txt, and ensure when the endpoint disconnects and reconnects that it will be seen as non-compliant.
Doing so results in the file condition to fail, a need to download the file, and subsequent connection and compliance. This will reflect in the Radius Live Logs as an unknown posture, with non-compliance only coming from a user choosing not to remediate the finding in the time allowed. The time for this test was reverted back to 4 minutes to illustration purposes with a 20 minute grace period. This grace period can be entered into by hitting “Cancel” or just waiting out the 4 minute remediation timer. The 20 minute grace period then needed to be waited out for non-compliance:
With the policy in place, the failure message to remediate will look something like the following after the 20 minute grace period expires:
Testing without the Posture Module
After uninstalling the posture module from the endpoint through the control panel, attempting to join the wireless network without it, results in redirect and a notification to the user that they require additional security software to be installed before gaining access to the network.
Clicking Start will install the posture module, starting with a countdown to determine whether the endpoint has AnyConnect already installed at all.
This will then prompt the user to determine whether they have visited this page before, or whether there are next steps that need to occur.
This will download the network setup assistant and download the required software. This network setup assistant is hosted on the ISE server and downloaded to the client so that the client does not need internet access.
With a non-compliant device, this will install the posture module and prompt the user to remediate any non-compliance of the endpoint.
The same result occurs when AnyConnect is not installed:
In this test scenario, a restart of the machine was required. Upon restart, the same evaluation occurs and access is provided according to compliance as per above.