Secret Permissions

For information technology teams, securely sharing passwords is crucial. Due to the sensitive nature of sharing secure information, Secret Server ensures shared passwords are tracked and guarded via Delinea secret permissions.

Depending on your configuration, folder settings can affect the Delinea permissions of secrets contained in that folder (and its subfolders). Secrets and folders are not visible to users who do not have at least the View Secret (can see details) or the View Lists (can see a list of secrets) permissions. See Folder Permissions for more information.
To simplify sharing, new secrets automatically inherit the settings from the folder they are stored in. The Inherit Permissions checkbox (found in the Sharing tab of the secret's page) is enabled by default. Secrets inherit all the parent folders' sharing settings. As long as this checkbox is selected, you cannot modify the Delinea permissions for the secret. For more on folder security, see the Folders section.

Secrets can be shared with groups or individual users. The Sharing tab in a secret's page allows for Delinea secret permissions and access to be configured:

There are four secret permission levels when sharing secrets with another user or group:

  • List: The user may see a secret in a list, such as a list returned by running a search, but will not be able to view any more details about that secret or edit it.

  • View: The user can see all data of the secret, such as username, password, metadata, permissions, auditing, history, and security settings.
  • Edit: Users with Edit permission can modify secret data and deactivate secrets. They can also move secrets to another folder unless the Inherit Permissions from Folder setting is enabled. In such cases, Owner permission is required to move the secret. Note that sharing secrets is exclusively available to users with Owner permission.
  • Owner: The user may change all of the secret's metadata.
Password text-entry fields are not visible if a secret has a launcher and the Hide Launcher Password setting is on or the user does not have the View Launcher Password role permission.
The API calls use Delinea role permissions which are defined in the tbRolePermission table. In tbFolderACL, roles are not used, and it is less specific about the source, avoiding duplication.

Extended Permissions

In addition to the four secret permission levels, Secret Server supports extended permissions that grant fine-grained access to specific operations without changing the user's overall permission level.

Extended permissions are assigned per user or group on each secret, or on a folder with inheritance. They appear as checkboxes in the permission panel when sharing a secret or editing folder permissions.

Edit Dependencies

The Edit Dependencies extended permission grants the ability to create, update, delete, sort, enable, and disable secret dependencies and dependency groups. This allows administrators to delegate dependency management to users who do not need full Edit access to the secret itself.

Permission Level Edit Dependencies Available Behavior
Owner Not applicable (implicit) Owners have full access to all operations, including dependencies. The Edit Dependencies checkbox is not shown for Owner.
Edit Yes (selected by default) Users with Edit permission receive Edit Dependencies automatically. It can be deselected to restrict dependency access while preserving other Edit capabilities.
View Yes (deselected by default) Users with View permission can be granted Edit Dependencies to manage dependencies without being able to modify the secret's fields.
List No Users with List permission cannot receive extended permissions.
When upgrading to a version that includes extended permissions, all existing Edit permission entries automatically receive the Edit Dependencies permission, preserving current access levels. No administrator action is required.