Delinea Secret Server cheat sheet

Secret Server stores each credential as a Secret record whose encrypted fields are protected by a per-secret Data Encryption Key (DEK); the DEK is itself encrypted by the server's master key material.

A Secret Template defines the fields, launcher, and password-requirement rules for a class of secrets; every secret is created from exactly one template and inherits its field structure.

Secret Templates are composed of fields; field types include text, password, URL, file attachment, and password-change-aware types that drive Remote Password Changing.

The Secret Server application key (encryption.config) is generated at install and is required to decrypt the database; without it a database backup cannot be restored to readable secrets.

Distributed Engine and Secret Server nodes share the same database; the application key must be identical across nodes for secrets to decrypt consistently.

Secret Policy enforces settings such as password complexity, rotation interval, and heartbeat behavior across folders or the whole site; the most specific applied policy wins.

Secret access requires both an ACL grant (View, Edit, Owner, List) and, where enabled, a check-out or approval workflow before the secret value is revealed.

A Secret Template's "Password Type" field designates which field holds the password; Remote Password Changing and heartbeat operate on that designated field only.

DoubleLock (when enabled) adds a second encryption layer requiring an additional password to reveal a secret, independent of the user's login credentials.

Folders form a hierarchy; permissions inherit downward from parent folders unless inheritance is broken at a child folder, which then uses its own explicit ACL.

Folder permissions include View, Edit, Add Secret, Owner, and List (see folder without seeing contents); List without View hides secret names and values.

Role-Based Access Control (RBAC) assigns users to roles; roles carry permissions such as Administer Secret Server, Administer Users, and Report access, separate from per-folder ACLs.

A user's effective access to a secret is the intersection of role permissions and folder ACL grants; neither alone is sufficient.

Secret check-out locks a secret to one user for a configured period; other users see it as checked out and cannot reveal the value until it is checked in or the checkout expires.

Require Approval workflows route access requests to approvers; the requester gains temporary access only after approval, and access expires per the configured duration.

Secret access requests can be configured per folder or per secret, with approvers, maximum duration, and whether the requester may access immediately on approval.

Moving a secret to a different folder changes which ACL and inherited policy apply; verify target folder permissions before moving production secrets.

Group membership (Active Directory or local groups) is the recommended way to grant folder access so onboarding and offboarding scale without per-user edits.

Session Recording (launching via RDP/SSH through Secret Server) captures keystrokes and screen video for privileged sessions; recording is enabled per secret or template via the launcher.

Secret Server supports RDP, SSH, and PuTTY launchers; the launcher determines whether the session is proxied (recorded) or direct (not recorded).

Recorded sessions are stored and searchable in the Session Recording area; playback shows screen and keystroke timeline for audit.

Session recording requires a compatible launcher and, for RDP, the Secret Server session recorder component; sessions launched outside Secret Server are not captured.

Privileged Access Service / Privileged Access Management (PAM) features can broker access, enforce check-out, and inject credentials so the user never sees the password.

Password changing (Remote Password Changing) rotates the credential on the target system via a dependency; heartbeat verifies the stored password still works.

Dependencies define how Secret Server changes a password on a target (e.g., Windows local account, AD, SQL login) and run during RPC or heartbeat.

Session recording retention and access are governed by role permissions; auditors may be granted view-only access to recordings without secret-view rights.

The Audit log records events such as secret views, edits, check-outs, permission changes, and logins; each entry includes user, timestamp, action, and target.

Reports include Secret Audit, User Audit, Active Sessions, and Password Change status; report visibility is controlled by role permissions.

System Log and Application Log capture server-side events (errors, engine connectivity, RPC failures) for troubleshooting, distinct from the user-facing Audit log.

Remote Password Changing requires a Distributed Engine or the Secret Server node to reach the target; engine health and connectivity are visible in the engine configuration page.

Backup and disaster recovery: the database backup plus the application key (encryption.config) are both required; losing the key makes backups unrecoverable.

User management includes local users and AD/LDAP synchronization; synchronized users authenticate against the directory, and group sync drives role and folder membership.

Configuration items such as Secret Policies, Secret Templates, and Roles are administered centrally; changes are logged and should be exported for change control.

Sessions and login activity are reportable; Active Sessions report shows current check-outs and proxied sessions for operational oversight.

Encryption at rest uses AES; the master key protects DEKs, DEKs protect secret fields, and the application key protects the master key material stored in the database.

Secret Server can integrate with a Hardware Security Module (HSM) or external key store so the master key is not stored solely in the database.

Secret fields marked as password are masked in the UI and API by default; reveal requires View permission and, if configured, check-out or approval.

The API exposes secrets via REST endpoints; API access is governed by application accounts and their role permissions, and secret values are returned only with sufficient rights.

Secret versioning retains prior values; viewing history requires permission and each historical view is audited.

Secret Templates can require a "Generate" password policy so new secrets use the configured complexity and length rather than user-chosen values.

Heartbeat runs on a schedule per policy and marks secrets as failed when the stored credential no longer authenticates, flagging them for rotation.

Secret Server does not store secrets in plaintext in the database; all sensitive fields are encrypted with the secret's DEK before persistence.

Folder inheritance: a child folder inherits the parent ACL unless inheritance is explicitly broken; breaking inheritance replaces inherited grants with the child's own.

"List" permission lets a user see that a folder and its secret names exist without revealing values; "View" is required to see the secret value.

"Owner" on a folder grants administrative control of that folder's ACL and contents, distinct from site-wide admin roles.

Secret-level permissions can override folder inheritance for individual secrets when configured, allowing exceptions without restructuring folders.

Check-out requires the secret to be configured for check-out; the checkout duration and whether it auto-checks-in on session end are policy settings.

Approval workflows can require one or more approvers; the requester cannot access the secret until all required approvals are granted.

Role permissions are additive across roles a user holds; folder ACLs are evaluated against the user and their group memberships.

Deleting a user does not delete their audit history; audit entries persist and reference the former user for accountability.

Session recording captures both screen video and keystroke logs; the two can be reviewed together during playback for forensic reconstruction.

RDP proxied sessions route through Secret Server; if the recorder is unavailable, the session may fail or fall back to direct depending on configuration.

SSH sessions can be recorded via the Secret Server SSH proxy; the target's credentials are injected so the user does not type the password.

Session recording access is a separate permission from secret access; auditors can review recordings without the ability to reveal live secrets.

Active Sessions reporting shows who is currently connected, the target, and start time, enabling real-time oversight and forced termination where supported.

Password change on a target requires a working dependency and network reachability from the engine; failed RPC is logged and surfaced in reports.

Heartbeat failure indicates the stored credential is stale or the target is unreachable; distinguish credential failure from connectivity failure before rotating.

Privileged access brokering with check-out prevents credential sharing; the password is injected into the session rather than displayed to the user.

Audit entries are immutable from the UI; they record who, what, when, and the source IP for secret views, edits, and permission changes.

Report scheduling can deliver reports (e.g., password change status, secret audit) on a recurring basis to configured recipients.

Role permissions to administer users, roles, and configuration should be limited; the principle of least privilege applies to Secret Server admins too.

AD/LDAP synchronization settings include the domain, bind account, search base, and sync interval; group sync maps directory groups to Secret Server groups.

The application key file must be backed up separately from the database and stored securely; it is not recoverable from the database alone.

Upgrades require a supported path and a backup of both database and application key before proceeding; verify engine compatibility after upgrade.

System health and engine status pages show connectivity, RPC queue, and errors; use them to diagnose heartbeat and password-change failures.

Compliance reporting draws on the audit log to evidence who accessed which privileged credential and when, supporting periodic access reviews.

Secret lifecycle: create from template, assign to folder, apply policy, optionally require approval/check-out, rotate via RPC or heartbeat, and retire or delete with audit trail.

Deleting a secret moves it to a recycle bin where it can be restored; permanent deletion requires the appropriate permission and is audited.

Secret templates can be versioned; changing a template affects secrets created from it, so test template changes before applying to production.

Password requirements on a template or policy define minimum length, complexity, and history; generation enforces them at creation and rotation.

Remote Password Changing can be triggered manually, on a schedule, or after check-in, depending on policy and secret configuration.

A secret's dependency must match the target system type; mismatched dependencies cause RPC failures even when credentials and connectivity are correct.

Secret Server supports folder-level policies that override site defaults, letting teams apply stricter rotation to sensitive folders.

Grant access to groups rather than individuals; group-based ACLs simplify reviews and reduce orphaned permissions when users leave.

When a user is removed from a directory group, synchronized group membership removes the corresponding Secret Server access at the next sync.

Folder design should mirror the organization's access boundaries; placing secrets with different audiences in one folder forces overly broad grants.

"Add Secret" permission on a folder lets a user create secrets there without necessarily viewing existing ones; separate the two where needed.

Secret access requests can specify a reason; the reason is captured in the audit trail and visible to approvers.

Review folder ACLs periodically; inherited permissions from a broad parent can silently expose secrets placed in a child folder.

Application accounts used for API access should have narrowly scoped roles and folder grants, and their activity is audited like user activity.

Recording retention should align with the organization's evidence-retention policy; recordings consume storage and must be managed.

Session recordings are evidence; access to them should be restricted to auditors and security staff via role permissions.

Playback of a recording shows the timeline of screen and keystrokes; use it to reconstruct exactly what a privileged user did on a target.

Recording does not replace OS-level logging on the target; correlate Secret Server recordings with target event logs for full coverage.

Sessions launched directly (not proxied) bypass recording; enforce proxied launchers where recording is mandatory.

Forced session termination (where supported) ends an active proxied session; the action is logged and visible in session reporting.

Recording configuration is set per launcher/secret; verify the launcher used by a template actually enables recording before relying on it.

Change control: export templates, policies, and roles before changes; compare after changes to detect unintended drift.

Least privilege for service accounts and engines: engines need network access to targets and the database but should not hold broad Secret Server admin roles.

Audit log retention and export: export audit data to a SIEM for long-term retention beyond the in-product retention window.

Monitor heartbeat and RPC failure reports routinely; unresolved failures mean stored credentials may not match targets, creating lockout risk.

User onboarding/offboarding: disable or remove the user, confirm group sync removes access, and review any secrets they owned or checked out.

Test disaster recovery by restoring a database backup with the application key into a non-production environment to confirm decryptability.

Report permissions are role-based; grant reporting to auditors without granting secret-view rights to preserve separation of duties.

Revealing a secret value is an audited event; the audit records the user, secret, time, and source, even when access is via API.

Check-out and approval are independent controls; a secret can require both, requiring approval before checkout and checkout before reveal.

The "View" permission on a secret is required to see its value; "Edit" allows modification; "Owner" allows permission changes on that secret.

Secret Server's web UI, API, and launchers all enforce the same permission model; bypassing the UI does not bypass ACLs.

Session recording and secret reveal are separate capabilities: a user may launch a recorded session without ever seeing the password.

Password generation uses the template or policy requirements; generated passwords are stored encrypted and never shown in logs.

A secret's effective policy is the most specific applicable policy (secret, then folder, then site), so folder policy changes can alter rotation behavior.

Folder owners can manage their folder's ACL without site-admin rights; delegate ownership to team leads to scale administration.

Breaking inheritance on a child folder is appropriate when the child needs a different audience; document why to avoid accidental exposure.

Use "List" for users who need to know a secret exists (e.g., to request access) without seeing its value.

Approval workflows can be scoped to a folder so all secrets within inherit the same approvers and duration.

When moving secrets between folders, re-verify ACLs at the destination; inherited grants may differ from the source.

Audit permission changes on sensitive folders; unexpected grants are a common finding in access reviews.

Separate duties: those who approve access should not also be the ones who can silently grant folder ownership.

Credential injection means the password is passed to the target by Secret Server, so the user never sees it; this reduces exposure and sharing.

Check-out duration should be short enough to limit exposure but long enough to complete the task; expiration auto-checks-in the secret.

Approval + recording together give both pre-access authorization and post-access evidence, a common control pairing for privileged access.

Session recording captures what happened during the session; check-out records who held the credential and when, complementing the recording.

For SSH, the proxy handles authentication to the target; verify the target allows the proxy host and that keys/passwords are configured in the dependency.

Failed launches are logged; distinguish permission failure, connectivity failure, and credential failure when troubleshooting.

Review active sessions and check-outs during incident response to identify who currently holds privileged access.

Access reviews use audit and folder ACL reports to confirm each user's access is still justified; revoke grants that no longer match duties.

Secret audit reports show views, edits, and check-outs per secret; use them to detect unusual access patterns.

User audit reports show a user's activity across secrets; useful when a user leaves or changes roles.

Password change status reports identify secrets whose last rotation failed or is overdue; act on failures before they cause outages.

Engine and system logs are the first place to look for RPC or heartbeat failures; audit logs show the user-facing actions, not the internal error.

Backups must include the database and the application key; store the key offline and test restores periodically.

Separation of duties: auditors get report and recording access without secret-view rights; admins who change configuration are audited.

Template fields can be marked required, masked, or password-type; the password-type field is the one rotated by RPC.

A template's launcher and password-change dependency determine how a secret is used and rotated; mismatches cause operational failures.

Creating a secret from the wrong template produces fields that do not match the target system, breaking RPC and launchers.

Template changes propagate to existing secrets; adding a required field may require populating it on existing secrets before they can be saved.

Generated passwords follow template/policy complexity; avoid manual passwords that bypass generation rules.

File-attachment fields store documents (e.g., certificates) encrypted like other secret fields and are subject to the same ACLs.

Secret history preserves prior values for recovery and audit; viewing history is a permissioned, audited action.

Effective access = role permissions ∩ folder/secret ACLs; a user needs both a role that permits the action and a grant on the object.

Group nesting in the directory can grant access indirectly; trace group membership when a user has unexpected access.

"List" on a parent folder does not grant "View" on child secrets; each level's grants are evaluated.

Secret-level exceptions can grant access a folder would deny; review exceptions during access reviews.

Disabling a user immediately blocks login but does not remove their grants; clean up grants and ownership as part of offboarding.

Check-out status is visible to other authorized users, who see the secret as locked until check-in or expiry.

Approval requests capture requester, secret, reason, and approver decision in the audit trail.

Keystroke logs and screen video together reconstruct a session; use both when investigating an incident.

Recordings are stored and indexed for search; locate sessions by user, target, or time.

Recording access is permissioned separately from secret access; auditors review without revealing live credentials.

Direct (non-proxied) sessions are not recorded; enforce proxied launchers where evidence is required.

Correlate recordings with target OS logs to confirm actions taken during the session.

Retention of recordings should match evidence policy; expired recordings are removed per configuration.

Active session reporting supports real-time oversight and incident response.

Engine health and connectivity determine whether RPC and heartbeat can reach targets; check engine status when rotations fail en masse.

The application key is required to decrypt the database; back it up separately and store it securely offline.

Upgrade prerequisites include a supported path and verified backups of database and key; confirm engine compatibility after upgrade.

AD/LDAP sync settings (domain, bind account, search base, interval) drive user and group membership; broken sync stalls access changes.

Audit log export to a SIEM supports retention beyond the in-product window and enables correlation with other systems.

Role permissions for administration should be limited; broad admin rights expand the blast radius of a compromised account.

Routine review of password-change and heartbeat failure reports prevents lockouts and stale credentials.

Secrets are encrypted with a per-secret DEK; the DEK is protected by master key material, which is protected by the application key stored outside the database.

Losing the application key makes database backups unreadable; this is the single most important backup item.

HSM or external key store integration keeps master key material out of the database for stronger protection.

API access is governed by application accounts with scoped roles and folder grants; API secret reveals are audited.

Password-type fields are masked by default; reveal requires View permission and any configured check-out/approval.

Secret versioning retains prior values for recovery; history views are permissioned and audited.

Heartbeat verifies stored credentials still work; failures flag secrets for rotation.

Check-out locks a secret to one user for a configured duration; auto-check-in on expiry or session end returns it to the pool.

Approval workflows require designated approvers; access is granted only after all required approvals.

Approval requests capture a reason, which is recorded in the audit trail for later review.

Folder-level approval settings apply to secrets within unless overridden at the secret level.

"List" without "View" lets users request access without seeing the value beforehand.

Moving a secret changes its inherited ACL and policy; verify the destination before moving production secrets.

Review exceptions and overrides during access reviews; they are common sources of unintended access.

Rotation (RPC) changes the password on the target and updates the stored secret; heartbeat verifies the stored value still authenticates.

A dependency maps a secret to a target system type; mismatched dependencies cause RPC failure even with correct credentials.

Failed RPC is logged with an error; distinguish authentication failure, connectivity failure, and dependency mismatch.

Credential injection during proxied sessions means the user never sees the password; check-out records who held it.

Recording captures the session for evidence; together with check-out it provides who and what.

Active session reporting shows current connections for oversight and incident response.

Enforce proxied launchers where recording is mandatory; direct sessions bypass recording.

Audit entries record who, what, when, and source for secret views, edits, check-outs, and permission changes.

Secret audit reports show access per secret; user audit reports show activity per user.

Password change status reports identify failed or overdue rotations; act before lockouts occur.

Access reviews use audit and ACL reports to confirm access remains justified and to revoke stale grants.

Export audit data to a SIEM for retention beyond the in-product window and cross-system correlation.

Separation of duties: auditors get report and recording access without secret-view rights.

Backups must include the database and the application key; test restores periodically.

Secret Policy sets complexity, rotation interval, and heartbeat behavior; the most specific applicable policy wins (secret, folder, site).

Secret Templates define fields and the password-type field rotated by RPC; every secret is created from exactly one template.

Launchers determine how a secret is used (RDP, SSH, PuTTY) and whether the session is proxied and recorded.

Dependencies define how RPC changes a password on a target; they must match the target system type.

DoubleLock adds a second encryption layer requiring an additional password to reveal a secret.

The application key is generated at install and is required to decrypt the database; back it up separately.

Distributed Engines share the database and must use the same application key to decrypt secrets consistently.

Folders form a hierarchy; children inherit parent ACLs unless inheritance is broken.

Breaking inheritance replaces inherited grants with the child's own ACL; document the reason.

"View" reveals a secret value; "List" shows existence without the value; "Edit" modifies; "Owner" manages the folder ACL.

Folder owners can administer their folder without site-admin rights, scaling delegation.

Group-based grants simplify reviews and reduce orphaned permissions.

Place secrets with similar audiences together; mixing audiences forces overly broad grants.

Review inherited permissions from broad parents; they can silently expose child secrets.

RDP launchers can be proxied through Secret Server for recording; direct RDP bypasses recording.

SSH launchers can proxy through Secret Server, injecting credentials so the user never types the password.

PuTTY launchers provide SSH access; verify whether the launcher proxies and records.

The launcher configured on a template/secret determines recording behavior; verify before relying on evidence.

Recorded sessions are searchable by user, target, and time for investigation.

Recording access is permissioned separately from secret access; auditors review without revealing live secrets.

Failed launches are logged; distinguish permission, connectivity, and credential failures.

Role permissions grant site-wide capabilities (administer users, roles, configuration); folder ACLs grant object access; both are required.

AD/LDAP synchronization maps directory users and groups; group sync drives role and folder membership.

Disabling a user blocks login immediately; clean up grants and ownership as part of offboarding.

Engines need network access to targets and the database but should not hold broad admin roles.

Export templates, policies, and roles before changes; compare after to detect drift.

Monitor engine health and RPC/heartbeat failures routinely to prevent lockouts.

Test disaster recovery by restoring a backup with the application key in a non-production environment.

A secret's effective policy is the most specific applicable policy (secret, then folder, then site), so folder changes can alter rotation.

Generated passwords follow template/policy complexity; manual passwords bypass generation rules.

Password-type fields are masked by default; reveal requires View permission and any configured check-out/approval.

Secret versioning retains prior values for recovery; history views are permissioned and audited.

Deleting a secret moves it to a recycle bin; permanent deletion requires permission and is audited.

Template changes propagate to existing secrets; test before applying to production.

File-attachment fields are encrypted like other fields and subject to the same ACLs.

Access requests route to approvers; access is granted only after all required approvals and expires per configured duration.

Requests capture a reason, recorded in the audit trail and visible to approvers.

Approval settings can be scoped to a folder so secrets within inherit approvers and duration.

Secret-level overrides can change approval requirements for individual secrets.

"List" without "View" lets users request access without seeing the value beforehand.

Check-out and approval are independent; a secret can require both.

Review approval overrides during access reviews; they are common sources of unintended access.

Active session reporting shows current connections, targets, and start times for oversight.

Forced termination (where supported) ends a proxied session and is logged.

Check-out status is visible to authorized users; the secret appears locked until check-in or expiry.

Review active sessions and check-outs during incident response to identify current privileged access holders.

Recording captures what happened; check-out records who held the credential and when.

Enforce proxied launchers where recording is mandatory.

Correlate recordings with target OS logs to confirm actions taken.

Backups require both the database and the application key; losing the key makes backups unreadable.

Store the application key offline and separately from the database.

Test restores periodically in a non-production environment to confirm decryptability.

Upgrades require a supported path and verified backups before proceeding.

Confirm engine compatibility after upgrade; mismatched engines break RPC and heartbeat.

Audit log export to a SIEM supports retention beyond the in-product window.

Routine review of rotation failures prevents lockouts and stale credentials.