The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure LDAP servers used in AAA and includes the following sections:
The ASA is compatible with the most LDAPv3 directory servers, including:
By default, the ASA autodetects whether it is connected to Microsoft Active Directory, Sun LDAP, Novell, OpenLDAP, or a generic LDAPv3 directory server. However, if autodetection fails to determine the LDAP server type, you can manually configure it.
When configuring the LDAP server, note the following guidelines:
During authentication, the ASA acts as a client proxy to the LDAP server for the user, and authenticates to the LDAP server in either plain text or by using the SASL protocol. By default, the ASA passes authentication parameters, usually a username and password, to the LDAP server in plain text.
The ASA supports the following SASL mechanisms, listed in order of increasing strength:
The ASA and LDAP server supports any combination of these SASL mechanisms. If you configure multiple mechanisms, the ASA retrieves the list of SASL mechanisms that are configured on the server, and sets the authentication mechanism to the strongest one configured on both the ASA and the server. For example, if both the LDAP server and the ASA support both mechanisms, the ASA selects Kerberos, the stronger of the two.
When user LDAP authentication has succeeded, the LDAP server returns the attributes for the authenticated user. For VPN authentication, these attributes generally include authorization data that is applied to the VPN session. In this case, using LDAP accomplishes authentication and authorization in a single step.
Note For more information about the LDAP protocol, see RFCs 1777, 2251, and 2849.
Your LDAP configuration should reflect the logical hierarchy of your organization. For example, suppose an employee at your company, Example Corporation, is named Employee1. Employee1 works in the Engineering group. Your LDAP hierarchy could have one or many levels. You might decide to set up a single-level hierarchy in which Employee1 is considered a member of Example Corporation. Or you could set up a multi-level hierarchy in which Employee1 is considered to be a member of the department Engineering, which is a member of an organizational unit called People, which is itself a member of Example Corporation. See Figure 38-1 for an example of a multi-level hierarchy.
A multi-level hierarchy has more detail, but searches return results more quickly in a single-level hierarchy.
Figure 38-1 A Multi-Level LDAP Hierarchy
The ASA lets you tailor the search within the LDAP hierarchy. You configure the following three fields on the ASA to define where in the LDAP hierarchy that your search begins, the extent, and the type of information you are looking for. Together, these fields limit the search of the hierarchy to only the part that includes the user permissions.
Figure 38-1 shows a sample LDAP hierarchy for Example Corporation. Given this hierarchy, you could define your search in different ways. Table 38-1 shows two sample search configurations.
In the first example configuration, when Employee1 establishes the IPsec tunnel with LDAP authorization required, the ASA sends a search request to the LDAP server, indicating it should search for Employee1 in the Engineering group. This search is quick.
In the second example configuration, the ASA sends a search request indicating that the server should search for Employee1 within Example Corporation. This search takes longer.
|
|
|
|
|
---|---|---|---|---|
The ASA uses the login DN and login password to establish trust (bind) with an LDAP server. When performing a Microsoft Active Directory read-only operation (such as authentication, authorization, or group search), the ASA can bind using a login DN with fewer privileges. For example, the login DN can be a user whose AD “Member Of” designation is part of Domain Users. For VPN password management operations, the login DN needs elevated privileges, and must be part of the Account Operators AD group.
The following is an example of a login DN:
The ASA supports the following authentication methods:
The ASA does not support anonymous authentication.
Note As an LDAP client, the ASA does not support the transmission of anonymous binds or requests.
|
|
---|---|
This section includes the guidelines and limitations for this feature.
Supported in single and multiple context mode.
This section includes the following topics:
Step 1 Add an LDAP server group. See Configuring LDAP Server Groups.
Step 2 (Optional) Configure authorization from an LDAP server that is separate and distinct from the authentication mechanism. See Configuring Authorization with LDAP for VPN.
Step 3 Configure LDAP attribute maps. See Configuring LDAP Attribute Maps.
You must add an attribute map before adding an LDAP server to an LDAP server group.
The ASA can use an LDAP directory for authenticating users for:
The ASA uses LDAP attribute maps to translate native LDAP user attributes to Cisco ASA attributes. You can bind these attribute maps to LDAP servers or remove them. You can also show or clear attribute maps.
The LDAP attribute map does not support multi-valued attributes. For example, if a user is a member of several AD groups, and the LDAP attribute map matches more than one group, the value chosen is based on the alphabetization of the matched entries.
To use the attribute mapping features correctly, you need to understand LDAP attribute names and values, as well as the user-defined attribute names and values.
The names of frequently mapped LDAP attributes and the type of user-defined attributes that they would commonly be mapped to include the following:
Note A single LDAP attribute map may contain one or many attributes. You can only map one LDAP attribute from a specific LDAP server.
The following example shows how to limit management sessions to the ASA based on an LDAP attribute called accessType. The accessType attribute may have one of these values:
The following example shows how each value is mapped to one of the valid IETF-Radius-Service-Type attributes that the ASA supports: remote-access (Service-Type 5) Outbound, admin (Service-Type 6) Administrative, and nas-prompt (Service-Type 7) NAS Prompt.
The following example shows how to display the complete list of Cisco LDAP attribute names:
To use an external LDAP server for authentication, authorization, and/or accounting, you must first create at least one LDAP server group, and add one or more servers to each group. You identify LDAP server groups by name. Each server group is specific to one type of server.
The following steps show how to create and configure an LDAP server group, and add an LDAP server to that group.
|
|
|
---|---|---|
|
Identifies the server group name and the protocol. When you enter the aaa-server protocol command, you enter aaa-server group configuration mode. |
|
|
Specifies the maximum number of requests sent to an LDAP server in the group before trying the next server. The number argument can range from 1 and 5. The default is 3. If you configured a fallback method using the local database (for management access only) to configure the fallback mechanism), and all the servers in the group fail to respond, then the group is considered to be unresponsive, and the fallback method is tried. The server group remains marked as unresponsive for a period of 10 minutes (by default), so that additional AAA requests within that period do not attempt to contact the server group, and the fallback method is used immediately. To change the unresponsive period from the default, see the reactivation-mode command in the next step. If you do not have a fallback method, the ASA continues to retry the servers in the group. |
|
ciscoasa(config-aaa-server-group)# reactivation-mode deadtime 20 |
Specifies the method (reactivation policy) by which failed servers in a group are reactivated. The depletion keyword reactivates failed servers only after all of the servers in the group are inactive. The deadtime minutes keyword-argument pair specifies the amount of time in minutes, between 0 and 1440, that elapses between the disabling of the last server in the group and the subsequent reenabling of all servers. The default is 10 minutes. The timed keyword reactivates failed servers after 30 seconds of down time. |
|
|
Identifies the LDAP server and AAA server group to which it belongs. When you enter the aaa-server host command, you enter aaa-server host configuration mode. As needed, use host configuration mode commands to further configure the AAA server. Table 38-2 lists the available commands for LDAP servers, and whether or not a new LDAP server definition has a default value for that command. If no default value is provided (indicated by “—”), use the command to specify the value. |
The following example shows how to configure an LDAP server group named watchdogs and add an LDAP server to the group. Because the example does not define a retry interval or the port that the LDAP server listens to, the ASA uses the default values for these two server-specific parameters.
ciscoasa(config)# aaa-server watchdogs protocol ldap
ciscoasa(config-aaa-server-group)# aaa-server watchdogs host 192.168.3.4
ciscoasa(config-aaa-server-host)#
exit
ciscoasa(config)#
When user LDAP authentication for VPN access has succeeded, the ASA queries the LDAP server, which returns LDAP attributes. These attributes generally include authorization data that applies to the VPN session. Using LDAP in this way accomplishes authentication and authorization in a single step.
There may be cases, however, where you require authorization from an LDAP directory server that is separate and distinct from the authentication mechanism. For example, if you use an SDI or certificate server for authentication, no authorization information is returned. For user authorizations in this case, you can query an LDAP directory after successful authentication, accomplishing authentication and authorization in two steps.
To set up VPN user authorization using LDAP, perform the following steps.
While there are other authorization-related commands and options available for specific requirements, the following example shows commands for enabling user authorization with LDAP. The example then creates an IPsec remote access tunnel group named remote-1, and assigns that new tunnel group to the previously created ldap_dir_1 AAA server group for authorization:
After you complete this configuration work, you can then configure additional LDAP authorization parameters such as a directory password, a starting point for searching a directory, and the scope of a directory search by entering the following commands:
To monitor LDAP servers,enter one of the following commands:
Table 38-3 lists each feature change and the platform release in which it was implemented.