View Cart
0 Items | Total: US$0.00
Welcome,      Register

You are here

SEC0096 - ACS 5.4 AnyConnect VPN RADIUS Authentication and Authorization

Average: 4.8 (4 votes)
Difficulty Level: 
Lab Document: 
<Please login to see the content>
The video walks you through configuration of VPN RADIUS authentication on Cisco ACS 5.4 with AnyConnect Client SSL VPN. We will try to solve the problem of users having to select a VPN group at login by dynamically assigning them to a group-policy via Class RADIUS attribute. We will also attempt to enforce per-user ACL via the Downloadable ACL on the ACS.
Cisco AnyConnect Client SSL VPN
  • Network Device RADIUS
  • Device Filter
  • Policy Element
    • Authorization Profile
    • Downloadable ACL
    • RADIUS Class Attribute
  • Service Selection Rule
  • Access Services
    • Authentication Policy
    • Authorization Policy
    • RADIUS Attributes
  • ASA RADIUS Server and Default Tunnel Group

About Author

Metha Cheiwanichakorn, CCIE#23585 (RS, Sec, SP), is a Cisco networking enthusiast with years of experience in the industry. He is currently working as a consulting engineer for a Cisco partner. As a founder of and an instructor at, Metha enjoys learning and challenges himself with new Cisco technologies.


the first question:

In your presentation admin1 user is connecting tunnel group DefaultWEBVPNGroup, but how to bind a user to a different group? RADIUS Attribute CVPN3000/ASA/PIX7.x-Tunnel-Group-Lock, I have added to my profile login does not work. Attribute in Group Policy is also not helping. effects of group locking - Login deny thanks in advance (ps sorry for my bad english)

your answer:
Hi ti_key,

Group lock is not used for that purpose. You need the ACS to return attrbute 'class' with OU= as explained in this video.
Please kindly post further question under relevant videos so other users can also benefit from it.

the second question:

yes my ACS to return attrbute 'class' with OU= , but asa using default tunnel group
attrbute 'class' this is Group policy
in another way?

You can't select a tunnel-group from RADIUS. But you can assign the right group-policy for your user with the class-attribute. For that you need to have different group-policies configured on your ASA. Alternatively instead of assigning the group-policy you can assign the individual parameters like IP, VPN-filter and so on.

Yes, Tunnel cannot be assigned by RADIUS attribute but Group-Policy can by Class OU=. Tunnel group the user is dropped into is determined by 1. Drop down on default Web login. or 2. Group-URL. However, if you already used Class OU= to switch user to proper Group-Policy, there usually isn't a need for multiple tunnel groups and you can just use the DefaultWeb tunnel group.


I liked this video very much, thank you for sharing it sir.

One more question, please.

Is this solution somehow possible without ACS, just only ASA and AD/LDAP

I want that my users from different AD/LDAP OU could connect and obtain ip from different pools dedicated to each other.

Please give advice.

Kindly Tural

ASA can integrate directly to LDAP/AD and you can use attribute-map to map LDAP user group to VPN group-policy.  Here is the link.
For native AD integration, you need to go through ACS.

I have already integrated, ASA with AD/LDAP with attributes, which is working,

The problem is that If I do not create any tunnel group and group policy (just only Default Tunnel and Default Group policy), the my users connects and obtains from the same ip pool. Perspective I can not do any acl against my users if they are from different OU groups

Or I can enable group-alias, and create different tunnel groups/group-policies, in this case, my users select which groups they want to connect. But I do not want that users see the name groups and be able to other user groups.

Is it somehow possible to let my users to their own OU groups automatically ?

Kindly Tural

You can use the default Tunnel-group where all of your vpn users will land and then use LDAP attribute to group-policy mapping config on the ASA to place each user to the corresponding group-policy based on their AD group membership. Also define VPN address pool at the group-policy level and not the tunnel group level.


Can you explain the difference between defining the address pool at the group-policy level versus the tunnel group level?

To clarify - I mean if it's just a single group-policy with a single tunnel-group. Does it matter where it's defined?

Thank you

If all you have is a simple one tunnel-group to one group-policy, then it does not matter where the ip pool is defined. Defining IP pool to group-policy comes in handy when you have multiple group-policy sharing the same tunnel-group (ie. when assigning user to group via RADIUS class attribute) and you want different groups to use different IP.

Thank you


Can we use Tacacs insted of Radius ?


You could but not sure what would the reason be. RADIUS is more widely used protocol with many supported attributes.