You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Balázs Bence Sári (JIRA)" <ji...@apache.org> on 2017/07/21 12:25:00 UTC

[jira] [Created] (AMBARI-21546) Centralize LDAP Configuration for all services

Balázs Bence Sári created AMBARI-21546:
------------------------------------------

             Summary: Centralize LDAP Configuration for all services
                 Key: AMBARI-21546
                 URL: https://issues.apache.org/jira/browse/AMBARI-21546
             Project: Ambari
          Issue Type: Epic
            Reporter: Balázs Bence Sári
            Assignee: Laszlo Puskas
            Priority: Critical


LDAP configuration is time consuming, and follows a different pattern for each of the components below:

* Ambari
* Ranger
* Knox
* Atlas
* Hive
* Zeppelin

In each case the same information is required, but duplicated across multiple components.  Information required is:

* LDAP Host
* LDAP Port (389|636|*)
* LDAP Security (LDAP, LDAPS)
* LDAP anonymous bind support (default to false)
* LDAP Bind DN (dn: cn=hadoop,ou=services,ou=Users,dc=hortonworks,dc=local)
* LDAP Bind Password (****)
* LDAP Referrals Handling (follow|ignore)
* LDAP Search Scope (subtree|base|one)
* LDAP Server Certificate/CA Certificate (path to cert so it can be trusted using appropriate means)
* User Search Base (cn=Users,dc=hortonworks,dc=local)
* User Object Class (user)
* User RDN (cn)
* Group Search Base (cn=Groups,dc=hortonworks,dc=local
* Group Object Class (group)
* Group RDN (cn)
* Group Membership attribute (member)

If we can collect all of that information in one go - we can use it to configure the components above appropriately.  Allowing the user to follow a single approach to LDAP enabling the stack.  Additionally, this process should be optimized for Active Directory as that is in play in 90% of our installations.

----------

How we make this information available to other services is important.  In some situations a user may need to override the centralized configuration, so if we use variables that teams can use by default, but customers can override if necessary, that will be best.  For example:

* atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
* atlas.ldap.group.searchbase={{ ldap_group_searchbase }}

There could be situations where they need to have a separate group searchable for Atlas so the user would just customize that property

* atlas.ldap.user.searchbase={{ ldap_user_searchbase }}
* atlas.ldap.group.searchbase=OU=GROUPS,dc=hortonworks,dc=local



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)