Improved Active Directory and LDAP Integration

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.

[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]

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