I am trying to configure LDAP authentication with Ambari and other components (e.g. Zeppelin, Ranger and Knox). This is a complex environment with Centrify where users have multiple identities which resolve to a single ID in Linux. On Linux, my id is "u1101". I can execute "id u1101" or "id james-jones" and both result in the same Linux ID -- e.g. uid=60012(u1101) gid=5001(user). On a Windows system, only james-jones works. There are two domains: company.com and corp.company.int.
I want to configure LDAP authentication using the Linux ID rather than the windows sAMAccountName, but it only works with the sAMAccountName. I have configured the correct settings in Ambari for userObjectClass, baseDn, userAttributeName, primaryUrl, managerDn, etc. I don't know if the problem is with Centrify or an LDAP server hosting the Linux accounts.
I decided to conduct a test, and it seems that using dn bind account is prohibited in one case but not the other.
Since Ambari LDAP authentication essentially does two queries, one with the bind user to find the person logging in, and then a second query with the person's DN and the password they entered, I tested two ldapsearch queries. One with the Windows DN and the second using the Linux DN.
Using ldapsearch, this query succeeds using my Windows domain DN
ldapsearch -D "CN=1101737,OU=NY,OU=my_company,OU=CO_Users,DC=corp,DC=company,DC=int" -W \ -b "dc=corp,dc=company,dc=int" \ "sAMAccountName=james-jones"
This query fails on authentication using my UNIX domain DN
ldapsearch -D "CNfirstname.lastname@example.org,CN=Users,CN=Global,CN=Zones,OU=Centrify,OU=Enterprise Systems,DC=corp,DC=company,DC=int" -W \ -b "DC=corp,DC=company,DC=int" \ "sAMAccountName=james-jones"
There are two different LDIFs for these two ids (u1101 and james-jones):
sAMAccountName=james-jones objectClass=person dn=CN=1101737,OU=NY,OU=my_company,OU=CO_Users,DC=corp,DC=company,DC=int distinguishedName==CN=1101737,OU=NY,OU=my_company,OU=CO_Users,DC=corp,DC=company,DC=int
The other looks like non-AD LDAP and I think openLdap may be behind it with some centrify magic going on.
uid=u1101 objectClass=posixAccount dn=CNemail@example.com,CN=Users,CN=Global,CN=Zones,OU=Centrify,OU=Enterprise Systems,DC=corp,DC=company,DC=int distinguishedName=CNfirstname.lastname@example.org,CN=Users,CN=Global,CN=Zones,OU=Centrify,OU=Enterprise Systems,DC=corp,DC=company,DC=int
The reason this matters is that when I use Ambari views, my account needs to match the Unix accounts.
Hopefully that made sense. It's a bit long and complicated. Any help is very appreciated.
Thank you @vperiasamy. We resolved the issue. I talked to Centrify Support and based on the way this environment was configured, authentication was not possible with the uid and Linux dn. The company's Centrify admins agreed to change the uid of users to match the Windows ID. We then configured authentication to go against the Windows identity, which happens to match the uid in Linux. It's a long story about the use-case, but this was by far the cleanest solution due to the fact that they use both Linux and Windows to access the cluster (we avoided manual mapping of identities this way).
The article you shared is very good information.