How To Configure Posture with AnyConnect Compliance Module and ISE 2.0

 

 

Introduction

This document describes how to configure the Cisco Adaptive Security Appliance (ASA) Version 9.2 and above in order to posture VPN users against the Cisco Identity Services Engine (ISE) utilizing a natively installed AnyConnect client and Compliance Module.


Requirements

Cisco recommends that you have knowledge of these topics:

  • Basic knowledge of ASA CLI configuration and Secure Socket Layer (SSL) VPN configuration
  • Basic knowledge of remote access VPN configuration on the ASA
  • Basic knowledge of ISE and posture services
  • Basic knowledge of AnyConnect

 

Components Used

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

  • Cisco ASA software Versions 9.2.1 and later
  • Microsoft Windows Version 7 with Cisco AnyConnect Secure Mobility Client Version 4.2
  • Cisco ISE Version 2.0

 

Background Information

Starting with Cisco ASA Version 9.2.1, support for RADIUS Change of Authorization (CoA) (RFC 5176) was added. This allows for posturing of VPN users against the Cisco ISE without the need for an IPN, and can be natively done with the Cisco AnyConnect Secure Mobility Client with AnyConnect Compliance Module. After a VPN user logs in, the ASA redirects web traffic to the ISE, where the user is provisioned with AnyConnect and its Compliance Module. AnyConnect then performs specific checks on the user machine in order to determine its compliance against a configured set of posture rules, such as Operating System (OS), patches, AntiVirus, Service, Application, or Registry rules.

 

The results of the posture validation are then sent to the ISE. If the machine is deemed complaint, then the ISE can send a RADIUS CoA to the ASA with the new set of authorization policies. After successful posture validation and CoA, the user is allowed access to the internal resources.

 


Network Diagram and Traffic Flow

 

Network Diagram.png

 

 

 

Here is the traffic flow, as illustrated in the network diagram:

  1. The remote user uses Cisco AnyConnect for VPN access to the ASA.The ASA sends a RADIUS Access-Request for that user to the ISE.
  2. That request hits the default policy set with a policy named ASA_POSTURE on the ISE. As a result, the ASA_POSTURE authorization profile is returned. The ISE sends a RADIUS Access-Accept with two Cisco Attribute-Value pairs:

 

  Tip: The Domain Name System (DNS) servers that are assigned to the VPN clients must be able to resolve the Fully Qualified Domain Name (FQDN) that is returned in the redirect URL, if the FQDN is used. If the VPN filters are configured in order to restrict access at the tunnel-group level, ensure that the client pool is able to access the ISE server on the configured port (TCP 8443 in this example).

 

  1. The ASA sends a RADIUS Accounting-Request start packet and receives a response. This is needed in order to send all of the details in regards to the session to the ISE. These details include the session_id, external IP address of the VPN client, and the IP address of the ASA. The ISE uses the session_id in order to identify that session. The ASA also sends periodic interim account information, where the most important attribute is the Framed-IP-Address with the IP that is assigned to the client by the ASA (192.168.123.33 in this example).
  2. When the traffic from the VPN user matches the locally-defined ACL (redirect), it is redirected to https://192.168.123.62:8443. Dependent upon the configuration, the ISE provisions the AnyConnect Posture Compliance Module.
  3. After the agent is installed on the client machine, it automatically performs specific checks. In this example, it searches for the c:\watermark.txt file. It also sends a posture report to the ISE, which can include multiple exchanges with the use of SWISS protocol and ports TCP/UDP 8905 in order to access the ISE.
  4. When the ISE receives the posture report from the agent, it processes the authorization rules once again. This time, the posture result is known and another rule is hit. It sends a RADIUS CoA packet:
    • If the user is compliant, then a Downloadable ACL (DACL) name that permits full access is sent (AuthZ rule ASA_COMPLIANT).
    • If the user is non-compliant, then a DACL name that permits limited access is sent (AuthZ rule ASA_NONCOMPLIANT).

 

  Note: The RADIUS CoA is always confirmed; that is, the ASA sends a response to the ISE in order to confirm.

 

  1. The ASA removes the redirection. If it does not have the DACLs cached, it must send an Access-Request in order to download them from the ISE. The specific DACL is attached to the VPN session.
  2. The next time that the VPN user tries to access the web page, it can access all of the resources that are permitted by the DACL that is installed on the ASA.
    If the user is not compliant, only limited access is granted.



Note
: This flow model differs from most scenarios that use RADIUS CoA. For wired/wireless 802.1x authentications, RADIUS CoA does not include any attributes. It only triggers the second authentication in which all attributes, such as DACL, are attached. For the ASA VPN posture, there is no second authentication. All of the attributes are returned in the RADIUS CoA. The VPN session is active and it is not possible to change most of the VPN user settings.

 

 

ASA Configuration

The ASA configuration is similar to that of a standard VPN configuration which utilizes AAA to authenticate the user.  The following basic configurations are included in the configuration below:

  • An IP Pool to allocate an address to the user
  • Interface configurations of both the inside and outside interface
  • A definition of the AAA RADIUS server
  • WebVPN configuration for SSL VPN termination
  • Group Policy for the VPN session
  • A tunnel group used for the VPN session

 

More information on basic configuration of remote access VPN is available with the vpnsetup command.

 

ASA Configuration Example

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! A local pool will need to be configured for clients which will be terminated on the ASA, providing them

! an IP address to use in their routing. This is a standard configuration for remote access VPN

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ip local pool ISE_POOL 192.168.123.33-192.168.123.39 mask 255.255.254.0

!

!  Outside interface to face the service provider through which clients will connect

!

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address 10.87.2.244 255.255.254.0

!

! Inside interface, which will also be used to connect to the ISE server, as a radius server.

!

interface GigabitEthernet0/1

nameif inside

security-level 100

ip address 192.168.122.70 255.255.254.0

!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Redirection ACL’s. Redirection ACL’s tell the ASA which traffic to permit to be redirected to the ISE

! server, triggering the posture assessment.  Deny statements should be configured as the first lines,

! specifying the DNS, DHCP, ISE PSN, and ISE PAN servers.  These servers will be denied from the

! redirection, allowing for traffic to hit these servers without triggering posture.  This is desired to

! prevent a loop in logic, such that traffic to the PSN needs to be redirected, but is redirected continually

! rather than reaching the PSN.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! PSN in our example

access-list REDIRECT extended deny ip any host 192.168.123.62

! PAN in our example, not necessarily needed beyond testing

access-list REDIRECT extended deny ip any host 192.168.123.61

! DNS Server in our example

access-list REDIRECT extended deny ip any host 192.168.123.8

! Permit all other traffic to be redirected, triggering posture check

access-list REDIRECT extended permit ip any any

!

! Default route to our service provider for all traffic

route outside 0.0.0.0 0.0.0.0 10.87.2.1 1

!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Configure the RADIUS AAA server.  Options include interim accounting updates being sent every 3

! hours, and dynamic authorization to allow for a COA to be sent to the VPN client.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

aaa-server ISE protocol radius

interim-accounting-update periodic 3

merge-dacl before-avpair

dynamic-authorization

!

! Definition of the RADIUS AAA Server and it’s interface based location

!

aaa-server ISE (inside) host 192.168.123.62

key cisco123!

!

! Definition of the HTTP server to allow for ASDM access to the device is required.

!

http server enable

http 10.87.2.0 255.255.254.0 outside

http 192.168.122.0 255.255.254.0 inside

!

! Enable the SSL VPN to connect via webvpn

!

webvpn

enable outside

anyconnect image disk0:/anyconnect-win-4.2.05015-k9.pkg 1

anyconnect image disk0:/anyconnect-win-4.1.06020-k9.pkg 2

anyconnect enable

tunnel-group-list enable

!

! Configure the group policy with allowed connection means and DNS servers.  The DNS servers defined

! in this section are important to ensure that we can reach the PSN when doing the redirection, as

! configured in the AnyConnect Configuration in ISE.

!

group-policy ISE_VPN internal

group-policy ISE_VPN attributes

dns-server value 192.168.123.8 10.87.3.78

vpn-tunnel-protocol ssl-client

!

! This username will do NOTHING in regards to posture.  Remember that our authentication and

! authorization will be done through ISE as configured.  The command “authorize-only” can be used in

! the aaa-server configuration if authentication should be done through a separate means.  This

! username was purposely added for illustration and device administration.

!

username cisco password 3USUcOPFUiMCO4Jk encrypted

!

! Tunnel group definition for remote access

!

tunnel-group ISE_AAA type remote-access

tunnel-group ISE_AAA general-attributes

! Refer to the local pool created above

address-pool ISE_POOL

! Set authentication and authorization to the ISE Server defined above

authentication-server-group ISE

! Set the accounting server to ISE for start-stop information

accounting-server-group ISE

! Refer to the group policy created above

default-group-policy ISE_VPN

!

! If the group URL isn’t set in the webvpn attributes below, you may see an error in authentication

! where authentication never hits the ISE server, as it is using a default authentication method.

!

tunnel-group ISE_AAA webvpn-attributes

group-alias ISE_AAA enable

group-url https://10.87.2.244 enable

!

 

 

ISE Configuration

The ISE configuration consists of multiple parts.

 

The Dynamic Access Control Lists

These lists will be applied to traffic as it originally terminates on the ASA and the ASA reaches out via RADIUS to be authenticated and authorized.  At least two Access lists will need to be created for this task:

    • A compliant access control list: This access control list allows for access to whatever resources the endpoint should be allowed access to in the case that it is given its full amount of access to the network.  Typically this access control list with be “permit ip any any”, however can change depending on the needs of the endpoints once authorized.

 

9-27-2016 1-46-21 PM.png

 

 

A noncompliant access control list

This access control list allows for access to whatever resources the endpoint should be allowed when not authorized to the network.  This is typically access to a remediation server which hosts resources for the endpoint to become compliant.  In addition, DNS, DHCP, and the PSN are all recommended to be allowed to ensure that resolution for the remediation can occur.  Typically, this access control list looks like the following:

! Policy Services Node

deny ip any host 192.168.123.62

! DNS Server

deny ip any host 192.168.123.8

! Internal network

deny ip any 192.168.122.0 0.0.1.255

! Permit access to only a DMZ based remediation server

permit ip 10.87.3.10



9-27-2016 1-47-35 PM.png

 

 

A redirection DACL is NOT needed on the ISE deployment or as part of the ISE configuration within the dynamic access control lists area.  The redirection ACL is configured on the ASA and pushed down to the ASA via RADIUS to apply to the endpoint session, allowing for access to the PSN, DNS, Remediation Server, and similar resources.

 

9-27-2016 1-48-45 PM.png

9-27-2016 1-49-33 PM.png

 

 

The Authorization Profiles

Authorization profiles will be used to dynamically change the access the endpoint has based on its posture status, which will be configured in the Authorization Policies step below.  Three authorization profiles will need to be created for each scenario of posture configuration:

 

The Unknown Posture Profile

The unknown posture profile is the default posture profile that every endpoint will hit when they first connect into the ASA for VPN termination. This is because ISE has not yet evaluated the posture of the endpoint, and still needs to connect to the compliance module to determine the state of the device, utilizing the checks which will be configured in later steps.  Therefore, the unknown compliance profile sets the redirection ACL which is pushed to the ASA via RADIUS, and redirects the session to the Client Provisioning Portal. While this may seem counter-intuitive, if the posture is unknown and ISE is unable to determine what the posture of the endpoint is, this typically means that the Compliance module is not installed, or hasn’t responded to the call for a compliance check.  If the compliance module is not installed on the endpoint, by redirecting the client to the client provisioning portal, it will be given the opportunity to download the compliance module and update the AnyConnect package currently installed to accommodate this request.  If the compliance module is installed, this redirect will typically kick off the compliance check against the endpoint.

 

9-27-2016 1-52-44 PM.png

 

 

The Compliant Posture Profile

In the vast majority of cases, the compliant posture profile will be hit at some point within the posture evaluation, giving the endpoint full access as configured in the compliant access control list above.  This is hit after the compliance check has completed, and the requirements configured for the endpoint have been met.  This will typically take the form of the compliance module checking for compliance, once it is installed during the Unknown Posture Profile Phase.  In this example, this profile will push a permit ip any any access list for the endpoint.

 

 

9-27-2016 2-16-37 PM.png

9-30-2016 10-48-16 AM.png

9-27-2016 1-50-43 PM.png

 

 

The Non-Compliant Posture Profile

The non-compliant posture profile is used for a client which is not compliant to the requirements which have been configured within Cisco ISE.  The behavior of ISE in this manner is slightly counter intuitive to some system administrators, as during the countdown which is provided to remediate the non-compliant workstation, the endpoint remains in a redirection or unknown compliance state.  Only after the countdown expires and an endpoint is not in compliance with the policy configured within ISE, will the session be put into a non-compliant state.

 

 

9-27-2016 2-24-52 PM.png

9-27-2016 2-19-36 PM.png

9-27-2016 1-47-35 PM.png

 

 

The Posture Requirements

Posture requirements are conditions configured by the ISE administrator to determine what a “compliant” endpoint is.  These conditions take many forms, and for each form will have a different configuration syntax which will need to be populated.  The conditions available within ISE 2.0 include the following:

    • File Condition
    • Registry Condition
    • Application Condition
    • Service Condition
    • Compound Condition
    • AV Compound Condition
    • AS Compound Condition
    • Dictionary Simple Condition
    • Dictionary Compound Condition
    • Patch Management Condition
    • Disk Encryption Condition.

 

For more information on supported conditions for the type of endpoint and client, refer to the following link:

http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/admin_guide/b_ise_admin_guide_20/b_ise_admin_guide_20_chapter_010110.html#ID443

 

  • For this example, I’ll being a file condition to simply demonstrate the ability to look on the endpoint’s hard drive for a file which exists in a certain area.

 

9-27-2016 2-35-11 PM.png

 

 

 

The Remediation Action

The remediation allows for an automated or manual remediation of the non-compliant condition which the endpoint is currently under.

  • For remediation of files, this can be done by automatically uploading a file to the endpoint’s hard drive, to exist in the designated by the requirement, defined in the previous step.
  • For remediation actions such as AS and AV remediation, automatic remediation can be triggered by citing the AV or AS vendor from within ISE’s built in vendor list, update regularly through the Posture Feed Profile.  This feed profile can be found in the Administration > System > Posture > Updates area.  Automatic check and immediate updating can be done to populate these lists when need be.

 

 

9-27-2016 2-41-03 PM.png

9-27-2016 2-43-38 PM.png

 

 

 

For remediation actions such as Windows Update Remediations, Windows Update settings can even be changed in case the end user has disabled windows update on their endpoint.

 

9-27-2016 2-45-47 PM.png

 

 

 

The Client Provisioning Resources

The client provisioning resources work in conjunction with the authorization profile which redirects users with an unknown posture status to the client provisioning portal to download a profile and configuration for ISE and its compliance module.  Four resources make up the client provisioning resources, which is found in Policy -> Policy Elements -> Results -> Client Provisioning -> Resources.

  • The AnyConnect Package: An operating system specific package which is uploaded to ISE through the “Add Agent Resources from Local Disk” context menu.  For Windows systems this is the head end deployment PKG file directly off of CCO.
  • The ISE Posture Configuration File: This configuration file dictates the compliance settings to be used when the compliance module is started on the end user’s machine.  This dictates configurations such as the length of time the user has to remediate a non-compliant machine, enables additional debug logs for compliance, and specifies the PSN to which the compliance module should reach out to.  The “server name rules” field can be used to specify the domain which the compliance server should exist on, if the end machine will be connecting to multiple domains with overlapping IP addresses.

 

9-28-2016 9-22-29 AM.png

9-28-2016 9-25-05 AM.png

 

 

AnyConnect Configuration File

This configuration file determines the packages which should be installed on the user’s endpoint to do compliance or Log Collection, in the case of the DART bundle.  Typically, VPN, Compliance, and DART are the main pieces which are required on the user’s endpoint.

 

 

9-28-2016 9-15-56 AM.png

 

In addition, the Compliance Configuration Profile within the ISE Posture drop down, AnyConnect update deferment, and whether the user should have their NAC client uninstalled are all referred to and configured in this area.

 

 

9-28-2016 9-18-01 AM.png

 

 

The Compliance Module Package

The AnyConnect Compliance Module file is the file which will be pushed down to the installed AnyConnect package to check compliance. This is pushed down to the Headend AnyConnect Deployment package which was added in the previous steps from CCO. However, this file is downloaded through the “Add Resources from Cisco Site”.  Note that multiple versions of this file may exist, and the correct module should be added for the installed version of AnyConnect, otherwise a “Failed to download compliance package” error message may be observed.  Where need be, this file can also be downloaded from the AnyConnect 4.x -> ISEComplianceModule area of CCO as well.

 

 

9-28-2016 9-33-39 AM.png

9-28-2016 9-49-24 AM.png

 

 

The Supplicant Provisioning Wizard

The Supplicant Provisioning Wizard is downloaded based on the operating systems which will be doing posture on the end user network.  This Wizard is an agent which will deploy the AnyConnect and Compliance modules through a small download when a user in an unknown posture state due to not having AnyConnect is detected.  This is triggered when the endpoint opens a web browser on an unknown compliance workstation to try to access the network, and is greeted by a client provisioning portal. This portal is hosted on the PSN, and is typically one of the few resources an unknown compliance workstation has access to, as per the DACL’s configured in the Authorization Profile configured previously.

 

 

 

9-28-2016 10-09-12 AM.png

 

 

Posture Configuration

Utilizing the requirements configured in previous steps, the posture policy is now configured to determine what a client requires to be in compliance with the ISE policy for posture.  This configuration refers back to the requirement configured in Conditions, as well as the operating system and identity group, if applicable.

 

 

9-28-2016 9-52-29 AM.png

 

 

Authorization Policy

Once the endpoint has been evaluated utilizing the requirements, had the AnyConnect and Compliance modules installed via the resources, and had the modules configured with their respective profiles, the authorization profile is finally hit now that a result has been reported back to ISE.  The Authorization policy will assign the proper results to compliant and non-compliant endpoints, as configured in the Authorization Profiles and DACLs configured in previous steps, or redirect the endpoint through a Redirection URL to the client provisioning portal for download of AnyConnect, the Compliance Module, and proper configuration files.  Each of these authorization policies will refer to the session posture status as a condition, equaling compliant, non-compliant, or unknown.

 

 

9-28-2016 10-02-29 AM.png

 

 

Client Provisioning Policy

Once the AnyConnect configuration and Posture configuration are both configured, for the times in which the compliance module is not deployed and the endpoint needs to be redirected to the client provisioning portal, a policy needs to be configured referencing what resources need to be pushed down to the endpoint when the user hits the Start button. This start button will deploy the AnyConnect Client if needed, Compliance Module if needed, and Compliance configuration, all configured in previous steps.

 

 

9-28-2016 10-09-12 AM.png

 

 

This policy will be based on the operating system to which the client should be deployed, and will typically utilize the AnyConnect configuration, the Supplicant configuration wizard, and ISE Native Supplicant Provisioning Policy, all of which were either pre-populated, or configured in previous steps.

 

 

9-28-2016 10-04-53 AM.png

 

NSP.png