I tried to configure external authentication with AD on CDM5 but it' failed, i've the following errors into cloudera-scm-server.log file :
2014-08-15 19:26:43,229 INFO [1244120161@scm-web-5:ad.ActiveDirectoryLdapAuthenticationProvider@183] Active Directory authentication failed: Supplied password was invalid
2014-08-15 19:26:43,232 INFO [1244120161@scm-web-5:cmf.CmfLdapAuthenticationProvider@107] LDAP/AD authentication failure for email@example.com
2014-08-15 19:26:43,243 INFO [1244120161@scm-web-5:cmf.AuthenticationFailureEventListener@19] Authentication failure for user: firstname.lastname@example.org
Here is my configuration :
I've sucessfully configured kerberos AD authentication for all hadoop services but just for cdm not !
Could you please help me ?
Configuring Authentication Using Active Directory
I'm also have this problem.
Problem was solved?
Used Grizzly's screenshot as reference and was able to set External authentication with Active directory.
But running into this error for ONLY ONE user. Any ideas on how to troubleshoot this?
Created new post as I was not sure if this was still active.
Currently, LDAP authentication for Cloudera Manager is only available in Cloudera Enterprise as outlined here:
If you wish to discuss licensing options with Sales, the following form can be used:
For the one user, what message are you seeing, exactly, in the UI when they try to log in?
Since Active Directory authentication will concatenate the username provided in the UI with an '@' character and then the domain you specified to form a userPrincipalName.
For example, if you login with 'myname' and your "Active Directory NT Domain" configuration in Cloudera Manager is "example.com" then the userPrincipalName used to authenticate to AD is:
This works most of the time, but it will fail if the login string used does not match the left part of the user's userPrincipalName attribute in Active Directory. Sometimes the userPrincipalName shortname (left of the '@' sign) does not match the sAMAccountName that users often use as their login.
I'd check to the value the user who can't login is using as their username and see if the userPrincipalName that it generates in for authentication matches the userPrincipalName that exists for that user in their AD object.
The problem could be something else, but the issue I described is something we have see from time to time.
The remedy, then would be to use LDAP as the external authenitication method.