Chapter 13. AAA of VPN on ASA

In Chapter 12, “AAA of VPN and PPP Sessions on IOS,” you learned about authenticating, authorizing, and accounting (AAA) for IPsec Remote Access VPN (EzVPN Remote) and SSL VPN on IOS. In this chapter, you will learn about AAA for EzVPN and SSL VPN on ASA.

If you have not done so already, you should read the previous chapter to ensure that you have a firm grasp of the different phases of IPsec, Xauth, and the role of RADIUS attributes during authorization. This chapter will not rehash this content, but will focus on the difference in configuration and RADIUS attributes. In addition, this chapter looks at authentication and authorization of VPN sessions using LDAP because it is very commonly used today. This chapter again focuses on RADIUS as a protocol of choice for VPN authentication due to the extensive list of attributes available for authorization.

Authenticating Remote Access IPsec VPN (EzVPN Remote) and SSL VPN Using RADIUS

ASA was not only the successor for Cisco PIX but also for the Cisco VPN 3000 series Concentrators. It inherited and eventually built on the concepts from the 3000 series devices to evolve into a very powerful VPN platform.

There is no difference between the way IPsec is implemented between Cisco IOS and Cisco ASA including the support for Xauth. Similar to IPsec VPN, there is very little difference in SSL VPN implementation between IOS and ASA. Again, make sure you read about the mechanics of IKE, Xauth, and SSL VPN in Chapter 12.

It is also important that you familiarize yourself with the VPN configuration on ASA because it is very different from the VPN configuration on IOS.

Before enabling Xauth for IPsec or User authentication for SSL VPN, you have to configure an AAA server group using the following commands:

aaa-server group-tag protocol radius
aaa-server group-tag [if-name] host server-ip-address shared-key

You can add multiple servers to a single group for fallback. These commands are discussed in detail in Chapter 7, “Administrative AAA on ASA/PIX.”

When a new IPsec Remote Access or SSL VPN connection is initiated to an ASA, it matches the group name presented to a configured Tunnel-Group. Example 13-1 shows a Tunnel-Group configured on ASA. The tunnel-group configuration is divided into general attributes and ipsec attributes.

Example 13-1. Tunnel-Group Configuration on ASA

To enable Xauth or user authentication for SSL VPN, add the following command to the tunnel-group general attributes section:

authentication-server-group [if_name] group-tag

This command ties the AAA server group to the tunnel-group and enables Xauth or user authentication. The if_name parameter defines the interface through which the AAA servers can be reached. If you configure an if_name in this command, it will override the if_name configured in the aaa-server command. The wrong if_name will cause all RADIUS requests to be sent out the wrong interface in some ASA versions. Example 13-2 shows the tunnel-group configuration with Xauth enabled.

Example 13-2. Tunnel-Group Configuration with Xauth Enabled

Configuring ACS for IPsec Remote Access and SSL VPN Authentication

Configuring ACS 4.2 and 5.1 for VPN authentication requires the steps you followed for configuring administrative authentication on IOS devices. Refer to Chapter 6, “Administrative AAA on IOS,” to recall the steps you used. A summary of steps required is as follows:

Step 1. Add the ASA as an AAA Client with the correct shared key and protocol.

Step 2. Add a user.

Step 3. For ease of learning, ensure that you use a new group or access service so that previous configuration does not cause problems.

Verifying and Troubleshooting VPN RADIUS Authentication

The most common problems with VPN authentication relate to the communication between the ASA and the AAA server as discussed in Chapter 7. For the most part, when the communication between the ASA and the AAA server is working, VPN authentication works as well. If communication between the ASA and the AAA server is working well, but VPN authentication fails, you should verify the following:

• Authentication command is applied to the correct tunnel-group.

• Ensure that the authentication commands are using the correct group tag.

• Ensure that the server entry in the AAA server group is pointing to the correct interface.

• Test the local user authentication before configuring Xauth or SSL VPN authentication. This rules out problems with VPN configuration itself.

For troubleshooting VPN authentication, the following debug commands are most useful:

• debug radius: This command shows debugs of the RADIUS communication between the ASA and the RADIUS server. If authentication is failing, this is a good place to start troubleshooting.

• debug crypto isakmp: This command shows debugs of Internet Key Exchange (IKE) events. Xauth-related events are also part of these debugs. You can use these debugs in combination with RADIUS debugs to find out whether Xauth is failing or Phase 1 of the VPN negotiation is failing.

• debug webvpn: This command shows debugs of events and errors related to WebVPN. You can use these debugs along with RADIUS debugs to find out whether authentication is failing or WebVPN configuration is incorrect.

• debug aaa authentication: This command shows information regarding the authentication process. You can use this debug along with RADIUS and crypto/webvpn debugs to see the entire sequence of events starting from session establishment to authentication failure.

Authorizing IPsec Remote Access and SSL VPN Using RADIUS

You already know that when a new IPsec and SSL VPN connection is received by ASA, it looks for a tunnel-group matching the request. The tunnel-group has, among other configuration, a group-policy name configured in it. This group-policy contains all the authorization attributes required for connection. This group-policy can be configured on ASA for local authorization or on an external RADIUS server.

In Chapter 12, you learned that the group-policy (called client configuration group on IOS) can be added in the RADIUS server as a user with all the required attributes. VPN authorization on ASA works almost the same way. One difference between IOS and ASA VPN authentication is that you need to define the group as external on ASA and can use any password for group authentication (IOS allows using cisco as a password only). The following command is used to define the external group on ASA:

group-policy group-policy-name external server-group group-tag password group-password

group-policy-name is the name of the group-policy. This is added as a user in the RADIUS server with password set to group-password. group-tag is the RADIUS server group to be used for group authentication.

Another important difference between ASA and IOS is that the tunnel password used between the ASA and the VPN client is always defined on ASA. This means that ASA will generate only two RADIUS requests—the first one for Xauth and the second one to get the group attributes using the group-policy name as the username.

After you have defined the group as external on ASA, it can be associated to a tunnel-group using the following command:

tunnel-group group-name general-attributes
    default-group-policy group-policy-name

If you do not want to define the entire group-policy on the RADIUS server, you can use a local group-policy and configure a few attributes in the VPN user profile. These attributes will override the conflicting attributes in the group-policy. This can provide an increased or decreased privilege level on a per-use basis. Unlike on IOS, you can define any attribute in the VPN user profile. The remaining attributes are taken from the group profile.

Before moving onto ACS configuration, you should be aware of the fact that ASA has a local group-policy called DfltGrpPolicy defined by default. Any attributes not present in a VPN user profile and the group-policy will be picked up from DfltGrpPolicy. You can view this group-policy using the show run all group-policy DfltGrpPolicy command.

Configuring ACS 4.2 and 5.1 for IPsec and SSL VPN Authorization

When ASA is configured to use an external group-policy, the group is added in ACS as a user. The password of this user has to match the password specified in the group-policy on ASA.

Unlike VPN authorization on IOS, authorization on ASA requires you to use the Cisco VPN 3000/ASA 7.x RADIUS attributes, which have a vendor ID of 3076. These are an extensive list of attributes specifically created for IPsec and SSL VPN on VPN 3000 series Concentrators and ASA 7.x.

If you haven’t changed anything in the DfltGrpPolicy on ASA, the group-policy (added as a user) on ACS should have at least the following attribute—RADIUS (CVPN3000/ASA 7.x) Group-Based-Address-Pools (Attribute number 217), with the value set to a pool name configured on ASA for IPsec Remote Access VPN to work. For SSL VPN (WebVPN), there is no minimum requirement in terms of attributes.

There are many attributes in the Cisco VPN 3000/ASA 7.x RADIUS dictionary, owing to which you can create a comprehensive group or user profile on ACS. It is not possible to discuss each and every attribute in the dictionary but a few of the most commonly used attributes are as follows:

• IPSec-Split-Tunneling-Policy (3076/55): Used to specify the split tunnel policy of the group. Acceptable values are 0 (No Split Tunneling), 1 (Split Tunneling), and 2 (Local LAN permitted).

• IPSec-Split-Tunnel-List (3076/27): Used to specify the split tunnel access list name/number. The access list has to be present in the ASA configuration.

• Tunnel-Group-Lock (3076/85): Used to specify which tunnel-group the user is allowed to log in to. If the user tries to log in to a different group, the session will be disconnect after Xauth. This attribute works for both IPsec and SSL VPN.

• Class (RADIUS IETF Attribute 25): Used to specify the group-policy name to apply to the user. This is another form of group lock but, unlike the Tunnel-Group-Lock attribute, it does not disconnect the user if the user tries to log in to a different group. This attribute will simply apply the correct group-policy irrespective of the tunnel-group the user connects to. This attribute works for both IPsec and SSL VPN. The value of this attribute has to be in the following format:

OU=group-policy-name;

• Downloadable Access List: You can use the Downloadable IP ACLs feature in ACS for VPN. When configured for a user or group of users, these ACLs will be downloaded on ASA and applied on a per-connection basis as VPN filters. This will restrict the traffic that can be initiated by the client to the network. See Chapter 10, “Cut-Through Proxy AAA on PIX/ASA,” for more details on configuring downloadable ACLs.

A complete list of supported Cisco VPN 3000/ASA 7.x attributes for VPN on ASA can be found at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ref_extserver.html#wp1605508.

A complete list of supported RADIUS IETF attributes for VPN on ASA can be found at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ref_extserver.html#wp1773486.

You already know how to add users and configure RADIUS attributes in ACS 4.2 and 5.1 from previous chapters. If you cannot recall the steps, see Chapter 6 for the steps to add a user and Chapter 8 for the steps to add attributes for users and groups.

Verifying and Troubleshooting VPN Authorization

When troubleshooting VPN authorization, the following problems are most commonly seen:

• Attribute value incorrect: An incorrect value or reference to nonexistent objects, such as address pools, will cause ASA to ignore the attribute. You should ensure that the values are correct and objects are present on the ASA.

• Downloadable ACLs on ASA will only work with ACS 4.0 and later: If you are using an earlier version, ASA will not be able to download the ACL from ACS. You will need to use Cisco-av-pair to define the ACL. Use the show access-list command on ASA to verify that the downloaded ACL is present in the configuration.

• Attribute not supported by VPN type: Certain attributes are meant for certain types of VPNs. Ensure that the VPN type supports the attribute you are configuring.

The following commands are useful when troubleshooting VPN authorization:

• debug radius: This command shows debugs of the RADIUS communication between the ASA and the RADIUS server that includes the attributes received from the RADIUS server. If authorization results are not as desired, these debugs will help verify the attributes that were received from the server.

• debug crypto isakmp: This command shows debugs of Internet Key Exchange (IKE) events. Xauth- and MODECFG-related events are also part of these debugs. You can use these debugs in combination with RADIUS debugs to find out whether there are problems during MODECFG.

• debug webvpn: This command shows debugs of events and errors related to WebVPN. You can use these debugs along with RADIUS debugs to find out whether authorization is failing or WebVPN configuration is incorrect.

• debug aaa authorization: This commands shows information regarding the authorization process. You can use this debug along with RADIUS and crypto/webvpn debugs to see the entire sequence of events starting from session establishment.

Accounting for IPsec and SSL VPN Using RADIUS

ASA enables you to send accounting information for IPsec Remote Access and SSL VPN sessions. When accounting is configured, ASA sends the following information for both IPsec and SSL VPN:

• Session ID

• Session Time

• Input Octets

• Output Octets

• Input packets

• Output Packets

• Framed-IP-Address (sends the address assigned to the client, where relevant)

To configure accounting, add the following command in the tunnel-group general-attributes section:

accounting-server-group group-tag

ASA sends start and stop accounting packets by default. This behavior cannot be changed.

Lab Scenario # 16: VPN AAA Using RADIUS

ABC Inc. has IPsec Remote Access VPN configured on its ASA. Currently it is using the ASA’s local database to authenticate users and assign group policies. It now wants to use its ACS server to authenticate users.

Split-tunneling is disabled for the VPN sessions. For the ACS group named Admins, the company wants to allow the users to have access to their local LAN.

The tunnel-group used on the ASA is named officevpn.

Lab Setup

The lab scenario requires an ASA, at least one Layer 2 switch, ACS, and a host with Cisco VPN client. Figure 13-1 shows the setup required.

Figure 13-1. Setup for Lab Scenario #16

Before proceeding with this lab, add the ASA as a client in ACS with the key set to cisco123. If you are using ACS 4.2, rename a group as Admins. If you are using ACS 5.1, create an identity group named Admins. You can use the default RADIUS Access Service or create a new one. The Identity policy can be left as default (Internal Users). You also need to create an authorization rule in the Access Service. This rule should match the Admins identity group. You should also apply the following initial configuration on the ASA:

Lab Solution

The following solution provides steps for both ACS version 4.2 and version 5.1:

Step 1. Add the ACS server on the ASA:

ASA(config)#aaa-server labserver protocol radius
ASA(config-aaa-server-group)#exit
ASA(config)#aaa-server labserver host 192.168.1.22 cisco123

Step 2. Configure the ASA for Xauth using ACS:

ASA(config)#tunnel-group officevpn general-attributes
ASA(config-tunnel-general)#authentication-server-group labservers

Step 3. (For ACS 4.2 only) Add the IPSec-Split-Tunneling-Policy attribute to the group:

Enable the IPsec-Split-Tunneling-Policy attribute from Interface Configuration > RADIUS (Cisco VPN 3000/ASA/PIX 7.x+) for the Group level.

Select Admins group from Group Setup and click Edit Settings.

Scroll down to RADIUS (Cisco VPN 3000/ASA/PIX 7.x+) section and select IPsec-Split-Tunneling-Policy. In the drop-down list, select Tunnel Everything except Local-LAN.

Click Submit+Restart.

Step 4. (For ACS 5.1 only) Create an authorization profile:

Authorization profiles can be created from Policy Elements > Authorization and Permissions > Network Access > Authorization Profiles.

The authorization profile should have the following RADIUS-Cisco VPN 3000/ASA/PIX 7.x attribute:

CVPN3000/ASA/PIX7.x-IPSec-Split-Tunneling-Policy with Static value set to Local LAN permitted.

Step 5. (For ACS 5.1 only) Apply the authorization profile created in step 4 to the authorization rule created during Lab Setup.

Lab Verification

To verify the solution, create a user in the Admins Group/Identity Group in ACS. Create a new connection on the VPN Client according to the tunnel-group on the ASA and connect. When prompted for Xauth, authenticate with the user you created. The authentication should succeed and you should have access to the local LAN even when connected to the VPN.

Authenticating IPsec and SSL VPN Using LDAP

Most enterprises today use some kind of directory services, such as Microsoft Active Directory, for centralized account management. These directory services can be used for authentication and authorization of various services and usually support Lightweight Directory Access Protocol (LDAP) for access. Cisco ACS supports such directory services as external databases for user accounts. ASA supports authentication with such directory services using LDAP in case you do not have a RADIUS server or your RADIUS server does not support external databases.

This section looks at authenticating VPN sessions using LDAP. Microsoft Active directory is used as the LDAP server for this section and the next; however, the concepts and configuration discussed here can be applied to any LDAP server.

The first and most important step in configuring authentication with LDAP is to define the server. To define the server, you create a server group and then add the server in the group using the following commands:

aaa-server group-tag protocol ldap
aaa-server group-tag [if_name] host {server_ip_address | server_name}

The second command will bring you to the aaa-server-host configuration mode. In this mode, you need to define the parameters that ASA will use to communicate with the LDAP server. You will need to configure the following parameters at the least:

• ldap-login-dn: The Distinguished Name (DN) for the admin account or any account in the directory that can log in, search, and retrieve account information from the directory. ASA will log in to the directory using this account to search for the user. For most LDAP servers, this should be the complete DN of the account.

• ldap-login-password: The password of the account configured as the ldap-login-dn.

• ldap-base-dn: This specifies the starting point for the user search. This can be the base DN of the directory itself.

• ldap-naming-attribute: This is the relative DN attribute that uniquely identifies a user account in the directory. Microsoft Active Directory uses sAMAccountName. Other common naming attributes are CN and UID.

• ldap-scope: This defines whether ASA will look at the base DN level or go below the base DN level to search for the user accounts.

• server-port: This defines the port the server is listening on. By default, port 389 is used.

Example 13-3 shows an LDAP host configuration.

Example 13-3. LDAP Host Configuration

After the LDAP server group is configured, it can be used as an authentication server group in a tunnel-group using the following commands:

tunnel-group group-name general-attributes
authentication-server-group group-tag

Verifying and Troubleshooting VPN Authentication Using LDAP

If VPN authentication fails with LDAP, but works with local users, you can use the debug ldap 255 command to troubleshoot the communication between ASA and LDAP. In an attempt to authenticate the user, ASA tries to bind to the LDAP server twice. The first time, it tries to bind as the user specified by the ldap-login-dn command. If this bind is not successful, debug output will be similar to that shown in Example 13-4. This shows that either the login DN is invalid or a wrong password has been configured. One thing you should be certain about is the complete DN of the login account.

Example 13-4. debug Output for a Failed LDAP Admin Bind

After the first bind is successful, ASA will attempt to search the LDAP server for the user as per the configuration. The debug output in Example 13-5 shows an unsuccessful search. If authentication is failing at this stage, ensure that the base DN, naming attribute, and the scope are correct.

Example 13-5. debug Output for an Unsuccessful LDAP Search

If this search is successful, ASA retrieves the complete DN of the user and attempts to bind to the LDAP server again, using the user’s DN and the password provided by the user. If the authentication fails at this stage, the password provided by the user is incorrect. Upon successful authentication, ASA will retrieve all the attributes from the user profile that can be used for authorization.

Authorizing IPsec and SSL VPN Using LDAP

After a successful LDAP authentication, ASA queries the server for the user profile that contains various attributes. These attributes vary from server to server and are not understood by ASA. To use them for authorization, you need to map them to RADIUS attributes that can be used for VPN authorization.

LDAP attributes are mapped to RADIUS attributes using LDAP attribute maps. These maps are a list of mapping between LDAP and RADIUS attributes and values.

To better understand how LDAP attribute-maps work, consider the output in Example 13-6. This output, from the debug ldap 255 command, shows some of the attributes received from an LDAP server on successful authentication.

Example 13-6. LDAP Attributes Received After Authentication

Earlier in the chapter you learned that based on group membership in ACS you can restrict the tunnel-group that can be used by the user. This is done by using Cisco VPN 3000/ASA 7.x attribute 85 (Tunnel-Group-Lock). Similarly, to restrict an LDAP user to a tunnel-group, you can map any LDAP attribute, such as the memberOf attribute shown in Example 13-6, to the RADIUS Tunnel-Group-Lock attribute. Based on the value of the LDAP attribute, a value can be assigned to the mapped RADIUS attribute and applied to the VPN session.

You can create an LDAP attribute-map using the following command:

ldap attribute-map map-name

This command will put you in the ldap-attribute-map configuration mode. You can create a new mapping here using the following command:

map-name LDAP-attribute RADIUS-attribute

After you have created a map, you also need to map the values between the LDAP and RADIUS attributes. This can be done using the following command:

map-value LDAP-attribute LDAP-value RADIUS-value

The map-value command tells the ASA to assign RADIUS-value to the RADIUS-attribute, defined in the map-name command, if the value of the LDAP-attribute is equal to LDAP-value in the user profile.

Example 13-7 shows an LDAP attribute-map that maps the LDAP memberOf attribute to the RADIUS Tunnel-Group-Lock. In this example, if the value of the memberOf attribute is equal to the specified value, the user will be locked to the remvpn tunnel-group.

Example 13-7. LDAP attribute-map

After creating the LDAP attribute-map, you need to apply the map to the AAA server group that is being used by the tunnel-group for authentication using the following commands:

aaa-server group-tag host {server-ip-address | server-name}
ldap-attribute-map map-name

Almost any RADIUS attribute can be used in an LDAP attribute map. A list of all the RADIUS attributes supported for LDAP mapping can be found at the following link: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ref_extserver.html#wp1773708.

Verifying and Troubleshooting VPN Authorization with LDAP

When troubleshooting VPN authorization with LDAP, the most useful command is debug ldap 255. Of particular interest in the debug are the lines where the mapped LDAP attributes are shown. The debug will show whether the attribute received from the server was successfully mapped to a RADIUS attribute, as shown in Example 13-8.

Example 13-8. debug LDAP Showing Mapped Attributes

If the debug output does not show a successful mapping, the LDAP attribute-map is not properly configured. The attribute names are case sensitive; so you should consider copying and pasting the attribute name and value from the debug itself. Apart from this potential for error, ensure that the following items are true:

• The RADIUS attribute that you are trying to use is supported by the VPN type.

• The objects referenced in the RADIUS value, such as IP pool names, exist on the ASA.

Lab Scenario # 17: VPN Authentication and Authorization Using LDAP

ABC Inc. has IPsec Remote Access VPN configured on its ASA. Currently the company is using the ASA’s local database to authenticate users and assign group policies. It now wants to use Active Directory to authenticate users using LDAP.

Split-tunneling is disabled for the VPN sessions. For users belonging to LDAP group CN=Domain Admins,CN=Users,DC=abc,DC=com, the company wants to allow the users to have access to their local LAN. The group membership is defined by the memberOf attribute.

The tunnel-group used on the ASA is named officevpn. The base DN of the LDAP server is DC=abc,DC=com. The login DN to be used is cn=admin,cn=Users,dc=abc,dc=com with a password of ldappass. The user accounts are defined by the naming attribute of sAMAccountName.

Lab Setup

The Lab Scenario requires an ASA, at least one Layer 2 switch, an LDAP server (preferably a Microsoft Active Directory domain controller), and a host with a Cisco VPN Client. Figure 13-2 shows the setup required.

Figure 13-2. Setup for Lab Scenario #17

If you are not using an Active Directory domain controller as an LDAP server, use any group from your LDAP server instead of the group given in the Objective. You will also need to use your own LDAP parameters.

You should also apply the following initial configuration on ASA:

Lab Solution

Step 1. Add the LDAP server on ASA:

Step 2. Create an LDAP attribute-map for authorization:

Step 3. Apply the attribute-map to the server group:

ASA(config)#aaa-server labserver host 192.168.1.22
ASA(config-aaa-server-host)#ldap-attribute-map vpnmap

Step 4. Enable Xauth on the tunnel-group:

ASA(config)#tunnel-group officevpn general-attributes
ASA(config-tunnel-general)#authentication-server-group labserver

Lab Verification

To verify the solution, create a user in the Domain Admins group in LDAP Server. Create a new connection on the VPN Client according to the tunnel-group on the ASA and connect. When prompted for Xauth, authenticate with the user you created. The authentication should succeed and you should have access to the local LAN even when connected to the VPN.

Summary

This chapter covered AAA in regard to IPsec and SSL VPN on ASA. You must have noticed that, as in the previous chapter, this chapter also shows the importance of attributes in VPN authorization.

ASA has more options for authorization compared to IOS that can be used to design your security policies and exceptions on per-user or per-group basis. You should look at the various attributes available in the links provided throughout the chapter because this will help you decide the kind of user or group policy you want for VPN connections.