User Management

As PMP serves as a repository for the sensitive passwords, fine-grained access restrictions are critical for the secure usage of the product. PMP provides role-based access control to achieve this.

In practical applications, information stored in PMP will have to be shared among multiple users. By default, PMP comes with four pre-defined roles -

• Administrators set up, configure and manage the PMP application and can perform all the resource and password related operations. However, they can view only those resources and passwords that were created by them and the ones shared to them by other users.
   

• Password Administrators can perform all resource and password related operations. However, they can view only those resources and passwords that were created by them and the ones shared to them by other users

• An administrator/Password Administrator can be made as a 'Super Administrator' by other administrators (and not by himself). Super Administrator will have the privilege to manage all the resources added in the system by all. (To know how to make an administrator or a password administrator as super administrator, click here)
   

• Password Users can only view passwords that are shared to them by the Administrators or Password Administrators. They can modify passwords if the sharing permission allows them to do so
   

• Password Auditors have the same privileges as Password Users and in addition they have access to audit records and reports

You can create as many users as you desire and define appropriate roles for the user. This section explains how to create users and assign roles for them.

Adding New Users

From the Users tab, administrators can

• View all the existing PMP users

• Create new users

• Edit the access role of the user

• Enable two-factor authentication

• When RSA SecurID is used as the second authentication factor, you need to ensure that the user name in RSA Authentication Manager and the corresponding one in PMP are same. In case, for the already existing RSA users, if the user name in PMP and in RSA Authentication Manager are different, you can do a mapping of names in PMP instead of editing the name in RSA. This can be done from here through "RSA SecurID UserName". (Assume the scenario that in PMP you have imported a user from Active Directory, who has the username (say) ADVENTNET\rob in PMP. In RSA Authentication Manager, assume that the username is recorded as 'rob'. In normal case, there will be mismatch of usernames between PMP and RSA Authentication Manager. To avoid that, you can do a mapping in PMP - ADVENTNET\rob will be mapped to rob).

New users can be added in four ways

• Adding users manually

• Importing users from Active Directory

• Importing users from LDAP

• Importing users list from a CSV file

By default, PMP stores all user data in the MySQL database and performs authentication using database lookups. When you integrate AD/LDAP as the authentication system, the default authentication of PMP would be replaced by AD or LDAP to authenticate a user's identity. At any point of time, only one mode of authentication could be employed in PMP.

Denying Super-Administrator Creation by Administrators

Super-Administrators in PMP get the privilege to view all the passwords stored in the system. Organizations generally wish to keep the super-administrator role as a break-glass account for emergency access to passwords. At present, any administrator can change the role of another administrator (not himself) as super-administrator.

PMP now provides the option to deny administrators from creating super-administrators. This can be done by any super-administrator from Admin >> Super Administrator >> Deny Administrators from Creating Super Administrators.

The Best Practice Approach

If your organization requires super-administrator only as a break-glass account, the following would be the best practice approach:

• Create a new administrator account in PMP

• Designate the new account as the Super-Administrator

• The new super-administrator will login and enforce the above option of denying other administrators from creating super-administrators

• The login credentials of this super-administrator will be sealed and kept in a safe to be opened only for emergency access

The Implications

• Once you enforce this option, no more super-administrators could be created by administrators

• The existing super-administrators (other than the break-glass account), if any, will not get affected. They will continue to have super-admin access as usual

• The existing super-administrators and the break-glass super-admin accounts will have the privilege to create new super-admins

© 2009, ZOHO Corp. All Rights Reserved.