Configuring Cloudera Navigator for LDAP
There is more than one way to configure an LDAP-compatible identity/authentication service to authenticate Navigator users and to allow Navigator to access group membership. The most commonly used LDAP authentication mode is search-bind.
Alternatively, you can configure Navigator to use bind-direct LDAP authentication. Note that this method assumes all users are in one directory tree; it doesn't have the flexibility to identify multiple LDAP directory trees.
Considerations for Configuring Navigator with LDAPS (TLS/SSL)
It is important that you configure TLS/SSL for Cloudera Manager as part of using LDAP for authenticating users. If you don't have secure network communication, you risk exposing your LDAP Distinguished Name credentials on the network.
Navigator uses a separate TLS/SSL truststore when communicating with an LDAP server from the one it uses when communicating with Cloudera Manager and other services (described in Configuring TLS/SSL for Navigator Metadata Server). Be sure that you complete configuration for both truststores.
Navigator establishes trust for LDAP server certificate using the JDK on the local host. The JDK looks for certificates in three places:
- $JAVA_HOME/jre/lib/security/jssecacerts
- $JAVA_HOME/jre/lib/security/cacerts
- Location specified by java.net.ssl.truststore. This property can be set through the Navigator Metadata Server Advanced Configuration Snippet (Safety Valve) for cloudera-navigator.properties
If the java.net.ssl.truststore location is set, the JDK ignores the default certificate locations.
For information on how to generate and distribute certificate files, see Generate TLS Certificates.
Configuring LDAP as Navigator's External Authentication
- Make sure that you have the TLS truststore for communicating with the LDAP server configured on the host where the Navigator Metadata Server role is running.
- Decide which LDAP authentication method you want to use to locate user entries in the directory.
In enterprise environments, the more common method is Search-Bind because it allows a flexible configuration for determining the Distinguished Name based on a user's login. In some cases, Direct Bind may be used when all users must be under a single branch in the LDAP directory. There's more information about the requirements for configuration properties for these modes in the table below.
- Select Clusters > Cloudera Management Service.
- Click the Configuration tab.
- Select Scope > Navigator Metadata Server.
- Select Category > External Authentication.
- In the External Authentication Type property, select LDAP.
- Configure the remaining settings for the LDAP server instance as detailed in the table.
Property Description and usage note External Authentication Type LDAP LDAP URL Full path to the LDAP server instance, including the protocol specifier, ldap or ldaps (for TLS/SSL). It is not necessary to specify port number if the Active Directory service is hosted using the default ports—389 (LDAP), 636 (LDAPS). For example: ldaps://ldap-server.corp.com
If you have not configured TLS, the URL would start with ldap://.Authentication Backend Order To instruct Navigator to refer to the LDAP server to authenticate users, set this property to External then Cloudera Manager or External Only. The "External then Cloudera Manager" option allows administrators to log into Navigator in the case where LDAP logins are failing. If you need to debug connectivity issues without LDAP involved, you can log in with a Cloudera Manager-only user account. LDAP Bind User Distinguished Name The LDAP account that has permission to query the LDAP database of user accounts on behalf of Cloudera Navigator. The bind user can be specified as the full distinguished name (DN) (cn=account,ou=people,dc=corp,dc=region) or as only the common name (user@domain). Use the same format as the string used for Cloudera Manager LDAP configuration.
This property is not required if your LDAP server accepts anonymous binding.
LDAP Bind Password The password for the bind user. LDAP Group Search Base Specify the organizational unit (OU) and domain component (DC) properties for the LDAP search tree where Navigator searches for groups. For example, this search base starts the group membership search to an organizational unit configured specifically for Navigator users and Navigator searches this subtree: ou=nav_people,dc=ldap-srvs,dc=subnet,dc=example,dc=com
The Group Search Base is used for both the Groups Search Filter and the Group Search Filter for Logged in User.
LDAP Group Search Filter For Logged In User Optional. Specifies how a user is determined to be a member of a group. Defaults to: member={0} where {0} is replaced with the DN of the user you are authenticating. For a filter requiring the username, use {1}, as memberUid={1}. LDAP Groups Search Filter Specify this filter to refine the scope of LDAP groups to associate with Navigator roles. LDAP groups and users belonging to these groups inherit the Navigator roles. The roles are then used for authorization. For example, to limit the groups to groups with the current user as a member, specify (&(objectClass=group)(cn=*{0}*))
The Groups Search Filter is combined with the Group Search Base to define the group lookup.
Search-Bind Authentication Mode LDAP User Search Base Specify the organizational unit (OU) and domain component (DC) properties for the LDAP search tree where Navigator searches to authenticate users. You can also specify a User Search Filter to further reduce the scope of the search. For example, the following User Search Base string limits Navigator authentication to users inside the specified OU and DCs: ou=nav_people,dc=ldap-srvs,dc=subnet,dc=example,dc=com
If you leave out OUs from the search base, Navigator authenticates users from any OU. For example, with the User Search Base dc=corp,dc=com and the user search filter as uid={0}, Navigator searches for the user anywhere in the tree starting from the User Search Base. If LDAP includes two OUs—ou=Engineering and ou=Operations—Navigator finds user "foo" if it exists in either of these OUs, that is, uid=foo,ou=Engineering,dc=corp,dc=com or uid=foo,ou=Operations,dc=corp,dc=com.LDAP User Search Filter Used with the User Search Base to further limit the scope of the search for a directory entry that matches the credentials of the user logging into Navigator. Use a user search filter along with a DN pattern so that the search filter provides a fallback if the DN pattern search fails. For example, set the filter to uid={0} to use the username provided at login. For Active Directory's LDAP server, use sAMAccountName={0}.
Direct-Bind Authentication Mode LDAP Distinguished Name Pattern Direct-bind authentication can be used if search is not required to determine the DN needed to bind to the LDAP server. Leave this property blank if LDAP User Search Base is set. To use this authentication mode, all users must be under a single branch in the LDAP directory.
For example, to search for a distinguished name where the uid attribute is the username at login, you might provide a pattern such asuid={0},ou=People,dc=corp,dc=com
where {0} indicates the username of the authenticating user. If a user provides the username "foo" at the Navigator login page, Navigator searches for the DN uid=foo,ou=People,dc=corp,dc=com. - Click Save Changes.
- Restart the Navigator Metadata Server.
Categories: Authentication | Configuring | Data Management | LDAP | Navigator | Security | All Categories