Mapping Cisco ASA VPN Users to Tunnel Groups via Tunnel-Group-Lock on ACS

Posted in Networking by shaw38 on August 13, 2010

Over the past 9 months since I changed jobs, I’ve had a ton of opportunities to work with the the Cisco ASA. Up until this point, our only clients utilizing the IPSec VPN client have been internal employees authenticated against Active Directory (via ACS) and a handful of vendors with locally created accounts on the ASA. However, a recent security policy change has dictated all users, both employees and vendors, must be authenticated against Active Directory but Radius must be utilized for accounting. No big deal, right? Move the local accounts on the ASA to AD, create new group mappings in ACS and communicate with the vendors. Not so fast. As it turns out, this will all work fine but, under the covers, a security problem has been created. Let’s look at the problem at a high level.

Here’s the configuration:

  • In the ASA, there are two tunnel-groups created: Employee and Vendor. The Employee tunnel-group allows full access to the internal network. The Vendor tunnel-group allows restricted access to the internal network.
  • In Active Directory, there are two groups/OUs created: Employee and Vendor.
  • In Radius, there are two groups created: Employee and Vendor. These are mapped to their respective groups in AD.

The Good

Let’s follow vendor JoeyNT logging into his VPN client, specifying tunnel-group “Vendor”:

Vendor JoeyNT is successfully authenticated! Nice job, Joey. As you can see:

  1. The clients credentials are passed from the ASA to Radius to Active Directory (AD).
  2. When Radius passes the client’s credentials to AD, it will also ask for which groups(OUs) the user belongs via Microsoft Net Logon. These are then passed back to Radius upon successful authentication.
  3. The client is placed into the AD-mapped group in Radius
  4. Radius finally sends an auth success/failure message back to the ASA
  5. In this case, the ASA receives an auth success and permits the client

The one important item to note is tunnel-group membership is not conveyed in any way between Radius and the ASA, by default. Radius simply sends a pass/fail message. This becomes the root of our problem.

The Bad

Now vendor JoeyNT is dissatisfied with his level of access and is feeling a bit ambitious. He has acquired the “Employee” PCF file from a developer within our organization to help with “support issues”. He logs into his VPN client with the Employee tunnel-group specified:

As you can see, JoeyNT is authenticated successfully and is placed into the Employee tunnel-group, allowing full access to the internal network, even though he is part of the Vendor OU in AD and placed in the Vendor group in Radius. Uh oh.

The Solution

What we need is a way for Radius to tell the ASA what tunnel-group the client should be allowed, along with the auth success message.

Enter vendor-specific-attribute (VSA) 3076/85 – Tunnel-Group-Lock.

By enabling this, Radius will send the locally configured tunnel group name to the ASA, based on the AD-to-Radius group mapping. If this does not match the tunnel-group to which the client is attempting to join, the client will be denied access. With Tunnel-Group-Lock used, here is our oh so adventurous vendor JoeyNT attempting to authenticated to the Employee tunnel-group:

The Configuration

In Cisco ACS, this first needs to be enabled under Interface Configuration–>RADIUS (Cisco VPN 3000/ASA/PIX 7.x+):

Then check the box under [026/3076/085] Tunnel-Group-Lock and click submit:

Now under Group Setup, each group will have the following under the Cisco VPN 3000/ASA/PIX v7.x+ RADIUS Attributes section. The value specified here MUST match a configured tunnel-group on the ASA:

That’s it!

Footnote: I believe this can also be done using IETF class attribute 25 but I have not tested this.