User Guide for Cisco Security Manager 4.1
Managing Policy Objects
Downloads: This chapterpdf (PDF - 700.0KB) The complete bookPDF (PDF - 25.75MB) | Feedback

Managing Policy Objects

Table Of Contents

Managing Policy Objects

Selecting Objects for Policies

Policy Object Manager Window

Policy Object Manager Window Shortcut Menu

Working with Policy Objects—Basic Procedures

Creating Policy Objects

Editing Objects

Using Category Objects

Cloning (Duplicating) Objects

Viewing Object Details

Generating Object Usage Reports

Deleting Objects

Managing Object Overrides

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for a Single Device

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides

Importing and Exporting Policy Objects

Understanding AAA Server and Server Group Objects

Supported AAA Server Types

Additional AAA Support on ASA, PIX, and FWSM Devices

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Creating AAA Server Objects

Add or Edit AAA Server Dialog Box

AAA Server Dialog Box—RADIUS Settings

AAA Server Dialog Box—TACACS+ Settings

AAA Server Dialog Box—Kerberos Settings

AAA Server Dialog Box—LDAP Settings

AAA Server Dialog Box—NT Settings

AAA Server Dialog Box—SDI Settings

AAA Server Dialog Box—HTTP-FORM Settings

Add and Edit LDAP Attribute Map Dialog Boxes

Add and Edit LDAP Attribute Map Value Dialog Boxes

Add and Edit Map Value Dialog Boxes

Creating AAA Server Group Objects

AAA Server Group Dialog Box

Creating Access Control List Objects

Creating Extended Access Control List Objects

Creating Standard Access Control List Objects

Creating Web Access Control List Objects

Add or Edit Access List Dialog Boxes

Add and Edit Extended Access Control Entry Dialog Boxes

Add and Edit Standard Access Control Entry Dialog Boxes

Add and Edit Web Access Control Entry Dialog Boxes

Configuring Time Range Objects

Recurring Ranges Dialog Box

Understanding Interface Role Objects

Creating Interface Role Objects

Interface Role Dialog Box

Specifying Interfaces During Policy Definition

Using Interface Roles When a Single Interface Specification is Allowed

Handling Name Conflicts between Interfaces and Interface Roles

Understanding Map Objects

Understanding Network/Host Objects (IPv4 and IPv6)

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Creating IPv4 or IPv6 Network/Host Objects

Add or Edit Network/Host Dialog Box (IPv4 or IPv6)

Using Unspecified IPv4 or IPv6 Network/Host Objects

Specifying IP Addresses During Policy Definition

Specifying IPv6 Addresses During Policy Definition

Understanding and Specifying Services and Service and Port List Objects

Configuring Port List Objects

Configuring Service Objects

How Policy Objects are Provisioned as Object Groups

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups

How Service Objects are Provisioned as Object Groups


Managing Policy Objects


Policy 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 MyServers network/host object to send and receive traffic for the services defined in the service object. If a change is made to these servers, you need only update the network/host or service object and redeploy, instead of trying to locate and edit each rule in which the servers are used.

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 Understanding Policy Object Overrides for Individual Devices.

This chapter contains the following topics:

Selecting Objects for Policies

Policy Object Manager Window

Working with Policy Objects—Basic Procedures

Understanding AAA Server and Server Group Objects

Creating Access Control List Objects

Configuring Time Range Objects

Understanding Interface Role Objects

Understanding Map Objects

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

How Policy Objects are Provisioned as Object Groups

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 the Select button to display an object selector dialog box. In certain cases, the object selector is prefiltered to display only the objects that are applicable to the policy that 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. 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 open 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 the Create button to open 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. If you need to modify an existing object before using it, select it, click the Edit button and make your modifications, then click OK to save your changes; this returns you to the object selector.

When you create an object by opening the object editor from within a selector, the new object must conform to the requirements of the field from which the selector was opened. For example, if you open 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.

There are 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. The following table explains these selectors and how to use them.

Table 6-1 Object Selectors 

Element
Description

Type

The type of object to display in the selector, if there is an option. For example:

You can choose between network/host objects and interface roles when configuring sources and destinations in some rule-based policies.

You can choose between standard and extended ACL objects when configuring some ACLs (for example, when configuring VLAN ACLs on Catalyst 6500/7600 devices).

Tip In some policies, if you select more than one type of object, they are displayed on different tabs within the field.

Available [object type]

Displays all objects that are relevant to the policy or object you are configuring.

When selecting interfaces, be aware that there can 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.

Tip You can quickly find an object inside a selector by clicking in the list box and then starting to type the name of the object.

Selected [object type]

Displays the objects that you selected to apply to the policy or object that you are editing.

Multi-Object Selector Buttons

>> button

<< button

Moves the selected objects from one list to the other list in the direction indicated. You can select multiple objects by using Ctrl+click.

You can also move objects between lists by double-clicking them or by selecting them and pressing Enter.

Up/Down arrow buttons

For a limited number of object types, order matters. If the selector includes Move Up and Move Down buttons, arrange the objects in priority order. 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.

Common Buttons

Create button

Click this button to create an object of this type.

Tip In a few cases, such as network/host and service objects, clicking this button opens a list from which you need to select a specific type for the object.

Edit button

Click this button to edit the selected user-defined object. If you try to edit a system-defined object, it is opened in read-only mode.


Related Topics

Allowing a Policy Object to Be Overridden

Filtering Items in Selectors, page 1-34

Policy Object Manager Window

Use the Policy Object Manager window to:

View all the available objects grouped according to object type.

Create, copy, edit, and delete policy objects.

Generate usage reports, which describe how selected objects are being used by other Security Manager objects and policies.

Navigation Path

Click the Policy Object Manager button on the toolbar or select Manage > Policy Objects.

Related Topics

Creating Policy Objects

Selecting Objects for Policies

Generating Object Usage Reports

Managing Object Overrides

Filtering Tables, page 1-37

Field Reference

Table 6-2 Policy Object Manager Window 

Element
Description

Object Type selector or table of contents

(Left pane.)

Lists the object types available in Security Manager. When you select an object type, all existing objects of that type are listed in the table in the right pane.

Policy Object Table (Right Pane)

The policy object table in the right pane lists existing objects of the type selected in the table of contents. Using this table, you create new objects and work with existing ones. You can use the buttons below the table, or right-click within the table to see additional commands (see Policy Object Manager Window Shortcut Menu).

Except for the Access Control Lists (ACL) object, there is one table per object type. For ACLs, there are tabs to separate Extended, Standard, and Web ACLs. Select the appropriate tab to work with the desired object type.

The columns in the table vary based on the type of object you select. You can alter the columns displayed in the table by right-clicking the table heading and selecting or deselecting columns in the Show Columns command. You can also sort the information by the contents in a column by clicking the column heading; click the heading to toggle between alphabetical and reverse alphabetical sorting.

For detailed information on the settings that are displayed in the table, click the Create or Edit buttons below the table and click Help in the dialog box that is opened. Following is a description of the columns that you typically see.

Icon (unlabeled field)

The icon displayed for a policy object type identifies objects of that type wherever they appear, such as in rules tables. If the icon includes the image of a pencil, you can edit it.

Name

The name of the policy object.

Content

A summary of the object definition that might not include all defined settings.

Permit

For ACL objects, if the Access Control Entry (ACE) allows traffic, a check mark appears in the Permit column. If the action is deny, a red circle with a slash appears.

Category

The category object that is assigned to the object, if any. Categories help you organize and identify rules and objects. For more information, see Using Category Objects.

Overridable

Whether a user can override the object properties at the device level. A check mark indicates that the object can be overridden. Not all object types are overridable.

For more information about device overrides, see Managing Object Overrides.

Description

If a paper icon appears in this column, there is a description for the object. Double-click the icon to view the description or mouse-over the icon.

Buttons Below Table

Click the New Object button to create a new object. The same icon is used for any button that adds an item to a table.

Tip In a few cases, such as network/host and service objects, clicking this button opens a list from which you need to select a specific type for the object.

Clicking this button opens a dialog box to create the object. Click the Help button in the dialog box for information on the selected object type. Also, see Creating Policy Objects.

Click the Edit Object button to edit the selected object. The same icon is used for editing any object in a table.

The dialog box used for editing the object is the same as the one used for creating the object. If you try to edit a system-defined default object, you are allowed only to view the object contents. Click the Help button in the dialog box for information on the settings. For more information, see Editing Objects.

Click the Delete Object button to delete the selected object. You can delete only user-defined objects that are not currently being used in a policy or another policy object. For more information, see Deleting Objects.


Policy Object Manager Window Shortcut Menu

Right-clicking inside the policy object table in the Policy Object Manager Window displays a shortcut menu for performing various functions on the selected object type.

Field Reference

Table 6-3 Policy Object Manager Window Shortcut Menu 

Menu Command
Description

New Object

Select this command to create a new policy object. Click Help in the dialog box that is opened for information specific to the object type. Also, see Creating Policy Objects.

Tip For network/host and service objects, you need to also select an object type from the submenu.

Edit Object

Select this command to edit the policy object selected in the table. If you select a system-defined default object, you are presented with a view-only look at the object definition. For more information, see Editing Objects.

Delete Object

Select this command to delete the policy object selected in the table. You can delete only user-defined objects that are not being used in a policy or in another policy object. For more information, see Deleting Objects.

Edit Device Overrides

Select this command to change the device-level overrides for this object using the Policy Object Overrides Window. You can create, edit, and delete overrides. For more information, see Managing Object Overrides.

Clone Object

Select this command to create a copy of the policy object. For more information, see Cloning (Duplicating) Objects.

Find Usage

Select this command to generate a usage report for the selected object using the Object Usage dialog box. The usage report tells you where the object is currently being used. for more information, see Generating Object Usage Reports.

View Object

Select this command to view the definition of the object using a read-only version of the edit dialog box for the object. For more information, see Viewing Object Details.


Working with Policy Objects—Basic Procedures

The following topics describe the actions that you can perform on policy objects. Some tasks are limited to certain types of objects. For example, not all types of object can be overridden, you cannot edit predefined objects, and you cannot import or export all objects.

This section contains the following topics:

Creating Policy Objects

Editing Objects

Using Category Objects

Cloning (Duplicating) Objects

Viewing Object Details

Generating Object Usage Reports

Deleting Objects

Managing Object Overrides

Importing and Exporting Policy Objects

Creating Policy Objects

Security Manager provides predefined policy 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.

Using object selectors. When you define a policy that uses objects, object selectors include buttons for creating and editing objects so you don't have to leave the policy you are defining. This is frequently the best method to use, because during policy creation you are prompted for the specific type of object that applies to the situation, and you are more aware of the settings you need for the policy. See Selecting Objects for Policies.


Tip 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 (select 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 11-33.


Related Topics

Chapter 6 "Managing Policy Objects"

Working with Policy Objects—Basic Procedures


Step 1 Do one of the following:

Select Manage > Policy Objects to open the Policy Object Manager Window. Select the type of object you want to create from the table of contents, right-click in the table and select New Object.

While configuring a rule, click Select next to a field that allows or requires a policy object. In the object selector, click the Create button below the available objects list.


Tip In a few cases, such as network/host and service objects, clicking these buttons opens a list from which you need to select a specific type for the object.


The dialog box for adding the selected type of object opens. For more information about the individual types of objects, see the following topics:

Understanding AAA Server and Server Group Objects

Creating Access Control List Objects

ASA Group Policies Dialog Box, page 30-1

Using Category Objects

Configuring Credentials Policy Objects, page 24-9

Add and Edit File Object Dialog Boxes, page 30-22

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

Configuring IKEv1 Proposal Policy Objects, page 22-10

Configuring IKEv2 Proposal Policy Objects, page 22-13

Understanding Interface Role Objects

Configuring IPSec IKEv1 or IKEv2 Transform Set Policy Objects, page 22-23

Add and Edit LDAP Attribute Map Dialog Boxes

Understanding Map Objects

Understanding Network/Host Objects (IPv4 and IPv6)

PKI Enrollment Dialog Box, page 22-50

Add or Edit Port Forwarding List Dialog Boxes, page 30-24

Configuring Port List Objects

Creating Cisco Secure Desktop Configuration Objects, page 29-18

Understanding and Specifying Services and Service and Port List Objects

Add or Edit Single Sign On Server Dialog Boxes, page 30-26

Monitoring Service Level Agreements (SLAs) To Maintain Connectivity, page 47-7

Configuring SSL VPN Bookmark Lists for ASA and IOS Devices, page 27-64

Configuring ASA Portal Appearance Using SSL VPN Customization Objects, page 27-59

Add or Edit SSL VPN Gateway Dialog Box, page 30-45

Configuring SSL VPN Smart Tunnels for ASA Devices, page 27-66

Add or Edit Text Object Dialog Box, page 7-32

Configuring Time Range Objects

Configuring Traffic Flow Objects, page 53-13

Add or Edit User Group Dialog Box, page 30-53

Configuring WINS/NetBIOS Name Service (NBNS) Servers To Enable File System Access in SSL VPNs, page 27-69

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

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, maps, network/host 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.


Step 3 Configure the settings specific to the type of object. Refer to the online help page for the dialog box.

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

Step 5 (Optional) If the object type provides the option, select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Policy Object to Be Overridden.

Step 6 Click OK to save the object.


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. However, if an override for the object is already defined for a device, your edits are not reflected in the object used on those devices.

Tips

You cannot edit predefined objects, but you can copy them to create new objects. See Cloning (Duplicating) Objects.

Messages appear at the top of the Edit dialog box to indicate the following situations:

That you have read-only access to the object. You cannot save changes to these objects.

That the policy object was imported using the procedure described in Importing Policies or Devices, page 10-12. Imported objects might be re-imported at some point if the shared policy that uses the object is managed on a different server. Any changes that you make are eliminated if the policy object is imported again. Before editing the object, ensure that you understand the protocols used in your organization for policy management and importation. You can control whether this message appears using an option on the Tools > Security Manager Administration > Policy Management page (see Policy Management Page, page 11-32).

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

Creating Policy Objects


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select the object type from the table of contents.

Step 3 Right-click the object you want to edit and 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. Click the Help button for information specific to the type of object.


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.


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

Step 2 Select Categories from the Object Type selector.

Step 3 Click Edit Object to open the Category Editor dialog box.

Step 4 Modify the names and descriptions of the predefined category objects as required:

Label—The color associated with the category.

Name—The category name. Names can have a maximum of 128 characters, including special characters and spaces.

Description—Additional information about the object (up to 1024 characters).

Step 5 Click OK to save your changes.


Cloning (Duplicating) Objects

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

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

Related Topics

Working with Policy Objects—Basic Procedures


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select the object type from the table of contents.

Step 3 Right-click the object you want to duplicate and select Clone Object.

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. Click the Help button for information specific to that type of object.

Step 5 Click OK to save your changes.


Viewing Object Details

You can view contents of an object 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.

Related Topics

Working with Policy Objects—Basic Procedures


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select the object type from the table of contents.

Step 3 Right-click the object and select View Object.

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


Generating Object Usage Reports

Before you make any changes to a policy 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 database.

You can use either of these methods to generate usage reports:

Policy Object Manager—Select Manage > Policy Objects to open the Policy Object Manager Window. Select the type of object from the table of contents, right-click the object and select Find Usage.

Firewall rules policies—Left-click an object in a firewall rules table, then right-click and select Find Usage.

The usage information is displayed in the Object Usage dialog box. You can select or deselect the checkboxes below the table to view only devices, policies, or other objects that use the selected object. The following table describes the fields in the dialog box.

Table 6-4 Object Usage Dialog Box 

Element
Description

Used By

The name of the device, policy, VPN, or object that is referencing the selected object.

Type

The type of item that is referencing the selected object. This can be a device, policy, or another object.

Usage

Indicates how the object is being referenced. For example, if a device is referencing the selected object, this column will indicate that it is a policy assigned to the device that is referencing the object.

Proximity

Indicates the relationship between the selected object and the item that it using it. For example:

A policy that includes a network/host object in its definition has a direct relationship with the object and an indirect relationship with any other network/host objects contained within the object.

A device on which this policy is assigned references the network/host object directly and any other network/host objects contained within the object indirectly.

Devices

Policies

Other Objects

The types of references you want to view. For example, you can deselect Devices and Policies to view only references to the object from other objects.


Deleting Objects

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


Tip You might be prevented from deleting an unused 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 unused objects in the database, because they will not affect your policies.


Before You Begin

Determine if the object is currently being used and which policies, objects, and devices would be affected by the deletion. You need to remove all references to the object before you can delete it. You can generate a usage report for this purpose. See Generating Object Usage Reports.


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select the object type from the table of contents.

Step 3 Right-click the object you want to delete and select Delete Object, or select the object and click the Delete Object button. You are asked to confirm the deletion.


Managing Object Overrides

When you create a policy object, you can elect to allow the object to be overridden. This makes it possible to create a generic object to enable you to create general policies. For individual devices, you override the policy object definition to make the policy apply correctly to the device.

From the Policy Object Manager Window, you can select a policy object that can be overridden and generate a table of device-level overrides that are defined for that global object. Right-click the object and select Edit Device Overrides to generate the table (see Policy Object Overrides Window).

You can create device-level overrides in two places:

In the Device Properties window of a selected device, which allows you to create and manage overrides for the selected device only. For more information, see Creating or Editing Object Overrides for a Single Device.

In the Policy Object Manager window, which allows you to create and manage overrides for more than one device at a time. For more information, see Creating or Editing Object Overrides for Multiple Devices At A Time.


Tip 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.


The following topics explain policy object overrides in more detail:

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for a Single Device

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides

Understanding Policy Object Overrides for Individual Devices

For many types of policy objects, you can elect to allow an object to be overridden for a particular device. Thus, you can create an object whose definition works for most devices, and then create modifications to the object for the few devices that need slightly different definitions. Or, you can create an object that needs to be overridden for all devices, but which allows you to create a single policy for all devices. Object overrides make it possible for you to create a smaller set of shared policies for use across your devices without giving up the ability to alter policies when needed for individual devices.

For example, you might 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 an access rule firewall policy with a rule that includes a 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.

You can quickly tell if an object can be overridden by looking for the Overridable column in the objects table in the Policy Object Manager Window. A green checkmark indicates that you can create overrides for the object; the presence of the column indicates the object type allows overrides.

Related Topics

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for a Single Device

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides

Allowing a Policy Object to Be Overridden

To create overrides for an object, the object must allow overrides. Not all object types allow overrides.

For those that do allow overrides, you define the object as allowing overrides by selecting Allow Value Override per Device when defining the object. After selecting this option, you must click OK to save the object before you can define any overrides. For more information on creating objects, see Creating Policy Objects.

You can also configure Security Manager to create device-level overrides for existing objects when you discover policies on devices that you add to the inventory. During discovery, if Security Manager determines that an existing object applies to a discovered policy, but that it is not a perfect fit, the object is used but a device-level override is created to account for the difference. For example, if you run policy discovery on a device that has an ACL with the same name as an ACL policy object in Security Manager, the name of the discovered policy object is reused, but a device-level override is created for the object. If you do not allow device-level overrides during discovery, a new policy object is created with a number appended to the name; this is the default.

To configure Security Manager to allow device overrides during discovery, select Tools > Security Manager Administration > Discovery and select Allow Device Override for Discovered Policy Objects.

Related Topics

Understanding Policy Object Overrides for Individual Devices

Creating or Editing Object Overrides for a Single Device

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides

Creating or Editing Object Overrides for a Single Device

You can create or edit 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.

Related Topics

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides


Step 1 (Device view) Right-click a device in the Device selector and select Device Properties.

Step 2 Select the object type you want to override from the Policy Object Overrides folder.

The table displays all objects of the selected type that can be overridden at the device level. If an object has an override already defined for the device, the Value Overridden? column contains a check mark.

Step 3 Select the object whose override you want to change and do one of the following:

Click the Create Override button, or right-click and select Create Override.

Click the Edit Override button, or right-click and select Edit Override.

The dialog box for defining that type of object is displayed with the current properties (either the global properties or the local override).

Step 4 Modify the definition of the object and click OK to save the device-level override. In the Device Properties window, a green check mark appears in the Value Overridden? column.


Creating or Editing Object Overrides for Multiple Devices At A Time

You can create or edit 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.

Related Topics

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for a Single Device

Deleting Device-Level Object Overrides


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select the object type you want to override from the table of contents, and then select the object to override.


Tip Not all types of object allow overrides, and not all objects are defined as overridable. Look for a green check mark in the Overridable column. If the object type allows overrides, but this object does not have a check mark, edit the object to enable object override (see Allowing a Policy Object to Be Overridden).


Step 3 Double-click the checkmark, or right-click the object and select Edit Device Overrides, to open the Policy Object Overrides Window. The window contains a table listing each device for which an override is defined for the object.


Tip You can also edit the overridable object and click Edit next to the Overrides field.


Step 4 Do one of the following:

To add an override, click the Create Override button, select the devices to which you want to apply the override, and define the override.

The dialog boxes for creating and editing the override are the same ones used to create the object; click the Help button for information specific to the type of object.

The override you create applies to all policies on the device that use the object; you cannot override the object for one policy but not for another policy.

To edit an override, select it and click the Edit Override button.


Policy Object Overrides Window

Use the Policy Object Overrides window to view a list of all device-level overrides that are defined for the selected object. The content displayed in the table differs depending on the type of object, but it always includes the device name, object description, and category. Sometimes the content of the object is shown, including the overrides.

To add an override, click the Create Override button. In the Create Overrides for Device window, select the devices from the available list and click >> to move them to the selected list. When you click OK, you are presented with the dialog box for defining your override, which applies to all newly selected devices. (You are not changing the override of the greyed out devices)


Note The available devices list shows the devices that have not already had overrides defined for the object. Devices with overrides are shown greyed out in the selected devices list.


The dialog boxes for creating and editing the override are the same ones used to create the object; click the Help button for information specific to the type of object.

The override you create applies to all policies on the device that use the object; you cannot override the object for one policy but not for another policy.

To edit an override, select it and click the Edit Override button.

To delete an override, select it and click the Delete Override button.

Deleting an override does not delete the object or remove the object from its device assignment. When you delete the override, the policies on the device that use the object start using the global definition for the object. This changes the meaning of the policies.


Tip You can also create and edit device-level overrides from the Device Properties window of a selected device. Using the Device Properties windows makes it easy for you to manage the overrides for all objects used by a single device. For more information, see Creating or Editing Object Overrides for a Single Device.


Navigation Path

Open the Policy Object Manager Window. Select an object type that can be overridden (its object page contains a column called Overridable), then do one of the following:

Double-click the green checkmark in the Overridable column.

Right-click the object and select Edit Device Overrides.

Edit the overridable object and click Edit next to the Overrides field.

Related Topics

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Creating or Editing Object Overrides for Multiple Devices At A Time

Deleting Device-Level Object Overrides

Filtering Tables, page 1-37

Filtering Items in Selectors, page 1-34

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:

Deleting overrides from Device view—Right-click the device and select Device Properties, then select the object type from the Policy Object Overrides folder. Select the override you want to delete and click Delete Override.

Deleting overrides from the Policy Object Manager—Select the object type from the table of contents, then right-click the object and select Edit Device Overrides. Select the override you want to delete and click Delete Override.

Related Topics

Understanding Policy Object Overrides for Individual Devices

Allowing a Policy Object to Be Overridden

Policy Object Override Pages, page 3-43

Policy Object Overrides Window

Importing and Exporting Policy Objects

Security Manager includes a Perl script that you can use to export network/host, service, and port list policy objects so that you can import them into another Security Manager server. The information includes device-level overrides for policy objects that have them.


Note The command works with network/host objects that contain IPv4 addresses only. You cannot use the command to import network/host-IPv6 objects.


You can also manually create a CSV file that you can import. For example, you might obtain a list of IP addresses that identify networks or hosts that should be denied entry to your network. You can create a CSV file that will bulk-load the list as one or more network/host objects if that is easier than manually creating the object in the Policy Object Manager.


Tip Besides using this command, you can use other facilities to export and import policy objects that are assigned to shared policies or configured in local device policies. For more information, see the following topics: Exporting the Device Inventory from the Security Manager Client, page 10-6, Exporting Shared Policies, page 10-11, and Importing Policies or Devices, page 10-12


The Perl command is located in $NMSROOT\bin, which is typically C:\Program Files\CSCSpx\bin. The syntax of the command is:

perl [path]PolicyObjectImportExport.pl -u username -p password -o {import | export} [-a activity] -t object_type -f filename [-c {true | false}] [-d {true | false}] [-h]

Syntax

perl [path] PolicyObjectImportExport.pl

The Perl script command. Include the path to the PolicyObjectImportExport.pl file if the path is not defined in the system path variable.

-u username

A Security Manager username. The data exported is limited by the permissions assigned to this user. The user must have Modify Objects permission for the import or export of policy objects, and additionally the Modify Devices permission for the import or export of device-level overrides.

If you are importing objects in non-Workflow mode, you must also have Submit and Approve privileges.

-p password

The user's password.

-o {import | export}

The type of operation you are performing, either to import policy objects from an existing file, or to export policy objects to a CSV file. Only committed objects are exported.

-a activity

(Optional.) The name of a Workflow activity. If you do not specify a name, a new activity is created with the name username_time.

-t object_type

Object type, one of the following:

network—For network/host objects.

service—For service objects.

portlist—For port list objects.

-f filename

The name of the CSV file. When exporting, if the file exists, it is overwritten.

-c {true | false}

(Optional.) When importing objects, whether to enable policy object conflict detection.

false—An object is imported even if an existing object has the same content.

true—If an existing object has the same content as an imported object, the imported object is skipped. You must also select Enforce for the When Redundant Objects Detected option on the Policy Objects Page, page 11-33.

-d {true | false}

(Optional.) How to handle device-level policy object overrides during either an import or export operation:

true—Include all globally-defined objects and all device-level overrides of the objects.

false—Include only the global definitions of the policy objects. Do not include any device-level policy object override information. This is the default.

-h

(Optional.) Display the command line help. If you include this option, all other options are ignored.


Importing Policy Objects

When you are importing objects, if an object refers to another object, that object must already be defined in Security Manager, or it must be defined in the same CSV file that you are importing. If the object is in the same CSV file, it must come before the object that refers to it. (Security Manager automatically sorts objects as required when exporting them.)

If Security Manager already has a policy object of the same name as one you are importing, the object is skipped and not imported. The name conflict can even occur if another user has created an object but not yet committed it for public viewing, so you might not be able to see the conflicting object. Security Manager creates only new objects, it does not update existing objects. Use the -c option to specify whether new objects can be created that have the same content as existing objects.

When you run the command, if there are any errors in the file, only the affected objects are not imported. Error messages indicate these problems as they occur, and Security Manager continues evaluating all records in the file. All correctly defined policy objects are imported, and the objects with errors are skipped. The total count and the names of the policy objects that are not imported are shown in the output screen.

After the import command completes, additional actions depend on the Workflow mode you are using:

Workflow mode—You must log into Security Manager using the same username and password and submit the activity you specified during the import. The activity must be submitted and approved for the changes to take effect.

Non-Workflow mode—The imported objects are automatically submitted and approved without action on your part. However, you will receive an error if the username you supplied does not have Submit and Approve privileges, and the import operation will fail.

CSV File Format

All objects in a single file are of the same policy object type. The file is in standard comma-separated values (CSV) format. The first line has column headings. Each row represents a single policy object. The columns, left to right, are:

Name—(Mandatory.) The name of the object.

Node—The display name of the device on which an override of the policy object is defined. If the policy object is defined on the global level, the field is empty. When importing objects, if the display name does not match a device already in the Security Manager inventory, the object is skipped and not imported.

Description—The description of the object, if any.

Category—The category identifier of the object, if any. The category ID is from 10 to 19.

Allow Override—Whether the object can be overridden. True if the policy object can be overridden on device level, False (or an empty field) if not.

Group—The names of other policy objects with the same type referenced by this policy object. If there is more than one object, they are separated by commas. For example, network building block Net1 references network building block Net2 and Net3. The Group field of Net1 would have "Net2,Net3" as its value.

Data—The content of the object.

Subtype—The object subtype, if any, for network/host and service objects. For an explanation of network/host and service object types, see Understanding Network/Host Objects (IPv4 and IPv6) and Understanding and Specifying Services and Service and Port List Objects. Possible values are:

Blank, or space—The object is a group object, either network/host or service.

NH—(Network/host objects only.) Single host network/host object.

NN—(Network/host objects only.) Single network address network/host object.

NR—(Network/host objects only.) Single Address range network/host object.

SO—(Service objects only.) Single-service service object.

If there is no value for a particular field, that field is blank in the output. If there are multiple values for a field, the field is enclosed in double quotation marks.

Understanding AAA Server and Server Group Objects

You use AAA server objects to identify the AAA servers used in your network. 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, 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 access rules (ACLs) alone. For example, you can create an access rule allowing all outside users to attempt to use Telnet on a server on the DMZ network. If you want only some users to actually reach the server (and you might not always know the IP addresses of these users, making it impossible to configure simple access rules), you can enable AAA to allow only authenticated or authorized users to make it through the network device (for example, the ASA or router). Thus, users must authenticate before reaching the Telnet server, where Telnet can also require a separate login.

AAA server objects are collected into AAA server group objects. Policies requiring AAA (such as Easy VPN, Remote Access VPNs, and router platform policies such as Secured Device Provisioning and 802.1x) usually 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.

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

Supported AAA Server Types

Additional AAA Support on ASA, PIX, and FWSM Devices

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Creating AAA Server Objects

Add or Edit AAA Server Dialog Box

Add and Edit LDAP Attribute Map Dialog Boxes

Creating AAA Server Group Objects

Supported AAA Server Types

You can use AAA servers that use the RADIUS protocol with all devices, and the TACACS+ protocol with all devices except IPS. For ASA, PIX, and FWSM devices, you can also use the protocols described in Additional AAA Support on ASA, PIX, and FWSM Devices

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.

You can use RADIUS with other AAA security protocols, such as TACACS+, Kerberos, and local username lookup, depending on what is supported by a particular device type. 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 independently.

Related Topics

Additional AAA Support on ASA, PIX, and FWSM Devices

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

Additional AAA Support on ASA, PIX, and FWSM Devices

In addition to supporting RADIUS and TACACS+, ASA, PIX 7.0+, and FWSM 3.1+ devices can support AAA servers running the following protocols. For more information, see the explanation of AAA usage in the configuration guides for the device type and operating system version that interests you.

Kerberos—These devices can use Kerberos servers for VPN authentication. When a user attempts to establish VPN access through the 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—These 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 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, you must specify whether the server is version 5.0 or an earlier version.

LDAP—These devices can use Lightweight Directory Access Protocol (LDAP) servers for VPN authorization. These 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 one of these devices using one of these other servers for authentication and their password has expired, the 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, PIX, or FWSM device) to an LDAP server. These devices and LDAP servers can support multiple mechanisms. If both mechanisms (MD5 and Kerberos) are available, the ASA, PIX, or FWSM 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, PIX, or FWSM device queries the LDAP server and applies the authorizations it receives to the VPN session.

HTTP-Form—These devices 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 6-5 describes the AAA services that are supported by each protocol:

Table 6-5 AAA Services Supported by ASA, PIX, and FWSM 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

Yes1

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 and Server Group Objects

Predefined AAA Authentication Server Groups

There are 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 6-6 describes the predefined AAA authentication server groups.

Table 6-6 Predefined AAA Authentication Server Groups 

Name
Description

Enable

Uses the enable password defined on the device for authentication.

KRB5

KRB5-Telnet

Uses Kerberos 5 for authentication. Use KRB5-Telnet when using Telnet to connect.

For Cisco IOS routers, you can use 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).

If-Authenticated

Uses the if-authenticated method, which allows the user to access the requested function if the user is authenticated.

Line

Uses the line password defined on the device for authentication.

Local

Local-case

Uses the local username database (defined on the device) for authentication. Use Local-case if you want the login to be case-sensitive.

None

Uses no authentication.

RADIUS

TACACS+

Use RADIUS or TACACS+ authentication. (Does not apply to Cisco IOS routers.)

These AAA server groups do not contain any AAA servers. To use one of them 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 or Editing Object Overrides for a Single Device.


Related Topics

Creating AAA Server Group Objects

Default AAA Server Groups and IOS Devices

Understanding AAA Server and 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.

You can also create your own default group. 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 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 and Server Group Objects

Creating AAA Server Objects

You can create AAA server objects to populate the AAA server group objects that are referenced by policies such as AAA rules, Easy VPN, and 802.1x. In some cases, AAA server objects are used directly by a policy, such as in AAA policies on IPS devices.

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.


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 not referenced by any policies.


Related Topics

Creating Policy Objects

Supported AAA Server Types

Additional AAA Support on ASA, PIX, and FWSM Devices

Understanding AAA Server and Server Group Objects


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

Step 2 Select AAA Servers from the Object Type selector.

Step 3 Right-click in the work area, then select New Object to open the Add or Edit AAA Server Dialog Box.

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

Step 5 Identify the AAA server:

In the Host field, enter the IP address or for ASA, or PIX 7.2+ devices, the host name of the AAA server. You can also enter the name of a network/host object that contains the host IP address, or click Select to select the object.

Optionally, in the Interfaces field, enter the name of an interface or an interface role (which must resolve to a single interface name on the device) whose IP address should be used for all outgoing RADIUS or TACACS+ packets. Do not specify an interface for objects used on an IPS device.

Optionally, enter the amount of time to wait until a AAA server is considered unresponsive.

Step 6 Select the protocol used by the AAA server and configure protocol-specific properties. You can use RADIUS with all device types, and TACACS+ with all device types except for IPS devices. You can use the Kerberos, LDAP, NT, SDI, and HTTP-FORM protocols only with ASA, PIX 7.x+, and FWSM 3.1+ devices.

For details about the properties, see the following topics:

RADIUS—See AAA Server Dialog Box—RADIUS Settings.

TACACS+—See AAA Server Dialog Box—TACACS+ Settings.

Kerberos—See AAA Server Dialog Box—Kerberos Settings.

LDAP—See AAA Server Dialog Box—LDAP Settings.

NT—See AAA Server Dialog Box—NT Settings.

SDI—See AAA Server Dialog Box—SDI Settings.

HTTP-FORM—See AAA Server Dialog Box—HTTP-FORM Settings.

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.


Add or Edit AAA Server Dialog Box

Use Add or Edit AAA Server dialog box to create, copy, and edit a AAA server object. These objects are collected into AAA server group objects and identify the AAA servers that you want to use when defining various AAA policies. In some cases these objects are used directly in a AAA policy.

For a description of the protocols you can use, see Supported AAA Server Types and Additional AAA Support on ASA, PIX, and FWSM Devices.


Note You cannot edit the protocol if the object is already included in a AAA server group.


Navigation Path

Select Manage > Policy Objects, then select AAA Servers from the Object Type Selector. Right-click inside the work area and select New Object or right-click a row and select Edit Object.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

Policy Object Manager Window

Field Reference

Table 6-7 AAA Server Dialog Box—General Settings 

Element
Description

Name

The object name, which can be up to 128 characters. Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Host

The address of the AAA server to which authentication requests will be sent. Specify one of the following:

IP Address—The IP address of the AAA server. You can also enter the name of a network/host object that contains the host IP address, or click Select to select the object.

DNS Name (for PIX/ASA 7.2+ devices only)—The DNS hostname of the AAA server, up to 128 characters. The hostname can contain alphanumeric characters and hyphens, but each element of the hostname must begin and end with an alphanumeric character.

Interface

The interface whose IP address should be used for all outgoing RADIUS or TACACS packets (known as the source interface). Enter the name of an interface or interface role, or click Select to select it from a list or to create a new interface role.

Tips

If 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.

If you enter the name of an interface role, make sure the role represents a single interface, not multiple interfaces.

Only one source interface can be defined for the AAA servers in a AAA server group. An error is displayed when you submit your changes if different AAA servers in the group use different source interfaces. See Creating AAA Server Group Objects.

You cannot specify an interface name for a AAA server used on an IPS device.

Timeout

The amount of time to wait until the AAA server is considered unresponsive:

Cisco IOS routers—The range is 1-1000 seconds. The default is 5 seconds.

ASA/PIX 7.x+, FWSM 3.1+ devices—The range is 1-300 seconds. The default is 10 seconds.

PIX 6.3 firewalls—The range is 1-512 seconds. The default is 5 seconds.

IPS devices—The range is 1-512 seconds. The default is 3 seconds.

Protocol

The protocol used by the AAA server. The fields to the right of the protocol list change depending on your selection.

For specific information about the fields, see the topics indicated.

The following protocols are the most common:

RADIUS—All device types. See AAA Server Dialog Box—RADIUS Settings.

TACACS+—All device types except IPS. See AAA Server Dialog Box—TACACS+ Settings.

The following protocols are supported for ASA/PIX 7.x+ and FWSM 3.1+ devices:

Kerberos—See AAA Server Dialog Box—Kerberos Settings.

LDAP—See AAA Server Dialog Box—LDAP Settings.

NT—See AAA Server Dialog Box—NT Settings.

SDI—See AAA Server Dialog Box—SDI Settings.

HTTP-FORM—See AAA Server Dialog Box—HTTP-FORM Settings.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.


AAA Server Dialog Box—RADIUS Settings

Use the RADIUS settings in the AAA Server dialog box to configure a RADIUS AAA server object.

Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select RADIUS in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-8 AAA Server Dialog Box—RADIUS Settings 

Element
Description

Key

Confirm

The shared secret that is used to encrypt data between the client and AAA server. The key is a case-sensitive, alphanumeric string of up to 127 characters (U.S. English). Spaces and special characters are permitted.

The key you define in this field must match the key on the RADIUS server. Enter the key again in the Confirm field.

Note the following:

A key is required for AAA server objects used in an IPS AAA policy. Otherwise, the key is optional.

Activity validation fails if you try defining a key with a space on a PIX, ASA, or FWSM device.

If you do not define a key, all traffic between the AAA server and its AAA clients is sent unencrypted.

Authentication/Authorization Port

The port on which AAA authentication and authorization are performed. The default is 1645.

Tip The default port for IPS devices is 1812, so you need to change this value if you are configuring the object for IPS and you want to use the default port.

Accounting Port

The port on which AAA accounting is performed. The default is 1646.

RADIUS Password

Confirm

(ASA, PIX 7.x+, and FWSM 3.x+ devices only.)

The alphanumeric keyword that serves as the password to the RADIUS server (maximum of 128 characters; spaces are not allowed). Enter the password again in the Confirm field.

Retry Interval

(ASA, PIX 7.x+, and FWSM 3.x+ devices only.)

The interval between attempts to contact the AAA server. Values are:

ASA/FWSM devices—1 to 10 seconds.

PIX devices—1 to 5 seconds.

ACL Netmask Convert

(ASA, PIX 7.x+, and FWSM 3.x+ devices only.)

The method for handling the netmask expressions that are contained in downloadable ACLs received from the RADIUS server:

Standard—The security appliance assumes that all downloadable ACLs received from the RADIUS server contain only standard netmask expressions. No translation from wildcard netmask expressions is performed. This is the default.

Auto-Detect—The security appliance tries to determine the type of netmask expression used in the downloadable ACL. If it detects a wildcard netmask expression (used by Cisco IOS software), it converts it to a standard netmask expression.

Wildcard—The security appliance assumes that all downloadable ACLs received from the RADIUS server contain only wildcard netmask expressions, which it converts to standard netmask expressions.

Some Cisco products, including Cisco IOS routers, require that downloadable ACLs be configured with wildcards instead of network masks. ASA devices, on the other hand, require that downloadable ACLs be configured with network masks. This feature allows the ASA device to internally convert a wildcard to a netmask. Translation of wildcard netmask expressions means that downloadable ACLs written for Cisco IOS routers can be used by ASA devices without altering the configuration of the ACLs on the RADIUS server.


AAA Server Dialog Box—TACACS+ Settings

Use the TACACS+ settings in the AAA Server dialog box to configure a TACACS+ AAA server object.

Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select TACACS+ in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-9 AAA Server Dialog Box—TACACS+ Settings 

Element
Description

Key

Confirm

The shared secret that is used to encrypt data between the client and the AAA server. The key is a case-sensitive, alphanumeric string of up to 127 characters (U.S. English). Spaces and special characters are permitted.

The key you define in this field must match the key on the TACACS+ server. Enter the key again in the Confirm field.

Note the following:

Activity validation fails if you try defining a key with a space on a PIX, ASA, or FWSM device.

If you do not define a key, all traffic between the AAA server and its AAA clients is sent unencrypted.

Server Port

The port used for communicating with the AAA server. The default is 49.


AAA Server Dialog Box—Kerberos Settings

Use the Kerberos settings in the AAA Server dialog box to configure a Kerberos AAA server object.


Note This type of AAA server can be configured only on ASA, PIX 7.x+, and FWSM 3.1+ devices.


Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select Kerberos in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-10 AAA Server Dialog Box—Kerberos Settings 

Element
Description

Server Port

The port used for communicating with the AAA server. The default is 88.

Kerberos Realm Name

The name of the realm containing the Kerberos authentication server and ticket granting server (maximum of 64 characters). For example, example.com.

Retry Interval

The interval between attempts to contact the AAA server. Values range from 1 to 10 seconds.


AAA Server Dialog Box—LDAP Settings

Use the LDAP settings in the AAA Server dialog box to configure an LDAP AAA server object.


Note This type of AAA server can be configured only on ASA, PIX 7.x+, and FWSM 3.1+ devices.


Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select LDAP in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-11 AAA Server Dialog Box—LDAP Settings 

Element
Description

Enable LDAP over SSL

Whether to establish a secure SSL connection between the ASA/PIX/FWSM device and the LDAP server.

Tip You must select this option when using a Microsoft Active Directory LDAP server in order to enable password management.

Server Port

The port used for communicating with the AAA server. The default is 389.

LDAP Hierarchy Location

The base distinguished name (DN), which is the location in the LDAP hierarchy where the authentication server should being searching when it receives an authorization request. For example, OU=Cisco. The maximum length is 128 characters.

The string is case-sensitive. Spaces are not permitted, but other special characters are allowed.

LDAP Scope

The scope of LDAP searches:

onelevel—Searches only one level beneath the base DN. This type of search scope is faster than a subtree search, because it is less comprehensive. This is the default.

subtree—Searches all levels beneath the base DN.

LDAP Distinguished Name

The DN and password that uniquely identify the ASA/PIX/FWSM device in the LDAP schema (maximum of 128 characters). The DN is similar to a unique key in a database or a fully qualified path for a file. These parameters are used only when the LDAP server requires them for authentication.

LDAP Login Directory

The name of the directory object in the LDAP hierarchy used for authenticated binding (maximum of 128 characters). Authenticated binding is required by some LDAP servers (including the Microsoft Active Directory server) before other LDAP operations can be performed.

This string is case-sensitive. Spaces are not permitted in the string, but other special characters are allowed.

LDAP Login Password

The case-sensitive, alphanumeric password for accessing the LDAP server (maximum of 64 characters). Spaces are not allowed.

SASL MD5 Authentication

SASL Kerberos Authentication

Kerberos Server Group

These options establish a Simple Authentication and Security Layer (SASL) mechanism to authenticate an LDAP client (the ASA/PIX/FWSM device) with an LDAP server.

You can define one or both SASL authentication mechanisms. When negotiating SASL authentication, the ASA/PIX/FWSM device retrieves the list of SASL mechanisms configured on the LDAP server and selects the strongest mechanism configured on both devices.

SASL MD5 Authentication—Whether to have the device send the LDAP server an MD5 value computed from the username and password.

SASL Kerberos Authentication—Whether to have the device send the LDAP server the username and realm using the GSSAPI (Generic Security Services Application Programming Interface) Kerberos mechanism. This mechanism is stronger than the MD5 mechanism.

If you select Kerberos, you must also enter the name of the Kerberos AAA server group used for SASL authentication. The maximum length is 16 characters.

LDAP Server Type

The type of LDAP server used for AAA:

Auto-Detect—The ASA/PIX/FWSM device tries to determine the server type automatically. This is the default.

Microsoft—The LDAP server is a Microsoft Active Directory server.

Note You must configure LDAP over SSL to enable password management with Microsoft Active Directory.

Sun—The LDAP server is a Sun Microsystems JAVA System Directory Server.

OpenLDAP—The server is an Open LDAP server. You can use this only with ASA/PIX 8.0+ devices.

Novell—The server is a Novell LDAP server. You can use this only with ASA/PIX 8.0+ devices.

LDAP Attribute Map

The LDAP attribute configuration to bind to the LDAP server. Enter the name of an LDAP attribute map policy object or click Select to select it from a list or to create a new object.

LDAP attribute maps take the attribute names that you define and map them to Cisco-defined attributes. For more information, see Add and Edit LDAP Attribute Map Dialog Boxes.


AAA Server Dialog Box—NT Settings

Use the NT settings in the AAA Server dialog box to configure an NT AAA server object.


Note This type of AAA server can be configured only on ASA, PIX 7.x+, and FWSM 3.1+ devices.


Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select NT in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-12 AAA Server Dialog Box—NT Settings 

Element
Description

Server Port

The port used for communicating with the AAA server. The default is 139.

NT Authentication Host

The name of the authentication domain controller hostname (maximum of 16 characters).


AAA Server Dialog Box—SDI Settings

Use the SDI settings in the AAA Server dialog box to configure an SDI AAA server object.


Note This type of AAA server can be configured only on ASA, PIX 7.x+, and FWSM 3.1+ devices.


Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select SDI in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-13 AAA Server Dialog Box—SDI Settings 

Element
Description

Server Port

The port used for communicating with the AAA server. The default is 5500.

Retry Interval

The interval between attempts to contact the AAA server. Values range from 1 to 10 seconds. The default is 10 seconds.

SDI Server Version

The SDI server version:

SDI-pre-5—All SDI versions before version 5.0

SDI-5—SDI version 5.0 or later.

SDI pre-5 Slave Server

(Optional) A secondary server to be used for authentication if the primary server fails when using an SDI version prior to 5.0. Enter the IP address or the name of a network/host object, or click Select to select an object or create a new one.


AAA Server Dialog Box—HTTP-FORM Settings

Use the HTTP-FORM settings in the AAA Server dialog box to configure an HTTP-Form AAA server object for single sign-on authentication (SSO).


Note This type of AAA server can be configured only on ASA, PIX 7.x+, and FWSM 3.1+ devices.


Navigation Path

Go to the Add or Edit AAA Server Dialog Box and select HTTP-FORM in the Protocol field.

Related Topics

Creating AAA Server Objects

Understanding AAA Server and Server Group Objects

AAA Server Group Dialog Box

Field Reference

Table 6-14 AAA Server Dialog Box—HTTP-Form Settings 

Element
Description

Start URL

The URL from which the WebVPN server of the security appliance should retrieve an optional pre-login cookie. The maximum URL length is 1024 characters.

The authenticating web server might execute a pre-login sequence by sending a Set-Cookie header along with the login page content. The URL in this field defines the location from which the cookie is retrieved.

Note The actual login sequence starts after the pre-login cookie sequence.

Action URI

The Uniform Resource Identifier (URI) that defines the location and name of the authentication program on the web server to which the security appliance sends HTTP POST requests for single sign-on (SSO) authentication.

The maximum length of the action URI is 2048 characters.

Tip You can discover the action URI on the authenticating web server by connecting to the web server's login page directly with a browser. The URL of the login web page displayed in your browser is the action URI for the authenticating web server.

Username Parameter

The name of the username parameter included in HTTP POST requests for SSO authentication. The maximum length is 128 characters.

At login, the user enters the actual name value, which is entered into the HTTP POST request and passed on to the authenticating web server.

Password Parameter

The name of the password parameter included in HTTP POST requests for SSO authentication. The maximum length is 128 characters.

At login, the user enters the actual password value, which is entered into the HTTP POST request and passed on to the authenticating web server.

Hidden Values

The hidden parameters included in HTTP POST requests for SSO authentication. They are referred to as hidden parameters because, unlike the username and password, they are not visible to the user.

The maximum length of the hidden parameters is 2048 characters.

Tip You can discover the hidden parameters that the authenticating web server expects in POST requests by using an HTTP header analyzer on a form received from the web server.

Authentication Cookie Name

The name of the authentication cookie used for SSO by the security appliance. The maximum length is 128 characters.

If SSO authentication succeeds, the authenticating web server passes this authentication cookie to the client browser. The client browser then authenticates to other web servers in the SSO domain by presenting this cookie.


Add and Edit LDAP Attribute Map Dialog Boxes

Use the Add and Edit LDAP (Lightweight Directory Access Protocol) Attribute Map dialog boxes to populate the attribute map with name mappings that translate Cisco LDAP attribute names to custom, user-defined 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 LDAP support on ASA, PIX, and FWSM devices, see Additional AAA Support on ASA, PIX, and FWSM Devices.

Navigation Path

Select Manage > Policy Objects, then select LDAP Attribute Map from the Object Type selector. Right-click inside the table and select New Object, or right-click a row and select Edit Object.

Related Topics

Creating AAA Server Objects

AAA Server Dialog Box—LDAP Settings

Field Reference

Table 6-15 Add and Edit LDAP Attribute Map Dialog Boxes 

Element
Description

Name

The object name, which can be up to 128 characters. Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Attribute Map table

The table shows the mapped values. Each entry shows the customer map name, Cisco map name, and the attribute mapping of customer name to Cisco name.

To add a mapping, click the Add Row button to open the Add and Edit LDAP Attribute Map Value Dialog Boxes.

To edit a mapping, select it and click the Edit Row button.

To delete a mapping, select it and click the Delete Row button.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


Add and Edit LDAP Attribute Map Value Dialog Boxes

Use the Add and Edit LDAP Attribute Map Value dialog boxes to populate the attribute map with value mappings that apply user-defined attribute values to the custom attribute name and to the matching Cisco attribute name and value.

Navigation Path

From the Add and Edit LDAP Attribute Map Dialog Boxes, click the Add Row button to add a new mapping, or select a row and click the Edit Row button.

Field Reference

Table 6-16 Add and Edit LDAP Attribute Map Value Dialog Boxes 

Element
Description

Customer Map Name

The name of your attribute map that relates to the Cisco map.

Cisco Map Name

The Cisco attribute map name you want to map to the customer map name.

Customer to Cisco Map Value table

The mappings of customer names to Cisco names.

To add a mapping, click the Add Row button to open the Add and Edit Map Value Dialog Boxes.

To edit a mapping, select it and click the Edit Row button.

To delete a mapping, select it and click the Delete Row button.


Add and Edit Map Value Dialog Boxes

Use the Add and Edit Map Value dialog boxes to map a customer LDAP attribute value to a Cisco map value. Enter the value from your LDAP map that you want to equate with a Cisco value.

Navigation Path

From the Add and Edit LDAP Attribute Map Value Dialog Boxes, click the Add Row button to add a new mapping, or select a row and click the Edit Row button.

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.


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.


Related Topics

Creating Policy Objects

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Understanding AAA Server and Server Group Objects


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

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

Step 3 Right-click inside the work area, then select New Object to open the AAA Server Group Dialog Box.

Step 4 Enter a name for the object. The maximum name length is 16 characters if you plan to use this object with ASA, PIX, or FWSM 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 Select the protocol to be used by the servers in the group.

Step 6 Enter the names of the AAA server policy objects that define the AAA servers to include in the group. Click Select to select the objects from a list filtered by the protocol you selected. You can also create new AAA server objects from the selection list. Separate multiple objects with commas.

Step 7 Configure the additional options that you want:

Make this Group the Default AAA Server Group—For IOS devices only, whether you are using this group as the default group. Use this option if you intend to have a single global server group for this protocol for all policies requiring AAA. For more information, see Default AAA Server Groups and IOS Devices.

ASA, PIX, FWSM devices—Select options for how to handle AAA servers that stop responding, and for how to send accounting messages. For more information, see AAA Server Group Dialog Box.

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 Policy Object to Be Overridden.

Step 10 Click OK to save the object.


AAA Server Group Dialog Box

Use the AAA Server Group dialog box to create, copy, and edit AAA server groups. When defining a policy that uses a AAA server for authentication, authorization, or accounting, you select the server by selecting the server group to which the server belongs.

Navigation Path

Select Manage > Policy Objects, then select AAA Server Groups from the Object Type Selector. Right-click inside the work area and select New Object or right-click a row and select Edit Object.

Related Topics

Creating AAA Server Group Objects

Understanding AAA Server and Server Group Objects

Creating Policy Objects

Add or Edit AAA Server Dialog Box

Policy Object Manager Window

Field Reference

Table 6-17 AAA Server Group Dialog Box 

Element
Description

Name

The object name (up to 16 characters when using this object with firewall devices; up to 128 characters for Cisco IOS routers). Object names are not case-sensitive. Spaces are not supported.

Consider the following important points:

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

If you define this AAA server group as the RADIUS or TACACS+ default group, any name you define here is automatically replaced in the device configuration by the default name (RADIUS or TACACS+) upon deployment.

Description

An optional description of the object.

Protocol

The protocol used by the AAA servers in the group. For more information about these options, see Supported AAA Server Types and Additional AAA Support on ASA, PIX, and FWSM Devices.

AAA Servers

The AAA server policy objects that comprise the server group. Enter the names of the objects or click Select to select them from a list that is filtered to show only those AAA server objects that use the selected protocol. Separate multiple objects with commas. You can also create new objects from the selection list.

Make this Group the Default AAA Server Group (IOS)

(IOS devices only.)

Whether to designate this AAA server group as the default group for the RADIUS or TACACS+ protocol. Select this option if you intend to use a single global group for the selected protocol for all policies on a specific device requiring AAA.

Do not select this option if you intend to create multiple RADIUS or TACACS+ AAA server groups. Multiple groups can be used to separate different AAA functions (for example, use one group for authentication and a different group for authorization) or to separate different customers in a VRF environment.

Note When you discover an IOS router, any AAA servers in the device configuration that are not members of a AAA server group are placed in special groups called CSM-rad-grp (for RADIUS) and CSM-tac-grp (for TACACS+), both of which are marked as default groups. These two groups are created solely to enable Security Manager to manage these servers. During deployment, the AAA servers in these special groups are deployed back to the device as individual servers. For more information, see Default AAA Server Groups and IOS Devices.

Max Failed Attempts

(PIX, ASA, FWSM devices only.)

The number of connection attempts that can fail before an unresponsive AAA server in the group is deactivated.

Values range from 1 to 5.

Reactivation Mode

(PIX, ASA, FWSM devices only.)

The method to use when reactivating failed AAA servers in the group:

Depletion—Reactivate failed servers only after all of the servers in the group fail. This is the default.

Timed—Reactivate failed servers after 30 seconds of downtime.

Note You must use the Timed option when using Simultaneous as the Group Accounting Mode.

Reactivation Deadtime

(PIX, ASA, FWSM devices only.)

When you select Depletion as the reactivation mode, the number of minutes that should elapse between the deactivation of the last server in the group and the reactivation of all the servers in the group. Values range from 0 to 1440 minutes (24 hours).

Group Accounting Mode

(PIX, ASA, FWSM devices only.)

When using the RADIUS or TACACS+ protocols, the method for sending accounting messages to the AAA servers in the group:

Simultaneous—Accounting messages are sent to all servers in the group simultaneously.

Note If you select this option, you must select Timed as the Reactivation Mode.

Single—Accounting messages are sent to a single server in the group. This is the default.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this 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.

For reference information about the dialog boxes used with these objects, see Add or Edit Access List Dialog Boxes.

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 6-18:

Table 6-18 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

Creating Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Creating Policy Objects

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

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

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.

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

Creating Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Creating Policy Objects

Understanding Network/Host Objects (IPv4 and IPv6)


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

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

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.

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 6-19 shows examples of Web VPN ACLs.

Table 6-19 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

Creating Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Creating Policy Objects


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

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

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.

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.


Add or Edit Access List Dialog Boxes

Use the Add and Edit Access List dialog boxes to define access control entries (ACEs) for an ACL object. From this page, you can change the order of the ACEs and ACL objects within the table, add or edit ACEs and ACL objects, and delete ACEs and ACL objects.

The title of the dialog box indicates the type of ACL you are creating: Extended, Standard, or Web Type. The dialog boxes are essentially the same, the difference being the columns displayed in the ACE table.

Navigation Path

Select Manage > Policy Objects, then select Access Control Lists from the Object Type selector. Select the tab for the type of ACL object you want to create, and then right-click inside the work area and select New Object or right-click a row and select Edit Object.

Related Topics

Creating Access Control List Objects

Creating Extended Access Control List Objects

Creating Standard Access Control List Objects

Creating Web Access Control List Objects

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

Field Reference

Table 6-20 Add and Edit Access List Dialog Boxes 

Element
Description

Name

The object name, which can be up to 128 characters. Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Access Control Entry table

The access control entries (ACEs) and ACL objects that are part of the ACL. The table displays the name of the entry or object, description, options, services, and other attributes of the entry.

In the Permit column, a green checkmark indicates that the entry permits traffic (typically, the traffic is considered a match for the service you are defining), whereas a red circle with a slash indicates that traffic is denied (typically, the traffic is considered to not match, and the service you are defining is not applied to the denied traffic).

The source and, if applicable, destination addresses can be host IP addresses, network addresses, or network/host policy objects.

To add an ACE, click the Add button and fill in the dialog box for the type of ACL you are creating:

Add and Edit Extended Access Control Entry Dialog Boxes

Add and Edit Standard Access Control Entry Dialog Boxes

Add and Edit Web Access Control Entry Dialog Boxes

To edit an ACE, select it and click the Edit button.

To delete an ACE, select it and click the Delete button.

To change the position of an entry, select it and click the Up/Down arrow buttons as required. Entries are evaluated top to bottom, so correct positioning is crucial for you to get the results you intend.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


Add and Edit Extended Access Control Entry Dialog Boxes

Use the Add or Edit Extended Access Control Entry dialog box to add an access control entry (ACE) or an ACL object to an Extended ACL object.

Navigation Path

From the Add or Edit Access List Dialog Boxes for Extended ACL objects, click the Add button in the ACE table, or select a row and click the Edit button.

Related Topics

Creating Extended Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

Filtering Items in Selectors, page 1-34

Field Reference

Table 6-21 Add and Edit Extended Access Control Entry Dialog Boxes 

Element
Description

Type

The type of entry you are adding. The fields on the dialog box change based on your selection.

Access Control Entry—You want to define an ACE.

ACL Objects—You want to include an existing ACL object. You are presented with a list of available ACL objects. Select the objects you want to include and click the >> button to move them to the list of selected objects. You can remove an object by selecting it and clicking <<. You can also edit objects in the selected objects list.

Action

The action to take on traffic defined in the entry:

Permit—The service associated with this ACL is applied to this traffic. That is, the traffic is permitted to use the service.

Deny—The service associated with this ACL is not applied to this traffic. If there are multiple ACLs configured for a service, denied traffic is typically compared to the next ACL in the list; if it matches no permit entry in any ACL for the service, the service is not applied to the traffic. Whether the traffic is dropped from the network depends on the service.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Source

Destination

The source or destination of the traffic. You can enter more than one value by separating the items with commas.

You can enter any combination of the following address types. For more information, see Specifying IP Addresses During Policy Definition.

Network/host object. Enter the name of the object or click Select to select it from a list. You can also create new network/host objects from the selection list.

Host IP address, for example, 10.10.10.100.

Network address, including subnet mask, in either the format 10.10.10.0/24 or 10.10.10.0/255.255.255.0.

A range of IP addresses, for example, 10.10.10.100-10.10.10.200.

An IP address pattern in the format 10.10.0.10/255.255.0.255, where the mask is a discontiguous bit mask (see Contiguous and Discontiguous Network Masks for IPv4 Addresses).

Services

The services that define the type of traffic to act on. You can enter more than one value by separating the items with commas.

You can enter any combination of service objects and service types (which are typically a protocol and port combination). If you type in a service, you are prompted as you type with valid values. You can select a value from the list and press Enter or Tab.

For complete information on how to specify services, see Understanding and Specifying Services and Service and Port List Objects.

Description

An optional description of the object.

Advanced button

Click this button to define logging options for the entry:

For PIX, ASA, and FWSM devices, you can enable:

Default logging—If a packet is denied, message 106023 is generated. If a packet is permitted, no message is generated.

Per ACE logging—If a packet is denied, message 106100 is generated. You can select the logging severity level for the messages, and the interval (in seconds from 1 to 600) for generating messages.

For IOS devices, when you enable logging, informational messages about packets that match the entry are sent to the console. You can also elect to include the input interface and source MAC address or VC in the logging output.


Add and Edit Standard Access Control Entry Dialog Boxes

Use the Add or Edit Standard Access Control Entry dialog box to add an access control entry (ACE) or an ACL object to a Standard ACL object.

Navigation Path

From the Add or Edit Access List Dialog Boxes for Standard ACL objects, click the Add button in the ACE table, or select a row and click the Edit button.

Related Topics

Creating Standard Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

Filtering Items in Selectors, page 1-34

Field Reference

Table 6-22 Add and Edit Standard Access Control Entry Dialog Boxes 

Element
Description

Type

The type of entry you are adding. The fields on the dialog box change based on your selection.

Access Control Entry—You want to define an ACE.

ACL Objects—You want to include an existing ACL object. You are presented with a list of available ACL objects. Select the objects you want to include and click the >> button to move them to the list of selected objects. You can remove an object by selecting it and clicking <<. You can also edit objects in the selected objects list.

Action

The action to take on traffic defined in the entry:

Permit—The service associated with this ACL is applied to this traffic. That is, the traffic is permitted to use the service.

Deny—The service associated with this ACL is not applied to this traffic. If there are multiple ACLs configured for a service, denied traffic is typically compared to the next ACL in the list; if it matches no permit entry in any ACL for the service, the service is not applied to the traffic. Whether the traffic is dropped from the network depends on the service.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Source

The source of the traffic. You can enter more than one value by separating the items with commas.

You can enter any combination of the following address types. For more information, see Specifying IP Addresses During Policy Definition.

Network/host object. Enter the name of the object or click Select to select it from a list. You can also create new network/host objects from the selection list.

Host IP address, for example, 10.10.10.100.

Network address, including subnet mask, in either the format 10.10.10.0/24 or 10.10.10.0/255.255.255.0.

A range of IP addresses, for example, 10.10.10.100-10.10.10.200.

An IP address pattern in the format 10.10.0.10/255.255.0.255, where the mask is a discontiguous bit mask (see Contiguous and Discontiguous Network Masks for IPv4 Addresses).

Description

An optional description of the object.

Log Option

Whether to create log entries when traffic meets the entry criteria. ACL logging generates syslog message 106023 for denied packets. Deny packets must be present to log denied packets.


Add and Edit Web Access Control Entry Dialog Boxes

Use the Add or Edit Web Access Control Entry dialog box to add an access control entry (ACE) or an ACL object to a Web Type ACL object.

Navigation Path

From the Add or Edit Access List Dialog Boxes for Web Type ACL objects, click the Add button in the ACE table, or select a row and click the Edit button.

Related Topics

Creating Web Access Control List Objects

Understanding Access Rule Address Requirements and How Rules Are Deployed, page 14-5

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

Filtering Items in Selectors, page 1-34

Field Reference

Table 6-23 Add and Edit Web Access Control Entry Dialog Boxes 

Element
Description

Type

The type of entry you are adding. The fields on the dialog box change based on your selection.

Access Control Entry—You want to define an ACE.

ACL Objects—You want to include an existing ACL object. You are presented with a list of available ACL objects. Select the objects you want to include and click the >> button to move them to the list of selected objects. You can remove an object by selecting it and clicking <<. You can also edit objects in the selected objects list.

Action

The action to take on traffic defined in the entry:

Permit—The service associated with this ACL is applied to this traffic. That is, the traffic is permitted to use the service.

Deny—The service associated with this ACL is not applied to this traffic. If there are multiple ACLs configured for a service, denied traffic is typically compared to the next ACL in the list; if it matches no permit entry in any ACL for the service, the service is not applied to the traffic. Whether the traffic is dropped from the network depends on the service.

Filter Destination

Whether the entry specifies a network filter (host or network address) or a URL filter (web site address). Your selection changes the fields on the dialog box. The fields are described below.

Destination

(Network Filter only.)

The destination of the traffic. You can enter more than one value by separating the items with commas.

You can enter any combination of the following address types. For more information, see Specifying IP Addresses During Policy Definition.

Network/host object. Enter the name of the object or click Select to select it from a list. You can also create new network/host objects from the selection list.

Host IP address, for example, 10.10.10.100.

Network address, including subnet mask, in either the format 10.10.10.0/24 or 10.10.10.0/255.255.255.0.

A range of IP addresses, for example, 10.10.10.100-10.10.10.200.

An IP address pattern in the format 10.10.0.10/255.255.0.255, where the mask is a discontiguous bit mask (see Contiguous and Discontiguous Network Masks for IPv4 Addresses).

Ports

(Network Filter only.)

The port numbers or port list policy objects that define the port the traffic uses, if you want to use port identification. You can enter more than one value by separating the items with commas.

You can enter any combination of the following types:

Port list object. Enter the name of the object or click Select to select it from a list. You can also create new port list objects from the selection list.

Port number, for example, 80.

A range of ports, for example, 80-90.

URL Filter

(URL Filter only.)

The Universal Resource Locator (URL), or web address, of the traffic. You can use an asterisk as a match-all wildcard. For example, http://*.cisco.com matches all servers on the cisco.com network. You can specify any valid URL.

Logging

The type of logging to use for this entry:

Select Log Disabled to not create log entries.

Select Default to use the default settings on the device.

All other available options enable logging and identify the log level that will be used.

Logging Interval

The interval of time, in seconds, used to generate logging messages, from 1 to 600. The default is 300. You can modify this field only if you select a logging level in the Logging field.

Time Range

The time range policy object that defines the time range associated with the entry. The time range defines the access to the device and relies on the device's system clock. For more information, see Configuring Time Range Objects.

Enter the name of the object or click Select to select it from a list. You can also create new time range objects from the selection list.

Note Time range is not supported on FWSM 2.x or PIX 6.3 devices.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Description

An optional description of the object.


Configuring Time Range Objects

Use the Add or Edit Time Range dialog box to create, edit, or copy a time range object.

You can create time range objects for use when creating time-based ACLs and some firewall rules. While similar to extended ACLs in function, time-based ACLs allow for access control based on time considerations. The time range applies to specific rules, and makes those rules active for the specific time period defined in the range. For example, you can implement a rule for typical work hours to allow or prevent certain types of access.

You can also use time range objects when defining ASA user groups to restrict VPN access to specific times during the week. For more information, see ASA Group Policies SSL VPN Settings, page 30-14.

Time range objects can rely on the device's system clock, but they work best when using Network Time Protocol (NTP) synchronization.

Navigation Path

Select Manage > Policy Objects, then select Time Ranges from the Object Type Selector. Right-click inside the work area and select New Object or right-click a row and select Edit Object.

Field Reference

Table 6-24 Time Range Dialog Box 

Element
Description

Name

The object name, which can be up to 128 characters. Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object (up to 1024 characters).

Start Time

End Time

The overall starting and ending time for the time range object:

Start Now—Defines the time of deployment as the start time.

Never End—Defines no end time for the range.

Start At, End At—Defines a specific start or end date and time. Click the calendar icon to display a tool for selecting the date. Enter the time in the Time field using the 24-hour clock format, HH:MM.

Recurring Ranges

Recurring time periods that happen within the overall start and end times, if any. For example, if you want to create a time range object that defines work hours, you could select Start Now and Never End for the overall range, and enter a recurring range of weekdays from 08:00 to 18:00 hours.

To add a range, click the New Recurring Range button and fill in the Recurring Ranges Dialog Box.

To edit a range, select it and click the Edit Recurring Range button.

To delete a range, select it and click the Delete Recurring Range button.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.


Recurring Ranges Dialog Box

Use the Recurring Ranges dialog box to add or edit recurring time intervals that are defined as part of a time range object. You can define as many recurring ranges as required.

Navigation Path

Go to the Add or Edit Time Range dialog box and click the New Recurring Range button under Recurring Ranges, or select a range and click Edit Recurring Range. See Configuring Time Range Objects.

Field Reference

Table 6-25 Recurring Ranges Dialog Box 

Element
Description

Specify days of the week and times during which this recurring range will be active

Defines a recurring range that is based on specific days and times of the week. You can select from:

Every day

Weekdays

Weekends

On these days of the week—Select the specific days to include in the range.

Also select the starting and ending time during the day. The default is all day.

Specify a weekly interval during which this recurring range will be active

Defines a recurring range for every week. Select the starting and ending day and time. For example, you can start the weekly period on Sunday and end it on Thursday.


Understanding Interface Role Objects

Interface Role objects have the following uses:

Specifying multiple interfaces— Interface role objects allow you to apply policies to specific interfaces on multiple devices without having to manually define the names 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.

Zones—You use interface role objects to define the zones in a zone-based firewall rules policy.

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 you apply 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—Includes every interface defined on a device.

Internal—Includes only specific interfaces that are meant to be on the inside of a network. See the object definition for a list.

External—Includes only specific interfaces that are meant to be on the outside of a network. See the object definition for a list.

Self—Does not include any interfaces. The Self interface role is specific to zone-based firewall rules policies. The Self zone is the router itself. You can use it to identify traffic originating from the router, or traffic directed to the router. It does not include traffic passing through the router.

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

Creating Interface Role Objects

Specifying Interfaces During Policy Definition

Using Interface Roles When a Single Interface Specification is Allowed

Handling Name Conflicts between Interfaces and Interface Roles

Creating Interface Role Objects

You can create interface role objects that represent one or more interfaces on devices. You can then use these roles when you define policies that require interfaces or zones. 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.


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.


Related Topics

Creating Policy Objects

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Using Interface Roles When a Single Interface Specification is Allowed

Managing Object Overrides


Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager Window).

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. Names can be up to 128 characters, descriptions up to 1024.

Step 5 Enter one or more naming patterns for the interface role object. The names are the complete or partial names of interfaces, subinterfaces, and other virtual interfaces. Separate multiple name patterns with commas.

You can use these wildcards to create name patterns that apply to multiple interfaces:

Use a period (.) as a wildcard for a single character.

To use a period as part of the pattern itself (for example, when defining subinterfaces), enter a backslash (\) before the period.

Use an asterisk (*) as a wildcard for one or more characters at the end of the interface pattern. For example, FastEthernet* would include interfaces named FastEthernet0 and FastEthernet1.

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.

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 Policy Object to Be Overridden.

Step 8 Click OK to save the object.


Interface Role Dialog Box

Use the Interface Role dialog box to create, copy, or edit an interface role object. Interface Role objects have the following uses:

Specifying multiple interfaces— Interface role objects allow you to apply policies to specific interfaces on multiple devices without having to manually define the names of each interface.

Zones—You use interface role objects to define the zones in a zone-based firewall rules policy.

Navigation Path

Select Manage > Policy Objects, then select Interface Roles from the Object Type Selector. Right-click inside the work area and select New Object or right-click a row and select Edit Object.

Related Topics

Creating Policy Objects

Creating Interface Role Objects

Using Interface Roles When a Single Interface Specification is Allowed

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Understanding the Zone-based Firewall Rules, page 18-3

Policy Object Manager Window

Field Reference

Table 6-26 Interface Role Dialog Box 

Element
Description

Name

The name of the policy object. A maximum of 128 characters is allowed.

Description

A description of the policy object. A maximum of 1024 characters is allowed.

Interface Name Patterns

The names to include in this interface role. The names are the complete or partial names of interfaces, subinterfaces, and other virtual interfaces. Separate multiple name patterns with commas.

You can use these wildcards to create name patterns that apply to multiple interfaces:

Use a period (.) as a wildcard for a single character.

To use a period as part of the pattern itself (for example, when defining subinterfaces), enter a backslash (\) before the period.

Use an asterisk (*) as a wildcard for one or more characters at the end of the interface pattern. For example, FastEthernet* would include interfaces named FastEthernet0 and FastEthernet1.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


Specifying Interfaces During Policy Definition

When you configure policies that require you to identify an interface, you have several options for specifying the interface:

Enter the name of the interface manually, for example, Ethernet0.

To manually specify a subinterface as part of a policy definition, you must enter a backslash (\) before the period. For example, Ethernet0\.1.

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. If you enter Ethernet1/1.0 instead, the name matches interfaces named Ethernet1/1.0 and Ethernet1/1/0, because the period on its own is treated as a wildcard.

Enter the name of an interface role manually. For more information about interface roles, see Understanding Interface Role Objects.

Select an interface or interface role from a list. By clicking Select next to the Interfaces field, you are prompted with a list of valid interface names and interface roles. Subinterfaces appear with a backslash before the period in their names.

By selecting from a list, you can ensure that your entry is valid. For more information, see Selecting Objects for Policies.

When a policy allows multiple interfaces, separate entries with commas.

In policies and object selectors, icons distinguish between interfaces and interface roles. If you create interface roles with the same name as interfaces, be careful to select exactly what you want. Table 6-27 explains the icons.

Table 6-27 Icons for Interfaces and Interface Roles 

Type
Icon

Interface

Interface role

If you can edit the role, a pencil image overlays the icon.

Global "interface" on ASA 8.3+ devices, used for rules created as global instead of interface-specific.


Related Topics

Basic Interface Settings on Cisco IOS Routers, page 56-1

Configuring Firewall Device Interfaces, page 42-2

Understanding Interface Role Objects

Creating Interface Role Objects

Using Interface Roles When a Single Interface Specification is Allowed

Using Interface Roles When a Single Interface Specification is Allowed

Interface roles objects can match a variable number of actual interfaces defined on a device depending on how you define the role. Thus, for a particular device, and interface role might match zero, one, or more than one interface. When you use an interface role in a policy, Security Manager converts the role to commands that configure all interfaces defined on the device that match the role.

Many policies, however, require that you specify a single interface name. If you use an interface role in a situation where the policy allows a single interface name, you should define the interface role so that it matches a single interface. If you use an interface role that matches two or more interfaces on the device, Security Manager selects the first interface on the device that matches the role, which might not be the interface you desire (or that will work properly).

Related Topics

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Creating Interface Role Objects

Handling Name Conflicts between Interfaces and Interface Roles

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, or in some cases, OK to update the policy.

When this sequence of events occurs, the Interface Name Conflict dialog box opens automatically so that you can select whether you want to specify the interface or the interface role. The dialog box lists only those names for which there are conflicts.

Related Topics

Specifying Interfaces During Policy Definition

Understanding Interface Role Objects

Understanding Map Objects

The objects in the Maps folder in the Policy Object Manager allow you to configure class, parameter, and policy maps for inspection rules, zone-based firewall rules, or IPS, QoS and connection rules policies. The types of maps you can use with these policies depends on the operating system running on the device as well as the specific version number, so typically it is best to configure the maps when you are configuring the policies.


Tip Devices enforce unique names for all configured maps. For example, you cannot use the same name for an FTP and DNS class map on the same device. If you select maps with the same name for a device, Security Manager automatically adds a numerical suffix to the duplicate names, for example, dnsmap_1.


The Maps folder contains the following folders. Subfolders organize the maps based on whether they are used for inspection or web content filtering.

Class Maps—Layer 7 class maps used for identifying traffic that you want to act on.

Parameter Maps—Parameter maps that configure settings used in zone-based firewall rules policies or other maps.

Policy Maps—Layer 7 policy maps used for identifying the action to take on selected traffic.

Also included in the Maps folder are entries for TCP Map objects (a Layer 4 object), Regular Expression objects, and Regular Expression Group objects.

The following sections describe the different types of maps in more detail.

Class Maps

Class maps are subordinate to policy maps. You cannot specify a class map directly in a device policy. Instead, you create a policy map to incorporate the class map. The class map itself defines the match conditions for the traffic that you want to target in an inspection rule or zone-based firewall rule.

ASA/PIX 7.2 and higher, and FWSM devices—You can create class maps for the inspection of DNS, FTP, HTTP, IM, and SIP traffic. You also have the option of defining the traffic match directly in the policy map object, but if you create separate class maps, you can reuse them in more than one policy map.

IOS 12.4(6)T and higher devices—You can create class maps for the inspection of IM applications (AOL, ICQ, MSN Messenger, Windows Messenger, and Yahoo Messenger), P2P applications (eDonkey, FastTrack, Gnutella, Kazaa2), H.323, HTTP, IMAP, POP3, SIP, SMTP, Sun RPC. You can also create class maps for filtering web content using the Local, N2H2, Trend, and Websense objects.

Unlike the class maps used for ASA/PIX/FWSM, you must create separate class maps and refer to them from the related policy maps. You can use these policy maps in zone-based firewall inspection or content filtering rules. For more information, see these topics:

Configuring Inspection Maps for Zone-based Firewall Policies, page 18-14

Configuring Content Filtering Maps for Zone-based Firewall Policies, page 18-34

To create class maps, see these topics:

Configuring Class Maps for Inspection Policies, page 15-23

Configuring Class Maps for Zone-Based Firewall Policies, page 18-16

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

Configuring Regular Expressions for Inspection Maps, page 15-77

Configuring Regular Expression Groups, page 15-76

Parameter Maps

Parameter maps define settings that you can use in zone-based firewall inspection or content filtering rules, or in other policy map objects.

Inspection—You can create Inspection Parameter maps for general zone-based firewall rule parameters, or Protocol Info Parameter maps for use with IM application inspection.

Content Filtering—You can create the following parameter maps to define web content filtering: Local, N2H2, Trend, URL Filter, URLF Glob, Websense.

Policy Maps

You can configure policy maps to alter the default actions of inspection or to configure web content filtering in zone-based firewall settings policies. Policy maps typically apply to applications that require special handling, perhaps due to embedded IP address information or the fact that the traffic opens secondary channels on dynamically assigned ports.

The policy map identifies the action to take on traffic that matches the conditions identified in the map. For most policy maps, you can specify traffic match conditions by referring to a class map. However, some policy maps require that you specify the match criteria within the policy map.

You can configure these types of policy maps:

Inspection Rules—When configuring inspection rules, you can use Security Manager to create policy map objects for the following applications: DCE/RPC, DNS, ESMTP, FTP, GTP, H.323, HTTP, IM, IP options, IPsec, NetBIOS, SIP, Skinny, and SNMP. for more information, see Configuring Protocols and Maps for Inspection, page 15-20.

Zone-Based Firewall Inspection Rules—When configuring zone-based firewall inspection rules, you can use Security Manager to create policy map objects for the following applications: H.323, HTTP, IM (includes AOL, ICQ, MSN Messenger, Windows Messenger, and Yahoo Messenger), IMAP, P2P (includes eDonkey, FastTrack, Gnutella, Kazaa2), POP3, SIP, SMTP, Sun RPC. For more information, see Configuring Inspection Maps for Zone-based Firewall Policies, page 18-14.

Zone-Based Firewall Content Filtering Rules—When configuring zone-based firewall content filtering rules, you can use Security Manager to create Web Filter policy maps. You can also configure HTTP policy maps to inspect HTTP traffic. For more information, see Configuring Content Filtering Maps for Zone-based Firewall Policies, page 18-34.

IPS, QoS and Connection Rules—When configuring this service policy, which is specific to PIX 7.x+ and ASA devices, you can customize TCP inspection using a TCP map. For more information, see Configuring TCP Maps, page 53-17 and Chapter 53, "Configuring Service Policy Rules on Firewall Devices".

Understanding Network/Host Objects (IPv4 and IPv6)

Network/host objects are logical collections of IP addresses that represent networks, hosts, or both. There are separate objects for IPv4 and IPv6 addresses: the IPv4 object is simply called "networks/hosts," whereas the IPv6 object is called "network/hosts-IPv6." Except for the address notation, these objects are functionally identical, and in many instances the name network/host applies to either type of object. Note that specific policies require the selection of one type of object over the other, depending on the type of address expected in the policy.

When you create a network/host object, you must select the type of object, which defines and limits the type of addresses the object can contain:

Group—You can include combinations of any of the following types of addresses:

Networks or subnets, specified by IP addresses and subnet masks (IPv4) or prefixes and prefix lengths (IPv6).

Ranges of IPv4 or IPv6 network addresses.

Individual hosts, specified by IPv4 or IPv6 addresses.

Other network/host objects, specified by selecting from a list of existing objects. Your selection is restricted to the same type of object, for example, you can incorporate IPv6 objects only in other IPv6 objects.

Host—This object can contain a single host address, such as 10.100.10.10 (for IPv4) or 2001:DB8::0DB8:800:200C:417A (for IPv6).

Network—This object can contain a single IPv4 network address and subnet mask, such as 10.100.10.0/24, or a single IPv6 prefix and prefix length, such as 2001:DB8::/32.

Address Range—This object can contain a single range of IPv4 addresses, such as 10.100.10.1-10.100.10.255. You cannot create an Address Range object for IPv6 addresses.

Network/host group 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 other types of network/host objects—host, network, and address range—have special uses when used in policies for an ASA 8.3+ device. On these devices, you can configure object NAT rules in the policy object itself. If you use the object on other types of device, this NAT configuration is ignored. The IPv6 objects do not support NAT configuration regardless of the target device platform.

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

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Creating IPv4 or IPv6 Network/Host Objects

Using Unspecified IPv4 or IPv6 Network/Host Objects

Specifying IP Addresses During Policy Definition

Specifying IPv6 Addresses During Policy Definition

Contiguous and Discontiguous Network Masks for IPv4 Addresses

A network mask determines which portion of an IPv4 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. 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.

The following table shows different methods of representing commonly used standard network masks:

Table 6-28 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 contiguous format. For example, 10.0.1.1/255.0.255.255 indicates that you want to match an address that matches octets 1, 3, and 4 exactly, but any value in octet 2 is accepted.

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

Creating IPv4 or IPv6 Network/Host Objects

Specifying IP Addresses During Policy Definition

Using Unspecified IPv4 or IPv6 Network/Host Objects

Understanding Network/Host Objects (IPv4 and IPv6)

Creating IPv4 or IPv6 Network/Host Objects

You can create network/host objects to represent networks or individual hosts. There are separate types of network/host object for IPv4 and IPv6 addresses; the object for IPv6 is explicitly called network/host-IPv6.

When you create a network/host object, you must select the type of object (group, host, network, address range). Once created, you cannot change the object type.


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.


Related Topics

Understanding Network/Host Objects (IPv4 and IPv6)

Creating Policy Objects

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Specifying IP Addresses During Policy Definition

Specifying IPv6 Addresses During Policy Definition

Using Unspecified IPv4 or IPv6 Network/Host Objects

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups


Step 1 Select Manage > Policy Objects to open the Policy Object Manager Window.

Step 2 Select either Networks/Hosts or Networks/Hosts-IPv6 from the Object Type selector.

Step 3 Right-click in the work area, then select New Object, and select one of the following types of network/host object, to open the Add or Edit Network/Host Dialog Box (IPv4 or IPv6):

Group—To create an object that has one or more entry. You can include any combination of networks, hosts, address ranges, or other network/host objects.

Host—To create an object with a single host address, such as 10.100.10.10 (IPv4) or 2001:DB8::12ab:5689 (IPv6).

Network—To create an object with a single network address, such as 10.100.10.0/24 (IPv4) or 2001:DB8::/32 (IPv6).

Address Range—To create an object with a single range of addresses, such as 10.100.10.1-10.100.10.255. Address range objects are available for IPv4 only.


Tip Host, network, and address range objects for IPv4 also allow you to configure object NAT rules for ASA 8.3+ devices. Any NAT configuration is ignored for other devices. NAT configuration does not apply to IPv6 objects.


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

Step 5 Depending on the object type you selected, enter the required address information.

Group—The Members in Group list shows the networks, hosts, address ranges, and other network/host objects that are included in the object. To populate the list, do any combination of the following:

Select the option for Existing Network/Host objects, then select the desired object and click the Add >> button between the lists.

Select the option for Enter Address Information and type in a valid address of the appropriate type, either IPv4 or IPv6, then click the Add >> button between the lists. Separate multiple addresses with commas; they are added as separate lines in the members list.

For IPv4 objects, you can include host addresses, network addresses (with subnet masks entered after a / character, such as 10.100.10.0/24), or a range of addresses (separate the starting and ending address with a hyphen, "-", and optionally include a subnet mask). For more information on supported formats, see Specifying IP Addresses During Policy Definition.

For IPv6 objects, you can include host addresses, network addresses (with prefixes entered after a / character, such as 2001:DB8::/32), or a range of addresses (such as 2001:DB8::1-2001:DB8::100). For more information on supported formats, see Specifying IPv6 Addresses During Policy Definition.

To remove an item from the object, select it in the Members list and click the << Remove button between the lists.

Host—Enter a single IPv4 or IPv6 address.

Network—Enter the network address and subnet mask (IPv4) or IPv6 address prefix and prefix length (IPv6). If the correct subnet mask is not included in the Subnet Mask list, type it into the field; you are always required to type in the IPv6 prefix length.

Address Range—Enter the first and last address that define the range. You cannot enter the same address in each field.


Tip You can leave these fields blank if you want to create an object that must be overridden for every device that uses it. You must also select Allow Value Override per Device. For more information, see Using Unspecified IPv4 or IPv6 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 Policy Object to Be Overridden.


Tip If you configure a NAT rule on the NAT tab, you must select this option. All object NAT rules are considered device overrides.


Step 8 Click OK to save the object.


Add or Edit Network/Host Dialog Box (IPv4 or IPv6)

Use the Add or Edit Network/Host dialog box to view, create, or edit network/host objects. When creating IPv6 objects, the dialog box is called IPv6 Network/Host. The IPv4 and IPv6 objects are exclusive: you cannot mix address types in a single object.

The content of the dialog box (and its name) also differs based on the type of network/host object you are creating: group, host, network, or address range. The group type allows you to enter multiple values, so you can have a collection of networks, hosts, or other network/host objects, whereas the other types allow single values only. The address range type is available for IPv4 only.

When you create IPv4 host, network, or address range objects for use on ASA 8.3+ devices, you can also configure object NAT rules on the NAT tab. For reference information on the NAT tab, see Add or Edit Network/Host Dialog Box: NAT Tab, page 20-39. NAT configuration does not apply to IPv6 objects.

You can create an object with no addresses. For these objects, you must also select Allow Value Override per Device and create overrides for every device that uses the object. For more information about using unspecified addresses, see Using Unspecified IPv4 or IPv6 Network/Host Objects.

Navigation Path

Select Manage > Policy Objects, then select either Networks/Hosts or Networks/Hosts-IPv6 from the Object Type Selector. Right-click inside the work area and select New Object (and select an object type) or right-click a row and select Edit Object.

Related Topics

Creating IPv4 or IPv6 Network/Host Objects

Understanding Network/Host Objects (IPv4 and IPv6)

Policy Object Manager Window

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups

Filtering Items in Selectors, page 1-34

Field Reference

Table 6-29 Network/Host Dialog Box General Tab (IPv4 or IPv6) 

Element
Description

Name

The object name (up to 64 characters). Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Existing Networks/Hosts

Existing Networks/Hosts-IPv6

Enter IPv4 Address Information

Enter IPv6 Address Information

Members In Group list

(Group objects only; IPv4 and IPv6.)

The Members In Group list shows the networks, hosts, or network/host objects that are included in the object. These can be exclusively IPv4 or IPv6 addresses, but not a mixture. You can select a member of the list that is a network/host object and click the Edit button below the list to change its definition.

To populate the list, do any combination of the following:

Select the option for Existing Network/Host objects, then select the desired object and click the Add >> button between the lists. You can create new objects in the list by clicking the Create (+) button below it, or modify an object by selecting it and clicking the Edit button.

Select the option for Enter Address Information and type in an address of the appropriate type, either IPv4 or IPv6, then click the Add >> button between the lists. Separate multiple addresses with commas; they are added as separate lines in the members list.

For IPv4 objects, you can include host addresses, network addresses (with subnet masks entered after a / character, such as 10.100.10.0/24), or a range of addresses (separate the starting and ending address with a hyphen, "-", and optionally include a subnet mask). For more information on supported formats, see Specifying IP Addresses During Policy Definition.

For IPv6 objects, you can include host addresses, network addresses (with prefixes entered after a / character, such as 2001:DB8::/32), or a range of addresses (such as 2001:DB8::1-2001:DB8::100). For more information on supported formats, see Specifying IPv6 Addresses During Policy Definition.

To remove an item from the object, select it in the Members list and click the << Remove button between the lists.

IP Address

IPv6 Address

(Host objects only; IPv4 and IPv6.)

The IPv4 or IPv6 address of the single host to include in the object.

Start IP Address

End IP Address

(Address range objects only; IPv4 only.)

The first and last IP address that define a range of addresses. The start and end addresses must be different, with the start being lower than the end.

IP Address

Subnet Mask

(Network objects only; IPv4 only.)

The address that represents the network, for example, 10.100.10.0/24.

The Subnet Mask field includes a list of common masks (in CIDR format), but you can type in any mask in either CIDR format (for example, /24) or dotted decimal format (for example, 255.255.255.0).

IPv6 Address

Prefix Length

(Network objects only; IPv6 only.)

The IPv6 address prefix and prefix length that represents the network, for example, 2001:DB8::/32.

Enter the address prefix and the prefix length in the separate fields.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

Tip If you configure NAT for host, address range, or network objects, you must select this option. The NAT configuration is created as a device override and is not kept in the object.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


Using Unspecified IPv4 or IPv6 Network/Host Objects

When you define network/host objects, whether IPv4 or IPv6, you can leave the address fields blank, thereby creating a network/host object with an unspecified value. Network/host objects with unspecified values require that you create overrides for 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.

Related Topics

Creating IPv4 or IPv6 Network/Host Objects

Understanding Policy Object Overrides for Individual Devices

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Specifying IP Addresses During Policy Definition

Specifying IPv6 Addresses During Policy Definition

Understanding Network/Host Objects (IPv4 and IPv6)


Step 1 Create a network/host object, making sure to:

Leave the address fields blank (for example, the Members in Group, IP Address, Subnet Mask, Start/End IP Address, IPv6 Address, or Prefix Length fields).

Select the Allow Value Override per Device check box.

For more information, see Creating IPv4 or IPv6 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 or Network/Hosts-IPv6 pages, double-click the green checkmark to open the Policy Object Overrides Window.

b. Click the Create Override button and select the devices on which you want to create overrides, then define a value in the address field. At this point, this override value applies to all the selected devices. For more information, see Creating or Editing Object Overrides for Multiple Devices At A Time.

c. Double-click each device in the Policy Object Overrides dialog box, then modify the address field for the value required by that device.

Step 3 Define the policy that requires the 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 5-37 and Modifying Shared Policy Assignments in Device View or the Site-to-Site VPN Manager, page 5-45.

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 5-51.


Note You can create a network/host group 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.



Specifying IP Addresses During Policy Definition

Many policies and policy objects require that you enter an IP address for a host or network. For some policies or objects, you must enter just a host, or just a network. For other policies or objects, you can enter some combination of hosts and networks. You are prevented from entering or selecting addresses that are not appropriate for the circumstances.

The following is a description of all acceptable formats that you can use, although a particular policy or object might not allow specific formats (for example, interface roles are allowed as address designations in only a very limited number of policies). If the policy or object allows it, you can enter multiple addresses by separating them with commas.

Network/host object. Enter the name of the object or click Select to select it from a list. You can also create new network/host objects from the selection list.

Host IP address, for example, 10.10.10.100.

Network address, including subnet mask, in either the format 10.10.10.0/24 or 10.10.10.0/255.255.255.0.

A range of IP addresses, for example, 10.10.10.100-10.10.10.200. Separate the beginning and ending addresses with a hyphen. The range does not need to be within a single subnet unless the policy requires it.

You can also include a subnet mask: 10.10.10.100-10.10.10.200/24.

An IP address pattern in the format 10.10.0.10/255.255.0.255, where the mask is a discontiguous bit mask (see Contiguous and Discontiguous Network Masks for IPv4 Addresses).

Interface role object (in rare cases). Enter the name of the object or click Select to select it from a list (you must select Interface Role as the object type). When you use an interface role, the rule behaves as if you supplied the IP address of the selected interface. This is useful for interfaces that get their address through DHCP, because you do not know what IP address will be assigned to the device. For more information, see Understanding Interface Role Objects.

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 when 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.

Related Topics

Creating IPv4 or IPv6 Network/Host Objects

Contiguous and Discontiguous Network Masks for IPv4 Addresses

Using Unspecified IPv4 or IPv6 Network/Host Objects

Policy Object Manager Window

Understanding Network/Host Objects (IPv4 and IPv6)

Specifying IPv6 Addresses During Policy Definition

You can specify IPv6 addresses in some policies and policy objects, such as IPv6 Access Rules and network/host-IPv6 objects. For some policies or objects, you must enter just a host, or just a network. For other policies or objects, you can enter some combination of hosts and networks. You are prevented from entering or selecting addresses that are not appropriate for the circumstances.

IPv6 addresses are 128-bit identifiers. The IPv6 address consists of eight 16-bit hexadecimal pieces separated by colons, in the format x:x:x:x:x:x:x:x. The following is a description of all acceptable formats that you can use, although a particular policy or object might not allow specific formats (for example, interface roles are allowed as address designations in only a very limited number of policies). If the policy or object allows it, you can enter multiple addresses by separating them with commas.

Network/host-IPv6 object. Enter the name of the object or click Select to select it from a list. You can also create new network/host-IPv6 objects from the selection list.

Host addresses. You can specify host addresses using any of the following formats:

Full address, showing all eight pieces. For example, 2001:DB8:0:0:0DB8:800:200C:417A. It is not necessary to include the leading zeros in an individual field. Security Manager converts the address to compressed format if possible.

Compressed address, where a group of fields is replaced by two colons (::). It is common for IPv6 addresses to contain successive hexadecimal fields of zeros. To make IPv6 addresses less cumbersome, you can use two colons (::) to compress successive hexadecimal fields of zeros at the beginning, middle, or end of an IPv6 address (the colons represent successive hexadecimal fields of zeros). You can use :: at most once in an IPv6 address. For example, 2001:DB8::0DB8:800:200C:417A. The unspecified address, 0:0:0:0:0:0:0:0, can be represented as ::. The loopback address is ::1.

IPv6 representation of an IPv4 address. When dealing in mixed IPv4/IPv6 environments, you can represent the IPv4 addresses in an alternate IPv6 format: x:x:x:x:x:x:d.d.d.d, where the x's are the hexadecimal values of the first 6 fields, and the d's are the IPv4 address with the octets separated by periods. The first 6 fields are either all zeros, ::FFFF, or 2001:DB8::. For example, 0:0:0:0:0:0:10.1.68.3, which in compressed format is ::10.1.68.3, or 0:0:0:0:0:FFFF:10.1.68.3, or 2001:DB8::10.1.68.3.

Network addresses. You can specify a network address by including the prefix length in decimal format in a manner similar to CIDR notation for IPv4, for example, /64. The number specifies the number of the left-most contiguous bit of the address that comprise the prefix. For example, 2001:DB8:0:CD30::/60.


Note You could also enter 2001:DB8:0:CD30::/60 as 2001::CD30:0:0:0:0/60. However, compressing the trailing zeros is the preferred method, and Security Manager will translate the address to 2001:DB8:0:CD30::/60.


Interface role object (in rare cases). Enter the name of the object or click Select to select it from a list (you must select Interface Role as the object type). When you use an interface role, the rule behaves as if you supplied the IP address of the selected interface. This is useful for interfaces that get their address through DHCP, because you do not know what IP address will be assigned to the device. For more information, see Understanding Interface Role Objects.

When you create an network/host-IPv6 object or define IPv6 addresses as part of a policy, Security Manager verifies that the syntax of the address is correct and that a prefix length was entered when required. For example, when you define a policy that requires a host, you do not need to enter a prefix length. However, when you define a policy that requires a network address, you must enter the IPv6 prefix with the prefix length or select a network/host-IPv6 object that has a prefix length defined.

For more detailed information on IPv6 addressing, see the IETF RFC 4291, IP Version 6 Addressing Architecture, at http://www.ietf.org/rfc/rfc4291.txt.

Related Topics

Creating IPv4 or IPv6 Network/Host Objects

Using Unspecified IPv4 or IPv6 Network/Host Objects

Policy Object Manager Window

Understanding Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

Many policies in Security Manager require that you identify a service to which the policy applies. A service is a protocol and port definition that identifies a particular type of traffic. In many cases, you can specify the service directly in the policy. You can also select service policy objects that define the required services, or use a combination of service objects and policy-specific service designations.

Service objects are convenient because you can create 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. There are two types of service policy object:

Service group—Can contain one or more service, including other service objects. This is the type of service object that was available in all Security Manager 3.x releases.

Service object—Can contain a single service.

When configuring a policy that requires that you identify a service, you can select or create service objects by clicking the Select button next to the Services field. To create a new service from the selection dialog box, click the Add button beneath the service list and select a type: group or object. You can also create services from the Policy Object Manager Window by selecting Services > Services from the table of contents and clicking the Add Object button and selecting group or object. For information on the specific fields available when creating a service object, see Configuring Service Objects.

Security Manager includes a comprehensive collection of predefined service group objects, including ICMP messages and objects for commonly used services such as HTTP, Syslog, POP3, Telnet, and SNMP. Before using a predefined service group 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 Cloning (Duplicating) Objects.

Whether you are creating a service object or specifying services directly in a policy, you can specify services using the following formats. As you type, Security Manager might prompt you with text-completion options related to your entry. You can select a value from the list and press Enter or Tab. You can enter more than one service by separating services with commas.

protocol, where the protocol is 1-255 or a well known protocol name such as tcp, udp, gre, icmp, and so forth. If you enter a number, Security Manager might convert it to the associated name.

icmp/message_type, where the message type is 1-255 or a well-known message type name such as echo.

{tcp | udp | tcp&udp}/{destination_port_number | port_list_object} where the destination port number is 1-65535 or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20. The source port number is the Default Range port list object. The Default Range object includes either all ports (1-65535) or all secure ports (1024-65535), depending on the setting you select in the Policy Objects Page, page 11-33 (select Tools > Security Manager Administration > Policy Objects).

For example, defining a service as tcp/10 means that 10 is the destination port and no source port is defined.

When you specify ports, you can also use the following special keywords: lt (less than), gt (greater than), eq (equal to), and neq (not equal to), followed by a number. For example, lt 440 specifies all ports less than 440.


Tip To create port list objects, select Services > Port Lists in the Policy Object Manager Window and click the Add Object button. For more information, see Configuring Port List Objects.


{tcp | udp | tcp&udp}/{source_port_number | port_list_object}/ {destination_port_number | port_list_object}, where the source and destination port numbers are 1-65535 or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20.

For example, 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 port list object, for example, tcp/10/Default Range.

(Service groups only) service_object_name, which is the name of another existing service object. Specifying other objects lets you nest object definitions. Click Select to select a service object or to create a new object.

Related Topics

Selecting Objects for Policies

Creating Policy Objects

Editing Objects

How Service Objects are Provisioned as Object Groups

Using Category Objects

Managing Object Overrides

Allowing a Policy Object to Be Overridden

Configuring Port List Objects

Use the Port List dialog box to create, edit, or copy a port list object. Each port list object can contain one or more ports or port ranges (for example, 1-1000 and 2000-2500). Additionally, a port list object can include other port list objects.

You typically use port list objects when defining services, but you can also use them in various policies to identify a port rather than typing in the port number. For more information about using port lists in service definitions, see Understanding and Specifying Services and Service and Port List Objects.


Tip The predefined Default Range port list object includes either all ports (1-65535) or all secure ports (1024-65535), depending on the setting you select in the Security Manager Administration window (select Tools > Security Manager Administration > Policy Objects and see Policy Objects Page, page 11-33).


Navigation Path

Select Manage > Policy Objects, then select Services > Port Lists from the Object Type Selector. Right-click inside the work area and select New Object or right-click a row and select Edit Object.

Related Topics

Understanding and Specifying Services and Service and Port List Objects

Configuring Service Objects

Field Reference

Table 6-30 Port List Dialog Box 

Element
Description

Name

The object name, which can be up to 128 characters. Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Ports

The ports or ranges included in the port list object, for example, 443, or 1-1000. You can define a single port, a range of ports, multiple port ranges, or any combination of single ports and ranges. Separate multiple entries with commas. Port values range from 1 to 65535.

You can use the following operators to identify ranges:

gt—Greater than. For example, gt 1000.

lt—Less than. For example, lt 1000.

eq—Equals. For example, eq 1000. However, eq 1000 has the same meaning as simply entering 1000.

neq—Does not equal. For example, neq 1000.

If you use this operator, you can include only the neq value in the Ports field. However, you can include port ranges in the object. Thus, if you want to create an object that specifies all ports from 1000-1200 except for 1150, create a port list object for the 1000-1200 range, and another object that specifies neq 1150 and that includes the other port list object.

Port Lists

The other port list objects included in the object, if any. Enter the name of the port lists or click Select to select them from a list or to create new objects. Separate multiple entries with commas.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


Configuring Service Objects

Use the Add and Edit Service dialog boxes to create or edit service objects. You can create a service object to describe a type of traffic carried by the devices in your network. When creating a service object, you must specify the protocol used by the service.

When you create a service object, you must choose the object type:

Service Group—Can contain one or more services, including other service objects. This is the type of service object available in all Security Manager 3.x releases.

Service object—Can contain a single service.

Security Manager provides many predefined service group objects. Before creating an object, scan the list in the Policy Object Manager to see if an existing object fits your needs. Note that although you can duplicate a predefined object, you cannot edit it.

Navigation Path

Select Manage > Policy Objects, then select Services > Services from the Object Type Selector. Right-click inside the work area and select New Object (and select an object type) or right-click a row and select Edit Object.

Related Topics

Understanding and Specifying Services and Service and Port List Objects

Policy Object Manager Window

Field Reference

Table 6-31 Add and Edit Service Dialog Boxes 

Element
Description

Name

The object name. If you are using the object for ASA or PIX devices running software version 8.x, limit the length of the name to 64 characters. For other devices the name can be up to 128 characters.

Object names are not case-sensitive. For more information, see Creating Policy Objects.

Description

An optional description of the object.

Services (for groups)

Service (for objects)

The services to include in this policy object. When creating a Service Group, you can enter more than one service by separating services with commas. When creating a Service Object, you can enter one service only.

You can specify services using the following formats. As you type, Security Manager may prompt you with text-completion options related to your entry. If you enter a service that translates directly to a predefined service object, the entry is converted to the predefined object name; for example, TCP/80 is converted to HTTP.

protocol, where the protocol is 1 to 255 or a well known protocol name such as tcp, udp, gre, icmp, and so forth. If you enter a number, Security Manager might convert it to the associated name.

icmp/message_type, where the message type is 1 to 255 or a well-known ICMP message type name such as echo.

{tcp | udp | tcp&udp}/{destination_port_number | port_list_object} where the destination port number can be 1 to 65535, or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20. In this instance, the source port number is the Default Range port list object, which specifies the range 1-65535. (See Configuring Port List Objects for information about creating and editing port list objects.)

Whenever you specify ports, you can also use the following special keywords: lt (less than), gt (greater than), eq (equal to), and neq (not equal to), followed by a number. For example, lt 440 specifies all ports less than 440.

{tcp | udp | tcp&udp}/{source_port_number | port_list_object}/ {destination_port_number | port_list_object}, where the source and destination port numbers can be 1 to 65535, or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20.

(Service groups only) service_object_name, which is the name of another existing service object. Specifying other objects lets you nest object definitions. Click Select to select a service object or to create a new object.

Category

The category assigned to the object. Categories help you organize and identify rules and objects. See Using Category Objects.

Allow Value Override per Device

Overrides

Edit button

Whether to allow the object definition to be changed at the device level. For more information, see Allowing a Policy Object to Be Overridden and Understanding Policy Object Overrides for Individual Devices.

If you allow device overrides, you can click the Edit button to create, edit, and view the overrides. The Overrides field indicates the number of devices that have overrides for this object.


How Policy Objects are Provisioned as Object Groups

Object groups are a feature of ASA, PIX, FWSM, and IOS 12.4(20)T+ 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), whereas object groups of all types defined on the device 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 information about the options available when deploying object groups, see Deployment Page, page 11-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.


Note For IOS devices, any policy objects that are used by access control list objects are subsequently replaced during deployment by the contents of the object. Object groups used with ACL objects are not preserved, although they are discovered as Security Manager policy objects.


The following sections describe the changes that are made when provisioning policy objects to object groups on the device, or when creating the policy objects when discovering policies on these devices:

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups

How Service Objects are Provisioned as Object Groups

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups

In most cases, network/host, port list, and service objects can be provisioned as object groups without changing the object name. Table 6-32 describes how object names are changed when the names cannot be converted directly to object groups on supported devices.


Note The predefined network/host object any is not provisioned as an object group.


Table 6-32 How Network/Host, Port List, and Service Objects are Named as Object Groups 

Condition
New Name
Examples

Object name includes a space.

Space is replaced with an underscore.

An object named my object is provisioned as an object group named my_object.

Object name is longer than 64 characters (the 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 have 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.

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 or service 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 Network/Host Objects (IPv4 and IPv6)

Understanding and Specifying Services and Service and Port List Objects

How Service Objects are Provisioned as Object Groups

How Policy Objects are Provisioned as Object Groups

How Service Objects are Provisioned as Object Groups

The following table describes how Security Manager creates object groups when deploying service objects to supported devices.


Tip For ASA 8.3+ devices, service objects are provisioned using the object service command instead of the object-group command.


Table 6-33 How Service Objects are Provisioned as Object Groups 

Condition
Generated Object Group
Examples

Service object contains the 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.

 

Service object contains multiple ports or port ranges, but does not use a 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 a 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 and Specifying Services and Service and Port List Objects

How Network/Host, Port List, and Service Objects are Named When Provisioned As Object Groups

How Policy Objects are Provisioned as Object Groups