Folder Permissions
in Secret Server
Delinea Secret Server uses a layered permissions model to control who can see, use, and manage secrets. Understanding how groups, roles, and explicit folder permissions interact is essential for secure and efficient PAM administration.
Secret Server permissions work in three tiers: Roles define what actions users can take system-wide. Groups organize users for easier management. Folder permissions control access to specific folders and the secrets within them.
Folders are the primary organisational containers in Secret Server. They store secrets and inherit a tree structure. Permissions applied to a folder can propagate down to all child folders and secrets — unless explicitly overridden.
By completing this training you will be able to:
Managing Groups
Groups are collections of users that simplify permission management. Instead of assigning permissions to individual users on every folder, you assign them once to a group — and all members inherit those rights.
Secret Server supports two group sources:
-
1
Navigate to Administration
From the top menu, go to Admin → Groups. You'll see the Groups management page with all existing groups listed.
-
2
Create New Group
Click + Create Group. Enter a meaningful name (e.g.,
SEC-Ops-Team) and an optional description. Keep naming consistent across your environment. -
3
Add Members
On the Group detail page, select Members → Add Members. Search by username and add the appropriate users. You can add both local and directory users.
-
4
Assign a Role (Optional)
Navigate to the Roles tab on the group. Assign a system role to give all group members a baseline set of permissions. See the Roles module for details.
-
5
Save the Group
Click Save. The group is now available to be assigned to folder permissions throughout your Secret Server instance.
Roles & System Permissions
Roles control what users can do in Secret Server at the system level — independent of folder-level access. A user may have a role that allows them to create folders, but they still need explicit folder permissions to access secrets inside one.
| Role | Create Folders | Manage Users | View Audit Logs | Access All Secrets |
|---|---|---|---|---|
| System Administrator | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Administrator | ✓ Yes | Limited | View Only | ✗ No |
| Auditor | ✗ No | ✗ No | ✓ Yes | ✗ No |
| User | Config. | ✗ No | ✗ No | ✗ No |
| Read Only | ✗ No | ✗ No | ✗ No | ✗ No |
Custom roles allow fine-grained control. Navigate to Admin → Roles → Create Role.
-
1
Name the Role
Provide a clear, descriptive name. Use a naming convention such as
ROLE_DEPT_Functionto maintain consistency. -
2
Select Role Permissions
Tick the system-level permissions required. Common ones include: View Users, Add Secret, Delete Secret, Administer Folders, View Audit Log, View Remote Password Changing.
-
3
Assign to Groups or Users
Roles can be assigned to individual users or to groups. Assigning via groups is the recommended approach — it scales better and is easier to audit.
Folder Permission Levels
Folder permissions determine exactly what a user or group can do within a specific folder and its contents. Secret Server provides four distinct permission levels for folders.
Users can see the folder and its secrets in the tree, and view secret metadata (name, template, last modified). They cannot view the actual secret values unless the secret template also grants access.
Includes all View permissions, plus the ability to add, modify, and move secrets within the folder. Users can edit secret values and create new secrets. They cannot delete secrets or change folder permissions.
Full control. Includes View + Edit, plus the ability to delete secrets, modify folder permissions, add sub-folders, and rename or delete the folder itself. Assign this level sparingly.
Overrides any inherited permissions. If a user's group has View access but they are explicitly denied, they will see nothing. Use this to exclude specific users from inherited group access.
-
1
Open Folder Settings
In the Secret Server tree, right-click the folder and select Edit Folder, or click the ⚙️ icon next to the folder name. Navigate to the Folder Permissions tab.
-
2
Add a User or Group
Click + Add. In the search box, type the name of a user, group, or role. Select the appropriate entry from the dropdown results.
-
3
Set the Permission Level
From the permission dropdown, choose View, Edit, or Owner. Consider using groups rather than individual users for maintainability.
-
4
Configure Inheritance
Decide whether to Inherit Permissions from the parent folder (default) or break inheritance and set explicit permissions. This is covered in detail in the Inheritance module.
-
5
Apply to Sub-folders and Secrets
If desired, tick Apply to Sub-Folders and Apply to Secrets to propagate the permission change down the hierarchy. This is a one-time push — future changes won't auto-propagate unless inheritance is enabled.
Permission Inheritance
Inheritance allows child folders and secrets to automatically receive the permissions of their parent. This reduces administrative overhead but requires careful planning to avoid unintended access.
By default, every new sub-folder and secret inherits its parent folder's permissions. The permission chain flows from the root folder downward:
When a folder or secret requires different permissions from its parent, you break inheritance and set explicit permissions. This creates an isolated permission boundary.
-
1
Open Folder Permissions
Navigate to the folder, open Edit Folder → Folder Permissions.
-
2
Disable Inheritance
Uncheck "Inherit permissions from parent folder". A warning will appear — confirm you want to break inheritance. The folder will now show only explicitly assigned permissions.
-
3
Add Explicit Permissions
After breaking inheritance, immediately add the required permissions. Failing to add at least one Owner may lock everyone out of the folder.
-
4
Review Sub-folders
Sub-folders that previously inherited from this folder will now inherit your new explicit permissions. If they need different permissions, repeat the process for each sub-folder.
Explicit Permissions
Explicit permissions let you assign specific access rights directly to a folder, group, user, or secret — overriding what would otherwise be inherited from the parent. They are the most granular layer of the permissions model.
• A team needs access to one sub-folder but not its siblings
• A contractor needs temporary View access to specific secrets
• A break-glass folder needs tighter access than its parent
• An individual needs elevated access beyond their group's level
• As a substitute for proper group management
• When inheritance achieves the same outcome
• On every individual secret (creates audit/management burden)
• Without documentation of why the exception exists
| Attribute | Inherited Permission | Explicit Permission |
|---|---|---|
| Source | Parent folder | Directly assigned |
| Persistence | Updates when parent changes | Static — does not change with parent |
| Priority | Lower | Higher (overrides inherited) |
| Maintenance | Automatic | Manual — must be reviewed regularly |
| Audit Visibility | Shown as "Inherited" | Shown as "Explicit" — easier to spot |
Secrets have their own permission settings separate from the folder. To set permissions directly on a secret:
-
1
Open the Secret
Navigate to the secret and click into it. Then go to Security → Permissions tab.
-
2
Break Inheritance (if needed)
The secret shows permissions inherited from its folder. Uncheck "Inherit permissions from folder" to enable explicit secret-level permissions.
-
3
Add or Remove Principals
Add users, groups, or roles with specific permission levels (View / Edit / Owner). The secret-level permissions now take full effect.
-
4
Document the Exception
In the secret's Notes field or via your ITSM, record why the explicit permission was set, who approved it, and when it should be reviewed.
Interactive Permission Lab
Explore how permissions interact by clicking a folder in the tree and assigning permissions. See how inheritance and explicit settings affect the effective access.
Best Practices
Following these proven practices will keep your Secret Server environment secure, auditable, and easy to manage as your organisation grows.
-
Design your folder hierarchy before assigning permissions Plan a folder structure that mirrors your organisational or functional boundaries. Permissions flow downward, so a well-designed tree reduces the number of explicit overrides needed. Common structures: by department, by technology, by environment (Prod/Dev/Test).
-
Always assign permissions to groups, never individuals User-based permissions become unmanageable at scale. When someone leaves or changes roles, group membership changes automatically propagate. Reserve user-level assignments for temporary exceptions, and document them.
-
Apply least-privilege: start with View, escalate as needed Grant View access by default. Only elevate to Edit or Owner when there is a clear business requirement. Periodically review Owner-level assignments — these should be kept to a minimum.
-
Break inheritance sparingly and document every exception Each inheritance break creates a separate permission island that must be maintained independently. Every break-glass folder or exception should have a ticket reference and a review date in its notes or description.
-
Run access reviews quarterly Use Admin → Reports → Folder/Secret Permissions and Admin → Reports → User Access to generate permission reports. Validate active users still require their access level. Remove stale permissions promptly.
-
Sync Active Directory groups regularly If using AD groups, ensure sync intervals are appropriate (15 minutes is typically fine; reduce for highly sensitive folders). Monitor sync health under Admin → Directory Services.
-
Protect break-glass folders with dual approvals and alerting Any folder containing emergency credentials should require approval workflows and send real-time alerts on access. Configure this under the folder's Security → Requires Approval and the Event Subscription engine.
-
Maintain a permissions runbook Document your group naming conventions, folder structure rationale, role assignments, and explicit permission exceptions in a runbook stored outside Secret Server. This is essential for onboarding new admins and for disaster recovery.
Knowledge Check
Test your understanding of Secret Server folder permissions. Answer all questions to complete your training.