User Guide for Cisco Security Manager 3.2.2
Managing Objects
Downloads: This chapterpdf (PDF - 1.4MB) The complete bookPDF (PDF - 31.94MB) | Feedback

Managing Objects

Table Of Contents

Managing Objects

Introduction to Objects

Creating Objects

Using Category Objects

Guidelines for Managing Objects

Managing Existing Objects

Editing Objects

Deleting Objects

Managing Object Overrides

Duplicating Objects

Generating Object Usage Reports

Viewing Object Details

Understanding AAA Server Group Objects

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Creating AAA Server Group Objects

Understanding AAA Server Objects

Supported AAA Server Types

AAA Support on ASA Devices

Creating AAA Server Objects

Creating Access Control List Objects

Creating Extended Access Control List Objects

Creating Standard Access Control List Objects

Creating Web Access Control List Objects

Understanding How Security Manager Handles ACL Names

Preserving User-Defined ACL Names

How ACL Names Are Generated

Identifying Original ACL Names

Naming Conflicts and Resolutions

Notes on ACL Naming

Understanding ASA User Group Objects

Creating ASA User Group Objects

Understanding Credential Objects

Creating Credential Objects

Understanding File Objects

Creating File Objects

Understanding IKE Proposal Objects

Creating IKE Proposal Objects

Understanding Inspection Map Objects

Creating Class Map Objects

Creating DCE/RPC Map Objects

Creating DNS Map Objects

Creating ESMTP Map Objects

Creating FTP Map Objects

Creating GTP Map Objects

Creating H.323 Map Objects

Configuring HTTP Policy Map Objects

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

Creating IM Map Objects for IOS Devices

Creating IPSec Pass Through Map Objects

Creating NetBIOS Map Objects

Creating SIP Map Objects

Creating Skinny Map Objects

Creating SNMP Map Objects

Creating Regular Expression Group Objects

Creating Regular Expression Objects

Metacharacters Used to Build Regular Expressions

Creating TCP Map Objects

Understanding Interface Role Objects

Creating Interface Role Objects

Specifying Interfaces During Policy Definition

Exceptional Cases When Using Interface Roles

Understanding IPsec Transform Set Objects

IPsec Protocols

IPsec Modes

Creating IPsec Transform Set Objects

Understanding LDAP Attribute Map Objects

Creating LDAP Attribute Map Objects

Understanding Network/Host Objects

Supported IP Address Formats

Contiguous and Discontiguous Network Masks

Creating Network/Host Objects

Using Unspecified Network/Host Objects

Specifying IP Addresses During Policy Definition

Understanding PKI Enrollment Objects

Creating PKI Enrollment Objects

Defining CA Server Properties

Defining PKI Enrollment Parameters

Defining Additional PKI Attributes

Defining the Trusted CA Hierarchy

Understanding Port Forwarding List Objects

Creating Port Forwarding List Objects

Understanding Port List Objects

Creating Port List Objects

Understanding Cisco Secure Desktop Configuration Objects

Creating Cisco Secure Desktop Configuration Objects

Understanding Service Objects

Creating Service Objects

Understanding Single Sign-On Server Objects

Creating Single Sign-On Server Objects

Understanding SLA Monitor Objects

Creating SLA Monitor Objects

Understanding SSL VPN Bookmark Objects

Creating SSL VPN Bookmark Objects

Understanding SSL VPN Customization Objects

Understanding SSL VPN Customization Objects

Localizing SSL VPN Web Pages for ASA Devices

Creating Your Own SSL VPN Logon Page

Creating SSL VPN Customization Objects

Understanding SSL VPN Gateway Objects

Creating SSL VPN Gateway Objects

Understanding SSL VPN Smart Tunnel List Objects

Creating SSL VPN Smart Tunnel List Objects

Understanding Style Objects

Creating Style Objects

Creating Text Objects

Understanding Time Range Objects

Creating Time Range Objects

Creating Traffic Flow Objects

Understanding IP Precedence Bits

Understanding User Group Objects

Creating User Group Objects

Understanding WINS Server List Objects

Creating WINS Server List Objects

Overriding Global Objects for Individual Devices

Allowing a Global Object to Be Overridden

Creating Device-Level Object Overrides

Creating Object Overrides for a Single Device

Creating Object Overrides for Multiple Devices

Deleting Device-Level Object Overrides

Deleting Overrides from the Device Properties Window

Deleting Overrides from the Policy Object Manager window

Selecting Objects for Policies

How Policy Objects are Provisioned as PIX/ASA Object Groups

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

How Port List Objects are Provisioned as PIX/ASA Object Groups

How Service Objects are Provisioned as PIX/ASA Object Groups


Managing Objects


This chapter contains the following topics:

Introduction to Objects

Managing Existing Objects

Understanding AAA Server Group Objects

Understanding AAA Server Objects

Creating Access Control List Objects

Understanding How Security Manager Handles ACL Names

Understanding ASA User Group Objects

Understanding Credential Objects

Understanding File Objects

Understanding IKE Proposal Objects

Understanding Inspection Map Objects

Understanding Interface Role Objects

Understanding IPsec Transform Set Objects

Understanding LDAP Attribute Map Objects

Understanding Network/Host Objects

Understanding PKI Enrollment Objects

Understanding Port Forwarding List Objects

Understanding Port List Objects

Understanding Cisco Secure Desktop Configuration Objects

Understanding Service Objects

Understanding Single Sign-On Server Objects

Understanding SLA Monitor Objects

Understanding SSL VPN Bookmark Objects

Understanding SSL VPN Customization Objects

Understanding SSL VPN Gateway Objects

Understanding SSL VPN Smart Tunnel List Objects

Understanding Style Objects

Creating Text Objects

Understanding Time Range Objects

Creating Traffic Flow Objects

Understanding User Group Objects

Understanding WINS Server List Objects

Overriding Global Objects for Individual Devices

Selecting Objects for Policies

How Policy Objects are Provisioned as PIX/ASA Object Groups

Introduction to Objects

Objects enable you to define logical collections of elements. They are reusable, named components that can be used by other objects and policies. Objects aid policy definition by eliminating the need to define that component each time you define a policy. When used, an object becomes an integral component of the object or policy. This means that if you change the definition of an object, this change is reflected in all objects and policies that reference the object.

Objects facilitate network updates, because you can identify objects separately but maintain them in a central location. For example, you can identify the servers in your network as a network/host object called MyServers, and the protocols to allow on these servers in a service object. You can then create an access rule that permits the service object to access the MyServers network/host object. If a change is made to these servers, you need only update the network/host object and redeploy, instead of trying to locate and edit each rule in which the servers are used.

By default, objects are defined globally. This means that the definition of an object is the same for every object and policy that references it. However, many object types (for example, interface roles) can be overridden at the device level. Thus, you can create an object that works for most of your devices, yet customize the object to match the configuration of a particular device that has slightly different requirements. For more information, see Overriding Global Objects for Individual Devices.

Related Topics

Creating Objects

Guidelines for Managing Objects

Policy Object Manager Window, page F-1

Managing Existing Objects

Understanding How Security Manager Handles ACL Names

Creating Objects

Security Manager provides predefined objects of various types that you can use to define policies. Additionally, you can create your own objects, as required.

You can create objects in one of two ways:

Using the Policy Object Manager window. This option is best suited for situations where you are defining one or more objects outside of the context of defining a particular policy. See Policy Object Manager Window, page F-1.

Using object selectors. When you define a policy that uses objects, object selectors include buttons for creating and editing objects without your having to first leave the policy that you are defining. See Selecting Objects for Policies.

The following topics describe the types of objects that are available in Security Manager and how to create them:

Understanding AAA Server Group Objects

Understanding AAA Server Objects

Creating Access Control List Objects

Understanding ASA User Group Objects

Using Category Objects

Understanding Credential Objects

Understanding File Objects

Understanding FlexConfig Policies and Policy Objects, page 19-1 and Creating FlexConfig Policy Objects, page 19-24 (in Chapter 19, "Managing FlexConfigs")

Understanding IKE Proposal Objects

Understanding Inspection Map Objects

Understanding Interface Role Objects

Understanding IPsec Transform Set Objects

Understanding LDAP Attribute Map Objects

Understanding Network/Host Objects

Understanding PKI Enrollment Objects

Understanding Port Forwarding List Objects

Understanding Port List Objects

Understanding Cisco Secure Desktop Configuration Objects

Understanding Service Objects

Understanding Single Sign-On Server Objects

Understanding SLA Monitor Objects

Understanding SSL VPN Bookmark Objects

Understanding SSL VPN Customization Objects

Understanding SSL VPN Gateway Objects

Understanding SSL VPN Smart Tunnel List Objects

Understanding Style Objects

Creating Text Objects

Understanding Time Range Objects

Creating Traffic Flow Objects

Understanding User Group Objects

Understanding WINS Server List Objects

Related Topics

Introduction to Objects

Guidelines for Managing Objects

Policy Object Manager Window, page F-1

Managing Existing Objects

Using Category Objects

Categories provide an intermediate level of detail to objects. By assigning a category to an object, you can look for the name and color of a category to more easily identify rules and objects in rules tables. You can assign a category to a rule or object when you create the rule, or you can edit the rule or object to include category information later. No device configuration commands are generated for category assignments.

The benefits of assigning categories to policy objects are:

Visibility is improved when you view rules tables using objects that are categorized.

Objects can be filtered in the rules tables based on category, facilitating rule maintenance.

For example, you might want to create a network/host object and keep track of its use for administrative purposes. When you define this network/host object, you associate it with a category. When you view the access rules table, you can easily identify those rules that use your network/host object. You can also filter the table to display only those items associated with the category.

Security Manager includes a set of predefined categories. Although you cannot change the colors, you can change their names and descriptions. The following procedure explains how to change the name and description.

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Categories from the Object Type selector.

Step 3 Click Edit Object to open the Category Editor dialog box (see Category Editor Dialog Box, page F-44).

Step 4 Modify the names and descriptions of the predefined category objects, as required. Names can have a maximum of 128 characters, including special characters and spaces. Descriptions can have a maximum of 1024 characters.

Step 5 Click OK to save your changes.


Guidelines for Managing Objects

You should keep in mind the following guidelines when working with objects:

Object names are not case-sensitive and are limited to 128 characters. You can begin object names with a letter, a number, or an underscore. You can use a mix of letters, numbers, special characters, and spaces for the remainder of the object name. Supported special characters include hyphens (-), underscores (_), periods (.), and plus signs (+).


Note Certain object types, such as AAA Server Groups, ASA User Groups, Inspect Maps, Network Objects, Service objects, and Traffic Flows, have different naming guidelines. For more details, refer to the online help when you are creating each object type.


You can rename an object that is referenced by policies or other objects. Security Manager synchronizes the references with the new object name.

Objects are defined on the global level and are available for use with all relevant policies and other objects. To override the definitions of certain types of objects for specific devices, see Overriding Global Objects for Individual Devices.

If you change the definition of an object, this change is reflected in all policies that reference that object.

Your ability to create multiple objects with the same definition depends on a setting on the Policy Objects page in the Security Manager Administration window (Tools > Security Manager Administration). By default, Security Manager warns you when you create an object whose definition is identical to that of an existing object, but it does not prevent you from proceeding. For more information, see Policy Objects Page, page A-34.

You cannot delete an object that is referenced by policies or other objects.

In certain situations, you might not be allowed to delete an object, even though the usage report indicates that it is not being used by any other objects or policies. For example, if you configured a device with a local policy that uses network/host object A and later replace that local policy with a shared policy that does not use that object, you will still be prevented from deleting object A. This can also happen when Security Manager creates an internal object from the configuration of a discovered device, and the device is later deleted. If you are prevented from deleting an object and you do not find any policies or objects that use that object, we recommend that you submit or discard all pending changes, then try again.

Related Topics

Introduction to Objects

Creating Objects

Policy Object Manager Window, page F-1

How Policy Objects are Provisioned as PIX/ASA Object Groups

Understanding Locking and Objects, page 7-10

Managing Existing Objects

The following topics describe the actions that you can perform on the objects defined in the Policy Object Manager:

Editing Objects

Deleting Objects

Managing Object Overrides

Duplicating Objects

Generating Object Usage Reports

Viewing Object Details

You can access the options for performing all these actions by right-clicking an object in the Policy Object Manager and selecting from the displayed shortcut menu. Not all options are available for all objects. For example, predefined objects cannot be edited, and certain object types cannot be overridden for individual devices.

Related Topics

Guidelines for Managing Objects

Policy Object Manager Window, page F-1

Chapter 9 "Managing Objects"

Editing Objects

You can edit any user-defined object as required. Changes that you make to the object are reflected in all policies (and other objects) that use the object. This procedure describes how to edit an object.


Note Predefined objects cannot be edited, but they can be copied. See Duplicating Objects.



Tip You can also edit objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Determine if the object is being used, and which policies, objects, and devices would be affected by the changes. You can generate a usage report for this purpose. See Generating Object Usage Reports.

Related Topics

Policy Object Manager Window, page F-1

Procedure


Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window appears.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object you want to edit, then select Edit Object.

Step 4 Modify the fields in the Edit dialog box for that object type as required, then click OK to save your changes.


Deleting Objects

You can delete user-defined objects only when they are not being used by policies or other objects. Predefined objects cannot be deleted. If you delete an object for which device-level overrides are defined, all overrides are also deleted.

This procedure describes how to delete user-defined objects.


Note You might be prevented from deleting an unreferenced object from the database, if, for example, you replace a local policy that used the object with a shared policy that does not. If object deletion fails, submit or discard all pending changes (in Workflow mode, submit or discard all pending activities), then try again to delete the object. Alternatively, you can leave unreferenced objects in the database, because they will not affect Security Manager operation.


Before You Begin

Determine if the object is currently being used and which policies, objects, and devices would be affected by the deletion. You can generate a usage report for this purpose. See Generating Object Usage Reports.

You need to remove all references to the object before you can delete it.

Related Topics

Managing Existing Objects

Procedure


Step 1 Select Tools > Policy Object Manager.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click a user-defined object, then select Delete Object.


Tip You can select multiple objects by pressing Ctrl and clicking on the desired objects.


Step 4 When prompted, click Yes to confirm the deletion.


Note To verify that the object was deleted, select Tools > Audit Report and view the generated report.



Managing Object Overrides

From the Policy Object Manager window, you can select a global object that can be overridden and generate a table of device-level overrides that are defined for that global object. For example, you can select a global AAA server group object and view a table of all devices for which you defined a local variation of the global object.

For more information, see Overriding Global Objects for Individual Devices.

Object override definitions are displayed in the Policy Object Override window. This procedure describes how to create, edit, and delete object overrides from this window.

Related Topics

Managing Existing Objects

Creating Object Overrides for a Single Device

Creating Object Overrides for Multiple Devices

Policy Object Manager Window, page F-1

Procedure


Step 1 Select Tools > Policy Object Manager.

Step 2 Select an object type from the Object Type selector to display the table of existing objects of that type.

Step 3 In the work area, select a global object for which device-level overrides have been permitted. These objects are indicated by a green checkmark in the Overridable column. See Allowing a Global Object to Be Overridden.

Step 4 Double-click the checkmark, or right-click the object and select Edit Device Overrides. The Policy Object Overrides window is displayed.

Each device-level override defined for the selected object is displayed in a table containing the name of the device to which the override applies, the category assigned to the object, and the object definition. See Policy Object Overrides Window, page F-181 for a description of the fields in this window.

Step 5 (Optional) Do one of the following:

To create a device-level override, click the New Object button. For more information, see Creating Device-Level Object Overrides.

To edit a device-level override, select the object from the table, then click the Edit Object button.

To delete a device-level override, select the object from the table, then click the Delete Object button. For more information, see Deleting Device-Level Object Overrides.

Step 6 Click Close to return to the Policy Object Manager window.


Duplicating Objects

An alternative to creating a policy object from scratch is to duplicate an existing object. The new object contains all the attributes of the copied object and a default name. You can then modify the name and all attributes as required.

Duplicating is useful for creating objects that are based on predefined objects that cannot be edited.

This procedure describes how to duplicate an object.

Related Topics

Managing Existing Objects

Policy Object Manager Window, page F-1

Procedure


Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window is displayed.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object you want to duplicate, then select Create Duplicate.

The dialog box for that object type appears. The Name field contains the following default name for the new object: Copy of name of copied object. The remaining fields contain the same values as the copied object.

Step 4 Modify the name of the new object and its configuration, as required.

Step 5 Click OK to save your changes.


Generating Object Usage Reports

Before you make any changes to a user-defined object, you should determine if the object is being used. You can do this by generating usage reports that show which policies, objects, and devices are using the selected object and would therefore be affected by changes to that object. Usage reports contain any references to the selected object in your current activity as well as references found in the data committed to the Security Manager database.

Related Topics

Managing Existing Objects

Policy Object Manager Window, page F-1

Procedure


Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window appears.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object for which you want to generate a report, then select Find Usage.

The Usage Reports window appears, displaying all references to the selected object. See Table F-139 on page F-181 for a description of the fields in this window.


Tip Click a column header to sort the table according to the contents of that column. Click the column header again to sort the table in reverse order.


Step 4 (Optional) Filter the information displayed in the usage report by deselecting one or more of the following check boxes:

Devices

Policies

Other Objects

The deselected entries are removed from the report.


Viewing Object Details

You can view detailed object information in read-only mode, even when the object is locked by another activity. This is useful when you need to view complete configuration details for complex objects whose definitions cannot be fully displayed in the Policy Object Manager window or when your user privileges allow you only to view object information.


Note You can display object details without opening an activity.


This procedure describes how to display complete configuration details for a selected object in read-only mode.

Related Topics

Managing Existing Objects

Policy Object Manager Window, page F-1

Procedure


Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window is displayed.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object that you want to view configuration details for, then select View Object.

The dialog box for that object appears in read-only mode.


Understanding AAA Server Group Objects

In Security Manager, policies requiring AAA (such as Easy VPN, Remote Access VPNs, and router platform policies such as Secured Device Provisioning and 802.1x) refer to AAA server group objects. These objects contain multiple AAA servers that use the same protocol, such as RADIUS or TACACS+. In essence, AAA server groups represent collections of authentication servers focused on enforcing specific aspects of your overall network security policy. For example, you can group those servers dedicated to authenticating internal traffic, external traffic, or remote dial-in users, as well as servers that authorize the administration of your firewall devices.

AAA server groups objects are typically made up of individual AAA server objects. For more information, see Understanding AAA Server Objects. Security Manager policies always refer to the AAA server group, rather than individual AAA servers.

The following topics describe how to work with AAA server group objects:

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Creating AAA Server Group Objects

Related Topics

Creating Objects

Predefined AAA Authentication Server Groups

Security Manager contains several predefined AAA server groups that define an authentication method without specifying particular AAA servers. In policies such as IPsec proposals, you can use these predefined server groups to define the types of AAA authentication to perform and the order in which to perform them.

Table 9-1 lists the predefined AAA authentication server groups.

Table 9-1 Predefined AAA Authentication Server Groups 

Name
Description

Enable

Uses the enable password for authentication.

KRB5

Uses Kerberos 5 for authentication.

Note For Cisco IOS routers, Security Manager supports Kerberos 5 client configuration only on selected platforms running IOS Software versions that support this protocol. Server configuration is not supported. The device must include an Advanced series feature set (k9 crypto image).

Line

Uses the line password for authentication.

Local

Uses the local username database for authentication.

None

Uses no authentication.

RADIUS

Does not apply to Cisco IOS routers.

Uses RADIUS authentication.

Note This AAA server group does not contain any AAA servers at the global level. To use this AAA server group when defining a policy, you must create a device-level override and define the AAA servers to associate with the group. For more information, see Creating Device-Level Object Overrides.

TACACS+

Does not apply to Cisco IOS routers.

Uses TACACS+ authentication.

Note This AAA server group does not contain any AAA servers at the global level. To use this AAA server group when defining a policy, you must create a device-level override and define the AAA servers to associate with the group. For more information, see Creating Device-Level Object Overrides.


Related Topics

Creating AAA Server Group Objects

Default AAA Server Groups and IOS Devices

Understanding AAA Server Group Objects

Default AAA Server Groups and IOS Devices

IOS software enables you to define AAA servers either as members of AAA server groups or as individual servers. Security Manager, however, requires all AAA servers to belong to a AAA server group.

Therefore, when you discover an IOS device whose device configuration contains individual AAA servers that do not belong to a AAA server group, Security Manager creates the following server groups to contain these servers:

For RADIUS: CSM-rad-grp

For TACACS+: CSM-tac-grp

Both of these special AAA server groups are marked in the Policy Object Manager as the default groups for their protocol. This is indicated by the Make this Group the Default AAA Server Group check box.

These groups are created solely for the purpose of management by Security Manager. During deployment, the AAA servers in these special groups are deployed back to the IOS device as individual servers, not as part of the group.


Note If you use one of these default AAA server groups in a policy defined for a PIX/ASA/FWSM device, the AAA servers are deployed as a group to that device, not as individual servers. This is because all AAA servers on PIX/ASA/FWSM devices must belong to a AAA server group.



Caution We recommend that you use caution when using these default AAA server groups in a policy definition. There are certain commands (for example, ip radius and ip tacacs, which are configured using the Interface field in the AAA Server dialog box) that can be defined once for each AAA server group and once for all individual AAA servers. Because the AAA servers in the default group are deployed to IOS devices as individual servers, you might inadvertently change the ip radius or ip tacacs settings for all the individual AAA severs configured on the device, including servers that are not being managed by Security Manager (and whose configurations would otherwise be left undisturbed).

Related Topics

Predefined AAA Authentication Server Groups

Creating AAA Server Group Objects

Understanding AAA Server Group Objects

Understanding AAA Server Objects

Creating AAA Server Group Objects

You can create AAA server group objects for Security Manager policies requiring AAA services, such as authentication and authorization. Each AAA server group object can contain multiple AAA servers, all of which use the same protocol, such as RADIUS or TACACS+. For example, if you want to use RADIUS to authenticate network access and TACACS+ to authenticate CLI access, you must create at least two AAA server group objects, one for RADIUS servers and one for TACACS+ servers.

In addition, only one source interface can be defined for the AAA servers in the group. An error is displayed when you submit your changes if different AAA servers in the group use different source interfaces.


Note The error is triggered by the actual interface defined as the source, not the name of the interface role that represents the interface. That is, two AAA servers can have different interface roles defined as the source interface as long as they both resolve to the same device interface. An error is also displayed if the interface role defined for the source interface matches more than one actual interface on the device.


The number of AAA server group objects that can be created and the number of AAA server objects that can be included in each group object depend on the selected platform. For example, ASA devices support up to 18 single-mode server groups (with up to 16 servers each) and 7 multi-mode server groups (with up to 4 servers each). PIX firewalls support up to 14 server groups, each containing up to 14 servers.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override AAA server group object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create AAA server group objects.


Note Security Manager includes a predefined AAA server group object that you can use when you perform authentication locally inside the Cisco IOS router.



Tip You can also create AAA server group objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Understanding AAA Server Group Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select AAA Server Groups from the Object Type selector.

Step 3 Right-click inside the work area, then select New Object.

The AAA Server Group dialog box appears. For a description of the fields in this dialog box, see Table F-3 on page F-6.

Step 4 Enter a name for the object. The maximum name length is 16 characters if you plan to use this object with firewall devices and 128 characters for Cisco IOS routers. Spaces are not supported.


Note Cisco IOS routers do not support the following AAA server group names: RADIUS, TACACS, TACACS+. In addition, we do not recommend using an abbreviation of one of these names, such as rad or tac.


Step 5 (Optional) Enter a description for the object. The maximum length is 1024 characters (special characters are permitted).

Step 6 Select the protocol to be used by the servers in the group.

Step 7 Enter the names of the AAA servers to include in the group, or click Select to display a selector (see Selecting Objects for Policies). Only those servers corresponding to the selected protocol are displayed.


Tip If the required AAA server is not listed, click the Create button or the Edit button in the selector to open the AAA Server Dialog Box, page F-8. From here you can define a AAA server to include in the server group.


When you finish, click OK to return to the AAA Server Group dialog box. Your selections are displayed in the AAA Servers field.

Step 8 (IOS devices only) Select the check box if this group is to be the default group in the network for RADIUS or TACACS+. Use this option if you intend to have a single global server group for this protocol for all policies requiring AAA.

The default group can be used in most cases, except when you need to configure multiple AAA server groups that use the same protocol. For example, you might want to define multiple RADIUS groups so that one group can be used for authentication and another group for authorization. Service providers may want to define multiple groups with the same protocol in order to provide customer separation when using VRF.


Note Default groups are created automatically when you discover individual AAA servers configured on an IOS router. These server groups are created solely for the purpose of management by Security Manager. For more information, see Default AAA Server Groups and IOS Devices.


Step 9 (PIX/ASA/FWSM devices only) Configure the following settings:

a. Specify the number of connection attempts that can fail before a server is considered inactive.

b. Select the method for reactivating failed servers in the group:

Depletion—All servers in the group are permitted to fail before all the servers are reactivated (known as depletion). This is the default.

Timed—Causes failed servers to be reactivated after 30 seconds of downtime. This option is useful when customers use the first server in a server list as the primary server and prefer that it is online whenever possible.


Note The Timed option must be used when simultaneous accounting has been enabled, as described in d. below.


c. (When Depletion is selected) You can configure the deadtime, which determines how long (in minutes) the system waits after the last server in the group has become inactive before beginning reactivation.

d. Select the method to use for sending accounting messages (single or simultaneous). This setting applies only to RADIUS to TACACS+.

Step 10 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 11 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 12 Click OK to save the object.


Understanding AAA Server Objects

You can create AAA server objects in Security Manager. AAA enables devices to determine who the user is (authentication), what the user is permitted to do (authorization), and what the user actually did (accounting), as described below:

Authentication—Authentication is the way a user is identified before being allowed access to the network and network services. It controls access by requiring valid user credentials, which are typically a username and password. All authentication methods, except for local, line password, and enable authentication, must be defined through AAA. You can use authentication alone or with authorization and accounting.

Authorization—After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform. These attributes are compared to the information contained in a database for a given user and the result is returned to AAA to determine the user's actual capabilities and restrictions. The database can be located locally on the access server or router or it can be hosted remotely on a RADIUS or TACACS+ security server. Were you not to use authorization, authentication alone would provide the same access to services to all authenticated users. You must use authorization together with authentication.

Accounting—Accounting is used to track the services users are accessing, as well as the amount of network resources they are consuming. When AAA accounting is activated, the network access server reports user activity to the RADIUS or TACACS+ security server (depending on which security method you have implemented) in the form of accounting records. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the service used, and the duration of each session. This data can then be analyzed for network management, client billing, and/or auditing. You can use accounting alone or together with authentication and authorization.

AAA provides an extra level of protection and control for user access over using ACLs alone. For example, you can create an ACL allowing all outside users to access Telnet on a server on the DMZ network. If you want only some users to access the server (and you might not always know the IP addresses of these users), you can enable AAA to allow only authenticated and/or authorized users to make it through the device.

AAA server objects are collected into AAA server group objects. In Security Manager, all policies requiring AAA (such as EzVPN, Remote Access VPNs, and router platform policies such as Secured Device Provisioning and 802.1x) use AAA server group objects. See Understanding AAA Server Group Objects.

The following topics describe how to work with AAA server objects:

Supported AAA Server Types

AAA Support on ASA Devices

Creating AAA Server Objects

Related Topics

Creating Objects

Supported AAA Server Types

Security Manager supports AAA servers using one of the following protocols:

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco devices and send authentication requests to a central RADIUS server that contains all user authentication and network service access information. RADIUS is a fully open protocol, distributed in source code format, that can be modified to work with any security system currently available on the market.

Cisco supports RADIUS under its AAA security model. RADIUS can be used with other AAA security protocols, such as TACACS+, Kerberos, and local username lookup. RADIUS is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms.

TACACS+

Terminal Access Controller Access Control System (TACACS+) is a security application that provides centralized validation of users attempting to gain access to a router or network access server. The goal of TACACS+ is to provide a methodology for managing multiple network access points from a single management service.

TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service—authentication, authorization, and accounting—independently.

Related Topics

AAA Support on ASA Devices

Creating AAA Server Objects

Understanding AAA Server Objects

AAA Support on ASA Devices

In addition to supporting RADIUS and TACACS+, ASA devices can support AAA servers running the following protocols:

AAA Support on ASA Devices

AAA Support on ASA Devices

AAA Support on ASA Devices

AAA Support on ASA Devices

AAA Support on ASA Devices


Note For more information, see Configuring AAA Servers and the Local Database at this URL:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/aaa.html


Kerberos

ASA devices can use Kerberos servers for VPN authentication. When a user attempts to establish VPN access through the ASA device, and the traffic matches an authentication statement, the device consults the Kerberos server for user authentication and grants or denies user access based on the response from the server. 3DES, DES, and RC4 encryption types are supported.

NT

ASA devices can use NT servers for VPN authentication. When a user attempts to establish VPN access and the applicable tunnel-group policy specifies an NT authentication server group, the ASA device consults the Microsoft Windows domain server for user authentication and grants or denies user access based on the response from the domain server.

SDI Servers

SecurID servers from RSA Security, Inc. are known as SDI servers. When a user attempts to establish VPN access and the applicable tunnel-group policy specifies an SDI authentication server group, the ASA device sends the username and one-time password to the SDI server. The device then grants or denies user access based on the response from the server. Version 5.0 of SDI introduced the concept of SDI master and slave servers that share a single-node secret file (SECURID). As a result, when you configure an SDI server as a AAA server object in Security Manager, you must specify whether the server is version 5.0 or an earlier version.

LDAP

ASA devices can use Lightweight Directory Access Protocol (LDAP) servers for VPN authorization. ASA devices support LDAP version 3 and are compatible with any v3 or v2 directory server. However, password management is supported only on the Sun Microsystems JAVA System Directory Server and the Microsoft Active Directory.

With any other type of LDAP server (such as Novell or OpenLDAP), all LDAP functions are supported except for password management. Therefore, if someone tries to log in to an ASA device using one of these other servers for authentication and their password has expired, the ASA device drops the connection and a manual password reset is required.

You can configure Simple Authentication and Security Layer (SASL) mechanisms to authenticate an LDAP client (in this case, the ASA device) to an LDAP server. Both ASA devices and LDAP servers can support multiple mechanisms. If both mechanisms (MD5 and Kerberos) are available, the ASA device uses the stronger mechanism, Kerberos, for authentication.

When user authentication for VPN access has succeeded and the applicable tunnel-group policy specifies an LDAP authorization server group, the ASA device queries the LDAP server and applies the authorizations it receives to the VPN session.

HTTP-Form

The security appliance can use the HTTP Form protocol for single sign-on (SSO) authentication of WebVPN users only. Single sign-on support lets WebVPN users enter a username and password only once to access multiple protected services and Web servers. 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.

Table 9-2 describes the AAA services that are supported by each protocol:

Table 9-2 AAA Services Supported by ASA Devices 

AAA Service
Database Type
 
Local
RADIUS
TACACS+
SDI
NT
Kerberos
LDAP

HTTP Form

Authentication of...

VPN users

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Firewall sessions

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Administrators

Yes

Yes

Yes

Yes2

Yes

Yes

Yes

No

Authorization of...

VPN users

Yes

Yes

No

No

No

No

Yes

No

Firewall sessions

No

Yes3

Yes

No

No

No

No

No

Administrators

Yes4

No

Yes

No

No

No

No

No

Accounting of...

VPN connections

No

Yes

Yes

No

No

No

No

No

Firewall sessions

No

Yes

Yes

No

No

No

No

No

Administrators

No

Yes5

Yes

No

No

No

No

No

1. HTTP Form protocol supports single sign-on (SSO) authentication for WebVPN users only.
2. SDI is not supported for HTTP administrative access.
3. For firewall sessions, RADIUS authorization is supported with user-specific ACLs only, which are received or specified in a RADIUS authentication response.
4. Local command authorization is supported by privilege level only.
5. Command accounting is available for TACACS+ only.


Related Topics

Supported AAA Server Types

Creating AAA Server Objects

Understanding AAA Server Objects

Creating AAA Server Objects

You can create AAA server objects to populate the AAA server group objects that are referenced by Security Manager policies, such as Easy VPN and 802.1x. When creating a AAA server object, you must specify the IP address of the external AAA server, the key used for data encryption, the protocol used by the server, and the timeout interval.

This procedure describes how to create AAA server objects.


Note On PIX/ASA/FWSM devices, AAA objects in a device configuration that are not referenced by any policies are removed from the device during the next deployment. However, the predefined AAA objects named RADIUS and TACACS+ are never removed from PIX 6.3 devices, even if they are unreferenced by any policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Configure the external AAA server that will be referenced by the AAA server object.

Related Topics

Supported AAA Server Types

AAA Support on ASA Devices

Understanding AAA Server Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select AAA Servers from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The AAA Server dialog box appears. For a description of the fields in this dialog box, see Table F-4 on page F-8.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 In the Connect to Host Using field, do one of the following:

Enter the IP address of the AAA server in the IP Address field, or click Select to display a selector. See Selecting Objects for Policies.

(ASA 7.2 devices only) Enter the DNS name of the AAA server.

Step 6 (Optional) In the Interface field, enter the interface or interface role whose IP address that should be used for all outgoing RADIUS or TACACS packets, or click Select to display a selector. See Selecting Objects for Policies.

When you enter the name of an interface, make sure the policy that uses this AAA object is assigned to a device containing an interface with this name. Otherwise, deployment will fail.

When you enter the name of an interface role, make sure the role represents a single interface, not multiple interfaces. Otherwise, an error message is displayed.


Tip If the required interface role is not listed, click the Create button or the Edit button to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to use in the object. The interface role you define must correspond to a single interface on the device.


Step 7 Enter the amount of time to wait until a AAA server is considered unresponsive.

Step 8 Select the protocol used by the AAA server and configure protocol-specific properties. For details about these properties, see Table F-4 on page F-8.


Note The Kerberos, LDAP, NT, SDI, and HTTP-FORM protocols can be used only with ASA, PIX 7.x, and FWSM 3.1 and above devices.


Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.


Creating Access Control List Objects

An Access Control List (ACL) object is made up of one or more access control entries (ACEs), one or more ACL objects, or a combination of both. Each ACE is an individual permit or deny statement within an ACL. You can use ACL policy objects in several other policies and policy objects.

You can create the following types of ACL objects:

Extended—Extended ACLs enable you to specify source and destination addresses and service (or traffic protocol), and, based on the protocol type, the ports (for TCP or UDP), or the ICMP type (for ICMP) can be specified. For information on extended ACL objects, see Creating Extended Access Control List Objects.

Standard—Standard ACLs use the source address for matching traffic. For information on standard ACL objects, see Creating Standard Access Control List Objects.

Web Type—Web ACLs use destination address and port or a URL filter. For information on Web Type ACL objects, Creating Web Access Control List Objects.

When you add devices to the device inventory that already have ACLs configured, Security Manager tries to preserve your ACL names to some extent. For more information, see Understanding How Security Manager Handles ACL Names.

Creating Extended Access Control List Objects

Extended access control lists allow you to permit or deny traffic from specific IP addresses to specific destination IP address and port, and specify the protocol of the traffic, such as ICMP, TCP, UDP, and so forth. Extended ACLs range from 100 to 199, and for devices running Cisco IOS Software Release 12.0.1 and higher, 2000 to 2699.

Extended ACL example:

access-list 110 - Applied to traffic leaving the office (outgoing)
access-list 110 permit tcp 10.128.2.0 0.0.0.255 any eq 80

ACL 110 permits traffic originating from any address on the 10.128.2.0 network. The "any" statement means that the traffic is allowed to have any destination address with the limitation of going to port 80. The value of 0.0.0.0/255.255.255.255 can be specified as "any".

Uses:

Identifying addresses for NAT (policy NAT and NAT exemption)—Policy NAT lets you identify local traffic for address translation by specifying the source and destination addresses and ports in an extended access list. Regular NAT can only consider local addresses. An access list that is used with policy NAT cannot be configured to deny an access control entry (ACE).

Identifying addresses for IOS dynamic NAT—For user-defined ACLs, the NAT plug-in generates its own ACL CLIs when deducing NAT traffic from VPN traffic.

Filtering traffic that will be intercepted by Network Admission Control (NAC).

Identifying traffic in a traffic class-map for modular policy—Access lists can be used to identify traffic in a class-map, which is used for features that support Modular Policy Framework such as TCP and general connection settings, inspection, IPS, and QoS. You can use one or more access lists to identify specific types of traffic.

For transparent mode, enabling protocols that are blocked by a routed mode security appliance, including BGP, DHCP, and multicast streams. Because these protocols do not have sessions on the security appliance to allow return traffic, these protocols also require access lists on both interfaces.

Establishing VPN access—You can use an extended access list in VPN commands to identify the traffic that should be tunneled on the device for an IPsec site-to-site tunnel or to identify the traffic that should be tunneled on the device for a VPN client. Use in conjunction with the policy objects and settings shown in Table 9-3:

Table 9-3 Policy Objects and Settings 

Policy Object
Device
Purpose

VPN Topology

Any

Selecting Protected Networks.

ASA User Group

ASA

Inbound Firewall Policy; Outbound Firewall Policy; Filter ACL.

Traffic Flow

ASA 7.x, PIX 7.x

Service Policy Rules (MPC). The traffic flow BB (class-map) uses Extended ACL as one of its traffic match types.

User Group

IOS

Catalyst 6500/7600

PIX 6.3

For Easy VPN, Split Tunnel ACL and Firewall ACL (IOS devices only).


Related Topics

Guidelines for Managing Objects

Creating Access Control List Objects

Understanding Network/Host Objects

Understanding Service Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears. The Extended tab opens by default.

Step 3 Right-click inside the work area, then select New Object.

The Add Extended Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the table, then select Add.

The Add Extended Access Control Entry dialog box appears.

Step 6 Create the access control entry:

If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. Enter the source addresses whence the traffic originates, the destination addresses whither the traffic travels, and the services that define the characteristics of the traffic. Click Advanced to define logging options. For detailed information about the fields on the dialog box, see Add and Edit Extended Access Control Entry Dialog Boxes, page F-20.

If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 7 Click OK to save your changes.

The dialog box closes and you return to the Add Extended Access List page. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.


Creating Standard Access Control List Objects

A standard access control list allows you to permit or deny traffic from specific IP addresses. The destination of the packet and the ports involved can be anything. Standard IP ACLs range from 1 to 99.

Standard ACL example:

access-list 10 permit 192.168.2.0 0.0.0.255

Uses:

Identifying OSPF route redistribution.

Filtering users of a community string using SNMP.

Configuring VLAN ACLs for a Catalyst 6500/7600 device.

Related Topics

Guidelines for Managing Objects

Creating Access Control List Objects

Understanding Network/Host Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears.

Step 3 Click the Standard tab.

Step 4 Right-click inside the work area, then select New Object.

The Add Standard Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 5 Enter a name for the object and optionally a description of the object.

Step 6 Right-click inside the table, then select Add.

The Add Standard Access Control Entry dialog box appears.

Step 7 Create the access control entry:

If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. Enter the source addresses whence the traffic originates and select logging options. For detailed information about the fields on the dialog box, see Add and Edit Standard Access Control Entry Dialog Boxes, page F-22.

If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 8 Click OK to save your changes.

The dialog box closes and you return to the Add Standard Access List dialog box. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.


Creating Web Access Control List Objects

Web ACLs, also referred to as WebVPN, let you establish a secure, remote-access VPN tunnel to the security appliance using a web browser. There is no need for either a software or hardware client. WebVPN provides easy access to a broad range of web resources and both web-enabled and legacy applications from almost any computer that can reach HTTPS Internet sites. WebVPN uses Secure Socket Layer Protocol and its successor, Transport Layer Security (SSL/TLS1) to provide a secure connection between remote users and specific, supported internal resources that you configure at a central site.

Table 9-4 shows examples of Web VPN ACLs.

Table 9-4 Examples of Web VPN ACLs 

Action
Filter
Effect

Deny

url http://*.yahoo.com/

Denies access to all of Yahoo!

Deny

url cifs://fileserver/share/directory

Denies access to all files in the specified location.

Deny

url https://www.company.com/ directory/file.html

Denies access to the specified file.

Permit

url https://www.company.com/directory

Permits access to the specified location

Deny

url http://*:8080/

Denies HTTPS access to anywhere via port 8080.

Deny

url http://10.10.10.10

Denies HTTP access to 10.10.10.10.

Permit

url any

Permits access to any URL. Usually used after an ACL that denies url access.


Uses:

As a filter ACL in an ASA User Group policy object (under SSL VPN > Clientless).

Related Topics

Guidelines for Managing Objects

Creating Access Control List Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears.

Step 3 Click the Web tab.

Step 4 Right-click inside the work area and select New Object.

The Add WebType Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 5 Enter a name for the object and optionally a description of the object.

Step 6 Right-click inside the access control entry table and select Add.

The Add Web Access Control Entry dialog box appears.

Step 7 Create the access control entry:

If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. You can filter based on the network destination of the traffic (Network Filter) or the web address (URL Filter). For detailed information about the fields on the dialog box, see Add and Edit Web Access Control Entry Dialog Boxes, page F-23.

If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 8 Click OK to save your changes.

The dialog box closes and you return to the Add WebType Access List page. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.


Understanding How Security Manager Handles ACL Names

Security Manager tries preserve user-defined ACL names as they appear in devices. For more information, see Preserving User-Defined ACL Names. Security Manager also has the ability to assign a name to an ACL, which requires no user intervention. For more information, see How ACL Names Are Generated.

ACL policy objects also support device-override during discovery. Device override allows policy objects that have different content to share the same policy object name in Security Manager. For example, Device A and Device B both have an ACL with the name `myACL', but each ACL contains different content. After discovering Device A, `myACL' policy object is created. Without device-override, Security Manager will create `myACL_1' for Device B because the content of the two `myACLs' is different. With device-override, Security Manager can create `myACL' for Device B, resulting in two `myACL' policy objects in Security Manager, one for Device A and one for Device B.

For IOS devices, when device override is not set, ACLs with duplicate names are imported with a suffix `_n', where n is a number. A numbered ACL can be imported as <ACL number>_n, such as 100_1. 100_1 is not a valid ACL name in IOS. As a result, _n is stripped from the numbered ACL at deployment. For example, IOS Device 1 has ACL 100. IOS Device 2 has ACL 100. Device 1 and Device 2 have different content. Both devices are imported in Security Manager. Security Manager creates 100 for device 1 and 100_1 for Device 2. 100_1 is not a valid name in IOS devices. Security Manager removes the _1 suffix at deployment and 100 is deployed to the device.

The _n suffix is not removed from the named ACL during deployment because <named ACL>_n is a valid ACL name in IOS.

Policies that do not support ACL name preservation are as follows:

IOS Policies

AAA rules

SSL VPN

Transparent firewall rules

ASA/PIX Policies

Service policy rules

SSL VPN

Transparent firewall rules

Related Topics

How ACL Names Are Generated

Preserving User-Defined ACL Names

Identifying Original ACL Names

Naming Conflicts and Resolutions

Notes on ACL Naming

Preserving User-Defined ACL Names

For Access Control Rules

You can elect to retain user-defined ACL names instead of having Security Manager generate ACL names. Note, however, that a relationship exists between name preservation, deployment time, and non-traffic interruption. For example, name preservation will have an effect on deployment time and traffic interruption. (Deployment approaches and their effects are explained in detail in the Troubleshooting Guide.) To define user-defined ACL names, select Firewall > Settings > Access Control. For a description of the GUI elements, see Access Control Page, page I-101.

If the same ACL is applied to more than one interface and direction, you can specify the ACL name (e.g., MyInsideACL) for a maximum of one interface and direction. Security Manager automatically detects the sharing relationship and applies the same ACL to all sharing interfaces.

For Firewall Policies

For ACLs used by AAA, NAT, and firewall access (access-group), ACL sharing is preserved if you choose to reuse existing ACL names (Tools > Security Manager Administration > Deployment). By preserving ACL sharing, we mean that if an ACL is already shared by multiple commands on the device, Security Manager will continue to leave the sharing intact upon new deployments. This preservation, however, is only possible if the according Security Manager policies that this ACL corresponds to translate to the same ACL.

For example, an ACL is originally shared by AAA and NAT commands on a device. If you change the AAA policy in Security Manager so it translates to an ACL with different content from the NAT ACL, the two ACLs can no longer be shared. Two ACLs with different content and names are then provisioned.


Note Although ACL sharing is not commonly used, certain circumstances might find it beneficial with regard to ease-of-use and memory usage.


During deployment, Security Manager generates one ACL for each interface and direction. Names of the ACLs are determined in a number of ways.

You can define a name in Access Control Settings. Go to Firewall > Settings > Access Control.

You can select the method by which Security Manager deploys ACLs. Go to Tools > Security Manager Administration > Deployment.

If you select "reuse existing names," the names might correspond to the ACL name in the device, or a name previously generated by Security Manager.


Note In situations where an ACL name is not specified in Security Manager, but a name exists in the original configuration, Security Manager can reuse the ACL name instead of using the default ACL naming conventions. For example, if no name is specified in the Access Control page for an ACL that is applied to the inbound of the inside interface, but the device has an access-list named "InsideAcl" on the inbound direction of the inside interface, Security Manager can recognize "InsideAcl" if "Reuse existing names" is selected.


ACL names cannot be specified for all firewall rule types. For example, you can specify a name for ACLs used in access rules, but you cannot specify a name for ACLs used in IOS AAA or inspection rules. For these unnamed ACL policies, Security Manager automatically generates ACL names. For more information, see How ACL Names Are Generated.

You can retain names of user-defined VPN policies that use ACL policy object names. Supported use cases are shown in the table.

Access Type
Supported Device
How Used

Remote Access VPN

PIX 6.3

User Group Object/Split Tunneling

Remote Access VPN

IOS

User Group Object/Split Tunneling

User Group Object/Client Settings/Firewall Are You There

Remote Access VPN

ASA/PIX 7.0

User Group Object/Split Tunneling

User Group Object/Client Firewall Attributes/Inbound and Outbound Traffic Policies

Remote Access VPN

ASA/PIX 8.x

Dynamic Access

EZVPN

PIX 6.3

User Group Object/Split Tunneling

EZVPN

IOS

User Group Object/Split Tunneling

User Group Object/Client Settings/Firewall Are You There

Client Connection Characteristics/Tunnel Activation ACL

EZVPN

ASA/PIX 7.0

User Group Object/Split Tunneling

User Group Object/Client Firewall Attributes/Inbound and Outbound Traffic Policies

IPSec

IOS, PIX 6.3, PIX 7.0, ASA 7.0+

Peer/Protected Network


Additional policies that support ACL name preservation:

Device
Policies

IOS

Firewall Access Rules, NAT, VTY, Console, HTTP, QoS, NAC, SNMP, Advance Interface Settings, Dialer, VLAN ACl, IPS AIM, IPS Interface Rules, Client Connection Characteristics for Easy VPN, User Group Policy for Easy VPN and for Remote Access VPN, Protected Network for IPSec VPN

ASA/PIX/FWSM

AAA Rules

ASA/PIX

Firewall Acess Rules, NAT, RIP, Dynamic Access under Remote Access VPN, User Group Policy for Easy VPN and for Remote Access VPN (ASA, PIX 7.x, PIX 6.3), Protected Network for IPSec VPN


Note the following (for firewall rules):

The activity validation process catches the duplication of the ACL name with policies that don't use ACL policy objects, for example, Access Control.

For policies that use an ACL policy object and support ACL name preservation, deployment is stopped if the ACL name used in VPN policies is used in an "unsupported" command.

Related Topics

Notes on ACL Naming

Naming Conflicts and Resolutions

How ACL Names Are Generated

An ACL is assigned a name, which requires no user intervention; however, user-defined ACL names can be retained in Security Manager. For more information, see Preserving User-Defined ACL Names.

When the name for the ACL is generated by Security Manager, the name is derived from the type of rule or platform being defined and certain configuration settings that make it unique. A group command is then generated that binds the defined rules to the ACL.

Table 9-5 shows the naming conventions used for the rule types and platforms.

Table 9-5 ACL Naming Conventions for Rule Types and Platforms 

Rule Type
Name

Access ACL

CSM_FW_ACL_InterfaceName (for inbound)

CSM_FW_ACL_OUT_InterfaceName (for outbound)

Note Only OUT is explicitly present as part of the ACL name.

Inspection

For ASA 7.0/PIX 7.0:

CSM_CMAP_ACL_n where n is an integer beginning with 1.

For IOS devices:

Devices use a numbered ACL.

AAA ACL

For PIX/ASA/FWSM:

CSM_AAA_{AUTHO | ATHEN | ACCT}_InterfaceName _ServerGroupName

Authentication Proxy for IOS devices:

On an interface without NAC: CSM_AUTH-PROXY_<InterfaceName > <traffic type >_ACL, where InterfaceName is the interface in which the rule is applied and traffic type is HTTP, Telnet, or FTP.

AuthProxy and NAC on the same interface: CSM_ADMISSION_<ID of interface role in snapshot >_ACL, where ID of interface role in snapshot is an internal ID of the interface within Security Manager to which NAC is applied.

Web Filter ACL

For ASA 7.0/PIX 7.0:

Devices correspond to a filter command.

For IOS devices:

Devices use a numbered ACL.

NAT 0 ACL

CSM_nat0_InterfaceName_in (for inbound)

CSM_nat0_InterfaceName (for outbound)

Policy Nat ACL

CSM_nat_InterfaceName_poolID_in (for inbound)

CSM_nat_InterfaceName_poolID (for outbound)

For PIX 6.3(x):

_dns (for dns)

_nrseq (for norandomseq)

_emb## (for embryonic limit)

_tcp## (for tcp max connection limits)

_udp## (for udp max connection limits)

Policy Static ACL

CSM_static_localIP_globalIP_LocalInterfaceName _globalInterfaceName (for IP)

CSM_static_localIP_globalIP_LocalInterfaceName _globalInterfaceName_ protocol _globalPort (for other protocols)


During deployment, sometimes a suffix ".n " (where n is an integer) might get added to an ACL name if the existing ACL cannot be edited in place. For example, if an ACL named acl_mdc_outside_10 already exists on the device, a new ACL with the name acl_mdc_outside_10.1 is created if you do not remove the old ACL before you deploy the new ACL.

Related Topics

Preserving User-Defined ACL Names

Naming Conflicts and Resolutions

Identifying Original ACL Names

Notes on ACL Naming

Identifying Original ACL Names

ACLs are identified by a set of key attributes, which are described in Table 9-6. If Security Manager is provisioning the access ACL on the inbound of the interface "Inside," and the original configuration on the device has CLI

access-group acl-inside in interface inside

Then the corresponding original ACL is identified as "acl-inside".

Table 9-6 Identifying Original ACL Names 

ACL
Attributes

Access

Interface, direction

AAA

Interface, AAA server tag

Nat 0

Interface, direction

Policy Nat

Interface, pool ID, direction (dns, norandomseq, embryonic limit, tcp/udp max connection limits for PIX 6.3(x)).

Policy Static

Local interface, global interface, local IP (if non-PIX 6.3(x) device), global IP (IP address and mask), global port (if protocol is tcp/udp).


Related Topics

Notes on ACL Naming

How ACL Names Are Generated

Naming Conflicts and Resolutions

Preserving User-Defined ACL Names

Naming Conflicts and Resolutions

When a naming conflict occurs that results from more than one ACL with different contents attempting to reuse the same ACL name in the original configuration, priorities determine where the original ACL name is used and where the Security Manager naming convention is used. The following order of priority is used, which recognizes the different types of ACLs in descending order:

Access ACLs > AAA ACLs > Static ACLs > NAT 0 ACLs > NAT ACL

For example, if an access ACL and a NAT 0 ACL attempt to reuse the same ACL named MyACL, the access ACL is assigned the user-defined name and the NAT 0 ACL is assigned a name automatically generated by Security Manager. (See Table 9-5.)

If the two competing ACLs are of the same type, (for example, they are both Access ACLs), and using the same naming convention generated by Security Manager, then the one recognized first based on alpha order will have higher priority.

Related Topics

Identifying Original ACL Names

Notes on ACL Naming

How ACL Names Are Generated

Preserving User-Defined ACL Names

Notes on ACL Naming

If an ACL has a name specified in Security Manager, it can be retained. For a list of policies that support ACL name preservation, see Preserving User-Defined ACL Names.

If an ACL is not shared on the device and you change only its content in Security Manager, then the original name is preserved.

If an ACL is shared on the device and the according ACL policies are still identical in Security Manager, then the original name is preserved.

If an ACL is shared on the device and the according ACL policies are not identical in Security Manager, then one version of the ACL policies will preserve the original name. The remaining policies will use the Security Manager naming conventions.

Newly created ACLs use Security Manager naming conventions.

For Policy Statics, if the source of the access list that is used by the static rule contains an object group, Security Manager flattens the object group and deploys the IP address it contains.

All ACEs defined in the ACL on the device must have the same source.

Additional Activity Validation For IOS:

A device cannot reference two ACL policy objects with the same number prefix before an underscore. Since 100_1 is deployed as 100, 100_1 and 100 cannot be assigned to the same device.

Validated ACL names (for IOS devices)

Named ACLs cannot start with an underscore (_) or a number.

Numbered ACLs must be within a certain range depending on the ACL type, for example, standard or extended.

ACL object names not used in unsupported commands

You cannot overwrite an ACL used by unsupported commands.

You can overwrite an ACL if it is originally shared with Security Manager policies.

NAT that participates in a VPN cannot share an ACL object with another policy.

Security Manager does not support all IOS commands. NAT participates in VPN and adds additional ACEs to its ACL; therefore, NAT cannot share the ACL with unsupported commands.

NAT that participates in a VPN adds additional ACEs to its referenced ACL. Thus, changing a shared ACL is not a desirable behavior.

Firewall access rules cannot use the same ACL name as a referenced ACL object.

Firewall access rules do not use ACL objects. The ACL name defined in firewall access rules can conflict with a referenced ACL object name. Therefore, the ACL name used in the firewall access rules cannot be the same as a referenced ACL object name.

Related Topics

How ACL Names Are Generated

Preserving User-Defined ACL Names

Identifying Original ACL Names

Naming Conflicts and Resolutions

Understanding ASA User Group Objects

ASA User Groups objects are group policies that you use to manage Virtual Private Networks (VPN) group policies.

ASA user groups are configured on ASA security appliances in Easy VPN topologies, IPSec VPNs, and SSL VPNs. When you configure an Easy VPN, IPSec VPN or SSL VPN connection, you must create user groups to which remote clients will belong. A user group policy is a set of user-oriented attribute/value pairs for SSL VPN connections that are stored either internally (locally) on the device or externally on an AAA server. The tunnel group uses a user group policy that sets terms for user connections after the tunnel is established. Group policies let you apply whole sets of attributes to a user or a group of users, rather than having to specify each attribute individually for each user.

An ASA user group object comprises the following attributes:

Group policy source—Identifies whether the user group's attributes and values are stored internally (locally) on the security appliance or externally on an AAA server. If the user group is an external type, no other settings need to be configured for it. For more information, see ASA User Group Dialog Box, page F-25.

Client Configuration settings, which specify the Cisco client parameters for the user group in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Client Configuration Settings, page F-27.

Client Firewall Attributes, which configure the firewall settings for VPN clients in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Client Firewall Attributes, page F-28.

Hardware Client Attributes, which configure the VPN 3002 Hardware Client settings in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Hardware Client Attributes, page F-30.

IPsec settings, which specify tunneling protocols, filters, connection settings, and servers for the user group in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: IPsec Settings, page F-32.

Clientless settings, which configure the Clientless mode of access to the corporate network in an SSL VPN, for the ASA user group. For more information, see ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34.

Full Client settings, which configure the Full Client mode of access to the corporate network in an SSL VPN, for the ASA user group. For more information, see ASA User Group Dialog Box: SSL VPN Full Client Settings, page F-35.

General settings that are required for Clientless/Port Forwarding in an SSL VPN. For more information, see ASA User Group Dialog Box: SSL VPN Settings, page F-37.

DNS/WINS settings that define the DNS and WINS servers and the domain name that should be pushed to remote clients associated with the ASA user group. For more information, see ASA User Group Dialog Box: DNS/WINS Settings, page F-39.

Split tunneling that lets a remote client conditionally direct packets over an IPsec or SSL VPN tunnel in encrypted form or to a network interface in clear text form. For more information, see ASA User Group Dialog Box: Split Tunneling, page F-41.

Remote access or SSL VPN session connection settings for the ASA user group. For more information, see ASA User Group Dialog Box: Connection Settings, page F-42.

To create ASA user group objects, see Creating ASA User Group Objects.

Related Topics

Configuring a Tunnel Group Policy for Easy VPN, page 10-81

Creating Objects

Policy Object Manager Window, page F-1

Creating ASA User Group Objects

Use the ASA User Groups Objects page to create ASA user group objects for use in an Easy VPN, IPSec VPN, or SSL VPN.


Note You must select the technology (Easy VPN/IPSec VPN, SSL VPN, or Easy VPN/IPSec VPN and SSL VPN) for which you are creating the ASA user group object. If you are editing an existing ASA user group object, the technology is already selected, and you cannot change it. Depending on the selected technology, the appropriate settings are available for configuration.



Tip You can also create ASA User Group objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


This procedure describes how to create ASA User Group objects.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding ASA User Group Objects

ASA User Group Dialog Box, page F-25

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select ASA User Groups.

The ASA User Groups page appears.

Step 3 From the work area, right-click inside the table, then select New Object.

The Add ASA User Group dialog box appears, displaying a list of settings that you can configure for the ASA user group object. For a description of the elements on this dialog box, see Table F-16 on page F-26.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select whether to store the ASA user group's attributes and values locally on the device, or on an external server.


Note If you selected to store the ASA user group's attributes on an external server, you do not need to configure any Technology settings. After you specify the AAA server group that will be used for authentication and a password to the AAA server, click OK to save your definitions and close the ASA User Group dialog box.


Step 6 If you selected to store the ASA user group's attributes locally on the device, select the type of VPN for which you are creating the ASA user group from the Technology list.

Step 7 To configure the user group for an Easy VPN/IPSec VPN, from the Easy VPN/IPSec VPN folder in the Settings pane:

a. Select Client Configuration to configure the Cisco client parameters for the ASA user group. For a description of the elements required to configure these parameters, see ASA User Group Dialog Box: Client Configuration Settings, page F-27.

b. Select Client Firewall Attributes to configure the firewall settings for VPN clients for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Client Firewall Attributes, page F-28.

c. Select Hardware Client Attributes to configure the VPN 3002 Hardware Client settings for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Hardware Client Attributes, page F-30.

d. Select IPsec to specify tunneling protocols, filters, connection settings, and servers for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: IPsec Settings, page F-32.

Step 8 To configure the user group for an SSL VPN, from the SSL VPN folder in the Settings pane:

a. Select Clientless to configure the Clientless mode of access to the corporate network in an SSL VPN, for the ASA user group object. For a description of the elements required to configure the Clientless mode settings, see ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34.

b. Select Full Client to configure the Full Client mode of access to the corporate network in an SSL VPN, for the ASA user group object. For a description of the elements required to configure the Full Client mode settings, see ASA User Group Dialog Box: SSL VPN Full Client Settings, page F-35.

c. Select Settings to configure the general settings that are required for Clientless/Port Forwarding in an SSL VPN, for the ASA user group object. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: SSL VPN Settings, page F-37.

Step 9 Specify the following settings for an ASA user group in an Easy VPN/IPSec VPN and SSL VPN configuration, in the Settings pane:

a. Select DNS/WINS to define the DNS and WINS servers and the domain name that should be pushed to clients associated with the ASA user group. For a description of the elements required to configure the DNS and WINS servers, see ASA User Group Dialog Box: DNS/WINS Settings, page F-39.

b. Select Split Tunneling to specify a secure tunnel to the central site and simultaneous clear text tunnels to the Internet. For a description of the elements required to configure split tunneling, see ASA User Group Dialog Box: Split Tunneling, page F-41.

c. Select Connection Settings to configure the SSL VPN connection settings for the ASA user group, such as the session and idle timeouts, including the banner text. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Connection Settings, page F-42.

Step 10 Click OK to save the object.


Understanding Credential Objects

Credential objects are used when authenticating user access to the network and network services. A credential object comprises user credentials, typically a username and password that identify the user during authentication.

In Security Manager, credential objects are used in Easy VPN configuration during IKE Extended Authentication (Xauth). When negotiating tunnel parameters for establishing IPsec tunnels in an Easy VPN configuration, Xauth identifies the user who requests the IPsec connection. If the VPN server is configured for Xauth, the client waits for a "username/password" challenge after the IKE SA has been established. When the end user responds to the challenge, the response is forwarded to the IPsec peers for an additional level of authentication. You can save the Xauth credentials (username and password) on the device itself so you do not need to enter them manually each time the Easy VPN tunnel is established.

To create Credential objects, see Creating Credential Objects.

Related Topics

Easy VPN and IKE Extended Authentication (Xauth)

Creating Objects

Policy Object Manager Window, page F-1

Creating Credential Objects

You can create credential objects to use for IKE Extended Authentication (Xauth) in Easy VPN configurations. For more information, see Understanding Credential Objects.

Credential objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override credential object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create a credential object.


Tip You can also create credential objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Credential Objects

Credentials Dialog Box, page F-46

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Credentials. The Credentials page opens, displaying the currently defined credential objects.

Step 3 Right-click in the work area, then select New Object.

The Credentials dialog box appears. For a description of the elements in this dialog box, see Table F-31 on page F-47.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Specify a name that will be used to identify the user during Xauth authentication.

Step 6 Enter a password that will be used to identify the user during Xauth authentication.

Step 7 Enter the password again to confirm it.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 10 Click OK to save the object.


Understanding File Objects

File objects represent files that are used in device configurations. Such files include XML configuration files, image logo files, plug-in jar files, and binary files. The files can be discovered from a device or added by users, managed in Security Manager, and deployed to devices.

When a file is introduced into Security Manager, Security Manager makes a copy of the file and keeps it. A file object is created for this file. A one-to-one relationship exists between a File Object and a file. The File Object keeps a reference to the file in the form of a file URL. The actual file content remains outside of Security Manager. Currently, the ability to edit the actual file content is not supported by Security Manager. However, you can access the file content using the link that is saved in the File Object.


Note Security Manager does not support modification to the actual configuration file. If the file content needs to be modified after the File Object is created, you must manually edit the file in Security Manager's file repository. The full path and filename of the file can be obtained from the File Object's file attribute.


The file storage system is implemented as an internal file directory within Security Manager. The files managed by the File Object are maintained in Security Manager's central file repository. The location of the file repository is: CSCOpx\MDC\FileRepository, where CSCOpx is the root directory of the Security Manager installation.

The files are put under the sub-folders within the file repository. The sub-folder is named after the file type.


Note When a file object is deleted in Security Manager, the actual file corresponding to the file object is not removed from Security Manager's file repository.



Note The Security Manager file repository is included in the standard Security Manager data backup/restore process.


Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating File Objects

Creating File Objects

You can create a file object to use when you are configuring a logo image for an SSL VPN customization object, or specifying the filename of the Cisco Secure Desktop (CSD) distribution package to install into the running configuration.

File objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override credential object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create a file object.


Tip You can also create file objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding File Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select File Objects. The File Objects page appears.

Step 3 Right-click in the work area, then select New Object.

The Add File Object dialog box appears. For a description of the GUI elements, see Table F-32 on page F-47.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the type of file from the list box.

Step 6 Click Browse to select the navigation path to the desired file. The File Name on Device field will automatically be set based on the actual filename. Note: The file can reside anywhere on the Security Manager server; however, it must reside on the server. File selection from the Security Manager client computer is not supported. After the File Object is created, Security Manager automatically copies the file into its central file repository.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 Click OK to save the object.


Understanding IKE Proposal Objects

Internet Key Exchange (IKE) proposal objects contain the parameters required for IKE proposals when defining remote access VPN policies. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).

The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes security associations (SAs) for other applications, such as IPsec. Both phases use proposals when they negotiate a connection.

For more information about IKE proposals, see Understanding IKE, page 10-47. To create an IKE proposal object, see Creating IKE Proposal Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating IKE Proposal Objects

You can create IKE proposal objects to use when you define IKE proposals for remote access VPN policies. When you create an IKE proposal object, you must enter the priority of the proposal and define the encryption and authentication methods to use. Additionally, you can modify the default lifetime of the SA, if required.

This procedure describes how to create IKE proposal objects.


Tip You can also create IKE proposal objects when defining policies that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding IKE Proposal Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select IKE Proposals from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The IKE Proposal dialog box appears. For a description of the fields in this dialog box, see Table F-36 on page F-53.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 (Optional) Enter a priority value for the IKE proposal. Lower values indicate higher priorities. If the remote IPsec peer does not support the parameters selected in your first priority policy, the device tries to use the parameters defined in the policy with the next lowest priority number.


Note If you leave this field blank, Security Manager assigns the lowest unassigned value starting with 1, then 5, then continuing in increments of 5.


Step 6 Select the encryption algorithm to use to establish the Phase 1 SA for protecting Phase 2 negotiations. See Deciding Which Encryption Algorithm to Use, page 10-47.

Step 7 Select the hash algorithm to use for authentication and ensuring data integrity. See Deciding Which Hash Algorithm to Use, page 10-48.

Step 8 In the Modulus Group field, select the Diffie-Hellman group to use for deriving a shared secret between two IPsec peers without transmitting it to each other. See Deciding Which Diffie-Hellman Group to Use, page 10-48.

Step 9 Enter the SA lifetime, in seconds. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes.

Step 10 Select the method of authentication to use to establish the identity of each IPsec peer. See Deciding Which Authentication Method to Use, page 10-49.

Step 11 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 12 Click OK to save the object.


Understanding Inspection Map Objects

Inspection map objects comprise class maps and policy maps. The Inspection Maps policy object is subdivided into several entries. The Class Maps folder contains all Layer 7 class-maps that are supported in ASA and PIX devices running software versions 7.2 and higher. The Policy Maps folder contains all Layer 7 policies that are supported. Also included in the Inspect Maps folder are entries for TCP Map objects, Regular Expression objects, and Regular Expression Group objects.

Class Maps

An inspection class map matches application traffic with criteria specific to the application, such as a URL string. You then identify the class map in the inspect map and enable actions. The difference between creating a class map and defining the traffic match directly in the inspect map policy object is that you can reuse class maps in more than one inspect map policy. You can create class maps for the inspection of DNS, FTP, HTTP, IM, and SIP traffic.

To create class maps, see Creating Class Map Objects.

To create the regular expressions and regular expression groups that you can use in class and policy inspection maps, see these topics:

Creating Regular Expression Group Objects

Creating Regular Expression Objects

Policy Maps

The algorithm the security appliance uses for stateful application inspection ensures the security of applications and services. Some applications require special handling, and specific application inspection engines are provided for this purpose. Applications that require special application inspection engines are those that embed IP addressing information in the user data packet or open secondary channels on dynamically assigned ports.

Application inspection engines work with NAT to help identify the location of embedded addressing information. This allows NAT to translate these embedded addresses and to update any checksum or other fields that are affected by the translation.

Each application inspection engine also monitors sessions to determine the port numbers for secondary channels. Many protocols open secondary TCP or UDP ports to improve performance. The initial session on a well-known port is used to negotiate dynamically assigned port numbers. The application inspection engine monitors these sessions, identifies the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.

In addition, stateful application inspection audits the validity of the commands and responses within the protocol being inspected. The security appliance helps to prevent attacks by verifying that traffic conforms to the RFC specifications for each protocol that is inspected.

You can create inspect maps for specific protocol inspection engines. You use an inspect map to store the configuration for a protocol inspection engine. You then enable the configuration settings in the inspect map by associating the map with a specific type of traffic using a global security policy or a security policy for a specific interface.

You can use Security Manager to create policy inspection map objects for the following applications: DCE/RPC, DNS, ESMTP, FTP, GTP, H.323, HTTP, IM, IPsec, NetBIOS, SIP, Skinny, and SNMP.

To create policy inspection maps, refer to the following:

Creating DCE/RPC Map Objects

Creating DNS Map Objects

Creating ESMTP Map Objects

Creating FTP Map Objects

Creating GTP Map Objects

Creating H.323 Map Objects

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

Creating IM Map Objects for IOS Devices

Creating IPSec Pass Through Map Objects

Creating NetBIOS Map Objects

Creating SIP Map Objects

Creating Skinny Map Objects

Creating SNMP Map Objects

You can also create TCP Maps, which are not a Layer 7 policy inspection map, as described in Creating TCP Map Objects.

Creating Class Map Objects

You can create class maps as independent policy objects and then assign them to specific policy inspection map objects. Although you can create class maps directly in a policy map object, by creating them separately, you can reuse the class maps in multiple policy objects.

The procedure for creating a class map is essentially the same for each type of class map. The only difference is that the available criteria differ based on the type of traffic for which you are creating the object.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select the type of class map object you want to create from the Inspect Maps > Class Maps folder.

Step 3 Right-click inside the work area, then select New Object.

The Add Class Map dialog box appears (see Add or Edit Class Maps Dialog Boxes, page F-54).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the match criteria table, then select Add Row.

The Add Match Criterion dialog box appears.

Step 6 Select the criterion from the list. The available criteria differ depending on the type of class map you are creating. For more information regarding criterion, see the topic related to the type of class map:

DNS Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-59

FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66

H.323 Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-75

HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87

IM Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-92

SIP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-99

Step 7 Select the match type from the list.

Step 8 Complete the dialog box with appropriate values. The dialog box values vary based on your selection in the Criterion list.

Step 9 Click OK.

The Add Match Criterion dialog box closes and you return to the Add Class Map dialog box.

Step 10 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 11 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 12 Click OK to save the object.


Creating DCE/RPC Map Objects

A DCE/RPC inspection policy map lets you change the default configuration values used for DCE/RPC inspection.

DCE/RPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

This typically involves a client querying a server called the Endpoint Mapper listening on a well-known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.

DCE/RPC inspection maps inspect for native TCP communication between the EPM and client on well-known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and port number are received from the applicable EPM response messages. Because a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > DCE/RPC Maps.

The DCE/RPC Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add DCE/RPC Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Change the default parameter values if they do not suit your requirements. For information on the options, see Add or Edit DCE/RPC Dialog Box, page F-56.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating DNS Map Objects

A DNS map lets you change the default configuration values used for DNS application inspection.

DNS application inspection supports DNS message controls that provide protection against DNS spoofing and cache poisoning. User configurable rules allow certain DNS types to be allowed, dropped, or logged, while others are blocked. Zone transfer can be restricted between servers with this function, for example.

The Recursion Desired and Recursion Available flags in the DNS header can be masked to protect a public server from attack if that server only supports a particular internal zone. In addition, DNS randomization can be enabled avoid spoofing and cache poisoning of servers that either do not support randomization or utilize a weak pseudo random number generator. Limiting the domain names that can be queried protects the public server further.

A configurable DNS mismatch alert can be used as notification if an excessive number of mismatching DNS responses are received, which could indicate a cache poisoning attack. In addition, a configurable check to enforce a Transaction Signature be attached to all DNS messages is also supported.

Related Topics

Understanding Inspection Map Objects

Creating Class Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > DNS Maps.

The DNS Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add DNS Map dialog box appears (see Add and Edit DNS Map Dialog Boxes, page F-56).

Step 4 Enter the name of the object and optionally a description.

Step 5 Click the Protocol Conformance tab and select the options you want to enforce. For information on the available options, see DNS Map Protocol Conformance Tab, page F-58.

Step 6 Click the Filtering tab and select the options you want to enforce. For information on the available options, see DNS Map Filtering Tab, page F-58.

Step 7 Click the Mismatch Rate tab and select whether you want to log DNS mismatches based on threshold or time interval limits. For more information, see Add and Edit DNS Map Dialog Boxes, page F-56.

Step 8 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see DNS Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-59.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 11 Click OK to save the object.


Creating ESMTP Map Objects

An ESMTP policy map lets you change the default configuration values used for ESMTP inspection.

ESMTP inspection detects attacks, including spam, phising, malformed message attacks, and buffer overflow/underflow attacks. It also provides support for application security and protocol conformance, which enforce the sanity of the ESMTP messages as well as detect several attacks, block senders/receivers, and block mail relay.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > ESMTP Maps.

The ESMTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add ESMTP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit ESMTP Map Dialog Boxes, page F-62.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see ESMTP Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-63.

c. Click OK to save your changes.

The Add Match Condition and Action dialog box closes and you return to the Add Skinny Map dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Creating FTP Map Objects

An FTP policy map object lets you change the default configuration values used for FTP application inspection. When creating an FTP policy inspection map, you can use FTP class map objects as part of the map object.

FTP is a common protocol used for transferring files over a TCP/IP network such as the Internet. You can use an FTP map to block specific FTP protocol methods, such as an FTP PUT, from passing through the security appliance and reaching your FTP server.

Related Topics

Understanding Inspection Map Objects

Creating Class Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > FTP Maps from the Object Type selector. The FTP Maps page opens, displaying a list of the existing FTP Map objects.

Step 3 Right-click inside the work area, then select New Object.

The Add FTP Map dialog box appears (see Add and Edit FTP Map Dialog Boxes, page F-65).

Step 4 Enter the name of the object and optionally a description.

Step 5 On the Parameters tab, determine whether you want to mask server information from the user.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears (see FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66).

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Although optional, you can select the platform for which you will use this object in the Validate For field and click Validate to verify that the object can be used on that platform. This can help you avoid deployment problems later.

Step 10 Click OK to save the object.


Creating GTP Map Objects

The GPRS Tunnel Protocol (GTP) provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate networks or the Internet. GTP uses a tunneling mechanism to provide a service for carrying user data packets.

A GTP map object lets you change the default configuration values used for GTP application inspection. The GTP Map object page lets you create, view, and manage GTP inspect maps. The GTP protocol is designed to provide security for wireless connections to TCP/IP networks such as the Internet. You can use a GTP map to control timeout values, message sizes, tunnel counts, and GTP versions traversing the security appliance.


Tip GTP inspection requires a special license. If you do not have the required license, you will see device errors if you try to deploy a GTP map.


Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > GTP Maps.

The GTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add GTP Map dialog box appears (see Add and Edit GTP Map Dialog Boxes, page F-68).

Step 4 Enter the name of the object and optionally a description.

Step 5 On the Parameters tab, configure the desired settings. All settings on this tab are optional; change them only if the defaults do not suit your requirements. You can configure the following options:

In the Country and Network Codes table, click Add Row to add codes to the table.

In the Permit Response table, click Add Row to add Network/Host object pairs for which you will permit GTP responses from a GSN that is different from the one to which the response was sent.

In Request Queue, you can specify the maximum requests allowed in the queue.

In Tunnel Limit, you can specify the maximum number of tunnels allowed.

You can select Permit Errors to allow packets with errors or different GTP versions that are invalid or that encountered an error during inspection to be sent through the security appliance instead of being dropped.

By clicking Edit Timeouts, you can configure the time out values for various operations (see GTP Map Timeouts Dialog Box, page F-71).

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see GTP Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-71.

c. Click OK to save your changes.

The Add Match Condition and Action dialog box closes and you return to the Add GTP Map dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Although optional, you can select the platform for which you will use this object in the Validate For field and click Validate to verify that the object can be used on that platform. This can help you avoid deployment problems later.

Step 10 Click OK to save the object.


Creating H.323 Map Objects

An H.323 policy map lets you change the default configuration values used for H.323 inspection.

H.323 inspection supports H.323 compliant applications such as Cisco CallManager and VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication Union for multimedia conferences over LANs. The security appliance supports H.323 through Version 4, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.

With H.323 inspection enabled, the security appliance supports multiple calls on the same call signaling channel, a feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the security appliance. The two major functions of H.323 inspection are as follows:

NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages are encoded in PER encoding format, the security appliance uses an ASN.1 decoder to decode the H.323 messages.

Dynamically allocate the negotiated H.245 and RTP/RTCP connections.

Related Topics

Understanding Inspection Map Objects

Creating Class Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > H.323 Maps.

The H.323 Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add H.323 Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. You can add HSI groups and end points and select other options if the default values do not meet your requirements. For an explanation of the options, see Add and Edit H.323 Map Dialog Boxes, page F-73.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see H.323 Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-75.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Configuring HTTP Policy Map Objects

An HTTP map object lets you change the default configuration values used for HTTP application inspection. An HTTP Map object defines different HTTP packet criteria to be inspected, as well as the action to be taken when the criteria are met. The HTTP Map object only defines general HTTP protocol-related parameters; it is not specific to any particular traffic flow. This ensures that the same HTTP Map object can be reused for different devices or different traffic flow within a single device.

The enhanced HTTP inspection feature, also known as an application firewall, verifies that HTTP messages conform to RFC 2616, use RFC-defined and supported extension methods, and comply with various other criteria. This can help prevent attackers from using HTTP messages for circumventing network security policy.


Note When you enable HTTP inspection with an HTTP map, strict HTTP inspection with the action reset and log is enabled by default. You can change the actions performed in response to inspection failure, but you cannot disable strict inspection as long as the HTTP map remains enabled.


In many cases, you can configure the criteria and how the security appliance responds when the criteria are not met.

The following topics describe how to create HTTP inspection maps based on the target device operating system:

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

An HTTP map lets you change the default configuration values used for HTTP application inspection. This procedure explains how to create a map that you can deploy to devices that run ASA 7.1.x, PIX 7.1.x, FWSM 3.x, or IOS operating systems.

For more information about HTTP maps, see Configuring HTTP Policy Map Objects.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Configuring HTTP Policy Map Objects

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > HTTP Maps (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS).

The HTTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add HTTP Map dialog box appears (see Add and Edit HTTP Map Dialog Boxes for ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS Devices, page F-77).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Click the General tab and define the actions you want to take when non-compliant HTTP requests are received and to verify content type. For a description of the options, see HTTP Map General Tab, page F-78.

Step 6 Click the Entity Length tab and define the actions you want to take if the length of the HTTP content falls outside of configured targets. For a description of the options, see HTTP Map Entity Length Tab, page F-79.

Step 7 The remaining four tabs function in the same way. You can select from a list of available methods, application categories, or encoding types, and configure an action and syslog setting for the ones you want to handle in specific ways. You can also select the option to specify an action to take for the ones you do not uniquely configure. The tabs, and what you can configure on them, are:

RFC Request Method tab—Defines the action that the security appliance should take when specific RFC request methods are used in the HTTP request. For a description of the options, see HTTP Map RFC Request Method Tab, page F-81.

Extension Request Method tab—Defines the action taken when specific extension request methods are used in the HTTP request. For a description of the options, see HTTP Map Extension Request Method Tab, page F-82.

Port Misuse tab—Defines the action taken when specific undesirable applications are encountered. For a description of the options, see HTTP Map Port Misuse Tab, page F-83.

Transfer Encoding tab—Defines the action taken when specific transfer encoding types are used in the HTTP request. For a description of the options, see HTTP Map Transfer Encoding Tab, page F-84.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 10 Click OK to save the object.


Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

An HTTP map lets you change the default configuration values used for HTTP application inspection. This procedure explains how to create a map that you can deploy to devices that run ASA 7.2 or higher or PIX 7.2 or higher operating systems.

For more information about HTTP maps, see Configuring HTTP Policy Map Objects.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Configuring HTTP Policy Map Objects

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > HTTP Maps (ASA 7.2+/PIX 7.2+) from the Object Type selector. The HTTP Maps page for ASA/PIX 7.2 and higher opens, displaying a list of the existing HTTP Map objects.

Step 3 Right-click inside the work area, then select New Object.

The Add HTTP Map dialog box appears (Add or Edit HTTP Map Dialog Boxes for ASA 7.2+/PIX 7.2+ Devices, page F-85).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Complete the information in the Parameters tab. For a description of the options, see Add or Edit HTTP Map Dialog Boxes for ASA 7.2+/PIX 7.2+ Devices, page F-85.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears. For a description of the GUI elements, see HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87.

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

An IM map lets you change the default configuration values used for IM application inspection.

Instant Messaging causes concern due to its use of clear text when conducting business and the potential for network attacks and the spreading of viruses. Thus, you might want to block certain types of instant messages from occurring, while allowing others.

For ASA and PIX devices, IM application inspection provides detailed access control to control network usage. It also helps stop leakage of confidential data and the propagation of network threats. A regular expression database search representing various patterns for IM protocols to be filtered is applied. A syslog is generated if the flow is not recognized. You can inspect Yahoo! Messenger or MSN Messenger traffic.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Creating Class Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > IM Maps (ASA 7.2+/PIX 7.2+).

The IM Maps (ASA 7.2+/PIX 7.2+) page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add IM Map dialog box appears (see Add and Edit IM Map Dialog Boxes (for ASA 7.2+/PIX 7.2+), page F-91).

Step 4 Enter the name of the object and optionally a description.

Step 5 Configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see IM Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-92.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating IM Map Objects for IOS Devices

You can create Instant Messenger inspection map objects for use on IOS devices. An IM map lets you change the default configuration values used for IM application inspection.

Instant Messaging causes concern due to its use of clear text when conducting business and the potential for network attacks and the spreading of viruses. Thus, you might want to block certain types of instant messages from occurring, while allowing others.

IM application inspection provides detailed access control to control network usage. It also helps stop leakage of confidential data and the propagation of network threats. The scope can be limited by using an access list to specify any traffic streams to be inspected. For UDP messages, a corresponding UDP port number is also configurable. Inspection of Yahoo! Messenger, MSN Messenger, and AOL instant messages are supported.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > IM Maps (IOS) from the Object Type selector. The IM Maps (IOS) page opens, displaying a list of the existing IM Map for IOS objects.

Step 3 Right-click inside the work area, then select New Object.

The Add IM Map (IOS) dialog box appears (see Add or Edit IM Map (IOS) Dialog Boxes, page F-94).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the appropriate options for each service provider that you want to configure. The fields for each provider are identical, but you must configure each service separately. Typically, you want to determine whether you want to allow, deny, or log the various services provided by these IM applications. You can also permit or deny specific servers, which can help you block known sources of unwanted traffic.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating IPSec Pass Through Map Objects

An IPsec Pass Through policy map lets you change the default configuration values used for IPsec Pass Through inspection.

The IPSec Pass Through inspection engine lets the security appliance pass ESP (IP protocol 50) and AH (IP protocol 51) traffic that is formed between two hosts because of successful IKE (UDP port 500) negotiation without the requirement of specific ESP or AH access lists.

The inspection engine works on IKE UDP port 500 to create the control flow. The inspect ipsec-pass-thru command is attached to a UDP flow as defined in the MPF framework. When an ESP or AH packet between the two peers arrives at the device, or a UDP packet with either source or destination port equal to 500, the packet is sent to the inspect module.

The ESP or AH traffic is permitted by the inspection engine with the configured idle timeout if there is an existing control flow and it is within the connection limit defined in the MPF framework. A new control flow is created for IKE UDP port 500 traffic with the configured UDP idle timeout if there is not one, or it uses the existing flow.

To ensure that the packet arrives into the inspection engine, a hole is punched for all such traffic (ESP and AH). This inspect is attached to the control flow. The control flow is present as long as there is at least one data flow (ESP or AH) established, but the traffic always flows on the same connection. Because this IKE connection is kept open as long as data flows, a rekey would always succeed. The flows are created irrespective of whether NAT is being used. However, PAT is not supported.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > IPSec Pass Through Maps.

The IPSec Pass Through Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add IPSec Pass Through Map dialog box appears (see Add or Edit IPsec Pass Through Map Dialog Boxes, page F-95).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select whether to allow ESP or AH traffic, or both, and configure the allowable tunnel and timeout values.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating NetBIOS Map Objects

A NetBIOS policy map lets you change the default configuration values used for NetBIOS inspection.

The NetBIOS inspection engine translates IP addresses in the NetBIOS name service (NBNS) packets according to the security appliance NAT configuration.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > NetBIOS Maps.

The NetBIOS Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add NetBIOS Map dialog box appears (see Add or Edit NetBIOS Map Dialog Boxes, page F-96).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select Check for Protocol Violations if you want to specify an action to take if violations occur, and select the desired action.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating SIP Map Objects

A SIP policy inspection map lets you change the default configuration values used for SIP application inspection.

SIP is a widely used protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. Partially because of its text-based nature and partially because of its flexibility, SIP networks are subject to a large number of security threats.

SIP application inspection provides address translation in message header and body, dynamic opening of ports and basic sanity checks. It also supports application security and protocol conformance, which enforce the sanity of the SIP messages, as well as detect SIP-based attacks.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Creating Class Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > SIP Maps.

The SIP Maps page appears.

Step 3 Right-click inside the work area, then click New Object.

The Add SIP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit SIP Map Dialog Boxes, page F-97.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see SIP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-99.

If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Creating Skinny Map Objects

A Skinny policy map lets you change the default configuration values used for Skinny inspection.

Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals. Application layer functions in the security appliance recognize SCCP version 3.3. There are 5 versions of the SCCP protocol: 2.4, 3.0.4, 3.1.1, 3.2, and 3.3.2.

The security appliance supports all versions through 3.3.2. The security appliance supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application inspection ensures that all SCCP signaling and media packets can traverse the security appliance.

Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The security appliance also supports DHCP options 150 and 66, which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > Skinny Maps.

The Skinny Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Skinny Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit Skinny Map Dialog Boxes, page F-101.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see Skinny Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-103.

c. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Creating SNMP Map Objects

An SNMP policy map lets you change the default configuration values used for SNMP application inspection.

SNMP application inspection lets you restrict SNMP traffic to a specific version of SNMP. Earlier versions of SNMP are less secure; therefore, denying certain SNMP versions may be required by your security policy. The security appliance can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by creating an SNMP map. You then apply the SNMP map when you enable SNMP inspection.

Related Topics

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > SNMP Maps.

The SNMP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add SNMP Map dialog box appears (see Add and Edit SNMP Map Dialog Boxes, page F-103).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the SNMP versions you want to prohibit.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating Regular Expression Group Objects

A Regular Expression Group object groups regular expressions together. The objects can be used by inspection class maps and inspection policy maps.

Related Topics

Guidelines for Managing Objects

Creating Regular Expression Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Regular Expression Groups.

The Regular Expression Groups page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Regular Expression Group dialog box appears (see Add and Edit Regular Expression Group Dialog Boxes, page F-104).

Step 4 Enter the name of the object and optionally a description.

Step 5 Enter the names of the Regular Expression objects to include in the group in the Regular Expressions field. Click Select to select the objects from a list or to create new objects.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Creating Regular Expression Objects

A regular expression matches text strings either literally as an exact string or by using metacharacters so you can match multiple variants of a text string. You can use regular expressions in various type of class and policy inspection maps to match various target items, for example, the content of certain application traffic such as the body text inside an HTTP packet.

Related Topics

Guidelines for Managing Objects

Metacharacters Used to Build Regular Expressions

Creating Regular Expression Group Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Regular Expressions.

The Regular Expressions page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Regular Expression dialog box appears (see Add and Edit Regular Expression Dialog Boxes, page F-105).

Step 4 Enter the name of the object and optionally a description.

Step 5 Enter the regular expressions in the Value field. For information on the metacharacters you can use to build regular expressions, see Metacharacters Used to Build Regular Expressions.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Metacharacters Used to Build Regular Expressions

Table 9-7 explains the metacharacters you can use to build regular expressions. Keep the following tips in mind when creating regular expressions:

If you enter any metacharacters in your text string that you want to be used literally, add the backslash (\) escape character before them. For example, "example\.com".

If you want to match upper and lower case characters, enter text in both upper- and lowercase. For example, "cats" is entered as "[cC][aA][tT][sS]".

Table 9-7 Metacharacters Used to Build Regular Expressions 

Character
Description
Notes

.

Dot

Matches any single character. For example, d.g matches dog, dag, dtg, and any word that contains those characters, such as doggonnit.

(exp)

Subexpression

A subexpression segregates characters from surrounding characters, so that you can use other metacharacters on the subexpression. For example, d(o|a)g matches dog and dag, but do|ag matches do and ag. A subexpression can also be used with repeat quantifiers to differentiate the characters meant for repetition. For example, ab(xy){3}z matches abxyxyxyz.

|

Alternation

Matches either expression it separates. For example, dog|cat matches dog or cat.

?

Question mark

A quantifier that indicates that there are 0 or 1 of the previous expression. For example, lo?se matches lse or lose.

*

Asterisk

A quantifier that indicates that there are 0, 1 or any number of the previous expression. For example, lo*se matches lse, lose, loose, etc.

+

Plus

A quantifier that indicates that there is at least 1 of the previous expression. For example, lo+se matches lose and loose, but not lse.

{x}

Repeat Quantifier

Repeat exactly x times. For example, ab(xy){3}z matches abxyxyxyz.

 

Minimum repeat quantifier

Repeat at least x times. For example, ab(xy){2,}z matches abxyxyz, abxyxyxyz, etc.

[abc]

Character class

Matches any character in the brackets. For example, [abc] matches a, b, or c.

[^abc]

Negated character class

Matches a single character that is not contained within the brackets. For example, [^abc] matches any character other than a, b, or c. [^A-Z] matches any single character that is not an uppercase letter.

[a-c]

Character range class

Matches any character in the range. [a-z] matches any lowercase letter. You can mix characters and ranges: [abcq-z] matches a, b, c, q, r, s, t, u, v, w, x, y, z, and so does [a-cq-z].

The dash (-) character is literal only if it is the last or the first character within the brackets: [abc-] or [-abc].

""

Quotation marks

Preserves trailing or leading spaces in the string. For example, " test" preserves the leading space when it looks for a match.

^

Caret

Specifies the beginning of a line.

\

Escape character

When used with a metacharacter, matches a literal character. For example, \[ matches the left square bracket.

char

Character

When character is not a metacharacter, matches the literal character.

\r

Carriage return

Matches a carriage return 0x0d.

\n

Newline

Matches a new line 0x0a.

\t

Tab

Matches a tab 0x09.

\f

Formfeed

Matches a form feed 0x0c.

\xNN

Escaped hexadecimal number

Matches an ASCII character using hexadecimal (exactly two digits).

\NNN

Escaped octal number

Matches an ASCII character as octal (exactly three digits). For example, the character 040 represents a space.


Related Topics

Creating Regular Expression Objects

Creating Regular Expression Group Objects

Creating TCP Map Objects

The TCP Maps object lets you customize inspection on TCP flow for both through and to box traffic.

Related Topics

Guidelines for Managing Objects

Understanding Inspection Map Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > TCP Maps.

The TCP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add TCP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select from the settings you want to configure for the map, including TCP option ranges and how to handle reserved bits. For a complete explanation of the options, see Add and Edit TCP Map Dialog Boxes, page F-106.

Step 6 (Optional) Select a color from the Category list to help you readily identify the object when it appears in the object or rules tables. For more information, see Using Category Objects.

Step 7 Click OK to save the object.


Understanding Interface Role Objects

Interface role objects enable you to apply policies to specific interfaces on multiple devices without having to manually define the name of each interface. Because most devices follow a standard naming convention for their interfaces, you can define a naming pattern that describes a particular interface type and then assign a policy to all interfaces matching that pattern.

For example, you might define an interface role with a naming pattern of DMZ*. When you include this interface role in a policy, the policy is applied to all interfaces whose name begins with "DMZ" on the selected devices. As a result, you can, for example, assign a policy that enables anti-spoof checking on all DMZ interfaces to all relevant device interfaces with a single action. Interface roles can refer to any of the actual interfaces on the device, including physical interfaces, subinterfaces, and virtual interfaces, such as loopback interfaces.

Interface roles serve as an indirection entity between interfaces on the one hand and policies on the other. This enables you to apply policies to particular device interfaces based on the assigned role. Additionally, if you change the naming convention used for a particular interface type, you do not need to determine which policies are affected by the change. All you do is edit the interface role. Interface roles are especially useful when applying policies to new devices. As long as the devices you are adding share the same interface naming scheme as existing devices, the relevant policies can be extended to them without the need to make additional assignments.

Security Manager includes the following predefined interface roles:

All-Interfaces

Internal

External

The following topics describe how to work with interface role objects:

Creating Interface Role Objects

Specifying Interfaces During Policy Definition

Exceptional Cases When Using Interface Roles

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating Interface Role Objects

You can create interface role objects that represent one or more interfaces on devices. These interface roles can then be used when you define policies that require interfaces. When you create an interface role object, you must define the naming pattern of the device interfaces to include in the object. Interface roles can refer to any of the actual interfaces on the device, including physical interfaces, subinterfaces, and virtual interfaces.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override interface role object definitions at the device level, which enables you to associate the role with specific interfaces on a particular device. For more information, see Managing Object Overrides.

This procedure describes how to create interface role objects.


Tip You can also create interface role objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Exceptional Cases When Using Interface Roles

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Interface Roles from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The Interface Role dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Enter one or more naming patterns for the interface role object. This pattern defines the device interfaces to include in the definition of the interface role. Separate multiple patterns with commas.

Two wildcards are available:

You can use a period (.) as a wildcard to represent a single character.

You can use an asterisk (*) as a wildcard at the end of a pattern to represent multiple interfaces with similar names. (An asterisk can also be used on its own to indicate all interfaces.)

If the pattern does not include a wildcard, it must match the exact name of the interface. For example, the pattern "FastEthernet" will not match FastEthernet0/1 unless you include an asterisk at the end of the pattern.


Note When the pattern defines a subinterface, enter a backslash (\) before the period. Otherwise, Security Manager treats the period as a wildcard.


Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Specifying Interfaces During Policy Definition

Security Manager provides you with several options for specifying an interface when defining a policy:

Entering the name of an interface manually. (To manually enter a subinterface, see Specifying Interfaces During Policy Definition.)

Entering the name of an interface role manually. See Understanding Interface Role Objects.

Selecting an interface or interface role from a list. For more information, see Selecting Objects for Policies.

When the policy allows multiple interfaces, each entry must be separated by a comma.

Defining Subinterfaces

If you manually define a subinterface as part of a policy definition, be sure to enter a backslash (\) before the period. If you enter the period without the backslash, Security Manager treats the period as a wildcard for a single character.

For example, if you want to define Ethernet1/1.0 as part of an access rule, you need to enter Ethernet1/1\.0 in the Interfaces field. If you enter Ethernet1/1.0 instead, the interface role will match interfaces named Ethernet1/1.0 and Ethernet1/1/0, since the period on its own is treated as a wildcard.


Note Subinterfaces always appear with a backslash in object selectors.


Distinguishing Interfaces from Interface Roles

When using the selector, be aware that there may be interfaces and interface roles with the same name. They can be distinguished by the icon displayed next to the name, as shown in Table 9-8.

Table 9-8 Icons for Interfaces and Interface Roles 

Type
Icon

Interface

Interface role


Related Topics

Basic Interface Settings on Cisco IOS Routers, page 14-14

Configuring Firewall Device Interfaces, page 15-2

Understanding Interface Role Objects

Creating Interface Role Objects

Exceptional Cases When Using Interface Roles

Exceptional Cases When Using Interface Roles

This section describes exceptional cases than can occur when defining interface roles in policies.

One Interface Role Assigned to Multiple Interfaces

When using interface roles, you might define a role that applies to more than one interface on a device. For example, the All-Ethernets interface role might be assigned to two different Ethernet interfaces on the device. If you then define a policy requiring a single interface definition that includes the All-Ethernets interface role, a warning message tells you that Security Manager will use the first interface on the device it finds with that role. Any other interfaces assigned the same role are ignored.

Interfaces and Interface Roles with the Same Name

Under normal circumstances, you can configure an interface role that has the same name as an actual interface on the device. If you use object selectors when defining policies (see Selecting Objects for Policies), both the interface and the interface role are listed as available choices, enabling you to select either option. If you type in this common name when you define a policy, Security Manager automatically associates the interface role with the policy, not the interface.

However, a naming conflict can occur under the following circumstances:

1. You type the name of an interface when defining a policy.

2. You later create an interface role that has the same name.

3. You type this name again when defining a policy.

4. You click Select to display the object selector, or Save to save the policy.

When this sequence of events occurs, the Interface Name Conflict Dialog Box, page F-109 is displayed. From here, you can select whether to include the interface or the interface role in the policy.

Related Topics

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Creating Interface Role Objects

Understanding IPsec Transform Set Objects

A transform set comprises a combination of security protocols, algorithms and other settings that specify exactly how the data in the IPsec tunnel will be encrypted and authenticated. During IPsec security association negotiation, the peers agree to use a particular transform set when protecting a particular data flow. When defining a transform set, you can make use of the AH (authentication header) protocol, the ESP (encapsulation security protocol) protocol, or both. When using ESP, you can specify whether to use ESP encryption only, or ESP encryption together with ESP authentication. Additionally, you can use the transform set to specify whether to compress the traffic being carried over the IPsec tunnel.


Note We recommend using both encryption and authentication on IPsec tunnels.


IPsec transform set objects are used when defining IPsec proposal policies for VPNs. For more information, see Configuring IPsec Proposals, page 10-53.

To create an IPsec transform set object, see Creating IPsec Transform Set Objects.

Related Topics

IPsec Protocols

IPsec Modes

Policy Object Manager Window, page F-1

Creating Objects

IPsec Protocols

Two different security protocols are included within the IPsec standard:

Encapsulating Security Protocol (ESP)—Provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.

Authentication Header (AH)—Provides authentication and anti-replay services. AH does not provide encryption and has largely been superseded by ESP. AH is IP protocol type 51.

When using ESP, you can choose from several encryption options, including:

Data Encryption Standard (DES)

3DES (requires 3DES license)

Advanced Encryption Standard (AES—128-bit, 192-bit, and 256-bit)

ESP and AH perform authentication through the use of a hash algorithm, which creates a message to ensure message integrity. Both ESP and AH offer the following authentication options:

Message Digest 5 (MD5)—Produces a 128-bit digest. MD5 uses less processing time than SHA, but is less secure.

Secure Hash Algorithm (SHA)—Produces a 160-bit digest. SHA is more resistant to brute-force attacks than MD5, but requires more processing time.

Related Topics

IPsec Modes

Creating IPsec Transform Set Objects

Understanding IPsec Transform Set Objects

IPsec Modes

IPsec can operate in the following modes:

Tunnel Mode—Tunnel mode encapsulates the entire IP packet. The IPsec header is added between the original IP header and a new IP header. Tunnel mode is used when the firewall is protecting traffic to and from hosts positioned behind the firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.

Transport Mode—Transport mode encapsulates only the upper-layer protocols of an IP packet. The IPsec header is inserted between the IP header and the upper-layer protocol header (such as TCP). Transport mode requires that both the source and destination hosts support IPsec, and can only be used when the destination peer of the tunnel is the final destination of the IP packet. Transport mode is generally used only when protecting a Layer 2 or Layer 3 tunneling protocol such as GRE, L2TP, and DLSW.

Related Topics

IPsec Protocols

Creating IPsec Transform Set Objects

Understanding IPsec Transform Set Objects

Creating IPsec Transform Set Objects

You can create IPsec transform set objects for use in IPsec proposals when defining site-to-site and remote access VPNs. When you create an IPsec transform set object, you must select the mode in which IPsec should operate, as well as define the required encryption and authentication types. Additionally, you can select whether to include compression in the transform set.

This procedure describes how to create IPsec transform set objects.


Tip You can also create IPsec transform set objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding IPsec Transform Set Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select IPsec Transform Sets from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The IPsec Transform Set dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the required IPsec mode—tunnel or transport. For more information, see IPsec Modes.

Step 6 (Optional) Select the type of ESP encryption and authentication to use in the transform set. If the AH protocol is being used instead of ESP, leave this field blank, then select the type of AH authentication to use. For more information, see IPsec Protocols.

Step 7 (Optional) Select the Compression check box to compress the data in the IPsec tunnel.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.


Understanding LDAP Attribute Map Objects

Use the LDAP Attribute Map page to create and name an attribute map for mapping custom (user-defined) attribute names to Cisco LDAP attribute names. If you are introducing a security appliance to an existing LDAP directory, your existing custom LDAP attribute names and values are probably different from the Cisco attribute names and values. Rather than renaming your existing attributes, you can create LDAP attribute maps that map your custom attribute names and values to Cisco attribute names and values. By using simple string substitution, the security appliance then presents you with only your own custom names and values. You can then bind these attribute maps to LDAP servers or remove them as needed. You can also delete entire attribute maps or remove individual name and value entries.

For more information regarding AAA Support on ASA devices, see LDAP.

Related Topics

Creating LDAP Attribute Map Objects

Creating LDAP Attribute Map Objects

Use the Add and Edit LDAP Attribute Map dialog boxes to add or edit an existing LDAP attribute map.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding LDAP Attribute Map Objects

Overriding Global Objects for Individual Devices

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select LDAP Attribute Maps from the Object Type selector.

Step 3 Right-click inside the work area, then select New Object.

The Add LDAP Attribute Map dialog box appears. For a description of the GUI elements, see Table F-80 on page F-112.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the table, then select Add Row.

The Add LDAP Attribute Map Value dialog box appears. For a description of the GUI elements, see Table F-81 on page F-113.

Step 6 Enter the name of the custom map.

Step 7 Select the Cisco map name from the list.

Step 8 Right-click inside the table, then select Add Row.

The Add Map Value dialog box appears. For a description of the GUI elements, see Table F-82 on page F-114.

Step 9 Enter the Custom Map Value.

Step 10 Enter the Cisco Map Value.

Step 11 Click OK to save your changes.

The Add Map Value dialog box closes and you return to the Add LDAP Attribute Map Value dialog box. The new values are displayed in the table.

Step 12 Click OK to save your changes.

The Add LDAP Attribute Map Value dialog box closes and you return to the LDAP Attribute Maps page. The new object is shown in the table.

Step 13 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 14 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 15 Click OK to save the object.


Understanding Network/Host Objects

Network/host objects are logical collections of IP addresses that represent networks, hosts, or both. They can contain one or more network or host IP addresses, as well as other network/host objects. You can reference network/host objects when defining a variety of policies, instead of specifying each network or host individually. By collecting multiple objects in a network/host object, you can refer to all objects in the group as a single item.

Network/host objects can contain the following:

Networks or subnets, specified by IP addresses and subnet masks.

Individual hosts, specified by IP addresses.

Other network/host objects, specified by selecting from a list of existing objects.

Network/host objects make it easier to manage scalable policies. By using the associative capabilities of network/host objects, you can expand your policies along with your network. For example, when you make changes to the list of addresses contained in a network/host object, the changes propagate to all other network/host objects and to policies that refer to that network/host object.

The following topics describe how to work with network/host objects:

Creating Network/Host Objects

Using Unspecified Network/Host Objects

Supported IP Address Formats

Contiguous and Discontiguous Network Masks

Specifying IP Addresses During Policy Definition

Related Topics

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

Policy Object Manager Window, page F-1

Creating Objects

Supported IP Address Formats

When defining network/host objects, you can use any of the following formats:

Host address: x.x.x.x (where x is a value between 0-255)

Example: 192.0.2.252

Network IP address: x.x.x.x/y (where x is a value between 0-255, and y is a value between 1-32)

Example: 192.0.2.0/24

Network IP address: x.x.x.x/x.x.x.x (where x is a value between 0-255)

Example: 192.0.2.0/255.255.255.0

IP address range: x.x.x.x—x.x.x.x

Examples: 192.0.2.14—192.0.2.112

Notes

IP address ranges can span more than one subnet.

You cannot define an IP address range with a network mask when defining a network/host object. You can, however, add the network mask when entering the address range directly in a policy. See Specifying IP Addresses During Policy Definition.

For more information about how Security Manager works with network masks, see Contiguous and Discontiguous Network Masks.

Network/Host Object Optimization

Security Manager optimizes the addresses that you define in network/host objects by removing redundant entries and combining adjacent entries. For example, 192.168.1.0 and 192.168.1.1 are combined as 192.168.1.0/31. Optimization reduces the size of your configuration and provides better performance and memory usage.

To perform optimization, the adjacent addresses must be located on the same subnet boundary (as defined by the CIDR notation). For example, take the following addresses:

10.1.1.228 (00001010 00000001 00000001 11100100 in binary)

10.1.1.229 (00001010 00000001 00000001 11100101)

These two addresses can be optimized as 10.1.1.228/31. However, in the case of these two addresses:

10.1.1.227 (00001010 00000001 00000001 11100011)

10.1.1.228 (00001010 00000001 00000001 11100100)

Security Manager cannot optimize these addresses because these is no way to define a subnet boundary without including additional addresses.

In addition, optimization cannot be performed in the following circumstances:

On ACLs.

On nested network/host objects, which are objects that refer to other objects as part of their definition.


Note IP addresses that you enter directly when you define a policy (for example, in the Source and Destination fields of an access rule) are not optimized.


Related Topics

Specifying IP Addresses During Policy Definition

Creating Network/Host Objects

Using Unspecified Network/Host Objects

Policy Object Manager Window, page F-1

Understanding Network/Host Objects

Contiguous and Discontiguous Network Masks

A network mask determines which portion of an IP address identifies the network and which portion identifies the host. Like the IP address, the mask is represented by four octets. (An octet is an 8-bit binary number equivalent to a decimal number in the range 0-255.) If a given bit of the mask is 1, the corresponding bit of the IP address is in the network portion of the address, and if a given bit of the mask is 0, the corresponding bit of the IP address is in the host portion.

Standard, or contiguous, network masks start with zero or more 1s followed by zero or more 0s, as described by the regular expression, 1 x 0 (32-x). This kind of network mask is considered contiguous because it represents a network that consists of a contiguous IP address range. For example, the network 192.168.1.0/255.255.255.0 contains all the IP addresses ranging from 192.168.1.0 to 192.168.1.255.

Table 9-9 shows different methods of representing commonly used standard network masks:

Table 9-9 Standard Network Masks 

Dotted Decimal Notation
Classless Inter-Domain Routing (CIDR) Notation

255.0.0.0

/8

255.255.0.0

/16

255.255.255.0

/24

255.255.255.255

/32


For example, 255.255.255.0 indicates that the first three octets of the IP address (24 bits or /24 in CIDR notation) are made up of ones and identify the network; the last octet is made up of zeros and identifies the host.

Discontiguous Network Masks

Nonstandard, or discontiguous, network masks are masks that do not conform to the format of 1 x 0 (32-x). Although discontiguous network masks are not typically used for network configurations, they are sometimes used for certain commands, such as filtering commands when defining access control lists (ACLs). Security Manager supports the use of nonstandard network masks in the policies whose CLI commands support them. An error is displayed if you try to define a discontiguous network mask in a policy that does not support them.

Network Masks and Discovery

During discovery, Security Manager attempts to match network/host objects with existing equivalent objects defined in the Policy Object Manager:

For contiguous network masks—Two network/host objects containing only standard networks are considered equivalent if they consist of the same set of IP addresses.

For discontiguous network masks—Two network/host objects are considered equivalent only if the standard networks consist of the same set of IP addresses and the nonstandard networks are syntactically equivalent.

How Network Masks are Displayed

Although you can enter both contiguous and discontiguous network masks using dotted decimal notation, all contiguous network masks are converted to CIDR notation. This makes it easier to distinguish them from discontiguous network masks, which are displayed in dotted decimal notation only.

Related Topics

Supported IP Address Formats

Creating Network/Host Objects

Specifying IP Addresses During Policy Definition

Using Unspecified Network/Host Objects

Understanding Network/Host Objects

Creating Network/Host Objects

You can create network/host objects to represent networks or individual hosts. When you create a network/host object, you can include one or more IP addresses and address ranges in IPv4 format. Additionally, you can include existing network/host objects in a new network/host object. For example, you can create a network/host object that comprises two existing network/host objects, a range of IP addresses, and two additional IP addresses.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override network/host object definitions at the device level, which enables you to associate the object with a specific IP address used by a particular device. For more information, see Overriding Global Objects for Individual Devices.

This procedure describes how to create network/host objects.


Tip You can create network/host objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

In addition, you can right-click the source or destination defined in an access rule or AAA rule and create a network/host object directly from the contents of the cell. For more information, see Editing Access Rules, page 12-43 and Editing AAA Rules, page 12-62.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Supported IP Address Formats

Contiguous and Discontiguous Network Masks

Specifying IP Addresses During Policy Definition

Using Unspecified Network/Host Objects

Understanding Network/Host Objects

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Networks/Hosts from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The Network/Host dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Under Networks/Hosts, enter the addresses (including network masks; the /32 host mask is not required) and/or address ranges to include in the object, or click Select to display a selector (see Selecting Objects for Policies). Use a "-" to separate the first and last IP address in an address range.

If the network you want is not listed, click the Create button or the Edit button to display the Network/Host Dialog Box, page F-114. From here you can define a network/host object.


Note See Supported IP Address Formats for a complete list of supported formats.



Tip You can leave this field blank when creating a global object that will be overridden on all devices that use the object. See Using Unspecified Network/Host Objects.


Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.


Note You must select this option when creating a network/host object with an unspecified value.


Step 8 Click OK to save the object.


Using Unspecified Network/Host Objects

When you define network/host objects, you can leave the Networks/Hosts field blank, thereby creating a network/host object with an unspecified value. Use this feature to create global network/host objects that are overridden on every device that uses them.

The advantage of using a network/host object with an unspecified value is that Security Manager displays an error if you submit your changes without creating a device-level override on every device using the object; by contrast, when you define the global object with a placeholder value (such as, 10.10.10.10), that global value could be deployed by mistake if you fail to define an override.

The following procedure describes how to create and implement network/host objects with unspecified values.

Procedure


Step 1 Create a network/host object, making sure to:

Leave the Networks/Hosts field blank.

Select the Allow Value Override per Device check box.

For more information, see Creating Network/Host Objects.

Step 2 Create overrides for each device that will use the object:

a. In the Overridable column for the object on the Networks/Hosts page, double-click the green checkmark. The Policy Object Overrides window is displayed. See Policy Object Overrides Window, page F-181.

b. Select the devices on which you want to create overrides, then define a value in the Networks/Hosts field. At this point, this override value applies to all the selected devices. For more information, see Creating Object Overrides for Multiple Devices.

c. Double-click each device in the Policy Object Overrides dialog box, then modify the Networks/Hosts field for the value required by that device.

Step 3 Define the policy that requires the network/host object. You can use one of two methods:

Define the policy on a single device in Device view, share the policy, then assign the policy to the other devices. See Sharing a Local Policy, page 7-26 and Modifying Shared Policy Assignments in Device View, page 7-34.

Create a shared policy in Policy view, then assign the policy to the other devices using the Assignments tab. See Modifying Policy Assignments in Policy View, page 7-39.


Note You can create a network/host object that refers to a network/host object with an unspecified value. You do not have to create the device-level overrides before you assign the policy containing the object to devices.


Related Topics

Creating Network/Host Objects

Overriding Global Objects for Individual Devices

Supported IP Address Formats

Contiguous and Discontiguous Network Masks

Specifying IP Addresses During Policy Definition

Understanding Network/Host Objects


Specifying IP Addresses During Policy Definition

Security Manager provides you with several options for specifying an IP address when defining a policy:

Entering the IP address manually.

Entering an IP address range manually. You can add a network mask in CIDR or dotted decimal format, if required (for example, when defining tunnel groups or dynamic NAT policies).


Note Adding network masks to an IP address range is not supported when defining a network/host object. See Supported IP Address Formats.


Entering the name of a network/host object that represents one or more IP addresses. See Understanding Network/Host Objects.

Selecting a network/host object from a list. For more information, see Selecting Objects for Policies.

When you create a network/host object or define IP addresses as part of a policy, Security Manager verifies that the syntax of the address is correct and that a mask was entered where required. For example, when you define a policy that requires a host, you do not need to enter a mask. However, when you define a policy that requires a subnet, you must enter the address with the mask or select a network/host object that has a mask defined.

Notes

For more information about the types of addresses you can enter, see Supported IP Address Formats.

If the policy requires a specific type of IP address, such as a subnet, other types of IP addresses are not accepted.

When the policy allows multiple addresses, you must separate each entry with a comma.

IP addresses that you enter directly when defining a policy (for example, in the Source and Destination fields of an access rule) are not optimized. For more information, see Network/Host Object Optimization.

Related Topics

Creating Network/Host Objects

Contiguous and Discontiguous Network Masks

Using Unspecified Network/Host Objects

Policy Object Manager Window, page F-1

Understanding Network/Host Objects

Understanding PKI Enrollment Objects

PKI (public key infrastructure) enrollment objects define the Certification Authority (CA) servers that operate within a public key infrastructure. CA servers, also known as trustpoints, manage public PKI certificate requests and issue certificates to participating IPsec network devices. CA servers provide centralized key management for the participating devices, eliminating the need for you to configure keys on each device. Instead, you enroll each participating device with a CA server, which is explicitly trusted to validate identities and create a digital certificate for that device. When peers must negotiate a secured communication session, they validate the identity of the other peer and establish an encrypted session with the public keys contained in the certificates.

CAs can also revoke certificates for devices that will no longer participate in IPsec. Revoked certificates are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation list (CRL) stored on an LDAP server, which each peer can check before accepting a certificate from another peer.

PKI can be set up in a hierarchical framework consisting of multiple CAs. At the top of the hierarchy is a root CA, which holds a self-signed certificate. The trust within the entire hierarchy is derived from the RSA key pair of the root CA. Subordinate CAs within the hierarchy can enroll with either the root CA or another subordinate CA. Within a hierarchical PKI, all enrolled peers can validate each other's certificates if the peers share a trusted root CA certificate or a common subordinate CA.

A PKI enrollment object identifies the name and URL of a particular CA server, specifies the revocation-checking method that server uses, and defines the parameters that devices require to enroll with that server. In addition, a PKI enrollment object can define additional information for inclusion in certificate requests. When using a hierarchical PKI framework, the PKI enrollment object specifies the trusted servers located above this server in the established hierarchy.

PKI enrollment objects are used in PKI policies. For more information, see Understanding Public Key Infrastructure Policies, page 10-60.

To create a PKI enrollment object, see Creating PKI Enrollment Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating PKI Enrollment Objects

You can create PKI enrollment objects to define the properties of a CA server used when devices exchange certificates as part of an IPsec network. When you create a PKI enrollment object, you define a name for the server and the URL for enrollment. You must specify whether the devices you wish to enroll with this server should retrieve the CA server's own certificate using the Simple Certificate Enrollment Process (SCEP) or use a certificate that you have entered manually into the device configuration. You must also select the method of support used by the CA server for revocation checking.

In addition, you can optionally define the following:

Whether the CA server is acting as a Registration Authority (RA) server.

Enrollment parameters, including retry settings and RSA key pair settings.

Additional attributes to include in the certificate request.

The list of trusted CA servers located above this server in the PKI hierarchy.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override PKI enrollment object definitions at the device level, which enables you to associate a specific CA server with a particular device. For more information, see Managing Object Overrides.

This procedure describes how to create a PKI enrollment object.


Tip You can also create PKI enrollment objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding PKI Enrollment Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select PKI Enrollments from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The PKI Enrollment dialog box appears. For a description of the fields in this dialog box, see Table F-84 on page F-116.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Define the properties of the PKI enrollment object, as described in the following topics:

Defining CA Server Properties

Defining PKI Enrollment Parameters

Defining Additional PKI Attributes

Defining the Trusted CA Hierarchy

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Defining CA Server Properties

Use the CA Information tab of the PKI Enrollment dialog box to define the basic properties of the PKI enrollment object, including the name and URL of the CA server, the source for obtaining the CA server's certificate, and the type of revocation checking support.

This procedure describes how to define the properties of the CA server in a PKI enrollment object.

Naming the CA Server

When you enter a name for the CA server, bear in mind the following:

You cannot configure two CA servers with the same name but different URLs on the same device.

The CA name cannot match the name of a trusted CA configured as part of the same PKI enrollment object. For more information about trusted CAs, see Defining the Trusted CA Hierarchy.

When the device is configured as part of a VPN, do not configure a device-level override that uses the same CA name as that of the CA server used by any of the peers. (This is not a problem when the device and its peers use a tiered PKI hierarchy.)

In all of these cases, deployment will succeed, but one CA definition will overwrite the other.

Related Topics

Defining PKI Enrollment Parameters

Defining Additional PKI Attributes

Defining the Trusted CA Hierarchy

Creating PKI Enrollment Objects

Understanding PKI Enrollment Objects

Procedure


Step 1 In the PKI Enrollment dialog box, click the CA Information tab. SeeTable F-85 on page F-117 Table F-247 on page F-437 for a description of the fields on this tab.

Step 2 (Optional) Enter the name used to identify the CA server in the certification request.


Note If you leave this field blank, the domain name is used. You must leave this field blank for Verisign CAs, because they require the domain name.


Step 3 Enter the URL of the CA server. The following formats are supported:

http://CA_name:port, where CA_name is the host DNS name or IP address of the CA. The port number is mandatory.


Note If the CA cgi-bin script location at the CA is not the default (/cgi-bin/pkiclient.exe), you must also include the nonstandard script location in the URL, in the form of http://CA_name:port/script_location, where script_location is the full path to the CA scripts.


tftp://certserver/file_specification, when you enroll with the CA server by means of a TFTP server. This option can be used if you do not have direct access to the CA server.

Any of the following formats: bootflash, cns, flash, ftp, null, nvram, rcp, scp, system.

Step 4 Select one of the following options for obtaining the CA server's certificate:

Select Retrieve CA Certificate Using SCEP to have the router retrieve the certificate from the CA server. When using SCEP, you must enter the fingerprint for the CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the certificate is rejected.


Tip You can obtain the CA's fingerprint by contacting the server directly, or by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll


Select Enter Manually and then copy up to three certificates from another device and paste them into the text field (using your browser's Paste function or the Ctrl-V keyboard shortcut). Each certificate must begin with the word "certificate" and end with the word "quit". Use this option when you want the PKI enrollment object to represent predefined certificates.

Step 5 Select the level of revocation checking support provided by the PKI enrollment object. For more information, see Table F-85 on page F-117.

Step 6 (If you selected OCSP checking in Step 5) Enter the URL for the OCSP server that is providing real-time certificate status checking. This URL must start with http://.

Step 7 (If you selected CRL checking in Step 5) Enter the URL for the LDAP server containing the CRL to be downloaded and checked by the CA server. This URL must start with ldap://.


Note You must include a port number in the URL when using this AAA server on ASA devices, otherwise LDAP will fail.


Step 8 (Optional) Select the Enable Registration Authority Mode check box if the CA server represented by the enrollment object is operating in Registration Authority (RA) mode. In RA mode the server acts as a proxy for the actual CA, which means that CA operations can continue even when the CA itself is offline.


Note This option does not apply to PIX/ASA 7.0+ devices. In addition, you do not need to configure this option if the PKI enrollment object is being used by Cisco IOS routers. Cisco IOS routers configure RA mode automatically, if required.



Defining PKI Enrollment Parameters

Use the Enrollment Parameters tab of the PKI Enrollment dialog box to define the retry settings to use when the device contacts the CA server as well as the settings for generating the RSA key pair to associate with the certificate.

If the PKI enrollment object represents a Microsoft CA, you can define the challenge password required to validate the router's identity.

This procedure describes how to define enrollment parameters for a PKI enrollment object.

Related Topics

Defining CA Server Properties

Defining Additional PKI Attributes

Defining the Trusted CA Hierarchy

Creating PKI Enrollment Objects

Understanding PKI Enrollment Objects

Procedure


Step 1 In the PKI Enrollment dialog box, click the Enrollment Parameters tab. See Table F-86 on page F-119 for a description of the fields on this tab.

Step 2 (Mandatory for PIX 6.3 devices; optional for PIX/ASA 7.0 devices and Cisco IOS routers) Enter the password used by the CA server to validate the device's identity.


Tip You can obtain the password by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll. The password is good for 60 minutes from the time you obtain it from the CA server. Therefore, it is important that you deploy the password as soon as possible after you create it.



Note Each password is valid for a single enrollment by a single device. Therefore, we do not recommend that you assign a PKI enrollment object where this field is defined to a VPN, unless you first configure a device-level override for each device in the VPN. For more information, see Overriding Global Objects for Individual Devices.


Step 3 (Optional) Modify the default retry values, as follows:

a. In the Retry Period field, specify the interval between certificate request attempts, in minutes.

b. In the Retry Count field, specify the number of times the device should resend the certificate request, if no response is received from the CA server to the first request.

Step 4 (Optional) To have the router request new certificates automatically (known as autoenrollment), enter the percentage of the current certificate's lifetime that triggers the request. For example, if you enter 70, the router requests a new certificate after 70% of the lifetime of the current certificate has been reached.

Step 5 (Optional) Select the Include Device's Serial Number check box if you want to include the serial number of the device in the certificate request.


Note The CA uses the serial number to either authenticate certificates or to later associate a certificate with a particular router. If you are in doubt, include the serial number, as it is useful for debugging purposes.


Step 6 (Optional) Define the RSA key pair to associate with the certificate:

a. In the RSA Key Pair Name field, enter the name of the key pair. If you are associating an existing key pair, enter its name. If you are generating a new key pair, it will be given the name you enter here.


Note If you do not specify an RSA key pair, the fully qualified domain name (FQDN) key pair is used instead. On PIX and ASA devices, the key pair must exist on the device before it is deployed.


b. (Cisco IOS routers only) In the Key Size field, enter the size of the key pair (modulus) in bits. Valid values range from 512 to 1024 (in multiples of 64), 1536 and 2048.


Note Keys with larger modulus values are more secure, but take longer to generate and process. For example, keys larger than 512 bits may take a minute or longer to generate.


c. (Cisco IOS routers only) In the Encryption Key Size field, define the size of the second key, which is used to request separate encryption, signature keys, and certificates.

Step 7 (Optional—for Cisco IOS routers only) In the Source Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all outgoing connections to the CA or LDAP server, or click Select to display a selector (see Selecting Objects for Policies).

This option is useful when the CA or LDAP server cannot reach the address from which the connection originated (for example, due to a firewall). If you do not enter a value in this field, the address of the outgoing interface is used.


Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to use in the object.



Defining Additional PKI Attributes

Use the Certificate Subject Name tab of the PKI Enrollment dialog box to optionally define additional attributes to include in the certificate request. This information is placed in the certificate and can be viewed by any party who receives the certificate from the router.

This procedure describes how to define additional attributes for a PKI enrollment object.


Note You must enter all information in the LDAP X.500 format.


Related Topics

Defining CA Server Properties

Defining PKI Enrollment Parameters

Defining the Trusted CA Hierarchy

Creating PKI Enrollment Objects

Understanding PKI Enrollment Objects

Procedure


Step 1 In the PKI Enrollment dialog box, click the Certificate Subject Name tab. See Table F-87 on page F-121 for a description of the fields on this tab.

Step 2 (Optional) Select the Include Device's FQDN check box to include the router's fully qualified domain name in the certificate.

Step 3 (Optional) Select the device interface whose IP address should be included in the certificate. Enter the name of an interface or interface role, or click Select to display a selector (see Selecting Objects for Policies).


Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to include in the object.


Step 4 (Optional) Specify one or more X.500 attributes.


Note If you are using digital certificates for user authentication on a Cisco EzVPN IPsec remote-access system, each EzVPN Remote component must be configured with the name of the client group to which it connects. Enter this information in the Organization Unit (OU) field. Although this information is not required for the EzVPN Server, including it does not create configuration problems. For more information about EzVPN, see Understanding Easy VPN, page 10-75.



Defining the Trusted CA Hierarchy

Use the Trusted CA Hierarchy tab of the PKI Enrollment dialog box to optionally define the CA servers that reside at a higher level in a PKI hierarchy. Within a hierarchical PKI, all enrolled peers can validate each other's certificate if the peers share a trusted root CA certificate or a common subordinate CA.

This procedure describes how to define a trusted CA hierarchy for a PKI enrollment object.

Related Topics

Defining CA Server Properties

Defining PKI Enrollment Parameters

Defining Additional PKI Attributes

Creating PKI Enrollment Objects

Understanding PKI Enrollment Objects

Procedure


Step 1 In the PKI Enrollment dialog box, click the Trusted CA Hierarchy tab. See Table F-88 on page F-123 for a description of the fields on this tab.

Step 2 Define the trusted servers by selecting one or more PKI enrollment objects from the Available CA Servers list, then clicking >> to add them to the Selected CA Servers list.


Understanding Port Forwarding List Objects

Application port forwarding is configured for thin client access mode in SSL VPN. Port forwarding allows users to access applications (such as telnet, email, VNC, SSH, and Terminal services) inside the enterprise via an SSL VPN session. When port forwarding is enabled, the hosts file on the SSL VPN client is modified to map the application to the port number configured in the forwarding list. A Port Forwarding List object defines the mappings of port numbers on the remote client to the application's IP address and port behind the SSL VPN gateway.

To create Port Forwarding List objects, see Creating Port Forwarding List Objects.

Related Topics

ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

Thin Client Access Mode

Creating Objects

Policy Object Manager Window, page F-1

Creating Port Forwarding List Objects

You can create port forwarding list objects to use when you are configuring the Thin Client access mode for SSL VPN. A port forwarding list object defines the mappings of port numbers on the remote client to the application's IP address and port behind the SSL VPN gateway.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override Port Forwarding List object definitions at the device level. For more information, see Managing Object Overrides.


Tip You can also create port forwarding list objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


This procedure describes how to create port forwarding list objects.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Port Forwarding List Objects

ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Port Forwarding List.

The Port Forwarding List page opens, displaying the defined port forwarding list objects.

Step 3 Right-click in the work area, then select New Object.

The Port Forwarding List dialog box opens, displaying a table of any port forwarding entries that are defined for the object. For a description of the elements in this dialog box, see Table F-89 on page F-123.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 To create a new port forwarding entry or modify the properties of an existing one, click Create below the Port Forwarding List table, or select an entry in the table and click Edit. The Add/Edit Port Forwarding Entry dialog box opens. For a description of the elements on this dialog box, see Table F-90 on page F-125.

a. Specify the port number to which the local application is mapped.

b. Specify the IP address or fully qualified domain name of the remote server.

c. Specify the port number of the application for which port forwarding is configured.

d. Enter any additional information about the port forwarding entry (mandatory on IOS routers).

e. Click OK to save the changes, and close the Add/Edit Port Forwarding Entry dialog box. The entry appears in the table in the Port Forwarding List dialog box.

Step 6 In the Include Port Forwarding Lists field, specify the names of other Port Forwarding List objects that you want to include in this Port Forwarding List object. You can click Select to open the Port Forwarding List selector from which you can make your selection.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Understanding Port List Objects

Port list objects contain one or more ranges of port numbers. These objects are used to streamline the process of creating service objects (see Creating Service Objects).

Security Manager contains a predefined port list object that includes either all ports (1-65535) or all secure ports (1024-65535), depending on the setting you select in the Security Manager Administration window (Tools > Security Manager Administration. For more information, see Policy Objects Page, page A-34.

To create a port list object, see Creating Port List Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

How Port List Objects are Provisioned as PIX/ASA Object Groups

Creating Port List Objects

You can create port list objects for use in defining service objects. Each port list object can contain one or more port ranges (for example, 1-1000 and 2000-2500). Additionally, a port list object can include other port list objects.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override port list object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to define port list objects.


Tip You can also create port list objects when defining service objects. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Port List Objects

How Port List Objects are Provisioned as PIX/ASA Object Groups

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Services > Port Lists from the Object Type selector.

Step 3 Right-click inside the work area, then select New Object.

The Add Port List dialog box appears. For a description of the fields in this dialog box, see Table F-91 on page F-125.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Define the contents of the port list object by doing one or both of the following:

In the Ports field, enter one or more ports and port ranges. Use hyphens to separate the first and last port number in the range, for example, 100-999. Separate multiple entries with commas. You can also use the following operators:

gt—greater than

lt—less than

eq—equals

neq—does not equal


Note You cannot combine a port range containing the neq operator with additional ranges.


Enter the names of existing port list objects, or click Select to display a selector (see Selecting Objects for Policies).

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Understanding Cisco Secure Desktop Configuration Objects

Cisco Secure Desktop Configuration objects are reusable, named components that can be referenced by SSL VPN policies for Cisco IOS routers. For ASA devices running 8.x, the feature is set up as part of the Dynamic Access Policy. For more information, see Understanding Dynamic Access Policies, page 11-17.

Cisco Secure Desktop (CSD) provides a reliable means of eliminating all traces of sensitive data by providing a single, secure location for session activity and removal on the client system. CSD provides a session-based interface where sensitive data is shared only for the duration of a SSL VPN session. All session information is encrypted, and all traces of the session data are removed from the remote client when the session is terminated, even if the connection terminates abruptly.

To create a Secure Desktop Configuration object, see Creating Cisco Secure Desktop Configuration Objects.

About Windows Locations

Windows locations let you determine how clients connect to your virtual private network, and protect it accordingly. For example, clients connecting from within a workplace LAN on a 10.x.x.x network behind a NAT device are an unlikely risk for exposing confidential information. For these clients, you might set up a CSD Windows Location named Work that is specified by IP addresses on the 10.x.x.x network, and disable both the Cache Cleaner and the Secure Desktop function for this location.

In contrast, users' home PCs might be considered more at risk to viruses due to their mixed use. For these clients, you might set up a location named Home that is specified by a corporate-supplied certificate that employees install on their home PCs. This location would require the presence of antivirus software and specific, supported operating systems to grant full access to the network.

Alternatively, for untrusted locations such as Internet cafes, you might set up a location named "Insecure" that has no matching criteria (thus making it the default for clients that do not match other locations). This location would require full Secure Desktop functions, and include a short timeout period to prevent access by unauthorized users.


Caution If you create a location and do not specify criteria, make sure it is the last entry in the "Locations in priority order" list described in the next section.

Related Topics

Creating Objects

Policy Object Manager Window, page F-1

Add or Edit Secure Desktop Configuration Dialog Box, page F-44

Creating Cisco Secure Desktop Configuration Objects

Cisco Secure Desktop Configuration objects are referenced by SSL VPN policies. Creating a Secure Desktop Configuration object involves first creating a location (such as Work, Home, or Insecure) that you can assign to Microsoft Windows clients as they connect to the corporate network. Then you can configure a group of settings for the location, enable or restrict web browsing and file access for Windows CE clients, and configure the Cache Cleaner and a VPN Feature Policy for Macintosh and Linux clients.

This procedure describes how to create Secure Desktop Configuration objects.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Cisco Secure Desktop Configuration Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Cisco Secure Desktop Configuration from the Object Type selector. The Secure Desktop Configuration page opens, displaying the defined Secure Desktop Configuration objects.

Step 3 Right-click in the work area, then select New Object.

The Secure Desktop Configuration dialog box appears, displaying a list of settings in the Secure Desktop Manager pane that you can configure for the Secure Desktop Configuration object. For a description of the elements in this dialog box, see Add or Edit Secure Desktop Configuration Dialog Box, page F-44.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 From the Secure Desktop Manager pane, select Windows Location Settings to create a location (such as Work, Home, or Insecure), and define the location-based settings (also called adaptive policies) for CSD.

a. For each location you want to configure, enter its name in the field provided, and click Add to move it to the Locations field. You can reorder the locations using the Move Up and Move Down buttons.

b. If you want all the open browser windows to close after the Secure Desktop installation, make sure to select the corresponding check box.

c. Select the required check boxes to configure a VPN Feature policy that enables web browsing, file access, port forwarding, and full tunneling, if installation or location matching fails.

Step 6 Select Windows CE to configure a VPN feature policy for the location, to enable or restrict both web browsing and remote server file access for remote clients running Microsoft Windows CE.

Step 7 Select Mac and Linux Cache Cleaner to configure the Cache Cleaner and a VPN Feature Policy for the location, that enables or restricts web browsing, remote server file access, and port forwarding for Macintosh and Linux clients.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.


Understanding Service Objects

Service objects are defined mappings of protocol and port definitions that describe services used by policies, such as Kerberos, SSH, and POP3. You can reference service objects directly within your policies.

Prior to Security Manager 3.2.1, Services Objects and Service Group Objects were defined under two different policy object types. With the release of version 3.2.1, these two policy object types have been combined into a single policy object called Services.

The Services policy object now accepts nameless services. A nameless service is one that identifies protocols and ports, but has no formal object name.

For example:

Defining a service as tcp/10 means that 10 is the destination port and no source port is defined.

Defining a service as tcp/10/20 means that 10 is the source port and 20 is the destination port.

If you do not want to specify a destination port, use the Default Range portlist name, for example, "tcp/10/Default Range". Other protocols possible are udp, tcp&udp, and icmp.

Service objects are convenient because they reflect the nature of most applications (such as a web browser) that require several network services to function. You can create service objects to represent the composition of a particular application, or you can model them after the logical organizations that exist on your network, such as a development team or corporate department.

Security Manager includes a comprehensive collection of predefined service objects, including ICMP messages, as well as objects for commonly used services such as HTTP, Syslog, POP3, Telnet, and SNMP.


Note Before using a predefined service object, you should review the object definition to verify that it conforms to your network implementation. If the predefined object does not meet your needs (for example, if you require different destination ports), you can create a new service object from scratch or based on a copy of an existing object. For more information, see Duplicating Objects.


When protocol type is specified, object-group service subcommands behave as in ASA 7.2. When protocol type is not specified, you can configure an object group as an object that uses the subcommand group-object or configure a service object that uses the subcommand service-object.

With the release of ASA 8.0, a service object can be created without specifying a tcp, udp, or tcp-udp protocol. Service objects can contain other service objects; they can contain protocols and ports; or they can contain a mix of protocols and ports, as well as other service objects. For example:

object-group service MySvcOG

service-object tcp

service-object icmp

service-object udp range 20 40

service-object tcp-udp neq 18

The nested service objects (group-object subcommand) must have the same protocol as the parent service object-group. For example, if you try to add a TCP service object to MySvcOG, an error will result. For example:

object-group service MyTCPSvcOG tcp

port-object eq 12

object-group service MySvcOG

group-object MyTCPSvcOG

An error results: "Adding obj to object-group (MySvcOG) failed; obj and group type inconsistent."

To create a service object, see Creating Service Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

How Service Objects are Provisioned as PIX/ASA Object Groups

Creating Service Objects

You can create service objects to describe a type of traffic carried by the devices in your network. When creating a service object, you must select the protocol used by the service. If this protocol is either TCP or UDP, you must also select the source and destination ports. When creating an Internet Control Message Protocol (ICMP) service object, you must define the message type.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override service object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create service objects.


Tip You can also create service objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Duplicating Objects

Editing Objects

Understanding Service Objects

How Service Objects are Provisioned as PIX/ASA Object Groups

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Services > Services from the Object Type selector. The Services page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Service dialog box appears. For a description of the fields in this dialog box, see Table F-92 on page F-127.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Enter the service by doing any of the following:

Type in the service type and identify source and destination ports, for example, tcp/10/20. (This is commonly referred to as a nameless service.)

Enter a protocol and portlist name, for example, tcp/portlistX or icmp/echo.

Type in the name of another service such as HTTP, or another user-defined service.

Click Select, which opens the Services Selector dialog box from which to make your selections. The dialog box includes both predefined and user-defined services.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Understanding Single Sign-On Server Objects

Single Sign-On (SSO) lets SSL VPN users enter a username and password once and be able to access multiple protected services and web servers.

The SSO mechanism starts as part of the AAA process or just after successful user authentication to an AAA server. The SSL VPN server running on the security appliance acts as a proxy for the user to the authenticating server. When a user logs in, the SSL VPN 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 SSL VPN 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.

Security Manager supports authentication for SSL VPN users using Computer Associates' SiteMinder SSO server or with Version 1.1 of Security Assertion Markup Language (SAML) Browser Post Profile. In addition to configuring the security appliance, for SiteMinder SSO, you also must configure your CA SiteMinder Policy Server with the Cisco authentication scheme. See Understanding Single Sign-On Server Objects. For SAML Browser Post Profile you must configure a Web Agent (Protected Resource URL) for authentication. For the specifics of setting up a SAML Browser Post Profile SSO server, see Understanding Single Sign-On Server Objects.

SSO Authentication with SiteMinder

SSO authentication using SiteMinder is separate from AAA authentication, and begins after the AAA process is completed. If you want to configure SSO for a SSL VPN user or group, you must first configure a AAA server, such as a RADIUS or LDAP server. You can then setup SSO support for SSL VPN.

To configure SSO with SiteMinder, you need to:

1. Specify the SSO server.

2. Specify the URL of the SSO server to which the security appliance makes SSO authentication requests.

3. Specify 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.

4. Optionally, you can also configure the authentication request timeout, and the number of authentication request retries.

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


Note 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. For the complete procedure to configure a custom authentication scheme on your SiteMinder Policy Server, please refer to the CA SiteMinder documentation.


SSO with SAML Post Profile

After a session is initiated, the security appliance authenticates the user against a configured AAA method. Next, the security appliance (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.


Note The SAML Browser Artifact profile method of exchanging assertions is not supported.


This section presents an overview of the tasks necessary to configure SSO with SAML Browser Post Profile. These tasks are:

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 security appliance 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) After completing the configuration tasks, you assign an SSO server to a user or group policy.

For the procedure to create a Single Sign-On Server object, see Creating Single Sign-On Server Objects.

Related Topics

Creating Objects

Policy Object Manager Window, page F-1

Add or Edit Single Sign On Server Dialog Boxes, page F-127

Creating Single Sign-On Server Objects

You can create Single Sign On (SSO) Server objects to enable you to configure or delete SSO for SSL VPN users using Computer Associates' SiteMinder SSO server and Version 1.1 of Security Assertion Markup Language (SAML). SSO support, available only for SSL VPN, lets users access different secure services on different servers after entering a username and password just once.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override Single Sign On Server object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create an SSO Server object.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Single Sign-On Server Objects

Add or Edit Single Sign On Server Dialog Boxes, page F-127

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Single Sign On Servers from the Object Type selector. The Single Sign On Servers page opens, displaying the defined SSO Server objects.

Step 3 Right-click in the work area, then select New Object.

The SSO Server dialog box appears. For a description of the elements in this dialog box, see Table F-93 on page F-128.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 From the Authentication Type list, select the type of SSO server as follows:

SiteMinder—Enables the security appliance to use SiteMinder for SSO authentication.

SAML POST—Enables the security appliance to use the SAML Browser Post Profile type for SSO authentication

Step 6 In the URL field, select a protocol (http or https) from the list, and specify the the SSO server URL to which the security appliance makes SSO authentication requests in the field provided.

Step 7 Enter and confirm the secret key used to encrypt authentication communications with the SSO Server in the fields provided.

Step 8 Enter the number of times the security appliance retries a failed SSO authentication attempt before the authentication times out.

Step 9 Enter the number of seconds before a failed SSO authentication attempt times out. The range is from 1 to 30 seconds, and the default is 5 seconds.

Step 10 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 11 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 12 Click OK to save the object.


Understanding SLA Monitor Objects

Service level agreement (SLA) monitor objects are used by PIX/ASA security appliances running version 7.2 or later to perform route tracking. This feature provides a method to track the availability of a primary route and install a backup route if the primary route fails. For example, you can define a default route to an Internet service provider (ISP) gateway and a backup default route to a secondary ISP in case the primary ISP becomes unavailable. This feature, called Dual ISP, provides security appliances with a form of high availability, which is a vital part of providing customers with the services to which they are entitled.

Without route tracking, there is no inherent mechanism for determining if the route is up or down. A static route remains in the routing table even if the next hop gateway becomes unavailable, and is removed only if the associated interface on the security appliance goes down.

The security appliance performs route tracking by associating a route with a monitoring target that you define in the SLA monitor object. It monitors the target using ICMP echo requests, according to the parameters configured in the object. If an echo reply is not received within a specified time period, the object is considered down and the associated route is removed from the routing table. A previously configured backup route is used in place of the removed route.

To create an SLA monitor object, see Creating SLA Monitor Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Configuring Firewall Device Interfaces, page 15-2

Configuring Static Routes, page 15-78

Creating SLA Monitor Objects

When you define an SLA monitor object, you must define:

The address to be monitored for reachability.

The interface on the security appliance that sends out the ICMP echo requests.

An ID number for the SLA operation.

You can optionally modify the default values that define the ICMP echo requests, such as the frequency of the request transmissions and the timeout that triggers the removal of the nonresponsive static route from the routing table and its replacement by the backup route.


Note SLA monitoring jobs start immediately after deployment and continue to run until you unassign the policy from the device (that is, they do not age out).


Selecting a Monitoring Target

When you select a monitoring target, make sure that it can respond to ICMP echo requests. The target can be any network address that you choose, but consider the use of:

The ISP gateway address.

The next hop gateway address (if you are concerned about the availability of the ISP gateway).

A server on the target network, such as an AAA server, with which the security appliance needs to communicate.

A persistent network object on the destination network. (A desktop or notebook computer that you can shut down at night is not a good choice.)

This procedure describes how to create SLA monitor objects.


Tip You can also create SLA monitor objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding SLA Monitor Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select SLA Monitors from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The SLA Monitor dialog box appears. For a description of the fields in this dialog box, see Table F-94 on page F-129.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Enter the ID number that identifies the SLA operation.

Step 6 Enter the IP address to be monitored.

Step 7 In the Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all ICMP echo requests sent to the monitored address, or click Select to display a selector (see Selecting Objects for Policies).


Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to use in the object.


Step 8 (Optional) Modify the default values that determine how the monitored address is checked for reachability. See Table F-94 on page F-129.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.


Understanding SSL VPN Bookmark Objects

An SSL VPN Bookmark object defines a list of URLs that are displayed on a browser-based clientless SSL VPN Portal page. Use the SSL VPN Bookmarks page to view, create, edit, or delete SSL VPN Bookmarks objects.

You can create SSL VPN Bookmark objects for SSL VPNs hosted on IOS devices or ASA devices. However, these device types allow different bookmark configurations, the ASA device allowing more configuration options than IOS devices. Besides allowing more configuration options, you can also create bookmarks for ASA devices in non-English, non-ASCII languages. For more information on localizing the bookmarks and portal for ASA devices, see Localizing SSL VPN Web Pages for ASA Devices.

To create SSL VPN Bookmark objects, see Creating SSL VPN Bookmark Objects.

Using the Post URL Method and Macro Substitutions

One of the options you have for configuring bookmarks on an SSL VPN hosted on an ASA device is the method used by a URL, either Get or Post. The Get method is the standard method; a user clicks the URL and is taken to the web page. The Post method is useful when processing the data might involve changes to it, for example, storing or updating data, ordering a product, or sending e-mail.

If you choose the Post URL method, you must configure Post parameters for bookmark entries. Because these are often personalized resources that contain the user ID and password or other input parameters, you might need to define clientless SSL VPN macro substitutions.

Clientless SSL VPN macro substitutions let you configure users for access to personalized resources that contain the user ID and password or other input parameters. Examples of such resources include bookmark entries, URL lists, and file shares.


Note For security reasons, password substitutions are disabled for file access URLs (cifs://). Also for security reasons, use caution when introducing password substitutions for web links, especially for non-SSL instances.


You can use the following macro substitutions:

Logon Information Substitutions— The security appliance obtains values for these substitutions from the SSL VPN Logon page. It recognizes these strings in user requests, and replaces them with the value specific to the user before it passes the request on to a remote server.

These are the available macro substitutions:

CSCO_WEBVPN_USERNAME

The username used to log into the SSL VPN.

CSCO_WEBVPN_PASSWORD

The password used to log into the SSL VPN.

CSCO_WEBVPN_INTERNAL_PASSWORD

The internal resource password entered when logging into the SSL VPN.

CSCO_WEBVPN_CONNECTION_PROFILE

The connection profile associated with the user group selected when logging into the SSL VPN.

For example, if a URL list contains the link http://someserver/homepage/CSCO_WEBVPN_USERNAME.html, the security appliance translates it to the following unique links:

For USER1 the link becomes http://someserver/homepage/USER1.html

For USER2 the link is http://someserver/homepage/USER2.html

In the following example, cifs://server/users/CSCO_WEBVPN_USERNAME lets the security appliance map a file drive to specific users:

For USER1 the link becomes cifs://server/users/USER1

For USER2 the link is cifs://server/users/USER2

RADIUS/LDAP Vendor-Specific Attributes (VSAs)—These substitutions let you set substitutions configured on either a RADIUS or an LDAP server. These are the available macro substitutions:

CSCO_WEBVPN_MACRO1

CSCO_WEBVPN_MACRO2

Related Topics

ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

Creating Objects

Policy Object Manager Window, page F-1

Creating SSL VPN Bookmark Objects

You can create SSL VPN Bookmark objects to use when you are configuring a browser-based clientless SSL VPN. SSL VPN Bookmark objects define lists of web sites that can be displayed on an SSL VPN Portal page, providing easy access to important resources to users.

You can use non-English, non-ASCII languages for the text to display for bookmarks if you are configuring the object for use on an ASA device. For more information about how you can configure the SSL VPN portal in local languages, see Localizing SSL VPN Web Pages for ASA Devices.


Tip You can also create SSL VPN Bookmark objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Related Topics

Guidelines for Managing Objects

Understanding SSL VPN Bookmark Objects

ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select SSL VPN Bookmarks from the Object Type selector. The SSL VPN Bookmarks page opens, displaying a list of the existing SSL VPN Bookmark objects.

Step 3 Right-click in the work area, then select New Object.

The Add SSL VPN Bookmark dialog box appears (see Add or Edit Bookmarks Dialog Boxes, page F-130).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 If you are creating the object for an SSL VPN hosted on an IOS device, you can enter a name for the heading that is displayed above the bookmarks list in the Bookmarks Heading (IOS) field.

Step 6 The Bookmarks table displays any URLs that are defined for the object. To add a bookmark, click the Add Row button below the table; to edit an existing bookmark, select it and click the Edit Row button.

The Add/Edit SSL VPN Bookmark Entry dialog box opens. For more information about the fields on this dialog box, see Add and Edit Bookmark Entry Dialog Boxes, page F-132.

In the Bookmark Option field, select whether you are defining a bookmark (Enter Bookmark) or adding bookmarks from another SSL VPN Bookmark object (Include Existing Bookmarks). If you are including an existing object, enter the object's name or click Select to select it from a list of existing objects.

If you are creating the object for use on an IOS device, enter the title of the bookmark, which is displayed to users, and the URL. Be careful to select the correct protocol for the URL. Click OK to add the bookmark to the table of bookmarks.

If you are creating the object for use on an ASA device, you have many more options. Besides the title and the URL, you can define a subtitle and image icon for the bookmark plus other options.


Tip If you choose the protocols RDP, SSH, Telnet, VNC, or ICA, you must configure the plug-in for the protocol in the Remote Access VPN > SSL VPN > Other Settings policy (see SSL VPN Other Settings Page, page H-105).


You can also configure the bookmark to use the Post method rather than the Get method. If you use Post, you must configure the post parameters by clicking Add Row beneath the Post Parameters table. For more information on Post parameters, see these topics:

Understanding SSL VPN Bookmark Objects

Add and Edit Post Parameter Dialog Boxes, page F-133

Click OK to add the bookmark to the table of bookmarks.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.


Understanding SSL VPN Customization Objects

You use SSL VPN Customization policy objects when configuring browser-based clientless SSL VPNs for ASA devices. These objects define the look of the web pages the user sees when logging into or out of the VPN and the home page for the portal.

This section contains the following topics:

Understanding SSL VPN Customization Objects

Localizing SSL VPN Web Pages for ASA Devices

Creating Your Own SSL VPN Logon Page

Creating SSL VPN Customization Objects

Understanding SSL VPN Customization Objects

An SSL VPN Customization object describes the appearance of browser-based clientless SSL VPN web pages displayed to users. This includes the Logon page displayed when they connect to the ASA security appliance, the Home page displayed after authentication, and the Logout page displayed when users log out of the SSL VPN service.

You use SSL VPN Customization objects when defining ASA group objects or Remote Access VPN Connection policies for ASA devices. You can create several customization objects and define multiple ASA group or connection profiles so that each user group sees web pages designed specifically for their use. Customization can include localizing the web pages in the languages appropriate for each group. For more information about localization, see Localizing SSL VPN Web Pages for ASA Devices.

Initially, when a user first connects, the default customization object (named DfltCustomization) identified in the connection profile determines how the logon screen appears. If the user selects a different group from the connection profile list on the logon page, and that group has its own customization, the screen changes to reflect the customization object for the selected group. After the remote user is authenticated, the screen appearance is determined by the customization object that has been assigned to the group policy.

To create customization objects, see Creating SSL VPN Customization Objects.

Related Topics

Localizing SSL VPN Web Pages for ASA Devices

Creating Your Own SSL VPN Logon Page

Creating Objects

Add and Edit SSL VPN Customization Dialog Boxes, page F-134

Localizing SSL VPN Web Pages for ASA Devices

Localization is the process of providing text in a language that is appropriate for the target users. When you create an SSL VPN Customization object for defining the look of browser-based clientless SSL VPN web pages hosted on an ASA device, you can configure the pages to use the desired language.

To see localized web pages correctly, users must configure their browsers to use UTF-8 encoding (for example, in Internet Explorer, select View > Encoding > Unicode (UTF-8). They also must install the required fonts or language support files for their language using the Regional and Language Options control panel. On the Languages tab, click Details to install the desired languages, and select the appropriate supplemental language settings for East Asian, complex scripting, and right-left languages. On the Advanced tab, select the desired code page conversion tables. If users do not configure the browser correctly, they might see boxes instead of characters.

There are two techniques you can use to localize SSL VPN web pages that are hosted on an ASA device. These techniques are not mutually exclusive; you can use both of them. These are the techniques:

Configure the SSL VPN Customization object using the desired language—When you create the SSL VPN Customization object, you can enter text for labels and messages in non-English, non-ASCII languages in UTF-8 encoding. To enter non-ASCII languages in UTF-8 encoding, you must configure Windows with the correct locale setting and have the required fonts installed. Use the Regional and Language Options control panel to configure your system and install files required for complex script or East Asian languages. If you want to type in text directly, you also need to install an appropriate keyboard; otherwise, you can use a text editor that supports the language's characters and copy and paste text from a document that contains the text you want to use.

You can also enter non-ASCII languages into SSL VPN Bookmarks objects.

Configure translation tables on the ASA device to support the languages you want to make available—To enable the security appliance to provide language translation for the portal and screens displayed to users, you must define the necessary languages in a translation table and import the table into the security appliance. The software image package for the security appliance includes a translation table template. Every language you list in an SSL VPN Customization object must have a corresponding translation table on the device. Conversely, translation tables for languages that are not listed in the SSL VPN Customization object are ignored.

If you use this technique, you must use the ASA CLI or ASDM to configure and upload the translation tables. You cannot manage the translation tables with Security Manager. However, the SSL VPN Customization object includes settings that allow you to configure automatic browser language selection and to enable users to select their desired language. Thus, if you install translation tables for ten languages, the pages defined in the SSL VPN Customization object will be available to users in all of those languages. For more information on these settings, see SSL VPN Customization Dialog Box—Language, page F-138.

Although both of the following features require translation tables, they are separate and complementary:

Automatic Browser Language Selection—Automatic browser language selection attempts to select the appropriate language based on the user's browser settings. This technique does not ask for user input. In the SSL VPN Customization object, you create a list of languages that will be used in the negotiation with the browser. During a connection, the security appliance receives a list of languages (and their priorities) from the browser, and looks through your list of languages top to bottom until a match is found. If there is no match, then the language you defined in the list as the default language is used. If you do not specify a default language, English is used.

The languages on the security appliance are labels for the translation tables. The languages must mirror those of the browser, and can consist of groups of up to 8 alphanumeric characters (starting from alpha characters), separated by hyphens. For example, fr-FR-paris-univ8. However, when you add a language to the list in Security Manager, only the first two characters are available.

When looking for a match, the security appliance starts with the longest language name, and if it does not match, it discards the rightmost group of the name. For example, if the preferred language on the browser is fr-FR-paris-univ8, and the security appliance supports fr-FR-paris-univ8, fr-FR-paris, fr-FR, and fr, it matches fr-FR-paris-univ8 and uses the translated strings from that translation table. If fr is the only language on the security appliance, the security appliance considers it a match also, and uses that translation table.

For more information about setting up translation tables, see the user documentation for the ASA device and operating system or the ASDM online help.

Language Selector—By enabling the language selector, you provide the user with the ability to actively select the desired language from a list of languages that you support. This technique does not rely on the browser language settings being configured correctly. The language selector is displayed on the logon page.

Related Topics

Creating SSL VPN Customization Objects

Creating Objects

Understanding SSL VPN Customization Objects

Add and Edit SSL VPN Customization Dialog Boxes, page F-134

Creating Your Own SSL VPN Logon Page

You can create your own custom SSL VPN Logon page rather than use the page provided by the security appliance for browser-based clientless SSL VPNs. This is called full customization, and replaces the settings you can configure in the SSL VPN Customization policy object.

To provide your own Logon page, you must create the page, copy it to the Security Manager server, and identify the page on the Full Customization page of the SSL VPN Customization object dialog box. For information on creating SSL VPN Customization objects, see Creating SSL VPN Customization Objects.

When you enable full customization, all other settings for the Logon page configured in the policy object are ignored. When you deploy your configuration to the ASA device, Security Manager copies your custom page to the device.

The Logon page you create must include all of the HTML code required to present the page correctly, and include special Cisco HTML code that provides the functions for the login form and the Language Selector drop-down list. Keep the following in mind when you create the HTML file:

The file extension must be .inc.

All images in the custom Logon page must be present on the security appliance. Replace the file path with the keyword /+CSCOU+/, which is an internal directory on the ASA device. When you upload an image to the device, it is saved in this directory.

Use the csco_ShowLoginForm('lform') Javascript function to add the login form to the page. This form prompts for the username, passwords, and group information. You must include this function somewhere on the page.

Use the csco_ShowLanguageSelector('selector') Javascript function to add the Language Selector drop-down list to the page. You do not have to use this function if you are not supporting the use of more than one language.

Related Topics

Understanding SSL VPN Customization Objects

Creating SSL VPN Customization Objects

Add and Edit SSL VPN Customization Dialog Boxes, page F-134

SSL VPN Customization Dialog Box—Full Customization, page F-142

Creating SSL VPN Customization Objects

An SSL VPN Customization object lets you customize pages that are displayed to browser-based clientless SSL VPN users when they connect to the security appliance, including the Logon page, Portal (Home) page, and the Logout page.

You can use non-English, non-ASCII languages for the text to display on these pages. For more information about how you can configure the SSL VPN portal in local languages, see Localizing SSL VPN Web Pages for ASA Devices.


Tip You can also create SSL VPN Customization objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Related Topics

Guidelines for Managing Objects

Understanding SSL VPN Customization Objects

Localizing SSL VPN Web Pages for ASA Devices

Managing Existing Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select SSL VPN Customization from the Object Type selector. The SSL VPN Customization page opens, displaying a list of the existing SSL VPN Customization objects.

Step 3 Right-click in the work area and select New Object.

The Add SSL VPN Customization dialog box appears (see Add and Edit SSL VPN Customization Dialog Boxes, page F-134).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Before you configure settings for the various pages, use the Preview button to view the default settings. Clicking Preview opens a browser window to display the current settings for the Logon page, Portal page, or Logout page, whichever one is selected in the table of contents (selecting a page within one of these folders is the same as selecting the parent folder).


Tip Click Preview after making any changes to settings to verify that the changes are what you desire.


Step 6 Configure the settings for the Logon page. This web page is the one users see first when connecting to the SSL VPN portal. It is used for logging into the VPN. Select the following items in the Logon Page folder in the table of contents on the left of the dialog box to view and change the settings:

Logon Page—Specify the title of the web page, which is displayed in the browser's title bar.

Title Panel—Determine whether the Logon page will have a title displayed in the web page itself. If you enable the title panel, you can specify the title, font, font size and weight, styles, and colors used. You can also select a File object that identifies a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Title Panel, page F-137.

Language—If you want to configure translation tables for other languages on the ASA device and use them, you can configure the supported languages and allow users to choose their language. For information about translation tables and localization support, see Localizing SSL VPN Web Pages for ASA Devices. For more information about the settings, see SSL VPN Customization Dialog Box—Language, page F-138.

Logon Form—Configure the labels and colors used in the form that accepts user logon information. For more information about the settings, see SSL VPN Customization Dialog Box—Logon Form, page F-140.

Informational Panel—If you want to provide extra information to the user, you can enable an informational panel and add text and a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Informational Panel, page F-140.

Copyright Panel—If you want to include copyright information on the logon page, you can enable the copyright panel and enter your copyright statement. For more information about the settings, see SSL VPN Customization Dialog Box—Copyright Panel, page F-141.

Full Customization—If you do not want to use the security appliance's built-in logon page, even customized, you can instead enable full customization and supply your own web page. For information on creating the required file, see Creating Your Own SSL VPN Logon Page. For more information about the settings, see SSL VPN Customization Dialog Box—Full Customization, page F-142.

Step 7 Configure the settings for the Portal page. This is the home page for the SSL VPN portal, and is displayed after the users log in. Select the following items in the Portal Page folder in the table of contents on the left of the dialog box to view and change the settings:

Portal Page—Specify the title of the web page, which is displayed in the browser's title bar.

Title Panel—Determine whether the Portal page will have a title displayed in the web page itself. If you enable the title panel, you can specify the title, font, font size and weight, styles, and colors used. You can also select a File object that identifies a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Title Panel, page F-137.

Toolbar—Determine whether the Portal page will have a toolbar, which contains a field for entering a URL to browse. For more information about the settings, see SSL VPN Customization Dialog Box—Toolbar, page F-142.

Applications—Determine which application buttons will appear on the page. For more information about the settings, see SSL VPN Customization Dialog Box—Applications, page F-143.

Custom Panes—Determine how you want to organize the body of the Portal page. The default is a single column with no internal panes. You can create a multiple-column layout, create internal panes that display text or references to URLs, and determine in which column and row to place the panes. For more information about the settings, see SSL VPN Customization Dialog Box—Custom Panes, page F-144.

Home Page—Determine how and whether to display URL lists on the home page, and whether to use your own web page for the main body of the Portal page. For more information about the settings, see SSL VPN Customization Dialog Box—Home Page, page F-146.

Step 8 Select Logout Page to configure the settings of the page displayed when a user logs out of the SSL VPN. You can configure the title, message text, fonts, and colors. For more information about the settings, see SSL VPN Customization Dialog Box—Logout Page, page F-147.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 11 Click OK to save the object.


Understanding SSL VPN Gateway Objects

An SSL VPN gateway acts as a proxy for connections to protected resources, which are accessed through an SSL-encrypted connection between the gateway and a web-enabled browser on a remote device.

An SSL VPN gateway object includes parameters that enable the gateway to be used as a proxy for connections to the protected resources in your SSL VPN. These parameters include the gateway's IP address, the port that will carry HTTPS traffic, and the digital certificate required to establish a secure connection.

To create SSL VPN gateway objects, see Creating SSL VPN Gateway Objects.

Related Topics

Gateway and Context Page (IOS), page H-13

Creating Objects

Policy Object Manager Window, page F-1

Creating SSL VPN Gateway Objects

You can create an SSL VPN Gateway object to use when you are configuring an SSL VPN connection on your VPN gateway (server) device. For more information, see Gateway and Context Page (IOS), page H-13.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override SSL VPN Gateway object definitions at the device level. For more information, see Managing Object Overrides.


Tip You can also create SSL VPN Gateway objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


This procedure describes how to create an SSL VPN Gateway object.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding SSL VPN Gateway Objects

Add or Edit SSL VPN Gateway Dialog Box, page F-148

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select SSL VPN Gateways.

The SSL VPN Gateways page opens, displaying any currently defined SSL VPN Gateway objects.

Step 3 Right-click inside the work area, then select New Object.

The Add SSL VPN Gateway dialog box appears. For a description of the elements in this dialog box, see Table F-112 on page F-148.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Specify the IP address used to configure the gateway object. Choose either the public static IP address of the router interface or the router's public static IP address.

Step 6 Specify the port that will carry the HTTPS traffic.

Step 7 Specify the trustpoint (digital certificate) required to establish the secure connection.


Note A self-signed certificate is generated when an SSL VPN gateway is activated.


Step 8 Select Enable Gateway to activate the SSL VPN gateway.

Step 9 Select Specify SSL Encryption Algorithms to specify the encryption algorithm(s) that the SSL protocol uses for the SSL VPN connections. Then select up to three algorithms, in order of preference, from the lists provided.

Step 10 Select Redirect HTTP Traffic to configure the gateway to redirect HTTP traffic over secure HTTP (HTTPS), then specify the port number over which the HTTP traffic will be redirected in the field provided.

Step 11 (Optional) Select hostname. For a description of the elements in this dialog box, see Table F-112 on page F-148.

Step 12 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 13 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 14 Click OK to save the object.


Understanding SSL VPN Smart Tunnel List Objects

A smart tunnel is a connection between a Winsock 2, TCP-based application and a private site. The connection uses a clientless (browser-based) SSL VPN session with the security appliance as the pathway, and the security appliance as a proxy server. Local applications can be granted smart tunnel access. Lotus SameTime, Microsoft Outlook, and Microsoft Outlook Express are a few examples of applications on your local machine to which a user might want to grant smart tunnel access. Smart tunnel access does not require user connection of the local application to the local port. Therefore, smart tunnels do not require users to have administrator privileges.

Providing smart tunnel access is useful in the following cases:

A plug-in is unavailable for the Winsock 2, TCP-based application for which you want to enable access.

Cisco currently redistributes the following plug-ins for use with Clientless SSL VPN: SSH (for both SSH and Telnet sessions), RDP, and VNC.

You have chosen not to configure application access for a particular application.

Application access requires that you know the ports the application uses. Remote users who do not have admin rights must connect the application to the local port on the local machine. Unlike full-tunnel clients, smart tunnel access does not require administrator privileges.

Smart tunnels have the following requirements:

The remote host originating the smart tunnel connection must be running a 32-bit version of Microsoft Windows 2000 or Microsoft Windows XP.

The browser must be enabled with Java, Microsoft ActiveX, or both.

Smart tunnels also have the following restrictions:

Only Winsock 2, TCP-based applications are eligible. Moreover, Smart tunnels do not support MAPI, also called Microsoft Outlook Exchange proxy. For MAPI proxy access, remote users must use AnyConnect.

If the remote computer requires a proxy server to reach the security appliance, the URL of the terminating end of the connection must be in the list of URLs excluded from proxy services. In this configuration, smart tunnels support only basic authentication.

A group policy or username supports no more than one list of applications eligible for smart tunnel access.

A stateful failover does not retain smart tunnel connections. Users must reconnect following a failover.

In this release, An SSL VPN Smart Tunnel is modeled as a separate policy object and referenced within an ASA Group Policy object (Tools > Policy Object Manager > ASA Group Policies). The smart tunnel reference in a group policy means the associated smart tunnel list is enabled for that group policy. Only one smart tunnel list can be referenced for one group policy. If smart-tunnel auto-start is also enabled, you can start smart tunnel access automatically upon user login. Otherwise, smart tunnel access is started manually, using the Application Access > Start Smart Tunnels button on the clientless SSL VPN portal page.

You can add an application to which you want to grant smart tunnel access, and specify the local path to each application and the SHA-1 hash of its checksum to check before granting it access.

To create an SSL VPN smart tunnel list object, see Creating SSL VPN Smart Tunnel List Objects.

Related Topics

Creating SSL VPN Smart Tunnel List Objects

Creating Objects

Policy Object Manager Window, page F-1

Creating SSL VPN Smart Tunnel List Objects

You can create an SSL VPN Smart Tunnel List object to use as a connection between a Winsock 2, TCP-based application and a private site.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override SSL VPN Smart Tunnel List object definitions at the device level. For more information, see Managing Object Overrides.


Tip You can also create SSL VPN Smart Tunnel List objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.


This procedure describes how to create an SSL VPN Smart Tunnel List object.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding SSL VPN Smart Tunnel List Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select SSL VPN Smart Tunnel Lists.

The SSL VPN Smart Tunnel Lists page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add SSL VPN Smart Tunnel List dialog box appears. For a description of the elements in this dialog box, see Table F-113 on page F-150.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the Smart Tunnel Entries table, then select Add Row. The Add a Smart Tunnel Entry dialog box appears. For a description of the elements in this dialog box, see Table F-114 on page F-151

Step 6 Enter the App Name, which specifies a string that names the application to be granted smart tunnel access. If the application associated with multiple files, you may enter multiple file entries with the same App Name.

Step 7 Enter the App Path, which allows you to specify the filename and extension of the application, or a path to the application, including its filename and extension.

SSL VPN 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 and extension, SSL VPN does not enforce a location restriction on the remote host to qualify the application for smart tunnel access.

Step 8 Specify the hash value of the application for which smart tunnel access is enabled.

Step 9 Click OK. The dialog box closes and you return to the Add Smart Tunnel List dialog box.

Step 10 (Optional) Click Select to select from a list of existing Smart Tunnel Lists. This will create a smart tunnel list embedded within the current smart tunnel list.

Step 11 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 12 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 13 Click OK to save the object.


Understanding Style Objects

Style objects are reusable, named components that can be referenced by other objects and policies. A style object lets you configure style elements, including color swatches and preview capabilities, to customize the appearance of the SSL VPN page that appears to SSL VPN users when they connect to the security appliance. Style objects enable you to configure font characteristics and colors without requiring any Cascading Style Sheet (CSS) parameters to define the style.

To create a style object, see Creating Style Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating Style Objects

You can create style objects to populate the SSL VPN Customization objects that are referenced by SSL VPN policies. When you create a style object, you can configure style elements, including font family, style, weight, and size, color swatches, and preview capabilities.

This procedure describes how to create a style object.


Tip You can also create style objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Style Objects

Style Objects Dialog Box, page F-153

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Style Objects from the Object Type selector.

The Style Objects page opens, displaying the currently defined style objects.

Step 3 Right-click in the work area, then select New Object.

The Style Objects dialog box appears. For a description of the fields in this dialog box, see Table F-115 on page F-154.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Specify a font family, style, weight, and size.

Step 6 Click Select next to the Foreground and Background fields to open the Select Color dialog box from which you can select a foreground and background color for the font. For more information, see Select Color Dialog Box, page B-11.

A preview of the font style is displayed.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 Click OK to save the object.


Creating Text Objects

You can create a text object if you need textual data to be referenced and acted upon by another policy object that accepts text objects.

Text objects are a type of policy object variable. They are a name and value pair, where the value can be a single string, a list of strings, or a table of strings. Their flexibility allows you to enter any type of textual data to be referenced and acted upon by FlexConfigs.


Tip You can also create text objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Related Topics

Guidelines for Managing Objects

Chapter 19, "Managing FlexConfigs"

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Text Objects from the Object Type selector.

Step 3 Right-click inside the work area and click New Object.

The Add Text Object dialog box appears (see Add or Edit Text Object Dialog Box, page F-154).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Enter the object data. You can create a simple single-value variable, a list of variables (by selecting Dimension 1) or a table or variables (by selecting Dimension 2). After you create the desired grid by selecting the dimension and if applicable, the number of rows and columns, enter the data into each cell by first clicking in the cell.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Understanding Time Range Objects

Time range objects are used when creating time-based ACLs and inspection rules. While similar to extended ACLs in function, time-based ACLs allow for access control based on time considerations. Each time range, which defines specific times of the day and/or week, is referenced in the ACL or inspection rule by a function. This enables you to place time restrictions on that function. For more information, see Adding Access Rules, page 12-40 and Adding Inspection Rules, page 12-49.

Time range objects can also be used when defining ASA user groups to restrict VPN access to specific times during the week. For more information, see Creating ASA User Group Objects.

Time range objects can rely on the device's system clock, but using Network Time Protocol (NTP) synchronization is recommended.

To create a time range object, see Creating Time Range Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating Time Range Objects

You can create time range objects for use when creating time-based ACLs and inspection rules. When you create a time range object, you can optionally define specific periods within the defined start and end time.

This procedure describes how to create a time range object.


Tip You can also create time range objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding Time Range Objects

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Time Ranges from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The Time Range dialog box appears. For a description of the fields in this dialog box, see Table F-117 on page F-155.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Define a start time for the time range object. You can either have the time range take effect immediately upon deployment or define a specific date and time as the start time.

Step 6 Define an end time for the time range object. You can either define a specific date and time or specify that the time range continues indefinitely.

Step 7 (Optional) Define one or more recurring ranges for the time range object. These ranges, which are recurring time intervals that fall within the start and end times defined for the object, are defined as follows:

a. In the Recurring Ranges field, click the Add button. The Recurring Ranges dialog box is displayed. See Table F-118 on page F-156 for a description of the fields in this dialog box.

b. Select one of the following options:

Specify days of the week and time during which this recurring range will be active

Specify a weekly interval during which this recurring range will be active

c. If you are basing the recurring range on days of the week, select which days to include. Additionally, you can select a start time and end time, if required. (By default, the start time and end time are both midnight.)

d. If you are basing the recurring range on a weekly interval, select the start day/time and the end day/time.

e. Click OK. The Recurring Range dialog box closes and your definitions appear in the Recurring Ranges field of the Time Range dialog box.

f. Repeat a. through e. to add additional recurring ranges to the time range object, if required.


Note To edit a recurring range, select it in the Recurring Ranges field, then click the Edit button. To remove a recurring range, select it, then click the Delete button.


Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.


Creating Traffic Flow Objects

Traffic Flow objects are used to support PIX Firewall 7.0 and ASA 7.0 platforms. This object supports the class-map command.

Related Topics

Guidelines for Managing Objects

Understanding IP Precedence Bits

Default Inspection Traffic, page F-159

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Traffic Flow.

The Traffic Flow page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Traffic Flow dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the traffic match type from the list, then enter the appropriate values. The dialog box values vary based on your selection. For detailed information on the fields, see Add and Edit Traffic Flow Dialog Boxes, page F-157.

The traffic match options are:

Any traffic.

Source and destination IP address (uses access lists). Select the desired ACL object.

Default inspection traffic.

Default inspection traffic with access list. Select the desired ACL object.

TCP or UDP destination port. Enter the desired port or port range (0-65535).

RTP range. Enter the desired port range within 2000-65535.

Tunnel group. Enter the name of the tunnel group and decide whether to base it on the destination address.

IP precedence bits. Select up to 4 values.

IP DiffServe Code Points (DSCP) values. Select up to 8 values.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 Click OK to save the object.


Understanding IP Precedence Bits

IP precedence bits are standard Type of Service (ToS) bits in an IP packet. They are used for QoS packet classification. Using packet classification, you can partition network traffic into multiple priority levels or classes of service.

By setting precedence levels on incoming traffic and using them in combination with the Cisco IOS QoS queueing features, you can create differentiated service. You can use features such as policy-based routing (PBR) and committed access rate (CAR) to set precedence based on extended access list classification. These features afford considerable flexibility for precedence assignment. For example, you can assign precedence based on application or user, or by destination and source subnetwork.

For historical reasons, each precedence corresponds to a name. These names, which continue to evolve, are defined in the RFC 791 document. Table 9-10 lists the numbers and their corresponding names, from least to most important.

You can partition traffic into up to six classes (the remaining two are reserved for internal network use) and then use policy maps and extended ACLs to define network policies in terms of congestion handling and bandwidth allocation for each class.

Table 9-10 IP Precedence Pre-Defined Objects 

Number
Name

0

Routine

1

Priority

2

Immediate

3

Flash

4

Flash-override

5

Critical

6

Internet

7

Network


Related Topics

Creating Traffic Flow Objects

Understanding User Group Objects

User group objects are used in Easy VPN topologies, remote access VPNs, and SSL VPNs.

When you configure a remote access VPN, SSL VPN, or Easy VPN server, you can create user groups to which remote clients belong. The remote clients must be configured with the same group name as the user group on the VPN server, in order to connect to the server; otherwise, no connection is established. When the remote client connects to the VPN server successfully, the group policies for that particular user group are pushed to all remote clients belonging to the user group.

For more information about user groups, see:

Understanding User Group Policies (IOS), page 11-44

Understanding Group Policies (ASA), page 11-30

Configuring User Group Policies, page 11-44

Configuring a User Group Policy for Easy VPN, page 10-80

Configuring an SSL VPN Policy (IOS), page 11-45

To create user group objects, see Creating User Group Objects.

Related Topics

Creating Objects

Policy Object Manager Window, page F-1

User Group Dialog Box, page F-160

Creating User Group Objects

Use the User Groups Objects page to create user group objects for use in your remote access VPN, SSL VPN, or configured on your Easy VPN server.


Note You must select the technology (Easy VPN/Remote Access VPN, or SSL VPN) for which you are creating the user group object. If you are editing an existing user group object, the technology is already selected, and you cannot change it. Depending on the selected technology, the appropriate settings are available for configuration.



Tip You can also create User Group objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


This procedure describes how to create User Group objects.

Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding User Group Objects

User Group Dialog Box, page F-160

User Group Dialog Box—General Settings, page F-162

User Group Dialog Box—DNS/WINS Settings, page F-163

User Group Dialog Box—Split Tunneling, page F-164

User Group Dialog Box—IOS Client Settings, page F-165

User Group Dialog Box—IOS Xauth Options, page F-166

User Group Dialog Box—IOS Client VPN Software Update, page F-168

User Group Dialog Box—Advanced PIX Options, page F-169

User Group Dialog Box—Clientless Settings, page F-170

User Group Dialog Box—Thin Client Settings, page F-172

User Group Dialog Box—SSL VPN Full Tunnel Settings, page F-172

User Group Dialog Box—SSL VPN Split Tunneling, page F-174

User Group Dialog Box—Browser Proxy Settings, page F-175

User Group Dialog Box—SSL VPN Connection Settings, page F-176

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select User Groups.

The User Groups page opens, displaying the currently defined user group objects.

Step 3 From the work area, right-click inside the table, then select New Object.

The User Group dialog box opens, displaying a list of settings that you can configure for the user group. For a description of the elements on this dialog box, see Table F-121 on page F-160.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Specify a name for the user group. You should configure the same user group name within the remote client or device to ensure that the appropriate group attributes are downloaded.

Step 6 If you opened the User Group dialog box from the Policy Object Manager window, select the type of technology for which you are creating the user group object— Easy VPN/Remote Access VPN or SSL VPN.


Note If you opened the dialog box from the Site-to-site VPN Manager, or the Remote Access VPN or SSL VPN folder in the Device View, the technology is already selected, and you cannot edit it.


Depending on the selected technology, the appropriate settings are displayed in the Settings pane for configuration, as described in the following steps.

Step 7 To configure the user group for an Easy VPN or remote access VPN, from the Settings pane:

a. Select General to configure general settings for your user group policy, including the authentication method, IP address pool information, and connection attributes for PIX Firewalls. For a description of the elements required to configure these settings, see Table F-122 on page F-162.

b. Select DNS/WINS to define the DNS and WINS servers and the domain name that should be pushed to clients associated with the user group. For a description of the elements required to configure these settings, see Table F-123 on page F-163.

c. Select Split Tunneling to configuring split tunneling for your user group. For a description of the elements required to configure split tunneling, see Table F-124 on page F-164.

d. Select Client Settings (IOS) to define Cisco IOS specific options for your user group, including firewall settings for VPN clients. For a description of the elements required to configure these settings, see Table F-125 on page F-165.

e. Select Xauth Options (IOS) to configure IKE Extended Authentication (Xauth) user authentication and connection parameters for the user group, including the banner text. For a description of the elements required to configure these settings, see Table F-126 on page F-167.

f. Select Client VPN Software Update (IOS) to configure, for an IOS VPN client, the platform type, VPN Client revisions, and image URL for each client VPN software package installed, for your user group. For a description of the elements required to configure these settings, see Table F-127 on page F-168.

g. Select Advanced Options (PIX) to configure options specifically for PIX Firewalls in your user group. For a description of the elements required to configure these options, see Table F-129 on page F-170.

Step 8 To configure the user group for an SSL VPN, from the Settings pane:

a. Select Clientless to configure the Clientless mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Clientless mode, see Table F-130 on page F-171.

b. Select Thin Client to configure the Thin Client settings that enable the Thin Client mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Thin Client mode, see Table F-131 on page F-172.

c. Select Settings from the Full Tunnel folder to configure Full Tunnel settings that enable the Full Tunnel mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Full Tunnel settings, see Table F-132 on page F-173.

d. Select DNS/WINS from the Full Tunnel folder to define the DNS and WINS servers for the user group in an SSL VPN. For a description of the elements required to configure these settings, see Table F-123 on page F-163.

e. Select Split Tunneling from the Full Tunnel folder to configure split tunneling for your user group in an SSL VPN. For a description of the elements required to configure split tunneling, see Table F-133 on page F-174.

f. Select Browser Proxy Settings from the Full Tunnel folder to configure the browser proxy settings for your user group in an SSL VPN. For a description of the elements required to these settings, see Table F-134 on page F-176.

g. Select Connection Settings to configure the SSL VPN connection settings for the user group. For a description of the elements required to configure the connection settings, see Table F-135 on page F-177.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.


Understanding WINS Server List Objects

SSL VPN uses WINS and the Common Internet File System (CIFS) protocol to access or share files on remote systems. When you attempt a file-sharing connection to a Windows computer by using its computer name, the file server you specify corresponds to a specific WINS name that identifies a resource on the network.

The security appliance queries WINS or NetBIOS name servers to map WINS names to IP addresses. SSL VPN requires NetBIOS to access or share files on remote systems.

The Common Internet File System (CIFS) protocol provides users with network access to files, printers, and other machine resources. SSL VPN serves remote users with HTTPS portal pages that interface with a proxy CIFS client running on the security appliance. Using this client, SSL VPN provides users with network access to the files on the network, provided that the users meet user authentication requirements and the file properties do not restrict access. The client is transparent—the portal pages delivered by SSL VPN provide the appearance of direct access to the file systems.

When a user requests a list of files, SSL VPN queries the server designated as the master browser for the IP address of the server containing the list. The security appliance gets the list and delivers it to the remote user on the SSL VPN portal page.

To create WINS Server List objects, see Creating WINS Server List Objects.

Related Topics

Policy Object Manager Window, page F-1

Creating Objects

Creating WINS Server List Objects

Creating WINS Server List Objects

The WINS Server List object lets you configure the Windows Internet Naming Server (WINS) or NetBIOS attributes for the tunnel group. To make the WINS function operational, you must configure at least one WINS server (host). For more information about WINS Servers, see Understanding WINS Server List Objects.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override WINS Server List object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create a WINS Server List object.


Tip You can also create WINS Server List objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.


Before You Begin

Read and understand Guidelines for Managing Objects.

Related Topics

Understanding WINS Server List Objects

Add or Edit WINS Server List Dialog Box, page F-177

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select WINS Server Lists from the Object Type selector.

The WINS Server List page opens, displaying the currently defined WINS server list objects.

Step 3 Right-click in the work area, then select New Object.

The WINS Server List dialog box appears. For a description of the fields in this dialog box, see Table F-136 on page F-177.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 From the WINS Server List table, you can create a new WINS server or modify the properties of an existing one, as follows:

a. Click Create below the table, or select a WINS server in the table and click Edit. The Add/Edit WINS Server dialog box opens. For a description of the elements on this dialog box, see Add or Edit WINS Server Dialog Box, page F-178.

b. In the Server field, enter the IP address for the WINS server to translate Windows file server names to IP addresses. You can click Select to open the Network/Hosts Selector from which you can make your selection.

c. Select the Set as Master Browser check box (by default it is deselected), to enable the WINS server to function as a CIFS server. The master browser maintains the list of computers and shared resources.

d. In the Timeout field, specify the initial time in seconds that the server waits for a response to a WINS query before sending the query to the next server.

e. In the Retries field, specify the number of times to retry sending a WINS query to the configured servers, in order.

f. Click OK to save the changes and close the dialog box. The new or modified WINS Server entry appears in the table in the WINS Server List dialog box.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.


Overriding Global Objects for Individual Devices

By default, objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, there are many object types whose definition can be overridden at the device level. To identify those object types, look for the Overridable column in the objects table.

You can define overridable object types globally, then use device-level overrides to specify the exact definition required on each device. One example might be a case where you want to deny ICMP traffic to the different departments in your company, each of which is connected to a different network. You can do this by defining a policy with an access rule that includes a global network/host object called Departmental Network. By allowing device override for this object, you can then create overrides on each relevant device that specify the actual network to which that device is connected.

Device-level object overrides are especially important when the global object is included in the definition of a VPN policy, which applies to every device in the VPN topology. For example, you select a PKI enrollment object when defining a PKI policy on a site-to-site VPN. If the hub of your VPN uses a different CA server than the spokes, you must use device-level overrides to specify the CA server used by the hub. Although the PKI policy references a single PKI enrollment object, the actual CA server represented by this object will differ for the hub, based on the device-level override you define.

Related Topics

Allowing a Global Object to Be Overridden

Creating Device-Level Object Overrides

Deleting Device-Level Object Overrides

Allowing a Global Object to Be Overridden

You can designate discovered objects as well as objects created in Security Manager as overridable.


Note To identify the object types that can be overridden, select the object type in the Policy Object Manager, then look for the Overridable column in the objects table.


Related Topics

Overriding Global Objects for Individual Devices

Creating Device-Level Object Overrides

Deleting Device-Level Object Overrides

Procedure


Step 1 To allow device-level overrides for policy objects that are discovered on devices:

a. Select Tools > Security Manager Administration > Discovery.

b. Select the Allow Device Override for Discovered Policy Objects check box.

c. Click Save.

Step 2 To allow device-level overrides when defining a global object in Security Manager, select the Allow Value Override per Device check box when defining the object.

When you finish creating the object, a green checkmark appears in the Overridable column in the Policy Object Manager window table entry for that object. This checkmark indicates that you can create device-level overrides for the object.


Creating Device-Level Object Overrides

After enabling the Allow Value Override per Device attribute in the relevant object dialog box (see Allowing a Global Object to Be Overridden), you can create device-level overrides in two places in Security Manager:

In the Device Property window of a selected device.

In the Policy Object Manager window.

Creating device-level overrides from the Policy Object Manager window makes is easier to define overrides on multiple devices at one time. The procedure for creating overrides is dependent on which method you use, as described in the following sections:

Creating Object Overrides for a Single Device

Creating Object Overrides for Multiple Devices

If you override any part of the object definition at the device level, any subsequent changes made to the policy definition at the global level do not affect the device on which the object was overridden.

Related Topics

Deleting Device-Level Object Overrides

Creating Object Overrides for a Single Device

You can create device-level object overrides from the Device Properties window. An override specifies a definition for a global object that affects only the selected device. For example, you can override the definition of a AAA server group object so that the object represents a different group of AAA servers for one device than the group it represents for other devices.

Before You Begin

Define the global object, making sure to select the option that allows device-level overrides. See Allowing a Global Object to Be Overridden.

Related Topics

Creating Object Overrides for Multiple Devices

Deleting Device-Level Object Overrides

Procedure


Step 1 Select View > Device View or click the Devices button on the toolbar.

Step 2 Right-click a device in the Device selector, then select Device Properties.

Step 3 Select Policy Object Overrides from the Device Properties selector, then select an overridable object type.

The work area of the Device Properties window displays all objects of the selected type that may be overridden at the device level.

Step 4 Click the Create Override button, or right-click an object in the table, then select Create Override. The dialog box for defining that object type is displayed. The fields in the dialog box contain the global definition for the selected object.

Step 5 Modify the definition of the object, as required.

Step 6 Click OK to save the device-level override. In the Device Properties window, the check box in the Value Overridden column of the table appears selected.


Creating Object Overrides for Multiple Devices

In addition to the Device Properties window of a particular device, you can create device-level object overrides from the Policy Object Manager window. This method enables you to create overrides on multiple devices at the same time, which is especially useful when creating overrides for several devices that participate in the same VPN topology. For example, if the spokes located in one part of the VPN use a different CA server than the spokes located in a different part of the VPN, you can override the PKI enrollment object that defines the server for these devices. This is a more convenient method than selecting each device individually from Device view and defining the override from the Device Properties window.

Before You Begin

Define the global object, making sure to select the option that allows device-level overrides. See Allowing a Global Object to Be Overridden.

Related Topics

Creating Object Overrides for a Single Device

Deleting Device-Level Object Overrides

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select an overridable object types from the Object Type selector.

Step 3 In the work area, select a user-defined object that can be overridden, as indicated by the green checkmark in the Value Override column.

Step 4 Double-click the checkmark, or right-click the object and select Edit Device Overrides. The Policy Object Overrides window is displayed.

Step 5 Click the Create button. The Create Overrides for Device dialog box is displayed. See Table F-141 on page F-183 for a description of the elements in this dialog box.

Step 6 Select one or more devices from the Available Devices list, click >> to add them to the Selected Devices list, then click OK.

Step 7 In the dialog box that appears, define the properties of the device-level override, then click OK.

The device-level overrides are created for each selected device and are displayed in the Policy Object Overrides window.

Step 8 Click the Close button to return to the Policy Object Manager window.


Deleting Device-Level Object Overrides

Deleting a device-level override restores the global definition of the object to the selected device. You can delete overrides from the Device Properties window or from the Policy Object Manager window, as described in the following sections:

Deleting Overrides from the Device Properties Window

Deleting Overrides from the Policy Object Manager window

Deleting Overrides from the Device Properties Window

This procedure describes how to delete overrides from the Device Properties window of a selected device.

Related Topics

Overriding Global Objects for Individual Devices

Allowing a Global Object to Be Overridden

Procedure


Step 1 Select View > Device View or click the Devices button on the toolbar.

Step 2 Right-click a device in the Device selector, then select Device Properties.

Step 3 Select Policy Objects from the Device Properties selector, then select one of the available object types.

Step 4 In the work area, right-click the override you want to delete, then select Delete Override. A confirmation message is displayed.

Step 5 Click Yes to delete the override and restore the global object definition.


Deleting Overrides from the Policy Object Manager window

This procedure describes how to delete device-level object overrides when working in the Policy Object Manager window. When you delete an override, the global definition of the object is restored to the selected device.

Related Topics

Overriding Global Objects for Individual Devices

Allowing a Global Object to Be Overridden

Procedure


Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select one of the overridable object types from the Object Type selector. See Creating Object Overrides for Multiple Devices.

Step 3 In the work area, select a user-defined object that can be overridden, as indicated by the green checkmark in the Value Override column.

Step 4 Double-click the checkmark, or right-click the object and select Edit Device Overrides. The Policy Object Overrides window is displayed.

Step 5 Select the override to delete and click the Delete button. A confirmation message is displayed.

Step 6 Click Yes to delete the override and restore the global object definition.


Selecting Objects for Policies

When creating a policy, you often need to select one or more objects to include in the policy definition. For example, firewall policies make use of network/host objects, interface role objects, and service objects.

To include objects in policies, you can manually enter the object name or click a button to display a popup object selector. Object selectors make it easy for you to select which objects to include in a particular policy.

Additionally, object selectors enable you to create and edit objects of that type on the fly. This makes it easy to work with objects without leaving the policy you are defining to launch the Policy Object Manager. For example, if when creating a dynamic NAT rule you discover that the ACL object you require does not exist, you can click a button to launch the dialog box for creating an ACL object. When you finish creating the object, you are returned to the object selector with the new object selected and ready for inclusion in the policy.

When you create an object by launching the object editor from within a selector, the new object must conform to the requirements of the field from which the selector was launched. For example, if you launch a selector from a field requiring a host and then decide to create a network/host object for that field, you must define the network/host object as a host.

Security Manager includes two types of objects selectors—a simple list selector for policies that require you to select a single object, and a dual selector for policies that allow you to select multiple objects of a certain type.

Object selectors for service objects include a third button for grouping. This enables you to create a service group object without first closing the policy dialog box.


Note When using an object selector to select interfaces, be aware that there may be interfaces and interface roles with the same name. They can be distinguished by the icon displayed next to the name. For more information, see Specifying Interfaces During Policy Definition.


Related Topics

Guidelines for Managing Objects

Procedure


Step 1 From the page or dialog box of the policy you are configuring, go to a field requiring an object, then click Select.

An object selector for the required object type is displayed. See Table F-138 on page F-179 for a description of object selectors.

In certain cases, the object selector is prefiltered to display only the objects that are applicable to the policy you are configuring. For example, when configuring a policy that requires a subnet, the object selector displays only those network/host objects that represent subnets, not network/host objects that represent single hosts.


Tip You can also create your own filters to apply to object selectors. For more information, see Filtering Items in Selectors, page 3-14.


Step 2 (When configuring sources and destinations) Select the type of object to display—network/host objects or interface roles. You can include both types in the same set of selections. When you click OK, your selections are displayed in separate tabs in the page or dialog box in which they are defined.


Note This option is available in the following policies—AAA Rules, Access Rules, Inspection Rules, and NAT (PIX/ASA devices only).


(When selecting ACL objects) Select the type of ACLs to display, standard or extended. You can include both types in the same set of selections. When you click OK, your selections are displayed in separate tabs in the page or dialog box in which they are defined.

Step 3 Select the objects to include in the policy definition by doing one of the following:

In single-object selectors—Click the object you want to select from the displayed list. The name of the object appears in the field at the bottom of the selector.

In multiple-object selectors—Click the objects you want to select from the Available list (standard multiple-selection shortcuts are supported), then click >> to move your selections to the Selected list on the right. You can return objects from the Selected list to the Available list by selecting them, then clicking <<.


Tip You can also move objects between lists by double-clicking them or by selecting them and pressing Enter.

To quickly find a particular object, start typing its name. The selector jumps to the nearest match.


Step 4 Use the Move Up and Move Down buttons to change the order of the selected objects. The order of the selected objects affects how they are used within a particular policy.


Note The up and down arrows appear only in those selectors where the order in which the objects appear affects the policy definition. For example, when defining a method list for AAA, use the arrows to determine the order in which different types of AAA server groups are used.


Step 5 (Optional) If the object you need does not appear in the Available list, do one of the following:

Right-click inside the list and select Create.

Click the Create button.

The dialog box for creating an object of that type is displayed. For example, if you click the Create button from an interface role selector, the Interface Role dialog box is displayed. When you finish creating the object, click OK to return to the object selector. The new object is displayed in the Selected list.


Note Object creation is limited to objects that can be successfully applied to the current policy. For example, if the policy requires a network/host object that represents a subnet, the new network/host object that you create from the selector must represent a subnet.


Step 6 (Optional) If you wish to modify the properties of a user-defined object, select it, then do one of the following:

Right-click the object, then select Edit.

Click the Edit button.

The dialog box for editing that object is displayed. Modify the properties of the object as required, then click OK to return to the object selector.


Note Predefined objects cannot be edited.


Step 7 Click OK to save your definitions. The objects you selected are added to the policy definition.


How Policy Objects are Provisioned as PIX/ASA Object Groups

Object groups are a feature of PIX and ASA devices that enable you reduce the size of access rules by grouping objects such as IP hosts, networks, protocols, ports, and ICMP message types. Although the functionality of object groups is similar to the functionality of policy objects in Security Manager, there are several important differences in implementation.

As a result, when deploying policies to a device, it is not always possible to create object groups that are an exact copy of the policy objects that you configured in Security Manager. To take one example, policy object names are unique per object type in Security Manager (that is, you can define a network/host object and a service object with the same name); PIX object groups of all types, however, share a single naming scheme. Therefore, if you deploy a network/host object whose name matches an existing service object group on the device, a suffix is added to the name of the network/host object to distinguish it from the service object group.


Note For more information about the options available when deploying object groups, see Deployment Page, page A-7.


Similarly, when discovering policies on a device, it is not always possible to create policy objects that are an exact copy of the object groups that are configured on the device. However, Security Manager preserves as much of the original configuration as possible.

The following sections describe the changes that are made when provisioning policy objects to PIX object groups:

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

How Port List Objects are Provisioned as PIX/ASA Object Groups

How Service Objects are Provisioned as PIX/ASA Object Groups


Note The information contained in these sections can also be used to understand how object groups are converted into policy objects when imported into Security Manager. For more information, see Discovering Policies, page 7-11.


Related Topics

Guidelines for Managing Objects

Chapter 9 "Managing Objects"

Working with Deployment and the Configuration Archive, page 18-16

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

In most cases, network/host objects can be provisioned as object groups without changing the object name. Table 9-11 describes how Security Manager changes the names of network/host objects whose names cannot be converted directly to object groups on PIX/ASA devices.


Note The predefined network/host object any cannot be provisioned as an object group.


Table 9-11 How Network/Host Objects are Named as Object Groups 

Condition
New Name
Examples

Object name includes a space.

Space is replaced with an underscore.

A network/host object named my network is changed to an object group named my_network when deployed.

Object name is longer than 64 characters (maximum supported by object groups).

Name is truncated so that any suffixes required by the object group (such as _TCP or _UDP, or unique numbers, such as _1) can be added while remaining within the 64-character limit.

 

Device already has an object group (Protocol/ICMP/Service) with the same name.

A numeric suffix is added to the name, starting from 1.

If you provision a network/host object named West and the device already has a TCP service object group named West, the name of the object group is changed to West_1 when deployed.


Related Topics

Understanding Network/Host Objects

How Policy Objects are Provisioned as PIX/ASA Object Groups

How Port List Objects are Provisioned as PIX/ASA Object Groups

In most cases, port list objects can be provisioned as object groups without changing the object name. Table 9-12 describes how Security Manager changes the names of port list objects whose names cannot be converted directly to object groups on PIX/ASA devices.

Table 9-12 How Port List Objects are Named as Object Group 

Condition
New Name
Examples

Object name includes a space.

Space is replaced with an underscore.

A port list object named my portlist is changed to an object group named my_portlist when deployed.

Object name is longer than 64 characters (maximum supported by object groups).

Name is truncated so that any suffixes required by the object group (such as _TCP or _UDP, or unique numbers, such as _1) can be added while remaining within the 64-character limit.

 

Device already has an object group (Protocol/ICMP/Service) with the same name.

A numeric suffix is added to the name, starting from 1.

If you provision a port list object named West and the device already has a TCP service object group named West, the name of the object group is changed to West_1 when deployed.

You have already created a network/host object group with the same name.

A numeric suffix is added to the name, starting from 1.

If you have a network/host object and a port list object that are both named West, the network/host object is deployed as West and the port list is deployed as West_1.


Related Topics

Understanding Port List Objects

How Policy Objects are Provisioned as PIX/ASA Object Groups

How Service Objects are Provisioned as PIX/ASA Object Groups

Table 9-13 describes how Security Manager changes the names of service objects whose names cannot be converted directly to object groups on PIX/ASA devices.

Table 9-13 How Service Objects are Named as Object Groups 

Condition
New Name
Examples

Object name includes a space.

Space is replaced with an underscore.

A service object named my service is changed to an object group named my_service when deployed.

Object name is longer than 64 characters (maximum supported by object groups).

Name is truncated so that any suffixes required by the object group (such as _TCP or _UDP, or unique numbers, such as _1) can be added while remaining within the 64-character limit.

 

Device already has an object group (Protocol/ICMP/Service) with the same name.

A numeric suffix is added to the name, starting from 1.

If you provision a service object named West and the device already has a TCP service object group named West, the name of the object group is changed to West_1 when deployed.

You have already created a network/host object group with the same name.

A numeric suffix is added to the name, starting from 1.

If you have a network/host object and a service object that are both named West, the network/host object is deployed as West and the service is deployed as West_1.


Table 9-14 describes how Security Manager creates object groups when deploying service objects to PIX/ASA devices.

Table 9-14 How Service Objects are Provisioned as Object Groups 

Condition
Generated Object Group
Examples

Service object contains ICMP protocol and ICMP message types.

Generates an ICMP-type object group with the same name as the service object.

Service object service1: icmp/icmp-echo, 23

Object group:

object-group icmp-type 
service1
    icmp-object icmp-echo
    icmp-object 23

Service object contains only protocols.

Generates a protocol object group with the same name as the service object.

Service object service1: tcp, gre, 34

Object group:

object-group protocol 
service1
    protocol-object tcp
    protocol-object gre
    protocol-object 34

Service object uses port list objects for both source and destination ports.

Generates service object groups that match the port list objects.

For more information, see Table 9-12.

Service object contains multiple ports or port ranges, but does not use port list object for the source ports.

Generates service object group with the name <ObjectName>.src for the source ports.

Service object serv1: tcp/400,600/23-80

Object group:

object-group service 
serv1.src tcp
    port-object eq 400
    port-object eq 600

Service object contains multiple ports or port ranges, but does not use port list object for the destination ports.

Generates service object group for the destination ports with the same name as the service object.

Service object serv1: tcp/400,600/23-80, 566

Object group:

object-group service serv1 
tcp
    port-object range 23 80
    port-object eq 566
object-group service 
serv1.src tcp
    port-object eq 400
    port-object eq 600

Service object contains the TCP&UDP protocol and includes defined ports.

 

Service object serv1: tcp&udp/400,600/23-80, 566

Object group:

object-group service serv1 
tcp
    port-object range 23 80
    port-object eq 566
object-group service 
serv1.src tcp
    port-object eq 400
    port-object eq 600
object-group protocol 
tcp-udp
    protocol-object tcp
    protocol-object udp

Related Topics

Understanding Service Objects

How Policy Objects are Provisioned as PIX/ASA Object Groups