NoSwitchport.com

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.

Advertisements

7 Responses

Subscribe to comments with RSS.

  1. bashMG said, on December 10, 2010 at 3:24 am

    Very cute explanation!

  2. shendy said, on January 17, 2011 at 11:54 pm

    Nice articel, but anyone knows how to do it in ACS 5.1?
    thanks in advance

  3. Mark said, on January 21, 2011 at 1:49 pm

    It needs more testing, but I posted how I did it in the Cisco Support forum. ACS 5.x is much different than 4.x.

    https://supportforums.cisco.com/message/3274128#3274128

  4. Craig said, on January 18, 2012 at 7:21 am

    Hi All

    Anyone know if the Group-lock is available without a Radius server, so just applying to the ASA and using local auth.

    • Johan said, on January 19, 2012 at 10:51 am

      Hi Craig,

      It is possible, on an existing users do.

      asa(config)#username “user” attributes
      asa(config-username)# group-lock value “tunnel-group”

      /Johan

      • Craig said, on January 19, 2012 at 5:22 pm

        Hi Johan

        Thanks for the response, I take this is good for all VPN’s as the Group lock is on the User’s. I am trying to lock SSL VPN’s user’s to there groups.

        Regards

  5. Johan said, on January 19, 2012 at 6:10 pm

    Craig, I think so, but I have not used it with the older Cisco VPN IPSEC client, only while testing with the Cisco Anyconnect (SSL) VPN client. In production I use the radius attribute from a radius server and not local users.

    There is a bunch of settings you can configure for only the user, just do a question mark after the attributes command. For example “service-type remote-access” that will force the user only to have access to remote access services. If not properly configured they could have full ASDM and also SSH access.

    /Johan


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: