Delinea Secret Server key terms

A stored credential record in Secret Server, such as a password, API key, SSH key, or certificate, wrapped with metadata like owner, folder, and access policy. Users retrieve or check out the underlying value according to permissions rather than reading it directly from a file or script.

A reusable definition that determines which fields a secret contains, how each field behaves, and which password changer or heartbeat policy applies. Templates standardize data entry and drive automation, so choosing the right template is a prerequisite for rotation and session launching to work.

The encrypted storage layer where secret values reside, protected by a server-side encryption key hierarchy rather than plain database columns. Even someone with direct database read access sees ciphertext, so vault integrity depends on protecting the encryption keys and the application host itself.

A cryptographic key in the Secret Server key hierarchy that protects vault contents. Keys can be stored locally or in a hardware security module, and their loss or exposure is catastrophic, so backup, custody, and rotation procedures are core administrative concerns.

A tamper-resistant appliance that stores and uses cryptographic keys without exposing them to the application host. Integrating an HSM with Secret Server moves key custody out of software files, strengthening protection against host compromise but adding a dependency that must be highly available.

The scheduled or event-driven replacement of encryption keys protecting stored secrets. Rotation limits the blast radius of a leaked key and is often required by policy, but it must be planned with backups and HSM coordination so that existing secrets remain decryptable throughout the change.

An individual application server in a Secret Server deployment. Multiple nodes can sit behind a load balancer for availability, sharing the same database and distributed vault key material, so configuration, patching, and time synchronization must be consistent across all nodes.

A lightweight component installed on remote networks that performs password changes, heartbeats, and session recordings on behalf of the central Secret Server. It lets rotation and proxying reach segmented environments without opening inbound firewall paths to the core platform.

A container that organizes secrets and carries permissions, inheritance settings, and template restrictions. Because access is often granted at folder level rather than per secret, folder design is the primary determinant of who can see and use which credentials.

An access rule assigned to a user or group on a folder, specifying allowed actions such as view, edit, owner, or restricted retrieval. Folder permissions cascade to contained secrets unless inheritance is broken, making them the main lever for least-privilege design.

The behavior where child folders and secrets automatically receive the permissions defined on parent folders. Inheritance simplifies administration but can silently over-grant access, so administrators periodically review where it is enabled and where explicit overrides break the chain.

The combined access a user actually has on a secret after merging direct grants, group memberships, folder inheritance, and role assignments. Troubleshooting access problems requires calculating effective permissions rather than looking at any single permission entry.

An administration model where users receive roles that bundle application capabilities, such as creating secrets, managing users, or viewing audit logs, separate from which secrets they can see. Roles govern platform functions while folder permissions govern data access.

A named collection of application permissions assigned to users or groups in Secret Server, controlling features like user management, reporting, or configuration. Roles answer what a person can do in the product; folder permissions answer which secrets they can touch.

A set of users, often synchronized from a directory service, used to simplify permission assignment. Granting access to groups instead of individuals keeps administration manageable and reduces orphaned access when staff change roles or leave the organization.

The configured process that imports users and groups from a directory service into Secret Server. Synchronization keeps identities current and enables group-based permissions, but stale or misconfigured mappings can leave departed users with lingering access until reviewed.

The principle of granting each identity only the access needed for its tasks and no more. In Secret Server this means scoping folder permissions narrowly, avoiding broad inheritance, limiting owner rights, and reviewing access requests rather than defaulting to wide visibility.

A workflow in which a user asks for time-bound access to a secret or folder, and an approver grants or denies it. It supports just-in-time privilege so standing access is minimized, and the approval trail becomes part of the audit evidence.

The configured rules that decide who must approve an access request and under what conditions, such as requiring a manager plus a security reviewer. Well-designed workflows balance speed for routine access against scrutiny for high-impact credentials.

A retrieval mode that grants one user exclusive use of a secret for a defined period, optionally changing the password on checkout and again on check-in. It prevents simultaneous use of shared accounts and produces a clear record of who held the credential and when.

The action of returning a checked-out secret, which may trigger a password change and release the lock for other users. Forced check-in by an administrator recovers secrets abandoned by users who never returned them, keeping rotation schedules intact.

The automated routine that resets a credential on the target system and writes the new value back into Secret Server. Changers are template- and platform-specific, and a failing changer leaves the stored secret out of sync with reality, breaking automation and logins.

A scheduled verification that a stored secret still works against its target system, with optional automatic rotation when it fails. Heartbeats detect drift caused by manual password changes, expired accounts, or connectivity problems before users discover them during an incident.

A recorded relationship showing where a secret is used, such as a service, script, or scheduled task. Dependencies let administrators assess impact before rotating or deleting a credential and support cleanup when a system is decommissioned.

The capture of a privileged remote session, including keystrokes and screen activity, for later review. Recordings provide non-repudiation and forensic evidence, and they are typically stored and retained according to policy separate from the credential vault itself.

The Secret Server feature that opens a connection to a target system using a stored credential without revealing the password to the user. It supports protocols like RDP and SSH and can inject credentials automatically, reducing exposure of shared account passwords.

An intermediary that brokers connections between the user and the target system, enabling recording, keystroke logging, and policy enforcement. Because traffic passes through the proxy, access can be controlled and observed even when the user never sees the credential.

A technique where the launcher supplies the credential directly to the target's login process so the user never views or types the password. It preserves credential secrecy while still authenticating the session, and it depends on supported protocols and target configuration.

The discipline of controlling, monitoring, and auditing high-impact accounts such as domain administrators, root, and service accounts. Secret Server implements PAM through vaulting, rotation, brokered sessions, and approval workflows rather than through shared spreadsheets or memory.

Granting elevated access only for the period it is needed, then revoking it automatically. In Secret Server this is achieved with access requests, approvals, and time-limited checkouts, shrinking the window in which a compromised account or insider can do harm.

The chronological record of actions in Secret Server, including secret views, edits, permission changes, and administrative configuration. Audit logs answer who did what and when, and they are the primary evidence source for investigations and compliance reviews.

A predefined or custom view that summarizes data such as secret inventory, expiring credentials, permission assignments, and activity trends. Reports support operational hygiene and audit preparation, and they can often be scheduled for delivery to stakeholders.

Producing evidence that controls are operating as intended for frameworks and auditors, such as access reviews, rotation coverage, and privileged session records. Effective compliance reporting maps product data to control requirements rather than exporting raw logs without context.

A periodic examination of who can access which secrets and folders, confirming that grants remain justified. Reviews catch permission creep from inheritance, group changes, and temporary access that was never removed, and they generate documented attestation for auditors.

Sending Secret Server audit and event data to an external log collector or SIEM. Centralizing logs protects evidence from tampering on the application host and enables correlation with other security events, but forwarding failures must be monitored so gaps are noticed.

The practice of protecting the Secret Server database, encryption keys, and configuration so the platform can be rebuilt after failure. Restores are useless without matching key material, so backups of vault data and key custody must be tested together.

Authentication where users log in to Secret Server through an identity provider rather than a separate password. SSO centralizes deprovisioning and enforces multifactor authentication, but emergency local accounts must still be maintained for identity provider outages.

Distributing client requests across multiple Secret Server nodes to improve availability and performance. Correct configuration requires session affinity or shared state, health checks, and synchronized node settings so users are not routed to a misconfigured or unhealthy server.