Cisco Secure Desktop (CSD) – Part 5 and 6

I’ve decided to merge parts 5 and 6 together since host scan results are used directly with dynamic access policies.  In this post we’ll walk through an example of how to define a basic host scan and use its results to determine access with dynamic access policies.

DAPs (Dynamic Access policies) allow you to evaluate tons of different client settings and apply policy based upon the results.  In regards to CSD, DAPs are evaluated at the time of logon.  As you might recall from part 2 of this series we can ask host scan to look for processes, files, and registry entries during the CSD load process.  The results of those scans are sent to the ASA and then evaluated during the user login process.  A default DAP (DfltAccessPolicy) is defined in the ASA which is enforced if the ASA can’t match the user to another DAP based on other criteria.  Let’s take a look at the DAP screen in the ASDM.

As mentioned above, there is a single DAP defined from the start.  The DAP is enforced if no other DAPs are matched to the client configuration.  Let’s do a quick example of how the default DAP works.

Select the Default DAP and select ‘Edit’ from the right-hand side of the screen.  Editing the default DAP will look slightly different then editing DAPs you create.  This is because you aren’t allowed to change which attributes match the default DAP.  Change the settings of the default DAP to look like the screen below.  Ensure that ‘Terminate’ is selected and enter a meaningful user message.  Then press OK to close the DAP window and then press apply in the ASDM window.

Now let’s try logging into our WebVPN portal to see what happens. 

As you can see we matched the default DAP and received the error message we defined.  Now, let’s define a DAP of our own.   Navigate to CSD – Host Scan in the ASDM.  Under basic host scan select the ‘Add’ button and select ‘File Scan…’ as shown below.
 

In the ‘Add File Scan’ window let’s define a test scan searching for a file that we are sure the DAP will find.  Press ‘OK’ to add the file to basic host scan.  Ensure you press the ‘Apply All’ button at the bottom of the screen as well.

Now let’s go back to the DAP window and define a new DAP.  Press the ‘Add’ button on the right side of the screen.  You should be presented with the ‘Add Dynamic Access Policy’ window as shown below.
 

There are a ton of options we can define but for now let’s just make a DAP that looks for the file we defined in host scan.  To do this, press the ‘Add’ button on the far right of the screen. This should present you with the ‘Add Endpoint Attribute’ window as shown below. 

Endpoint attributes are any settings sent to the ASA about the state of the client.  This includes the files, processes, and registry entries we ask host scan to search for, as well as all of the information it should return by default.  The information it should return by default are items such as anti-virus, anti-spyware, operating system, client firewall, etc…  However as you’ll recall, most of those items don’t return the correct values which means that they won’t work in our DAPs.  That being said, I’m going to stick with evaluating host scan items during this walk through.  I am NOT saying that the other attributes won’t work for you, all I’m saying is that you should test them in your environment before deployment.

So let’s ask the DAP to look for the file we defined in host scan.  Under the ‘Endpoint Attribute Type’ drop down select ‘File’.  Since we only defined one file for host scan to look for it will automatically be selected in the ‘Endpoint ID:’ drop down.  Press ‘OK’ to add the endpoint attribute.

Now we need to tell the ASA what we want to do with clients who match this DAP.  Let’s set this DAP to ‘Terminate’ as well and set the message to something meaningful as I have done below.  Press ’OK’ and then ensure you apply the configuration.

Now, let’s try logging into our WebVPN portal again.  We now get the screen shown below.

A click on the ‘More Info’ link shows us the message we defined in the DAP.

Now, let’s go back into the ASDM and change the DAP from terminate to continue and update the message to reflect this change.  Now, try logging in again.  You should be able to login to the portal and should see something similar to what is shown below. The yellow exclamation box next to the address bar will be flashing.  If you click on the exclamation box you’ll see the message you specified in the DAP. 

I’m not going to go through all of the different policies you can apply to a users sessions with DAPs, they are far too numerous.  Play around with the different settings you can apply within the DAP and see if there are any that you can use.  I’ve found that checking for files, processes, and registry entries can halfway-substitute checking for things like anti-virus or anti-spyware.  In the next post we’ll talk about using advanced expressions within the DAPs to automatically check for anti-virus and anti-spyware.

I’m going to wrap up my overview of DAPs by talking about their configuration and where it is stored. DAPs are something that are best created, modified, and edited through the ASDM.  However there is some code that still appears in the config.  For instance, after I completed this configuration I had the following code in my config file.

dynamic-access-policy-record Test
user-message "Test DAP, Access allowed"
dynamic-access-policy-record DfltAccessPolicy
user-message "This is the default policy, no access allowed."
action terminate

As you can see, the default action would be to continue so its not defined underneath our test DAP.  The rest of the DAP information is stored in a XML file similar to the pre-login policy definitions.  The XML file is called ‘dap.xml’ and it’s located in the root of Disk:0.  A quick look at the XML shows the following.

Our look at DAPs today has been brief but I’m hoping that, by showing you the initial configuration, you’ll play around with the different DAP settings and see what else you can do with them.