Overview:
In large enterprises, authentication and authorization to various IT systems are centrally controlled for security and auditing purposes. Directory software such as LDAP or Active Directory is often deployed.
Prior to the release of IOP 4.2.5, Ambari supports 2 types of users for accessing Ambari via UI and REST APIs:
- LOCAL – userids (and groups) that are defined within Ambari server only and are independent of local OS users
- LDAP – userids (and groups) that were imported synched from an LDAP server
Using locally defined Ambari users for accessing Ambari works fine for development and test clusters, but cannot be considered as a secure option for production clusters. Ambari also supports LDAP integration in prior releases. However, its current support is rather restricted where LDAP users are imported and synchronized into Ambari after configuring Ambari-server to use LDAP. The LDAP synching is done manually which introduces a latency between when the user is added or modified in the LDAP server and when these changes are reflected in Ambari. This also create a security issue in which users who were removed from group(s) in the LDAP server but still have access to Ambari server until synching is done.
In IOP 4.2.5, PAM (Pluggable Authentication Module) authentication support is added in Ambari to help simplify and enable enterprise class authentication. Ambari’s PAM support also addresses the manually synching problem by performing dynamic synching of user name and group membership upon successful login. This enables changes in group membership to be dynamically reflected as soon as the users logged in.
Setting PAM in Ambari:
In order to setup Ambari PAM support, a couple of artifacts are required:
- PAM configuration file for your machine – this file contains the authentication requirement for the machine.
- Optionally, the admin can provide a set of user groups that Ambari will pre-grant roles so that users belonging to these groups will automatically get the proper privileges in Ambari as soon as s/he logs in. Otherwise, the admin can only grant roles to these groups after they were implicitly added into Ambari – this only happens when a user belong to that group logs into Ambari:
- Cluster Admin Group – users in this group will have Cluster Admin role
- Cluster Operator Group – users in this group will have Cluster Operator role
- Service Admin Group – users in this group will have Service Admin role
- Service Operator Group – users in this group will have Service Operator role
- Cluster User Group – users in this group will have Cluster User role
Below is an example of Ambari Server PAM setup:
Once the setup is done, Ambari will add these properties into the /etc/ambari-server/conf/ambari.properties file:
pam.configuration
pam.group.cluster.admin
pam.group.cluster.operator
pam.group.cluster.user
pam.group.service.admin
pam.group.service.operator
Also, client.security will be set to pam (client.security=pam).
Note: In IOP4.2.5, PAM setup is allowed even if Ambari is already configured with LDAP authentication. However, Ambari will not allow switching to LDAP when PAM is already configured.
Restart ambari server for the pam setup configurations to be updated in the ambari server.
ambari-server restart
Upon restart, the custom groups will be created as PAM groups in Ambari with the corresponding roles granted. Below is an example on roles assigned to those groups:
Ambari PAM User Management:
Once Ambari is setup with PAM authentication, users logging in will be authenticated using PAM. Once the authentication is successful, Ambari will request information about the group membership of the logged in userid. Ambari will then check if the userid and its membership groups exist, and will add them to the Ambari metastore if not. Ambari will also synch up groups membership of the userid in Ambari metastore to reflect what PAM has returned; this help ensures that user whose groups membership modification is reflected immediately after logging-in.
Ambari PAM Group Management:
PAM groups are implicitly created when users log in if the users’ group does not exist yet in Ambari metastore. Similar to LDAP groups, PAM groups cannot be created or deleted explicitly in Ambari for security reason. Once the PAM groups are implicitly created and visible in Ambari, Ambari admin can grant roles to those groups or users. However, PAM groups can be automatically created and roles can be assigned at Ambari PAM setup to help simplify the admin process. The following are the rules that Ambari follows during automatic PAM groups setup:
- Non-existing PAM groups will be created and roles assigned
- If a specified PAM group already exists in Ambari, the role will be assigned to the group if and only if that group doesn’t already have an existing role.
- If the specified PAM group already exists and has an existing role associated that is different than the role assigned in setup-pam, then that group’s role remains unchanged and an error is logged in the ambari-server log
- If the specified PAM group already exists and is a non-PAM group, Ambari will not grant role to non-PAM group and will log an error in the ambari-server log, i.e.
Migration of Ambari users from LDAP to PAM:
If PAM is setup on a cluster that has been using LDAP for Ambari authentication, the LDAP users and groups in Ambari can be migrated to PAM mode in order to help preserve roles assignment. Migration from LDAP to PAM is useful when reconfiguring Ambari to access the same LDAP server using PAM that Ambari was configured to access using LDAP previously. To perform the migration, execute:
ambari-server migrate-ldap-pam
Using python /usr/bin/python
Migration LDAP to PAM
Ambari Server configured for Embedded Postgres. Confirm you have made a backup of the Ambari Server database [y/n] (y)? y
Migrating LDAP Users & Groups to PAM
Ambari Server ‘migrate-ldap-pam’ completed successfully.
Restart Ambari server
Ambari-server restart
Go the Ambari UI, Manage Ambari-> Users, where the LDAP users and groups are now shown as PAM users and groups.
Note:
- Always make a backup of the ambari-server database before doing migrate-ldap-pam
- Ambari server needs to be restarted after migration in order to clear obsolete cached user information.
Common Problems:
- The groups and their roles configured during PAM setup is stored in the ambari.properties file. This configuration will be validated at each ambari-server startup. If the roles assigned for those groups are changed by admin to different roles the roles specified in the properties file, Ambari will log errors in the ambari-server log. The error can be ignored if the groups’ roles have been reassigned by design. To get rid of the errors, a work-around is to run setup-pam again and assign the desire roles for those groups.
- Even with PAM configured, Ambari server still has support for local user authentication. Ambari will give local authentication precedence over PAM authentication. The implication of this is that a PAM user will not be able to log in if there exists a local user with the same userid. To enable the PAM user to log in, delete the conflicting local userid from Ambari.
- Ambari does not allow duplicate userids even with different user types (Local/LDAP/PAM). In PAM mode, when a user logs in and there exists a same userid in Ambari with non-PAM user type such as LDAP, Ambari may return the error “Invalid UserName/Password combination”. More detailed information about the error can be found in the /var/log/ambari-server/ambari-server.log file.
E.g.
- Executing migrate-ldap-pam command, might throw some warnings in the console not related to migration as in the screenshot. These warnings can be ignored since they are not related to the ldap to pam migration.
Note: Some of the PAM features described in this article are also available in Apache Ambari 2.5. The migration of Ambari Users from LDAP to PAM and granting roles to groups during PAM setup are not included in Apache Ambari 2.5. Currently work is ongoing with the community to include the missing features.