The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure the ASA for the Identity Firewall and includes the following sections:
This section includes the following topics:
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 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:
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.
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 40-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 40-1 Identity Firewall Components
The Identity Firewall includes the following key features.
You can deploy the components of the Identity Firewall in the following ways, depending on your environmental requirements.
Figure 40-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 40-2 Deployment Scenario without Redundancy
Figure 40-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 40-3 Deployment Scenario with Redundant Components
Figure 40-4 shows how all Identity Firewall components—Active Directory server, the AD Agent, and the clients—are installed and communicate on the LAN.
Figure 40-4 LAN -based Deployment
Figure 40-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 40-5 WAN-based Deployment
Figure 40-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 40-6 WAN-based Deployment with Remote AD Agent
Figure 40-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 40-7 WAN-based Deployment with Remote AD Agent and AD Servers
|
|
---|---|
This section includes the guidelines and limitations for this feature.
Supported in single and multiple context mode.
Supported in routed and transparent firewall modes.
Additional Guidelines and Limitations
– Group policy (except for VPN filters)
By design, if a previous download session has finished, the ASA does not allow you to issue this command again.
As a result, if the user-IP database is very large, the previous download session is not finished yet, and you issue another user-identity update active-user-database command, the following error message appears:
You need to wait until the previous session is completely finished, then you can issue another user-identity update active-user-database command.
Another example of this behavior occurs because of packet loss from the AD Agent to the ASA.
When you issue a user-identity update active-user-database command, the ASA requests the total number of user-IP mapped entries to be downloaded. Then the AD Agent initiates a UDP connection to the ASA and sends the change of authorization request packet.
If for some reason the packet is lost, there is no way for the ASA to discern this. As a result, the ASA holds the session for 4-5 minutes, during which time this error message continues to appear if you have issued the user-identity update active-user-database command.
– Authentication port for UDP—1645
– Accounting port for UDP—1646
The listening port is used to send change of authorization requests from the CDA to the ASA or to the WSA.
Before configuring the Identity Firewall in the ASA, you must meet the prerequisites for the AD Agent and Microsoft Active Directory.
Note Windows 2003 R2 is not supported for the AD Agent server.
Note Before running the AD Agent Installer, you must install the patches listed in the README First for the Cisco Active Directory Agent on each 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.
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.
See also the 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 Agents.
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 Security Policy. After the AD domain and AD Agent are configured, you can create identity-based object groups and ACLs for use in many features.
See Configuring Identity-Based Security Policy.
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.
To configure the Active Directory domain, perform the following steps:
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.
Make sure that you have the following information before configuring the AD Agents:
To configure the AD Agents, perform the following steps:
Configure access rules for the Identity Firewall. See Configuring Identity-Based Security Policy.
Perform this procedure 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.
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:
Configure the Active Directory domain and server groups. See Configuring the Active Directory Domain.
Configure AD Agents. See Configuring Active Directory Agents.
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:
For more information, see the legacy feature guide.
To activate the collection of user statistics by the Modular Policy Framework and match lookup actions for the Identify Firewall, enter the following command:
This section includes the following topics:
This example shows a typical cut-through proxy configuration to allow a user to log in through the ASA. In this example, the following conditions apply:
In this example, the following guidelines apply:
Some traffic might need to bypass the Identity Firewall.
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 IP-user mapping of authenticated users is forwarded to all ASA contexts that include the input interface where HTTP/HTTPS packets are received and authenticated. The ASA designates users logging in through a VPN as belonging the LOCAL domain.
There are two different ways to apply identity firewall (IDFW) rules to VPN users:
By default, the sysopt connection permit-vpn command is enabled and VPN traffic is exempted from an access list check. To apply interface-based ACL rules for VPN traffic, VPN traffic access list bypassing needs to be disabled.
In this example, if the user logs in from the outside interface, the IDFW rules control which network resources are accessible. All VPN users are to be stored under the LOCAL domain. Therefore, it is only meaningful to apply the rules for LOCAL users or object groups that include LOCAL users.
By default, the sysopt connection permit-vpn command is enabled, with VPN traffic access bypassing enabled. A VPN filter can be used to apply the IDFW rules to the VPN traffic. A VPN filter with IDFW rules can be defined in the CLI username and group policy.
In the example, when user idfw logs in, the user can access network resources in the 10.0.00/24 subnet. However, when user user1 logs in, access to network resources in 10.0.00/24 subnet is denied. Note that all VPN users are stored under the LOCAL domain. Therefore, it is only meaningful to apply the rules for LOCAL users or object groups that include LOCAL users.
Note IDFW rules can only be applied to VPN filters under group policy and are not available in all of the other group policy features.
This section includes the following topics:
To obtain troubleshooting information for the AD Agent, use one of the following commands:
These commands display the following information about the primary and secondary AD Agents:
To obtain troubleshooting information for the user groups configured for the Identity Firewall, use the show user-identity group command.
To obtain troubleshooting information for memory usage for the Identity Firewall, use the show user-identity memory command.
The command displays the memory usage in bytes of various modules in the Identity Firewall:
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.
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.
To obtain troubleshooting information for the AD Agent, enter one of the following commands:
These commands display 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 command user - identity action domain - controller - down domain _ name disable - user - identity - rule is configured and the specified domain is down, or if the user - identity action ad - agent - down disable - user - identity - rule command is configured and the AD Agent is down, all the logged-in users have the disabled status.
Table 40-1 lists the release history for this feature.