[
https://issues.apache.org/jira/browse/AMBARI-23328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated AMBARI-23328:
-------------------------------------
Fix Version/s: 3.1.0
(was: 3.0.0)
> Remove LDAP Synchronization Process
> -----------------------------------
>
> Key: AMBARI-23328
> URL: https://issues.apache.org/jira/browse/AMBARI-23328
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Robert Levas
> Assignee: Robert Levas
> Priority: Major
> Labels: authentication, ldap
> Fix For: 3.1.0
>
>
> The existing LDAP synchronization process has the following challenges:
> * Common annoyance among Operators
> * Difficult to schedule as it’s interactive
> * Introduces delay in entitlements being granted to users (in LDAP), and more
> importantly from revocation.
> * Introduces issues with remove users that are no longer active, or with the
> company which == compliance concerns
> and benefits:
> * Simplifies auto-complete for adding users/groups to cluster roles and view
> permissions
> * Shields users from LDAP performance issues on login, and during user/group
> permission mapping
> Given that, Ambari's LDAP sync process should be removed to allow for users
> and groups to be dynamically synchronized with a configured LDAP server.
> Users should be added to the Ambari DB if necessary and groups are to be
> dynamically assigned and mapped to Ambari roles upon successful
> authentication with the configured LDAP server (via Ambari). A scheduled job
> may need to execute to clean out any orphaned data.
> The requirements will be broken out into categories of capabilities:
> 1.) Permission Mapping
> 2.) Permission Resolution
> 3.) User management
> *Permission Mapping*: Ability to map an individual LDAP User DN to a
> permission, as well as an individual Group DN to a permission
> *Permission Resolution*: Ability to resolve DN of user, DN of all directly
> mapped groups, and DN of all in-directly mapped groups (nested groups)
> * If the user logging in has no permissions they should not be allowed to
> login, but shown a message stating that they have no mapped permissions in
> Ambari and to contact their administrator, no Ambari DB user should be
> auto-created
> * If the user logging in has permissions, we should:
> ** Auto-create the Ambari user in the DB if it does not exist
> ** Check if we were asked to auto-create home directories on login, and if so
> check if the user has a home directory, if they don't, then auto-create it
> *User Management*: Because users will be auto-created in the Ambari DB, and
> because they will be authenticated against LDAP before being able to login we
> have to appropriately deal with two types of users:
> # Orphaned Users: Users without any mapped permissions - users enter this
> state by being in a group "HadoopOps" lets say and then six months later they
> are removed from this group. Or were directly mapped to a permission by name,
> and were removed from that permission. If they try logging into Ambari they
> will not be allowed to login and will be shown the message stating that they
> have no permissions. These users need to be removed from Ambari individually
> through the Ambari UI with a "Remove LDAP User" button on the user.
> # Deprovisioned Users: Users who have been either removed or inactivated in
> the upstream LDAP server due to termination or other reasons - In most
> situations we'll never see these users again.
> For both types of users having the following capabilities would be extremely
> helpful:
> * Ability to remove individual LDAP users from Ambari "Remove LDAP User"
> button
> * Ability to remove all users who haven't logged in in more than x days.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
