Delegated Administration

Overview of role-based Administrative Permissions

Delegated Admin via Administrative Permissions

A Keeper role can be granted Administrative permissions over the node (or sub-nodes) for which a role exists. This delegated administration allows different roles to have different permissions inside of the Admin Console.

An example of a role that can be created would be a Delegated Admin role. In this role the administrator can set up one or more Administrative Permissions that allow that user in the role to login to the Keeper Admin Console and perform administrative functions. For example, the delegated admin can be given permission to create teams, add users, create or edit roles, run reports, approve devices and perform account transfers. These permissions can be limited to a single node or they can cascade or traverse down the tree structure to all the sub-nodes.

Adding Administrative Permission

To create a privileged role with admin permissions, click on the + Add Managing Node button in the Administrative Permissions sections.

Each node a role manages has its own set of permissions and those permissions can cascade down from that node for example, if the role was created in the top root level node and there were three other nodes created under the top, root level node. The Administrative Permission can be added as the top node, the privileges added, and Cascade Node Permissions selected. This would then give those permissions to all four nodes and members of that role.

  1. To give Administrative Permissions to a Role, select the + Add Managing Node button on the Role screen.

  2. Select a Node and click OK.

  3. Set permissions by clicking on the gear icon next to the node you added.

When Cascade Node Permissions is selected, the permissions will be applied to all sub-nodes of the parent node. It is important to note that Administrative Permissions cannot be added to a Role if one or more of its users still have an "invited" status.

A description of each permission is below.


Manage Nodes

The ability to add, remove, or edit nodes.

Manage Users

The ability to add, remove, or edit users.

Manage Roles

The ability to add, remove, or edit roles.

Manage Licenses

MSP-specific ability to manage licensing (only appears for MSP customers)

Manage Teams

The ability to add, remove, or add members to Teams.

Manage Bridge/SSO

The ability to add, remove, or configure the Enterprise Bridge or SSO.

Run Security Reports

The ability to run and configure reports (Advanced Reporting & Alerts Module)

Perform Device Approvals

For SSO cloud users, the ability to approve devices

Transfer Account

The ability to transfer a user's vault (if the user's Role is configured to allow this. See Account Transfer policy.

Cascade Node Permissions

If selected, the permissions apply to this node and all sub-nodes.

Manage record Types in Vault

This permission allows the admin rights to create, edit, or delete Record Types which have pre-defined fields. Record Types appear during creation of records in the user's vault. Learn more about record types.

Share Admin

Provides elevated access rights over the organization's shared folders and shared records. Learn more about Share Admin.

Run Compliance Reports

Provides on-demand visibility of the access permissions associated with your enterprise records. Learn more about compliance reports.

Only administrators who are a currently a member of this role are able to select "Transfer Account". If needed, you can add yourself to the role or another administrator within the role can set this permission.

Administrative Permission vs. Role Enforcements

Both Administrative permissions and enforcements are configurable from within a role. Enforcements are rules or policies that apply to the end user's vault experience and security. Administrative Permissions grant rights to perform certain actions within the admin console (also known as delegated administration).

We recommend that only specific roles are given Administrative Permission, and the permission level should be based on the least amount of privilege required by that role.

For example, the default Keeper Administrator may have created a role called "All Users" specifically to handle the policies that are desired for all the users that have been onboarded to the Keeper platform. If you intend for one of those users to be able to perform some of the administrative permissions, create a new role called "Delegated Admin", grant the administrative permissions, and make the user a member of that role.

Last updated