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.