Procedure

• To create a new rule, click the plus button. To understand identity source objects and how they could affect your rules, see About Identity Sources 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.

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.

You must select the AD identity realm that includes the user accounts for passive and active authentication rules. choose one of the following:

• Passive Auth—Use passive authentication to determine user identity. All configured identity sources are shown. The rule automatically uses all configured sources.

• Active AuthUse active authentication to determine user identity. Active authentication is applied to HTTP traffic only. If any other t—ype 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 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.

• 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 PagePrompt 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.

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.

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.