How to limit VPN access

I am using Cisco ASA firewalls.  I would like to use Cisco anyconnect VPN and direct some active directory users to be able to connect only to specific computers inside the network. Other users need unrestricted access.  Looking for thoughts on how to design this.
I could create VPN groups on the firewall that have access rules allowing only a single IP and even port to be connected, but all three firewalls would need to be manually updated with usernames and passwords.  Additionally, when connecting, the user would have to select the VPN group name.
I could create and active directory user with limited access to specific servers.  Radius is already in place.  But Restrictions in active directory seem to end at the machine level.  I would like these users to only be able to access port 80.  (RDP is open for maintenance as well as the usual windows ports)

Got any creative ideas?
LVL 3
Bill HerdeOwnerAsked:
Who is Participating?
 
Pete LongConnect With a Mentor Technical ConsultantCommented:
As you already have a solution in place, I'm assuming everyone authenticates using their AD username/password?

Then the simplest way to do this, is use DAP (Dynamic access policies) these are setup in the ADSM, and will apply specific restrictions if a user is (or is not) a member of a group, in you case and ACL, you can then assign specific ACLs in the ASA to specific windows security groups.

I only ever use DAP for LDAP group authentication, but I have sen it used to do exactly what you want just remember == is equals and != is not equals :)

P
0
 
JohnBusiness Consultant (Owner)Commented:
People who do not have access to specific servers / devices should not have passwords to these devices and so cannot get into them.
0
 
Matthew AyersConnect With a Mentor Senior Systems AdminstratorCommented:
Could you use the radius server to specify which Access-list is applied to the users. Looking at https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113449-asa-vpn-acs-00.html may help you.
0
Choose an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

 
Bill HerdeOwnerAuthor Commented:
Mathew - This sounds like the solution needed. The desire is for this restricted group to not be able to see anything but the selected target. Do you have any links to more information on setting up a windows radius server to send acl lists? Anything else that can shorten the learning curve to implement this?
0
 
JohnBusiness Consultant (Owner)Commented:
While you can try to limit access by VPN rules, if a user comes in the office (so VPN does not apply) then you need to consider logical server access controls by user and password as well.
0
 
Bill HerdeOwnerAuthor Commented:
@john  Understood.  This group will be for users in a remote call center.  When they connect to the VPN, they will have access to a single web server running the application. They will also be restricted from access to any other servers using windows security, but management would like them to not be able to even see the names of or ping any other devices or even attempt connection to any other ports on the web server.
0
 
Matthew AyersSenior Systems AdminstratorCommented:
This article from sonic wall may help. https://www.sonicwall.com/en-us/support/knowledge-base/170502802997480

I have no experience with the windows radius servers so I can’t offer first hand experience of it.
0
 
Bill HerdeOwnerAuthor Commented:
@Pete  Thanks.  Let me look into how that is done.  Simple is good!
0
 
Pete LongTechnical ConsultantCommented:
0
 
Pete LongTechnical ConsultantCommented:
Just tested it - simples!

DAP Policy
0
 
Bill HerdeOwnerAuthor Commented:
Ran into a complication.   LDAP failed to return any information.  I opened ticket with TACS to assist getting this first part right, and after some effort we came to the conclusion that LDAP was returning a code 10 referral.  Referral is not supported by the ASA.  Cisco tech just emailed me that we may be able to use radius attribute ID.  I will give it another shot a little later, I have a telephone issue to fix first.
0
 
Bill HerdeOwnerAuthor Commented:
Waiting for phone tech to appear. Did a quick test of the policy using radius attribute id 4242 testing for membership in the AD group, and it returned a status on 1 = continue.  Looks good so far.
0
 
Bill HerdeOwnerAuthor Commented:
Fires are out so I can get back to this.
Not sure what I am doing wrong here. The DAP screen sets up as in your screenshot above, but using radius 4242 to test for group membership.  The 'TEST Dynamic Access Policies' button runs the test and returns the following.

The DAP policy contains the following attributes for user:
--------------------------------------------------------------------------
1: tunnel-protocol = svc
2: svc ask = ask: no, dflt: svc
3: action = continue
4: user-message = Connecting to EDMS Dashboard

But there does not seem to be a place to tie the result to the ACL created.  When connecting with anyconnect as the test user, I still get the same full access as any authorized  VPN user.

Using CLI (which I am by NO means adept at) I look for the restricted  ACL to show up on the user session, but it does not look to be applied.
0
 
Bill HerdeOwnerAuthor Commented:
I had Cisco on the phone just now, and the DAP will be the correct solution.  What is lacking now is how to get the radius server to respond with the correct group name.  Workin on that, If Windows Radius configuration is in your wheel house please respond.
0
 
Bill HerdeOwnerAuthor Commented:
Still can’t make English out of this…

Since I could find no means in windows NPS to define attribute 146, I am trying to make it meet condition testing for attribute ID 25, which I can set per user group in AD.  .

This is the current test for in DAP.


------------------------
aaa.radius.4121 =             CallCenterVPN

Selected DAP records
--------------------
Call_Center_VPN

ACLs to aggregate for DAP-ip-user-
--------------------------------
priority 1, access-list CallCenterVPN
Using existing access-list: CallCenterVPN

The DAP policy contains the following attributes for user:
--------------------------------------------------------------------------
1: tunnel-protocol = svc
2: url-entry = enable
3: file-entry = disable
4: file-browsing = disable
5: svc ask = ask: no, dflt: svc
6: action = continue
7: user-message = Connecting to EDMS Dashboard
8: network-acl = CallCenterVPN

This is what the ASA reports when connecting.


Radius: Type = 25 (0x19) Class
Radius: Length = 15 (0x0F)
Radius: Value (String) =
43 61 6c 6c 43 65 6e 74 65 72 56 50 4e             |  CallCenterVPN
Radius: Type = 25 (0x19) Class

But the ACL is still not applied……

Quickly forming a head-shaped hole in the wall here.
0
 
Bill HerdeOwnerAuthor Commented:
Well we have an answer at last.  Yes, Setting a dynamic access policy (DAP) is the cure.  I was unable to use LDAP because multiple LDAP servers in the environment cause the response to be flagged as 'referral'.  Radius was set up for authentication, and Cisco TACs suggested using tunnel group type identifier as trigger for DAP.  Also sent along a KB telling me to test using radius ID (146) plus 4096 as test value. This information, while documented, is bogus.  (See below)  Then needed to get MSFT radius to change that value dependent on security group.  

Unable to set value 146 in MSFT radius, but in Network Policy Server you can create a network policy for the security group, and on the settings tab of the properties for that policy add (or change) the 'Class' value to the value you will be testing for in DAP. That will change attribute 25.  4096+25=4121, and DAP failed to trigger still.  Then tried testing ID 25 for value (actually by accident) and it finally worked!

From ASDM defining the Access List straight out of the DAP settings is very intuitive.  Took only a few minutes more to finish it up.

Many thanks to all participants.
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/117641-config-asa-00.html
0
 
Bill HerdeOwnerAuthor Commented:
Wanted to make sure Mathew got a thank you for the link regarding using DAP.  Examples from Pete made solution much easier.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.