I'have ambari with ldap authentication throught Active directory.
I have users that are members of bigdata_dept and this group is member of bigdata_test, I've successfuly configured ambari to allow login with nested members from bigdata_test, but when you check their group membership, ambari only recognice bigdata_dept and it doesn't sync the membership to bigdata_test, with this kind of configuration if I've a new group member of bigdata_test I've to configure the roles for it when I want to avoid it giving every nested member of bigdata_test the same role.
Do you know any way to acomplish this?
Thank you in advance
- Enabling the logging inside ambari's log4j.properties file can give us more details.
. - Also can you please share the output of the following so that we can check the AD settings are correct or not? Specially the "authentication.ldap.groupMembershipAttr=member"
# grep 'ldap' /etc/ambari-server/conf/ambari.properties
- Some sample settings can be seen in the Hortonworks University Github: https://github.com/HortonworksUniversity/Security_Labs#setup-ambariad-sync
- Using the "ldapsearch" are you able to locate the groups and members properly.- Which version of Ambari Server are you using? I remember that there were few issues reported for older version of Ambari for Nested Group membership syncing. https://issues.apache.org/jira/browse/AMBARI-15383 https://issues.apache.org/jira/browse/AMBARI-16875
Hello @Jay SenSharma
My properties of ldap are:
[root@hadoop01 ~]# cat /etc/ambari-server/conf/ambari.properties | grep ldap ambari.ldap.isConfigured=true authentication.ldap.baseDn=DC=TEST,dc=INT authentication.ldap.bindAnonymously=false authentication.ldap.dnAttribute=distinguishedName authentication.ldap.groupMembershipAttr=member authentication.ldap.groupNamingAttr=cn authentication.ldap.groupObjectClass=group authentication.ldap.managerDn=CN=Administrador,CN=Users,DC=test,DC=int authentication.ldap.managerPassword=/etc/ambari-server/conf/ldap-password.dat authentication.ldap.primaryUrl=dns.test.int:389 authentication.ldap.referral=ignore authentication.ldap.useSSL=false authentication.ldap.userObjectClass=user authentication.ldap.usernameAttribute=sAMAccountName client.security=ldap
I also have tried with authentication.ldap.groupMembershipAttr=member:1.2.840.1135184.108.40.2061:
I have a cron script for ldapsync which take groups from a csv which contains the following:
[root@hadoop01 ~]# cat /etc/ambari-server/ambari-groups.csv bigdata_pro,bigdata_test
As I said the user of the nested groups from bigdata_test are correctly imported but only get the non nested membership, for exampler user A is member of bigdata_dept so ambari with the current config import it fine, also import the group but it doesn't import the nested membership from bigdata_test of the user A.
I think this is happening because ambari is using the "member" attribute of the group to resolve membership instead of the "memberOf" from users, so the member attribute in AD is not the sAMAccount attribute is a DN using the name of the user instead of his username.
Using ldapsearch I'm able to locate them, I have also configured this with ranger without any problem because ranger uses memberOf, i just had to change memberOf attribute for memberOf:1.2.840.1135220.127.116.111: in the configuration.
Example of ldapsearch
[root@hadoop01 ~]# ldapsearch -H ldap://dns.test.int:389 -D "CN=Administrador,CN=Users,DC=test,DC=int" -w ******** -b "CN=Users,DC=test,DC=int" "(&(objectClass=group)(member:1.2.840.113518.104.22.1681:=CN=Test User,CN=Users,DC=test,DC=int))" # extended LDIF # # LDAPv3 # base <CN=Users,DC=test,DC=int> with scope subtree # filter: (&(objectClass=group)(member:1.2.840.113522.214.171.1241:=CN=Test User,CN=Users,DC=test,DC=int)) # requesting: ALL # # bigdata_test, Users, test.int dn: CN=bigdata_test,CN=Users,DC=test,DC=int objectClass: top objectClass: group cn: bigdata_test member: CN=bigdata_dept,CN=Users,DC=test,DC=int distinguishedName: CN=bigdata_test,CN=Users,DC=test,DC=int instanceType: 4 whenCreated: 20170327155638.0Z whenChanged: 20170327155801.0Z uSNCreated: 114767 uSNChanged: 114775 name: bigdata_test objectGUID:: N5RfdDd6BkehR11KV9R60g== objectSid:: AQUAAAAAAAUVAAAAkdwG8YCru32euQq7bwQAAA== sAMAccountName: bigdata_test sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=test,DC=int dSCorePropagationData: 16010101000000.0Z # bigdata_dept, Users, test.int dn: CN=bigdata_dept,CN=Users,DC=test,DC=int objectClass: top objectClass: group cn: bigdata_dept member: CN=Test User,CN=Users,DC=test,DC=int distinguishedName: CN=bigdata_dept,CN=Users,DC=test,DC=int instanceType: 4 whenCreated: 20170327155801.0Z whenChanged: 20170329120729.0Z uSNCreated: 114771 memberOf: CN=bigdata_test,CN=Users,DC=test,DC=int uSNChanged: 117001 name: bigdata_dept objectGUID:: s88OW4HJ1kuBxZljIlRSAw== objectSid:: AQUAAAAAAAUVAAAAkdwG8YCru32euQq7cAQAAA== sAMAccountName: bigdata_dept sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=test,DC=int dSCorePropagationData: 16010101000000.0Z # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2