Delinea Secret Server study materials
Delinea Secret Server study resources

Delinea Secret Server: Secret Server Fundamentals and Vaulting

Delinea Secret Server · Work through your exam, one topic at a time.

All guide sections

Secret Server Fundamentals and Vaulting

What vaulting means in Secret Server

Secret Server is a centralized vault for privileged credentials and other sensitive records. The exam tests whether you can explain what is stored, how it is protected, and which component does what. A secret is the record (for example, a Windows service account). A secret template defines the record's fields, password policy, launcher options, and heartbeat/RPC behavior. A secret field is one data element on that template, such as Username, Password, Host, or Port. Vaulting means users and scripts do not hold the credential directly; they authenticate to Secret Server, authorization is checked, and the value is decrypted only for an authorized action. Data at rest is encrypted with AES-256 before it is written to the SQL database; TLS protects traffic between clients, web nodes, and engines.

Core components and flow

An on-prem deployment has a web application on IIS, a SQL Server database, and optional Distributed Engines for remote networks. Cloud is Delinea-hosted, but the same template/secret/permission model applies. A user's request flows through authentication, folder/secret authorization, decryption, and an audit event. Heartbeat validates that a credential still works; Remote Password Changing (RPC) changes it on the target and in Secret Server. Dependencies update dependent services or scheduled tasks after a change. Do not confuse heartbeat (verification) with RPC (rotation).

Worked example

A scheduled task runs under a Windows service account in a remote site. Choose the built-in Windows Account template, populate Username, Password, and Host, and assign the secret to a folder. Put a Distributed Engine in that site so heartbeat and RPC can reach the target. Configure heartbeat on a schedule, enable RPC, and add the scheduled task as a dependency. Reasoning: the template supplies the right fields and password changer; the engine solves network reachability; heartbeat proves the credential works; RPC plus dependency rotates the password without breaking the task. A custom template is unnecessary unless the built-in fields are insufficient.

Traps

  • Treating a template as a secret: the template is the schema/policy; the secret is the instance.
  • Saying heartbeat changes the password; it checks it. RPC changes it.
  • Forgetting that database backups are useless without the encryption key material.
  • Assuming every deployment needs a Distributed Engine; it is for segmented/remote networks.
  • Thinking folder names or descriptions are a safe place for credentials; they are not the vaulted field.