You can create access policies based on user identity rather than IP addresses. To enable identity-based services, you configure policies and options to obtain user identity, and then use identity objects in your access policies. The following topics describe authentication and identity services and how to configure them.
Authentication is the act of confirming the identity of a user. You can obtain user identities passively or actively.
With passive authentication, user identity is obtained by checking a mapping of IP addresses to user identity collected by the CDA or AD agent application. Authentication is passive because the user is not prompted to provide credentials.
With active authentication, when an HTTP or decrypted HTTPS traffic flow comes from an IP address for which ASA CX has no user-identity mapping, you can decide whether to authenticate the user who initiated the traffic flow against the directories configured for the network. If the user successfully authenticates, the IP address is considered to have the identity of the authenticated user.
You can apply identity-based access policies to traffic that has either a passive or active user mapping, controlling network access based on who is trying to access the resource rather than controlling it by static IP address-based policies.
There are many separate features involved in providing authentication and identity services:
You can use AAA servers running LDAP (Lightweight Directory Access Protocol) to implement authentication and identity services. Following are the supported servers and the authentication methods you can use with each.
To enable identity services, so that traffic flows can be conditionally handled based on the user who initiates the flow, the CX device maps the user name to the IP address of the user’s device.
Based on how the user-to-IP address mapping is obtained, users are considered to have one of the following identity types:
If you configure identity policies to require or allow for active authentication, users might be prompted to authenticate when they make HTTP requests, or HTTPS requests that are decrypted by decryption policies. To help users authenticate correctly, ensure that they know the following:
The following procedure provides an overview of the process for configuring authentication and identity services. Use this procedure to understand the general configuration process and see the referenced topics for detailed steps.
Step 1 |
Configure directory realms as described in Configuring Directory Realms. The directory realms define the directory servers that contain user and user group information. Users authenticate against these servers to provide user identity, which can then be used to provide identity-based access control and reporting. |
||
Step 2 |
(Optional)Configure the Active Directory (AD) agent as described in Identifying the Active Directory Agent. If you are using Active Directory in your directory realm, you can install the Context Directory Agent (CDA) or Active Directory agent to provide passive user-to-IP address mappings based on Windows login authentications. |
||
Step 3 |
(Optional)Change the authentication settings if necessary as described in Configuring Authentication Settings. Authentication settings have default values appropriate for most networks, so you might not need to change them. |
||
Step 4 |
Create at least one identity policy for each directory realm as described in Configuring Identity Policies. Identity policies determine the type of identity users must supply, either through active authentication, passive mapping, or none at all if you elect to not require authentication. You must have at least one policy per realm, or you will not get user identity mappings for users defined within the realm.
|
||
Step 5 |
If you are using active authentication, and you want to enforce authentication for HTTPS requests, configure decryption policies to decrypt secure traffic from the sources you want to authenticate. The decryption policy should apply the Decrypt Everything action. |
||
Step 6 |
(Optional)When using Active Directory, you can configure client browsers to provide transparent authentication for NTLM or Kerberos as described in Enabling Transparent User Authentication. When configured to provide transparent authentication, browsers can respond to authentication requests from trusted sources by providing Windows login information without prompting users. Thus, active authentication occurs but users are not aware that authentication happened and they are not inconvenienced or confused by an unexpected authentication prompt. |
||
Step 7 |
(Optional)Create identity-based access policies as described in Configuring Context-Aware Access Policies. You can control access to a destination by using identity policy objects in the source definition of an access policy. The identity object defines the user or user group names that are allowed, or denied, access to a destination. For information on identity policy objects, see CX Identity Objects. |
||
Step 8 |
Analyze network traffic using identity information in dashboards and events. Many dashboards, such as the Users dashboard, includes identity-based traffic analysis. You can also access dashboards related to identity-based access policies by looking at the policy hits dashboard for the policy. Use this information to determine the efficacy of your policy and to identify users who are violating acceptable use policies. For information on dashboards, see Viewing Dashboards and Reports . In addition to dashboards, the Event Viewer includes user name information on events when available. For information on Event Viewer, see Viewing Events. |
A directory realm is a named list of directory servers. For Active Directory (AD), a realm is equivalent to an AD domain. For LDAP, the realm is any LDAP server and its redundant servers, that is, all servers with the same top level distinguished name (DN).
You use directory realms:
To open the directory realms page, where you can add, edit, or delete realms and the directory servers contained in them, or reorder the directory servers within a realm, select .
The Directory Realm page includes the following items:
Contains the following commands:
The list shows all directory realms and within each realm is an ordered list of directory servers contained in the realm. The first server in the list is always used unless it becomes unavailable, in which case the next server in the list is tried until a response is received.
There can be a single Active Directory realm. When binding to Active Directory, the first AD server in the realm is used. There can by any number of Standard LDAP realms.
To see the commands related to a directory realm or server, mouse over the directory realm header or the directory server row. The following are the available commands:
A directory realm is a named list of directory servers. For Active Directory (AD), a realm is equivalent to an AD domain. For LDAP, the realm is any LDAP server and its redundant servers, that is, all servers with the same top level distinguished name (DN).
To configure a directory realm, you must create the realm and then add directory servers to the realm. The following procedure explains both aspects.
![]() Tip |
(Single Device mode.) When you create your first directory realm, a default identity policy is automatically created for that realm. You can edit the policy to change any characteristic of the policy to suit your needs. In Multiple Device mode, no default policy is created. |
The following table describes properties for directories that you include in directory realms. Where indicated, some properties apply to certain directory types only. For more information about LDAP properties and their syntax, refer to RFC 2253.
Property |
Description |
||
---|---|---|---|
Directory Hostname |
The DNS name or IP address of the directory server. |
||
Port |
The port number used for communications with the server. The default is 389.
|
||
LDAP Login Name (LDAP only.) |
The distinguished name of the directory object in the LDAP hierarchy used for authenticated binding. The LDAP login name represents a user record in the LDAP server that the administrator uses for binding (administrator privileges are not required for the user). For example, cn=Administrator,dc=example,dc=com. This string is case-sensitive and alphanumeric. Special characters are allowed. If you do not specify a name, the system will attempt an anonymous bind to LDAP for querying user and group information. |
||
AD Login Name (AD only.) |
The user name used for authenticated binding with the AD server, for example, username@example.com. |
||
AD/LDAP Password |
The password for the user specified in AD/LDAP Login Name. |
||
User Search Base |
The LDAP search base distinguished name used to fully-qualify usernames being authenticated against LDAP directories. The field also defines the location in the LDAP hierarchy for searching or querying user information in both LDAP and AD. For example, cn=users,dc=example,dc=com. The maximum length is 128 characters. The string is case-sensitive. Spaces are not permitted, but other special characters are allowed. If you do not specify a user search base, the system will create a generic one consisting of the entire domain components of the directory name. For example, if the directory name is ad.example.com, the constructed qualifier would be dc=example,dc=com. The generic name might or might not work in your network, so it is best to explicitly enter a qualifier. For standard LDAP, you probably will always need to explicitly enter a qualifier. If you use an IP address instead of a DNS name, you will always need to enter a qualifier. |
||
Group Search Base |
The LDAP search base distinguished name used to search individual groups for user membership for authorization against LDAP directories. The field also defines the location in the LDAP hierarchy for searching or querying user group information in both LDAP and AD. For example, ou=groups,dc=example,dc=com. The maximum length is 128 characters. The string is case-sensitive. Spaces are not permitted, but other special characters are allowed. If you do not specify a group search base, the system will create a generic one consisting of the entire domain components of the directory name. For example, if the directory name is ad.example.com, the constructed qualifier would be dc=example,dc=com. The generic name might or might not work in your network, so it is best to explicitly enter a qualifier. If you use an IP address instead of a DNS name, you will always need to enter a qualifier.
|
||
Group Attribute |
|
||
Test Connection link |
Tests whether the properties you entered will successfully connect to the directory server. If the connection fails, check your settings. If you are certain they are correct, check whether there is a network path between the device and the directory. |
You can delete directories within a realm, or you can delete the entire directory realm. However, you cannot delete a directory realm if it is currently being used in a policy or policy object, or as the global realm for system users..
Step 1 | Select . |
Step 2 | Do any of the following: |
Use identity policies to enable policies based on user identity, including username and user group membership. Identity policies never result in dropped or blocked traffic, even if the user fails to authenticate.
Instead, identity policies can prompt users to provide username/password when attempting to connect to a destination according to your matching criteria and authentication action. If the user fails authentication, the user’s traffic is evaluated against your access rules and is permitted or denied based on those rules. If no passive authentication mapping is available for the IP address of the workstation the user is using, only the user’s IP address is used for matching purposes, so any identity-based rules you create will not apply.
Thus, you might have an identity-based access rule that would allow traffic for UserA to ServerA, and disallows all other access to ServerA. If UserA successfully authenticates, the access rule will apply and UserA will be allowed to access ServerA. If UserA fails authentication, and there is no passive mapping, the access rule will not apply and UserA will not be allowed access to ServerA.
You must create the directory realm before you can configure identity policies for the realm.
(Single Device mode only.) When you create the first directory realm, a default identity policy is automatically created for the realm. You can edit or delete the default policy to suit your needs.
Step 1 |
Select . The policies are organized in policy sets, and each policy set is a separate ordered list of policies. To see the commands related to a policy set, you must mouse-over the name of the policy set. To see the commands related to an individual policy, you must mouse-over the name of the policy. You can then select the desired command. If you need to work with an existing policy, use the filter controls to help you locate the policy you want to change. |
Step 2 |
Do one of the following:
A form opens with the identity policy properties. For detailed information about these properties, see Identity Policy Properties. |
Step 3 |
Define the traffic matching criteria using the Source, Destination, and Service fields. You can leave any field blank to not restrict traffic based on that criteria. |
Step 4 | Select the directory realm in the Realm field. |
Step 5 |
Define the action to apply to matching traffic, including authentication type and user agents if necessary.
|
Step 6 | Click Save Policy. |
Step 7 |
On the Policies page, if necessary, move the policy so that it is in priority order within the policy set. Policies within a policy set are applied on a first-match basis, so you must ensure that policies with highly specific traffic matching criteria appear above policies that have more general criteria that would otherwise apply to the matching traffic. You can drag and drop policies, or use the Move Up, Move Down links that appear when you mouse over a policy. |
Use identity policies on CX devices to define the user authentication requirements for matching traffic. Identity policies never result in blocked traffic. Instead, they determine whether user identity is obtained for the source IP address of a traffic flow.
Requiring authentication makes it possible to configure access policies based on user identity, and provides user-based usage information in dashboards.
Identity policies have the following properties:
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.
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.
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.
![]() Note |
(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:
(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.
(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.
(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.
![]() Note |
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. |
(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:
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.
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.
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.
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.)
If the ASA hosts remote access AnyConnect VPN connections, the active authentication prompt might not be displayed for certain clients. For example, Windows 7 Enterprise and Professional Editions, and Mac OS X 10.6.8, clients have this problem.
To enable active authentication prompting in these cases, you need to configure a split tunnel policy on the VPN access group to exclude the ASA's Internet IP address from the VPN. The following example shows what such a configuration would look like.
ASA-5525-3# show running-config interface ! interface GigabitEthernet0/4 nameif internet security-level 100 ip address 10.194.204.37 255.255.255.0 ! ASA-5525-3# show running-config access-list access-list Split_Tunnel_List standard permit host 10.194.204.37 ASA-5525-3# show running-config group-policy group-policy test internal group-policy test attributes vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless split-tunnel-policy excludespecified split-tunnel-network-list value Split_Tunnel_List ASA-5525-3#
With basic authentication, users are always prompted to authenticate with their directory username and password. The password is transmitted in clear text. For that reason, basic authentication is not considered a secure form of authentication.
Basic is the default authentication mechanism.
With integrated Windows authentication, you take advantage of the fact that users log into a domain to use their workstation. The browser tries to use this domain login when accessing a server, or in the case of ASA CX, the network protected by the ASA CX. The password is not transmitted. If authentication is successful, the user is transparently authenticated; the user is unaware that any authentication challenge was made or satisfied.
If the browser cannot satisfy an authentication request using the domain login credentials, the user is prompted for username and password, which is the same user experience as basic authentication. Thus, if you configure integrated Windows authentication, it can reduce the need for users to supply credentials when accessing the network or servers in the same domain.
You must configure client browsers to support integrated Windows authentication to enable transparent authentication. The configuration is explained below.
The following sections explain the general requirements and basic configuration of integrated Windows authentication for some commonly used browsers that support it; users should consult the help for their browser (or other user agent) for more detailed information, because the techniques can change between software releases.
![]() Tip |
Not all browsers support integrated Windows authentication, such as Chrome and Safari (based on the versions available when this was written). Users will be prompted for username and password. Consult the browser’s documentation to determine if support is available in the version you use. |
Users must configure their browser or user agent to implement transparent authentication. They can do this individually, or you can configure it for them and push the configuration to client workstations using your software distribution tools. If you decide to have users do it themselves, ensure that you provide the specific configuration parameters that work for your network.
![]() Tip |
Configuring transparent authentication is not a requirement, but a convenience to end users. If you do not configure transparent authentication, users are presented with a login challenge for all authentication methods. |
To configure Internet Explorer for both NTLM and Kerberos transparent authentication:
Firefox has different properties for NTLM and Kerberos authentication. The following steps explain the configuration for both methods. If you do not support both methods, skip the steps for the unsupported method.
The Cisco Active Directory Agent provides user-to-IP address mappings to all devices that are configured to use it. 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 can be augmented by other devices in the network, such as the ASA, which can provide mappings obtained from VPN and direct sources. Identity mappings obtained from the AD agent are considered passive mappings.
Both the ASA and CX devices use the same AD agent setup to enable identity-aware firewall services.
![]() Tip |
Configuring an AD agent is optional. Configure it only if you want to support passive mappings. Note that if you do not support passive mappings, you must use active authentication in your identity policies or you will not have user names available for access control, and events and dashboards will not include user information. |
The AD agent is separate software that you must install in your network. You must configure it to work with the Active Directory servers and with the network devices that are its clients. Before completing this task, install and configure the AD agent software.
Obtain the AD agent software from http://www.cisco.com/go/asa. For information on setting up and configuring the AD agent, see Installation and Setup Guide for the Active Directory Agent, available from http://www.cisco.com/en/US/products/ps6120/prod_installation_guides_list.html.
You must add the CX device as a client, which you can do before or after you complete this procedure. Keep in mind that the RADIUS shared secret configured for the CX client on the AD agent and the one configure here must be the same. The command to create the client on the AD agent is:
AD agent mappings are used only if you allow for passive mappings in the identity policies for the realm that contains the AD servers that are also clients of the AD agent. Thus, you should check your identity policies to ensure they specify Get Identity Using AD Agent. If your policies use Get Identity via Active Authentication, then the passive mappings are not used.
You can configure authentication settings related to how your identity policies function.