Thursday, January 21, 2016

Dynamic Group Policy Assignment (Cisco ASA, Windows Radius, Cisco DAP, AnyConnect)

I had the opportunity to set up automatic group-policy assignment on a Cisco ASA from a Windows Radius server. This guide walks through that setup, instructs on Cisco DAP (Deep client inspection). This only shows one group assignment, but it's easy to use these instructions in a lego-like manner and build out dozens of group policies with different access rules.


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.
# Create unique subnet
 ip local pool ITNetworkVPNPool mask

# Create object groups for ACL
 object-group network ITNetworkVPNPool
 description AnyConnect IT Network team pool

# Create group policy
 group-policy ITNetworkVPNGroupPolicy internal
 group-policy ITNetworkVPNGroupPolicy attributes
 wins-server value
 dns-server value
 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 
 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 to initiate connection the first time. After a successful connection, the hostname is remembered.


DAP configuration guide:

ASA and Windows Radius configuration guide:

Good luck configuring your own!