Filter
Top Products
13-22
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 13 Managing Identity-Aware Firewall Policies
Configuring Identity-Aware Firewall Policies
Guidelines For Adding Identity-Based Rules
Following are some general guidelines and recommendations for adding identity-based rules:
• FQDN (fully-qualified domain name) network/host objects are allowed in both Source and
Destination fields. For information on configuring these objects, see Creating Networks/Hosts
Objects, page 6-76.
• User, user group, and identity user group objects, which specify Active Directory (AD) user or user
group names, are defined in a separate field: User. If you configure a rule with one or more user
names, user group names, or identity user group objects, the specifications modify the Source
address configuration only. They never apply to the addresses specified in the Destination field. For
information on configuring these identity user group objects, see Creating Identity User Group
Objects, page 13-19.
You must always configure a source address in a rule, even if you want the rule to primarily operate
based on the specified users or user groups. The source and user specifications conjoin to control
the scope of the rule. Based on the value of the Source field, the rules operate as follows:
–
Source = any—Use “any” as the source if you want the rule to apply based solely on the user
specifications. These rules will match the user specification regardless of the workstation IP
address from which the user sends traffic.
–
Source = anything else—If you specify anything other than “any” as the source address, the
rule applies only if the user sends traffic from an IP address that matches the source address
specification. Use this technique if you want to provide variable services based on the source
network.
For example, you might have an internal trusted network from which you would allow access
to a sensitive destination for users in a particular user group, although you would deny access
even to those users if they were outside of the trusted network. In this case, you would create a
permit rule that specified the trusted network as the source, the trusted user group as the user,
and the sensitive server as the destination. You could also create a specific deny rule with just
the source and destination specified, or allow the default deny any rule to capture the
non-matching traffic.
• Evaluate whether there are classes of traffic that will never be sensitive to user identity. For example,
you might allow DNS traffic for all users. Place these types of rules above identity-based rules so
that matching traffic can be quickly allowed before the device needs to evaluate identity-based rules.
• When troubleshooting rules, keep in mind that ultimately rules are applied based on IP address.
FQDN rule matching is based on DNS lookups, and the IP address of a host can change between a
successful lookup and the next time the lookup is refreshed. For users, IP address mappings are
obtained from the AD agent configured in the network or by authentications conducted by the ASA
itself.
• FQDN and user specifications are completely independent. You can use one without the other.
Firewall Policies That Allow Identity-Based Rules
Identity-based rules are allowed on ASA 8.4.2+ only. The following policies allow you to configure
identity-based rules:
• AAA Rules—Select Firewall > AAA Rules and see Configuring AAA Rules for ASA, PIX, and
FWSM Devices, page 15-4.
Tip You can use AAA rules to configure cut-through proxy, which allows users whose IP address mappings
have become invalid, resulting in denied network access, to authenticate directly to the ASA to resolve
the mapping problem. See Configuring Cut-Through Proxy, page 13-23.