Requirements
1. Use Radius/AD credentials and user accounts
2. Ease of use for network personnel in order to quickly troubleshoot
3. Simple, extensible features which can be customized to meet future needs
4. Ability to customize access for specific users or specific groups of users to prevent users/partners/contractors from receiving more access than they require for their jobs
5. Ability for non-network IT staff to add remote access to users, but limit non-network staff ability to provide too much access to users
6. Use of familiar tools to ease the transition for affected teams
7. Deep inspection of AnyConnect clients - treat on-domain computers differently from off-domain, same with mobile, mac, linux, etc.
Technical Building Blocks
Each technical building block is covered in turn. When a user attempts to connect, Radius passed a value to the ASAs, instructing them which ‘group policy’ to use on the ASA for that user. ‘Group Policies’ can have ACLs and other security measures implemented on them. We can also utilize Dynamic Access Protection via AnyConnect to ‘deep inspect’ clients that attempt to connect to the network.
Active Directory Security Groups
The security of this system is rooted in Active Directory (AD) security groups, which meets the need to allow non-network IT staff to provide users remote access.
Windows-based Radius
When run from Windows, Radius is natively integrated with AD and can read membership in AD security groups. We should build radius remote access policies based on a specific security group membership.
- These groups are evaluated top to bottom, so if users are part of multiple “VPN” security groups, the first match will be used.
- Based on this remote access policy match, we send an attribute called “Class” as a string to the firewalls when users attempt to VPN in, and this tells the ASAs which “group policy” to use for inbound VPN’d users.
Specific Group-Policies and Associated ACLs
A group policy with the same (caps-sensitive) name as the “class” attribute in radius is created on the ASA. This is where inbound users that match the radius connection policy will be placed.
Access is limited across an entire group policy by associating an ACL that exists on the ASA with a group policy. This ACL is dynamically associated with the inbound VPN session when a user connects. This allows for an extensible, dynamic solution to limit access for inbound connections.
ip local pool ITNetworkVPNPool 172.16.1.0-172.16.1.250 mask 255.255.255.0
# Create object groups for ACL
object-group network ITNetworkVPNPool
description AnyConnect IT Network team pool
network-object 172.16.1.0 255.255.255.0
# Create group policy
group-policy ITNetworkVPNGroupPolicy internal
group-policy ITNetworkVPNGroupPolicy attributes
wins-server value 10.1.1.1 10.1.1.2
dns-server value 10.1.1.1 10.1.1.2
vpn-idle-timeout 30
vpn-tunnel-protocol IPSec svc
split-tunnel-policy tunnelall
msie-proxy method no-modify
address-pools value ITNetworkVPNPool
vpn-filter value ITNetworkACLInbound <-- Use this command to filter only this group of users with a particular local ACL on the firewall.
# Create tunnel-group
tunnel-group ITNetworkVPN_TunnelGroup type remote-access
tunnel-group ITNetworkVPN_TunnelGroup general-attributes
address-pool ITNetworkVPNPool
authentication-server-group AAA-Radius
authorization-server-group AAA-Radius
accounting-server-group AAA-Radius
default-group-policy ITNetworkVPNGroupPolicy
password-management
tunnel-group ITNetworkVPN_TunnelGroup webvpn-attributes
group-alias ITNetworkVPN enable
tunnel-group ITNetworkVPN_TunnelGroup ipsec-attributes
ikev1 pre-shared-key 2yjvi69%6#9v03jdk
isakmp keepalive disable
Dynamic Access Policies – Client Deep Inspection
When devices running AnyConnect attempt to connect to the ASA, they gather specific information about the inbound device. We can use that information to determinate if we want that device VPN’ing into the network. We can check computer domain, patch level, OS type and version, anything in the registry, etc. We can also check and trigger antivirus and firewall actions.
To accomplish this on the firewall side, we use a feature called Dynamic Access Policies. These allow the firewall to evaluate a connecting client and treat it differently based on the info provided by AnyConnect. If clients do not match any policies, they fall into the default “DftlAccessPolicy” and this terminates their connection immediately.
Dynamic Access Policies are only accessible via the ASDM interface at: Configuration --> Remote Access VPN --> Network (Client) Access --> Dynamic Access Policies
Policies are evaluated in a top-down (higher priority first) fashion. “Deny” steps have an action of “terminate” and “Permit” steps have an action of “continue”. Each step evaluates the information sent to AnyConnect from the client, parses it, and sees if the client meets the requirements for the step.
Cisco AnyConnect
Cisco AnyConnect is Cisco’s new VPN solution. It supports VPN, client evaluation, remote execution of code, triggered A/V updates/programming, and lots more. When users open the tool, they must type in a dns name, like vpn.myDomain.com to initiate connection the first time. After a successful connection, the hostname is remembered.
References
DAP configuration guide: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/108000-dap-deploy-guide.html
ASA and Windows Radius configuration guide: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/117641-config-asa-00.html
Good luck configuring your own!
Kyler
