You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Oliver Szabo <os...@hortonworks.com> on 2015/11/06 17:24:51 UTC
Review Request 40019: LDAP - Group Membership not pulled in with
FreeIPA/RHELIDM
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40019/
-----------------------------------------------------------
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
Re: Review Request 40019: LDAP - Group Membership not pulled in with
FreeIPA/RHELIDM
Posted by Oliver Szabo <os...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40019/
-----------------------------------------------------------
(Updated Nov. 9, 2015, 7:54 p.m.)
Review request for Ambari, Dmytro Sen and Robert Levas.
Changes
-------
I did some performance testing. It seems: not a good idea to gather all of the users during sync (e.g.: we just want to sync some groups, and obtaining all of the users is a must...so pagination is needed). because of that, filter query is changed: where the model attribute can be used as a base DN a different query is used. Also an another fix is included to the patch for group membership pulling, subgroups are not processed in case of those are not found in the group csv file.
Bugs: AMBARI-13767
https://issues.apache.org/jira/browse/AMBARI-13767
Repository: ambari
Description (updated)
-------
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)))
Notes:
- 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.
- 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 (updated)
-----
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java 103cfcb
ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java 3f4f7b5
Diff: https://reviews.apache.org/r/40019/diff/
Testing (updated)
-------
Unit tests done.
Functional testing:
- works as expected with different ldap providers
- nested group case: groupA has a groupB member, groupB has 2 users. Group csv file only contains groupA, then groupA and groupB were processed and 2 memberships were created.
Thanks,
Oliver Szabo
Re: Review Request 40019: LDAP - Group Membership not pulled in with
FreeIPA/RHELIDM
Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
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
>
>