External Authentication Active Directory (AD) Cloudera Enterprise Trial 5.14.3

[#1]

We are evaluating an Azure marketplace Cloudera Enterprise Trial for the purpose of BI.  We have nearly everything configured except External Authentication against A.D.  We have configured Kerberos within Cloudera manager successfully and have also tested successful LDAP queries via a Windows server in Azure against our on premise A.D. servers.

But, no matter the configuration we have set in the External Authentication page, we cannot get it to work.

• Type
• AD
• LDAP
• URL
• ldap & ldaps
• Bind User
• CN=username,OU=Hadoop,OU=Prod,OU=ServiceAccounts,OU=Users,OU=Site,DC=domain,DC=org
• username
• username@domain.org
• AD Domain
• domain.org
• NETBIOSDOMAIN
• Blank
• User search filter
• (sAMAccountName={0})
• (uid={0})
• (userPrincipalName={0})
• Update both User/Group
• OU=Users,OU=Site,DC=domain,DC=org
• OU=Prod,OU=Roles,OU=Security,OU=Groups,OU=Site,DC=domain,DC=org
• On Logon
• username
• username@domain.org
• username@sub.domain.org
• NETBIOSDOMAIN\username
• Domain Controller Event Logs, showed no attempt by the Bind account

Is there any limitations of the Enterprise Trial that might prevent this?  Or where are the logs on the system related to the External Authentication?

Thanks!

 

[#2]

@dchu You can check the CM server log at /var/log/cloudera-scm-server/cloudera-scm-server.log while you attempt to log in to see what the exception is (if there is one).

Can you show an example query using ldapsearch to return a user? (redact anything you don't want seen publicly)

[#3]

Thank you, that path does not show when doing an LS under /var/log, but cd /var/log/cloudera-scm-server does work... I made a few attempts using different username styles (username, username@domain.org, domain/username) and in the log it says "LDAP/AD authentication failed" / "Authentication failure for user: 'username' from x.x.x.219" for each attempt... this is my personal account and I know I am entering my password correctly.

I also know I am a member of the group "UsrGrpFullAdmin" which is the group configured to be "LDAP Full Administrators Group."

Could this suggest there is a problem with the bind account (which is different then the account I am using to log in via the main page).  How should the bind account be typed for A.D.? (i.e.)

• CN=username,OU=Hadoop,OU=Prod,OU=ServiceAccounts,OU=Users,OU=Site,DC=domain,DC=org
• username
• username@domain.org 

I ran the following successfully from the Cloudera Management server via SSH:

ldapsearch -h x.x.x.x -b OU=Site,DC=domain,DC=org -x -w 'password' -D CN=username,OU=Hadoop,OU=Prod,OU=ServiceAccounts,OU=Users,OU=Site,DC=domain,DC=org sAMAccountName=endusername

What was interesting, it was finicky with the password.  But with the single quotes it was successful.  Both the server via IP and FQDN worked.

Are there any limitations regarding the password or what not?

[#4]

Use LDAP binding and set the bind username to what you set here (along with the bind password in CM):

CN=username,OU=Hadoop,OU=Prod,OU=ServiceAccounts,OU=Users,OU=Site,DC=domain,DC=org 

Then from the output of your ldapsearch make sure the attributes and membership are what you expect and have configured in CM.

You can also test the ldap config set in CM with the following:

https://github.com/gdgt/ldapcheck/releases (grab the one with dependencies)

https://raw.githubusercontent.com/gdgt/ldapcheck/master/src/main/resources/ldap-config.properties (for sample config)

On the CM node:

java -classpath '/usr/share/cmf/common_jars/*:./cmldap-v1.0.0-cm5.jar' com.gdgt.app.LdapChk 'ldap-config.properties'

[#5]

I have tried everything I can think of - but it always fails.  I can query with no problems using the ldapsearch from the shell of the Cloudera server; however, no matter the configuration it seems to fail...

• Authentication failure for user: 'username' from x.x.x.x
  • Incorrect result size: expected 1, actual 0
• LDAP/AD authentication failure for username@domain.org
  • Bad credentials
• LDAP/AD authentication failure for DOMAIN\username
  • Bad credentials

I have tried a simplier password for the bind account, more narrowed/broad user/group base DNs, different user accounts for the bind, various search filters...

We have 2x domains (1x domain.org & a sub domain - intranet.domain.org) the host I am pointing the config to is a domain controller for intranet.domain.org - all the users sit in this domain.

I have tried with a blank and populated A.D. directory domain...

[#6]

Try the jar I linked you first and as a note CM doesn't follow referrals so you may have to use the global catalog port.

[#7]

Sorry, I missed the jar file...  But I actually got it working...  Turns out we thought going to "Clusters" - selecting the cluster - Actions - Restart, did not actually restart the necessary services. Every change I made, no matter how drastic, it still reported the same errors in the log.

After finding the correct way to restart the necessary services [Link], the errors started to make more sense. Now I cannot get it to work using “Active Directory,” I wonder if because of referrals [Link], but it does work using LDAP now which is fine by us… Thanks for the help/insight!

[#8]

I thought you were restarting the CM server each time but I'm glad you figured it out!