ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Levas (JIRA)" <>
Subject [jira] [Created] (AMBARI-20859) Improve User Account Management Within Ambari
Date Wed, 26 Apr 2017 14:52:04 GMT
Robert Levas created AMBARI-20859:

             Summary: Improve User Account Management Within Ambari
                 Key: AMBARI-20859
             Project: Ambari
          Issue Type: Epic
          Components: ambari-server, ambari-web
    Affects Versions: 3.0.0
            Reporter: Robert Levas
            Assignee: Robert Levas
             Fix For: 3.0.0

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

* *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.

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

View raw message