Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6

Restrictions

By default, the ASA permits all portal traffic to all web resources (e.g., HTTPS, CIFS, RDP, and plug-ins). The ASA clientless service rewrites each URL to one that is meaningful only to itself; the user cannot use the rewritten URL displayed on the page accessed to confirm that they are on the site they requested. To avoid placing users at risk, assign a web ACL to the policies configured for clientless access – group-policies, dynamic access policies, or both – to control traffic flows from the portal. For example, without such an ACL, users could receive an authentication request from an outside fraudulent banking or commerce site. Also, we recommend disabling URL Entry on these policies to prevent user confusion over what is accessible.

Figure 72-1 Example URL Typed by User

Figure 72-2 Same URL Rewritten by Security Appliance and displayed on the Browser Window

Detailed Steps

We recommend that you do the following to minimize risks posed by clientless SSL VPN access:

Step 1 Configure a group policy for all users who need clientless SSL VPN access, and enable clientless SSL VPN only for that group policy.

Step 2 With the group policy open, choose General > More Options > Web ACL and click Manage.

Step 3 Create a web ACL to do one of the following: permit access only to specific targets within the private network, permit access only to the private network, deny Internet access, or permit access only to reputable sites.

Step 4 Assign the web ACL to any policies (group policies, dynamic access policies, or both) that you have configured for clientless access. To assign a web ACL to a DAP, edit the DAP record, and select the web ACL on the Network ACL Filters tab.

Step 5 Disable URL entry on the portal page, the page that opens upon the establishment of a browser-based connection. To do so, click Disable next to URL Entry on both the group policy Portal frame and the DAP Functions tab. To disable URL entry on a DAP, use ASDM to edit the DAP record, click the Functions tab, and check Disable next to URL Entry

Step 6 Instruct users to enter external URLs in the native browser address field above the portal page or open a separate browser window to visit external sites.

Detailed Steps

Step 1 Choose the Configuration > VPN > General > Group Policy >Add/Edit >WebVPN pane. Then choose the Configuration > Properties >Device Administration >User Accounts > VPN Policy pane to assign the group policy to a user.

Step 2 Enable or disable clientless SSL VPN connections on configured ASA interfaces.

The Interface field displays the names of all configured interfaces. The WebVPN Enabled field displays the current status for clientless SSL VPN on the interface. (A green check next to Yes indicates that clientless SSL VPN is enabled. A red circle next to No indicates that clientless SSL VPN is disabled.

Step 3 Enter the port number that you want to use for clientless SSL VPN sessions. The default port is 443, for HTTPS traffic; the range is 1 through 65535. If you change the port number, all current clientless SSL VPN connections terminate, and current users must reconnect. You also lose connectivity to ASDM, and a prompt displays, inviting you to reconnect.

Step 4 Enter the amount of time, in seconds, that a clientless SSL VPN session can be idle before the ASA terminates it. This value applies only if the Idle Timeout value in the group policy for the user is set to zero (0), which means there is no timeout value; otherwise the group policy Idle Timeout value takes precedence over the timeout you configure here. The minimum value you can enter is 1 minute. The default is 30 minutes (1800 seconds). Maximum is 24 hours (86400 seconds).

We recommend that you set this attribute to a short time period. A browser set to disable cookies (or one that prompts for cookies and then denies them) can result in a user not connecting but nevertheless appearing in the sessions database. If the Simultaneous Logins attribute for the group policy is set to one, the user cannot log back in because the database indicates that the maximum number of connections already exists. Setting a low idle timeout removes such phantom sessions quickly, and lets a user log in again.

Step 5 Enter the maximum number of clientless SSL VPN sessions you want to allow. Be aware that the different ASA models support clientless SSL VPN sessions as follows: ASA 5510 supports a maximum of 250; ASA 5520 maximum is 750; ASA 5540 maximum is 2500; ASA 5550 maximum is 5000.

Step 6 Enter the percent of total memory or the amount of memory in kilobytes that you want to allocate to clientless SSL VPN processes. The default is 50% of memory. Be aware that the different ASA models have different total amounts of memory as follows: ASA 5510—256 MB; ASA5520 —512 MB: ASA 5540—1GB, ASA 5550—4G. When you change the memory size, the new setting takes effect only after the system reboots.

Step 7 In the WebVPN Memory field, choose to allocate memory for clientless SSL VPN either as a percentage of total memory or as an amount of memory in kilobytes.

Step 8 Click to include a drop-down list of configured tunnel groups on the clientless SSL VPN end-user interface. Users select a tunnel group from this list when they log on. This field is checked by default. If you uncheck it, the user cannot select a tunnel group at logon.

Disabling URL on the Portal Page

The portal page is the page that opens when the user establishes a browser-based connection. Follow these steps to disable the URL entry on the portal page.

Prerequisites

• Configure a group policy for all users who need clientless SSL VPN access, and enable clientless SSL VPN only for that group policy.
• Create a web ACL to either permit access only to specific targets within the private network, permit access only to the private network, deny Internet access, or permit access only to reputable sites.
• Assign the web ACL to any policies (group policies, dynamic access policies, or both) that you have configured for clientless access.

Detailed Steps

Using HTTPS for Clientless SSL VPN Sessions

To permit clientless SSL VPN sessions on an interface, perform the following steps:

Prerequisites

In a web browser, users enter the ASA IP address in the format https:// address where address is the IP address or DNS hostname of the ASA interface.

Restrictions

• You must enable clientless SSL VPN sessions on the ASA interface that users connect to.
• You must use HTTPS to access the ASA or load balancing cluster.

Configuring Clientless SSL VPN and ASDM Ports

Beginning with Version 8.0(2), the ASA supports both clientless SSL VPN sessions and ASDM administrative sessions simultaneously on Port 443 of the outside interface. You do, however, have the option to configure these applications on different interfaces.

Configuring Support for Proxy Servers

The ASA can terminate HTTPS connections and forward HTTP and HTTPS requests to proxy servers. These servers act as intermediaries between users and the Internet. Requiring Internet access via a server that the organization controls provides another opportunity for filtering to assure secure Internet access and administrative control.

When configuring support for HTTP and HTTPS proxy services, you can assign preset credentials to send with each request for basic authentication. You can also specify URLs to exclude from HTTP and HTTPS requests.

Restrictions

You can specify a proxy autoconfiguration (PAC) file to download from an HTTP proxy server, however, you may not use proxy authentication when specifying the PAC file.

The ASA clientless SSL VPN configuration supports only one http-proxy and one http-proxy command each. For example, if one instance of the http-proxy command is already present in the running configuration and you enter another, the CLI overwrites the previous instance.

Note Proxy NTLM authentication is not supported in http-proxy. Only proxy without authentication and basic authentication are supported.

Configuring SSL/TLS Encryption Protocols

Prerequisites

TCP Port Forwarding requires Sun Microsystems Java Runtime Environment (JRE) version 1.4.x and 1.5.x. Port forwarding does not work when a user of clientless SSL VPN connects with some SSL versions, as follows:

• Negotiate SSLv3—Java downloads
• Negotiate SSLv3/TLSv1—Java downloads
• Negotiate TLSv1—Java does NOT download
• TLSv1 Only—Java does NOT download
• SSLv3Only—Java does NOT download

Restrictions

When you set SSL/TLS encryption protocols, be aware of the following:

• Make sure that the ASA and the browser you use allow the same SSL/TLS encryption protocols.
• If you configure e-mail proxy, do not set the ASA SSL version to TLSv1 Only. Microsoft Outlook and Microsoft Outlook Express do not support TLS.

Prerequisites

Browser cookies are required for the proper operation of clientless SSL VPN.

Configuring ACLs

You can configure ACLs (access control lists) to apply to user sessions. These ACLs filter user access to specific networks, subnets, hosts, and web servers. The Web ACLs table displays the filters configured on the ASA application to the clientless SSL VPN traffic. The table shows the name of each access control list (ACL), and below and indented to the right of the ACL name, the ACEs (access control entries) assigned to the ACL.

Each ACL permits or denies access permits or denies access to specific networks, subnets, hosts, and web servers. Each ACE specifies one rule that serves the function of the ACL.

Guidelines

If you do not define any filters, all connections are permitted.

Restrictions

• The ASA supports only an inbound ACL on an interface.
• At the end of each ACL, there is an implicit, unwritten rule that denies all traffic that is not permitted. If traffic is not explicitly permitted by an ACE (access control entry), the ASA denies it. ACEs are referred to as rules in this topic.

Detailed Steps

You can add and edit ACLs to be used for clientless SSL VPN sessions with the following functions:

• Click Add ACL to add an ACL or ACE. To insert a new ACE before or after an existing ACE, click Insert or Insert After.
• Click Edit to highlight the ACE you want to change.
• Highlight the ACL or ACE you want to remove and click Delete. When you delete an ACL, you must delete all of its ACEs. No warning or undelete.
• Use the Move Up and Move Down buttons to change the order of ACLs or ACEs. The ASA checks ACLs to be applied to clientless SSL VPN sessions and their ACEs in the sequence determined by their position in the ACLs list until it finds a match.
• Click + to expand or - to collapse the list of ACEs under each ACL. The priority of the ACEs under each ACL is displayed. The order in the list determines priority.
• (Optional) Click Find to search for a web ACL. Start typing in the field, and the tool searches the beginning characters of every field for a match. You can use wild cards to expand your search. For example, typing sal in the Find field matches a web ACL named sales but not a customization object named wholesalers. If you type *sal in the Find field, the search finds the first instance of either sales or wholesalers in the table.

Use the up and down arrows to skip up or down to the next string match. Check the Match Case checkbox to make your search case sensitive.

• (Optional) Highlight a web ACL and click Assign to assign the selected web ACL to one or more VPN group policies, dynamic access policies, or user policies.
• When you create an ACE, by default it is enabled. Clear the check box to disable an ACE.

The IP address or URL of the application or service to which the ACE applies is displayed. The TCP service to which the ACE applies is also displayed. The Action field displays whether the ACE permits or denies clientless SSL VPN access. The time range associated with the ACE and the logging behavior (either disabled or with a specified level and time interval) is also displayed.

Adding or Editing ACEs

An Access Control Entry (or “access rule”) permits or denies access to specific URLs and services. You can configure multiple ACEs for an ACL. ACLs apply ACEs in priority order, acting on the first match.

Detailed Steps

Step 1 Permit or deny access to specific networks, subnets, hosts, and web servers specified in the Filter group field.

Step 2 Specify a URL or an IP address to which you want to apply the filter (permit or deny user access):

• URL—Applies the filter to the specified URL.
• Protocols (unlabeled)—Specifies the protocol part of the URL address.
• ://x—Specifies the URL of the Web page to which to apply the filter.
• TCP—Applies the filter to the specified IP address, subnet, and port.
• IP Address—Specifies the IP address to which to apply the filter.
• Netmask—Lists the standard subnet mask to apply to the address in the IP Address field.
• Service—Identifies the service (such as https, kerberos, or any) to be matched. Displays a list of services from which you can select the service to display in the Service field.
• Boolean operator (unlabeled)—Lists the boolean conditions (equal, not equal, greater than, less than, or range) to use in matching the service specified in the service field.

Step 3 The Rule Flow Diagram graphically depicts the traffic flow using the filter. This area may be hidden.

Step 4 Specify the logging rules. The default is Default Syslog.

• Logging—Choose enable if you want to enable a specific logging level.
• Syslog Level—Grayed out until you select Enable for the Logging attribute. Lets you select the type of syslog messages you want the ASA to display.
• Log Interval—Lets you select the number of seconds between log messages.
• Time Range—Lets you select the name of a predefined time-range parameter set.
• ...—Click to browse the configured time ranges or to add a new one.

Configuration Examples for ACLs for Clientless SSL VPN

Examples

Here are examples of ACLs for clientless SSL VPN:

Authenticating with Digital Certificates

SSL uses digital certificates for authentication. The ASA creates a self-signed SSL server certificate when it boots; or you can install in the ASA an SSL certificate that has been issued in a PKI context. For HTTPS, this certificate must then be installed on the client. You need to install the certificate from a given ASA only once.

Restrictions

• Application Access does not work for users of clientless SSL VPN who authenticate using digital certificates. JRE does not have the ability to access the web browser keystore. Therefore JAVA cannot use a certificate that the browser uses to authenticate a user, so it cannot start.
• E-mail clients such as MS Outlook, MS Outlook Express, and Eudora lack the ability to access the certificate store.

For more information on authentication and authorization using digital certificates, see the “Using Certificates and User Login Credentials” section.

Enabling Cookies on Browsers for Clientless SSL VPN

When cookies are disabled on the web browser, the links from the web portal home page open a new window prompting the user to log in once more.

Configuring the Setup for Cisco Secure Desktop

The Cisco Secure Desktop Setup window displays the version and state of the Cisco Secure Desktop image if it is installed on the ASA, indicates whether it is enabled, and shows the size of the cache used to hold the Cisco Secure Desktop and SSL VPN Client on the ASA.

You can use the buttons in this window as follows:

To transfer a copy of a Cisco Secure Desktop image from your local computer to the flash device of the ASA, click Upload.

To prepare to install or upgrade Cisco Secure Desktop, use your Internet browser to download a securedesktop_asa_< n >_< n >*.pkg file from http://www.cisco.com/cgi-bin/tablebuild.pl/securedesktop to any location on your PC. Then use this button to transfer a copy from your local computer to the flash device. Click Browse Flash to install it into the running configuration. Finally, click Enable Secure Desktop.

• To install or replace the Cisco Secure Desktop image on the flash device of the ASA, click Browse Flash.

Note If you click Browse Flash to upgrade or downgrade the Cisco Secure Desktop image, select the package to install, and click OK, the Uninstall Cisco Secure Desktop dialog window asks you if you want to delete the Cisco Secure Desktop distribution currently in the running configuration from the flash device. Click Yes if you want to save space on the flash device, or click No to reserve the option to revert to this version of Cisco Secure Desktop.

• To remove the Cisco Secure Desktop image and configuration file (sdesktop/data.xml) from the running configuration, click Uninstall.

If you click this button, the Uninstall Cisco Secure Desktop dialog window asks if you want to delete the Cisco Secure Desktop image that was named in the “Secure Desktop Image field” and all Cisco Secure Desktop data files (including the entire Cisco Secure Desktop configuration) from the flash device. Click Yes if you want to remove these files from both the running configuration and the flash device, or click No to remove them from the running configuration, but retain them on the flash device.

Detailed Steps

The Cisco Secure Desktop image loaded into the running configuration is displayed in the Location field. By default, the filename is in the format securedesktop_asa_<n>_<n>*.pkg.

Step 1 Click Browse Flash to insert or modify the value in this field.

Step 2 Click Enable Secure Desktop and click Apply to do the following:

a. Make sure the file is a valid Cisco Secure Desktop image.

b. Create an “sdesktop” folder on disk0 if one is not already present.

c. Insert a data.xml (Cisco Secure Desktop configuration) file into the sdesktop folder if one is not already present.

d. Load the data.xml file into the running configuration.

Note If you transfer or replace the data.xml file, disable and then enable Cisco Secure Desktop to load the file.

e. Enable Cisco Secure Desktop.

Uploading Images

The Upload Image dialog box lets you transfer a copy of a Cisco Secure Desktop image from your local computer to the flash device on the ASA. Use this window to install or upgrade Cisco Secure Desktop.

Prerequisites

• Before using this window, use your Internet browser to download a securedesktop_asa_< n >_< n >*.pkg file from http://www.cisco.com/cgi-bin/tablebuild.pl/securedesktop to any location on your local computer.

Detailed Steps

You can use the buttons in this window as follows:

• To choose the path of the securedesktop_asa_< n >_< n >*.pkg file to be transferred, click Browse Local Files. The Selected File Path dialog box displays the contents of the folder you last accessed on your local computer. Navigate to the securedesktop_asa_< n >_< n >*.pkg file, select it, and click Open.
• To select the target directory for the file, click Browse Flash. The Browse Flash dialog box displays the contents of the flash card.
• To uploads the securedesktop_asa_< n >_< n >*.pkg file from your local computer to the flash device, click Upload File. A Status window appears and remains open for the duration of the file transfer. Following the transfer, an Information window displays the message, “File is uploaded to flash successfully.” Click OK. The Upload Image dialog box removes the contents of the Local File Path and Flash File System Path fields.
• To close the Upload Image dialog box, click Close. Click this button after you upload the Cisco Secure Desktop image to the flash device or if you decide not to upload it. If you uploaded it, the filename appears in the Secure Desktop Image field of the Cisco Secure Desktop Setup window. If you did not upload it, a Close Message dialog box prompts, “Are you sure you want to close the dialog without uploading the file?” Click OK if you do not want to upload the file. The Close Message and Upload Image dialog boxes close, revealing the Cisco Secure Desktop Setup pane. Otherwise, click Cancel in the Close Message dialog box. The dialog box closes, revealing the Upload Image dialog box again, with the values in the fields intact. Click Upload File.

Step 1 Specify the path to the securedesktop_asa_< n >_< n >*.pkg file on your local computer. Click Browse Local to automatically insert the path in this field, or enter the path. For example:

D:\Documents and Settings\ Windows_user_name.AMER\My Documents\My Downloads\securedesktop_asa_3_1_1_16.pkg

ASDM inserts the file path into the Local File Path field.

Step 2 Specify the destination path on the flash device of the ASA and the name of the destination file. Click Browse Flash to automatically insert the path into this field, or enter the path. For example:

disk0:/securedesktop_asa_3_1_1_16.pkg

The file name of the Cisco Secure Desktop image that you selected on your local computer is displayed in the Browse Flash dialog box. We recommend that you use this name to prevent confusion. Confirm that this field displays the same name of the local file you selected and click OK. The Browse Flash dialog box closes. ASDM inserts the destination file path into the Flash File System Path field.

Detailed Steps

Step 1 Information about the location of the APCF package is displayed. The locations include the ASA flash memory or an HTTP, HTTPS, FTP, or TFTP server.

Step 2 (Optional) Click Add/Edit to create a new APCF profile or change an existing one.

Step 3 (Optional) Click Delete to remove an existing APCF profile. No confirmation or undo exists.

Step 4 Use the Move Up option to rearrange APCF profiles within a list. The list determines the order in which the ASA attempts to use APCF profiles.

Step 5 Click Flash file to locate an APCF file stored on the ASA flash memory.

Step 6 You can browse to locate the path to an APCF file stored on flash memory or manually enter the path.

Step 7 Click to browse flash memory to locate the APCF file. A Browse Flash Dialog pane displays. Use the Folders and Files columns to locate the APCF file. Highlight the APCF file and click OK. The path to the file then displays in the Path field.

Step 8 (Optional) Click Refresh if you do not see the name of an APCF file that you recently downloaded.

Step 9 Click Upload to get an APCF file from a local computer to the ASA flash file system. The Upload APCF package pane displays.

Step 10 Click URL to use an APCF file stored on an HTTP, HTTPS or TFTP server.

Step 11 Enter the path to the FTP, HTTP, HTTPS, or TFTP server. The server types are identified.

Uploading APCF Packages

Detailed Steps

Step 1 The path to the APCF file on your computer is shown. Click Browse Local to automatically insert the path in this field, or enter the path.

Step 2 Click to locate and choose the APCF file on your computer that you want to transfer. The Select File Path dialog box displays the contents of the folder you last accessed on your local computer. Navigate to the APCF file, choose it, and click Open. ASDM inserts the file path into the Local File Path field.

Step 3 The path on the ASA to upload the APCF file is shown in the Flash File System Path. Click Browse Flash to identify the location on the ASA to which you want to upload the APCF file. The Browse Flash dialog box displays the contents of flash memory.

Step 4 The file name of the APCF file you selected on your local computer is displayed. We recommend that you use this name to prevent confusion. Confirm that this file displays the correct filename, and click OK. The Browse Flash dialog box closes. ASDM inserts the destination file path in the Flash File System Path field.

Step 5 Click Upload File when you have identified the location of the APCF file on your computer, and the location where you want to download it to the ASA.

Step 6 A Status window appears and remains open for the duration of the file transfer. Following the transfer, an Information window displays the message, “File is uploaded to flash successfully.” Click OK. The Upload Image dialog window removes the contents of the Local File Path and Flash File System Path fields, indicating you can upload another file. To do so, repeat these instructions. Otherwise, click Close.

Step 7 Close the Upload Image dialog window. Click Close after you upload the APCF file to flash memory or if you decide not to upload it. If you do upload it, the filename appears in the APCF File Location field of the APCF window. If you do not upload it, a Close Message dialog box prompts, “Are you sure you want to close the dialog without uploading the file?” Click OK if you do not want to upload the file. The Close Message and Upload Image dialog boxes close, revealing the APCF Add/Edit pane. Otherwise, click Cancel in the Close Message dialog box. The dialog box closes, revealing the Upload Image dialog box again, with the values in the fields intact. Click Upload File.

Managing Passwords

Optionally, you can configure the ASA to warn end users when their passwords are about to expire.

The ASA supports password management for the RADIUS and LDAP protocols. It supports the “password-expire-in-days” option for LDAP only.

You can configure password management for IPsec remote access and SSL VPN tunnel-groups.

When you configure password management, the ASA notifies the remote user at login that the user’s current password is about to expire or has expired. The ASA then offers the user the opportunity to change the password. If the current password has not yet expired, the user can still log in using that password.

This command is valid for AAA servers that support such notification.

The ASA, releases 7.1 and later, generally supports password management for the following connection types when authenticating with LDAP or with any RADIUS configuration that supports MS-CHAPv2:

• AnyConnect VPN Client
• IPsec VPN Client
• Clientless SSL VPN

The RADIUS server (for example, Cisco ACS) could proxy the authentication request to another authentication server. However, from the ASA perspective, it is talking only to a RADIUS server.

Prerequisites

• Native LDAP requires an SSL connection. You must enable LDAP over SSL before attempting to do password management for LDAP. By default, LDAP uses port 636.
• If you are using an LDAP directory server for authentication, password management is supported with the Sun Microsystems JAVA System Directory Server (formerly named the Sun ONE Directory Server) and the Microsoft Active Directory.
  
  Sun—The DN configured on the ASA to access a Sun directory server must be able to access the default password policy on that server. We recommend using the directory administrator, or a user with directory administrator privileges, as the DN. Alternatively, you can place an ACI on the default password policy.
  
  
  Microsoft—You must configure LDAP over SSL to enable password management with Microsoft Active Directory.

Restrictions

• Some RADIUS servers that support MSCHAP currently do not support MSCHAPv2. This command requires MSCHAPv2 so check with your vendor.
• Password management is not supported for any of these connection types for Kerberos/Active Directory (Windows password) or NT 4.0 Domain.
• For LDAP, the method to change a password is proprietary for the different LDAP servers on the market. Currently, the ASA implements the proprietary password management logic only for Microsoft Active Directory and Sun LDAP servers.
• The ASA ignores this command if RADIUS or LDAP authentication has not been configured.

Detailed Steps

Note This command does not change the number of days before the password expires, but rather, the number of days ahead of expiration that the ASA starts warning the user that the password is about to expire.

Step 1 Navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles > Add or Edit > Advanced > General > Password Management.

Step 2 Click the Enable password management option.

Configuring SSO with HTTP Basic or NTLM Authentication

This section describes single sign-on with HTTP Basic or NTLM authentication. You can configure the ASA to implement SSO using either or both of these methods. The auto-signon command configures the ASA to automatically pass clientless SSL VPN user login credentials (username and password) on to internal servers. You can enter multiple auto-signon commands. The ASA processes them according to the input order (early commands take precedence). You specify the servers to receive the login credentials using either IP address and IP mask, or URI mask.

Use the auto-signon command in any of three modes: webvpn configuration, webvpn group-policy mode, or webvpn username mode. Username supersedes group, and group supersedes global. The mode you choose depends upon scope of authentication you want:

Detailed Steps

The following example commands present various possible combinations of modes and arguments.

Configuring SSO Authentication Using SiteMinder

This section describes configuring the ASA to support SSO with SiteMinder. You would typically choose to implement SSO with SiteMinder if your website security infrastucture already incorporates SiteMinder. With this method, SSO authentication is separate from AAA and happens once the AAA process completes.

Prerequisites

• Specifying the SSO server.
• Specifying the URL of the SSO server to which the ASA makes SSO authentication requests.
• Specifying a secret key to secure the communication between the ASA and the SSO server. This key is similar to a password: you create it, save it, and enter it on both the ASA and the SiteMinder Policy Server using the Cisco Java plug-in authentication scheme.

Optionally, you can do the following configuration tasks in addition to the required tasks:

• Configuring the authentication request timeout.
• Configuring the number of authentication request retries.

Restrictions

If you want to configure SSO for a user or group for clientless SSL VPN access, you must first configure a AAA server, such as a RADIUS or LDAP server. You can then set up SSO support for clientless SSL VPN.

Detailed Steps

This section presents specific steps for configuring the ASA to support SSO authentication with CA SiteMinder. To configure SSO with SiteMinder, perform the following steps:

Adding the Cisco Authentication Scheme to SiteMinder

In addition to configuring the ASA for SSO with SiteMinder, you must also configure your CA SiteMinder Policy Server with the Cisco authentication scheme, a Java plug-in you download from the Cisco web site.

Prerequisites

Configuring the SiteMinder Policy Server requires experience with SiteMinder.

Detailed Steps

This section presents general tasks, not a complete procedure. To configure the Cisco authentication scheme on your SiteMinder Policy Server, perform the following steps:

Step 1 With the SiteMinder Administration utility, create a custom authentication scheme, being sure to use the following specific arguments:

• In the Library field, enter smjavaapi.
• In the Secret field, enter the same secret configured on the ASA.

You configure the secret on the ASA using the policy-server-secret command at the command line interface.

• In the Parameter field, enter CiscoAuthApi.

Step 2 Using your Cisco.com login, download the file cisco_vpn_auth.jar from http://www.cisco.com/cisco/software/navigator.html and copy it to the default library directory for the SiteMinder server. This.jar file is also available on the Cisco ASA CD.

Configuring SSO Authentication Using SAML Browser Post Profile

This section describes configuring the ASA to support Security Assertion Markup Language (SAML), Version 1.1 POST profile Single Sign-On (SSO) for authorized users.

After a session is initiated, the ASA authenticates the user against a configured AAA method. Next, the ASA (the asserting party) generates an assertion to the relying party, the consumer URL service provided by the SAML server. If the SAML exchange succeeds, the user is allowed access to the protected resource. Figure 72-3 shows the communication flow:

Figure 72-3 SAML Communication Flow

Prerequisites

To configure SSO with an SAML Browser Post Profile, you must perform the following tasks:

• Specify the SSO server with the sso-server command.
• Specify the URL of the SSO server for authentication requests (the assertion-consumer-url command)
• Specify the ASA hostname as the component issuing the authentication request (the issuer command)
• Specify the trustpoint certificates use for signing SAML Post Profile assertions (the trustpoint command)

Optionally, in addition to these required tasks, you can do the following configuration tasks:

• Configure the authentication request timeout (the request-timeout command)
• Configure the number of authentication request retries (the max-retry-attempts command)

Restrictions

• SAML SSO is supported only for clientless SSL VPN sessions.
• The ASA currently supports only the Browser Post Profile type of SAML SSO Server.
• The SAML Browser Artifact method of exchanging assertions is not supported.

Detailed Steps

This section presents specific steps for configuring the ASA to support SSO authentication with SAML Post Profile. To configure SSO with SAML-V1.1-POST, perform the following steps:

Configuring the SAML POST SSO Server

Use the SAML server documentation provided by the server software vendor to configure the SAML server in Relying Party mode.The following steps list the specific parameters required to configure the SAML Server for Browser Post Profile:

Detailed Steps

Step 1 Configure the SAML server parameters to represent the asserting party (the ASA):

• Recipient consumer URL (same as the assertion consumer URL configured on the ASA)
• Issuer ID, a string, usually the hostname of appliance
• Profile type -Browser Post Profile

Step 2 Configure certificates.

Step 3 Specify that asserting party assertions must be signed.

Step 4 Select how the SAML server identifies the user:

• Subject Name Type is DN
• Subject Name format is uid=<user>

Configuring SSO with the HTTP Form Protocol

This section describes using the HTTP Form protocol for SSO. HTTP Form protocol is an approach to SSO authentication that can also qualify as a AAA method. It provides a secure method for exchanging authentication information between users of clientless SSL VPN and authenticating web servers. You can use it in conjunction with other AAA servers such as RADIUS or LDAP servers.

Prerequisites

To configure SSO with the HTTP protocol correctly, you must have a thorough working knowledge of authentication and HTTP protocol exchanges.

Restrictions

As a common protocol, it is applicable only when the following conditions are met for the web server application used for authentication:

• The web form must not have dynamic parameters that are relevant for authentication (such as parameters set by JavaScript or unique for each request).
• The authentication cookie must be set for successful request and not set for unauthorized logons. In this case, ASA cannot distinguish successful from failed authentication.

Detailed Steps

The ASA again serves as a proxy for users of clientless SSL VPN to an authenticating web server but, in this case, it uses HTTP Form protocol and the POST method for requests. You must configure the ASA to send and receive form data. Figure 72-4 illustrates the following SSO authentication steps:

Step 1 A user of clientless SSL VPN first enters a username and password to log into the clientless SSL VPN server on the ASA.

Step 2 The clientless SSL VPN server acts as a proxy for the user and forwards the form data (username and password) to an authenticating web server using a POST authentication request.

Step 3 If the authenticating web server approves the user data, it returns an authentication cookie to the clientless SSL VPN server where it is stored on behalf of the user.

Step 4 The clientless SSL VPN server establishes a tunnel to the user.

Step 5 The user can now access other websites within the protected SSO environment without reentering a username and password.

Figure 72-4 SSO Authentication Using HTTP Forms

While you would expect to configure form parameters that let the ASA include POST data such as the username and password, you initially might not be aware of additional hidden parameters that the web server requires. Some authentication applications expect hidden data which is neither visible to nor entered by the user. You can, however, discover hidden parameters the authenticating web server expects by making a direct authentication request to the web server from your browser without the ASA in the middle acting as a proxy. Analyzing the web server response using an HTTP header analyzer reveals hidden parameters in a format similar to the following:

Some hidden parameters are mandatory and some are optional. If the web server requires data for a hidden parameter, it rejects any authentication POST request that omits that data. Because a header analyzer does not tell you if a hidden parameter is mandatory or not, we recommend that you include all hidden parameters until you determine which are mandatory.

To configure SSO with the HTTP Form protocol, you must perform the following:

• Configure the uniform resource identifier on the authenticating web server to receive and process the form data ( action-uri).
• Configure the username parameter ( user-parameter).
• Configure the user password parameter ( password-parameter).

You might also need to do the following tasks depending upon the requirements of authenticating web server:

• Configure a starting URL if the authenticating web server requires a pre-login cookie exchange ( start-url).
• Configure any hidden authentication parameters required by the authenticating web server ( hidden-parameter).
• Configure the name of an authentication cookie set by the authenticating web server ( auth-cookie-name).

Gathering HTTP Form Data

This section presents the steps for discovering and gathering necessary HTTP Form data. If you do not know what parameters the authenticating web server requires, you can gather parameter data by analyzing an authentication exchange using the following steps:

Prerequisites

These steps require a browser and an HTTP header analyzer.

Detailed Steps

Step 1 Start your browser and HTTP header analyzer, and connect directly to the web server login page without going through the ASA.

Step 2 After the web server login page has loaded in your browser, examine the login sequence to determine if a cookie is being set during the exchange. If the web server has loaded a cookie with the login page, configure this login page URL as the start-URL.

Step 3 Enter the username and password to log in to the web server, and press Enter. This action generates the authentication POST request that you examine using the HTTP header analyzer.

An example POST request—with host HTTP header and body—follows:

POST /emco/myemco/authc/forms/MCOlogin.fcc?TYPE=33554433&REALMOID=06-000430e1-7443-125c-ac05-83846dc90034&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$5FZmjnk3DRNwNjk2KcqVCFbIrNT9%2bJ0H0KPshFtg6rB1UV2PxkHqLw%3d%3d&TARGET=https%3A%2F%2Fwww.example.com%2Femco%2Fmyemco%2FHTTP/1.1

Host: www.example.com

(BODY)

SMENC=ISO-8859-1&SMLOCALE=US-EN&USERID=Anyuser&USER_PASSWORD=XXXXXX&target=https%3A%2F%2Fwww.example.com%2Femco%2Fmyemco%2F&smauthreason=0

Step 4 Examine the POST request and copy the protocol, host, and the complete URL to configure the action-uri parameter.

Step 5 Examine the POST request body and copy the following:

a. Username parameter. In the preceding example, this parameter is USERID, not the value anyuser.

b. Password parameter. In the preceding example, this parameter is USER_PASSWORD.

c. Hidden parameter. This parameter is everything in the POST body except the username and password parameters. In the preceding example, the hidden parameter is: SMENC=ISO-8859-1&SMLOCALE=US-EN&target=https%3A%2F%2Fwww.example.com%2Femco%2Fmyemco%2F&smauthreason=0

Figure 72-5 highlights the action URI, hidden, username and password parameters within sample output from an HTTP analyzer. This is only an example; output varies widely across different websites.

Figure 72-5 Action-uri, hidden, username and password parameters

Step 6 If you successfully log in to the web server, examine the server response with the HTTP header analyzer to locate the name of the session cookie set by the server in your browser. This is the auth-cookie-name parameter.

In the following server response header, the name of the session cookie is SMSESSION. You just need the name, not the value.

Figure 72-6 shows an example of authorization cookies in HTTP analyzer output. This is only an example; output varies widely across different websites.

Figure 72-6 Authorization cookies in sample HTTP analyzer output

Step 7 In some cases, the server may set the same cookie regardless of whether the authentication was successful or not, and such a cookie is unacceptable for SSO purposes. To confirm that the cookies are different, repeat Step 1 through Step 6 using invalid login credentials and then compare the “failure” cookie with the “success” cookie.

You now have the necessary parameter data to configure the ASA for SSO with HTTP Form protocol.

Configuring SSO for Plug-ins

Plug-ins support single sign-on (SSO). They use the same credentials (username and password) entered to authenticate the clientless SSL VPN session. Because the plug-ins do not support macro substitution, you do not have the option to perform SSO on different fields, such as the internal domain password or the attribute on a RADIUS or LDAP server.

To configure SSO support for a plug-in, you install the plug-in and add a bookmark entry to display a link to the server, specifying SSO support using the csco_sso=1 parameter. The following examples show plug-in bookmarks enabled for SSO:

Configuring SSO with Macro Substitution

This section describes using macro substitution for SSO. Configuring SSO with macro substitution allows for you to inject certain variables into bookmarks to substitute for dynamic values.

Note Smart tunnel bookmarks support auto-signon but not variable substitution. For example, a SharePoint bookmark configured for smart tunnel uses the same username and password credentials to log into the application as the credentials used to log into clientless SSL VPN. You can use variable substitutions and auto signon simultaneously or separately.

You can now use bookmarks with macro substitutions for auto sign-on on some web pages. The former POST plug-in approach was created so that administrators could specify a POST bookmark with sign-on macros and receive a kick-off page to load prior to posting the POST request. This POST plug-in approach eliminated those requests that required the presence of cookies or other header items. Now an an administrator determines the pre-load page and URL, which specifies where you want the post login request sent. A pre-load page enables an endpoint browser to fetch certain information that is sent along to the webserver or web application rather than just using a POST request with credentials.

The following variables (or macros) allow for substitutions in bookmarks and forms-based HTTP POST operations:

• CSCO_WEBVPN_USERNAME — user login ID
• CSCO_WEBVPN_PASSWORD — user login password
• CSCO_WEBVPN_INTERNAL_PASSWORD — user internal (or domain) password. This cached credential is not authenticated against a AAA server. When you enter this value, the security appliance uses it as the password for auto signon, instead of the password/primary password value.

Note You cannot use any of these three variables in GET-based http(s) bookmarks. Only POST-based http(s) and cifs bookmarks can use these variables.

• CSCO_WEBVPN_CONNECTION_PROFILE —user login group drop-down (connection profile alias)
• CSCO_WEBVPN_MACRO1 — set with the RADIUS-LDAP Vendor Specific Attribute (VSA). If you are mapping from LDAP with an ldap-attribute-map command, use the WebVPN-Macro-Substitution-Value1 Cisco attribute for this macro. See the Active Directory ldap-attribute-mapping examples at http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/ref_extserver.html#wp1572118.

The CSCO_WEBVPN_MACRO1 macro substitution with RADIUS is performed by VSA#223 (see Table 72-1 ).

A value such as www.cisco.com/email dynamically populates a bookmark on the Clientless SSL VPN portal, such as https://CSCO_WEBVPN_MACRO1 or https://CSCO_WEBVPN_MACRO2 for the particular DAP or group policy.

• CSCO_WEBVPN_MACRO2 —set with RADIUS-LDAP Vendor Specific Attribute (VSA). If you are mapping from LDAP with an ldap-attribute-map command, use the WebVPN-Macro-Substitution-Value2 Cisco attribute for this macro. See the Active Directory ldap-attribute-mapping examples at http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/ref_extserver.html#wp1572118.

The CSCO_WEBVPN_MACRO2 macro substitution with RADIUS is performed by VSA#224 (see Table 72-1 ).

Each time clientless SSL VPN recognizes one of these six strings in an end-user request (in the form of a bookmark or Post Form), it replaces the string with the user-specified value and then passes the request to a remote server.

If the lookup of the username and password fails on the ASA, an empty string is substituted, and the behavior converts back as if no auto sign-in is available.

Restrictions

• Do not enable auto signon for servers that do not require authentication or that use credentials different from the ASA. When auto signon is enabled, the ASA passes on the login credentials that the user entered to log into the ASA regardless of what credentials are in user storage.
• If you configure one method for a range of servers (for example, HTTP Basic) and one of those servers attempts to authenticate with a different method (for example, NTLM), the ASA does not pass the user login credentials to that server.

Detailed Steps

Step 1 Click to add or edit an auto signon instruction. An auto signon instruction defines a range of internal servers using the auto signon feature and the particular authentication method.

Step 2 Click to delete an auto signon instruction selected in the Auto Signon table.

Step 3 Click IP Block to specify a range of internal servers using an IP address and mask.

– IP Address—Enter the IP address of the first server in the range for which you are configuring auto sign-on.

– Mask—From the subnet mask menu, choose the subnet mask that defines the server address range of the servers supporting auto signon.

Step 4 Click URI to specify a server supporting auto signon by URI, then enter the URI in the field next to this button.

Step 5 Determine the authentication method assigned to the servers. For the specified range of servers, the ASA can be configured to respond to Basic HTTP authentication requests, NTLM authentication requests, FTP and CIFS authentication requests, or requests using any of these methods.

– Basic—Click this button if the servers support basic (HTTP) authentication.

– NTLM—Click this button if the servers support NTLMv1 authentication.

– FTP/CIFS—Click this button if the servers support FTP and CIFS authentication

– Basic, NTLM, and FTP/CIFS—Click this button if the servers support all of the above.

Detailed Steps

Step 1 Click none or choose the file server protocol (smb or ftp) from the User Storage Location drop-down menu. If you choose smb or ftp, use the following syntax to enter the file system destination into the adjacent text field:

username : password @ host : port-number / path

For example

mike:mysecret@ftpserver3:2323/public

Note Although the configuration shows the username, password, and preshared key, the ASA uses an internal algorithm to store the data in an encrypted form to safeguard it.

Step 2 Type the string, if required, for the security appliance to pass to provide user access to the storage location.

Step 3 Choose one of the following options from the Storage Objects drop-down menu to specify the objects the server uses in association with the user. The ASA store these objects to support clientless SSL VPN connections.

– cookies,credentials

– cookies

– credentials

Step 4 Enter the limit in KB transaction size over which to time out the session. This attribute applies only to a single transaction. Only a transaction larger than this value resets the session expiration clock.

Detailed Steps

Step 1 Global Encoding Type determines the character encoding that all clientless SSL VPN portal pages inherit except for those from the CIFS servers listed in the table. You can type the string or choose one of the options from the drop-down list, which contains the most common values, as follows:

• big5
• gb2312
• ibm-850
• iso-8859-1
• shift_jis

Note If you are using Japanese Shift_jis Character encoding, click Do not specify in the Font Family area of the associated Select Page Font pane to remove the font family.

• unicode
• windows-1252
• none

Note If you click none or specify a value that the browser on the clientless SSL VPN session does not support, it uses its own default encoding.

You can type a string consisting of up to 40 characters, and equal to one of the valid character sets identified in http://www.iana.org/assignments/character-sets. You can use either the name or the alias of a character set listed on that page. The string is case-insensitive. The command interpreter converts upper-case to lower-case when you save the ASA configuration.

Step 2 Enter the name or IP address of a CIFS server for which the encoding requirement differs from the “Global Encoding Type” attribute setting. The ASA retains the case you specify, although it ignores the case when matching the name to a server.

Step 3 Choose the character encoding that the CIFS server should provide for clientless SSL VPN portal pages. You can type the string, or choose one from the drop-down list, which contains only the most common values, as follows:

• big5
• gb2312
• ibm-850
• iso-8859-1
• shift_jis

Note If you are using Japanese Shift_jis Character encoding, click Do not specify in the Font Family area of the associated Select Page Font pane to remove the font family.

• unicode
• windows-1252
• none

If you click none or specify a value that the browser on the clientless SSL VPN session does not support, it uses its own default encoding.

You can type a string consisting of up to 40 characters, and equal to one of the valid character sets identified in http://www.iana.org/assignments/character-sets. You can use either the name or the alias of a character set listed on that page. The string is case-insensitive. The command interpreter converts upper-case to lower-case when you save the ASA configuration.

Detailed Steps

Step 1 Click to enable caching. The default value is disable.

Step 2 Define the terms for caching.

• Enable caching of compressed content—Click to cache compressed content. When you disable this parameter, the ASA stores objects before it compresses them.
• Maximum Object Size—Enter the maximum size in KB of a document that the ASA can cache. The ASA measures the original content length of the object, not rewritten or compressed content. The range is 0 to 10,000 KB; the default is 1000 KB
• Minimum Object Size—Enter the minimum size in KB of a document that the ASA can cache. The ASA measures the original content length of the object, not rewritten or compressed content. The range is 0 to 10,000 KB; the default is 0 KB.

Note The Maximum Object Size must be greater than the Minimum Object Size.

• Expiration Time—Enter an integer between 0 and 900 to set the number of minutes to cache objects without revalidating them. The default is one minute.
• LM Factor—Enter an integer between 1 and 100; the default is 20.

The LM factor sets the policy for caching objects which have only the last-modified timestamp. This revalidates objects that have no server-set change values. The ASA estimates the length of time since the object has changed, also called the expiration time. The estimated expiration time equals the time elapsed since the last change multiplied by the LM factor. Setting the LM factor to 0 forces immediate revalidation, while setting it to 100 results in the longest allowable time until revalidation.

The expiration time sets the amount of time to for the ASA to cache objects that have neither a last-modified time stamp nor an explicit server-set expiry time.

• Cache static content—Click to cache all content that is not subject to rewrite, for example, PDF files and images.
• Restore Cache Default—Click to restore default values for all cache parameters.

Detailed Steps

The Content Rewrite section displays the following:

• Rule Number—Displays an integer that indicates the position of the rule in the list.
• Rule Name—Provides the name of the application for which the rule applies.
• Rewrite Enabled—Displays content rewrite as enabled or disabled.
• Resource Mask—Displays the resource mask.

Follow these steps to add a rewrite entry or edit a selected rewrite entry.

Step 1 Click to enable content rewrite for this rewrite rule.

Step 2 (Optional) Enter a number for this rule. This number specifies the priority of the rule, relative to the others in the list. Rules without a number are at the end of the list. The range is 1 to 65534.

Step 3 (Optional) Provide an alphanumeric string that describes the rule, maximum 128 characters.

Step 4 Enter a string to match the application or resource to apply the rule to. The string can be up to 300 characters. You can use one of the following wildcards, but you must specify at least one alphanumeric character.

* — Matches everything. ASDM does not accept a mask that consists of a * or *.*

? —Matches any single character.

[!seq] — Matches any character not in sequence.

[seq] — Matches any character in sequence.

Configuration Example for Content Rewrite Rules

Authenticating with Digital Certificates

Clientless SSL VPN users that authenticate using digital certificates do not use global authentication and authorization settings. Instead, they use an authorization server to authenticate once the certificate validation occurs. For more information on authentication and authorization using digital certificates, see the “Using Certificates and User Login Credentials” section.

Assigning Users to Group Policies

Assigning users to group policies simplifies the configuration by letting you apply policies to many users. You can use an internal authentication server on the ASA or an external RADIUS or LDAP server to assign users to group policies. See Chapter 66, “Configuring Connection Profiles, Group Policies, and Users”for a thorough explanation of ways to simplify configuration with group policies.

Using a RADIUS Server

Using a RADIUS server to authenticate users, assign users to group policies by following these steps:

Step 1 Authenticate the user with RADIUS and use the Class attribute to assign that user to a particular group policy.

Step 2 Set the class attribute to the group policy name in the format OU=group_name

For example, to assign a clientless SSL VPN user to the SSL_VPN group, set the RADIUS Class Attribute to a value of OU=SSL_VPN; (Do not omit the semicolon.)

Using an LDAP Server

Using an LDAP server to authenticate users, assign users to group policies by following these steps:

Step 1 Authenticate the user with LDAP and use the Group Policy attribute to assign that user to a particular group policy.

Step 2 Set the Group Policy attribute to the group policy name in one of these formats:

• <group policy name>
• OU=<group policy name>
• OU=<group policy name>;

For example, to assign a clientless SSL VPN user to the SSL_VPN group, set the LDAP Group Policy Attribute to a value of SSL_VPN, OU=SSL_VPN, or OU=SSL_VPN;.

Prerequisites

• Clientless SSL VPN must be enabled on the ASA to provide remote access to the plug-ins.
• To configure SSO support for a plug-in, you install the plug-in, add a bookmark entry to display a link to the server, and specify SSO support when adding the bookmark.
• The minimum access rights required for remote use belong to the guest privilege mode.
• Plug-ins require ActiveX or Sun JRE 5, Update 1.4 or later (JRE 6 or later recommended) to be enabled on the browser. An ActiveX version of the RDP plug-in is unavailable for 64-bit browsers.

Restrictions

• The plug-ins do not work if the security appliance configures the clientless session to use a proxy server.

Note The remote desktop protocol plug-in does not support load balancing with a session broker. Because of the way the protocol handles the redirect from the session broker, the connection fails. If a session broker is not used, the plug-in works.

• The plug-ins support single sign-on (SSO). They use the same credentials entered to open the clientless SSL VPN session. Because the plug-ins do not support macro substitution, you do not have the options to perform SSO on different fields such as the internal domain password or on an attribute on a RADIUS or LDAP server.
• A stateful failover does not retain sessions established using plug-ins. Users must reconnect following a failover.
• If you use stateless failover instead of stateful failover, clientless features such as bookmarks, customization, and dynamic access-policies are not synchronized between the failover ASA pairs. In the event of a failover, these features do not work.

Adding a New Environment Variable

To set up and use an RDP plug-in, you must add a new environment variable. For the process of adding a new environment variable, use the following steps:

Detailed Steps

Step 1 Right click on My Computer to access the System Properties and choose the Advanced tab.

Step 2 On the Advanced tab, choose the environment variables button.

Step 3 In the new user variable dialog box, enter the RF_DEBUG variable.

Step 4 Verify the new Environment Variable in the user variables section.

Step 5 If you used the client computer with versions of WebVPN before version 8.3, you must remove the old Cisco Portforwarder Control. Go to the C:/WINDOWS/Downloaded Program Files directory, right click on the portforwarder control, and choose Remove.

Step 6 Clear all of the Internet Explorer browser cache.

Step 7 Launch your WebVPN session and establish an RDP session with the RDP ActiveX Plug-in.

You can now observe events in the Windows Application Event viewer.

Preparing the Security Appliance for a Plug-in

Before installing a plug-in, prepare the ASA as follows:

Prerequisites

Make sure clientless SSL VPN (“webvpn”) is enabled on an ASA interface.

Restrictions

Do not specify an IP address as the common name (CN) for the SSL certificate. The remote user attempts to use the FQDN to communicate with the ASA. The remote PC must be able to use DNS or an entry in the System32\drivers\etc\hosts file to resolve the FQDN.

Detailed Steps

Go to the section that identifies the type of plug-in you want to provide for clientless SSL VPN access.

• Installing Plug-ins Redistributed By Cisco
• Providing Access to Third-Party Plug-ins

Installing Plug-ins Redistributed By Cisco

Cisco redistributes the following open-source, Java-based components to be accessed as plug-ins for web browsers in clientless SSL VPN sessions.

Prerequisites

• Make sure clientless SSL VPN (“webvpn”) is enabled on an interface on the ASA. To do so, enter the show running-config command.
• Create a temporary directory named “plugins” on a local TFTP or FTP server (for example, with the hostname “local_tftp_server”), and download the plug-ins from the Cisco web site to the “plugins” directory.

Restrictions

These plug-ins are available on the Cisco Adaptive Security Appliance Software Download site.

Detailed Steps

Follow these steps to provide clientless SSL VPN browser access to a plug-in redistributed by Cisco.

Note The ASA does not retain the import webvpn plug-in protocol command in the configuration. Instead, it loads the contents of the csco-config/97/plugin directory automatically. A secondary ASA obtains the plug-ins from the primary ASA.

Step 1 Create a temporary directory named plugins on the computer you use to establish ASDM sessions with the ASA.

Step 2 Download the plug-ins you want from the Cisco website to the plugins directory.

Step 3 Choose Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Client-Server Plug-ins.

This pane displays the plug-ins that are available to clientless SSL sessions. The hash and date of these plug-ins are also provided.

Step 4 Click Import.

The Import Client-Server Plug-in dialog box opens.

Step 5 Use the following descriptions to enter the Import Client-Server Plug-in dialog box field values.

• Plug-in Name—Select one of the following values:

– ica to provide plug-in access to Citrix MetaFrame or Web Interface services. Then specify the path to the ica-plugin.jar file in the Remote Server field, as described below.

– rdp to provide plug-in access to Remote Desktop Protocol services. Then specify the path to the rdp-plugin.jar file in the Remote Server field.

– ssh,telnet to provide plug-in access to both Secure Shell and Telnet services. Then specify the path to the ssh-plugin.jar file in the Remote Server field.

– vnc to provide plug-in access to Virtual Network Computing services. Then specify the path to the vnc-plugin.jar file in the Remote Server field.

Note Any undocumented options in this menu are experimental and are not supported.

• Select a file—Click one of the following options and insert a path into its text field.

– Local computer—Click to retrieve the plug-in from the computer with which you have established the ASDM session. Enter the location and name of the plug-in into the associated Path field, or click Browse Local Files and navigate to the plug-in, choose it, then click Select.

– Flash file system—Click if the plug-in is present on the file system of the ASA. Enter the location and name of the plug-in into the associated Path field, or click Browse Flash and navigate to the plug-in, choose it, then click OK.

– Remote Server—Click to retrieve the plug-in from a host running an FTP or TFTP server. Choose ftp, tftp, or HTTP from the drop-down menu next to the associated Path attribute, depending on which service is running on the remote server. Enter the host name or address of the server and the path to the plug-in into the adjacent text field.

Step 6 Click Import Now.

Step 7 Click Apply.

The plug-in is now available for future clientless SSL VPN sessions.

Providing Access to Third-Party Plug-ins

The open framework of the security appliance lets you add plug-ins to support third-party Java client/server applications. The POST plug-in was developed to solve some key single sign-on (SSO) and homepage requirements for certain applications like Citrix Web Interface. This clientless SSL VPN plug-in as the following key capabilities:

• The option to display the homepage for a Web application (such as Citrix) in the right frame, as part of the default clientless portal, or as the only frame in the page (completely hiding anything that is part of the Cisco portal).
• The option for SSO on the homepage or with an application using WebVPN variables (also known as macros) (and therefore HTTP-POST parameters).
• The option to preload a page before issuing a POST request. This option becomes necessary when a logon page for an application sets some cookies.

Restrictions

• Cisco does not provide direct support for or recommend any particular plug-ins that are not redistributed by Cisco. As a provider of clientless SSL VPN services, you are responsible for reviewing and complying with any license agreements required for the use of plug-ins.
• It is strictly an HTML/JavaScript code and not a JAVA plug-in. It contains no client components.
• No support on Firefox. It is supported only on Internet Explorer and Mac Safari.
• Does not support URLs with queries such as http://example.com/names?Login. The ? character is not supported.
• A POST plug-in adds approximately a 10-second delay to make sure an intermediate page is fully loaded with all objects for an application. This delay is beneficial for an application such as Citrix where an intermediate page performs client detection functions.

Configuring and Applying the POST URL

POST plug-ins are configured with the customization object. For example, to make a Citrix portal as the homepage after Clientless SSL VPN login, follow these steps:

Detailed Steps

Step 1 Add the POST URL of the Citrix server to the customization object in the Custom Intranet Web Page URL field (see Figure 72-7).

For example, if the Citrix server URL is http://mycitrix-server.abcd.com/Citrix/AccessPlatform/auth/login.aspx, adding the POST URL, it becomes post://mycitrix-server.abcd.com/Citrix/AccessPlatform/auth/login.aspx?LoginType=Explicit&user=CSCO_WEBVPN_USERNAME&password=CSCO_WEBVPN_PASSWORD&csco_preload=http://mycitrix-server.abcd.com&csco_ispopup=yes.

Figure 72-7 SSL VPN Customization Editor Window

Step 2 Apply the customization object to the group or user.

For additional information on configuring SSO and the required parameters, refer to the SSL VPN deployment guide (http://www.cisco.com/en/US/docs/security/asa/asa80/asdm60/ssl_vpn_deployment_guide/deploy.html#wp1002989).

Providing Access to a Citrix Java Presentation Server

As an example of how to provide clientless SSL VPN browser access to third-party plug-ins, this section describes how to add clientless SSL VPN support for the Citrix Presentation Server Client.

With a Citrix plug-in installed on the ASA, clientless SSL VPN users can use a connection to the ASA to access Citrix MetaFrame services.

A stateful failover does not retain sessions established using the Citrix plug-in. Citrix users must reauthenticate after failover.

To provide access to the Citrix plug-in, follow the procedures in the following sections.

• Preparing the Citrix MetraFrame Server for Clientless SSL VPN Access
• Creating and Installing the Citrix Plug-in

Preparing the Citrix MetraFrame Server for Clientless SSL VPN Access

The ASA performs the connectivity functions of the Citrix secure gateway when the Citrix client connects to the Citrix MetaFrame Server. Therefore, you must configure the Citrix Web Interface software to operate in a mode that does not use the (Citrix) “secure gateway.” Otherwise, the Citrix client cannot connect to the Citrix MetaFrame Server.

Note If you are not already providing support for a plug-in, you must follow the instructions in the“Preparing the Security Appliance for a Plug-in” section before using this section.

Creating and Installing the Citrix Plug-in

To create and install the Citrix plug-in, perform the following steps:

Detailed Steps

Step 1 Download the ica-plugin.zip file from the Cisco Software Download web site.

This file contains files that Cisco customized for use with the Citrix plug-in.

Step 2 Download the Citrix Java client from the Citrix site.

Step 3 Extract the following files from the Citrix Java client, then add them to the ica-plugin.zip file:

• JICA-configN.jar
• JICAEngN.jar

You can use WinZip to perform this step.

Step 4 Ensure the EULA included with the Citrix Java client grants you the rights and permissions to deploy the client on your web servers.

Step 5 Open a CLI session with the ASA and install the plug-in by entering the following command in privileged EXEC mode:

import webvpn plug-in protocol ica URL

URL is the host name or IP address and path to the ica-plugin.zip file.

Note After you import the plug-in, remote users can choose ica and enter host/?DesiredColor=4&DesiredHRes=1024&DesiredVRes=768 into the Address field of the portal page to access Citrix services. We recommend that you add a bookmark to make it easy for users to connect. Adding a bookmark is required if you want to provide SSO support for Citrix sessions.

Step 6 Establish an SSL VPN clientless session and click the bookmark or enter the URL for the Citrix server.

Use the Client for Java Administrator’s Guide as needed.

Viewing the Plug-ins Installed on the Security Appliance

Detailed Steps

Requirements

In order for the kcd-server command to function, the ASA must establish a trust relationship between the source domain (the domain where the ASA resides) and the target or resource domain (the domain where the web services reside). The ASA, using its unique format, crosses the certification path from the source to the destination domain and acquires the necessary tickets on behalf of the remote access user to access the services.

This crossing of the certificate path is called cross-realm authentication. During each phase of cross-realm authentication, the ASA relies on the credentials at a particular domain and the trust relationship with the subsequent domain.

Authentication Flow with KCD

Figure 72-8 depicts the packet and process flow a user will experience directly and indirectly when accessing resources trusted for delegation via the clientless portal. This process assumes that the following tasks have been completed:

• Configured KCD on ASA
• Joined the Windows Active Directory and ensured services are trusted for delegation
• Delegated ASA as a member of the Windows Active Directory domain

Figure 72-8 KCD Process

Note A clientless user session is authenticated by the ASA using the authentication mechanism configured for the user. (In the case of Smartcard credentials, ASA performs LDAP authorization with the userPrincipalName from the digital certificate against the Windows Active Directory).

1. After successful authentication, the user logs in to the ASA clientless portal page. The user accesses a Web service by entering a URL in the portal page or by clicking on the bookmark. If the Web service requires authentication, the server challenges ASA for credentials and sends a list of authentication methods supported by the server.

Note KCD for Clientless SSL VPN is supported for all authentication methods (RADIUS, RSA/SDI, LDAP, digital certificates, and so on). Refer to the AAA Support table at http://www.cisco.com/en/US/partner/docs/security/asa/asa84/configuration/guide/access_aaa.html#wp1069492.

2. Based on the HTTP headers in the challenge, ASA determines whether the server requires Kerberos authentication. (This is part of the SPNEGO mechanism.) If connecting to a backend server requires Kerberos authentication, the ASA requests a service ticket for itself on behalf of the user from the key distribution center.

3. The key distribution center returns the requested tickets to the ASA. Even though these tickets are passed to the ASA, they contain the user’s authorization data.ASA requests a service ticket from the KDC for the specific service that the user wants to access.

Note Steps 1 to 3 comprise protocol transition. After these steps, any user who authenticates to ASA using a non-Kerberos authentication protocol is transparently authenticated to the key distribution center using Kerberos.

4. ASA requests a service ticket from the key distribution center for the specific service that the user wants to access.

5. The key distribution center returns a service ticket for the specific service to the ASA.

6. ASA uses the service ticket to request access to the web service.

7. The Web server authenticates the Kerberos service ticket and grants access to the service. The appropriate error message is displayed and requires acknowledgement if there is an authentication failure. If the Kerberos authentication fails, the expected behavior is to fall back to basic authentication.

Before Configuring KCD

To configure the ASA for cross-realm authentication, you must use the following commands:

Configuring KCD

To have the ASA join a Windows Active Directory domain and return a success or failure status, follow these commands:

Detailed Steps

Showing KCD Status Information

To display the domain controller information and the domain join status, follow these commands:

Showing Cached Kerberos Tickets

To display all Kerberos tickets cached on the ASA, enter the following commands:

Clearing Cached Kerberos Tickets

To clear all Kerberos ticket information on the ASA, follow these commands:

Adding Windows Service Account in Active Directory

The KCD implementation on the ASA requires a service account, or in other words, an Active Directory user account with privileges necessary to add computers, such as adding the ASA to the domain. For our example, the Active Directory username JohnDoe depicts a service account with the required privileges. For more information on how to implement user privileges in Active Directory, contact Microsoft Support or visit http://microsoft.com.

Configuring DNS for KCD

This section outlines configuration procedures necessary to configure DNS on the ASA. When using KCD as the authentication delegation method on the ASA, DNS is required to enable hostname resolution and communication between the ASA, Domain Controller (DC), and services trusted for delegation.

Step 1 From ASDM, navigate to Configuration > Remote Access VPN > DNS and configure the DNS setup as shown in Figure 72-9:

• DNS Server Group—Enter the DNS server IP address(es), such as 192.168.0.3.
• Domain Name—Enter the domain name in which the DC is a member, such as exampledc.com.

Step 2 Enable DNS Lookup on the appropriate interface. Clientless VPN deployments require DNS Lookups via the internal corporate network, typically the inside interface.

Figure 72-9 ASA DNS Configuration Example

Configuring the ASA to Join the Active Directory Domain

This section outlines configuration procedures necessary to enable the ASA to act as part of the Active Directory domain. KCD requires the ASA to be a member of the Active Directory domain. This configuration enables the functionality necessary for constrained delegation transactions between the ASA and the KCD server.

Step 1 From ASDM, navigate to Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Microsoft KCD Server, as shown in Figure 72-10.

Step 2 Click New to add a Kerberos Server Group for Constrained Delegation and configure the following
(see Figure 72-10):

• Server Group Configuration

– Server Group Name—Define the name of the constrained delegation configuration on the ASA, such as MSKCD, which is the default value. You can configure multiple server groups for redundancy; however, you can only assign one server group to the KCD server configuration used to request service tickets on behalf of VPN users.

– Reactivation Mode—Click the radio button for the mode you want to use (Depletion or Timed). In Depletion mode, failed servers are reactivated only after all of the servers in the group are inactive. In Timed mode, failed servers are reactivated after 30 seconds of down time. Depletion is the default configuration.

– Dead Time—If you choose the Depletion reactivation mode, you must add a dead time interval. Ten minutes is the default configuration. The interval represents the duration of time, in minutes, that elapses between the disabling of the last server in a group and the subsequent re-enabling of all servers.

– Max Failed Attempts—Set the number of failed connection attempts allowed before declaring an unresponsive server to be inactive. Three attempts is the default.

• Server Configuration

– Interface Name—Choose the interface on which the server resides. In general, authentication server deployments reside on the internal corporate network, typically via the inside interface.

– Server Name—Define the hostname of the domain controller, such as ServerHostName.

– Timeout—Specify the maximum time, in seconds, to wait for a response from the server. Ten seconds is the default.

• Kerberos Parameter

– Server Port—88 is the default and the standard port used for KCD.

– Retry Interval—Choose the desired retry interval. Ten seconds is the default configuration.

– Realm—Enter the domain name of the DC in all uppercase (such as EXAMPLEDC.COM). The KCD configuration on the ASA requires the realm value to be in uppercase. A realm is an authentication domain. A service can accept authentication credentials only from entities in the same realm. The realm must match the domain name which the ASA joins.

Figure 72-10 KCD Server Group Configuration

Step 3 Click OK to apply your configuration and then configure the Microsoft KCD Server to request service tickets on behalf of the remote access user (see Figure 72-10). The Microsoft KCD Server configuration window appears upon clicking OK.

Configuring Kerberos Server Groups

The Kerberos Server Group for Constrained Delegation, MSKCD, is automatically applied to the KCD Server Configuration. You can also configure Kerberos Server groups and manage them under Configuration > Remote Access VPN > AAA/Local User > AAA Server Groups.

Step 1 Under the Server Access Credential section, configure the following:

• Username—Define a Service Account (Active Directory username) such as JohnDoe, which has been granted privileges necessary to add computer accounts to the Active Directory domain. The username does not correspond to a specific administrative user but simply a user with service-level privileges. This service account is used by the ASA to add a computer account for itself to the Active Directory domain at every reboot. You must configure the computer account separately to request Kerberos tickets on behalf of the remote users.

Note Administrative privileges are required for initial join. A user with service-level priviledges on the domain controller will not get access.

• Password—Define the password associated with the username (such as Cisco123). The password does not correspond to a specific password but simply a service-level password privilege to add a device on the Window domain controller.

Step 2 Under the Server Group Configuration section, configure the following:

• Reactivation Mode—Click the mode you want to use (Depletion or Timed). In Depletion mode, failed servers are reactivated only after all of the servers in the group are inactive. In Timed mode, failed servers are reactivated after 30 seconds of down time. Depletion is the default configuration.
• Dead Time—If you choose the Depletion reactivation mode, you must add a dead time interval. The interval represents the duration of time, in minutes, that elapses between the disabling of the last server in a group and the subsequent re-enabling of all servers. Ten minutes is the default.
• Max Failed Attempts—Set the number of failed connection attempts allowed before declaring a nonresponsive server to be inactive. Three attempts is the default.

Note Under the Server Table section, the previously configured DC hostname, ServerHostName, was automatically applied to the KCD Server configuration (see Figure 72-11).

Figure 72-11 KCD Server Configuration

Step 3 Click Apply.

Note After applying your configuration, the ASA automatically starts the process of joining the Active Directory domain. The ASA’s hostname appears in the Computers directory in Active Directory Users and Computers.

To confirm if the ASA has successfully joined the domain, execute the following command from the ASA prompt as shown in Figure 72-12:

show webvpn kcd

Figure 72-12 ASA Domain Membership Confirmation

Configuring Bookmarks to Access the Kerberos Authenticated Services

To access Kerberos Authenticated Services such as Outlook Web Access using the ASA clientless portal, you must configure bookmark lists. Bookmark Lists are assigned and displayed to remote access users based on the VPN security policies they are associated with.

Step 1 Navigate to Configuration > Remote Access VPN > Clientless VPN Access > Portal > Bookmarks on the ASDM GUI.

Step 2 In Bookmark List, enter the URL to reference for the service location.

Configuring Smart Tunnel Access

A smart tunnel list identifies one or more applications eligible for smart tunnel access and the endpoint operating system associated with the list. Because each group policy or local user policy supports one smart tunnel list, you must group the nonbrowser-based applications to be supported into a smart tunnel list. Without writing a script or uploading anything, an administrator can specify which homepage in the group policy to connect with via smart tunnel (with the homepage use-smart-tunnel CLI command or on the GUI). Following the configuration of a list, you can assign it to one or more group policies or local user policies. If the administrator has it configured as such, you can browse the internet directly while accessing company internal resources via smart tunnel.

The following sections describe smart tunnels and how to configure them:

• About Smart Tunnels
• Why Smart Tunnels?
• Adding Applications to Be Eligible for Smart Tunnel Access
• Configuring a Smart Tunnel (Lotus example)
• Simplifying Configuration of Which Applications to Tunnel
• Adding Applications to Be Eligible for Smart Tunnel Access
• Assigning a Smart Tunnel List
• Configuring and Applying a Smart Tunnel Tunnel Policy
• Specifying Servers for Smart Tunnel Auto Sign-on
• Adding or Editing a Smart Tunnel Auto Sign-on Server Entry
• Enabling and Disabling Smart Tunnel Access

About Smart Tunnels

A smart tunnel is a connection between a TCP-based application and a private site, using a clientless (browser-based) SSL VPN session with the security appliance as the pathway, and the ASA as a proxy server. You can identify applications to which you want to grant smart tunnel access, and specify the local path to each application. For applications running on Microsoft Windows, you can also require a match of the SHA-1 hash of the checksum as a condition for granting smart tunnel access.

Lotus SameTime and Microsoft Outlook are examples of applications to which you might want to grant smart tunnel access.

Configuring smart tunnels requires one of the following procedures, depending on whether the application is a client or is a web-enabled application:

• Create one or more smart tunnel lists of the client applications, then assign the list to the group policies or local user policies for whom you want to provide smart tunnel access.
• Create one or more bookmark list entries that specify the URLs of the web-enabled applications eligible for smart tunnel access, then assign the list to the group policies or local user policies for whom you want to provide smart tunnel access.

You can also list web-enabled applications for which to automate the submission of login credentials in smart tunnel connections over clientless SSL VPN sessions.

Why Smart Tunnels?

Smart tunnel access lets a client TCP-based application use a browser-based VPN connection to access a service. It offers the following advantages to users, compared to plug-ins and the legacy technology, port forwarding:

• Smart tunnel offers better performance than plug-ins.
• Unlike port forwarding, smart tunnel simplifies the user experience by not requiring the user connection of the local application to the local port.
• Unlike port forwarding, smart tunnel does not require users to have administrator privileges.

The advantage of a plug-in is that it does not require the client application to be installed on the remote computer.

Prerequisites

See the Supported VPN Platforms, Cisco ASA 5500 Series for the platforms and browsers supported by ASA Release 8.4 smart tunnels.

The following requirements apply to smart tunnel access on Windows:

• ActiveX or Sun JRE 5, Update 1.5 or later (JRE 6 or later recommended) on Windows must be enabled on the browser.

ActiveX pages require that you enter the activex-relay command on the associated group policy. If you do so or assign a smart tunnel list to the policy, and the browser proxy exception list on the endpoint specifies a proxy, the user must add a “shutdown.webvpn.relay.” entry to this list.

Note Browser-based VPN access does not support Windows Shares (CIFS) Web Folders on Windows 7, Vista, Internet Explorer 8, Mac OS, and Linux. Windows XP SP2 requires a Microsoft hotfix to support Web Folders.

• Only Winsock 2, TCP-based applications are eligible for smart tunnel access.
• Smart tunnel supports Mac OS running on an Intel processor only.
• Java Web Start must be enabled on the browser.

Restrictions

• For users of Microsoft Windows Vista who use smart tunnel or port forwarding, we recommend that you add the URL of the ASA to the Trusted Site zone. To access the Trusted Site zone, they must start Internet Explorer and choose the Tools > Internet Options > Security tab. Vista users can also disable Protected Mode to facilitate smart tunnel access; however, we recommend against this method because it increases vulnerability to attack.
• Smart tunnel supports only proxies placed between computers running Microsoft Windows and the security appliance. Smart tunnel uses the Internet Explorer configuration (that is, the one intended for system-wide use in Windows). If the remote computer requires a proxy server to reach the ASA, the URL of the terminating end of the connection must be in the list of URLs excluded from proxy services. If the proxy configuration specifies that traffic destined for the ASA goes through a proxy, all smart tunnel traffic goes through the proxy.
• In an HTTP-based remote access scenario, sometimes a subnet does not provide user access to the VPN gateway. In this case, a proxy placed in front of the ASA to route traffic between the web and the end user's location provides web access. However, only VPN users can configure proxies placed in front of the ASA. When doing so, they must make sure these proxies support the CONNECT method. For proxies that require authentication, smart tunnel supports only the basic digest authentication type.
• When smart tunnel starts, the ASA by default passes all browser traffic through the VPN session if the browser process is the same. The ASA also does this if a tunnel-all policy applies. If the user starts another instance of the browser process, it passes all traffic through the VPN session. If the browser process is the same and the security appliance does not provide access to a URL, the user cannot open it. As a workaround, assign a tunnel policy that is not tunnel-all.
• A stateful failover does not retain smart tunnel connections. Users must reconnect following a failover.
• If it takes too long for smart tunnel to load, perform the following:

– Clear the SSL state (with Internet Explorer, go to Tools > Internet Options > Content).

– Disable the Check for server certificate revocation check box (with Internet Explorer, go to Tools > Internet Options > Advanced > Security).

– Delete cookies (with Internet Explorer, go to Tools > Internet Options > General).

• The Mac version of smart tunnel does not support POST bookmarks, form-based auto sign-on, or POST macro substitution.
• Only applications started from the portal page can establish smart tunnel connections. This requirement includes smart tunnel support for Firefox. Using Firefox to start another instance of Firefox during the first use of a smart tunnel requires the user profile named csco_st. If this user profile is not present, the session prompts the user to create one.
• In a Mac OS, applications using TCP that are dynamically linked to the SSL library can work over a smart tunnel.
• Smart tunnel does not support the following on Mac OS:

– Proxy services.

– Auto sign-on.

– Applications that use two-level name spaces.

– Console-based applications, such as Telnet, SSH, and cURL.

– Applications using dlopen or dlsym to locate libsocket calls.

– Statically linked applications to locate libsocket calls.

• For Windows, if you want to add smart tunnel access to an application started from the command prompt, you must specify “cmd.exe” in the Process Name of one entry in the smart tunnel list, and specify the path to the application itself in another entry, because “cmd.exe” is the parent of the application.
• Mac OS requires the full path to the process and is case-sensitive. To avoid specifying a path for each username, insert a tilde (~) before the partial path (e.g., ~/bin/vnc).
• Smart Tunnel and Secure Desktop (Vault) Interoperability

Cisco supports smart tunneling inside a Secure Desktop (Vault) environment on all operating systems that support Vault. We also support smart tunneling of desktop applications and browser-based applications.

ASA 8.3 or later is required to perform smart tunneling from an endpoint using IE8 or a 64-bit Windows operating system.

To implement smart tunneling with IE8, from within a Secure Desktop (Vault), the endpoint must be connected to a secure gateway running ASA 8.3 or later; in addition, the endpoint must have Cisco Secure Desktop 3.5 or later installed.

Smart tunneling is not intended to restrict network access to only internal resources.

Configuring a Smart Tunnel (Lotus example)

To configure a Smart Tunnel, perform the following steps:

Note These example instructions provide the minimum instructions required to add smart tunnel support for an application. See the field descriptions in the sections that follow for more information.

Detailed Steps

Step 1 Choose Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Smart Tunnels.

Step 2 Double-click the smart tunnel list to which you want to add an application; or click Add to create a list of applications, enter a name for this list in the List Name field, and click Add.

For example, click Add in the Smart Tunnels pane, enter Lotus in the List Name field, and click Add.

Step 3 Click Add in the Add or Edit Smart Tunnel List dialog box.

Step 4 Enter a string in the Application ID field to serve as a unique index to the entry within the smart tunnel list.

Step 5 Enter the filename and extension of the application into the Process Name dialog box.

Table 72-7 shows example Application ID strings and the associated paths required to support Lotus.

Step 6 Select Windows next to OS.

Step 7 Click OK.

Step 8 Repeat Steps 3 – 7 for each application to add to the list.

Step 9 Click OK in the Add or Edit Smart Tunnel List dialog box.

Step 10 Assign the list to the group policies and local user policies to which you want to provide smart tunnel access to the associated applications, as follows:

• To assign the list to a group policy, choose Configuration > Remote Access VPN> Clientless SSL VPN Access > Group Policies > Add or Edit > Portal and choose the smart tunnel name from the drop-down list next to the Smart Tunnel List attribute.
• To assign the list to a local user policy, choose Configuration > Remote Access VPN> AAA Setup > Local Users > Add or Edit > VPN Policy > Clientless SSL VPN and choose the smart tunnel name from the drop-down list next to the Smart Tunnel List attribute.

Simplifying Configuration of Which Applications to Tunnel

A smart tunnel application list is essentially a filter of what applications are granted access to the tunnel. The default is to allow access for all processes started by the browser. With Smart Tunnel enabled bookmark, the clientless session grants access only to processes initiated by the web browser. For non-browser applications, an administrator can choose to tunnel all applications and thus remove the need to know which applications an end user may invoke. Table 72-8 shows in which situations processes are granted access.

Restrictions

This configuration is applicable to Windows platforms only.

Detailed Steps

Follow these steps to configure tunnel policy.

Step 1 Choose Configuration > Remote Access VPN > AAA/Local Users > Local Users.

Step 2 In the User Account window, highlight the username that you want to edit.

Step 3 Click Edit. The Edit User Account window appears.

Step 4 In the left sidebar of the Edit User Account window, click VPN Policy > Clientless SSL VPN.

Step 5 Perform one of the following:

• Check the smart tunnel_all_applications check box. All applications will be tunneled without making a list or knowing which executables an end user may invoke for external applications.
• Or choose from the following tunnel policy options:

– Uncheck the Inherit check box at the Smart Tunnel Policy parameter.

– Choose from the network list and specify one of the tunnel options: use smart tunnel for the specified network, do not use smart tunnel for the specified network, or use tunnel for all network traffic.

Adding Applications to Be Eligible for Smart Tunnel Access

The clientless SSL VPN configuration of each ASA supports smart tunnel lists, each of which identifies one or more applications eligible for smart tunnel access. Because each group policy or username supports only one smart tunnel list, you must group each set of applications to be supported into a smart tunnel list.

To add an entry to a list of applications that can use a clientless SSL VPN session to connect to private sites, enter the following commands:

The Add or Edit Smart Tunnel entry dialog box lets you specify the attributes of an application in a smart tunnel list.

Step 1 Enter a unique name for the list of applications or programs. Do not user spaces.

Following the configuration of the smart tunnel list, the list name appears next to the Smart Tunnel List attribute in the Clientless SSL VPN group policies and local user policies. Assign a name that will help you to distinguish its contents or purpose from other lists that you are likely to configure.

Step 2 Enter a string to name the entry in the smart tunnel list. This user-specified name is saved and then returned onto the GUI. The string is unique for the operating system. It typically names the application to be granted smart tunnel access. To support multiple versions of an application for which you choose to specify different paths or hash values, you can use this attribute to differentiate entries, specifying the operating system, and name and version of the application supported by each list entry. The string can be up to 64 characters.

Step 3 Enter the filename or path to the application. The string can be up to 128 characters.

Windows requires an exact match of this value to the right side of the application path on the remote host to qualify the application for smart tunnel access. If you specify only the filename for Windows, SSL VPN does not enforce a location restriction on the remote host to qualify the application for smart tunnel access.

If you specify a path and the user installed the application in another location, that application does not qualify. The application can reside on any path as long as the right side of the string matches the value you enter.

To authorize an application for smart tunnel access if it is present on one of several paths on the remote host, either specify only the name and extension of the application in this field; or create a unique smart tunnel entry for each path.

Note A sudden problem with smart tunnel access may be an indication that a Process Name value is not up-to-date with an application upgrade. For example, the default path to an application sometimes changes following the acquisition of the company that produces the application and the next application upgrade.

For Windows, if you want to add smart tunnel access to an application started from the command prompt, you must specify “cmd.exe” in the Process Name of one entry in the smart tunnel list, and specify the path to the application itself in another entry, because “cmd.exe” is the parent of the application.

Step 4 Click Windows or Mac to specify the host operating system of the application.

Step 5 (Optional and applicable only for Windows) To obtain this value, enter the checksum of the application (that is, the checksum of the executable file) into a utility that calculates a hash using the SHA-1 algorithm. One example of such a utility is the Microsoft File Checksum Integrity Verifier (FCIV), which is available at http://support.microsoft.com/kb/841290/. After installing FCIV, place a temporary copy of the application to be hashed on a path that contains no spaces (for example, c:/fciv.exe), then enter fciv.exe -sha1 application at the command line (for example, fciv.exe -sha1 c:\msimn.exe) to display the SHA-1 hash.

The SHA-1 hash is always 40 hexadecimal characters.

Before authorizing an application for smart tunnel access, clientless SSL VPN calculates the hash of the application matching the Application ID. It qualifies the application for smart tunnel access if the result matches the value of Hash.

Entering a hash provides a reasonable assurance that SSL VPN does not qualify an illegitimate file that matches the string you specified in the Application ID. Because the checksum varies with each version or patch of an application, the Hash you enter can only match one version or patch on the remote host. To specify a hash for more than one version of an application, create a unique smart tunnel entry for each Hash value.

Note You must update the smart tunnel list in the future if you enter Hash values and you want to support future versions or patches of an application with smart tunnel access. A sudden problem with smart tunnel access may be an indication that the application list containing Hash values is not up-to-date with an application upgrade. You can avoid this problem by not entering a hash.

Following the configuration of the smart tunnel list, you must assign it to a group policy or a local user policy for it to become active, as follows:

• To assign the list to a group policy, choose Config > Remote Access VPN> Clientless SSL VPN Access > Group Policies > Add or Edit > Portal and choose the smart tunnel name from the drop-down list next to the Smart Tunnel List attribute.
• To assign the list to a local user policy, choose Config > Remote Access VPN> AAA Setup > Local Users > Add or Edit > VPN Policy > Clientless SSL VPN and choose the smart tunnel name from the drop-down list next to the Smart Tunnel List attribute.

Assigning a Smart Tunnel List

For each group policy and username, you can configure clientless SSL VPN to do one of the following:

• Start smart tunnel access automatically upon user login.
• Enable smart tunnel access upon user login, but require the user to start it manually, using the Application Access > Start Smart Tunnels button on the clientless SSL VPN Portal Page.

Restrictions

These options are mutually exclusive for each group policy and username. Use only one.

The following smart tunnel commands are available to each group policy and username. The configuration of each group policy and username supports only one of these commands at a time, so when you enter one, the ASA replaces the one present in the configuration of the group policy or username in question with the new one, or in the case of the last command, simply removes the smart-tunnel command already present in the group policy or username.

Detailed Steps

Configuring and Applying Smart Tunnel Policy

The smart tunnel policy requires a per group policy/username configuration. Each group policy/username references a globally configured list of networks. When the smart tunnel is turned on, you can allow traffic outside of the tunnel with the use of 2 CLIs: one configures the network (a set of hosts), and the other uses the specified smart-tunnel network to enforce a policy on a user. The following commands create a list of hosts to use for configuring smart tunnel policies:

Detailed Steps

Configuring and Applying a Smart Tunnel Tunnel Policy

Like the split tunnel configuration in SSL VPN client, the smart tunnel tunnel policy is a per group-policy/username configuration. Each group policy/username references a globally configured list of networks:

Detailed Steps

Specifying Servers for Smart Tunnel Auto Sign-on

The Add Smart Tunnel Auto Sign-on Server List dialog box lets you add one or more lists of servers for which to automate the submission of login credentials during smart tunnel setup. The Edit Smart Tunnel Auto-signon Server List dialog box lets you modify the contents of these lists. This feature is available for Internet Explorer and Firefox.

To create a list of servers for which to automate the submission of credentials in smart tunnel connections, enter the following commands:

Detailed Steps