Cisco ASA 5500 Series Configuration Guide using ASDM, 6.4 and 6.6
Configuring the Identity Firewall
Downloads: This chapterpdf (PDF - 1.45MB) The complete bookPDF (PDF - 26.27MB) | Feedback

Configuring the Identity Firewall

Table Of Contents

Configuring the Identity Firewall

Information About the Identity Firewall

Overview of the Identity Firewall

Architecture for Identity Firewall Deployments

Features of the Identity Firewall

Deployment Scenarios

Cut-through Proxy and VPN Authentication

Licensing for the Identity Firewall

Guidelines and Limitations

Prerequisites

Configuring the Identity Firewall

Task Flow for Configuring the Identity Firewall

Configuring the Active Directory Domain

Configuring Active Directory Server Groups

Configuring Active Directory Agents

Configuring Active Directory Agent Groups

Configuring Identity Options

Configuring Identity-based Access Rules

Adding Users and Groups to Access Rules

Configuring Local User Groups

Configuring Cut-through Proxy Authentication

Monitoring the Identity Firewall

Monitoring AD Agents

Monitoring Groups

Monitoring Memory Usage for the Identity Firewall

Monitoring Users for the Identity Firewall

Feature History for the Identity Firewall


Configuring the Identity Firewall


This chapter describes how to configure the ASA for the Identity Firewall. The chapter includes the following sections:

Information About the Identity Firewall

Licensing for the Identity Firewall

Guidelines and Limitations

Prerequisites

Configuring the Identity Firewall

Monitoring the Identity Firewall

Feature History for the Identity Firewall

Information About the Identity Firewall

This section includes the following topics:

Overview of the Identity Firewall

Architecture for Identity Firewall Deployments

Features of the Identity Firewall

Deployment Scenarios

Cut-through Proxy and VPN Authentication

Overview of the Identity Firewall

In an enterprise, users often need access to one or more server resources. Typically, a firewall is not aware of the users' identities and, therefore, cannot apply security policies based on identity. To configure per-user access policies, you must configure a user authentication proxy, which requires user interaction (a user name/password query).

The Identity Firewall in the ASA provides more granular access control based on users' identities. You can configure access rules and security policies based on user names and user groups name rather than through source IP addresses. The ASA applies the security policies based on an association of IP addresses to Windows Active Directory login information and reports events based on the mapped user names instead of network IP addresses.

The Identity Firewall integrates with Microsoft Active Directory in conjunction with an external Active Directory (AD) Agent that provides the actual identity mapping. The ASA uses Windows Active Directory as the source to retrieve the current user identity information for specific IP addresses and allows transparent authentication for Active Directory users.

Identity-based firewall services enhance the existing access control and security policy mechanisms by allowing users or groups to be specified in place of source IP addresses. Identity-based security policies can be interleaved without restriction between traditional IP address based rules.

The key benefits of the Identity Firewall include:

Decoupling network topology from security policies

Simplifying the creation of security policies

Providing the ability to easily identify user activities on network resources

Simplify user activity monitoring

Architecture for Identity Firewall Deployments

The Identity Firewall integrates with Window Active Directory in conjunction with an external Active Directory (AD) Agent that provides the actual identity mapping.

The identity firewall consists of three components:

ASA

Microsoft Active Directory

Though Active Directory is part of the Identity Firewall on the ASA, they are managed by Active Directory administrators. The reliability and accuracy of the data depends on data in Active Directory.

Supported versions include Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 servers.

Active Directory (AD) Agent

The AD Agent runs on a Windows server. Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.


Note Windows 2003 R2 is not supported for the AD Agent server.


Figure 39-1

Identity Firewall Components

1

On the ASA: Configure local user groups and Identity Firewall policies.

4

Client <-> ASA: The client logs onto the network through Microsoft Active Directory. The AD Server authenticates users and generates user logon security logs.

Alternatively, the client can log onto the network through a cut-through proxy or by using VPN.

2

ASA <-> AD Server: The ASA sends an LDAP query for the Active Directory groups configured on the AD Server.

The ASA consolidates local and Active Directory groups and applies access rules and MPF security policies based on user identity.

5

ASA <-> Client: Based on the policies configured on the ASA, it grants or denies access to the client.

If configured, the ASA probes the NetBIOS of the client to pass inactive and no-response users.

3

ASA <-> AD Agent: Depending on the Identity Firewall configuration, the ASA downloads the IP-user database or sends a RADIUS request to the AD Agent querying the user's IP address.

The ASA forwards the new mappings learned from web authentication and VPN sessions to the AD Agent.

6

AD Agent <-> AD Server: Periodically or on-demand, the AD Agent monitors the AD Server security event log file via WMI for client login and logoff events.

The AD Agent maintains a cache of user ID and IP address mappings. and notifies the ASA of changes.

The AD Agent sends logs to a syslog server.


Features of the Identity Firewall

The Identity Firewall has the following key features.

Flexibility

The ASA can retrieve user identity and IP address mappings from the AD Agent by querying the AD Agent for each new IP address or by maintaining a local copy of the entire user identity and IP address database.

Supports host group, subnet, or IP address for the destination of a user identity policy.

Supports a fully qualified domain name (FQDN) for the source and destination of a user identity policy.

Supports the combination of 5-tuple policies with ID-based policies. The identity-based feature works in tandem with existing 5-tuple solution.

Supports usage with IPS and Application Inspection policies.

Retrieves user identity information from remote access VPN, AnyConnect VPN, L2TP VPN and cut-through proxy. All retrieved users are populated to all ASA devices connected to the AD Agent.

Scalability

Each AD Agent supports 100 ASA devices. Multiple ASA devices are able to communicate with a single AD Agent to provide scalability in larger network deployments.

Supports 30 Active Directory servers provided the IP address is unique among all domains.

Each user identity in a domain can have up to 8 IP addresses.

Supports up to 64,000 user identity-IP address mappings in active ASA policies for ASA 5500 Series models. This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.

Supports up to 1024 user identity-IP address mappings in active ASA policies for the ASA 5505.

Supports up to 256 user groups in active ASA policies.

A single rule can contain one or more user groups or users.

Supports multiple domains.

Availability

The ASA retrieves group information from Active Directory and falls back to web authentication for IP addresses that the AD Agent cannot map a source IP address to a user identity.

The AD Agent continues to function when any of the Active Directory servers or the ASA are not responding.

Supports configuring a primary AD Agent and a secondary AD Agent on the ASA. If the primary AD Agent stops responding, the ASA can switch to the secondary AD Agent.

If the AD Agent is unavailable, the ASA can fall back to existing identity sources such as cut through proxy and VPN authentication.

The AD Agent runs a watchdog process that automatically restarts its services when they are down.

Allows a distributed IP address/user mapping database among ASA devices.

Deployment Scenarios

You can deploy the components of the Identity Firewall in the following ways depending on your environmental requirement.

As shown in Figure 39-2, you can deploy the components of the Identity Firewall to allow for redundancy. Scenario 1 shows a simple installation without component redundancy.

Scenario 2 also shows a simple installation without redundancy. However, in that deployment scenario, the Active Directory server and AD Agent are co-located on one Windows server.

Figure 39-2

Deployment Scenario without Redundancy

As shown in Figure 39-3, you can deploy the Identity Firewall components to support redundancy. Scenario 1 shows a deployment with multiple Active Directory servers and a single AD Agent installed on a separate Windows server. Scenario 2 shows a deployment with multiple Active Directory servers and multiple AD Agents installed on separate Windows servers.

Figure 39-3

Deployment Scenario with Redundant Components

As shown in Figure 39-4, all Identity Firewall components—Active Directory server, the AD Agent, and the clients—are installed and communicate on the LAN.

Figure 39-4 LAN -based Deployment

Figure 39-5 shows a WAN-based deployment to support a remote site. The Active Directory server and the AD Agent are installed on the main site LAN. The clients are located at a remote site and connect to the Identity Firewall components over a WAN.

Figure 39-5

WAN-based Deployment

Figure 39-6 also shows a WAN-based deployment to support a remote site. The Active Directory server is installed on the main site LAN. However, the AD Agent is installed and access by the clients at the remote site. The remote clients connect to the Active Directory servers at the main site over a WAN.

Figure 39-6

WAN-based Deployment with Remote AD Agent

Figure 39-7 shows an expanded remote site installation. An AD Agent and Active Directory servers are installed at the remote site. The clients access these components locally when logging into network resources located at the main site. The remote Active Directory server must synchronize its data with the central Active Directory servers located at the main site.

Figure 39-7

WAN-based Deployment with Remote AD Agent and AD Servers

Cut-through Proxy and VPN Authentication

In an enterprise, some users log onto the network by using other authentication mechanisms, such as authenticating with a web portal (cut-through proxy) or by using a VPN. For example, users with a Machintosh and Linux client might log in a web portal (cut-through proxy) or by using a VPN. Therefore, you must configure the Identity Firewall to allow these types of authentication in connection with identity-based access policies.

Figure 39-8 shows a deployment to support a cut-through proxy authentication captive portal. Active Directory servers and the AD Agent are installed on the main site LAN. However, the Identity Firewall is configured to support authentication of clients that are not part of the Active Directory domain.

Figure 39-8

Deployment Supporting Cut-through Proxy Authentication

The ASA designates users logging in through a web portal (cut-through proxy) as belonging to the Active Directory domain with which they authenticated.

The ASA designates users logging in through a VPN as belonging to the LOCAL domain unless the VPN is authenticated by LDAP with Active Directory, then the Identity Firewall can associate the users with their Active Directory domain.

The ASA reports users logging in through VPN authentication or a web portal (cut-through proxy) to the AD Agent, which distributes the user information to all registered ASA devices. Specifically, the user identity-IP address mappings of authenticated users are forwarded to all ASA contexts that contain the input interface where packets are received and authenticated.

See Configuring Cut-through Proxy Authentication.

Licensing for the Identity Firewall

The following table shows the licensing requirements for this feature:

Model
License Requirement

All models

Base License.


Guidelines and Limitations

This section includes the guidelines and limitations for this feature.

Context Mode Guidelines

Supported in single and multiple context mode.

Firewall Mode Guidelines

Supported in routed and transparent firewall modes.

Failover Guidelines

The Identity Firewall supports user identity-IP address mappings and AD Agent status replication from active to standby when stateful failover is enabled. However, only user identity-IP address mappings, AD Agent status, and domain status are replicated. User and user group records are not replicated to the standby ASA.

When failover is configured, the standby ASA must also be configured to connect to the AD Agent directly to retrieve user groups. The standby ASA does not send NetBIOS packets to clients even when the NetBIOS probing options are configured for the Identity Firewall.

When a client is determined as inactive by the active ASA, the information is propagated to the standby ASA. User statistics are not propagated to the standby ASA.

When you have failover configured, you must configure the AD Agent to communicate with both the active and standby ASA devices. See the Installation and Setup Guide for the Active Directory Agent for the steps to configure the ASA on the AD Agent server.

IPv6 Guidelines

Supports IPv6.

The AD Agent supports endpoints with IPv6 addresses. It can receive IPv6 addresses in log events, maintain them in its cache, and send them through RADIUS messages.

NetBIOS over IPv6 is not supported

Cut through proxy over IPv6 is not supported.

Additional Guidelines and Limitations

A full URL as a destination address is not supported.

For NetBIOS probing to function, the network between the ASA, AD Agent, and clients must support UDP-encapsulated NetBIOS traffic.

MAC address checking by the Identity Firewall does not work when intervening routers are present. Users logged onto clients that are behind the same router have the same MAC addresses. With this implementation, all the packets from the same router are able to pass the check, because the ASA is unable to ascertain to the actual MAC addresses behind the router.

The following ASA features do not support using the identity-based object and FQDN:

route-map

Crypto map

WCCP

NAT

group-policy (except VPN filter)

DAP

See Configuring Identity-based Access Rules.

When you use the Cisco Context Directory Agent (CDA) in conjunction with the ASA or Cisco Ironport Web Security Appliance (WSA), make sure that you open the following ports:

Authentication port for UDP—1645

Accounting port for UDP—1646

Listening port for UDP—3799

The listening port is used to send change of authentication requests from the CDA to the ASA or to the WSA.

Prerequisites

Before configuring the Identity Firewall in the ASA, you must meet the prerequisites for the AD Agent and Microsoft Active Directory.

AD Agent

The AD Agent must be installed on a Windows server that is accessible to the ASA. Additionally, you must configure the AD Agent to obtain information from the Active Directory servers. Configure the AD Agent to communicate with the ASA.

Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.


Note Windows 2003 R2 is not supported for the AD Agent server.


For the steps to install and configure the AD Agent, see the Installation and Setup Guide for the Active Directory Agent.

Before configuring the AD Agent in the ASA, obtain the secret key value that the AD Agent and the ASA use to communicate. This value must match on both the AD Agent and the ASA.

Microsoft Active Directory

Microsoft Active Directory must be installed on a Windows server and accessible by the ASA. Supported versions include Windows 2003, 2008, and 2008 R2 servers.

Before configuring the Active Directory server on the ASA, create a user account in Active Directory for the ASA.

Additionally, the ASA sends encrypted log in information to the Active Directory server by using SSL enabled over LDAP. SSL must be enabled on the Active Directory server. See the documentation for Microsft Active Diretory for the steps to enable SSL for Active Directory.


Note Before running the AD Agent Installer, you must install the following patches on every Microsoft Active Directory server that the AD Agent monitors. These patches are required even when the AD Agent is installed directly on the domain controller server. See the README First for the Cisco Active Directory Agent.


Configuring the Identity Firewall

This section contains the following topic:

Task Flow for Configuring the Identity Firewall

Configuring the Active Directory Domain

Configuring Active Directory Server Groups

Configuring Active Directory Server Groups

Configuring Active Directory Agent Groups

Configuring Identity Options

Configuring Identity-based Access Rules

Configuring Local User Groups

Configuring Cut-through Proxy Authentication

Task Flow for Configuring the Identity Firewall

Prerequisite

Before configuring the Identity Firewall in the ASA, you must meet the prerequisites for the AD Agent and Microsoft Active Directory. See Prerequisites for information.

Task Flow in the ASA

To configure the Identity Firewall, perform the following tasks:


Step 1 Configure the Active Directory domain in the ASA.

See Configuring the Active Directory Domain and Configuring Active Directory Server Groups.

See also Deployment Scenarios for the ways in which you can deploy the Active Directory servers to meet your environment requirements.

Step 2 Configure the AD Agent in ASA.

See Configuring Active Directory Server Groups and Configuring Active Directory Agent Groups.

See also Deployment Scenarios for the ways in which you can deploy the AD Agents to meet your environment requirements.

Step 3 Configure Identity Options.

See Configuring Identity Options.

Step 4 Configure Identity-based Access Rules in the ASA.

After AD domain and AD-Agent are configured, identity-based rules can be specified to enforce identity-based rules. See Configuring Identity-based Access Rules.

Step 5 Configure local user groups.

See Configuring Local User Groups.

Step 6 Configure the cut-through proxy.

See Configuring Cut-through Proxy Authentication.


Configuring the Active Directory Domain

Active Directory domain configuration on the ASA is required for the ASA to download Active Directory groups and accept user identities from specific domains when receiving IP-user mapping from the AD Agent.

Prerequisites

Active Directory server IP address

Distinguished Name for LDAP base dn

Distinguished Name and password for the Active Directory user that the Identity Firewall uses to connect to the Active Directory domain controller

To configure the Active Directory domain, perform the following steps:


Step 1 Choose Configuration > Firewall > Identity Options. The Identity Options pane appears.

Step 2 If necessary, check the Enable User Identity check box to enable the feature.

Step 3 In the Domains section, click Add or select a domain from the list and click Edit. The Domain dialog box appears.

Step 4 In the Domain NETBIOS Name field, enter a name up to 32 characters consisting of [a-z], [A-Z], [0-9], [!@#$%^&()-_=+[]{};,. ] except '.' and ' ' at the first character. If the domain name contains a space, you must enclose that space character in quotation marks. The domain name is not case sensitive.

When you edit the name of an existing domain, the domain name associated with existing users and user groups is not changed.

Step 5 From the AD Server Group list, select the Active Directory servers to associate with this domain or click Manage to add a new server group to the list. See Configuring Active Directory Server Groups.

Step 6 Click OK to save the domain settings.


What to Do Next

Configure Active Directory server groups. See Configuring Active Directory Server Groups.

Configure AD Agents. See Configuring Active Directory Server Groups and Configuring Active Directory Agent Groups.

Configuring Active Directory Server Groups

To configure the Active Directory server group, perform the following steps:


Step 1 Choose Configuration > Firewall > Identity Options > Add > Manage. The Configure Active Directory Server Groups dialog appears.

Step 2 To add an Active Directory server group for the Identify Firewall, click Add for the Active Directory Server Groups table. The Add Active Directory Server Group dialog box appears. See the "Configuring AAA Server Groups" section.

Step 3 To add servers to an Active Directory server group, select the group from the Active Directory Server Groups list and click Add for the Servers in the Selected Group table. The Add Active Directory Server dialog box appears. See the "Configuring AAA Server Groups" section.

Step 4 Click OK to save the settings.


What to Do Next

Configure AD Agents. See Configuring Active Directory Agents and Configuring Active Directory Agent Groups.

Configuring Active Directory Agents

Periodically or on-demand, the AD Agent monitors the Active Directory server security event log file via WMI for user login and logoff events. The AD Agent maintains a cache of user ID and IP address mappings. and notifies the ASA of changes.

Requirement

AD agent IP address

Shared secret between ASA and AD agent

To configure the AD Agents, perform the following steps:


Step 1 Open the Configuration > Firewall > Identity Options pane.

Step 2 If necessary, check the Enable User Identity check box to enable the feature.

Step 3 In the Active Directory Agent section, click Manage.

The Configure Active Directory Agents dialog box appears.

Step 4 To add an AD Agent, click the Add button.

OR

Select an agent group from the list and click Edit.

See Configuring Active Directory Agent Groups.

Step 5 Click OK to save your changes.


What to Do Next

Configure AD Agent groups. See Configuring Active Directory Agent Groups.

Configure access rules for the Identity Firewall. See Configuring Identity-based Access Rules.

Configuring Active Directory Agent Groups

Configure the primary and secondary AD Agents for the AD Agent Server Group. When the ASA detects that the primary AD Agent is not responding and a secondary agent is specified, the ASA switches to secondary AD Agent. The Active Directory server for the AD agent uses RADIUS as the communication protocol; therefore, you should specify a key attribute for the shared secret between ASA and AD Agent.

To configure the AD Agent Groups, perform the following steps:


Step 1 From the Configure Active Directory Agents dialog, click Add. The Add Active Directory Agent Group dialog box appears.

Step 2 Enter a name for the AD Agent group.

Step 3 From the Primary Active Directory Agent section, specify the interface on which the ASA listens for traffic from the AD Agent server, and enter the FQDN of the server or IP address.

Step 4 In the Primary Active Directory Agent section, enter a timeout interval and the retry interval for the attempts that the ASA will continue to contact the AD Agent when it is not responding.

Step 5 Enter the shared secret key that is used between primary AD Agent and the ASA.

Step 6 From the Secondary Active Directory Agent section, specify the interface on which the ASA listens for traffic from the AD Agent server, and enter the FQDN of the server or IP address.

Step 7 In the Secondary Active Directory Agent section, enter a timeout interval and the retry interval for the the attempts that the ASA will continue to contact the AD Agent when it is not responding.

Step 8 Enter the shared secret key that is used between secondary AD Agent and the ASA.

Step 9 Click OK to save your changes.


What to Do Next

Configure access rules for the Identity Firewall. See Configuring Identity-based Access Rules.

Configuring Identity Options

Use this pane to add or edit the Identity Firewall feature; select the Enable check box to enable the feature. By default, the Identity Firewall feature is disabled.

Prerequisites

Before configuring the identify options for the Identity Firewall, you must you must meet the prerequisites for the AD Agent and Microsoft Active Directory. See Prerequisites the requirements for the AD Agent and Microsoft Active Directory installation.

To configure the Identity Options for the Identity Firewall, perform the following steps:


Step 1 Choose Configuration > Firewall > Identity Options. The Identity Option pane appears.

Step 2 If necessary, check the Enable User Identity check box to enable the feature.

Step 3 To add a domain for the Identity Firewall, click Add by the Domains table. The Add Domain dialog box appears. See Configuring the Active Directory Domain.

Step 4 For domains already been added to the Domains list, check whether to disable rules when the domain is down because the Active Directory domain controller is not responding.

When a domain is down and this option is checked for that domain, the ASA disables the user identity rules associated with the users in that domain. Additionally, the status of all user IP addresses in that domain are marked as disabled in the Monitoring > Properties > Identity > Users pane.

Step 5 From the Default Domain drop-down list, select the default domain for the Identity Firewall.

The default domain is used for all users and user groups when a domain has not been explicitly configured for those users or groups. When a default domain is not specified, the default domain for users and groups is LOCAL.

Additionally, the Identity Firewall uses the LOCAL domain for all locally defined user groups or locally defined users (users who log in and authenticate by using a VPN or web portal).


Note The default domain name you select must match the NetBIOS domain name configured on the Active Directory domain controller. If the domain name does not match, the AD Agent will incorrectly associate the user-IP mappings with the domain name you enter when configuring the ASA.
To view the NetBIOS domain name, open the Active Directory user event security log in any text editor.


For multiple context modes, you can set a default domain name for each context, as well as within the system execution space.

Step 6 In the Active Directory Agent section, select the AD Agent group from the drop-down list. To add AD Agent groups, click Manage. See Configuring Active Directory Agents.

Step 7 In the Hello Timer field, enter a number between 10 to 65535 seconds.

The hello timer between the ASA and the AD Agent defines how frequently the ASA exchanges hello packets. The ASA uses the hello packet to obtain ASA replication status (in-sync or out-of-sync) and domain status (up or down). If the ASA does not receive a response from the AD Agent, it resends a hello packet after the specified interval.

Specify the number of times that the ASA will continue to send hello packets to the AD Agent. By default, the number of seconds is set to 30 and the retry times is set to 5.

Step 8 In the Poll Group Timer field, enter the number of hours that the ASA uses to query the DNS server to resolve fully-qualified domain names (FQDN). By default, the poll timer is set to 4 hours.

Step 9 In the Retrieve User Information, select an option from the list:

On Demand—specifies that the ASA retrieve the user mapping information of an IP address from the AD Agent when the ASA receives a packet that requires a new connection and the user of its source IP address is not in the user-identity database.

Full Download—specifies that the ASA send a request to the AD Agent to download the entire IP-user mapping table when the ASA starts and then to receive incremental IP-user mapping when users log in and log out.


Note Selecting On Demand has the benefit of using less memory as only users of received packets are queried and stored.


Step 10 In the Error Conditions section, select whether to disable rules in the AD Agent is not responding.

When the AD Agent is down and this option is selected, the ASA disables the user identity rules associated with the users in that domain. Additionally, the status of all user IP addresses in that domain are marked as disabled in Monitoring > Properties > Identity > Users pane.

Step 11 In the Error Conditions section, select whether to remove a user's IP address when the NetBIOS probe fails.

Selecting this option specifies the action when NetBIOS probing to a user is blocked (for example, the user client does not respond to a NetBIOS probe). The network connection might be blocked to that client or the client is not active. When this option is selected, the ASA disables the identity rules associated with that user's IP address.

Step 12 In the Error Conditions section, select whether to remove a user's MAC address when it is inconsistent with the IP address that the ASA has currently mapped to that MAC address. When this option is selected, the ASA disables the user identity rules associated with the specific user.

Step 13 In the Error Conditions section, select whether to track users that are not found.

Step 14 In the Users section, select the Idle Timeout option and enter a time in minutes from 1 minute to 65535. By default, the idle timeout is set to 60 minutes.

Enabling this option configures a timer when an active user is considered idle, meaning the ASA does not receive traffic from the user's IP address for more than the specified time. Once the timer expires, the user's IP address is marked inactive and removed from the local cached IP-user database and the ASA no longer notifies the AD Agent about that IP address. Existing traffic is still allowed to pass. When the Idle Timeout option is enabled, the ASA runs an inactive timer even when the NetBIOS Logout Probe is configured.


Note The Idle Timeout option does not apply to VPN or cut through proxy users.


Step 15 In the NetBIOS Logout Probe section, enable NetBIOS probing and set the probe timer (from1 to 65535 minutes) before a user's IP addresses is probed and the retry interval (from 1 to 256 retries) between retry probes.

Enabling this option configures how often the ASA probes the user host to determine whether the user client is still active. To minimize the NetBIOS packets, ASA only sends a NetBIOS probe to the client when the user has been idle for more than the specified number of minutes in the Idle Timeout minutes field.

Step 16 In the NetBIOS Logout Probe section, select an option from the User Name list:

Match Any—As long as the NetBIOS response from the host contains the user name of the user assigned to the IP address, the user identity is be considered valid. Specifying this option requires that the host enabled the Messenger service and configured a WINS server.

Exact Match—The user name of the user assigned to the IP address must be the only one in the NetBIOS response. Otherwise, the user identity of that IP address is considered invalid. Specifying this option requires that the host enabled the Messenger service and configured a WINS server.

User Not Needed—As long as the ASA received a NetBIOS response from the host the user identity is considered valid.

Step 17 Click Apply to save the Identity Firewall Configuration.


What to Do Next

Configure the Active Directory domain and server groups. See Configuring the Active Directory Domain and Configuring Active Directory Server Groups.

Configure AD Agents. See Configuring Active Directory Server Groups.

Configuring Identity-based Access Rules

An access rule permits or denies traffic based on the protocol, a source and destination IP address or network, and the source and destination ports. For information about access rules, see in Chapter 32 "Configuring Access Rules."

The Identity Firewall feature adds the ability to permit or deny traffic based on a users' identities or based on a user group. You configure access rules and security policies based on user names and user groups name in addition to source IP addresses. The ASA applies the security policies based on an association of IP addresses to Windows Active Directory login information and reports events based on the mapped user names instead of network IP addresses.

Users can be local, remote (via VPN), wired or wireless. Server resources can include server IP address, server DNS name, or domain.

Identity-based access rules follow the same general format that standard IP-address-based rules follow: action, protocol, source, destination, and optional source service when the protocol for the rule is TCP or UDP. In addition, they include specifying user and user group objects before traditional IP-address-based objects—any, network object/network group, interface, host, IP address, and network mask.

You can create access rules that solely contain identity-based objects (users and user groups) or combine identity-based objects with traditional IP-address-based objects. You can create an access rule that includes a source user or source user group from a qualifying IP-address-based source. For example, you could create and access rule for sample_user1 11.0.0.0 255.0.0.0, meaning the user could have any IP address on subnet 11.0.0.0/8.

You can create an access rule with FQDN in the source and the destination.

The destination portion of an identity-based access rule follows the same format and guidelines as traditional IP-address-based access rules.

Guidelines and Limitations

Supports up to 64,000 user identity-IP address mappings in active ASA policies for ASA 5500 Series models.

This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.

Supports up to 1024 user identity-IP address mappings in active ASA policies for the ASA 5505.

This limit controls the maximum users who have policies applied. The total users are the aggregated users configured on all different contexts.

Supports up to 256 user groups in active ASA security policies.

A single rule can contain one or more user groups or users.

Prerequisites

After AD domain and AD-Agent are configured, Identity-based rules can be specified to enforce identity-based rules.

To configure identity-based access rules, perform the following steps:


Step 1 Open the Configuration > Firewall > Access Rules > Add Access Rules or Add IPv6 Access Rule. The Add Access Rule or Add IPv6 Access Rule dialog box appears.

See Configuring Access Rules for the steps to create an access rule.

Step 2 From the access rule dialog box, click the ellipsis (.) for the User field. The Browse User dialog box appears. See Adding Users and Groups to Access Rules.


Adding Users and Groups to Access Rules

To add users and groups to an access policy, perform the following steps.

Create or edit an access rule. See Configuring Access Rules for the steps to create or edit an access rule.


Step 1 From the Add Access Rule or Add IPv6 Access Rule dialog box, click the ellipsis (...) for the User field. The Browse User dialog box appears.

Step 2 From the Domain field, select the domain of the group or user that you want to add. The domain can be the local domain or a specific Active Directory domain.

To add a domain for this access rule, click Manage. See Configuring the Active Directory Domain.

Step 3 In the User Groups section, enter the group name in the Find field and click Find. To view all the user groups in that domain, enter an asterisk (*). ASDM warns you that viewing all user groups can take a long time to display the results, especially if the domain has a large number of groups.

The value you enter in the Find field filters the user groups for that domain.

The group name appears in the User Groups list. To add additional user groups for the Identity Firewall, see Configuring Local User Groups.

Step 4 Select the groups that you want to add to the access rule and click Add. The groups appear in the Selected User Groups and Users list.

Step 5 In the User section, enter the user name in the Find field and click Find. The user name appears in the Users list.

Step 6 Select the user that you want to add to the access rule and click Add. The user appears in the Selected User Groups and Users list.

Step 7 To manually enter user names, enter them in the text box and click Add. Separate each user name with a comma. The user names appear in the Selected User Groups and Users list.

When you enter a user name manually and click Add, the user name appears in the Selected User Groups and Users list with the default domain, for example default_domain\\sample_user1.

The Selected User Groups and Users list can contain users and user groups from multiple Active Directory.

Step 8 Click OK to save your changes.


Configuring Local User Groups

The ASA sends an LDAP query to the Active Directory server for user groups globally defined in the Active Directory domain controller. The ASA imports these groups for the Identity Firewall feature.

However, the ASA might have localized network resources that are not defined globally that require local user groups with localized security policies.

Local user groups can contain nested groups and user groups that are imported from Active Directory. The ASA consolidates local and Active Directory groups.

A user can belong to local user groups and user groups imported from Active Directory.

To configure local user groups, perform the following steps:


Step 1 Open the Configuration > Firewall > Objects > Local User Groups pane.

A table of user groups and their members appears.

Step 2 To add a group, click Add. The Add User Object Group dialog appears.

Step 3 Enter a name and description for the group.

The group name can contain any character including [a-z], [A-Z], [0-9], [!@#$%^&()-_{}. ]. If the group name contains a space, you must enclose the name in quotation marks.

Step 4 From the Domain list, select the default domain for users in this group or click Manage to add a new domain or edit and existing domain.

Step 5 To add existing groups to this group, enter a search string in the text box and click Find.

Step 6 To add users to the group, enter a search string in the text box and click Find.

Step 7 Select groups and click the Add button to add them to the group.

Step 8 Select users and click the Add button to add them to the group.

Step 9 Click OK to save your changes.


Configuring Cut-through Proxy Authentication

In an enterprise, some users log onto the network by using other authentication mechanisms, such as authenticating with a web portal (cut-through proxy) or by using a VPN. For example, users with a Machintosh and Linux client might log in a web portal (cut-through proxy) or by using a VPN. Therefore, you must configure the Identity Firewall to allow these types of authentication in connection with identity-based access policies.

The ASA designates users logging in through a web portal (cut-through proxy) as belonging to the Active Directory domain with which they authenticated. The ASA designates users logging in through a VPN as belonging to the LOCAL domain unless the VPN is authenticated by LDAP with Active Directory, then the Identity Firewall can associate the users with their Active Directory domain. The ASA reports users logging in through VPN authentication or a web portal (cut-through proxy) to the AD Agent, which distributes the user information to all registered ASA devices.

Users can log in by using HTTP/HTTPS, FTP, Telnet, or SSH. When users log in with these authentication methods, the following guidelines apply:

For HTTP/HTTPS traffic, an authentication window appears for unauthenticated users.

For Telnet and FTP traffic, users must log in through the cut-through proxy and again to Telnet and FTP server.

A user can specify an Active Directory domain while providing login credentials (in the format domain\username). The ASA automatically selects the associated AAA server group for the specified domain.

If a user specifies an Active Directory domain while providing login credentials (in the format domain\username), the ASA parses the domain and uses it to select an authentication server from the AAA servers configured for the Identity Firewall. Only the username is passed to the AAA server.

If the backslash (\) delimiter is not found in the log in credentials, the ASA does not parse a domain and authentication is conducted with the AAA server that corresponds to default domain configured for the Identity Firewall.

If a default domain or a server group is not configured for that default domain, the ASA rejects the authentication.

If the domain is not specified, the ASA selects the AAA server group for the default domain that is configured for the Identity Firewall.

Detailed Steps

To configure the cut-through proxy for the Identity Firewall, perform the following steps:


Step 1 Open the Configuration > Firewall > AAA Rules pane.

Step 2 Choose Add > Add Authentication Rule. The Add Authentication Rule dialog box appears.

Step 3 From the Interface drop-down list, choose inside.

Step 4 In the Action field, click Authenticate.

Step 5 From the AAA Server Group drop-down list, choose a server group. To add a AAA server to the server group, click Add Server.

If you chose LOCAL for the AAA server group, you can optionally add a new user by clicking Add User. See the "Adding a User Account to the Local Database" topic for more information.

Step 6 In the Source field, enter any.

Step 7 In the User field, enter none.

Step 8 In the Destination field, enter any.

Step 9 In the Service field, enter an IP service name or number for the destination service, or click the ellipsis (.) to choose a service.

Step 10 (Optional) In the Description field, enter a description.

Step 11 Click OK. The Add Authentication Rule dialog box closes and the rule appears in the AAA Rules table.

Step 12 Click Apply. The changes are saved to the running configuration.


Monitoring the Identity Firewall

This section contains the following topic:

Monitoring AD Agents

Monitoring Groups

Monitoring Memory Usage for the Identity Firewall

Monitoring Users for the Identity Firewall

Monitoring AD Agents

You can monitor the AD Agent component of the Identity Firewall.


Step 1 Open the Monitoring > Properties > Identity > AD Agent.

The Active Directory Agent Information pane appears.

Step 2 Click Refresh to update the data in the pane.


This pane displays the following information about the primary and secondary AD Agents:

Status of the AD Agents

Status of the domains

Statistics for the AD Agents

Monitoring Groups

You can monitor the user groups configured for the Identity Firewall.


Step 1 Open the Monitoring > Properties > Identity > Group.

The Activated Groups pane appears.

Step 2 To display a list of the access rules using the selected group, click Where used.

Step 3 Click Refresh to update the data in the pane.


This pane displays displays the list of user groups in the following format:

domain\group_name

Monitoring Memory Usage for the Identity Firewall

You can monitor the memory usage that the Identity Firewall consumes on the ASA.


Step 1 Open the Monitoring > Properties > Identity > Memory Usage.

The Memory Usage of Identity Modules pane appears.

Step 2 Click Refresh to update the data in the pane.


This pane displays the memory usage in bytes of various modules in the Identity Firewall:

Users

Groups

User Stats

LDAP

The ASA sends an LDAP query for the Active Directory groups configured on the Active Directory server. The Active Directory server authenticates users and generates user logon security logs.

AD Agent

Miscellaneous

Total Memory Usage


Note How you configure the Identity Firewall to retrieve user information from the AD Agent impacts the amount of memory used by the feature. You specify whether the ASA uses on demand retrieval or full download retrieval. Selecting On Demand has the benefit of using less memory as only users of received packets are queried and stored. See Configuring Identity Options for a description of these options.


Monitoring Users for the Identity Firewall

You can display information about all users contained in the IP-user mapping database used by the Identity Firewall.


Step 1 Open the Monitoring > Properties > Identity > User.

The Users in the User Database pane appears.


Note Active users are highlighted in green.


Step 2 To display additional information about an active user, select the user in the list and click Details. The Details button is enabled for active users only.

Step 3 To display a list of the access rules using the selected user, click Where used.

Step 4 Click Refresh to update the data in the pane.


This pane displays the following information for users:

The default domain name can be the real domain name, a special reserved word, or LOCAL. The Identity Firewall uses the LOCAL domain name for all locally defined user groups or locally defined users (users who log in and authenticate by using a VPN or web portal). When default domain is not specified, the default domain is LOCAL.

The idle time is stored on a per user basis instead of per the IP address of a user.

If the option to disable rules when the Active Directory server is down and the domain is down, or the option to disable rules in the AD Agent is down and the AD Agent is down, all the logged on users have the status disabled. You configure these options in the Identity Options pane.

Alternatively, you can view statistics for users by accessing the Firewall Dashboard pane. The Firewall Dashboard pane lets you view important information about the traffic passing through your ASA. Choose Home > Firewall Dashboard > Top 10 Users tab in the Top Usage Status area.

The Top 10 Users tab displays data only when you have configured the Identity Firewall feature in the ASA, which includes configuring these additional components—Microsoft Active Directory and Cisco Active Directory (AD) Agent. See Configuring the Identity Firewall for information.

Depending on which option you choose, the Top 10 Users tab shows statistics for received EPS packets, sent EPS packets, and sent attacks for the top 10 users. For each user (displayed as domain\user_name), the tab displays the average EPS packet, the current EPS packet, the trigger, and total events for that user.


Note The first three tabs in the Top Usage Status area display threat detection data and are unrelated to the Identity Firewall feature.


Feature History for the Identity Firewall

Table 39-1 lists the release history for this feature.

Table 39-1 Feature History for the Identity Firewall

Feature Name
Releases
Feature Information

Identity Firewall

8.4(2)

The Identity Firewall feature was introduced.

We introduced or modified the following screens:

Configuration > Firewall > Identity Options
Configuration > Firewall > Objects > Local User Groups
Monitoring > Properties > Identity


\