[
https://issues.apache.org/jira/browse/AMBARI-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334055#comment-16334055
]
Sandor Molnar commented on AMBARI-21546:
----------------------------------------
[~rlevas]
This one is for you.
> 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: Sandor Molnar
> Priority: Critical
> Fix For: 3.0.0
>
>
> 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
(v7.6.3#76005)
