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 permissions.

Depending on your configuration, folder settings can affect the 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 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 permissions and access to be configured:

There are four 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: The user can edit the secret data as well as deactivate secrets. This permission also allows users to move the secret to another folder unless the Inherit Permissions from Folder setting is turned on, in which case the user needs the Owner permission to move the secret.
  • 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 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.