How are those of you in medium-large organization (1500+ employees) managing your VPN access rules?
We started down the path of using AD groups to granularly provide access allowed or disallowed by the VPN concentrator itself. However, this has resulted in a lot of complexity and it’s difficult to understand who has access to what.
I wonder if a more scalable approach would be to only do very simple permissions on the VPN box and rely on firewalls to handle the access control? I think we may end up with the same problem.
I love using Pulse’s UAC (NAC) along with their SSL VPN… Identities will follow the user from the LAN/VPN and let you control multiple enforcement points… e.g. dot1x vlan assignment, firewall integration for enforcement, etc…
Palo Alto firewalls using their Global Protect SSL client tied into AD via radius/ldaps works really well. I’ve deployed this for several large Enterprise customers and the USER-ID feature on the PANs makes writing/auditing/logging security policies really easy. The real kicker is to have purpose built security groups in AD. The Global Protect client has a lot of great features that makes integrating with 2FA pretty simple, plus you can add HIP and device type objects in to treat users different based on the device they are connecting with and some health checks. Another great feature is that it can detect if its inside the network, or if its outside it can find the closest firewall before connecting. Some of our customers that rely on zero trust use it internally even, to terminate users on a zone on the firewall before they can access servers etc.
Both large corporations I’ve worked for (1000+) allow VPN access for anyone, and there are no ACLs except for what IP ranges go via the split tunnel.
We require 2FA to sign in, but besides that VPN users are treated the same as if they were on the LAN.
Up until very recently we had no internal wireless, just a guest SSID that went to the internet, so the only way back in while in the building was to VPN.
I don’t see how you can do per user/group permissions on the firewalls (unless those are the VPN terminators) because they don’t have any idea the user–>IP mapping. You could break different groups into different /24’s or whatever, but at that level of complexity just do the NAC on the VPN devices.
Proper documentation and redesigning it from scratch may be the best idea.
We’re on a Cisco shop (running ASA 5515-5585 depending on the site.), so it’s primarily Dyanmic Access Policy, mapped to a Tunnel List, which is restricted via an LDAP Attribute (the AD Security Group).
We’re now deploying FirePower, Cisco Email and Web Security and probably ISE at a later time. So I imagine we’ll be integrating that into our security model as time goes on.
What you can do really depends on your VPN solution and whether or not you have something like Cisco ISE do you can do dynamic access policies.
Groups definitely work, though it sounds like you need to work on a naming standard and some sort of documentation that shows what a HR group has access too.
As you mentioned VPN user access, would assume SSL VPN.
Based on a deny all policy at your firewalls, you will require every time to open ports when access to new resources are granted. But the firewall doesn’t understand vpn users.
Best is to keep good documentation, good designs, and hopefully use good software. What are you using btw?
The real kicker is to have purpose built security groups in AD
This right here.
Do it by groups, have groups specifically for VPN and create access rules based on these.
It’s still work, but it’s like 1h instead of going crazy with each individual user and what groups they belong to. You can leverage groups already in AD if they are cut and dry, but that is rarely the case and making new groups that will not be messed about with is the way to go, despite having to talk to your sysadmin… bleh
Similar here. We use SecurID, and pull an attribute from there which tells us the group name for the user, which in turn is configured for that groups ACL.
What’s funny (funny sad) is that while we could have that value pulled from AD, when AD populates from the HRIS, HR has no hesitation changing the name of a department from (say) IT to Info Tech, not understanding the implications. So we statically set group name per user on the SecurID.
