Table Of Contents

Configuring WebVPN

Getting Started with WebVPN

Observing WebVPN Security Precautions

Understanding Features Not Supported for WebVPN

Using SSL to Access the Central Site

Using HTTPS for WebVPN Sessions

Configuring WebVPN and ASDM on the Same Interface

Setting WebVPN HTTP/HTTPS Proxy

Configuring SSL/TLS Encryption Protocols

Authenticating with Digital Certificates

Enabling Cookies on Browsers for WebVPN

Managing Passwords

Using Single Sign-on with WebVPN

Configuring SSO with HTTP Basic or NTLM Authentication

Configuring SSO Authentication Using SiteMinder

Configuring SSO with the HTTP Form Protocol

Authenticating with Digital Certificates

Creating and Applying WebVPN Policies

Creating Port Forwarding, URL, and Access Lists in Global Configuration Mode

Assigning Lists to Group Policies and Users in Group-Policy or User Mode

Enabling Features for Group Policies and Users

Assigning Users to Group Policies

Using the Security Appliance Authentication Server

Using a RADIUS Server

Configuring WebVPN Tunnel Group Attributes

Configuring WebVPN Group Policy and User Attributes

Configuring Application Access

Downloading the Port-Forwarding Applet Automatically

Closing Application Access to Prevent hosts File Errors

Recovering from hosts File Errors When Using Application Access

Understanding the hosts File

Stopping Application Access Improperly

Reconfiguring a hosts File

Configuring File Access

Configuring Access to Citrix MetaFrame Services

Using WebVPN with PDAs

Using E-Mail over WebVPN

Configuring E-mail Proxies

E-mail Proxy Certificate Authentication

Configuring MAPI

Configuring Web E-mail: MS Outlook Web Access

Optimizing WebVPN Performance

Configuring Caching

Configuring Content Transformation

Configuring a Certificate for Signing Rewritten Java Content

Disabling Content Rewrite

Using Proxy Bypass

Configuring Application Profile Customization Framework

APCF Syntax

APCF Example

WebVPN End User Setup

Defining the End User Interface

Viewing the WebVPN Home Page

Viewing the WebVPN Application Access Panel

Viewing the Floating Toolbar

Customizing WebVPN Pages

Using Cascading Style Sheet Parameters

Customizing the WebVPN Login Page

Customizing the WebVPN Logout Page

Customizing the WebVPN Home Page

Customizing the Application Access Window

Customizing the Prompt Dialogs

Applying Customizations to Tunnel Groups, Groups and Users

Requiring Usernames and Passwords

Communicating Security Tips

Configuring Remote Systems to Use WebVPN Features

Capturing WebVPN Data

Creating a Capture File

Using a Browser to Display Capture Data

Configuring WebVPN

---

This chapter includes the following sections:

•Getting Started with WebVPN

•Creating and Applying WebVPN Policies

•Configuring WebVPN Tunnel Group Attributes

•Configuring WebVPN Group Policy and User Attributes

•Configuring Application Access

•Configuring File Access

•Configuring Access to Citrix MetaFrame Services

•Using WebVPN with PDAs

•Using E-Mail over WebVPN

•Optimizing WebVPN Performance

•WebVPN End User Setup

•Capturing WebVPN Data

Getting Started with WebVPN

WebVPN lets users establish a secure, remote-access VPN tunnel to a security appliance using a web browser. Users do not need a software or hardware client.

WebVPN provides secure and easy access to a broad range of web resources and web-enabled applications from almost any computer on the Internet. They include:

•Internal websites

•Web-enabled applications

•NT/Active Directory file shares

•E-mail proxies, including POP3S, IMAP4S, and SMTPS

•MS Outlook Web Access

•MAPI

•Application Access (that is, port forwarding for access to other TCP-based applications)

WebVPN uses Secure Sockets Layer Protocol and its successor, Transport Layer Security to provide the secure connection between remote users and specific, supported internal resources that you configure at a central site. The security appliance recognizes connections that need to be proxied, and the HTTP server interacts with the authentication subsystem to authenticate users.

The network administrator provides access to WebVPN resources to users on a group basis. Users have no direct access to resources on the internal network.

The following sections address getting started with the configuration of WebVPN access:

•Observing WebVPN Security Precautions

•Understanding Features Not Supported for WebVPN

•Using SSL to Access the Central Site

•Authenticating with Digital Certificates

•Enabling Cookies on Browsers for WebVPN

•Managing Passwords

•Using Single Sign-on with WebVPN

•Authenticating with Digital Certificates

Observing WebVPN Security Precautions

WebVPN connections on the security appliance are very different from remote access IPSec connections, particularly with respect to how they interact with SSL-enabled servers, and precautions to reduce security risks.

In a WebVPN connection, the security appliance acts as a proxy between the end user web browser and target web servers. When a WebVPN user connects to an SSL-enabled web server, the security appliance establishes a secure connection and validates the server SSL certificate. The end user browser never receives the presented certificate, so therefore cannot examine and validate the certificate.

The current implementation of WebVPN on the security appliance does not permit communication with sites that present expired certificates. Nor does the security appliance perform trusted CA certificate validation. Therefore, WebVPN users cannot analyze the certificate an SSL-enabled web-server presents before communicating with it.

To minimize the risks involved with SSL certificates:

1. Configure a group policy that consists of all users who need WebVPN access and enable the WebVPN feature only for that group policy.

2. Limit Internet access for WebVPN users. One way to do this is to disable URL entry. Then configure links to specific targets within the private network that you want WebVPN users to be able to access.

3. Educate users. If an SSL-enabled site is not inside the private network, users should not visit this site over a WebVPN connection. They should open a separate browser window to visit such sites, and use that browser to view the presented certificate.

Understanding Features Not Supported for WebVPN

The security appliance does not support the following features for WebVPN connections:

•Inspection features under the Modular Policy Framework, inspecting configuration control.

•Functionality the filter configuration commands provide, including the vpn-filter command.

•NAT, reducing the need for globally unique IP addresses.

•PAT, permitting multiple outbound sessions appear to originate from a single IP address.

•QoS, rate limiting using the police command and priority-queue command.

•Connection limits, checking either via the static or the Modular Policy Framework set connection command.

•The established command, allowing return connections from a lower security host to a higher security host if there is already an established connection from the higher level host to the lower level host.

Using SSL to Access the Central Site

WebVPN uses SSL and its successor, TLS1 to provide a secure connection between remote users and specific, supported internal resources at a central site. This section includes the following topics:

•Using HTTPS for WebVPN Sessions

•Configuring WebVPN and ASDM on the Same Interface

•Setting WebVPN HTTP/HTTPS Proxy

•Configuring SSL/TLS Encryption Protocols

Using HTTPS for WebVPN Sessions

Establishing WebVPN sessions requires the following:

•Using HTTPS to access the security appliance or load balancing cluster. In a web browser, users enter the security appliance IP address in the format https:// address where address is the IP address or DNS hostname of the security appliance interface.

•Enabling WebVPN sessions on the security appliance interface that users connect to.

To permit WebVPN sessions on an interface, perform the following steps:

---

Step 1 In global configuration mode, enter the webvpn command to enter webvpn mode.

Step 2 Enter the enable command with the name of the interface that you want to use for WebVPN sessions.

For example, to enable WebVPN sessions on the interface called outside, enter the following:

hostname(config)# webvpn

hostname(config-webvpn)# enable outside

---

Configuring WebVPN and ASDM on the Same Interface

The security appliance can support both WebVPN connections and HTTPS connections for ASDM administrative sessions simultaneously on the same interface. Both HTTPS and WebVPN use port 443 by default. Therefore, to enable both HTTPS and WebVPN on the same interface, you must specify a different port number for either HTTPS or WebVPN. An alternative is to configure WebVPN and HTTPS on different interfaces.

To specify a port for HTTPS, use the port argument of the http server enable command. The following example specifies that HTTPS ASDM sessions use port 444 on the outside interface. WebVPN is also enabled on the outside interface and uses the default port (443). With this configuration, remote users initiate ASDM sessions by entering https://<outside_ip>:444 in the browser.

hostname(config)# http server enable 444

hostname(config)# http 192.168.3.0 255.255.255.0 outside

hostname(config)# webvpn

hostname(config-webvpn)# enable outside

To specify a port for WebVPN, use the port command from webvpn configuration mode. The next example enables WebVPN on port 444 of the outside interface. HTTPS for ASDM is also configured on the outside interface and uses the default port (443). With this configuration, remote users initiating WebVPN sessions enter https://<outside_ip>:444 in the browser.

hostname(config)# http server enable

hostname(config)# http 192.168.3.0 255.255.255.0 outside

hostname(config)# webvpn

hostname(config-webvpn)# port 444

hostname(config-webvpn)# enable outside

Setting WebVPN HTTP/HTTPS Proxy

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

To set values for HTTP and HTTPS proxy, use the http-proxy and https-proxy commands in webvpn mode. These commands let you identify HTTP and HTTPS proxy servers and ports.

Configuring SSL/TLS Encryption Protocols

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

•Make sure that the security appliance and the browser you use allow the same SSL/TLS encryption protocols.

•If you configure e-mail proxy, do not set the security appliance SSL version to TLSv1 Only.
MS Outlook and MS Outlook Express do not support TLS.

•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 WebVPN user connects with some SSL versions, as follows:

Negotiate SSLv3	Java downloads
Negotiate SSLv3/TLSv1	Java downloads
Negotiate TLSv1	Java does NOT download
TLSv1Only	Java does NOT download
SSLv3Only	Java does NOT download

Authenticating with Digital Certificates

SSL uses digital certificates for authentication. The security appliance creates a self-signed SSL server certificate when it boots; or you can install in the security appliance 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 security appliance only once.

Restrictions for authenticating users with digital certificates include the following:

•Application Access does not work for WebVPN users 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 proxy supports certificate authentication with Netscape 7.x e-mail clients only. Other 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 "Using Certificates and User Login Credentials" in the "Configuring AAA Servers and the Local Database" chapter.

Enabling Cookies on Browsers for WebVPN

Browser cookies are required for the proper operation of WebVPN. 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.

Managing Passwords

You can configure the security appliance to warn end users when their passwords are about to expire. To do this, you specify the password-management command in tunnel-group general-attributes mode.

When you configure this command, the security appliance notifies the remote user at login that the user's current password is about to expire or has expired. The security appliance 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; that is, RADIUS, RADIUS with an NT server, and LDAP servers. The security appliance ignores this command if RADIUS or LDAP authentication has not been configured.

Note that this does not change the number of days before the password expires, but rather specifies the number of days ahead of expiration that the security appliance starts warning the user that the password is about to expire. The default value is 14 days.

For LDAP server authentication only, you can use the password-expire-in-days keyword to specify a specific number of days. If you specify the password-expire-in-days keyword, you must also specify the number of days.

Specifying this command with the number of days set to 0 disables this command. The security appliance then does not notify the user of the pending expiration, but the user can change the password after it expires.

The following example sets the days before password expiration to begin warning the user of the pending expiration to 90 for the tunnel group "testgroup":

hostname(config)# tunnel-group testgroup type webvpn

hostname(config)# tunnel-group testgroup general-attributes

hostname(config-general)# password-management password-expire-in-days 90

Using Single Sign-on with WebVPN

Single sign-on support lets WebVPN users enter a username and password only once to access multiple protected services and web servers. In general, the SSO mechanism either starts as part of the AAA process or just after successful user authentication to a AAA server. The WebVPN server running on the security appliance acts as a proxy for the user to the authenticating server. When a user logs in, the WebVPN server sends an SSO authentication request, including username and password, to the authenticating server using HTTPS. If the server approves the authentication request, it returns an SSO authentication cookie to the WebVPN server. The security appliance keeps this cookie on behalf of the user and uses it to authenticate the user to secure websites within the domain protected by the SSO server.

This section describes the three SSO authentication methods supported by WebVPN: HTTP Basic and NTLMv1 (NT LAN Manager) authentication, the Computer Associates eTrust SiteMinder SSO server (formerly Netegrity SiteMinder), and the HTTP Form protocol.

This section includes:

•Configuring SSO with HTTP Basic or NTLM Authentication

•Configuring SSO Authentication Using SiteMinder

•Configuring SSO with the HTTP Form Protocol

Configuring SSO with HTTP Basic or NTLM Authentication

This section describes single sign-on with HTTP Basic or NTLM authentication. You can configure the security appliance to implement SSO using either or both of these methods. The auto-signon command configures the security appliance to automatically pass WebVPN user login credentials (username and password) on to internal servers. You can enter multiple auto-signon commands. The security appliance 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:

Mode	Scope
Webvpn configuration	All WebVPN users globally
Webvpn group configuration	A subset of WebVPN users defined by a group policy
Webvpn username configuration	An individual WebVPN user

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

All Users, IP Address Range, NTLM

To configure auto-signon for all WebVPN users to servers with IP addresses ranging from 10.1.1.0 to 10.1.1.255 using NTLM authentication, for example, enter the following commands:

hostname(config)# webvpn

hostname(config-webvpn)# auto-signon allow ip 10.1.1.1 255.255.255.0 auth-type ntlm 

All Users, URI Range, HTTP Basic

To configure auto-signon for all WebVPN users, using basic HTTP authentication, to servers defined by the URI mask https://*.example.com/*, for example, enter the following commands:

hostname(config)# webvpn

hostname(config-webvpn)# auto-signon allow uri https://*.example.com/* auth-type basic

Group, URI Range, HTTP Basic and NTLM

To configure auto-signon for WebVPN users ExamplePolicy group policy, using either basic 
or NTLM authentication, to servers defined by the URI mask https://*.example.com/*, for 
example, enter the following commands:

hostname(config)# group-policy ExamplePolicy attributes 

hostname(config-group-policy)# webvpn 

hostname(config-group-webvpn)# auto-signon allow uri https://*.example.com/* auth-type all

Specific User, IP Address Range, HTTP Basic

To configure auto-signon for a user named Anyuser to servers with IP addresses ranging from 10.1.1.0 to 10.1.1.255 using HTTP Basic authentication, for example, enter the following commands:

hostname(config)# username Anyuser attributes

hostname(config-username)# webvpn

hostname(config-username-webvpn)# auto-signon allow ip 10.1.1.1 255.255.255.0 auth-type 
basic

Configuring SSO Authentication Using SiteMinder

This section describes configuring the security appliance 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. If you want to configure SSO for a WebVPN user or group, you must first configure a AAA server, such as a RADIUS or LDAP server. You can then setup SSO support for WebVPN. This section includes:

•Task Overview: Configuring SSO with Siteminder

•Detailed Tasks: Configuring SSO with Siteminder

•Adding the Cisco Authentication Scheme to SiteMinder

Task Overview: Configuring SSO with Siteminder

This section presents an overview of the tasks necessary to configure SSO with SiteMinder SSO. These tasks are:

•Specifying the SSO server.

•Specifying the URL of the SSO server to which the security appliance makes SSO authentication requests.

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

In addition to these required tasks, you can optionally do the following configuration tasks:

•Configuring the authentication request timeout.

•Configuring the number of authentication request retries.

After you have completed the configuration tasks, you assign an SSO server to a user or group policy.

Detailed Tasks: Configuring SSO with Siteminder

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

---

Step 1 In webvpn configuration mode, enter the sso-server command with the type option to create an SSO server. For example, to create an SSO server named Example of type siteminder, enter the following:

hostname(config)# webvpn

hostname(config-webvpn)# sso-server Example type siteminder

hostname(config-webvpn-sso-siteminder)#

---

Note The security appliance currently supports only the SSO server type siteminder.

---

Step 2 Enter the web-agent-url command in webvpn-sso-siteminder configuration mode to specify the authentication URL of the SSO server. For example, to send authentication requests to the URL http://www.Example.com/webvpn, enter the following:

hostname(config-webvpn-sso-siteminder)# web-agent-url http://www.Example.com/webvpn

hostname(config-webvpn-sso-siteminder)#

Step 3 Specify a secret key to secure the authentication communications between the security appliance and SiteMinder using the policy-server-secret command in webvpn-sso-siteminder configuration mode. You can create a key of any length using any regular or shifted alphanumeric character, but you must enter the same key on both the security appliance and the SSO server.

For example, to create the secret key AtaL8rD8!, enter the following:

hostname(config-webvpn-sso-siteminder)# policy-server-secret AtaL8rD8!

hostname(config-webvpn-sso-siteminder)#

Step 4 Optionally, you can configure the number of seconds before a failed SSO authentication attempt times out using the request-timeout command in webvpn-sso-siteminder configuration mode. The default number of seconds is 5 seconds and the possible range is 1 to 30 seconds. To change the number of seconds before a request times out to 8, for example, enter the following:

hostname(config-webvpn-sso-siteminder)# request-timeout 8

hostname(config-webvpn-sso-siteminder)#

Step 5 Optionally, you can configure the number of times the security appliance retries a failed SSO authentication attempt before the authentication times-out using the max-retry-attempts command in webvpn-sso-siteminder configuration mode. The default is 3 retry attempts and the possible range is 1 to 5 attempts. To configure the number of retries to be 4, for example, enter the following:

hostname(config-webvpn-sso-siteminder)# max-retry-attempts 4

hostname(config-webvpn-sso-siteminder)#

Step 6 After you configure the SSO server, you must specify SSO authentication for either a group or user. To specify SSO for a group, assign an SSO server to a group policy using the sso-server value command in group-policy-webvpn configuration mode. To specify SSO for a user, assign an SSO server to a user policy using the same command, sso-server value, but in username-webvpn configuration mode. For example, to assign the SSO server named Example to the user named Anyuser, enter the following:

hostname(config)# username Anyuser attributes

hostname(config-username)# webvpn

hostname(config-username-webvpn)# sso-server value Example

hostname(config-group-webvpn)#

Step 7 Finally, you can test the SSO server configuration using the test sso-server command in privileged EXEC mode. For example, to test the SSO server named Example using the username Anyuser, enter the following:

hostname# test sso-server Example username Anyuser

INFO: Attempting authentication request to sso-server Example for user Anyuser

INFO: STATUS: Success

hostname#

Adding the Cisco Authentication Scheme to SiteMinder

Besides configuring the security appliance for SSO with SiteMinder, you must also configure your CA SiteMinder Policy Server with the Cisco authentication scheme, provided as a Java plug-in.

---

Note•Configuring the SiteMinder Policy Server requires experience with SiteMinder.

•This section presents general tasks, not a complete procedure.

•Refer to the CA SiteMinder documentation for the complete procedure for adding a custom authentication scheme.

---

To configure the Cisco authentication scheme on your SiteMinder Policy Server, perform these following tasks:

---

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 security appliance.

You configure this on the security appliance with either the policy-server-secret command at the command line interface or in the Secret Key field of the Add SSO Server dialog in ASDM.

•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/pcgi-bin/tablebuild.pl/asa and copy it to the default library directory for the SiteMinder server.

Configuring SSO with the HTTP Form Protocol

This section describes using the HTTP Form protocol for SSO. HTTP Form protocol is a common approach to SSO authentication that can also qualify as a AAA method. It provides a secure method for exchanging authentication information between WebVPN users and authenticating web servers. As a common protocol, it is highly compatible with web servers and web-based SSO products, and you can use it in conjunction with other AAA servers such as RADIUS or LDAP servers.

---

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

---

The security appliance again serves as a proxy for WebVPN users to an authenticating web server but, in this case, it uses HTTP Form protocol and the POST method for requests. You must configure the security appliance to send and receive form data. Figure 37-1 illustrates the following SSO authentication steps:

1. A WebVPN user first enters a username and password to log into the WebVPN server on the security appliance.

2. The WebVPN 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.

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

4. The WebVPN server establishes a tunnel to the user.

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

Figure 37-1 SSO Authentication Using HTTP Forms

While you would expect to configure form parameters that let the security appliance 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 security appliance 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:

<param name>=<URL encoded value>&<param name>=<URL encoded> 

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.

This section describes:

•Gathering HTTP Form Data

•Task Overview: Configuring SSO with HTTP Form Protocol

•Detailed Tasks: Configuring SSO with HTTP Form Protocol

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:

---

Note These steps require a browser and an HTTP header analyzer.

---

---

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

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-83 
846dc90034&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$5FZmjnk3DRNwNjk2KcqVCFbIrNT9%2b 
J0H0KPshFtg6rB1UV2PxkHqLw%3d%3d&TARGET=https%3A%2F%2Fwww.example.com%2Femco%2Fmyemco%2F 
HTTP/1.1

Host: www.example.com

(BODY)

SMENC=ISO-8859-1&SMLOCALE=US-EN&USERID=Anyuser&USER_PASSWORD=XXXXXX&target=https%3A%2F%2F 
www.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 37-2 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 37-2 Action-uri, hidden, username and password parameters

1	Action URI parameter
2	Hidden parameters
3	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.

Set-Cookie:

SMSESSION=yN4Yp5hHVNDgs4FT8dn7+Rwev41hsE49XlKc+1twie0gqnjbhkTkUnR8XWP3hvDH6PZPbHIHtWLDKTa8 
ngDB/lbYTjIxrbDx8WPWwaG3CxVa3adOxHFR8yjD55GevK3ZF4ujgU1lhO6fta0dSSOSepWvnsCb7IFxCw+MGiw0o8 
8uHa2t4l+SillqfJvcpuXfiIAO06D/gtDF40Ow5YKHEl2KhDEvv+yQzxwfEz2cl7Ef5iMr8LgGcDK7qvMcvrgUqx68 
JQOK2+RSwtHQ15bCZmsDU5vQVCvSQWC8OMHNGwpS253XwRLvd/h6S/tM0k98QMv+i3N8oOdj1V7flBqecH7+kVrU01 
F6oFzr0zM1kMyLr5HhlVDh7B0k9wp0dUFZiAzaf43jupD5f6CEkuLeudYW1xgNzsR8eqtPK6t1gFJyOn0s7QdNQ7q9 
knsPJsekRAH9hrLBhWBLTU/3B1QS94wEGD2YTuiW36TiP14hYwOlCAYRj2/bY3+lYzVu7EmzMQ+UefYxh4cF2gYD8R 
ZL2RwmP9JV5l48I3XBFPNUw/3V5jf7nRuLr/CdfK3OO8+Pa3V6/nNhokErSgyxjzMd88DVzM41LxxaUDhbcmkoHT9I 
mzBvKzJX0J+o7FoUDFOxEdIqlAN4GNqk49cpi2sXDbIarALp6Bl3+tbB4MlHGH+0CPscZXqoi/kon9YmGauHyRs+0m 
6wthdlAmCnvlJCDfDoXtn8DpabgiW6VDTrvl3SGPyQtUv7Wdahuq5SxbUzjY2JxQnrUtwB977NCzYu2sOtN+dsEReW 
J6ueyJBbMzKyzUB4L3i5uSYN50B4PCv1w5KdRKa5p3N0Nfq6RM6dfipMEJw0Ny1sZ7ohz3fbvQ/YZ7lw/k7ods/8Vb 
aR15ivkE8dSCzuf/AInHtCzuQ6wApzEp9CUoG8/dapWriHjNoi4llJOgCst33wEhxFxcWy2UWxs4EZSjsI5GyBnefS 
QTPVfma5dc/emWor9vWr0HnTQaHP5rg5dTNqunkDEdMIHfbeP3F90cZejVzihM6igiS6P/CEJAjE; 
Domain=.example.com;Path=/

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

Figure 37-3 Authorization cookies in sample HTTP analyzer output

1	Authorization cookies

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 security appliance for SSO with HTTP Form protocol.

Task Overview: Configuring SSO with HTTP Form Protocol

This section presents an overview of configuring SSO with the HTTP Form protocol.To enable SSO using HTTP Forms, perform the following tasks:

•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).

Detailed Tasks: Configuring SSO with HTTP Form Protocol

This section presents the detailed tasks required to configure SSO with the HTTP Form protocol. Perform the following steps to configure the security appliance to use HTTP Form protocol for SSO:

---

Step 1 If the authenticating web server requires it, enter the start-url command in aaa-server-host configuration mode to specify the URL from which to retrieve a pre-login cookie from the authenticating web server. For example, to specify the authenticating web server URL http://example.com/east/Area.do?Page-Grp1 in the testgrp1 server group with an IP address of 10.0.0.2, enter the following:

hostname(config)# aaa-server testgrp1 host 10.0.0.2

hostname(config-aaa-server-host)# start-url http://example.com/east/Area.do?Page-Grp1

hostname(config-aaa-server-host)# 

Step 2 To specify a URI for an authentication program on the authenticating web server, enter the action-uri command in aaa-server- host configuration mode. A URI can be entered on multiple, sequential lines. The maximum number of characters per line is 255. The maximum number of characters for a complete URI is 2048. An example action URI follows:

http://www.example.com/auth/index.html/appdir/authc/forms/MCOlogin.fcc?TYPE=33554433&REALM
OID=06-000a1311-a828-1185-ab41-8333b16a0008&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$S
M$5FZmjnk3DRNwNjk2KcqVCFbIrNT9%2bJ0H0KPshFtg6rB1UV2PxkHqLw%3d%3d&TARGET=https%3A%2F%2Fauth
.example.com

To specify this action URI, enter the following commands:

hostname(config-aaa-server-host)# action-uri http://www.example.com/auth/index.htm

hostname(config-aaa-server-host)# action-uri l/appdir/authc/forms/MCOlogin.fcc?TYP

hostname(config-aaa-server-host)# action-uri 554433&REALMOID=06-000a1311-a828-1185

hostname(config-aaa-server-host)# action-uri -ab41-8333b16a0008&GUID=&SMAUTHREASON

hostname(config-aaa-server-host)# action-uri =0&METHOD=GET&SMAGENTNAME=$SM$5FZmjnk

hostname(config-aaa-server-host)# action-uri 3DRNwNjk2KcqVCFbIrNT9%2bJ0H0KPshFtg6r

hostname(config-aaa-server-host)# action-uri B1UV2PxkHqLw%3d%3d&TARGET=https%3A%2F

hostname(config-aaa-server-host)# action-uri %2Fauth.example.com

hostname(config-aaa-server-host)#

---

Note You must include the hostname and protocol in the action URI. In the preceding example, these appear at the start of the URI in http://www.example.com.

---

Step 3 To configure a username parameter for the HTTP POST request, enter the user-parameter command in aaa-server-host configuration mode. For example, the following command configures the username parameter userid:

hostname(config-aaa-server-host)# user-parameter userid

hostname(config-aaa-server-host)#

Step 4 To configure a user password parameter for the HTTP POST request, use the password-parameter command in aaa-server-host configuration mode. For example, the following command configures a user password parameter named user_password:

hostname(config-aaa-server-host)# password-parameter user_password

hostname(config-aaa-server-host)#

Step 5 To specify hidden parameters for exchange with the authenticating web server, use the hidden-parameter command in aaa-server-host configuration mode. An example hidden parameter excerpted from a POST request follows:

SMENC=ISO-8859-1&SMLOCALE=US-EN&target=https%3A%2F%2Fwww.example.com%2Femco%2Fappdir%2FAreaRoot.do%3FEMCOPageCode%3DENG&smauthreason=0

This hidden parameter includes four form entries and their values, separated by &. The four entries and their values are:

•SMENC with a value of ISO-8859-1

•SMLOCALE with a value of US-EN

•target with a value of https%3A%2F%2Fwww.example.com%2Femco%2Fappdir%2FAreaRoot.do

%3FEMCOPageCode%3DENG

•smauthreason with a value of 0

To specify this hidden parameter, enter the following commands:

hostname(config)# aaa-server testgrp1 host example.com

hostname(config-aaa-server-host)# hidden-parameter SMENC=ISO-8859-1&SMLOCALE=US-EN&targe

hostname(config-aaa-server-host)# hidden-parameter t=https%3A%2F%2Fwww.example.com%2Femc

hostname(config-aaa-server-host)# hidden-parameter o%2Fappdir%2FAreaRoot.do%3FEMCOPageCo

hostname(config-aaa-server-host)# hidden-parameter de%3DENG&smauthreason=0

hostname(config-aaa-server-host)# 

Step 6 To specify the name for the authentication cookie, enter the auth-cookie-name command in aaa-server-host configuration mode. This command is optional. The following example specifies the authentication cookie name of SsoAuthCookie:

hostname(config-aaa-server-host)# auth-cookie-name SsoAuthCookie

hostname(config-aaa-server-host)# 

---

Authenticating with Digital Certificates

WebVPN 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 "Using Certificates and User Login Credentials" in the "Configuring AAA Servers and the Local Database" chapter.

Creating and Applying WebVPN Policies

Creating and applying WebVPN policies that govern access to resources at the central site includes the following tasks:

•Creating Port Forwarding, URL, and Access Lists in Global Configuration Mode

•Assigning Lists to Group Policies and Users in Group-Policy or User Mode

•Enabling Features for Group Policies and Users

•Assigning Users to Group Policies

Chapter 30, "Configuring Tunnel Groups, Group Policies, and Users" includes step-by-step instructions for all of these tasks.

Creating Port Forwarding, URL, and Access Lists in Global Configuration Mode

Use the port forward, url-list, and access-list commands in global configuration mode to configure the lists of ports to forward and URLs to present to WebVPN users, and their level of access. See

Assigning Lists to Group Policies and Users in Group-Policy or User Mode

After you configure port forwarding and URL lists, use the port forward and url-list, and filter commands in webvpn group-policy or user mode to assign lists to group policies and/or users.

Enabling Features for Group Policies and Users

To enable features for group policies and users, issue the functions command in group-policy or user configuration mode.

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 or a RADIUS server to assign users to group policies. See Chapter 30, "Configuring Tunnel Groups, Group Policies, and Users"for a thorough explanation of ways to simplify configuration with group policies.

Using the Security Appliance Authentication Server

You can configure users to authenticate to the security appliance internal authentication server, and assign these users to a group policy on the security appliance.

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 set a WebVPN user to the SSL_VPN group, set the RADIUS Class Attribute to a value of OU=SSL_VPN; (Do not omit the semicolon.)

---

Configuring WebVPN Tunnel Group Attributes

Table 37-1 provides a list of tunnel group attributes that are specific to WebVPN. In addition to these attributes, you configure general tunnel group attributes common to all VPN connections. For step-by-step information on configuring tunnel groups, see "Configuring WebVPN Tunnel Groups" in Chapter 30, "Configuring Tunnel Groups, Group Policies, and Users."

Table 37-1 WebVPN Tunnel Group Attributes

Command	Function
authentication	Sets the authentication method.
customization	Identifies the name of a previously defined customization to apply.
nbns-server	Identifies the name of the NetBIOS Name Service server (nbns-server) to use for CIFS name resolution.
group-alias	Specifies the alternate names by which the server can refer to a tunnel group
group-url	Identifies one or more group URLs. If you configure this attribute, users coming in on a specified URL need not select a group at login
dns-group	Identifies the DNS server group that specifies the DNS server name, domain name, name server, number of retries, and timeout values
hic-fail-group-policy	Specifies a VPN feature policy if you use the Cisco Secure Desktop Manager to set the Group-Based Policy attribute to "Use Failure Group-Policy" or "Use Success Group-Policy, if criteria match."

Configuring WebVPN Group Policy and User Attributes

Table 37-2 provides a list of WebVPN group policy and user attributes. For step-by-step instructions on configuring group policy and user attributes, see "Configuring Group Policies" and "Configuring Attributes for Specific Users"in Chapter 30, "Configuring Tunnel Groups, Group Policies, and Users."

.

Table 37-2 WebVPN Group Policy and User Attributes

Command	Function
auto-signon	Sets values for auto signon, which requires only that s user enter username and password credentials only once for a WebVPN connection.
customization	Assigns a customization object to a group-policy or user.
deny-message	Specifies the message delivered to a remote user who logs into WebVPN successfully, but has no VPN privileges.
filter	Sets the name of the webtype access list.
functions	Enables some or all of these WebVPN features: auto-download, Citrix, file access, file browsing, file entry, filter, http-proxy, URL entry, MAPI proxy, port forwarding.
homepage	Sets the URL of the web page that displays upon login.
html-content-filter	Configures the content and objects to filter from the HTML for this group policy.
http-comp	Configures compression.
keep-alive-ignore	Sets the maximum object size to ignore for updating the session timer.
port-forward	Applies a list of WebVPN TCP ports to forward. The user interface displays the applications on this list.
port-forward-name	Configures the name of the port forwarding applet.
sso-server	Sets the name of the SSO server.
svc	Configures SSL VPN Client attributes.
url-list	Applies a list of WebVPN servers and URLs that the user interface displays for end user access.

Configuring Application Access

The following sections provide information about configuring application access:

Downloading the Port-Forwarding Applet Automatically

Closing Application Access to Prevent hosts File Errors

Recovering from hosts File Errors When Using Application Access

Downloading the Port-Forwarding Applet Automatically

To run a remote application over WebVPN, a user clicks Start Application Access on the WebVPN homepage to download and start a port-forwarding Java applet. To simplify application access and shorten start time, you can configure WebVPN to automatically download this port-forwarding applet when the user first logs in to WebVPN.

To enable automatic download of the port-forwarding applet, enter the functions command in webvpn mode using the auto-download option.

---

Note Before you configure the auto-download feature, you must first enable an application that uses the applet: port forwarding, Outlook/Exchange proxy, or HTTP proxy.

---

Closing Application Access to Prevent hosts File Errors

To prevent hosts file errors that can interfere with Application Access, close the Application Access window properly when you finish using Application Access. To do so, click the close icon.

Recovering from hosts File Errors When Using Application Access

The following errors can occur if you do not close the Application Access window properly:

•The next time you try to start Application Access, it might be disabled; you receive a Backup HOSTS File Found error message.

•The applications themselves might be disabled or might malfunction, even when you are running them locally.

These errors can result from terminating the Application Access window in any improper way. For example:

•Your browser crashes while you are using Application Access.

•A power outage or system shutdown occurs while you are using Application Access.

•You minimize the Application Access window while you are working, then shut down your computer with the window active (but minimized).

This section includes the following topics:

•Understanding the hosts File

•Stopping Application Access Improperly

•Reconfiguring a hosts File

Understanding the hosts File

The hosts file on your local system maps IP addresses to host names. When you start Application Access, WebVPN modifies the hosts file, adding WebVPN-specific entries. Stopping Application Access by properly closing the Application Access window returns the file to its original state.

Before invoking Application Access...	hosts file is in original state.
When Application Access starts....	•WebVPN copies the hosts file to hosts.webvpn, thus creating a backup. •WebVPN then edits the hosts file, inserting WebVPN-specific information.
When Application Access stops...	•WebVPN copies the backup file to the hosts file, thus restoring the hosts file to its original state. •WebVPN deletes hosts.webvpn.
After finishing Application Access...	hosts file is in original state.

---

Note Microsoft anti-spyware software blocks changes that the port forwarding JAVA applet makes to the hosts file. See www.microsoft.com for information on how to allow hosts file changes when using anti-spyware software.

---

Stopping Application Access Improperly

When Application Access terminates abnormally, the hosts file remains in a WebVPN-customized state. WebVPN checks the state the next time you start Application Access by searching for a hosts.webvpn file. If it finds one, a Backup HOSTS File Found error message (Figure 37-4) appears, and Application Access is temporarily disabled.

Once you shut down Application Access improperly, you leave your remote access client/server applications in limbo. If you try to start these applications without using WebVPN, they might malfunction. You might find that hosts that you normally connect to are unavailable. This situation could commonly occur if you run applications remotely from home, fail to quit the Application Access window before shutting down the computer, then try to run the applications later from the office.

Reconfiguring a hosts File

To reenable Application Access or malfunctioning applications:

•If you are able to connect to your remote access server, follow the steps in the section "Reconfiguring a hosts File Automatically Using WebVPN."

•If you are unable to connect to your remote access server from your current location or if you have made custom edits to the hosts file, follow the steps in the section "Reconfiguring hosts File Manually."

Reconfiguring a hosts File Automatically Using WebVPN

If you are able to connect to your remote access server, follow these steps to reconfigure the hosts file and reenable both Application Access and the applications.

---

Step 1 Start WebVPN and log in. The home page opens.

Step 2 Click the Applications Access