Requiring authentication makes it possible to configure access policies based on user identity, and provides user-based usage information in dashboards.
- Policy Name
The name of the policy. This name appears in Event Viewer for authentication events generated by traffic that matches this policy, so choose a name that will help you analyze event data.
- Enable Policy: On/Off
Whether the policy is enabled. You can turn a policy off to temporarily disable it without deleting the policy. Disabled policies are never applied to traffic.
- Traffic Matching Criteria
The traffic matching criteria that identifies the traffic to which the policy applies. To match the policy, the flow must match every specified property, that is, there is an AND relationship between the properties. Use the default Any selection if you do not want to restrict the policy based on that condition. Leave all fields with the default Any to match every possible traffic flow.
All of the following criteria are used to determine the traffic to which a policy applies.
- Source—A list of network groups. If a packet matches any selected object, it is considered to satisfy the source condition.
- Destination—A list of network groups. If a packet matches any selected object, it is considered to satisfy the source condition.
- Service—A list of service groups that define protocol and port combinations. If a packet matches any selected object, it is considered to satisfy the service condition.
(Multiple Device mode.) When using PRSM in Multiple Device mode, you can also use network objects or groups defined on the device that contains the CX device for source or destination criteria, or ASA service objects for the service criteria. The network group objects come in two types: one that can be used on both ASA and CX devices, and one that can be used on CX devices only, which is explicitly called CX network group.
For information on how to select items, including how to add, edit, or remove them, filter the selection list, create or edit objects, or view object contents, see Selecting Items.
The directory realm used to authenticate traffic. If the user is prompted for authentication, servers in this realm are used to verify the credentials supplied by the user.
The type of authentication required for matching traffic flows. The options differ based on the directory type and whether you configured a CDA or AD agent. Select one of these options based on availability:
- Get Identity Using AD Agent
(AD with configured CDA or AD agent only.) If a passive user-to-IP address mapping was obtained from the CDA or AD agent, use it.
Select Yes or No for Do you want to use active authentication if AD agent cannot identify the user? If you select Yes (the default), and a passive mapping for the user’s IP address was not obtained from the CDA or AD agent, the system tries to get identity through the client, either transparently (NTLM, Kerberos only) or by prompting the user to authenticate.
If you select No, and a passive mapping is not available, the user’s IP address will not be associated with a user name, and identity-based access rules will not be applied to the user’s traffic.
- Get Identity via Active Authentication
(All directory types.) Obtain identity information even if a passive mapping exists for the user. Identity is obtained transparently if you use NTLM or Kerberos and the clients have the correct configuration; otherwise, users are prompted to authenticate.
Once authenticated, the user’s IP address is considered a surrogate for the user, and the user is not required to reauthenticate for every subsequent connection. Reauthentication is required after the authenticated session duration setting is exceeded.
- Do Not Require Authentication
(All directory types except AD with a CDA or AD agent configured.) Do not obtain user identity. Identity-based access rules will not be applied to the user’s traffic.
Active authentication is applied to HTTP or decrypted HTTPS 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.
- Authentication Type
(AD only.) If you select an option that requires or allows for active authentication, select the authentication method to use during active authentication. This setting applies for AD realms only; LDAP realms always use basic authentication. You can use the following authentication methods; select one for which your AD servers are configured:
- NTLM (NT LAN Manager). Supported by all Windows platforms.
- Kerberos. Supported for Windows XP only.
- Basic. This is the default. Supported on all platforms.
- Advanced. Select this option to 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, Kerberos, NTLM, then basic.
If you allow for NTLM or Kerberos, clients can configure their browsers to allow for transparent authentication as described in Enabling Transparent User Authentication. Otherwise, users are prompted for their directory username and password.
- Exclude User Agent
If you select an option that requires or allows for active authentication, you can exclude user agents (applications) that cannot respond to authentication requests, such as software update applications or remote access VPN clients that send authentication traffic through the VPN tunnel (such as Android 2.3 with AnyConnect 2.5). Select the user agent policy objects that identity the user agents (in the Include list in the object) that you do not want to prompt for authentication.
- Interface Roles
The criteria that identifies the parent device’s interfaces to which the policy applies. To match the policy, the traffic must enter the device on one of the source interfaces and leave the device on one of the destination interfaces. The default is any interface for both source and destination, meaning the policy is not restricted to specific interfaces.
To limit the policy to specific interfaces, select the appropriate interface role objects in either the Source Interface Role or Destination Interface Role fields, or both. The interface role objects define the interface names or naming patterns for the interfaces.
If you specify interface roles, and no interfaces on the device match the interface names defined in the role, the policy will never apply to any traffic on the device.
Words or phrases that help you identify this item. For example, you can assign the same tag to multiple items to make it easy to view them through a search. Tags could identify use case, purpose, or any other characteristic you choose. These tags are for your purposes only, and do not affect how the system or policies function. You can enter (or select) more than one tag.
- Ticket ID
A case or ticket identifier from your support system (for example, Remedy). If you are making a change that is related to a network support case, you can enter the ticket ID here for tracking purposes. You can enter new IDs or select from existing IDs that are used in pending changes; specify as many separate IDs as needed. (The list does not show IDs used in already-committed changes.)