Anyconnect VPN-Authentication multiple profiles via ACS

[amir.glibic]

Hi,

I'm currently facing the issue, that I need to migrate a customer VPN-structure from VPN-client to the new Anyconnect.

There is an ASA5515 and they have ACS with local users and AD-Integration.

The problem: The old system used different profiles with PSK, so every external partner who had a VPN connection got it's own profile, which was secured by the IKEv1 PSK. The credentials for externals are saved locally on ACS. Also there is a profile for the normal employees, which authenticate via AD or RSA. The guys who implemented this did it the easy way, means when a user connects, the whole user-table is checked (AD, local, RSA). So if an external would have the .pcf from an internal user, it would be possible for him to connect to internal resources. There was no profile-to-usergroup binding.

I should now implement a new ASA with Anyconnect and also keep up the different profiles. But in this case the problem is - there is no PSK any more. So if a smart guy changes the group in his XML-profile to e.g. "Internal", it would authenticate and grant access to all resources, since the internal pool isn't restricted by ACL's, but the externals are. 

I'm looking for a guide, how to set up different policies on the ACS, which look up the user only in the one group, depending on the profile he connected. As far as I understand, I must somehow define already on the FW which group or policy it should look up. How can I achieve this? 
 

What do I need e.g. for 10 different profiles?

- 10  groups on ACS?

- 1 Access-Policy? (Network Access) -> with 10 different Authorization Policy rules? 

- Anything else?

Where do I define the policy to use in Anyconnect?

Thanks in advance!

BR

[Marcin Latosiewicz]

I've done a similar deployment where all authentication/authorization and accounting was pointed from ASA to ACS.

There are multiple layers to your question. 

First of all, you have ACS, hopefully 5.x which gives you a nice policy driven authentication and authorization schema. 

1st layer - setup group-alias and group-urls for specific users on ASA. 

2nd layer - on ACS decides where those connection should be authenticated/authorized against (go to AD, RSA, local DB). ASA passess tunnel group name in authentication calls to ACS. 

3rd layer - group-lock feature ensures that user can only have access to resources if they are in a specific group. 

[Hooman G. shiraz]

Hi Marcin,

I'm trying to setup the same scenario but I'm sending the request directly to RSA first for authentication and setting the authorization server as ACS, I can see the traffic hitting ACS in the logs but cannot manage to process it and return a tunnel group name. will this work or I should redirect Auth requests to RSA from ACS.

Is there any document to explain your suggested 3 layers more in detail?

Thanks,