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?
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?
John
People who do not have access to specific servers / devices should not have passwords to these devices and so cannot get into them.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
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.
ASKER
@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.
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.
I have no experience with the windows radius servers so I can’t offer first hand experience of it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@Pete Thanks. Let me look into how that is done. Simple is good!
Just tested it - simples!
ASKER
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.
ASKER
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.
ASKER
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.
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.
ASKER
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.
ASKER
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.
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.
ASKER
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
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
ASKER
Wanted to make sure Mathew got a thank you for the link regarding using DAP. Examples from Pete made solution much easier.