[
https://issues.apache.org/jira/browse/HADOOP-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HADOOP-12782:
-------------------------------------
Attachment: HADOOP-12782.001.patch
Rev01: implemented fast ldap group name lookup, the associated test case, and
associated documentation.
In this implementation, there are basically three cases:
# general scenario, perform two ldap queries per group lookup.
# If the server supports posix semantics, perform two ldap queries using posix
gid/uid to find groups of the user
# (new implementation) perform one ldap query per group lookup, if fast lookup
is enabled (The server must be an Active Directory, no recursive group
membership and use CN attribute to identify a group's name)
To enable this feature, set
hadoop.security.group.mapping.ldap.search.filter.group=ldapFastLookup.
I also updated the first two scenarios so that more verbose message will be
logged in case of exceptions. (supportability)
Finally, a new test file TestLdapGroupsMappingWithFastLookup is added that
tests the new feature. The test (as well as TestLdapGroupsMapping and
TestLdapGroupsMappingWithPosixGroup) all passed locally.
> 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
>
>
> 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)
