CCNP Security VPN Cert Guide: Configuring Policies, Inheritance, and Attributes

Foundation Topics

Policies and Their Relationships

User policy and connection parameter enforcement is an important part of any VPN deployment. Without it, we cannot provide login parameters, authorization methods, or resource access for our users, which control what they can or cannot access and when.

An important part of policy assignment is the ability to provide flexibility and scalability to both administrators configuring them and the remote users using them.

• Flexibility is achieved through being able to assign the same security or network settings to any user or group regardless of their connection type.
• Scalability is achieved through modularity and policy inheritance, limiting the amount of duplicate configuration items required by policy reuse among groups or individual users.

All remote users must go through two phases before they can successfully connect and start to access resources made available through your VPN connection:

• The prelogin phase is achieved through the use of connection profiles (also known as tunnel groups). In connection profiles, we can carry out the assignment of connection attributes and parameters (for example, authentication, authorization, and accounting [AAA] and IP address assignment) and define the available connection methods (for example, IKEv1 and IKEv2 SSL), allowing our users to start the login process.
• The post-login phase is achieved through the use of group policy objects, Dynamic Access Policies (DAPs), and user-specific attributes. These may include such items as IPv4 or IPv6 access lists, Domain Name System (DNS) servers, access hours, split tunneling, and so on. Group policies offer a great deal of flexibility when assigning attributes to users, either individually in a user account or groupwide by assignment to a connection profile. DAPs provide an advanced policy assignment method based on user AAA attributes or client device posture assessment. We discuss DAPs, their configuration, and deployment in later chapters.

Different policy types, although they include their own specific attributes, are really just containers that can be used to hold multiple configuration items that might have been used multiple times already in different policies. For example, we can configure an access control list (ACL) (we'll call it Server_Access) to only allow access between remote client A and corporate server A. We assign it to the group policy object AnyConnect, limiting internal resource access for our AnyConnect users. Later, we create a new group policy for our IPsec VPN users and assign our Server_Access ACL to this group policy, as well.

In our example, we have two groups of users accessing our corporate network through their own protocol-specific connection profiles (AnyConnect and IPsec). Each of the two connection profiles has its own group policy objects, both using our Server_Access ACL. If we want to reduce the amount of configuration we have to carry out but still allow each connection group to have its specific attributes (for example, IP address pools and DNS servers), we can create a single group policy object using our Server_Access ACL and apply this to each connection profile.

Furthermore, if we want to really minimize the amount of configuration we have on our device, and the only difference between these two groups of users is their connection type (that is, they do not require any further attribute or parameter assignments between them), we can create a single connection profile allowing multiple connectivity types and attach the single group policy that uses our Server_Access ACL. Later, if one of our users requires access to corporate server B, we can create a custom ACL and apply it directly to their user account, or create a user-specific group policy object and assign this directly to our user.

We can be as specific as we like or as needs require for our particular environment, either sharing multiple policies between multiple groups, reusing multiple attributes in multiple policies, using multiple groups connecting to one connection profile, or configuring each group to have its own specific connection profiles, policies, and attributes. The choice is, well, yours.

As we create our connection profiles and policies, we might end up with a user who has been assigned the same attributes multiple times by separate policies. These might have been applied because of the user's group or department membership, connection type, or location. Regardless of the reason for these assignments, the result is that our user's policies are merged and assigned in a hierarchical fashion.

The hierarchal policy model shown in Figure 2-1 works from top to bottom with any attributes set within policy assignment methods toward the top of the list (DAPs), taking precedence over any conflicting attributes assigned within methods toward the end of the list (default group policy object).

Figure 2-1 ASA VPN Policy Enforcement Hierarchy

Each connection entry has its own default group policy object. As shown in Figure 2-1, the default group policy is at the end of the policy hierarchy. As a result, any attributes/settings that have not been configured within policies already assigned to a user are applied using the attribute assignment of the default group policy.

The same applies to other policy types within the policy hierarchy. However, if two policy types contain different values for the same attribute or property, the user is assigned the attribute set within the policy type that is higher in the hierarchy. For example, if IP pool A has been assigned to the group policy applied to the connection profile and IP pool B has been assigned to the user account directly, the user is assigned an IP address from IP pool B.

Understanding Connection Profiles

As you saw earlier, connection profiles provide our users with the necessary prelogin policies that must successfully establish a connection to our ASA device. We can also use connection profiles to separate our connecting users into the relevant groups that may require separate methods of access (for example, clientless SSL VPN, AnyConnect VPN sessions, or even separate AAA methods).

Consider the following scenario. You have two groups of users connecting into your environment: guests and corporate employees. Guests connecting into your organization do not require the same level of access as your employees. In fact, they only require access to an internal intranet portal. On the other hand, your corporate employees require access to internal file servers and email. Based on the level of access required by each group, we could create two connection profiles, aptly named Guests and Corporate for our discussion. Our Guests connection profile would only allow access for incoming clientless SSL VPNs and authenticate connecting users with a shared guest internal username and password. A group policy (covered in greater depth during the next section) would be applied to our connection profile containing the relevant bookmarks needed for browsing our company's intranet in the SSL VPN portal. However, our Corporate connection profile would allow access for incoming AnyConnect SSL, IKEv2, and IKEv1 (IPsec VPN clients), and an IP address would be assigned per remote user from an existing IP address pool. Authentication and authorization would be carried out using a combination of a one-time password (OTP) and internal Windows Active Directory server. A group policy would be applied to the connection profile to provide users with split-tunnel lists and access lists, restricting communication to only those internal subnets and devices that are required.

A few methods are available for allowing our users to select/connect to the appropriate connection profile they require. Depending on the authentication scheme we have configured for our users and their chosen login method (clientless SSL VPN, AnyConnect, IPsec client), they can either select a connection profile manually from a list of those available or have it selected for them automatically, based on one of the following methods:

• Group URL
• Group alias
• Certificate to connection profile mapping
• Per-user connection profile lock

Group URL

Group URLs allow remote users to select a connection profile by entering the direct URL configured for the profile they require. An example of a configured group URL is either of the following:

• https://<ASA IP address>/<connection profile>
• https://<ASA FQDN>/<connection profile>

Group Alias

Group aliases allow clientless SSL VPN users to select the appropriate connection profile from a list at the portal login page and AnyConnect users to select a connection profile in the client software. Both scenarios occur before a user has logged in and are covered in greater detail in Chapter 3, "Deploying an AnyConnect Remote-Access VPN Solution," and Chapter 9, "Deploying a Clientless SSL VPN Solution." As shown in Figure 2-2, the configuration of both a group alias and group URL is carried out in the Group Alias/Group URL pane of a connection profiles properties window. We navigate to Configuration > Remote Access VPN > Network (Client) Access | Clientless SSL VPN Access > AnyConnect Connection Profiles | Connection Profiles, select the connection profile, click Edit, and then use the menu on the left side to select Advanced > Group Alias/Group URL.

Figure 2-2 Connection Profile Group URL and Alias Configuration

As you will also see in later chapters, before our remote users can select a connection profile by group alias, we must first enable this feature on the ASA in the respective connection profiles pane of the Adaptive Security Device Manager (ASDM), as shown in Figure 2-3.

Figure 2-3 Connection Profile Pane: Allow Group Alias Selection

For example, we can enable our AnyConnect and clientless SSL VPN users to select a connection profile in their client software or from the portal login page using the following steps:

• AnyConnect Users: Navigate to Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles. In the Login Page Setting section of the window, select Allow User to Select Connection Profile, Identified by Its Alias.
• Clientless SSL VPN Users: Navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles. In the Login Page Setting section of the window, select Allow User to Select Connection Profile, Identified by Its Alias.

Certificate to Connection Profile Mapping

If you have chosen to use digital certificate authentication for your connection profiles, the distinguished name (DN) values in a remote user's certificate can be used to select the appropriate connection profile. For example, if the remote user initiating a connection is a member of the Accounts team, his certificate DN value may equal OU=Accounts. Using certificate-to-connection profile maps, the ASA can be configured to match any connecting users with the value of OU=Accounts to a custom connection profile created for Accounts department personnel. You can apply the same actions to any DN values held in your user certificates (as discussed in Chapter 9 and Chapter 4, "Advanced Authentication and Authorization of AnyConnect VPNs").

Per-User Connection Profile Lock

We can also assign a connection profile directly to remote users on an individual basis. For example, we might have a specific connection profile for our VPs and want to make the process of connecting as seamless as possible for them without their having to first enter or select a connection profile.

The process of assigning a connection profile directly to a user can be achieved in the properties menu of the user's account, as shown in Figure 2-4.

Figure 2-4 Configuring Per-User Connection Profile Lock

We begin by selecting the user account to edit from Configuration > Device Management > Users/AAA > User Accounts, and then click Edit. In the Edit User Account window, select VPN Policy from the menu on the left, and in the pane on the right side, uncheck the Connection Profile (Tunnel Group) Lock Inherit check box. Using the drop-down list, select the appropriate connection profile to be assigned to this user.

We see a great deal more of connection profiles and their use in the chapters that follow. It is important to note at this stage that we can only allow clientless SSL VPN and client-based (AnyConnect) VPN remote users the option to select a connection profile. As discussed in Chapter 15, "Deploying and Managing the Cisco VPN Client," when we work with IPsec remote-access VPNs, the connection profile name is configured in the client software as the group name and must match before a successful connection can occur.

Default Connection Profiles

Besides our own custom connection profiles, default connection profiles are applied to a user's session if the various connection parameters in manually configured connection profiles are not satisfied and the user is not allowed to select the connection profile before login.

Three default connection profiles are configured on the ASA, as listed here. These cannot be removed, but they can be modified, allowing us to change the settings to match our environment:

• DefaultRAGroup: Used for client-based (AnyConnect) SSL VPNs and IPsec remote-access VPNs.
• DefaultWEBVPNGroup: Used for clientless SSL VPNs.
• DefaultL2LGroup: Used for IPsec LAN-to-LAN connections.

The default connection profiles, as mentioned earlier, are used mainly for global property assignment or a catchall mechanism for users that may only require a basic VPN portal (webmail and so on) and are not able to or allowed to select a connection profile. It is recommended that your own custom connection profiles be created for your specific VPN deployments, instead of relying on the default connection profiles for remote user connection establishment.

By default, when using plain old username and password-based authentication for remote user authentication, users are automatically connected to the appropriate default connection profile based on their connection method (that is, clientless SSL, IPsec, and so on). We can overcome this problem by providing our remote users with the means to select a connection profile before authenticating (either from a drop-down list in the clientless SSL portal or the AnyConnect client). If we have deployed username and password-based authentication (no certificates) for our clientless SSL and AnyConnect VPNs, however, and we have configured our ASA to provide our remote users with the ability to select a connection profile, users must select an available connection profile from the list in order to continue. If they do not select a connection profile, they are mapped to their default connection profile.

When using certificate-based authentication the game changes, and the default connection profile is used only if predefined fields within a user's certificate do not match the values we configure in Certificate to Connection Profile Mapping Rules for automatic connection profile assignment.

The process that occurs when using the Cisco IPsec VPN client is different from that just described for both clientless and full-tunnel connections, again depending on the type of authentication method in use. As you will see later in Chapter 15, "Deploying and Managing the Cisco VPN Client," when deploying IPsec remote-access connections using pre-shared key authentication, the connection profile name must be entered exactly into the client software (in the Group Name field). If the connection process fails, the client is not assigned to the default connection profile for the specific method of connection (DefaultRAGroup). Instead, the connection fails.

If we are using certificate-based authentication with the Cisco IPsec VPN client, we are not given the option of selecting or entering a connection profile/group name. Instead, we must either configure our own certificate to connection profile mappings, or by default, the ASA attempts to match the OU field value of the certificate to an available connection profile with the same name. If one or both of these methods fail, unlike with the pre-shared key method, the remote user is mapped to the DefaultRAGroup connection profile instead of being disconnected.

The DefaultL2LGroup acts as a catchall for any LAN-to-LAN IPsec VPN sessions that do not match on a manually administrator-configured connection profile, regardless of its authentication type, pre-shared-key, or if it is certificate based.

Note that, by default, neither DefaultWEBVPNGroup nor DefaultRAGroup allows for AnyConnect sessions, because these connection profiles have the DfltGrpPolicy group policy attached, which only permits clientless SSL VPN, IPsec VPN, and L2TP/IPsec sessions. These settings can, of course, be modified.

As you move through the rest of the book, you will many more uses of connection profiles with all available types of connectivity offered by the ASA device, in addition to many advanced features that are available within a connection profile.

Connection profiles are created by first navigating to Configuration > Remote Access VPN or Site-to-Site VPN. Depending on the chosen method of connectivity (whether this be clientless SSL, IKEv1, IKEv2, or so forth), select one of the following options in the Remote Access VPN or Site-to-Site VPN areas to continue:

Remote Access VPN:

• Network (Client) Access: Use for AnyConnect (full tunnel) SSL and IKEv2, Cisco IPsec VPN client, and IKEv1 connections.
• Clientless SSL VPN: Use for browser-based clientless SSL VPN connections.

Site-to-Site VPN:

• Connection Profiles: Use for all site-to-site connection profiles.

After navigating to the appropriate area, create a connection profile by selecting Add on the right side of the window. The Add Connection Profile window appears, as shown in Figure 2-5.

Figure 2-5 Connection Profile Creation

In this window, the connection profile is given a name, the authentication method selected, and custom attributes assigned (such as IP address pools, Dynamic Host Configuration Protocol (DHCP) servers, group policies, and so on). These settings are described in detail in later chapters.

Understanding Group Policies

As you saw earlier, a group policy object is a container for the various attributes and post-login parameters that can be assigned to VPN users, and to endpoints such as IPv4 and IPv6 ACLs, DHCP servers, address pools, and so on.

Group policies can simplify the configuration required by allowing for their assignment to multiple users or connection profiles. This provides a greater level of scale, flexibility, and management when working with multiple connection methods and remote users.

Group policies may be internal (local) or external (remote). Both internal and external group policies are configured on the ASA. However, unlike internal policies, which hold their configured attributes and parameters locally on the ASA, external group policy attributes and parameters are configured and stored on external AAA servers. During a login attempt, the configured AAA authorization servers are contacted and send back the relevant policy attributes and parameters, based on the connecting user's policy assignment.

For more information about external group policy objects, see Chapter 4, "Advanced Authentication and Authorization of AnyConnect VPNs." For the remainder of this section, we focus only on the deployment and configuration of local group policies.

Group policies, as previously mentioned, are applied to either a connection profile or a user account directly. They do not provide any function while they are unassigned.

Although we can select the connection method that a group policy can apply to (for example, IKEv1, IKEv2, or AnyConnect SSL), unlike connection profiles, group policy objects are not locally specific to a connection profile type. If we create a group policy in the Network (Client) Access area of the ASDM for our AnyConnect or IPsec remote-access clients, the same group policy is globally available among the other connection types, and we can select, edit, or delete it within the Group Policies section of the Site-to-Site or Clientless SSL VPN areas of the ASDM. This enables us to reuse our group policy objects, not just by multiple connection profiles of the same type, but by all connection profile types and remote users regardless of their connection method (depending on the configured protocols in the group policy itself). However, not all configuration areas or items may be available, depending on the configuration area you are using to add or edit your group policy object. For example, when configuring a site-to-site group policy object, there is no need for us to be able to see all the remote user-specific attributes and parameters that might be assigned, because they are unavailable for use in the connection type being configured.

Group policy objects are configured in any one of these three areas:

• Configuration > Remote Access VPN > Network (client) Access > Group Policies
• Configuration > Remote Access VPN > Clientless SSL VPN > Group Policies
• Configuration > Site-to-Site VPN > Group Policies

Select Add > Internal Group Policy, and the window shown in Figure 2-6 appears.

Figure 2-6 Internal Group Policy Creation

We begin by giving our group policy object a name, a banner, and address pools. If we expand the More Options section of the window, we are presented with a greater list of parameters that may be configured to further tailor the experience our remote users have when connecting to our VPN deployment. All these options are covered in later chapters. For now, it is just important to at least know they exist and how to get to them.

You might have noticed also in Figure 2-6 that all the fields in the Add Internal Group Policy window have the Inherit option in front of them. Similar to connection profiles, the ASA also has a default group policy object DfltGrpPolicy that cannot be deleted. However, its properties can be modified and indirectly applied to our configured group policies, as they all by default inherit the settings configured in DfltGrpPolicy.

Configure User Attributes

We have several choices of which users to use. We can use local users or remote users that have been created specifically for our deployment on RADIUS, TACACS+, or other remote AAA servers. We can also use an existing database of users. For example, a company might want to use their existing Microsoft Windows Active Directory deployment for the management of new users and allow their internal users to connect into their environment remotely.

Many of the examples in this book use the internal user database (local users) available on the ASA. The policies and parameters we can assign to either local or remote users are the same by using either connection profiles or group policy objects. However, in a locally configured user, we can also assign attributes and policy objects directly to their user account using the various properties available. (For example, in the preceding sections we discussed the assignment of group policies and connection profiles to a user account directly.)

Local user accounts are configured on the ASA device in the Device Management > Users/AAA > User Accounts area of the ASDM. Begin by creating a new user account, shown in Figure 2-7, by selecting Add.

Figure 2-7 ASDM Local User Account Creation

We enter a username, password, and the type of management access our user will have to the ASA device (for example, telnet, Secure Shell [SSH], ASDM). Depending on the type of user account we are creating (VPN User, Management Only, VPN User with Management Functions), select the appropriate level of management access to the ASA to grant the user. By default, any new user accounts created are given the option of Full Access to the ASA. However, if our users are only created for the purposes of connecting to our VPNs, there is no requirement for them to have management access to the ASA, and this option should be changed to No ASDM, SSH, Telnet, or Console Access instead.

We can further customize the user experience during their VPN connection by assigning the various options available, either when connecting through a clientless SSL VPN session or AnyConnect full-tunnel session (for example, bookmark lists, Smart Tunnel applications and access, manual or automatic download of the AnyConnect client). However, it is recommended if you have multiple users in your VPN deployment that all have similar parameters and settings attached to their account. Assignment of these attributes should be carried out using group policy objects or connection profiles for ease of management.

As you continue through this book, you will see the creation of local user accounts in detail, along with the advanced attributes that are available to them and the results that occur after their assignment.

Using External Servers for AAA and Policies

As briefly discussed earlier, not only can we use remote AAA servers for the purposes of user creation and management, we can also use them for the purposes of policy assignment using external group policies.

The use of an external AAA server for the purposes of policy assignment is recommended. This provides centralized policy storage and management where a VPN deployment might have more than one ASA device available (for example, when using two or more ASA devices in a VPN cluster).

The ASA device supports the following external AAA server types and protocols for authorization purposes:

• RADIUS
• TACACS+
• LDAP
• NT Domain
• SDI
• Kerberos
• HTTP Form

Only two of the protocols are available for use with external group policy assignment: RADIUS and Lightweight Directory Access Protocol (LDAP). In earlier ASA releases, TACACS+ was also available for external policy assignment. However, because of the lack of support offered by the protocol for the purposes of policy assignment compared to the parameters offered by RADIUS and LDAP, TACACS+ has been removed for this purpose. (TACACS+ support has been removed for use with external group policy assignment only; the protocol still exists for use as an AAA server for user authentication purposes.)

To create a new external group policy object whose name will exist on the ASA device (although all attributes that are stored in the group policy exist only on the configured RADIUS or LDAP server), navigate to one of the following locations:

• Configuration > Remote Access VPN > Network (client) Access > Group Policies
• Configuration > Remote Access VPN > Clientless SSL VPN > Group Policies
• Configuration > Site-to-Site VPN > Group Policies

Select Add > External Group Policy to begin the configuration process, shown in Figure 2-8.

Figure 2-8 ASDM Local User Account Creation

The ASA asks for very few parameters in comparison to when creating an internal group policy, because we are only creating the container or name for the group policy on the ASA and specifying the AAA server that will store the policy attributes along with the password the ASA uses to authenticate against it.

Table 2-2 lists the available RADIUS attributes, attribute number, type, and values, respectively, which you may configure on an external RADIUS or LDAP server for the purposes of user policy assignment.

Table 2-2. Supported RADIUS Attributes and Values