Containers (Folders and Vaults)
Two forms of containers exist within the system, Folders and Vaults. Both options serve as containers that can hold child objects and inherit their configuration down to these child objects.
For a complete list of differences between these containers, please see our article PAM Containers: Folders vs Vaults.
Create a New Container
From within your desired parent container, click the Add Container button and select the container type to use from the dropdown menu list.
Enter both a Name (required) and Description (optional).
Neither the Name nor Description must be unique but for ease of use we recommend creating at least a unique description, if not both.
TIP: Vault containers can only be created in the All Records or Root Folder container. If you are currently within a vault or folder, then only the Add Folder option will be present to create a sub-folder. Vaults cannot be created inside containers.
Opening or Editing a Container
A container can be opened from the Record List page by either clicking on the container’s Name or selecting the Open option located in its dropdown menu.
A container can only be edited from the Record List page by selecting the Edit option located in its dropdown menu.
The Edit page will allow you to modify both the Name and Description of this container.
Sharing a Container
Containers can be shared with other users that have access to the system.
To share a container with another user(s) or group, click the Share button for this container on the Record List page or select the Permissions option located in the container’s top menu (Manage > Permissions).
Before you can share a folder, it is recommended to understand its current inheritance.
Containers can either have inherited permissions or unique permissions.
Vaults are always created with unique permissions, but they can be reset to inherit from their parent (i.e. All Records or Root Folder).
NOTE: Permissions are configured by default to inherit from the object’s parent container. When sharing a container, you will either need to share the parent container so that through inheritance this container is also shared (along with all other child objects) or you can break inheritance and create unique sharing permissions for an individual container. Both scenarios are equally supported, but you should consult with your object Owner or PAM System Administrator for guidance and recommendations.
Containers with inherited permissions (example shown below) means that the permissions associated to this object originate from its parent.
This means if you want to share a container with inherited permissions, then you must share its parent object.
Modifying permissions on a parent object will then affect all other objects that inherit permissions from it as well.
When viewing the permissions of an object with inherited permissions, the button Make Unique will be visible.
Clicking this Make Unique button will break the permission inheritance of this object to its parent and create a unique permission list that can be modified as needed.
Containers with unique permissions or broken inheritance (example shown below) means that the permissions associated to this object do not originate from a parent and are unique to only this object. This means if you want to share a container with unique permissions, then you can do so without affecting the permissions of its parent.
When viewing the permissions of an object with unique permissions, the button Inherit from Parent will be visible.
Clicking this Inherit from Parent button will remove all unique permissions and reestablish inheritance from this object’s parent.
-
Access the object’s permissions page by using the Share button or Manage > Permissions option.
-
Click the Grant Permissions button to open the dialog.
-
In the Principal field, enter the user(s) or group(s) that you wish to share with and then click the Add button. You may also use the Search button to locate your principal.
-
Configure the object permissions that you wish to grant to the selected principal(s).
-
Finally, click the Select button to complete the sharing or granting process.
-
Access the object’s permissions page by using the Manage > Permissions option.
-
Locate the Principal from the list that you want to edit their permissions and click the Edit button in the Actions column.
-
In the Grant Access dialog, confirm the principal is correct and then modify their permissions as required.
-
Finally, click the Select button to complete the edit process.
To Revoke existing permissions to the selected object:
-
Access the object’s permissions page by using the Manage > Permissions option.
-
Select the Principal that you wish to revoke permissions from the list by checking their box and click the Revoke Permission button.
-
Confirm your action to revoke the selected permissions in the confirmation dialog.
For ongoing maintenance and auditing, the Access Report button will generate a list of all users, unwound from any group membership, as well as their Permissions to this object. This report is helpful when determining how a user gained access to an object and with what level of permission.
Deleting a Container
A container can be deleted from the Record List page by selecting the Delete option located in its dropdown menu.
Please note that a container that contains child objects cannot be deleted. You must first delete all child objects before you can delete this parent container.
Managing a Container
The Manage menu options allow for advanced configuration of the container.
By default, the Permissions and Workflows configurations inherit from their parent so in order to make changes you will either need to update the parent or break inheritance to this container and make updates as required (Make Unique button).
Import |
Defines your import location. Your import will create objects in this originating container. |
Permissions |
Defines the users and groups that have access to this container. |
Workflows |
Defines all the workflow bindings that are associated to this container. |
Local Users |
Create and Manage local users that are specific to this container. |
Local Groups |
Create and Manage local groups that are specific to this container. |
Tokens |
Create and Manage API tokens that are generated specific to this container. |
Before making changes to the manage options of your container, please ensure you are in and working with the container you wish to update.
The name of the container you are managing will be displayed in the Record List breadcrumbs.
Container Scoped Objects
Containers (Vaults or Folders) can have objects created that are specific to this container only.
This allows for local users, groups and API tokens to be created and managed not only by System Administrators but also by the Container Owners as well.
These container scoped objects can only be used within the container that they are created and are useful for scenarios where the System Administrator wishes to delegate the management of users, groups and API tokens to the container owners themselves.
-
These objects can be created and managed by any users with the Record Control: Owner permission to any folder or vault, with the exception of Root Folder and any folders located in a user’s Personal Vault.
-
Container Scoped Principals (principals are Users or Groups) can only be used within the container in which they were created. For example:
-
A container scoped user created in Folder A cannot be used in Folder B, unless both folders exist as subfolders of the same first-level parent.
-
A container scoped group created in Folder A can include global principals or principals from this same folder or parent only. It cannot include container scoped users from another first-level container.
-
-
Container Scoped API Tokens can only be generated for Container Scoped Users available within this designated container, including any subfolders.
-
Container Scoped Principals cannot be granted the Global Roles System Administrator or Auditor.
-
Container Scoped Principals cannot be granted any Global Permissions.
-
Container Scoped Principals cannot be a member of any Global Local Groups.
For Container Owners, all subfolder container scoped principals and API tokens can be managed from the parent folder.
For System Administrators, all subfolder container scoped principals and API tokens can be managed from the parent folder or they can manage the same objects from the Administration area of the product for global reporting or management.
Container Scoped Local Users
Create and manage local user accounts that can only be used within this container itself.
These user accounts can be used to share objects or generate API tokens that are only valid in this container.
Creating a container scoped local user does not automatically grant them access to any objects.
Once created, permissions will still need to be granted to them as usual or they will need to be added to the appropriate container scoped groups as needed.
Container Scoped Local Groups
Create and manage local groups that can only be used within this container itself.
These groups can be used to share objects that are only valid to this container.
Container Scoped API Tokens
Create and manage API tokens that are assigned for use to container scoped users and can only be used within this container itself.