Details
-
Epic
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
None
-
None
-
None
-
Centralize LDAP Configuration for all services
Description
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