ISE Lab: ASA AnyConnect 2 – ISE Posture

The ISE posture scanning will work on wired, wireless and VPNs. There are multiple steps to getting the posture policy configured. This post will go through each step.

Client Provisioning Policy

This part has three main components
– Upload AnyConnect VPN and ISE Compliance Module
– Create Posture Profile
– Create AnyConnect Configuration

The files that need to be uploaded are the webdeploy VPN package and the ISE compliance module package. These are difficult to get if ISE isn’t licensed. So with just the ISE trial you can’t do this. You will need to download them from the Cisco site under a valid service contract. I tried finding the ISE compliance module on the internet. I couldn’t find it anywhere. Luckily, I had one from a previous company.
anyconnect-win-4.7.04056-webdeploy-k9.pkg
anyconnect-win-4.3.599.6144-isecompliance-webdeploy-k9.pkg

Now the files have been uploaded next is to create the posture profile

Now to create the AnyConnect configuration which will tie these things together.

The last part is to create the Client Provisioning Policy that references the AnyConnect configuration.

Posture Policy

This is where ISE can scan a client machine to determine if it is permitted onto the network. We can determine if it is a corporate machine, or does it have the latest Windows updates, a firewall/antivirus enabled and many other options.

To enable this there are several steps that must be configured. The most important step is to determine what the posture is looking for.
I am going to just perform a file scan to determine if the machine is a corporate or 3rd party machine. This will be in the form of a txt file name. Either “CORP” or “3rdPARTY”.

Now that I have my very basic file conditions created, the requirement can be set.

Until now, the file condition has been created and a posture requirement set. Still, this is not enough for ISE to run the posture scan against a connecting client. To enforce the posture, a posture policy must be created.

VPN Policy Set

The policy set is what will start to combine all these elements together. Inside the policy set, the compliance state is checked and a redirect to the Client Provisioning Portal is performed to enforce the posture state.

As always with ISE there are more building blocks that are required before the configuration of the policy set can take place.
– Create Authorisation policiy for Client Provisioning Portal Redirect
– Create VPN user groups for non compliant and compliant

Creating an authorisation policy for Client Provisioning Portal Redirect is referencing the ACL that is on the network access device. In this case it is a firewall, but it can be a switch.

The next step is to create three authorisation policies; compliant, non compliant and unknown posture status.
Compliant – I have chosen for a basic permit IP any any ACL to be applied along with the required VPN group policy for the admin users.
Non compliant – I have defined an ACL which is to deny all traffic, and the correct group policy for the user. This ACL will the downloaded by the ASA and applied to the user that is non compliant.
If the user is not compliant then they will have 4 minutes to fix the problem before their status changes to non compliant and in my example a deny any any ACL applied.
Unknown – This gets an ACL to allow traffic similar to the POSTURE-REDIRECT ACL

Now that those elements have been created, the policy set can be created. I will reuse the one that was created in the earlier part about policy sets.
This policy set has three entries that relate to the posture. In the screenshot below, there are several things going on.
– RADIUS request comes from the ASA
– Compliance status for each type; compliant, non compliant and unknown
– The different authorisation profile results based on the status

Testing – Local User

Now that all the configuration has been applied to ISE the config can be tested. These sets of tests are from the CORP_PC. This is inside the network and is using the DNS server of AD1. Which means that it knows all about securitydemo.lab and the A record for ise1.securitdemo.lab. This is important for a PC off the network being able to find the policy server.

The PC is missing the CORP.txt file from the c:\ drive. The message that was added in an earlier step has been shown, and there is a timer running down. The current posture is unknown. Once the timer runs out, the client will be non compliant.

The details in the ASA show the posture redirect and the dACL that has been passed to the ASA.

If the machine is left, it becomes non compliant and will have an updated dACL that denies all traffic.

When the CORP.txt file is added to compliance check passes

Testing – Remote User

Testing from a location that does not have the DNS server set to the AD1. This causes problems as the AnyConnect client needs to find the policy server from DNS queries, it then needs the appropriate permissions to connect to the ISE server through the firewall rules in place.
This investigation will find out why the CORP_PC1 that is outside the corporate network cannot access the ISE server for posture.

In the background with a Wireshark capture, the client is looking for DNS records to the public DNS.
ise1.securitydemo.lab, cpp.securitydemo.lab and wpad.securitydemo.lab can all be seen. This is expected behaviour and this should ideally be sent to the AD1 server and not to public DNS.
I have seen companies use public DNS for cpp.exampleorganisation.com and permit clients to talk to ISE through a NAT to a public IP.
I can use hosts file to mimic this type of behaviour, there just won’t be a DNS query in Wireshark.

After further investigation I have discovered that if the client is able to download and update the AnyConnect posture module before connecting to the VPN the connection works as expected. There seems to be a problem initiating the download for the posture module update. I can’t see that this is on any different ports. When the download is attempting, there is plenty of traffic between the ISE server and the AnyConnect client.

A client that can connect has previously connected to the ISE posture policy server, and is then able to connect and run a successful scan over the VPN. The check for ISE module updates is run, and the next steps are performed as expected.

There are no differences between the versions.

As the versions look to be correct on the client that can connect via the ASA and the one that cannot. I removed the ISE compliance module from the both clients, forcing AnyConnect to download the compliance module.
On the client that previously connected to the VPN and could reach the policy server successfully, it had no problem downloading the compliance module. The client that hadn’t ever connected got stuck in the update and failed to reach the policy server for compliance checks.

The solution to this is a work around and one that is not unreasonable. When the machine is built, it needs to connect to the local network to reach the policy server before it can use the VPN. This is already done in an organisation for joining AD and downloading software. Whether this would cause update problems for ISE in the future for clients that away from the LAN would be something to be aware of.
For a lab environment to look at posture, this isn’t a concern for me.