Details
-
Epic
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.7.0
-
Improve User Account Management Within Ambari
Description
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.
