Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Atlas LDAP authentication failed

avatar
Master Collaborator

I stand up a test cluster with HDP2.5.3 and use a self created openLDAP server for credential. Cluster is kerberized with MIT KDC. I could log into ranger with LDAP ids ok, but atlas always returns me a error. log says "LDAP: error code 49 - Invalid Credentials". ldapserach returns the ids fine on atlas node

What this error message means, is the ldap could not find the id or the user/pwd is wrong?

10191-screen-shot-2016-12-08-at-92916-pm.png

here is my config in atlas

10192-screen-shot-2016-12-08-at-93010-pm.png

atlas.authentication.method.ldap.type: LDAP

atlas.authentication.method.ldap.url: ldap://qwang-kdc-ldap.field.hortonworks.com:389

atlas.authentication.method.ldap.userDNpattern: uid={0},ou=Users,dc=field,dc=hortonworks,dc=com

atlas.authentication.method.ldap.groupSearchBase: ou=Groups,dc=field,dc=hortonworks,dc=com

atlas.authentication.method.ldap.groupSearchFilter: (cn={0})

atlas.authentication.method.ldap.groupRoleAttribute: cn

atlas.authentication.method.ldap.base.dn: dc=field,dc=hortonworks,dc=com

atlas.authentication.method.ldap.bind.dn: cn=admin,dc=field,dc=hortonworks,dc=com

atlas.authentication.method.ldap.bind.password: password

atlas.authentication.method.ldap.referral: ignore

atlas.authentication.method.ldap.user.searchfilter: (uid={0})

atlas.authentication.method.ldap.default.role: ROLE_USER

And ldapsearch works fine

ldapsearch -W -H ldap://qwang-kdc-ldap.field.hortonworks.com:389 -D "cn=admin,dc=field,dc=hortonworks,dc=com" -b "ou=Groups,dc=field,dc=hortonworks,dc=com" "(cn=sales)"
ldapsearch -W -H ldap://qwang-kdc-ldap.field.hortonworks.com:389 -D "cn=admin,dc=field,dc=hortonworks,dc=com" -b "dc=field,dc=hortonworks,dc=com" "(uid=sales1)"

What else could I look into for the problem?

1 ACCEPTED SOLUTION

avatar
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login
7 REPLIES 7

avatar
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login

avatar
Master Collaborator

@dvillarreal Problem fixed with you suggestion.

This looks like a defect for Ambari/Atlas, will this get addressed in next minor release? I know not many people use ldap, but still it is quite annoying to escape all the commas, and it is not needed anywhere else with similar setting.

avatar

Hi @Qi Wang, Yes, it should be fixed in the next maintenance release. In the meantime, please use the workaround provided. Thanks,

avatar
Contributor

I went crazy searching the solution to integrate Atlas with LDAP before summer and I couldn't fix it. But now, this workaround has worked in my HDP 2.5 cluster. Thank you so much @dvillarreal.

avatar
Contributor
@dvillarreal

I'm trying with the Atlas version provided by HDP 2.5.3 using Active Directory with both

atlas.authentication.method.ldap.type=ldap
atlas.authentication.method.ldap.type=ad

It doesn't work either way.

In the logs I see:

DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.base.dn = [DC=field, DC=hortonworks, DC=com]
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.bind.dn = [CN=binduser, OU=ServiceUsers, DC=field, DC=hortonworks, DC=com]
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.bind.password = BadPass#1
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.default.role = ROLE_USER
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.domain = FIELD
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.referral = follow
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.url = ldaps://ad01.field.hortonworks.com:636
DEBUG - [main:] ~ atlas.authentication.method.ldap.ad.user.searchfilter = (sAMAccountName={0})
DEBUG - [main:] ~ atlas.authentication.method.ldap.base.dn = [DC=field, DC=hortonworks, DC=com]
DEBUG - [main:] ~ atlas.authentication.method.ldap.bind.dn = [CN=binduser, OU=ServiceUsers, DC=field, DC=hortonworks, DC=com]
DEBUG - [main:] ~ atlas.authentication.method.ldap.bind.password = BadPass#1
DEBUG - [main:] ~ atlas.authentication.method.ldap.default.role = ROLE_USER
DEBUG - [main:] ~ atlas.authentication.method.ldap.groupRoleAttribute = cn 
DEBUG - [main:] ~ atlas.authentication.method.ldap.groupSearchBase = [DC=field, DC=hortonworks, DC=com]
DEBUG - [main:] ~ atlas.authentication.method.ldap.groupSearchFilter = [(member=CN={0}, OU=CorpUsers, DC=field, DC=hortonworks, DC=com)]
DEBUG - [main:] ~ atlas.authentication.method.ldap.referral = follow
DEBUG - [main:] ~ atlas.authentication.method.ldap.type = ad
DEBUG - [main:] ~ atlas.authentication.method.ldap.url = ldaps://ad01.field.hortonworks.com:636
DEBUG - [main:] ~ atlas.authentication.method.ldap.user.searchfilter = (sAMAccountName={0})
DEBUG - [main:] ~ atlas.authentication.method.ldap.userDNpattern = [CN={0}, OU=CorpUsers, DC=field, DC=hortonworks, DC=com]

What I notice is that the DNs are embedded in [].

avatar

Hi @Nicola Marangoni, You may want to take this up on another thread as AD implementation does work out of the box. Make sure you use the AD option. Some things to check. 1. Does your server trust the AD SSL certificate being presented to allow for ldaps. 2. To troubleshoot use port 389 and tcpdump the request and response. 3. ldapsearch is your friend to confirm all parameters.

avatar
Contributor

Hi @dvillarreal the problem was the domain: I entered FIELD instead of FIELD.HORTONWORKS.COM. I thought I should enter the windows domain name (not FQDN) and FIELD.HORTONWORKS.COM is only the realm.

In Ranger, I entered just FIELD and it works. I think Ranger make no use of the domain parameter, Atlas (or Shiro?) on the contrary append it to the username: looking at the tcpdump with Wireshark I discovered that it tried to login with "sales1@field".

Many thanks!