[
https://issues.apache.org/jira/browse/HADOOP-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283557#comment-15283557
]
Kai Zheng commented on HADOOP-12782:
------------------------------------
Sorry for the late. Thanks [~jojochuang] for the update! It looks almost
perfect to me now. Some comments for the test codes:
* Maybe we can rename: mockUserNamingEnum -> userNames, mockGroupNamingEnum ->
groupNames, mappingSpy -> groupsMapping, or something like that. Also note the
related methods.
* For above mentioned mocked variables, is it possible to refactor and move all
the related mock codes to the base class? For example:
{code}
SearchResult mockUserResult = mock(SearchResult.class);
when(getMockUserNamingEnum().nextElement()).thenReturn(mockUserResult);
{code}
> Faster LDAP group name resolution with ActiveDirectory
> ------------------------------------------------------
>
> Key: HADOOP-12782
> URL: https://issues.apache.org/jira/browse/HADOOP-12782
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Wei-Chiu Chuang
> Assignee: Wei-Chiu Chuang
> Attachments: HADOOP-12782.001.patch, HADOOP-12782.002.patch,
> HADOOP-12782.003.patch, HADOOP-12782.004.patch, HADOOP-12782.005.patch,
> HADOOP-12782.006.patch, HADOOP-12782.007.patch
>
>
> The typical LDAP group name resolution works well under typical scenarios.
> However, we have seen cases where a user is mapped to many groups (in an
> extreme case, a user is mapped to more than 100 groups). The way it's being
> implemented now makes this case super slow resolving groups from
> ActiveDirectory.
> The current LDAP group resolution implementation sends two queries to a
> ActiveDirectory server. The first query returns a user object, which contains
> DN (distinguished name). The second query looks for groups where the user DN
> is a member. If a user is mapped to many groups, the second query returns all
> group objects associated with the user, and is thus very slow.
> After studying a user object in ActiveDirectory, I found a user object
> actually contains a "memberOf" field, which is the DN of all group objects
> where the user belongs to. Assuming that an organization has no recursive
> group relation (that is, a user A is a member of group G1, and group G1 is a
> member of group G2), we can use this properties to avoid the second query,
> which can potentially run very slow.
> I propose that we add a configuration to only enable this feature for users
> who want to reduce group resolution time and who does not have recursive
> groups, so that existing behavior will not be broken.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
