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.
- 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 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.
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.
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 website.
Configuring the SiteMinder policy server requires experience with SiteMinder.
This section presents general tasks, not a complete procedure.
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 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.
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.
To configure SSO with the HTTP protocol correctly, you must have a thorough working knowledge of authentication and HTTP protocol exchanges.
As a common protocol, it is applicable only when the following conditions are met for the Web server application used for authentication:
- 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.
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 16-4 illustrates the following SSO authentication steps:
Step 1 A user of Clientless SSL VPN first enters a username and password to log on to 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 re-entering a username and password.
Figure 16-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 may 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:
<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.
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.
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 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 on 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:
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:
Figure 16-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 16-5 Action-uri, hidden, username and password parameters
Step 6 If you successfully log on 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 16-6 shows an example of authorization cookies in HTTP analyzer output. This is only an example; output varies widely across different websites.
Figure 16-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.
Using Auto Sign-On
The Auto Sign-on window or tab lets you configure or edit auto sign-on for users of Clientless SSL VPN. Auto sign-on is a simplified single sign-on method that you can use if you do not already have an SSO method deployed on your internal network. With auto sign-on configured for particular internal servers, the ASA passes the login credentials that the user of Clientless SSL VPN entered to log on to the ASA (username and password) to those particular internal servers. You configure the ASA to respond to a specific authentication method for a particular range of servers. The authentication methods you can configure the ASA to respond to consists of authentication using Basic (HTTP), NTLM, FTP and CIFS, or all of these methods.
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-on is available.
Auto sign-on is a straight-forward method for configuring SSO for particular internal servers. This section describes the procedure for setting up SSO with auto sign-on. If you already have SSO deployed using Computer Associates SiteMinder SSO server, or if you have Security Assertion Markup Language (SAML) Browser Post Profile SSO. To configure the ASA to support this solution, see the “SSO Servers” section.
The following fields are displayed:
- IP Address—In conjunction with the following Mask, displays the IP address range of the servers to be authenticated to as configured with the Add/Edit Auto Sign-on dialog box. You can specify a server using either the server URI or the server IP address and mask.
- Mask—In conjunction with the preceding IP Address, displays the IP address range of the servers configured to support auto sign-on with the Add/Edit Auto Sign-on dialog box.
- URI—Displays a URI mask that identifies the servers configured with the Add/Edit Auto Sign-on dialog box.
- Authentication Type—Displays the type of authentication—Basic (HTTP), NTLM, FTP and CIFS, or all of these methods—as configured with the Add/Edit Auto Sign-on dialog box.
- Do not enable auto sign-on for servers that do not require authentication or that use credentials different from the ASA. When auto sign-on is enabled, the ASA passes on the login credentials that the user entered to log on to 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.
Step 1 Click to add or edit an auto sign-on instruction. An auto sign-on instruction defines a range of internal servers using the auto sign-on feature and the particular authentication method.
Step 2 Click to delete an auto sign-on instruction selected in the Auto Sign-on 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 sign-on.
Step 4 Click URI to specify a server supporting auto sign-on 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.
Requiring Usernames and Passwords
Depending on your network, during a remote session users may have to log on to any or all of the following: the computer itself, an Internet service provider, Clientless SSL VPN, mail or file servers, or corporate applications. Users may have to authenticate in many different contexts, requiring different information, such as a unique username, password, or PIN.
Table 16-1 lists the type of usernames and passwords that Clientless SSL VPN users may need to know.
Table 16-1 Usernames and Passwords to Give to Users of Clientless SSL VPN Sessions
Access the computer
Starting the computer
Internet Service Provider
Access the Internet
Connecting to an Internet service provider
Clientless SSL VPN
Access remote network
Starting Clientless SSL VPN
Access remote file server
Using the Clientless SSL VPN file browsing feature to access a remote file server
Corporate Application Login
Access firewall-protected internal server
Using the Clientless SSL VPN Web browsing feature to access an internal protected website
Access remote mail server via Clientless SSL VPN
Sending or receiving email messages
Configuring Remote Systems to Use Clientless SSL VPN Features
This section describes how to set up remote systems to use Clientless SSL VPN and includes the following topics:
You may configure user accounts differently and different Clientless SSL VPN features can be available to each user.
Starting Clientless SSL VPN
You can connect to the internet using any supported connection including:
- Home DSL, cable, or dial-ups.
- Public kiosks.
- Hotel hotspots.
- Airport wireless nodes.
- Internet cafes.
NoteSee theSupported VPN Platforms, Cisco ASA 5500 Series for the list of Web browsers supported by Clientless SSL VPN.
- Cookies must be enabled on the browser in order to access applications via port forwarding.
- You must have a URL for Clientless SSL VPN. The URL must be an https address in the following form: https: //address , where address is the IP address or DNS hostname of an interface of the ASA (or load balancing cluster) on which SSL VPN is enabled. For example, https://cisco.example.com.
- You must have a Clientless SSL VPN username and password.
- Clientless SSL VPN supports local printing, but it does not support printing through the VPN to a printer on the corporate network.
Using the Clientless SSL VPN Floating Toolbar
A floating toolbar is available to simplify the use of Clientless SSL VPN. The toolbar lets you enter URLs, browse file locations, and choose preconfigured Web connections without interfering with the main browser window.
The floating toolbar represents the current Clientless SSL VPN session. If you click the Close button, the ASA prompts you to close the Clientless SSL VPN session.
Tip To paste text into a text field, use Ctrl-V. (Right-clicking is switched off on the toolbar displayed during the Clientless SSL VPN session.)
If you configure your browser to block popups, the floating toolbar cannot display.
Browsing the Web
Using Clientless SSL VPN does not ensure that communication with every site is secure. See Communicating Security Tips.
The look and feel of Web browsing with Clientless SSL VPN may be different from what users are accustomed to. For example:
- The title bar for Clientless SSL VPN appears above each Web page.
- You access websites by:
– Entering the URL in the Enter Web Address field on the Clientless SSL VPN Home page
– Clicking on a preconfigured website link on the Clientless SSL VPN Home page
– Clicking a link on a webpage accessed via one of the previous two methods
Also, depending on how you configured a particular account, it may be that:
- Some websites are blocked
- Only the websites that appear as links on the Clientless SSL VPN Home page are available
You need the username and password for protected websites.
Also, depending on how you configured a particular account, it may be that:
- Some websites are blocked
- Only the websites that appear as links on the Clientless SSL VPN Home page are available
Browsing the Network (File Management)
Users may not be familiar with how to locate their files through your organization network.
NoteDo not interrupt theCopy File to Server command or navigate to a different screen while the copying is in progress. Interrupting the operation can cause an incomplete file to be saved on the server.
- You must configure file permissions for shared remote access.
- You must have the server names and passwords for protected file servers.
- You must have the domain, workgroup, and server names where folders and files reside.
Only shared folders and files are accessible via Clientless SSL VPN.
Using the Remote File Explorer
The Remote File Explorer provides the user with a way to browse the corporate network from their Web browser. When the users clicks the Remote File System icon on the Cisco SSL VPN portal page, an applet is launched on the user’s system displaying the remote file system in a tree and folder view.
Figure 16-7 Clientless SSL VPN Remote File Explorer
The browser enables the user to:
- Browse the remote file system.
- Rename files.
- Move or copy files within the remote file system and between the remote and local file systems.
- Perform bulk uploads and downloads of files.
NoteThis functionality requires that the Oracle Java Runtime Environment (JRE) 1.4 or later is installed on the user’s machine and that Java is enabled in the Web browser. Launching remote files requires JRE 1.6 or later.
Renaming a File or Folder
To rename a file or folder:
Step 1 Click the file or folder to be renamed.
Step 2 Select Edit > Rename.
Step 3 When prompted, enter the new name in the dialog.
Step 4 Click OK to rename the file or folder. Alternative, click Cancel to leave the name unchanged.
Moving or Copying Files or Folders on the Remote Server
To move or copy a file or folder on the remote server:
Step 1 Navigate to the source folder containing the file or folder to be moved or copied.
Step 2 Click the file or folder.
Step 3 To copy the file select Edit > Copy. Alternatively, to move the file select Edit > Cut.
Step 4 Navigate to the destination folder.
Step 5 Select Edit > Paste.
Copying Files from the Local System Drive to the Remote Folder
You can copy files between the local file system and the remote file system by dragging and dropping them between the right pane of the Remote File Browser and your local file manager application.
Uploading and Downloading Files
You can download a file by clicking it in the browser, selecting Operations > Download, and providing a location and name to save the file in the Save dialog.
You can upload a file by clicking the destination folder, selecting Operations > Upload, and providing the location and name of the file in the Open dialog,
This functionality has the following restrictions:
- The user cannot view sub-folders for which they are not permitted access.
- Files that the user is not permitted to access cannot be moved or copied, even though they are displayed in the browser.
- The maximum depth of nested folders is 32.
- The tree view does not support drag and drop copying.
- When moving files between multiple instances of the Remote File Explorer, all instances must be exploring the same server (root share).
- The Remote File Explorer can display a maximum of 1500 files and folders in a single folder. If a folder exceeds this limit the folder cannot be displayed.
- On Mac OS X, only the Safari browser supports this feature.
- You must have client applications installed.
- You must have Cookies enabled on the browser.
- You must have administrator access on the PC if you use DNS names to specify servers, because modifying the hosts file requires it.
- You must have Oracle Java Runtime Environment (JRE) version 1.4.x and 1.5.x installed.
If JRE is not installed, a pop-up window displays, directing users to a site where it is available. On rare occasions, the port forwarding applet fails with Java exception errors. If this happens, do the following:
a. Clear the browser cache and close the browser.
b. Verify that no Java icons are in the computer task bar.
c. Close all instances of Java.
d. Establish a Clientless SSL VPN session and launch the port forwarding Java applet.
- If necessary, you must configure client applications.
Note The Microsoft Outlook client does not require this configuration step. All non-Windows client applications require configuration. To determine if configuration is necessary for a Windows application, check the value of the Remote Server field. If the Remote Server field contains the server hostname, you do not need to configure the client application. If the Remote Server field contains an IP address, you must configure the client application.
Because this feature requires installing Oracle Java Runtime Environment (JRE) and configuring the local clients, and because doing so requires administrator permissions on the local system or full control of C:\windows\System32\drivers\etc, it is unlikely that users will be able to use applications when they connect from public remote systems.
To configure the client application, use the server’s locally mapped IP address and port number. To find this information:
1. Start a Clientless SSL VPN session and click the Application Access link on the Home page. The Application Access window appears.
2. In the Name column, find the name of the server to use, then identify its corresponding client IP address and port number (in the Local column).
3. Use this IP address and port number to configure the client application. Configuration steps vary for each client application.
Note Clicking a URL (such as one in an -email message) in an application running over a Clientless SSL VPN session does not open the site over that session. To open a site over the session, paste the URL into the Enter Clientless SSL VPN (URL) Address field.
Using email Via Port Forwarding
To use email, start Application Access from the Clientless SSL VPN home page. The mail client is then available for use.
NoteIf you are using an IMAP client and you lose your mail server connection or are unable to make a new connection, close the IMAP application and restart Clientless SSL VPN.
You must fulfill requirements for application access and other mail clients.
We have tested Microsoft Outlook Express versions 5.5 and 6.0.
Clientless SSL VPN should support other SMTPS, POP3S, or IMAP4S email programs via port forwarding, such as Lotus Notes and Eudora, but we have not verified them.
Using email Via Web Access
The following email applications are supported:
- Microsoft Outlook Web App to Exchange Server 2010.
OWA requires Internet Explorer 7 or later, or Firefox 3.01 or later.
- Microsoft Outlook Web Access to Exchange Server 2007, 2003, and 2000.
For best results, use OWA on Internet Explorer 8.x or later, or Firefox 8.x.
You must have the web-based email product installed.
Other web-based email applications should also work, but we have not verified them.
Using email Via email Proxy
The following legacy email applications are supported:
- Microsoft Outlook 2000 and 2002
- Microsoft Outlook Express 5.5 and 6.0
See the instructions and examples for your mail application in “Using Email over Clientless SSL VPN” section.
- You must have the SSL-enabled mail application installed.
- Do not set the ASA SSL version to TLSv1 Only. Outlook and Outlook Express do not support TLS.
- You must have your mail application properly configured.
Other SSL-enabled clients should also work, but we have not verified them.
Using Smart Tunnel
Administration privileges are not required to use Smart Tunnel.
NoteJava is not automatically downloaded for you as in port forwarder.
- Smart tunnel requires either ActiveX or JRE (1.4x and 1.5x) on Windows and Java Web Start on Mac OS X.
- You must ensure cookies enabled on the browser.