Permission, Roles and Security

The system makes use of extensive permissions, roles and security to maintain control of your records and secrets.

Permissions or access can be granted via inheritance, on individual objects themselves or even globally for all assets.

Granting or sharing access may be done using Users or Groups, labelled throughout Privileged Access Management as principals.

Object Permissions

Objects (folders, vaults and records) permissions provide access to objects located in the system’s vault and a user’s personal vault.

When granting or sharing permissions to an object, the following roles are available:

Record Control

Record Control provides the selected principal(s) access to the object.

Viewer	The Viewer roles grants View Only access to the object. If you want a principal to see this object in their Record List or search results, they must have at least this role.
Unlock	Viewer plus the ability to Unlock (view) secured fields like Passwords, Secrets and Certificates.
Editor	Unlock plus the ability to Edit the object as well as its associated Formula and to view its Session History, Video Recordings and Session Events.
Manager	Editor plus the ability to Create or Delete objects (folders and records). Manager cannot create (share) or modify object permissions.
Owner	Full Control of the object. This includes creating new objects, modifying or deleting existing objects, sharing access (permissions), Audit Events, History and Session Termination.

Session Control

Session Control provides the selected principal(s) access to connect to Secure Remote Sessions using the record.

None	The principal may not establish a remote session using this record.
Connect (Optionally Recording without Session Events)	The principal may establish a remote session using this record and can choose whether their session is video recorded or not. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will not be recorded.
Connect (Always Recording without Session Events)	The principal may establish a remote session using this record and their session will always be video recorded. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will not be recorded.
Connect (Optionally Recording with Session Events)	The principal may establish a remote session using this record and can choose whether their session is video recorded or not. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will be recorded.
Connect (Always Recording with Session Events)	The principal may establish a remote session using this record and their session will always be video recorded. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will be recorded.
Connect (No Recording with Session Events)	The principal may establish a remote session using this record and their session will not be video recorded. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will be recorded.
Connect (No Recording without Session Events)	The principal may establish a remote session using this record and their session will not be video recorded. Session events (keystrokes including SQL traffic over tunnels, clipboard and file transfer) will not be recorded.

Task Control

Task Control provides the selected principal(s) access to Tasks associated to the record.

None	The principal may not execute, review or manage tasks or work with them in any manner.
Execute	The principal may execute tasks from the record’s Execute menu.
Review	The principal may execute or review task results in the Job History report.
Manage	The principal may execute or review task results as well as view the task list. To include the ability to Add/Remove tasks and edit Task Policies, the user should be assigned both Record Control: Owner and Task Control: Manage permissions.

Inheritance

Objects use inheritance from their parent container to simplify the management of objects that share or require a common configuration.

For example, all records in the same folder should have the same permissions or workflow bindings applied.

Newly created or pasted records will also inherit this configuration as well.

By default, all records created within the same container will inherit the Password and Workflow Bindings from the parent container.

Any changes that need to be made to these policies must be done on the parent container and will therefore also be applied to all other records that reside in this same container.

NOTE: While inheritance from parent container to child record is the default configuration, you can also break inheritance on a record and make the above configuration(s) unique. Once the settings are unique to a record, they can be updated as required without affecting the container configuration or any other records that continue to inherit from this parent. Additionally, you can also choose to Inherit from Parent within the record’s configuration page(s) if you wish to return it back to its inherited state with its parent container.

Global Permissions

Global Permissions enables a method to quickly and easily grant users and groups non-Administrative permissions to all objects (folders, vaults and records) stored in the system vault.

For example, you may now provide a user with Viewer permissions to all objects, regardless of their current inheritance setting and without having to navigate to each object, by simply granting Global Permission to this principal account.

A few details to note when considering the use of Global Permissions:

Global Permissions do not override object permissions, meaning if a user is an Owner of an object, Global Permissions cannot be used to reduce their existing permission level.
Global Permissions are not displayed when viewing the permissions for a specific object; however, they will be displayed when viewing the object’s Access Report.
Global Permissions can be assigned to both local System users and external users like Active Directory Users or Groups.
Global Permissions can only be assigned and managed by System Administrators.

To grant a principal Global Permissions, navigate to Administration > Global Permissions and click the Grant Permission button. Enter your principal(s), click the Add button, select the level of permissions to grant and finally click the Select button to complete the process.

To edit existing Global Permissions, simply click the Edit button for the required principal, make the necessary adjustments and click the Select button to finalize the update.

To remove existing Global Permissions, check the box next to each principal(s) to select them and then click the Revoke Permission button. On the Global Permission page, use the Access Report button to generate a list of all user principals that have access to any object throughout the entire system.

Global Roles

Global Roles provide system wide access using various level of roles, as described below.

Auditor

The Auditor role grants a limited View Only role to all containers and records in the system. It grants access to the Audit Log (record and system), Session History (record and system), Job History (record and system) as well as Administration Reports and read only configuration.

Auditors cannot modify the system or records nor can they unlock, execute or connect to any privileged systems or secrets.

System Administrator

The System Administrator role (the highest level available) grants full access to all vaults, folders, records, logs, security, script library, workflows, configuration and reports system wide.

It can be used to grant and revoke other principals to this System Administrator role and therefore it should only be given to trusted users.

Split View

The Split View role grants access to only the first or last part of a split password when the Split View Role is enabled.

The Split View Role is configured in the Parameters section of the Administration page.

Read more about the Split View feature in our article.

Service

The Service account is used for a distributed job engine deployment so an Administrator can designate certain records to be executed by specific job engine nodes. Read more about Distributed Job Engine Deployments for additional information about this role.

Blocked

The Blocked role is used to block the user or group members’ access to objects in PAM. The blocked user can still login to PAM, but until they are unblocked, they will have no access to any objects or settings. Remove the Blocked role from the principal to restore their access.

Automation

The Automation account is used to throttle the rate of new connections for scripts to control overall system performance. For additional configuration, read the description and adjust the global parameter Throttle SSH Proxy Automation Connections as needed.

Local Users and Groups

Local users and groups can be created in Access Manager’s internal user directory providing a method to quickly create, disable or automatically expire accounts for internal or external resources.

These accounts are independent of any external user directories that you may also integrate with Access Manager (i.e. Active Directory or LDAP).

Only System Administrators may create and manage local users and groups on this global level.

Create a Local User

To create a new local user, navigate to Administration > Local Users and click the Create button. Populate the new user form as required.

Login	Enter a unique value that will be used to login to the system.
First Name	Enter a first name for this account.
Last Name	Enter a last name for this account.
Mail	Enter an email address for this account.
Expiration	Enter a date and time when this account will be automatically disabled / locked. Leave blank if you do not want to automatically disable / lock this account.
Password	Enter the password for this account. The password must meet the requirements of the Local User Formula.
Repeat Password	Repeat the password for this account.

Click the Save button to complete the account creation process.

NOTE: Local Users can be added to Local Group membership only. Local Users cannot be added to any groups that originate from integrated external user directories like Active Directory.

Local User Password Formula

The local user password formula allows you to customize the complexity required for setting and resetting local user passwords.

This formula is used for local user passwords only and is separate from all other formulas in the system.

To configure this formula, navigate to Administration > Local Users and click the Formula button.

Customize this formula as required and click the Save button when complete.

Managing Local Users

Editing a local user account allows a System Administrator to update the First Name, Last Name, Email, Expiration and Password of any local user account. Click the Edit button associated to the Login to edit an account.

Locking a local user prevents this account from logging into the system while Unlocking an account restores the ability to login to the system.

To Lock or Unlock an account, check the box next to the Login(s) and select Bulk Actions > Lock or Unlock option.

A locked account will display a lock icon () in the Locked column.

Deleting a local user removes the account from the system.

Deleted accounts cannot be restored, so we would recommend using the Lock option instead of Delete if there is a possibility that the account will be needed again in the future.

To delete a local user, click their Edit button and then the Delete button on their account’s edit page.

Create a Local Group

Local Groups are created and managed within Access Manager’s internal user directory and are used to provide group membership capabilities to both Local Users as well as external accounts like Active Directory Users.

To create a new local group, navigate to Administration > Local Groups and click the Create button. Populate the new group form as required.

Name	Enter a unique group name.
Description	Enter a group name description.

Once the group has been created, use the Add Member or Remove Members buttons to populate the group membership. Alternatively, you can use the Edit button to update membership or configuration of existing local groups.

NOTE: Local Group membership may include both local users and users that originate from your Privileged Access Management integrated Active Directory.

Use the Delete Group button to delete the group and use the Save Group button to save any changes that have been made to the group.