ASDM Book 1: Cisco ASA Series General Operations ASDM Configuration Guide, 7.2

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 username/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 group names 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 usernames 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
• Simplifying 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

Although Active Directory is part of the Identity Firewall on the ASA, Active Directory administrators manage it. 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 show the components of the Identity Firewall. The succeeding table describes the roles of these components and how they communicate with one another.

Figure 39-1 Identity Firewall Components

Features of the Identity Firewall

The Identity Firewall includes the following key features.

Flexibility

• The ASA can retrieve user identity and IP address mapping 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 the existing 5-tuple solution.
• Supports use 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 ASAs that are connected to the AD Agent.

Scalability

• Each AD Agent supports 100 ASAs. Multiple ASAs 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 mapped entries in active policies for the ASA 5500 Series models. This limit controls the maximum number of users who have policies applied. The total number of users are the aggregate of all users configured in all different contexts.
• Supports up to 1024 user identity-IP address mapped entries in active policies for the ASA 5505.
• Supports up to 256 user groups in active ASA policies.
• A single access rule can contain one or more user groups or users.
• Supports multiple domains.

Availability

• The ASA retrieves group information from the Active Directory and falls back to web authentication for IP addresses when 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 for use among ASAs.

Deployment Scenarios

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

Figure 39-2 shows how 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 this deployment scenario, the Active Directory server and AD Agent are co-located on the same Windows server.

Figure 39-2 Deployment Scenario without Redundancy

Figure 39-3 shows how 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

Figure 39-4 shows how 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 accessed 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

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.

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

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 includes 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 and close this dialog box.

What to Do Next

See Configuring Active Directory Server Groups and the 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 box appears.

Step 2 To add an Active Directory server group for the Identify Firewall, click Add.

The Add Active Directory Server Group dialog box appears.

Step 3 To add servers to an Active Directory server group, select the group from the Active Directory Server Groups list, then click Add.

The Add Active Directory Server dialog box appears.

Step 4 Click OK to save the settings and close this dialog box.

What to Do Next

See Configuring Active Directory Agents and the Configuring Active Directory Agent Groups.

Configuring Active Directory Agents

Prerequisites

Make sure that you have the following information before configuring the AD Agents:

• AD agent IP address
• Shared secret between the ASA and AD agent

To configure the AD Agents, perform the following steps:

Step 1 Choose Configuration > Firewall > Identity Options.

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. Alternatively, choose an agent group from the list and click Edit.

To continue, 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 Security Policy.

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 the 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 the ASA and AD Agent.

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

Step 1 From the Configure Active Directory Agents dialog box, 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 the 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 perform to contact the AD Agent when it is not responding.

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

Step 9 Click OK to save your changes and close this dialog box.

What to Do Next

Configure access rules for the Identity Firewall. See Configuring Identity-Based Security Policy.

Configuring Identity Options

Use this pane to add or edit the Identity Firewall feature; check 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 meet the prerequisites for the AD Agent and Microsoft Active Directory. See Prerequisites for the requirements of 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.

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 to display the Add Domain dialog box.

Step 4 To continue, see Configuring the Active Directory Domain.

Step 5 For domains that have 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 is marked as disabled in the Monitoring > Properties > Identity > Users pane.

Step 6 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 that 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 incorrectly associates the user-IP mapping with the domain name that you entered 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 7 In the Active Directory Agent section, select the AD Agent group from the drop-down list. To add AD Agent groups, click Manage. For more information, see Configuring Active Directory Agents.

Step 8 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 9 Check the Enable Event Timestamp check box to enable the ASA to keep track of the last event time stamp that it receives for each identifier and to discard any message if the event time stamp is at least 5 minutes older than the ASA’s clock, or if its time stamp is earlier than the last event’s time stamp.

For a newly booted ASA that does not have knowledge of the last event time stamp, the ASA compares the event time stamp with its own clock. If the event is at least 5 minutes older, the ASA does not accept the message.

We recommend that you configure the ASA, Active Directory, and Active Directory agent to synchronize their clocks among themselves using NTP

Step 10 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 11 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 because only users of received packets are queried and stored.

Step 12 In the Error Conditions section, select whether to disable rules if 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 the Monitoring > Properties > Identity > Users pane.

Step 13 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 14 In the Error Conditions section, choose whether or not 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 15 In the Error Conditions section, choose whether to track users that are not found.

Step 16 In the Users section, choose 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. After 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 17 In the NetBIOS Logout Probe section, enable NetBIOS probing and set the probe timer (from 1 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 18 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 includes the username 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 username 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 19 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 the Configuring Active Directory Server Groups.

Configure AD Agents. See Configuring Active Directory Server Groups.

Configuring Identity-Based Security Policy

You can incorporate identity-based policy in many ASA features. Any feature that uses extended ACLs (other than those listed as unsupported in the Guidelines and Limitations) can take advantage of an identity firewall. You can now add user identity arguments to extended ACLs, as well as network-based parameters.

Features that can use identity include the following:

• Access rules—An access rule permits or denies traffic on an interface using network information. With an identity firewall, you can control access based on user identity. See firewall configuration guide.
• AAA rules—An authentication rule (also known as cut-through proxy) controls network access based on the user. Because this function is very similar to an access rule plus an identity firewall, AAA rules can now be used as a backup method of authentication if a user’s AD login expires. For example, for any user without a valid login, you can trigger a AAA rule. To ensure that the AAA rule is only triggered for users that do not have valid logins, you can specify special usernames in the extended ACL used for the access rule and for the AAA rule: None (users without a valid login) and Any (users with a valid login). In the access rule, configure your policy as usual for users and groups, but then include a AAA rule that permits all None users; you must permit these users so they can later trigger a AAA rule. Then, configure a AAA rule that denies Any users (these users are not subject to the AAA rule, and were handled already by the access rule), but permits all None users. For example:

For more information, see the legacy feature guide.

• Cloud Web Security—You can control which users are sent to the Cloud Web Security proxy server. In addition, you can configure policy on the Cloud Web Security ScanCenter that is based on user groups that are included in ASA traffic headers sent to Cloud Web Security. See the firewall configuration guide.
• VPN filter—Although a VPN does not support identity firewall ACLs in general, you can configure the ASA to enforce identity-based access rules on VPN traffic. By default, VPN traffic is not subject to access rules. You can force VPN clients to abide by access rules that use an identity firewall ACL (with the no sysopt connection permit-vpn command). You can also use an identity firewall ACL with the VPN filter feature; a VPN filter accomplishes a similar effect as allowing access rules in general.

Monitoring AD Agents

To monitor the AD Agent component of the Identity Firewall, perform the following steps:

Step 1 Choose Monitoring > Properties > Identity > AD Agent.

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

To monitor the user groups configured for the Identity Firewall, perform the following steps:

Step 1 Choose Monitoring > Properties > Identity > Group.

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 the list of user groups in the domain \ group_name format.

Monitoring Memory Usage for the Identity Firewall

To monitor the memory usage that the Identity Firewall consumes on the ASA, perform the following steps:

Step 1 Choose Monitoring > Properties > Identity > Memory Usage.

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 login security logs.

• AD Agent
• Miscellaneous
• Total Memory Usage

Note How you configure the Identity Firewall to retrieve user information from the AD Agent affects the amount of memory used by the feature. You specify whether the ASA uses on-demand retrieval or full download retrieval. Choosing on-demand retrieval has the benefit of using less memory because only users of received packets are queried and stored. For more information, see Configuring Identity Options.

Monitoring Users for the Identity Firewall

To display information about all users contained in the IP-user mapping database used by the Identity Firewall, perform the following steps:

Step 1 Choose Monitoring > Properties > Identity > User.

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 the default domain is not specified, the default domain is LOCAL.

The idle time is stored on a per-user basis instead of by 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-in users have the disabled status. 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 tab lets you view important information about the traffic passing through your ASA. Choose the Home > Firewall Dashboard > Top Usage Statistics > Top 10 Users tab.

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—the Microsoft Active Directory and Cisco Active Directory (AD) Agent. For more information, see Configuring the Identity Firewall.

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.