Cloudera Docs

Configure authentication using an LDAP-compliant identity service

How to configure authentication using LDAP in Cloudera Manager.

An LDAP-compliant identity/directory service, such as OpenLDAP, provides different options for enabling Cloudera Manager to look-up user accounts and groups in the directory:
  • Use a single Distinguished Name (DN) as a base and provide a pattern (Distinguished Name Pattern) for matching user names in the directory, or
  • Search filter options let you search for a particular user based on somewhat broader search criteria – for example Cloudera Manager users could be members of different groups or organizational units (OUs), so a single pattern does not find all those users. Search filter options also let you find all the groups to which a user belongs, to help determine if that user should have login or admin access.
  1. Log in to Cloudera Manager Admin Console.
  2. Select Administration > Settings.
  3. Select External Authentication for the Category filter to display the settings.
  4. For Authentication Backend Order, select the order in which Cloudera Manager should look up authentication credentials for login attempts.
  5. For External Authentication Type, select LDAP.
  6. In the LDAP URL property, provide the URL of the LDAP server and (optionally) the base Distinguished Name (DN) (the search base) as part of the URL — for example ldap://ldap-server.corp.com/dc=corp,dc=com.
  7. If your server does not allow anonymous binding, provide the user DN and password to be used to bind to the directory. These are the LDAP Bind User Distinguished Name and LDAP Bind Password properties. By default, Cloudera Manager assumes anonymous binding.
  8. Search for users and groups. You can search using User or Group search filters, using the LDAP User Search Base, LDAP User Search Filter, LDAP Group Search Base and LDAP Group Search Filter settings. These allow you to combine a base DN with a search filter to allow a greater range of search targets.

    For example, if you want to authenticate users who may be in one of multiple OUs, the search filter mechanism will allow this. You can specify the User Search Base DN as dc=corp,dc=com and the user search filter as uid={0}. Then Cloudera Manager will search for the user anywhere in the tree starting from the Base DN. Suppose you have two OUs—ou=Engineering and ou=Operations—Cloudera Manager will find 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.

    The Groups filters let you search to determine if a DN or username is a member of a target group. In this case, the filter you provide can be something like member={0} where {0} will be replaced with the DN of the user you are authenticating. For a filter requiring the username, {1} may be used, as memberUid={1}. This will return a list of groups the user belongs to, which will be compared to the list in the group properties.

  9. Save the configuration changes.
  10. In Admininstration > Users & Roles > LDAP/PAM Groups, choose Test LDAP User.
    You will be prompted to provide a username and password for an LDAP user in order to test whether that user can be authenticated.
  11. Restart the Cloudera Manager Server.

Configuring Cloudera Manager to Use LDAPS

If the LDAP server certificate has been signed by a trusted Certificate Authority, steps 1 and 2 below may not be necessary.
  1. Copy the CA certificate file to the Cloudera Manager Server host.
  2. Import the CA certificate(s) from the CA certificate file to the local truststore. The default truststore is located in the $JAVA_HOME/jre/lib/security/cacerts file.
    This contains the default CA information shipped with the JDK. Create an alternate default file called jssecacerts in the same location as the cacerts file. You can now safely append CA certificates for any private or public CAs not present in the default cacerts file, while keeping the original file intact.
    For our example, we will follow this recommendation by copying the default cacerts file into the new jssecacerts file, and then importing the CA certificate to this alternate truststore.
    cp $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/jssecacerts
    $ /usr/java/latest/bin/keytool -import -alias nt_domain_name
-keystore /usr/java/latest/jre/lib/security/jssecacerts -file path_to_CA_cert

    Alternatively, you can use the Java options: javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword. Open the /etc/default/cloudera-scm-server file and add the following options: 

    export CMF_JAVA_OPTS="-Xmx2G -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djavax.net.ssl.trustStore=/usr/java/default/jre/lib/security/jssecacerts -Djavax.net.ssl.trustStorePassword=changeit"
  3. Configure the LDAP URL property to use ldaps://ldap_server instead of ldap://ldap_server
  4. Restart the Cloudera Manager Server.