Configuring External Authentication for the Cloudera Navigator Data Management Component
Cloudera Navigator supports user authentication against Cloudera Manager user accounts and against an external service. The external service can be either LDAP or Active Directory. User authentication against Cloudera Manager user accounts requires users to have one of two Cloudera Manager user roles, either Full Administrator or Navigator Administrator. External authentication enables you to assign Cloudera Navigator user roles to LDAP or Active Directory groups to which the appropriate users belong.
For more information about Cloudera Manager user accounts, see Cloudera Manager User Accounts. For more information about Cloudera Navigator user roles, see Cloudera Navigator Data Management Component User Roles.
The following sections describe how to configure the supported external directory services.
Configuring Cloudera Navigator Authentication Using Active Directory
Cloudera Navigator has its own role-based access control and user management scheme. If you want to use LDAP/AD authentication, Cloudera Navigator roles must be explicitly assigned to AD users to allow them to log in to Navigator. To assign roles to AD users, log in to Cloudera Navigator for the first time using a Cloudera Manager admin user. Any non-externally authenticated Cloudera Manager user that has Full Administrator or Navigator Administrator privileges will have admin access to Cloudera Navigator. You can use this account to set up user groups and assign Cloudera Navigator roles to AD users.
Hence, Cloudera recommends that the Authentication Backend Order property be set initially to Cloudera Manager then External. Otherwise, the external authentication system will be checked first, and if the same user credentials also exist in the specified LDAP or Active Directory, the user will be authenticated there, and will not be authenticated as a Cloudera Manager administrator. Since no user roles will have been set up yet for the users in the external authentication system, the user's attempt to log in will fail. Once the groups and user roles for Cloudera Navigator are set up, the Authentication Backend Order can be changed to External then Cloudera Manager or External Only, if desired.To configure Cloudera Navigator to use AD authentication:
- Select .
- Click the Configuration tab.
- Select .
- Select .
- In the Authentication Backend Order field, select the order in which Cloudera Navigator should attempt its authentication. You can choose to authenticate users using just one of the methods (using Cloudera Manager user accounts is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method.
- In the External Authentication Type property, select Active Directory.
- In the LDAP URL property, provide the URL of the LDAP/Active Directory server to authenticate against. The URL has the form: [ldap|ldaps]://hostname:port. If a port is not specified, the default LDAP port is used (389 for LDAP and 636 for LDAPS). For more details on the LDAP URL format, see RFC 2255 .
- For the Bind Distinguished Name property, you require the userPrincipalName (UPN) of the user to bind as. For example, if the UPN is sampleuser@EXAMPLE.COM, the Bind Distinguished Name provided can be either sampleuser or the complete UPN, sampleuser@EXAMPLE.COM. This is used to connect to Active Directory for searching groups and to get other user information.
- In the LDAP Bind Password, enter the password for the bind user entered above.
- In the Active Directory NT Domain property, provide the NT domain to authenticate against.
- Click Save Changes to commit the changes.
- After changing the configuration settings, restart the Navigator Metadata Service: click the Instances tab on the Cloudera Management Service page, check Navigator Metadata Service, and click .
Configuring Cloudera Navigator Authentication Using an OpenLDAP-compatible Server
- You can specify a single base Distinguished Name (DN) and then provide a "Distinguished Name Pattern" to use to match a specific user in the LDAP directory.
- Search filter options let you search for a particular user based on somewhat broader search criteria – for example Cloudera Navigator 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 be allowed to log in.
- Select .
- Click the Configuration tab.
- Select .
- Select .
- In the Authentication Backend Order field, select the order in which Cloudera Navigator should attempt its authentication. You can choose to authenticate users using just one of the methods (using Cloudera Manager user accounts is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method.
- In the External Authentication Type, select LDAP.
- 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.
- In the LDAP Bind User Distinguished Name property, enter the user's sAMAcountName. This is used to connect to the LDAP server for searching groups and to get other user information.
- In the LDAP Bind Password property, enter the password for the bind user entered above.
- To use a single "Distinguished Name Pattern", provide a pattern in the LDAP Distinguished Name Pattern property.
Use {0} in the pattern to indicate where the username should go. For example, to search for a distinguished name where the uid attribute is the username, you might provide a pattern similar to uid={0},ou=People,dc=corp,dc=com. Cloudera Navigator substitutes the name provided at login into this pattern and performs a search for that specific user. So if a user provides the username "foo" at the Cloudera Navigator login page, Cloudera Navigator will search for the DN uid=foo,ou=People,dc=corp,dc=com.
If you provided a base DN along with the URL, the pattern only needs to specify the rest of the DN pattern. For example, if the URL you provide is ldap://ldap-server.corp.com/dc=corp,dc=com, and the pattern is uid={0},ou=People, then the search DN will be uid=foo,ou=People,dc=corp,dc=com.
- You can also 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 Navigator 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 Navigator 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.
You can use a user search filter along with a DN pattern, so that the search filter provides a fallback if the DN pattern search fails.
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 to which the user belongs.
- Click Save Changes to commit the changes.
- After changing the configuration settings, restart the Navigator Metadata Service: click the Instances tab on the Cloudera Management Service page, check Navigator Metadata Service, and click .
Configuring Cloudera Navigator to Use LDAPS
- Copy the CA certificate file to the Cloudera Navigator Server host.
- 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/jssecacerts
$ /usr/java/latest/bin/keytool -import -alias nt_domain_name \ -keystore /usr/java/latest/jre/lib/security/jssecacerts -file path_to_cert
Note:- The default password for the cacerts store is changeit.
- The alias can be any name (not just the domain name).
- Configure the LDAP URL property to use ldaps://ldap_server instead of ldap://ldap_server.