[ 
https://issues.apache.org/jira/browse/HADOOP-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268319#comment-15268319
 ] 

Kai Zheng commented on HADOOP-12782:
------------------------------------

I took a look more closely at the codes. It looks good overall. I'd suggest we 
refresh this to avoid the word *Fast* for the reason I mentioned above, when 
convenient. Also some minor comments:
* We could remove the variable {{useFastLookup}}, instead use {{memberOfAttr != 
null}} directly to indicate the case.
* Ref. the following block, we could embed the logic in {{fastLookup}} directly 
to simplify some bit?
{code}
    if (useFastLookup) {
      try {
        return fastLookup(result);
      } catch (NamingException e) {
        // If fast lookup failed, fall back to the typical scenario.
        LOG.debug("Failed in fast lookup. Initiating the second LDAP query " +
            "using the user's DN.", e);
      }
    }
{code}
* Please have a line break between functions; 
* Please also avoid star imports;
* Could we remove the word *experimental* in the user doc?

> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to