Atlas LDAP authentication failed

[#1]

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?

here is my config in atlas

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?

[#2 · Accepted solution]

Hi @Qi Wang

There is an issue with ldap and atlas settings where the ldap settings can get truncated at commas. You can tcpdump port 389 to verify. Possible solution is

Basically, escape every comma in the LDAP auth config page, but, it works now. Here are the relevant parameters I have set:

atlas.authentication.method.ldap.base.dn=cn=users\,cn=accounts\,dc=field\,dc=hortonworks\,dc=com atlas.authentication.method.ldap.bind.dn=uid=ldapconnect\,cn=users\,cn=accounts\,dc=field\,dc=hortonworks\,dc=com atlas.authentication.method.ldap.bind.password=password atlas.authentication.method.ldap.default.role=ROLE_USER atlas.authentication.method.ldap.groupRoleAttribute=cn atlas.authentication.method.ldap.groupSearchBase=cn=groups\,cn=accounts\,dc=field\,dc=hortonworks\,dc=com atlas.authentication.method.ldap.groupSearchFilter=(member=uid{0}\,cn=users\,cn=accounts\,dc=field\,dc=hortonworks\,dc=com)atlas.authentication.method.ldap.referral=ignore

atlas.authentication.method.ldap.type=ldap atlas.authentication.method.ldap.url=ldap://ldapserver.local:389 atlas.authentication.method.ldap.user.searchfilter=(uid={0})

atlas.authentication.method.ldap.userDNpattern=uid={0}\,cn=users\,cn=accounts\,dc=field\,dc=hortonworks\,dc=com

[#3]

@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.

[#4]

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

[#5]

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.

[#6]

@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 [].

[#7]

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.

[#8]

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!