Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

Configuring Cloudera Manager External Authentication with Centrify (Part One)

11 April,19 at 11:50 AM

In other blogs and publications, we have gone over how to use Centrify Server Suite to provide centralized authentication, authorization and auditing in big data environments such as Hadoop clusters. The steps are a little different for each distribution but generally we provide the same capabilities to get you fully integrated with Active Directory without much fuss. It's not until we start moving up the stack to the application layers that things really start to get interesting and complicated. 


Cloudera was nice enough to give me a test license which enables all sorts of fun new options. (Thanks!) This blog will be the first of three I plan on writing, focusing on using Centrify Server Suite and the included LDAP Proxy to provide external authentication and authorization for the web-based Cloudera Manager console. The next article will focus on using the same methods for Sentry and then I'll switch things up and switch from LDAP to SAML and integrate Cloudera Manager with Centrify Identity Services instead. (my word count must include more uses of “cloud” if I want people to think I’m smart.)


Before we get into the individual configuration values, let's talk prerequisites.


In order to get to this point, I first followed all the necessary steps in our Cloudera Integration guide to join and secure the cluster. Part of the integration included setting up ldaps/636 and our LDAP Proxy. All of the details for setting that up are in my previous blog. The Kerberos security wizard used the client portion of that to talk ldaps/636 into Active Directory to create all the necessary service principal accounts. Now we will focus on the server side of the proxy to look-up and authenticate zone-enabled users into Cloudera Manager. As I mentioned, this will require a Cloudera Enterprise license so no Express versions here.


So let's get started. First step, let's import our CA certificate into the java certificate store so it can be used to talk ldaps/636. If you're using an Active Directory-based CA like me, this will be necessary. According to Cloudera documentation, if you use a public certificate (Verisign, etc.) then you can skip this step. You can probably use the extra time to jump into your giant mountains of money like Scrooge McDuck. For the rest of us...


  1. Verify our certificate hasn't disappeared since the integration steps were completed. If you change directories to /var/centrify/net/certs, you should have your four auto_LDAPProxy certificates; three placed there through auto enrollment group policy and one converted chain file in pem format. If you followed the LDAP Proxy instructions, we're specifically looking for the auto_LDAPProxy_CA.pem file. Once you've confirmed this file is still where it's supposed to be and you know the file name, you can move on to step two.


  1. Import the certificate into the local keystore. Cloudera/java maintain a dedicated certificate store database. We have to copy our pem file into this store as follows:



[clusteradm@cse1n1 ~]$ dzdo /usr/java/jdk1.7.0_67-cloudera/bin/keytool -import -alias -keystore /usr/java/jdk1.7.0_67-cloudera/jre/lib/security/cacerts -file /var/centrify/net/certs/auto_LDAPProxy_CA.pem


I'm using Cloudera 5.8.1 so the current java version/folder is jdk1.7.0_67-cloudera. This path may have to be updated if your version of Cloudera or java differs. Easy enough to run ls against /usr/java to see what folders you have. You will also have to type in the store password to add the certificate. The default password is changeit. (shhh, secure.)


Once you get a successfully completed message, we're ready to move to Cloudera Manager to configure the rest. Login to Cloudera Manager with an account that already has full administrator rights such as the default admin:admin account. Browse to Administration from the top menu bar, select Settings from the drop-down, then select External Authentication from the left Category pane.


I’m a big fan of context so rather than simply listing my values, I’ll walk you through each option so you know why we’re making these choices.


Authentication Backend Order

Our options are:


  • Database Only
  • External then Database
  • Database then External
  • External Only (with emergency Administrator access)
  • External Only (without emergency Administrator access)


I went with ‘Database then External’. I figured this way, even if I screw something up while trying to figure out the parameters, I can still get in with admin. There’s the emergency option as well which seems like it would also do the trick but this worked so I’m sticking with it.


External Authentication Type

More radio buttons. Our options are:


  • Active Directory
  • LDAP
  • External Program
  • SAML


We want ‘LDAP’ here because we’re going to be using the RFC2307-compliant proxy rather than talking to Active Directory directly. If you’re wondering why, please read my LDAP Proxy article on why this wouldn’t work. (Shameless plug. I know. Sorry.)  



Easy enough. We’re going to use ldaps because we now have the certificate to do so and point to the host running the proxy. In my environments, that’s always the host running Cloudera Manager.

E.g. ldaps://


If you need to validate the server is listening at that address, you can check the process:


[clusteradm@cse1n1 ~]$ ps -ef|grep slap

root     15994     1  0 Sep08 ?        00:00:00 /usr/share/centrifydc/libexec/slapd -h ldap:// ldap://localhost:389 ldaps:// ldaps://localhost:636

931136597 53741 52856  0 19:04 pts/1   00:00:00 grep slap


LDAP Bind User Distinguished Name

When authenticating against the proxy, I typically use the user@domain format for my user name. This just needs to be any AD account with read permissions. It doesn’t even have to be zone-enabled.

E.g. (Overkill, but this is my test environment so not a big deal)


LDAP Bind Password

Type in the password for the above bind user.


LDAP User Search Filter

Now it’s time to get tricky. Since the proxy will intercept all calls for posixaccount and return data from adclient cache, we first want to search for that. We also want to filter for the username entered at the Cloudera Manager login screen. The {0} parameter does this for us. Combined, our search will look like:

E.g. (&(objectclass=posixaccount)(uid={0}))


LDAP User Search Base

The proxy is going to ignore this value because it’s returning cache values rather than searching the Active Directory tree but it makes Cloudera happy so put your domain root DN…

E.g. dc=centrifylab,dc=net


LDAP Group Search Filter

Same thing as the user filter except now we want it to search all groups to see which ones our user is a member of. Remember that in RFC2307 format, there is no memberOf attribute tied to the user showing their group membership so you have to search the groups and enumerate the memberUid array to see which users are members. This will give us the ability to also map group membership to predefined Cloudera Manager roles which I’ll touch on in a moment. The {1} parameter will give us the array of users for each zone-enabled Active Directory group.

E.g. (&(objectclass=posixgroup)(memberuid={1}))


LDAP Group Search Base

Another BaseDN value we’re going to ignore. Same as the User Search Base.



LDAP Full Administrator Groups

As I mentioned, Cloudera Manager has quite a few predefined roles and gives you the ability to map each to a known group. Since we’re using Centrify, we can zone-enable any number of AD groups, give them custom aliases and then use those aliases here to assign users to roles. In my environment, I already have a group called ‘supergroup’ that I use for HDFS management – another very cool feature unique to Cloudera. I’m going to hijack that group to give my AD user Full Administrator access within Cloudera Manager as well.

E.g. supergroup


In addition to Full Administrator, Cloudera also gives us the following predefined roles:


  • User Administrator
  • Cluster Administrator
  • BDR Administrator
  • Configurator
  • Navigator Administrator
  • Operator
  • Limited Operator
  • Auditor
  • Key Administrator


You can get the skinny what all of these roles provide here:

and create as many zone-enabled AD groups as you plan to use.


LDAP Distinguished Name Pattern

This option is nice if all of our users were really in a single LDAP organizational unit and we wanted to search only that OU. We’re using a proxy and cache data which may contain users all over Active Directory so leave the option blank since we’ve already used much more specific user and group filters above.


That’s it! Almost…


Before your saved changes will take effect, we first have to restart the Cloudera Manager server:


[clusteradm@cse1n1 ~]$ dzdo service cloudera-scm-server restart


Grab a beverage of your choice while that spins back up and now you should be able to login with your AD users and, if their group memberships map to any roles, you should now see that reflected in your user details.


 Cloudera Manager User Details