ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balázs Bence Sári (JIRA) <j...@apache.org>
Subject [jira] [Created] (AMBARI-21546) Centralize LDAP Configuration for all services
Date Fri, 21 Jul 2017 12:25:00 GMT
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)

Mime
View raw message