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.
Note: Many of the configurations here pertain to a wired deployment of posture with the exception of a need for ip http server being enabled. Active session modules none is always recommended in this case.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software versions:
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.
Here is the traffic flow, as illustrated in the network diagram:
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).
Note: The RADIUS CoA is always confirmed; that is, the ASA sends a response to the ISE in order to confirm.
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.
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:
More information on basic configuration of remote access VPN is available with the vpnsetup command.
! 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
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.
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
! Definition of the RADIUS AAA Server and it’s interface based location
aaa-server ISE (inside) host 192.168.123.62
! 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
anyconnect image disk0:/anyconnect-win-4.2.05015-k9.pkg 1
anyconnect image disk0:/anyconnect-win-4.1.06020-k9.pkg 2
! 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
! 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
! Set authentication and authorization to the ISE Server defined above
! Set the accounting server to ISE for start-stop information
! Refer to the group policy created above
! 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
The ISE configuration consists of multiple parts.
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:
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
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.
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 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.
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.
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.
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:
For more information on supported conditions for the type of endpoint and client, refer to the following link:
The remediation allows for an automated or manual remediation of the non-compliant condition which the endpoint is currently under.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.