User Guide for ASA CX and Cisco Prime Security Manager 9.1
- Updated:
- February 4, 2014
Chapter: Managing Authentication and Identity Services
- Overview of Authentication and Identity Services
- Configuring Authentication and Identity Services
Managing Authentication and Identity Services
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.
Overview of Authentication and Identity Services
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:
- Directory realms—You must define the directory realms that provide authentication services. A realm contains one or more directory servers, such as Active Directory or OpenLDAP, that define the user names and user group membership for the network. When you configure identity policies, you must select the directory realm that will provide authentication.
- Identity policies—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, they collect user information, so that access policies can match traffic based on user identity, and so that dashboards and events include user identity information.
- Authentication settings—Authentication settings control how authentication mappings and prompts are managed. For example, you can define how long a username-to-IP address mapping remains valid before you want to prompt the user to reauthenticate. These settings have system defaults, so you need to adjust them only if you desire different settings.
- Identity policy objects—Identity policy objects define the specific user names or user group names for which you want to define access control. You can also selectively exclude names from an object. For example, you could define an object that includes the user group Eng, but exclude users Guest1 and Guest2, who are members of that group.
- Access policies—When you specify Identity policy objects as part of the source field in an access policy, you are controlling access to the destination resources based on user identity.
- CDA or Active Directory agent—(Optional.) You can install the CDA or AD agent in your network to collect user identity information when users log into the network, before they try to pass traffic through the device. This type of identity is considered a passive identity mapping. By collecting this information, you can enable identity-based access control without forcing users to authenticate directly.
- Identity-based dashboards—Many dashboards include identity information if it is available, so you can analyze the traffic on your network based on user identity. The Users dashboard is specifically designed to provide user-based network usage information. You can use these dashboards to identify cases where network acceptable use criteria are not being met.
- Supported AAA Servers and Authentication Methods
- Types of User Identity
- What to Tell Users About Authentication
Supported AAA Servers and Authentication Methods
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.
-
Microsoft Active Directory—You can use the following AD servers: You can use the following authentication methods in identity policies when using AD; you can also allow negotiation to select the strongest supported method: - OpenLDAP—Version 2.4.21 or later. The Basic authentication method is the only available method.
Types of User Identity
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:
- Active—The user was directly authenticated by the CX device. 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.
- Passive—A user-to-IP address mapping was received from the Context Directory Agent (CDA) or Active Directory (AD) agent. This type of identity can be available regardless of the types of traffic sent by the user.
- Unknown—There is no user-to-IP mapping. For example, the user tried to actively authenticate to the CX device, but authentication failed. Users who fail active authentication are represented in user dashboards under the username Realm\ANONYMOUS. Users who simply do not have a mapping because they were not required to authenticate are shown as their IP address.
What to Tell Users About Authentication
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:
- Authentication prompts will include the name of the directory realm and the ASA CX management IP address. Ensure that users understand that authentication requests that include this information are valid requests and that they should respond to them.
- When using NTLM or Kerberos authentication with Active Directory, users can enter their name in any of these formats: username, username@domain, DOMAIN\username. For example, user1, user1@example.com, ENG\user1.
- When using basic authentication, users should supply their name in username@domain format, for example, user1@example.com.
Configuring Authentication and Identity Services
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. |
Overview of Directory Realms
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:
- In identity policies, to identify the directories with which the user must authenticate. There must be an identity policy for each realm in order to use identities defined in the realm in access policies.
- On the Users page, to identify the directory that contains remote users you are granting access to the web interface.
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:
- I want to
-
Contains the following commands:
- Add Realm—To add a new directory realm. You are prompted for a name, description, and directory type. The realm name will appear in dashboards along with the username in the format Realm\username. Thus, you might want to use NetBIOS domain names for your realm names so that username strings include the expected NetBIOS domain name.
- List of directory realms and their directory servers
-
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:
- Directory realm commands:
-
- Add New Directory—To add a new directory server to the realm. The server is added to the top of the realm as the first entry. After adding the directory, move it to the desired position before committing your changes.
- Delete Realm—To delete the realm. You cannot delete a realm if it is being used in a policy or policy object, or as the global realm for system users.
- Edit Realm—To edit the realm properties.
- Directory server commands:
-
- Delete Directory—To delete the directory server.
- Edit Directory—To edit the directory server properties.
- Move Up, Move Down—To move the directory server until it is in the desired position. The up and down commands move the directory a single row. You can also click and drag a directory to the desired location.
Configuring Directory Realms
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. |
Directory Properties
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. |
Navigation Path
Deleting Directory Realms or Directories
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: |
Configuring Identity Policies
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.
- By active or passive authentication, you can ensure that the user associated with a traffic flow is known, allowing identity-based access rules to function correctly, and providing user information in dashboards and events.
- 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. Thus, it is not necessary to create Do Not Require Authentication policies for non-HTTP/HTTPS traffic. Likewise, it is not meaningful to create a policy that applies the Get Identity via Active Authentication action for traffic matching criteria that excludes HTTP traffic, for example, by selecting a service group that specifies ICMP as the only service type.
- Identity policies are applied based on first match for traffic matching criteria. Ensure that you define the matching criteria precisely so that the desired action, including the directory realm to use, is applied to each traffic class.
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. |
Identity Policy Properties
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:
- 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.
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.
- Realm
-
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.
- Action
-
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.
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.
- 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.
- Tags
-
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.)
Navigation Path
Enabling Active Authentication
- The class map for the traffic redirection policy on the ASA must include the auth-proxy keyword, for example cxsc fail-open auth-proxy. If you configure redirection using PRSM, the keyword is automatically included.
- The default port used by the ASA for active authentication is tcp/885. You can configure a different port using the cxsc auth-proxy port number command using the ASA CLI. A non-default port must be higher than 1024. You can see the currently configured port using the show run all cxsc command.
- If there are firewalls between the ASA and the user, you must open the authentication port on those firewalls.
- Ensure that time settings are consistent among the directory servers, ASA CX, and clients. A time shift among these devices can prevent successful user authentication. “Consistent” means that you can use different time zones, but the time should be the same relative to those zones; for example, 10 AM PST = 1 PM EST.
- When using Active Directory with Kerberos authentication, the domain controller, ASA CX, and client must all be in the same domain, or authentication will fail. For NTLM and basic authentication, the devices should be in the domain, but authentication might work even if they are not in the same domain. Although NTLM is supported with all Windows clients, Kerberos is supported with Windows XP clients only. To increase the likelihood of successful authentication, consider selecting Advanced as the authentication method. This will allow the system to negotiate the strongest method supported by both the client and server, and to try different methods if one fails.
- If you use Kerberos or NTLM with Active Directory, you can configure browsers to transparently respond to active authentication requests. For detailed information, see Enabling Transparent User Authentication.
- Not all user agents can successfully respond to active authentication requests. For example, if a user agent in a remote access VPN connection sends the authentication traffic through the VPN tunnel, active authentication will not succeed. Android 2.3 using AnyConnect 2.5 is an example of this type of agent. Software updaters might also not successfully respond to active authentication. To account for these types of user agent, you can use an existing user agent object, or you can create a user agent policy object that lists these agents in the Include list. Then, in the active authentication identity policy, select the objects in the Exclude User Agent field.
- Users are prompted only if the traffic is HTTP or decrypted HTTPS. To prompt for HTTPS flows, you must create decryption policies that apply the Decrypt Everything action to the appropriate traffic sources.
Special Configuration Requirements for Remote Access VPN
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#
Enabling Transparent User Authentication
- Basic Authentication (Active Directory and LDAP)
-
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.
- Integrated Windows Authentication (Active Directory only)
-
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.
When you configure an authentication policy, you select the specific type of authentication method used in your network. The options are: - NTLM. Supported by all Windows platforms.
- Kerberos. Supported by Windows XP only.
- Advanced, where the strongest method allowed by both the Active Directory server and the user agent is used. (The user agent is typically a web browser through which the user is initiating a traffic flow.) The order of strength is Kerberos, NTLM, then basic.
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. |
- Requirements for Transparent Authentication
- Configuring Internet Explorer for Transparent Authentication
- Configuring Firefox for Transparent Authentication
Requirements for Transparent Authentication
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.
- Add the ASA interface through which users connect to the network to the Trusted Sites list. You can use the IP address or if available, the fully-qualified domain name (for example, asa_inside.example.com). You can also use wildcards or partial addresses to create a generalized trusted site. For example, you can typically cover all internal sites using *.example.com or simply example.com, trusting all servers in your network. If you add the specific address of the ASA interface, you might need to add several addresses to the trusted sites to account for all user access points to the network.
- Integrated Windows authentication does not work through a proxy server. Therefore, you must either not use a proxy, or you must add the ASA interface to the addresses excluded from going through the proxy. If you decide that you must use a proxy, users will be prompted for authentication even if you use the NTLM or Kerberos methods.
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. |
Configuring Internet Explorer for Transparent Authentication
To configure Internet Explorer for both NTLM and Kerberos transparent authentication:
Configuring Firefox for 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.
Identifying the Active Directory Agent
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:
- client_nickname is a name used by the AD agent to refer to the CX client.
- mgmt_IP is either the IP address of the CX management interface, or the subnet that contains the address, for example, 10.100.10.1 or 10.100.10.0/24.
- RADIUS_secret is a RADIUS shared secret that you will also configure in the CX device. This secret encrypts and protects communications between the CX device and the AD agent.
What to Do Next
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.
Configuring Authentication Settings
You can configure authentication settings related to how your identity policies function.
Feedback