Re: Cisco ASA automatically select tunnel-group / Need Separate AAA-Server Groups

jasonrpell20 · ‎03-01-2019

So I support an environment that has thousands of remote VPN users. They currently do not select anything on their AnyConnect client although they can select the Group dropdown box, but there's only one Group right now -- they just click Connect and then use their username and RSA pin to get in. This RSA is slowly going to migrate over to another option -- let's say Azure for example. I know the authentication server is chosen under the tunnel-group and we only have 1 group right now, but then we have LOTs of group-policies that are assigned to different IP Pools, so that based on your AD Group passed from RADIUS, you'll get an IP from a pool that has access to different needs on the network.

What I want is to have both AAA Server options be used at the same time but not cause any user intervention where they have to choose the right Group in AnyConnect. Is there a way to accomplish this, by the ASA choosing the correct AAA-Server based on some attribute of the user trying to connect? I know before authentication happens, there's very little information the ASA would have on the user. Are there any options to make this happen with no change in user intervention?

I've been reading on LDAP Attribute Maps and the Group-Lock option but haven't found a good example of anyone else doing this. Most examples are on the authorization side and automatically selecting the right Group Policy on the ASA. We're already doing that part, but I need this to start at the Authentication side. I need to keep user intervention the same so it's all transparent to them. I'm wondering if I'm going down the path of DAP and/or ISE. Thoughts?

Here are some pertinent configs of our existing setup:

tunnel-group connSSLVPN general-attributes
authentication-server-group RSA
accounting-server-group RSA
default-group-policy GENERAL_SSLVPN_GP
tunnel-group connSSLVPN webvpn-attributes
authentication aaa certificate
group-alias SSLVPN enable
!
aaa-server RSA (Inside) host 10.1.1.1
key *****
aaa-server RSA (Inside) host 10.1.1.2
key *****
aaa-server RSA (Inside) host 10.1.1.3
key *****
!
webvpn
enable Outside
enable Inside
anyconnect-essentials
anyconnect profiles GenSSLVPNProfile disk0:/GenSSLVPN7.xml
anyconnect enable
tunnel-group-list enable
cache
disable

!

Then there are LOTs of group-policies for ip pools. Here's one example:

ip local pool TEST1_IPPool 10.10.10.33-10.10.10.46 mask 255.255.255.240
!
group-policy TEST1_GP internal
group-policy TEST1_GP attributes
vpn-tunnel-protocol ikev1 ssl-client
address-pools value TEST1_IPPool

I've tried creating a 2nd tunnel-group and of course selecting that in the Group dropdown works fine, however if I disable the dropdown, there's nothing to tell AnyConnect which Group to choose. How can I do this automatically or can I? Thanks!

Rob Ingram · ‎03-01-2019

Hi,

If you authenticate via RADIUS you configure 1 tunnel-group that all users connect to, the user is authorize and dependant on AD group membership you can return a tunnel-group for that user. This document would confirm the attribute to use is PIX7x-Tunnel-Group-Name.

HTH

jasonrpell20 · ‎03-04-2019

Interesting. So we use ACS, eventually moving to ISE. So how would this work? By default today, when a user authenticates, it's against RSA. That means everyone would have to have an RSA method before it could even receive this tunnel-group information. Does that make sense? I'm not sure if this would work as most of these users will either not have an RSA or it will be shut off when they migrate. Do you see a work around here?

jasonrpell20 · ‎03-04-2019

I think I should clarify my last post -- ASA points to ACS for aaa-server, ACS can then talk to RSA and either gets the AD Group info from there or directly from AD, then passes this back to ACS. I just don't see how this could work if some users don't have RSA access and also if some users don't have the new access, like Azure.

Rahul Govindan · ‎03-01-2019

I don't there is an automatic way to do this with the AAA based authentication setup that you have. There is a certificate to tunnel-group mapping function on the ASA that let's the user fall into the right tunnel group based on the SSL client certificate they provide. But since you are using AAA only, this wont help you.

Now another way to have users fall into different tunnel-group is to create different group-urls for each tunnel-group and have users fall directly into that group. For example:

User1 connects to https://vpn.domain.com/group1 for Group1

User2 connects to https://vpn.domain.com/group2 for Group2

How you get users to go to the correct group-url automatically would require you to modify their AnyConnect client profile to reflect the group-url in the "Server Address" field ( they can manually type the above URL also). If you have a mutually exclusive group of users, then this easy to do - each group gets just one profile which has their respective Group-url set. It looks like you are in a transition period where eventually people could be moved from one group to another. This could get tricky if they end up with multiple profiles on their machine, which results in multiple connection entries on their client.

Can't think of any other way to force connection profile selection without user intervention. Hope this helps.

jasonrpell20 · ‎03-04-2019

Appreciate the idea here. Unfortunately everything here would involve a lot of changes and like you said, could get hard since we'll be migrating slowly by AD Group I'm assuming. I don't want to give Group URLs to people as the majority are non-technical and we're making this change to thousands of users. Trying to keep it as simple and non-impactful as possible.

Rahul Govindan · ‎03-04-2019

Yeah, it is a little bit of challenge to get all the steps correct. I can't think of any other way where you can automatically have users fall into the right tunnel group. You can block them from accessing a different tunnel-group using the group-lock feature. But this does not automatically force them into the right tunnel-group. An alternate way may be to block and message users to choose the right tunnel-group.