About LDAP and the ASA
The ASA is compatible with the most LDAPv3 directory servers, including:
-
Sun Microsystems JAVA System Directory Server, now part of Oracle Directory Server Enterprise Edition, and formerly named the Sun ONE Directory Server
-
Microsoft Active Directory
-
Novell
-
OpenLDAP
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.
How Authentication Works with LDAP
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:
-
Digest-MD5—The ASA responds to the LDAP server with an MD5 value computed from the username and password.
-
Kerberos—The ASA responds to the LDAP server by sending the username and realm using the GSSAPI Kerberos mechanism.
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 LDAP, see RFCs 1777, 2251, and 2849. |
LDAP Hierarchy
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 the following figure 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.
Search the 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.
-
LDAP Base DN defines where in the LDAP hierarchy that the server should begin searching for user information when it receives an authorization request from the ASA.
-
Search Scope defines the extent of the search in the LDAP hierarchy. The search proceeds this many levels in the hierarchy below the LDAP Base DN. You can choose to have the server search only the level immediately below it, or it can search the entire subtree. A single level search is quicker, but a subtree search is more extensive.
-
Naming Attribute(s) defines the RDN that uniquely identifies an entry in the LDAP server. Common naming attributes can include cn (Common Name), sAMAccountName, and userPrincipalName.
The figure shows a sample LDAP hierarchy for Example Corporation. Given this hierarchy, you could define your search in different ways. The following table 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.
No. |
LDAP Base DN |
Search Scope |
Naming Attribute |
Result |
---|---|---|---|---|
1 |
group= Engineering,ou=People,dc=ExampleCorporation, dc=com |
One Level |
cn=Employee1 |
Quicker search |
2 |
dc=ExampleCorporation,dc=com |
Subtree |
cn=Employee1 |
Longer search |
Bind to an LDAP Server
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:
cn=Binduser1,ou=Admins,ou=Users,dc=company_A,dc=com
The ASA supports the following authentication methods:
-
Simple LDAP authentication with an unencrypted password on port 389
-
Secure LDAP (LDAP-S) on port 636
-
Simple Authentication and Security Layer (SASL) MD5
-
SASL Kerberos
The ASA does not support anonymous authentication.
Note |
As an LDAP client, the ASA does not support the transmission of anonymous binds or requests. |
LDAP Attribute Maps
The ASA can use an LDAP directory for authenticating users for:
-
VPN remote access users
-
Firewall network access/cut-through-proxy sessions
-
Setting policy permissions (also called authorization attributes), such as ACLs, bookmark lists, DNS or WINS settings, and session timers.
-
Setting the key attributes in a local group policy
The ASA uses LDAP attribute maps to translate native LDAP user attributes to 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:
-
IETF-Radius-Class (Group_Policy in ASA version 8.2 and later)—Sets the group policy based on the directory department or user group (for example, Microsoft Active Directory memberOf) attribute value. The group policy attribute replaced the IETF-Radius-Class attribute with ASDM version 6.2/ASA version 8.2 or later.
-
IETF-Radius-Filter-Id—Applies an access control list or ACL to VPN clients, IPsec, and SSL.
-
IETF-Radius-Framed-IP-Address—Assigns a static IP address assigned to a VPN remote access client, IPsec, and SSL.
-
Banner1—Displays a text banner when the VPN remote access user logs in.
-
Tunneling-Protocols—Allows or denies the VPN remote access session based on the access type.
Note
A single LDAP attribute map may contain one or many attributes. You can only map one LDAP attribute from a specific LDAP server.