Module 01 โ€” Foundation

Access Control
Models in Delinea

Master RBAC, ABAC, and Context-Aware Access Control โ€” then see each model implemented live inside Secret Server with hands-on interactive exercises.

Role-Based Access Control

RBAC grants permissions based on pre-defined job roles. Users are assigned to roles; roles carry permissions. This is the foundational model inside Delinea Secret Server.

RBAC
Core Concept

How RBAC Works

Access decisions are based solely on the role(s) a user is assigned. A role bundles a set of permissions โ€” such as View Secret, Edit Secret, or Own Secret. Permissions never attach directly to users.

In Delinea

Secret Server Roles

Secret Server ships with built-in roles (Administrator, User, Read Only) and allows administrators to create custom roles. Roles are assigned at the user level and drive access to secrets and administrative functions.

๐Ÿ’ก
Delinea Best Practice Always follow the principle of least privilege. Create roles that grant only the minimum permissions required for a job function, then assign users to the most restrictive applicable role.
INTERACTIVE โ€” Secret Server Role Permission Matrix

Click checkboxes to grant/revoke permissions for each role. Observe how the same secret behaves differently for different users.

Role
View
Edit
Copy PW
Delete
Own
Administrator
Power User
Standard User
Read Only
INTERACTIVE โ€” Assign Users to Roles in Secret Server

Select a user on the left, then select a role on the right to simulate assigning the role in Secret Server.

Users

AL
alice.martin
BJ
bob.johnson
CS
carol.smith
DK
dan.kim
โ†’

Roles

๐Ÿ” Administrator
โšก Power User
๐Ÿ‘ค Standard User
๐Ÿ‘ Read Only

Implementing RBAC in Secret Server

  1. Navigate to Admin โ†’ Roles
    In the Secret Server admin console, go to Admin > Configuration > Roles. This is your central hub for role management.
  2. Create or Select a Role
    Click Create Role and name it by job function (e.g., "Network Ops", "DB Admins"). Avoid broad names like "Power User" in production โ€” specificity reduces sprawl.
  3. Assign Permissions to the Role
    Check only the permissions required by that function. Secret-level permissions (View, Edit, Own) are separate from admin-level permissions (Create Users, Manage Roles).
  4. Assign Users to the Role
    Navigate to Admin > Users, select a user, then use the Roles tab to add the role. A user can hold multiple roles; effective permission is the union of all assigned roles.
  5. Apply Roles to Secret Folders
    In the Secrets folder tree, open a folder's Security tab and assign the role with specific folder-level permissions. This creates the folder-to-role-to-user chain that RBAC depends on.
Secret Server REST API โ€” Assign Role to User REST / JSON
# Assign a role to a user via Secret Server REST API
POST /api/v1/users/{userId}/roles

# Request body
{
  "roleIds": [3],          // Role ID 3 = "Network Ops"
  "userId": 42,          // User: alice.martin
  "operation": "add"
}

# Response 200 OK
{
  "success": true,
  "rolesAssigned": [
    { "roleId": 3, "roleName": "Network Ops" }
  ]
}
Attribute-Based Access Control

ABAC evaluates attributes of users, resources, and the environment at request time. Delinea implements ABAC primarily through Active Directory group membership driving dynamic policy assignment.

ABAC
Core Concept

Attributes Drive Decisions

Instead of a static role assignment, ABAC policies evaluate attributes at runtime. In Delinea, the most common user attribute is Active Directory group membership โ€” giving you dynamic, infrastructure-driven access control.

RBAC vs ABAC

When to Choose ABAC

Choose ABAC when access must respond to organizational changes automatically. If a user joins the "Network-Admins" AD group, they immediately receive the mapped Secret Server permissions โ€” no manual re-assignment needed.

๐Ÿ”—
AD Integration in Delinea Secret Server syncs with Active Directory via LDAP/S. When a user authenticates, their current AD group memberships are evaluated against configured policies โ€” creating a live bridge between your identity infrastructure and PAM access decisions.
INTERACTIVE โ€” AD Group โ†’ Secret Server Policy Flow

Simulate a user joining or leaving an AD group and watch Secret Server policy assignment update in real time.

AD Groups Matched
โ€”
โ†’
Policy Mapped
โ€”
โ†’
SS Role Assigned
โ€”
โ†’
Folder Access
โ€”
ABAC Policy Configuration โ€” Attribute Conditions

Below is an example policy that maps AD attributes to Secret Server access levels. Toggle conditions to see combined policy outcomes.

Subject Attribute
AD Group = Network-Admins
Sourced from LDAP memberOf attribute at login
Resource Attribute
Secret Tag = network-device
Custom field on secret metadata in SS
Outcome
Permission = View + Edit
Policy auto-assigns SS role on sync
Delinea โ€” AD Group Sync Policy Configuration (XML) XML Config
<!-- Active Directory Group Mapping Policy -->
<GroupSyncPolicy>
  <ADGroup>
    <Name>CN=Network-Admins,OU=Groups,DC=corp,DC=local</Name>
    <SyncEnabled>true</SyncEnabled>
    <MappedSSRole>Network Operations</MappedSSRole>
    <FolderPermissions>
      <Folder path="/Network Devices">
        <Permission>View, Edit</Permission>
      </Folder>
    </FolderPermissions>
    <SyncInterval>Every 30 min</SyncInterval>
  </ADGroup>

  <ADGroup>
    <Name>CN=DB-Admins,OU=Groups,DC=corp,DC=local</Name>
    <MappedSSRole>Database Administrators</MappedSSRole>
    <FolderPermissions>
      <Folder path="/Databases">
        <Permission>View, Edit, Copy Password</Permission>
      </Folder>
    </FolderPermissions>
  </ADGroup>
</GroupSyncPolicy>
  1. Configure AD Domain in Secret Server
    Go to Admin > Active Directory. Add your domain, provide sync credentials, and test the LDAP/S connection. Enable Auto-create users on login for seamless onboarding.
  2. Create Group Sync Mappings
    Under Admin > Active Directory > Group Sync, map each AD group to a Secret Server role or group. Delinea evaluates these at next sync or at user login.
  3. Set Sync Frequency
    Configure the sync interval (15โ€“60 min recommended). For immediate changes, use Synchronize Now. Event-driven sync via webhook is also supported in newer versions.
  4. Validate Attribute Mapping
    Use Admin > Diagnostics to run a test sync for a specific user and verify the LDAP attributes are correctly resolving to the expected policies.
Context-Aware Access Control

Context-Aware access evaluates environmental conditions at the moment of request โ€” time of day, IP geolocation, and device posture โ€” to dynamically allow, restrict, or challenge secret access.

Context-Aware
Condition Type

โฐ Time of Day

Restrict secret access to business hours only. Access during off-hours triggers MFA step-up or is denied outright โ€” protecting against overnight credential attacks.

Condition Type

๐ŸŒ IP / Location

Allowlist trusted IP ranges (corporate offices, VPN exit nodes). Requests from unexpected geolocations or IP blocks are challenged or denied, even for valid credentials.

Condition Type

๐Ÿ’ป Device Type

Require managed, domain-joined devices for high-privilege secrets. Unmanaged or BYOD devices can be limited to view-only or blocked entirely based on certificate posture.

โš ๏ธ
Policy Layering Context-Aware policies in Delinea are additive with RBAC and ABAC. A user must satisfy ALL active policy layers โ€” role permission AND attribute match AND contextual conditions โ€” before access is granted.
INTERACTIVE โ€” Contextual Access Decision Simulator

Adjust the environmental conditions below. The policy engine evaluates all conditions and renders an access decision in real time.

โฐ Hour of Day (24h)
09:00
Allow
๐ŸŒ IP Zone
Corporate VPN
Allow
๐Ÿ’ป Device Type
Managed Laptop
Allow
๐Ÿ”‘ Secret Sensitivity
Standard
No extra restrictions
โœ…
Access Decision
PERMITTED
All conditions satisfied
Configure Context-Aware Policy โ€” Delinea Secret Server

Time-Based Restriction

Enable time-based access restriction on this policy
ALLOWED WINDOW
Mon โ€“ Fri, 07:00 โ€“ 19:00
OUT-OF-HOURS ACTION
Require MFA Step-Up

IP Allowlist

Restrict to trusted IP ranges
10.0.0.0/8   โœ“ Corporate VPN
192.168.1.0/24   โœ“ HQ Office
172.16.0.0/12   โœ“ Datacenter

Device Certificate Enforcement

Require valid device certificate (managed endpoint only)
๐Ÿ’ก
Integration Tip Pair device certificate enforcement with your MDM platform (Intune, JAMF) to issue certificates automatically to compliant devices, creating a seamless managed-device experience.
Context Policy โ€” REST API Configuration JSON
// POST /api/v1/secret-policy โ€” Create Context-Aware Policy
{
  "policyName": "Privileged Secrets - Context Policy",
  "secretIds": [101, 102, 203],
  "conditions": {
    "timeOfDay": {
      "enabled": true,
      "allowedDays": ["Mon","Tue","Wed","Thu","Fri"],
      "allowedStart": "07:00",
      "allowedEnd": "19:00",
      "offHoursAction": "RequireMFA"
    },
    "ipRestriction": {
      "enabled": true,
      "allowedRanges": ["10.0.0.0/8", "192.168.1.0/24"],
      "denyAction": "Block"
    },
    "deviceType": {
      "enabled": true,
      "requireManagedDevice": true,
      "unmanaged": "ViewOnly",
      "byod": "Block"
    }
  }
}
Knowledge Check

Test your understanding of RBAC, ABAC, and Context-Aware Access Control as implemented in Delinea Secret Server. Select the best answer for each question.

8 Questions
Question 01 / 08
In Delinea Secret Server, a user with the "Read Only" role tries to copy a password from a secret. What happens?
Question 02 / 08
What is the primary mechanism Delinea uses to implement Attribute-Based Access Control (ABAC)?
Question 03 / 08
A user belongs to the "Network-Admins" AD group, which maps to Secret Server's "Network Operations" role. Their AD group membership is removed. What is the expected behavior after the next sync?
Question 04 / 08
Which access model is best suited for a scenario where access must automatically adjust when an employee transfers departments?
Question 05 / 08
In a Context-Aware policy, what action should Secret Server take when a valid user requests a privileged secret from an IP outside the allowed range?
Question 06 / 08
In RBAC within Secret Server, a user holds two roles: "Standard User" (View only) and "Network Operations" (View + Edit on /Network Devices). When they access a secret in /Network Devices, what is their effective permission?
Question 07 / 08
A "Critical / Break Glass" secret has a Context-Aware policy requiring a managed device AND business hours. A user on a managed device accesses it at 2:00 AM on Saturday. What is the correct policy outcome?
Question 08 / 08
Which statement best describes the relationship between RBAC, ABAC, and Context-Aware policies in Delinea?