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 37-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 37-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 37-1 shows a sample LDAP hierarchy for Example Corporation. Given this hierarchy, you could define your search in different ways. Table 37-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 Add a server to the group, then configure server parameters. See Adding an LDAP Server to a Group.
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.
Step 1 Choose Configuration > Remote Access VPN > AAA Local Users > LDAP Attribute Map (for local users), or Configuration > Device Management > Users/AAA > LDAP Attribute Map (for all other users), then click Add.
The Add LDAP Attribute Map dialog box appears with the Map Name tab active.
Step 2 In the Name field, create a name for this attribute map.
Step 3 In the LDAP Attribute Name field, add the name of on of the LDAP attributes to be mapped.
Step 4 From the Cisco Attribute Name drop-down list, choose a Cisco attribute.
Step 6 The attributes are mapped. To map more attributes, repeat Steps 1 through 5 .
Step 7 If you want to map the value of any of the LDAP attributes to a new value in the mapped Cisco attribute, click the Map Value tab.
The Add Mapping of Attribute Name dialog box appears.
Step 9 Choose an LDAP attribute from the drop-down list.
Step 10 In the LDAP Attribute Value field, enter the value for this LDAP attribute that you expect to be returned from the LDAP server.
Step 11 In the Cisco Attribute Value field, enter the value you want to use in the Cisco attribute when this LDAP attribute contains the previous LDAP Attribute Value.
Step 13 To map more values, repeat Steps 8 through 12 .
Step 14 Click OK to return to the Map Value tab, and then click OK again to close the dialog box.
Step 15 In the LDAP Attribute Map pane, click Apply to save the value mappings to the running configuration.
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.
Step 1 Choose Configuration > Device Management > Users/AAA > AAA Server Groups, or Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups for VPN users.
Step 2 In the AAA Server Groups area, click Add.
The Add AAA Server Group dialog box appears.
Step 3 In the AAA Server Group field, name this AAA server group.
Step 4 From the Protocol drop-down list, choose the LDAP server type.
Step 5 In the Reactivation Mode field, click the radio button for the mode you want to use (Depletion or Timed).
In Depletion mode, failed servers are reactivated only after all of the servers in the group are inactive.
In Timed mode, failed servers are reactivated after 30 seconds of down time.
a. If you chose the Depletion reactivation mode, enter a time interval in the Dead Time field.
The Dead Time is the duration of time, in minutes, that elapses between the disabling of the last server in a group and the subsequent re-enabling of all servers.
Step 6 In the Max Failed Attempts field, add the number of failed attempts to connect to the server to allow.
This option sets the number of failed connection attempts allowed before declaring a nonresponsive server to be inactive.
The Add AAA Server Group dialog box closes, and the new server group is added to the AAA Server Groups table.
Step 8 In the AAA Server Groups dialog box, click Apply to save the changes.
The changes are saved to the running configuration.
Step 1 Choose Configuration > Device Management > Users/AAA > AAA Server Groups, or Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups for VPN users, and in the AAA Server Groups area, select the server group to which you want to add a server.
Step 2 Next to the list of Servers in Selected Grous, click Add.
The Add AAA Server dialog box appears for the selected server group.
Step 3 From the Interface Name drop-down list, choose the name of the interface that connects to the LDAP server.
Step 4 In the Server Name or IP Address field, add either the server name or IP address of the LDAP server.
Step 5 In the Timeout field, either add a timeout value or keep the default. The timeout is the duration of time, in seconds, that the ASA waits for a response from the primary server before sending the request to the backup server.
Step 6 In the LDAP Parameters for authentication/authorization area, configure the following fields:
Note If you do not configure the SASL protocol, we strongly recommend that you secure LDAP communications with SSL.
– Detect Automatically/Use Generic Type
– Sun, now part of Oracle Directory Server Enterprise Edition
– One Level—Searches only one level beneath the Base DN. This option is quicker.
– All Levels—Searches all levels beneath the Base DN (that is, searches the entire subtree hierarchy). This option takes more time.
– Group Base DN —Specifies the location in the LDAP hierarchy to begin searching for the AD groups (that is, the list of memberOf enumerations). If this field is not configured, the ASA uses the base DN for AD group retrieval. ASDM uses the list of retrieved AD groups to define AAA selection criteria for dynamic access policies. For more information, see the show ad-groups command.
– Group Search Timeout —Specifiy the maximum time to wait for a response from an AD server that was queried for available groups.
The Add AAA Server dialog box closes, and the AAA server is added to the AAA server group.
Step 8 In the AAA Server Groups pane, click Apply to save the changes to the running configuration.
To determine whether the ASA can contact an LDAP server and authenticate or authorize a user, perform the following steps:
Step 1 In the Configuration > Device Management > Users/AAA > AAA Server Groups pane, select the server group in which the server resides.
Step 2 From the Servers in the Selected Group area, select the server that you want to test.
The Test AAA Server dialog box appears for the selected server.
Step 4 Click the type of test that you want to perform— Authentication or Authorization.
Step 6 If you are testing authentication, enter the password for the username.
The ASA sends either an authentication or authorization test message to the server. If the test fails, ASDM displays an error message.
To monitor LDAP servers, perform the following steps:
Step 1 In ASDM, choose Monitoring > Properties > AAA Servers.
Step 2 To update an LDAP server status, select it then click Update Server Statistics.
The Update AAA Server Status dialog box appears with the LDAP server selected in the drop-down list.
Step 4 To update the currently displayed statistics, click Clear Server Statistics.
Table 37-2 lists each feature change and the platform release in which it was implemented. ASDM is backward-compatible with multiple platform releases, so the specific ASDM release in which support was added is not listed.