You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

User and Group Filter Support with LDAP

Starting in Hive 1.3.0, HIVE-7193 adds support in HiveServer2 for

  • LDAP Group filters
  • LDAP User filters
  • Custom LDAP Query support.

Filters greatly enhance the functionality of the LDAP Authentication provider. They allow Hive to restrict the set of users allowed to connect to HiveServer2.

Group Membership

This enables HiveServer2 to enforce group membership for users. The authentication request will succeed if the user belongs to one or more of the groups listed in the Hive configuration file. If the user does not belong to at least one of the groups listed, the user authentication fails.

Two configuration parameters support group-membership based authentication:

  • hive.server2.authentication.ldap.groupDNPattern

  • hive.server2.authentication.ldap.groupFilter

hive.server2.authentication.ldap.groupDNPattern

This value represents a pattern for “distinguishedName” (DN) for groups in the directory. This value could be a single DN if the LDAP Group entities are co-located or could be a colon separated list of all DN patterns if the groups are scattered across different trees.

Each DN pattern can contain a “%s” in it that will be substituted with the group name (from the group filter) by the provider for group search queries.

Example 1 (single DN):

<property>
  <name>
    hive.server2.authentication.ldap.groupDNPattern
  </name>
  <value>CN=%s,OU=Groups,DC=apache,DC=org</value>
</property>

This indicates that all LDAP group entries are under the directory root “OU=Groups,DC=apache,DC=org”.

The LDAP Authentication Provider replaces the %s with the group name in the LDAP queries to locate the group entry. For example, if a group named “group1” is being queried for, it uses "CN=group1,OU=Groups,DC=apache,DC=org".

Example 2 (two DNs):

<property>
  <name>
    hive.server2.authentication.ldap.groupDNPattern
  </name>
  <value>
      CN=%s,OU=Groups,DC=apache,DC=org:uid=%s,CN=Users,DC=apache,DC=org
  </value>
</property>

The above pattern advises the LDAPAtnProvider that LDAP group entities can exist in two separate trees in the directory and can have different attributes in their DNs. (Note the colon separator.)

hive.server2.authentication.ldap.groupFilter

This value represents the group name filter that is to be enforced by the LDAPAtnProvider. All individual groups are represented using a comma separated list. The user MUST belong to one or more of these groups for the authentication request to succeed.

Example:

<property>
  <name>hive.server2.authentication.ldap.groupFilter</name>
  <value>group1,group2</value>
</property>

User Search List

This enables HiveServer2 to restrict access to a specified list of users. If the user being authenticated is not part of this userlist, access will be denied.

Two configuration parameters support this feature:

  • hive.server2.authentication.ldap.userDNPattern
  • hive.server2.authentication.ldap.userFilter

hive.server2.authentication.ldap.userDNPattern

This value represents a pattern for “distinguishedName” (DN) for users in the directory. This value could be a single DN if the LDAP User entities are co-located within a single root or could be a colon separated list of all DN patterns if the users are scattered across different trees/forests in the directory.

Each DN pattern can contain a “%s” in it that will be substituted with the username (from the user filter) by the provider for user search queries.

Example 1 (single DN):

<property>
  <name>
    hive.server2.authentication.ldap.userDNPattern
  </name>
  <value>
    CN=%s,CN=Users,DC=apache,DC=org
  </value>
</property>

In the example above, all users are co-located under a single root “CN=Users,DC=apache,DC=org”. To search for user “foo”, LDAPAtnProvider attempts to find the user with DN like “CN=foo,CN=Users,DC=apache,DC=org”.

Example 2 (two DNs):

<property>
  <name>
    hive.server2.authentication.ldap.userDNPattern
  </name>
  <value>
      CN=%s,OU=Users,DC=apache,DC=org:uid=%s,CN=UnixUsers,DC=apache,DC=org
  </value>
</property>

The above pattern advises the LDAPAtnProvider that LDAP user entities can exist in two separate trees in the directory and can have different attributes in their DNs. (Note the colon separator.)

hive.server2.authentication.ldap.userFilter

This is a comma separated list of usernames to grant access to. The Atn provider grants access if the user being authenticated is part of this list, and denies access otherwise.

Example:

<property>
  <name>
    hive.server2.authentication.ldap.userFilter
  </name>
  <value>
    hive-admin,hive,hivetest,hive-user
  </value>
</property>

Custom Query String

There are several LDAP implementations available for commercial use, with no standard attributes within each implementation. If either of the above filters do not meet the requirements for some unforeseen reasons, HiveServer2 can use a user-specified LDAP Query string to execute against the LDAP server. The returned result will then be used to adjudicate a GRANT/DENY decision to the authenticating user. To support this configuration, a new configuration property has been introduced.

hive.server2.authentication.ldap.customLDAPQuery

Example:

<property>
  <name>hive.server2.authentication.ldap.customLDAPQuery</name>
  <value><![CDATA[(&(objectClass=person)(|(memberOf=CN=Domain Admins,CN=Users,DC=apache,DC=org)(memberOf=CN=Administrators,CN=Builtin,DC=apache,DC=org)))]]>
  </value>
</property>

The above query returns “All users that are members of the one of the groups (Domain Admins or Administrators)”. This offers a lot more flexibility that allows Hive users to customize the LDAP configuration for their implementation of LDAP.

Order of Precedence

The group membership parameters can be used in conjunction with the user lists to enforce a stricter access. The LDAP Atn provider adjudicates authentication decisions according to the following criteria:

  1. If hive-site.xml contains “hive.server2.authentication.ldap.customLDAPQuery”, only the results of this query are used to adjudicate an authentication decision. All other property values (*.groupDNPattern, *.groupFilter, *.userDNPattern, *.userFilter) are ignored entirely.
  2. If the *.groupFilter and *.userFilter parameters are both specified in the configuration file, access is granted if and only if the user being authenticated satisfies both conditions; access is denied otherwise. So the user has to be listed in the *.userFilter and the user MUST also belong to one of the groups listed in the *.groupFilter.
  3. If only one of the filters ( ( *.userDNPattern + *.userFilter ) || ( *.groupDNPattern + *.groupFilter ) ) is specified, a decision is adjudicated based on whether the user being authenticated satisfies the specified filter.
  4. If neither *.groupFilter nor *.userFilter is specified in the configuration file, the provider attempts to search for the user in the LDAP directory within the baseDN tree. Access is granted if user has been found, and denied otherwise. IMPORTANT: This implementation is a little more stringent compared to the prior implementation. In the prior implementation, if the baseDN was not provided, authentication would be granted if the provider is to be able to the bind to LDAP with the user.
  • No labels