Overview of Identity-Aware Firewall Policies
In traditional firewall policies, decisions are made based on source and destination IP addresses, ports, and services. The Identity Firewall in the ASA provides more granular control based on either or both of the following:
-
User identity—You can configure access rules and security policies based on user names and user group names rather than through source IP addresses alone. 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. For information on setting up and configuring the AD agent, see Installation and Setup Guide for the Active Directory Agent on Cisco.com at http://www.cisco.com/en/US/products/ps6120/prod_installation_guides_list.html.
-
FQDN network objects—You can use a host’s fully-qualified domain name (FQDN) in a rule instead of its IP address. Thus, if the host’s address changes (for example, because it acquires the address through DHCP), the rule will still apply.
Identity-based firewall services enhance the existing access control and security policy mechanisms by allowing users or groups to be specified as sources, and FQDNs in place of source or destination 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. The rules will apply to a user regardless of where the user connects in the network.
-
Simplifying the creation of security policies.
-
Providing the ability to easily identify user activities on network resources.
-
Simplify user activity monitoring.
This section contains the following topics:
User Identity Acquisition
When you specify Active Directory user names or user group names in a firewall policy, the ASA eventually needs to map the name to an IP address to process packets. The ASA uses two primary sources for this information:
-
User group membership—If you specify a user group in a rule, the ASA contacts the configured Active Directory (AD) server to obtain group membership.
-
User-to-IP address mappings—For users who log into the network domain on your standard (non-VPN) network, the AD agent, in communication with the AD server, obtains the login information and creates a user-to-IP address mapping table. This information is supplied to the ASA.
You must install and configure the required AD servers and agents before you can configure user-based identity firewall policies. For an explanation of the various deployment scenarios, see the ASA configuration guide for ASDM or CLI at http://www.cisco.com/en/US/products/ps6120/products_installation_and_configuration_guides_list.html .
User names are acquired for the following types of traffic, and include the AD domain unless noted otherwise:
-
Standard traffic.
-
Remote access VPN, including IPsec IKEv1 and IKEv2, AnyConnect clients, and L2TP VPN. If you use LDAP authentication for the VPN, and use the same server group for a domain for the VPN and identity firewall, the users are associated with the domain used for authentication. For all other authorization mechanisms, users acquired through VPN are considered to be in the LOCAL domain. The ASA reports these users to the AD agent, which distributes them to other ASAs or clients registered with the AD agent.
Note |
User names are not acquired for clientless SSL VPN. |
-
IPv4 cut-through proxy. User names are not acquired for IPv6 cut-through proxy. If the user includes the domain name during authentication, the user is associated with the domain name. Otherwise, the domain is the default domain as configured in the Identity Options policy. See Configuring Cut-Through Proxy.
Requirements for Identity-Aware Firewall Policies
Identity-aware firewall policies are not supported by all types of device and operating systems. The following table explains the requirements and some limits for implementing these types of policies in your network.
Requirement |
Description |
||
---|---|---|---|
Firewall device |
ASA running ASA Software version 8.4(2) or later, but not including the ASA-SM running 8.5(1). Single or multiple context configurations.
You can register up to 100 ASAs with a single Active Directory agent. |
||
Active Directory (AD) |
You must use Active Directory to define users and user groups. The ASA obtains user group information directly from the AD server, which runs the LDAP protocol. You cannot use other types of LDAP servers. For detailed information on the types of AD servers supported, and their configuration requirements, see Installation and Setup Guide for the Active Directory Agent on Cisco.com at https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-installation-guides-list.html .
|
||
AD agent |
You must configure off-box AD agents to act as an intermediary between the ASA and the AD servers. The AD agent maintains an active mapping of users to IP address. By default, except for the 5505, the ASA obtains this list when it boots or reloads, and the AD agent sends new mappings as they are collected. The 5505 queries the AD agent on an as-needed basis in response to traffic matching rules that include identity criteria. We recommend that you use this default behavior, although you can change it using the Identity Options policy. The AD agent uses the RADIUS protocol. For information on setting up and configuring the AD agent, see Installation and Setup Guide for the Active Directory Agent on Cisco.com at http://www.cisco.com/en/US/products/ps6120/prod_installation_guides_list.html. |
||
Client systems |
Users who pass traffic through the device must use one of the following client platforms:
|
||
IPv6 |
IPv6 is supported with the following exceptions:
There are two options for disabling the use of these temporary addresses:
netsh interface ipv6 set privacy state=disable netsh interface ipv6 set global randomizeidentifiers=disabled |
||
NetBIOS logout probing (Optional.) |
If you enable NetBIOS logout probing, the ASA can use NetBIOS to determine if an inactive user is logged off so the user can be removed from the database. The probe uses UDP-encapsulated NetBIOS traffic. Thus, you must ensure that access rules allow the following traffic on the networks between the ASA, AD agent, and user workstations:
In addition, you must configure workstations to provide user name information in NetBIOS reply packets. For Windows workstations, you need to enable the messenger service and configure WINS. If the messenger service is not turned on, the response from the workstation is the same whether the user is logged on or off. Tips
|
||
DNS configuration (Required for fully-qualified domain name usage.) |
If you use fully-qualified domain name (FQDN) network/host objects in firewall rules, you must configure the domain name system (DNS) settings as described in DNS Page. These settings identify the DNS servers used for looking up the names to determine the associated IP address. All processing is ultimately based on the IP address. When configuring DNS for FQDN usage, consider the following points:
Looked at another way, this means that you do not need to specify every version of an FQDN host name in your rules. When you know that several names always point to the same host, you can configure rules for the most commonly-used name and they will apply to all synonyms of that name. |
||
Maximum limits |
There are limits to the number of users, user groups, and IP addresses per user. If these limits are exceeded, identity-aware processing will not occur for the additional traffic:
|
Configuring the Firewall to Provide Identity-Aware Services
To provide identity-aware firewall services to your network, you need to configure several policies to enable the firewall to process user-based or fully-qualified domain name (FQDN)-based rules. The ASA depends on other servers in your network to provide the user, user group, and FQDN name resolution services required to implement your identity-aware policies.
The required configuration depends on which aspects of identity awareness that you will use:
-
User, user group resolution—To use identity user group objects in your firewall rules, you must configure several objects and policies to identify the Active Directory servers that will supply user and user group information.
-
FQDN resolution—To use FQDN network/host objects in your firewall rules, you must configure DNS servers to resolve FQDNs to IP addresses.
This procedure explains the overall process for implementing identity-aware policies.
Before You Begin
Your network must meet the requirements explained in Requirements for Identity-Aware Firewall Policies. The following procedure assumes that you are already using Active Directory (AD), that you have installed and configured the AD agents, and that these services are working correctly.
Procedure
Step 1 |
Enable AD user and user group resolution.
|
Step 2 |
Enable FQDN network/host object resolution.
|
Step 3 |
Configure firewall rules to use FQDN objects, usernames, user group names, or identity user group objects. See Configuring Identity-Based Firewall Rules. |
Step 4 |
Monitor the identity firewall system. See Monitoring Identity Firewall Policies. |