[ 
https://issues.apache.org/jira/browse/AMBARI-20859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Levas resolved AMBARI-20859.
-----------------------------------
    Resolution: Fixed

> Improve User Account Management Within Ambari
> ---------------------------------------------
>
>                 Key: AMBARI-20859
>                 URL: https://issues.apache.org/jira/browse/AMBARI-20859
>             Project: Ambari
>          Issue Type: Epic
>          Components: ambari-server, ambari-web
>    Affects Versions: 2.7.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Major
>              Labels: authentication, pull-request-available, security, 
> user_management
>             Fix For: 2.7.0
>
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> As of Ambari 2.4, user management is confusing and tends to lead to 
> inconsistent results during synchronization and authentication.  With the 
> addition of new mechanisms such as Kerberos and PAM, this will only get 
> worse.  Therefore, there is a need to rework how Ambari manages users to 
> ensure that new authentication facilities are easily integrated.
> The following problems need to be solved:
> * *Case-sensitivity*
> Some authentication sources are case sensitive and some are not.  Ambari 
> inconsistently handles the case of user names leading to confusing where user 
> metadata is being created or being overwritten.  This issue extends from the 
> front end through the backend and to the database layer.   
> * *Username Collisions*
> There are several cases where username collisions occur.  One is where a 
> username exists as a local user as well as an external user.  For example, 
> the initial administrator account has is a local user account with the 
> username of "admin".  There may also be an external user account with the 
> username "admin". In some cases Ambari will treat both accounts as the same 
> user, converting the local account during synchronization operation to an 
> LDAP account. However in other cases, Ambari will treat the accounts as 
> separate users and create a separate account.  
> * *REST API*
> Due to the implementation of the user resource in the REST API, there is no 
> way to distinguish between user accounts with the same username and different 
> data sources. For example usera/LOCAL vs usera/LDAP.  This is because the 
> primary key for user resources is only the username field.  This make 
> managing users confusing since the REST API entrypoint for user resources is 
> /api/v1/users/:USERNAME and there is no way to retrieve or set the details 
> for a specific user. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to