Presto: Improved Active Directory and LDAP Integration

[Ralnoc]

Currently the practices in place for the Active Directory/LDAP authentication integrations are not very flexible and make it difficult to work with on a platform running an advanced AD or LDAP implementation.

It is common for larger organizations to leverage many branched out organizational units to effectively handle the management of users within the organization. The existing implementation of ldap.user-bind-pattern for initial bind and user authentication dramatically limits the method of organizing users within an organization and would even block the ability to implement PrestoDB authentication with many larger organizations.

What I would recommend is making a change regarding how these processes are implemented. Creating a new ldap.binddn and ldap.bindpassword configuration property which would be used by the application to connect to the LDAP/AD servers for purposes of doing searches. You would be able to remove the ldap.user-bind-pattern and leverage everything off of the existing ldap.group-auth-pattern for purposes of identifying who a user is and if they should be able to log in.

For example, if you set the following configuration with the above changes:

password-authenticator.name=ldap
ldap.url=ldaps://ldap-server:636
ldap.binddn=CN=User Name,OU=CITY_OU,OU=STATE_OU,DC=domain,DC=domain_root
ldap.bindpassword=password1234
ldap.group-auth-pattern=(&(objectClass=user)(|(sAMAccountName=${USER}))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(|(memberOf=CN=users,OU=Groups,DC=domain,DC=domain_root)(memberOf=CN=admins,OU=Groups,DC=domain,DC=domain_root)(memberOf=CN=secops,OU=Groups,DC=domain,DC=domain_root)(memberOf=CN=operations,OU=Groups,DC=domain,DC=domain_root)))

You gain the ability to have users organized in whatever fashion you wish them to be within LDAP/AD. They are not locked into a specific organization path, as they currently are. In addition, this specific search will only return results for the user if the are in one of the listed groups, and are an Active account in Active Directory.

The idea is to leverage the power behind Active Directory or LDAP searches for controlling authentication, instead of trying to codify an implementation around a well developed platform. The new process would be to use the ldap.binddn and ldap.bindpassword to look up the users DN in LDAP/AD and then use the provided user provided password to authenticate once the validation of access has already been confirmed using the ldap.binddn user.

In addition, you can potentially have an ldap.bind.anonymous=<bool> option and set it to false so that the ldap.group-auth-pattern is just run against the LDAP/AD server without trying to auth. This is a configuration supported by ldap and can be configured in AD. Though I would suggest that would be a really low priority setup as most people I expect would have the system requiring a ldap.binddn/ldap.bindpassword.

[sqlaide]

+1

[sajjoseph]

While I agree with the proposal, one alternative is to use OpenID based authentication. So, Presto is not involved in authenticating user, but uses the token from authentication server.
@anusudarsan - thoughts/suggestions?

[Ralnoc]

While I agree with the reasoning and love the idea of alternative authentication methods, OpenID based auth would break future integrations with things like Apache Ranger and would make client authentication much more difficult. This is the same issue with SAML authentication.

LDAP and Active Directory authentications are industry standards, so having them in place makes sense. It would just be better if they were implemented in a way that is standardized with how LDAP and AD expect clients to communicate with it.

[sopel39]

@Ralnoc In your proposed solution, how do you suggest to validate user password if ldap.user-bind-pattern is removed for initial bind and user authentication?

[jar349]

Presto was always doing the Right Thing to validate users' passwords - attempt a bind with what's provided. However, many LDAP implementations restrict users' access to perform further searches (ex for group memberships). In addition, most production LDAP implementations I've seen have disallowed anonymous binding.

The solution is usually to configure a service with its own LDAP credentials (usually, a read-only account that has access to read much of the directory) and then to validate user credentials by attempting to perform a second bind.

[Ralnoc]

@sopel39 -
As commented by @jar349 , the standard behavior of LDAP in relation to validating passwords is not incorrect. It is just the process of getting to that which needs adjusting. The general authentication process for most applications against LDAP is as follows -

• User logs in with a username and password
• Application contains a pre-configured Bind DN and Bind Password
  -- Bind DN would be something like uid=username,ou=Users,dc=example,dc=com on LDAP
  -- Bind DN would be either something like cn=Full Name,ou=Users,dc=example,dc=com or [email protected] on AD
• Using preconfigured BindDN/BindPassword, application would lookup the user utilizing a administrator defined LDAP search query built to lookup a specific user within a search base. It would retrieve the user and it's atributes.
  -- And example of this would be something like (&(objectClass=user)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(sAMAccountName=${USER})) Which searches Active Directory for an enabled user that matches the specific username.
• Using the DN of the identified user, it would then auth against LDAP using the password entered by the user.
• The user is now authenticated and all the groups the user is a member of are available to the application as a result of the query.
• You can then implement the groups in one of two ways.
  -- The existing way is effective, at which point, you can run the group logic as is.
  -- Alternatively, you can leverage the groups which are queried from the user as a means of both controlling access to presto itself, as well as expanding what is available in the authorization features. Specifically, you can replace the group auth pattern with a list of groups. Then you can the built in system access control to support groups as well as users.

[jar349]

One small nit:

The user is now authenticated and all the groups the user is a member of are available to the application as a result of the query.

This is not _always_ true. Not everyone uses the memberOf overlay. In my experience, there's usually a preconfigured group membership query that can be run under the preconfigured bindDN/password to discover the authenticated user's group memberships.

[Ralnoc]

That is a fair point. The more common implementation is to lookup the DN, auth with it to complete authentication as described above.

Then the group implementation would either be exactly as it stands, requiring no changes, or build a user group search that returns a list of all groups on the user is a memeber of, which allows you to leverage those groups as described in the alternative group use above.

[bobbyburgess]

+1!

Okta's LDAP interface does not support anonymous binds, so we simply cannot use it with Presto which is unfortunate.

More info:

https://help.okta.com/en/prod/Content/Topics/Directory/LDAP_Using_the_LDAP_Interface.htm

[findepi]

@bobbyburgess,
anonymous binds are not necessary when using Starburst Presto 302e (or Presto 311).
dedicated service user for LDAP (as requested in this issue by @Ralnoc) is supported by Starburst Presto 302e. See ldap.bind-dn in Presto LDAP Authentication documentation.

[theesen]

Hello,

we had the same issue on our side and started to implement a solution that works for us. But I would love to contribute this back to the project.
It would be great to get some feedback on the implementation before doing a PR (especially since I have not done this a lot yet).
My fork is still WIP and I have not applied all the implementation ideas yet. But since this is open for a long time already I thought it can't hurt to kick it off somewhere :)
Sample Pull Request

[tomSmida]

Hello,

are there any plans to review/feedback the prePR? Or maybe @theesen would you mind to open the PR, so the momentum would take off a bit? We would appreciate to have this in upstream, since we are facing these exact issues and this would solve it completely. 🙏

[theesen]

Sure @tomSmida I will put some time aside next week to prepare the PullRequest.
Had my notification messed up in github so I saw the message quite late. I did not put any further effort into it because there was no reaction here :) But since I am not the only one looking for that feature I will invest more time in it.