Secret Management, Folders, and Permissions
Folder-centric authorization
Secret Server permissions are primarily folder-centric. Folders form a hierarchy; child folders and secrets inherit permissions unless inheritance is broken. Permissions are granted to users and, preferably, groups (including synced Active Directory groups). Common levels are View (open/use the secret), Edit (change its content/settings), Owner (change permissions), and List (see that it exists without opening it). Roles are different: a role grants system capabilities such as administering users or viewing audit, not automatic access to every secret. Least privilege means granting the minimum level on the narrowest folder or secret.
Lifecycle controls
A secret is created from a template, placed in a folder, and then managed through checkout, access requests, approvals, comments, and DoubleLock. Checkout gives one user exclusive use for a period and hides or locks the secret for others until check-in or forced check-in. Access Request is an approval workflow: a user requests access, an approver grants it for a limited duration. DoubleLock is a two-person control: a second authorized user must unlock the secret; it is not the same as approval. Require Comment forces a reason and improves audit quality.
Worked example
A contractor needs read-only access to one database secret in a folder containing 40 secrets. Do not grant View on the parent folder. Create or use a subfolder for that one secret (or set secret-level permissions if your version supports it), create an AD group for contractors, grant that group View only, enable Require Comment, and consider an access request with a 60-minute approval. Reasoning: folder-level View would expose all 40 secrets; a group simplifies onboarding/offboarding; View is sufficient for reading; comment and time-bound approval add accountability. Edit or Owner would exceed the requirement.
Traps
- Granting Owner to solve a visibility problem; Owner can change permissions.
- Breaking inheritance on a child folder and then wondering why parent changes do not apply.
- Confusing a system role with secret access.
- Treating checkout as an approval workflow; checkout is an exclusive lock.
- Assuming DoubleLock replaces View; the user still needs permission.
- Granting permissions to individuals when a group is required for scale.