Identity rules determine whether user identity information should be collected for matching traffic. You can configure No Authentication if you do not want to collect user identity information for matching traffic.
Keep in mind that regardless of your rule configuration, active authentication is performed on HTTP traffic only. Thus, you do not need to create rules to exclude non-HTTP traffic from active authentication. You can simply apply an active authentication rule to all sources and destinations if you want to get user identity information for all HTTP traffic.
Note: Also keep in mind that a failure to authentication has no impact on network access. Identity policies collect user identity information only. You must use access rules if you want to prevent users who failed to authenticate from accessing the network.
- Open the Devices & Services page, select the device for which you are configuring an identity policy, and click Policy in the Management pane.
- Click Identity in the policy bar.
- Do any of the following:
- To create a new rule, click the plus button. To understand identity source objects and how they could affect your rules, see Identity Sources in Identity Policies for more information.
- To edit an existing rule, click the rule you want to edit and click Edit in the Actions pane at the right.
- To delete a rule you no longer need, click the rule you want to delete and click Remove in the Actions pane at the right.
- In Order, select where you want to insert the rule in the ordered list of rules.
Rules are applied on a first-match basis, so you must ensure that rules with highly specific traffic matching criteria appear above policies that have more general criteria that would otherwise apply to the matching traffic.
The default is to add the rule to the end of the list. If you want to change a rule's location later, edit this option.
- In Name, enter a name for the rule.
- Select the Action that the FTD should apply on a match and if necessary, an AD Identity Source.
You must select the AD identity realm that includes the user accounts for passive and active authentication rules.
- Passive Auth—Use passive authentication to determine user identity. All configured identity sources are shown. The rule automatically uses all configured sources.
- Active Auth—Use active authentication to determine user identity. Active authentication is applied to HTTP traffic only. If any other type of traffic matches an identity policy that requires or allows active authentication, then active authentication will not be attempted.
- No Auth—Do not obtain user identity. Identity-based access rules will not be applied to this traffic. These users are marked as No Authentication Required.
Note: For both Passive Auth and Active Auth, you can opt to select an Active Directory (AD) Realm identity source. If you do not have any identity source objects readily prepared, click Create new object to launch the identity source object wizard. See Create and Edit a Firepower Threat Defense Active Directory Realm Object for more information.
- (Active Authentication only.) Click the Active authentication tab and select the authentication method (Type) supported by your directory server.
- HTTP Basic—Authenticate users using an unencrypted HTTP Basic Authentication connection. Users log in to the network using their browser's default authentication popup window. This is the default.
- NTLM—Authenticate users using an NT LAN Manager (NTLM) connection. This selection is only available when you select an AD realm. Users log in to the network using their browser's default authentication popup window, although you can configure Internet Explorer and Firefox browsers to transparently authenticate using their Windows domain login. That task is done in FDM, see Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager > Security Policies > Identity Policies > Enabling Transparent User Authentication for instructions.
- HTTP Negotiate—Allow the device to negotiate the method between the user agent (the application the user is using to initiate the traffic flow) and the Active Directory server. Negotiation results in the strongest commonly supported method being used, in order, NTLM, then basic. Users log in to the network using their browser's default authentication popup window.
- HTTP Response Page—Prompt users to authenticate using a system-provided web page. This is a form of HTTP Basic authentication.
Note: For the HTTP Basic, HTTP Response Page, and NTLM authentication methods, the user is redirected to the captive portal using the IP address of the interface. However, for HTTP Negotiate, the user is redirected using the fully-qualified DNS name firewall-hostname.AD-domain-name . If you want to use HTTP Negotiate, you must also update your DNS server to map this name to the IP addresses of all inside interfaces where you are requiring active authentication. Otherwise, the redirection cannot complete, and users cannot authenticate.
- (Active authentication only.) Select Fall Back as Guest > On/Off to determine whether users who fail active authentication are labeled as Guest users.
Users get 3 chances to successfully authenticate. If they fail, your selection for this option determines how the user is marked. You can deploy access rules based on these values.
- Fall Back as Guest > On—Users are marked as Guest.
- Fall Back as Guest > Off—Users are marked as Failed Authentication.
- Define the traffic matching criteria on the Source and Destination tabs for Passive authentication, Active authentication, or No Authentication rule actions.
Keep in mind that active authentication will be attempted with HTTP traffic only. Therefore, there is no need to configure No Auth rules for non-HTTP traffic, and there is no point in creating Active Authentication rules for any non-HTTP traffic. However, passive authentication is valid for any type of traffic.
The Source/Destination criteria of an identity rule define the security zones (interfaces) through which the traffic passes, the IP addresses or the country or continent (geographical location) for the IP address, or the protocols and ports used in the traffic. The default is any zone, address, geographical location, protocol, and port.
To modify a condition, you click the button within that condition, select the desired object or element, and click OK in the popup dialog box. If the criterion requires an object, you can click Create New Object if the object you require does not exist.
To remove an object from a condition, hover over the object and click the X.
You can configure the following traffic matching criteria.
Source Zones, Destination Zones
The security zone objects that define the interfaces through which the traffic passes. You can define one, both, or neither criteria: any criteria not specified applies to traffic on any interface.
- To match traffic leaving the device from an interface in the zone, add that zone to the Destination Zones.
- To match traffic entering the device from an interface in the zone, add that zone to the Source Zones.
- If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.
Use this criteria when the rule should apply based on where the traffic enters or exits the device. For example, if you want to ensure that user identity is collected from all traffic originating from inside networks, select an inside zone as the Source Zones while leaving the destination zone empty.
Note: You cannot mix passive and routed security zones in a single rule. In addition, you can specify passive security zones as source zones only, you cannot specify them as destination zones.
Source Networks, Destination Networks
The network objects or geographical locations that define the network addresses or locations of the traffic.
- To match traffic from an IP address or geographical location, configure the Source Networks.
- To match traffic to an IP address or geographical location, configure the Destination Networks.
- If you add both source and destination network conditions to a rule, matching traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.
When you add this criteria, you select from the following tabs:
- Network—Select the network objects or groups that define the source or destination IP addresses for the traffic you want to control.
- Country/Continent-Select the geographical location to control traffic based on its source or destination country or continent. Selecting a continent selects all countries within the continent. Besides selecting geographical location directly in the rule, you can also select a geolocation object that you created to define the location. Using geographical location, you could easily restrict access to a particular country without needing to know all of the potential IP addresses used there.
- Custom Geolocation—Select (or create) a geolocation object that has exactly the countries and continents you specify.
Note: To ensure you are using up-to-date geographical location data to filter your traffic, Cisco strongly recommends that you regularly update the geolocation database (GeoDB). See Update Geolocation Database for more information.
Source Ports, Destination Ports/Protocols
The port objects that define the protocols used in the traffic. For TCP/UDP, this can include ports.
- To match traffic from a protocol or port, configure the Source Ports. Source ports can be TCP/UDP only.
- To match traffic to a protocol or port, configure the Destination Ports/Protocols.
- To match traffic both originating from specific TCP/UDP ports and destined for specific TCP/UDP ports, configure both. If you add both source and destination ports to a condition, you can only add ports that share a single transport protocol, TCP or UDP. For example, you could target traffic from port TCP/80 to port TCP/8080.
- Click Save.
- Return to the Devices & Services page.
- Select the device to which you added these rules to the identity policy.
- Review and deploy now the changes you made, or wait and deploy multiple changes at once.