Secret server training guide

00

FOUNDATION

ARCHITECTURE OVERVIEW

Understanding Secret Server's core data model before configuration begins

🏗️

Secrets

Atomic unit of the vault. A secret holds one set of credentials (username, password, key) plus metadata, governed by a template.

📋

Templates

Blueprints that define the fields a secret contains. Templates are versioned and control launchers, heartbeat scripts, and RPC behavior.

📁

Folders

Hierarchical containers that organize secrets. Permissions assigned at folder level cascade to all children via inheritance.

🔄

Policies

Secret Policies define groups of settings (checkout, heartbeat, expiry) and apply uniformly across folders or individual secrets.

🤖

Remote Password Changing

RPC engine rotates credentials on the remote target after a Secret is updated. Requires a privileged account or discovery source.

🔗

Dependencies

Registered external services (Windows Services, IIS pools, scheduled tasks) that consume a vaulted credential and must be updated on rotation.

VAULT HIERARCHY

🔐 Secret Server Vault │ ├── 📁 IT Infrastructure │ ├── 📁 Windows Domain │ │ ├── 🗝 svc_backup (Active Directory Account) │ │ └── 🗝 admin_dc01 (Windows Local Account) │ └── 📁 Linux / SSH │ └── 🗝 root@web01 (Unix Account — SSH Key) │ ├── 📁 Applications │ ├── 🗝 mssql_app_user (SQL Server Login) │ └── 🗝 api_key_stripe (Generic API Credential) │ └── 📁 Cloud Platforms ├── 🗝 aws_prod_iam (AWS IAM Key Pair) └── 🗝 azure_sp_01 (Azure Service Principal)

ℹ️

Navigation Tip Click any step in the numbered lists below to expand detailed instructions. Use the sidebar to jump between modules. Your progress is tracked automatically.

01

CONFIGURATION

SECRET TEMPLATES

Creating and customizing field definitions, launchers, and RPC commands

Secret Templates define the shape of every secret in the vault. Getting templates right early prevents painful migrations later. Secret Server ships with 30+ built-in templates; create custom ones for internal systems that deviate from standard patterns.

01

Navigate to Admin → Secret Templates

Access the template management console from the Admin menu. Requires the Administer Secret Templates role permission.

🧭

PathAdmin > Secret Templates > [+ Create New] or duplicate an existing template as a baseline.

Required Permission=Administer Secret Templates

Recommended Approach=Copy closest built-in template, then modify

02

Define Template Fields

Add fields for each data element: username, password, host, port, notes. Mark the password field for RPC and heartbeat.

Field Name	Field Type	Required	Hide On View	Notes
Username	Text	Yes	No	Maps to RPC username variable
Password	Password	Yes	Yes	Enable for RPC + Heartbeat
Server / Host	Text	Yes	No	Used by launchers and RPC
Port	Text	Optional	No	Override default if non-standard
Notes	Notes	No	No	Free-form operational context

03

Configure the Password Changer (RPC)

Assign a built-in or custom password changer to automate credential rotation on the remote target after a rotation event.

# Example: Custom PowerShell RPC command for a proprietary service
$username  = "$[1]$username"      # Token: secret field reference
$password  = "$[1]$password"      # New password injected by SS
$oldpass   = "$[1]$currentpassword"

# Invoke proprietary CLI to perform rotation
svcctl.exe changepass "$username" "$oldpass" "$password"
if ($LASTEXITCODE -ne 0) { throw "Password change failed" }
            

RPC Tab→Password Type: Custom (PowerShell)

Privileged Account→Domain Admin or service account with rights

Retry Count→3 (default)

04

Attach a Launcher

Launchers open an RDP, SSH, or web session using vaulted credentials without exposing the password to the user.

🖥️

RDP Launcher

Maps $machine, $username, $password to an mstsc session via the Secret Server Connect As user.

🐚

SSH Launcher

Opens PuTTY or built-in web terminal. Supports both password and private key authentication from the secret.

🌐

Web Password Filler

Browser extension injects credentials into web login forms. Requires mapping field names to form element selectors.

05

Version and Publish the Template

Save the template. Existing secrets using it retain field values; added fields default to empty. Test with a sandbox secret before production rollout.

⚠️

Caution — Removing FieldsDeleting a field from a template is permanent and will delete that data from all secrets using the template. Export secrets to CSV first.

02

SECURITY

FOLDERS & PERMISSIONS

Organizing secrets into a hierarchy with role-based access inheritance

Folder permissions in Secret Server follow an additive inheritance model. Child folders inherit permissions from parents, and explicit permissions on a child folder supplement (not replace) inherited ones unless you break inheritance deliberately.

PERMISSION MATRIX

Permission Level	View Secret	Edit Fields	View Password	Own Secret	Typical Role
List	Name only	✗	✗	✗	Auditors
View	All fields	✗	Masked	✗	Help Desk
View + Copy	All fields	✗	Full	✗	Dev Teams
Edit	All fields	✓	Full	✗	SysAdmins
Owner	All fields	✓	Full	✓ (delete, share)	Secret Owners

CONFIGURATION STEPS

01

Plan the Folder Taxonomy

Design the folder tree to mirror your org structure or service categories before creating folders. Refactoring later is costly.

## Recommended taxonomy models

# Model A — By Org Unit (best for large enterprises)
/ Root
  /Infrastructure
    /Windows
    /Linux
    /Network
  /Applications
    /Databases
    /Middleware
  /Cloud
    /AWS
    /Azure

# Model B — By Environment (best for regulated industries)
/ Root
  /Production
  /Staging
  /Development
            

02

Create Folders and Set Inheritance Mode

Create folders via Admin → Folders. By default, child folders inherit parent permissions. Break inheritance only when an explicit permission override is needed.

Inherit Permissions from Parent=ON (recommended default)

Break Inheritance=Use only for high-security isolation (PAM accounts)

Apply to Sub-Folders=Propagate changes to all children on save

03

Assign Groups, Not Individual Users

Always assign permissions to AD groups or Secret Server roles — never to individual user accounts. This prevents access orphaning when staff change roles.

⚠️

Best Practice — Group AssignmentCreating a dedicated SS-Vault-{TeamName} AD group per team enables joiners/movers/leavers to be managed in Active Directory without any vault reconfiguration.

04

Assign a Default Secret Policy to the Folder

Set a Secret Policy at the folder level so all newly created secrets automatically inherit heartbeat, checkout, and expiry settings.

Folder Settings → Secret Policy→Select or create the appropriate policy

Force Policy On Children→Enable to prevent policy overrides at secret level

✅

Inheritance VerificationAfter setting folder permissions, open a child secret and verify the Permissions tab shows inherited (grey) entries alongside explicit ones. Inherited entries cannot be individually removed without breaking inheritance.

03

SECURITY

PASSWORD COMPLEXITY

Configuring generation rules and enforcement policies for credential rotation

Secret Server uses Password Requirements — named rulesets applied per template field — to govern what is generated and accepted. Complexity rules apply at both manual entry and RPC rotation time.

STRENGTH BENCHMARKS

Minimum 8 chars, any

Weak

12 chars + upper + lower

Low

16 chars + upper + lower + number

Medium

20 chars + mixed + symbols

High

32 chars + full charset + no repeat

Max

CONFIGURATION STEPS

01

Create a Password Requirement

Admin → Password Requirements → Create New. Name it descriptively (e.g., AD-Domain-Accounts-High-Security).

Minimum Length=24 (production service accounts)

Uppercase Characters=Minimum 2

Lowercase Characters=Minimum 2

Numeric Characters=Minimum 2

Special Characters=Minimum 2 (exclude: space, % , " \)

Character Repetition=Max 3 consecutive same characters

Custom Charset Exclusions=Remove chars that break legacy app parsers

02

Assign the Requirement to a Template Field

In the Secret Template editor, open the Password field and set the Password Requirements dropdown to your named ruleset.

ℹ️

Field-Level vs Policy-LevelSetting complexity at the template field level controls generation. To enforce a minimum complexity on import/manual entry, also configure it in the Secret Policy's Password Complexity section.

03

Configure Expiry and Rotation Schedules

Secret Policies include an Auto Change Schedule that triggers RPC on a cadence (e.g., every 90 days) independently of heartbeat results.

Auto Change Enabled=Yes

Change Frequency=Every 90 days (NIST 800-63B: change only on compromise)

Change On Check-In=Yes (rotate after every checkout session)

Notify Before Expiry=14 days via email/SIEM

🚫

Excluded Characters — CriticalTest generated passwords against your target system before production rollout. Legacy applications often reject backslash (\), percent (%), double-quote ("), or angle brackets. Add these to the exclusion list in the password requirement to prevent RPC failures mid-rotation.

04

AUTOMATION

HEARTBEAT MONITORING

Detecting credential drift by continuously validating vaulted passwords against their targets

Heartbeat sends an authentication probe to the remote target on a schedule. If the vaulted credential no longer authenticates, the secret is marked Failed and alerts are raised — before an operator encounters a lockout or failed service.

Scheduler fires heartbeat probe

Secret Server engine contacts the Distributed Engine (or internal engine) assigned to the secret's site.

Engine attempts authentication

Uses the vaulted username + password against the target (WMI, SSH, SQL login, LDAP bind, API auth, etc.).

Result recorded

Success → heartbeat timestamp updated. Failure → secret flagged with "Heartbeat Failed" status; event logged to Syslog/SIEM.

Alert / Auto-remediation fires

Email/Slack notifications sent. Optionally trigger an RPC attempt to re-sync the vaulted credential with the target.

HEARTBEAT CONFIGURATION

01

Enable Heartbeat on the Secret Policy

Admin → Secret Policies → [Policy] → Heartbeat tab. Enable and set the interval.

Heartbeat Enabled=Yes

Heartbeat Interval=15 minutes (critical accounts) / 1 hour (standard)

Auto-Change on Failure=Yes — if RPC is configured and target can accept changes

Out of Sync Threshold=3 consecutive failures before escalation alert

02

Assign the Correct Site / Distributed Engine

Heartbeat traffic must originate from a network segment that can reach the target. Assign the correct Site on the secret's General tab.

⚠️

Network SegmentationIf the target is in a DMZ or isolated VLAN, deploy a Distributed Engine in that segment. The engine only needs outbound HTTPS to Secret Server — no inbound rules required.

# Verify engine connectivity from the DE host
Test-NetConnection -ComputerName secretserver.corp.local -Port 443

# Confirm engine service is running
Get-Service -Name "Thycotic Secret Server Distributed Engine"

# Check engine registration in SS UI:
# Admin → Distributed Engine → [Engine Name] → Status: Online
            

03

Monitor Heartbeat Status Dashboard

Reports → Secrets → Heartbeat Failures shows all failing secrets in real time. Pin this to the SS dashboard for operations staff.

🟢

Success

Credential authenticated. Last heartbeat timestamp updated. No action needed.

🔴

Failed

Auth rejected. Credential may have been changed out-of-band. Investigate immediately — service accounts may be locked.

🟡

Pending / Unknown

First run not yet completed, or engine offline. Check engine health and site assignment.

04

Configure Alert Notifications

Admin → Configuration → Email → set SMTP. Then add notification rules in the Secret Policy or via Event Subscriptions.

Event: Heartbeat Failure→Email vault admins + ticket to ServiceNow

Event: Auto-Change Failure→PagerDuty P2 alert

SIEM Integration→Syslog CEF format → Splunk / Sentinel

05

ACCESS CONTROL

CHECK-IN / CHECK-OUT

Enforcing single-use access, approval workflows, and session isolation

Check-Out enforces that only one user at a time can access a secret. When combined with Change on Check-In, the password is rotated automatically after every use, ensuring no credential reuse between sessions.

🔒

Exclusive Check-Out

Once checked out, no other user can access the secret until it is checked in or the interval expires. Eliminates shared session risk.

⏱️

Interval Enforcement

Set a maximum check-out duration. Secret auto-returns after the interval. Prevents indefinite holds by forgetful users.

🔁

Change on Check-In

Rotates the password immediately upon check-in, making the previously-used credential invalid. Enables one-time-use semantics.

✍️

Approval Workflow

Require one or more approvers before access is granted. Integrates with ServiceNow change tickets for PAM compliance.

CONFIGURATION STEPS

01

Enable Check-Out in the Secret Policy

Navigate to Admin → Secret Policies → [Policy] → Check-Out tab. Toggle on and set the interval and change-on-check-in behavior.

Require Check-Out=Yes

Check-Out Interval=1 hour (adjust per use case)

Change Password On Check-In=Yes (requires RPC configured on template)

Allow Owner Override=No (break-glass handled separately)

02

Configure Approval Workflow (Optional)

Require 1 or 2 approvers before the check-out is granted. Approvers receive email with approve/deny links.

Require Approval for Access=Yes (PAM-tier accounts only)

Approvers=SS-VaultAdmins group (2 required)

Approval Timeout=30 minutes — then auto-deny

Emergency Access (Break-Glass)=Separate Break-Glass folder; notify CISO automatically

ℹ️

Ticket IntegrationAdmin → Configuration → Ticketing System Integration. Map approval requests to ServiceNow change tickets. The ticket number is stored in the audit log against each check-out event.

03

Test the Check-Out Flow

Log in as a non-admin test user, navigate to the secret, and verify the Check-Out button appears. Attempt to access from a second session to confirm exclusivity.

# Validate check-out via Secret Server REST API
POST /api/v1/secrets/{id}/check-out
Authorization: Bearer {token}

# Expected response on success
{
  "responseCode": 200,
  "checkedOutUserId": 42,
  "checkedOutDateUtc": "2025-03-10T09:00:00Z",
  "checkOutMinutesRemaining": 60
}

# Attempt second check-out (expect 403)
POST /api/v1/secrets/{id}/check-out   # → 403 Forbidden: Already checked out
            

04

Implement Break-Glass Procedure

Administrators need emergency access during a vault outage or approval system failure. Create a dedicated break-glass procedure and isolated folder.

Create /BreakGlass folder with explicit ACL — vault admins only

Duplicate highest-risk secrets into Break-Glass folder

Configure Event Subscription: any access to /BreakGlass → alert CISO + Audit team

Document the procedure in runbook (physical printed copy + encrypted USB)

Test break-glass quarterly; rotate break-glass passwords immediately after test

06

OPERATIONS

SECRET DEPENDENCIES

Managing Windows services, IIS app pools, and scheduled tasks that consume vaulted credentials

When a credential is rotated, any external process running under that credential must be updated simultaneously or it will fail to authenticate. Dependencies automate this propagation — stopping, re-credentialing, and restarting dependent services as part of the rotation workflow.

DEPENDENCY EXECUTION FLOW

Trigger

🔄 RPC Rotation

→

Step 1

🛑 Stop Dependents

→

Step 2

🔑 Change Password

→

Step 3

✏️ Update Credentials

→

Step 4

▶️ Restart Services

→

Step 5

✅ Verify Health

DEPENDENCY TYPES

🪟

Windows Services

Services running under a domain service account that is vaulted. Auto-updated via SC.exe or WMI after password rotation.

# Secret Server built-in dependency type: Windows Service
# Configuration fields in SS UI:

Dependency Name:   MyBackupService on APPSVR01
Machine Name:      APPSVR01.corp.local       # or $machine token
Service Name:      MyBackupService
Run As Secret:     [select a privileged secret with admin rights to APPSVR01]
Restart On Change: Yes
Wait For Start:    30 seconds

# SS will execute equivalent of:
sc.exe \\APPSVR01 config MyBackupService obj= "CORP\svc_backup" password= "<newpw>"
sc.exe \\APPSVR01 stop  MyBackupService
sc.exe \\APPSVR01 start MyBackupService
            

🌐

IIS Application Pools

App pools running under a custom identity. Secret Server updates the pool identity via WMI/PowerShell and recycles the pool.

# Dependency type: IIS Application Pool
Server Name:     WEB01.corp.local
App Pool Name:   MyAppPool
Run As Secret:   [IIS Admin secret with rights on WEB01]

# Under the hood, SS executes via PowerShell remoting:
Import-Module WebAdministration
$pool = Get-Item "IIS:\AppPools\MyAppPool"
$pool.processModel.userName = "CORP\svc_webapp"
$pool.processModel.password = "<newpw>"
$pool.processModel.identityType = 3  # SpecificUser
$pool | Set-Item
Restart-WebAppPool -Name "MyAppPool"
            

📅

Scheduled Tasks

Task Scheduler jobs run-as a service account. SS uses schtasks.exe or PowerShell to update the credential on the task after rotation.

# Dependency type: Windows Scheduled Task
Machine Name:  BATCHSVR01.corp.local
Task Path:     \Corp\NightlyDataSync      # Full task scheduler path
Run As Secret: [Admin secret on BATCHSVR01]

# SS executes:
schtasks.exe /Change /S BATCHSVR01 /TN "\Corp\NightlyDataSync" \
  /RU "CORP\svc_batch" /RP "<newpw>"

# Verify with:
schtasks.exe /Query /S BATCHSVR01 /TN "\Corp\NightlyDataSync" /V /FO LIST
            

🔧

Custom PowerShell Dependencies

For proprietary services, connection strings in config files, or any custom integration — use the PowerShell dependency type with full scripting control.

# Example: Update connection string in a .config file
param(
  [string]$username,
  [string]$newPassword,
  [string]$server
)

$configPath = "\\$server\d$\App\config\appSettings.config"
$xml = [xml](Get-Content $configPath)
$connStr = $xml.SelectSingleNode("//add[@key='DbConnectionString']")
$connStr.value = "Server=$server;User=$username;Password=$newPassword"
$xml.Save($configPath)

# Restart dependent IIS site to pick up new config
Invoke-Command -ComputerName $server -ScriptBlock {
  Restart-WebItem -PSPath "IIS:\Sites\MyApplication"
}
            

✅

Dependency Ordering and Testing

Set execution order — services should stop before the password changes, and restart after. Test each dependency individually before enabling auto-rotation in production.

Set dependency sort order: Stop tasks (order 1) → Change password (order 2) → Start services (order 3)

Verify "Run As" secret has sufficient rights on each target machine

Test each dependency via the "Run Now" button in the Dependencies tab

Review dependency run logs — Admin → Remote Password Changing → Dependency Run Log

Enable dependency failure alerts in the Secret Policy event subscriptions

Document rollback procedure: if dependency fails mid-rotation, prior password is in SS audit history

🚨

Production Rotation RiskAlways test dependency chains in a non-production environment first. A failed mid-rotation (password changed on AD but dependency update failed) will leave services using invalid credentials. Secret Server retains prior passwords in its audit vault for emergency rollback.

07

KNOWLEDGE CHECK

VALIDATION QUIZ

Confirm understanding of key concepts before operating the vault in production

Loading question...

Q 1 / 6

OPERATIONS CHECKLIST

Use this checklist to confirm your vault setup is production-ready before go-live.

All custom secret templates tested with at least 5 real secrets in UAT

Folder hierarchy created, AD groups assigned — no individual user permissions

Password requirements configured per credential type (AD, local, DB, API)

Heartbeat enabled on all production secrets; alert routing configured

Check-out + change-on-check-in enabled for all privileged accounts

Approval workflow configured for Tier-0/Tier-1 accounts

All known service dependencies registered and tested on a rotation dry-run

SIEM / Syslog event streaming validated with test events

Break-glass procedure documented, tested, and physically secured

DR/backup process confirmed: SS database backup + encryption key backup stored separately

SECRET SERVERPASSWORD VAULT

ARCHITECTURE OVERVIEW

Secrets

Templates

Folders

Policies

Remote Password Changing

Dependencies

SECRET TEMPLATES

Navigate to Admin → Secret Templates

Define Template Fields

Configure the Password Changer (RPC)

Attach a Launcher

RDP Launcher

SSH Launcher

Web Password Filler

Version and Publish the Template

FOLDERS & PERMISSIONS

Plan the Folder Taxonomy

Create Folders and Set Inheritance Mode

Assign Groups, Not Individual Users

Assign a Default Secret Policy to the Folder

PASSWORD COMPLEXITY

Create a Password Requirement

Assign the Requirement to a Template Field

Configure Expiry and Rotation Schedules

HEARTBEAT MONITORING

Scheduler fires heartbeat probe

Engine attempts authentication

Result recorded

Alert / Auto-remediation fires

Enable Heartbeat on the Secret Policy

Assign the Correct Site / Distributed Engine

Monitor Heartbeat Status Dashboard

Success

Failed

Pending / Unknown

Configure Alert Notifications

CHECK-IN / CHECK-OUT

Exclusive Check-Out

Interval Enforcement

Change on Check-In

Approval Workflow

Enable Check-Out in the Secret Policy

Configure Approval Workflow (Optional)

Test the Check-Out Flow

Implement Break-Glass Procedure

SECRET DEPENDENCIES

Windows Services

IIS Application Pools

Scheduled Tasks

Custom PowerShell Dependencies

Dependency Ordering and Testing

VALIDATION QUIZ

SECRET SERVER
PASSWORD VAULT