Enabling LDAP Authentication for Impala

Authentication against LDAP servers is available in Impala 1.2.2 and higher. Impala 1.4.0 adds support for secure LDAP authentication through SSL and TLS.

The Impala LDAP support lets you use Impala with systems such as Active Directory that use LDAP behind the scenes.

Only client-Impala connections can be authenticated by LDAP.

You must use the Kerberos authentication mechanism for connections between internal Impala components, such as between the impalad, statestored, and catalogd daemons. See Enabling Kerberos Authentication for Impala on how to set up Kerberos for Impala.

To enable LDAP authentication, start the impalad with the following startup options for:

--enable_ldap_auth

Enables LDAP-based authentication between the client and Impala.

--ldap_uri

Sets the URI of the LDAP server to use. Typically, the URI is prefixed with ldap://. You can specify secure SSL-based LDAP transport by using the prefix ldaps://. The URI can optionally specify the port, for example: ldap://ldap_server.example.com:389 or ldaps://ldap_server.example.com:636. (389 and 636 are the default ports for non-SSL and SSL LDAP connections, respectively.)

--ldap_search_bind_authentication

Allows to switch between search and simple bind user lookup methods when authenticating, the default value is false which is simple bind.

The bind user is used to run the user/group searches, the credentials can be configured with the following flags:

--ldap_allow_anonymous_binds

When true, LDAP authentication with a blank password (an 'anonymous bind') is allowed by Impala. The default value is false.

--ldap_bind_dn

Distinguished name of the user to bind as when doing user or group searches. Only required if user or group filters are being used and the LDAP server is not configured to allow anonymous searches.

--ldap_bind_password_cmd

A Unix command whose output returns the password to use with --ldap_bind_dn. The output of the command will be truncated to 1024 bytes and trimmed of trailing whitespace.

When Impala connects to LDAP it issues a bind call to the LDAP server to authenticate as the connected user. Impala clients, including the Impala shell, provide the short name of the user to Impala. This is necessary so that Impala can use Ranger for role-based access, which uses short names.

However, LDAP servers often require more complex, structured usernames for authentication. Impala supports three ways of transforming the short name (for example, 'henry') to a more complicated string. If necessary, specify one of the following configuration options when starting the impalad daemon.

--ldap_domain

Replaces the username with a string username@ldap_domain.

--ldap_baseDN

Replaces the username with a "distinguished name" (DN) of the form: uid=userid,ldap_baseDN. (This is equivalent to a Hive option).

--ldap_bind_pattern

This is the most general option, and replaces the username with the string ldap_bind_pattern where all instances of the string #UID are replaced with userid. For example, an ldap_bind_pattern of "user=#UID,OU=foo,CN=bar" with a username of henry will construct a bind name of "user=henry,OU=foo,CN=bar".

--ldap_user_filter

A comma separated list of usernames. If specified, users must be on this list for authentication to succeed

--ldap_group_filter

If specified, users must belong to one of these groups for authentication to succeed.

--ldap_group_dn_pattern

Colon separated list of patterns for the 'distinguished name' use to search for groups in the directory. Each pattern may contain a '%s' which will be substituted with each group name from --ldap_group_filter when doing group searches.

--ldap_group_membership_key

The LDAP attribute on group entries that indicates its members.

--ldap_group_class_key

The LDAP objectClass each of the groups in --ldap_group_filter implements in LDAP.

When Search Bind authentication is enabled Impala first tries to bind with the configured bind user, then executes an LDAP Search operation to find if the user exists. Once the search succeeds the DN is retrieved from the LDAP search results and another LDAP bind request is executed, this time with the connecting user to verify the password.

This authentication method allows to authenticate users existing in different LDAP subtrees when these users' parent tree is configured as base DN.

--ldap_user_search_basedn

The 'distinguished name' DN that will be used to search for the authenticating user, this field is required for search bind authentication.

--ldap_group_search_basedn

The 'distinguished name' DN that will be used to search for the authenticating group. If left empty, group checks will not be performed.

--ldap_user_filter

LDAP filter that will be used during LDAP search, it can contain {0} pattern which will be replaced with the username. The default value is (&(objectClass=user)(sAMAccountName={0})).

--ldap_group_filter

LDAP filter that will be used during LDAP group search, it can contain {1} pattern which will be replaced with the username and/or {0} which will be replaced with the user DN. The default value is (&(objectClass=group)(member={0}).

Note: The behaviour of this flag has been changed between Impala 4.1 and Impala 4.2 to comply with Spring LDAP. Previously {0} was for username and {1} for user dn, these paramters were swapped, now {0} is for user dn and {1} is for username.

To avoid sending credentials over the wire in cleartext, you must configure a secure connection between both the client and Impala, and between Impala and the LDAP server. The secure connection could use SSL or TLS.

Secure LDAP connections through SSL:

For SSL-enabled LDAP connections, specify a prefix of ldaps:// instead of ldap://. Also, the default port for SSL-enabled LDAP connections is 636 instead of 389.

--ldap_passwords_in_clear_ok

Allows LDAP passwords to be sent in the clear (without TLS/SSL) over the network, when set to true. This option should not be used in production environments.

Secure LDAP connections through TLS:

TLS, the successor to the SSL protocol, is supported by most modern LDAP servers. Unlike SSL connections, TLS connections can be made on the same server port as non-TLS connections. To secure all connections using TLS, specify the following flags as startup options to the impalad daemon.

--ldap_tls

Tells Impala to start a TLS connection to the LDAP server, and to fail authentication if it cannot be done.

--ldap_ca_certificate

Specifies the location of the certificate in standard .PEM format. Store this certificate on the local filesystem, in a location that only the impala user and other trusted users can read.

To connect to Impala using LDAP authentication, you specify command-line options to the impala-shell command interpreter and enter the password when prompted:

-l

Enables LDAP authentication.

-u

Sets the user. Per Active Directory, the user is the short username, not the full LDAP distinguished name. If your LDAP settings include a search base, use the --ldap_bind_pattern on the impalad daemon to translate the short username from impala-shell automatically to the fully qualified name.

--auth_creds_ok_in_clear

If set, LDAP authentication may be used with an insecure connection to Impala. This flag is required when SSL between impala-shell and Impala Server is not configured. Authentication credentials will therefore be sent unencrypted, and may be vulnerable to attack.

See Configuring Impala to Work with JDBC for the format to use with the JDBC connection string for servers using LDAP authentication.

See Configuring Impala Delegation for Clients for details about the delegation feature that lets certain users submit queries using the credentials of other users.

The LDAP support is preliminary. It currently has only been tested against Active Directory.