----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40019/#review105483 -----------------------------------------------------------
Ship it! Ship It! - Robert Levas On Nov. 6, 2015, 11:24 a.m., Oliver Szabo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/40019/ > ----------------------------------------------------------- > > (Updated Nov. 6, 2015, 11:24 a.m.) > > > Review request for Ambari, Dmytro Sen and Robert Levas. > > > Bugs: AMBARI-13767 > https://issues.apache.org/jira/browse/AMBARI-13767 > > > Repository: ambari > > > Description > ------- > > Group Membership not pulled in with FreeIPA/RHELIDM > > In FreeIPA/RHEL (389 DS for the directory server implementation) the DN is > not an attribute on the user, and cannot be used in a filter like this: > > (&(objectClass=posixaccount)(|(dn=uid=dstreev,cn=users,cn=accounts,dc=hdp,dc=local)(uid=uid=dstreev,cn=users,cn=accounts,dc=hdp,dc=local))) > > In some cases all of the groups/users are gathered from an ldap query (then > put into a set). I did the same, after ther filter the results based on dn > (or uid/groupname if that is the case) in the java code. > > > Notes: > - I filter the groups in memory, so there are some new places where I > gathered all of the groups/users. (we alrady do that actually) maybe that can > cause bad performance during the sync. I will do a performance testing with a > lot of users at the weekend, and see how much we should wait based on the > number of users,groups or on the nested group structure. in case of > performance issues: I have an another solution : > MemberAttributes can be used to query/filter on the groups/users. E.g.: in > openldap the member attributes are names, like: hive,hadoop etc. -> there we > can use the actual solution. In another providers, like freeIPA the member > attributes looks like: uid=hive,cn=..., that means these attributes can be > used in queries as the baseDN (so dn part is not needed in the filter), than > the query wont fail. (I did not want to choose this solution for avoiding > conditions based on how memberattributes looks like in different providers) > > - there is no group-group relation in ambari. for nested groups: currently > we don't see the user members in the upper groups. I could flatten the users > to the upper groups during the sync, but it is not the right way to do it, > because in case of we delete a user from the subgroup and we syncing only on > the subgroup, the users are not deleted from the upper groups. (we can do > that, but then we sync all of the groups..) > -> the right way should be if we would see the subgroups in the upper groups > (for that, we need the group-group relationship in the future) > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java > 103cfcb > > ambari-server/src/main/java/org/apache/ambari/server/security/ldap/LdapGroupDto.java > 132cbe5 > > ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java > 3f4f7b5 > > Diff: https://reviews.apache.org/r/40019/diff/ > > > Testing > ------- > > In progress ... > > > Thanks, > > Oliver Szabo > >
