Creating the Service Account
Secret Template
Why a Custom Template?
Secret Server ships with built-in templates for Active Directory accounts. However, service accounts require additional metadata fields — the associated application, dependency count, rotation approval chain, and compliance tags. A custom template ensures every vaulted service account carries the context needed for lifecycle management.
Template = Schema
A template defines what fields a secret stores. For service accounts, you need more than username + password — you need ownership, scope, and dependency metadata.
Template = Behavior
The template also binds the password changer, heartbeat configuration, and launcher — defining how Secret Server manages credentials, not just what it stores.
One Template, Consistent Governance
All service accounts vaulted under the same template will share the same rotation policies, heartbeat schedules, and audit behavior. Consistency is the goal.
Step-by-Step Procedure
01
Navigate to Admin → Secret Templates
In Secret Server, click the Admin menu (top nav) then select Secret Templates. You will see the list of existing templates. Service account templates built on the "Active Directory Account" base template are the recommended starting point.
02
Duplicate the Active Directory Account Template
Find "Active Directory Account" in the list. Click its name → select Duplicate (not Edit — duplicating preserves the original and the built-in password changer binding). Name the duplicate clearly:
Service Account — Windows (Managed).03
Add Custom Fields to the Template
In the duplicated template, click Edit Fields. Add the following custom fields to capture service account governance metadata. Fields marked Required enforce data completeness on import.
| Field Name | Type | Required | Purpose |
|---|---|---|---|
| Domain | Text | Yes | FQDN of the account's domain (pre-populated by discovery import) |
| Username | Text | Yes | SamAccountName — the core identifier |
| Password | Password | Yes | Encrypted credential field — binds to the password changer |
| Application Owner | Text | Yes | Name/team responsible for the associated application |
| Supporting Application | Text | Yes | Application or service this account authenticates |
| Notes | Notes | No | Rotation impact notes, exception rationale, etc. |
| Dependency Count | Text | No | Informational — number of mapped dependencies |
04
Bind the Password Changer
In the template settings, ensure the Password Changer field is set to "Active Directory". This binding is what enables automated rotation. If the field shows "None," Secret Server cannot rotate the password. You will configure changer details in Chapter 03.
05
Configure the Template's Secret Policy
In the template's General tab, set a Secret Policy. Create a policy named
Service Account — Standard Policy with: Requires approval for view (Owners exempt), auto-change password enabled, heartbeat enabled, and expiration interval of 90 days. This policy will apply automatically to every secret created from this template.
Policy vs Template
Secret Policies can override template settings for individual secrets. Ensure your policies do not accidentally disable heartbeat or rotation for exceptions, as this is a common misconfiguration.
06
Set Up Field Encryption and Masking
Mark the Password field as Encrypted (default for password-type fields) and enable Mask on View. This ensures passwords are never displayed in plain text in the UI or audit logs. All other fields should remain unencrypted for searchability and reporting.
Template Checkpoint
Your template is ready when: it appears in the template list with status Active, has the Active Directory password changer bound, includes all required fields, and has a Secret Policy assigned. Test by creating a dummy secret from the template — all required fields should prompt for input.
You duplicate the built-in "Active Directory Account" template and add custom fields. A colleague suggests editing the built-in template directly instead to save time. Why is duplicating the correct approach?
✓ Correct. Editing built-in templates propagates changes to every existing secret using that template — including field removals, which can cause data loss. Built-in templates are also re-evaluated during Secret Server upgrades. Duplicating preserves the original and isolates your customizations safely.
Vaulting the
Credential
Two Paths to Vaulting
Service accounts can be vaulted via the Discovery import flow (recommended — pre-populates fields from scan data) or manually via Secrets → New Secret. Both create the same result; discovery import is faster and more accurate for accounts already in your scan results.
Path A — From Discovery (Recommended)
01
Open Discovery → Unmanaged Accounts
Navigate to Admin → Discovery → Network View. Select your domain discovery source and click Unmanaged Accounts. Filter by Type: Service Account to show your priority queue. Each row represents a discovered, not-yet-vaulted account.
02
Select the Account and Click "Add Secret"
Check the box next to your target account (e.g.
CORP\svc_sqlprod01). Click Add Secret. A wizard opens. Select your custom template: Service Account — Windows (Managed).03
Complete All Required Fields
The import wizard pre-populates Domain and Username from the discovery scan. You must manually enter: the current password (obtain from the application owner — this is the initial vaulting credential), Application Owner name, and Supporting Application. Set folder location before saving.
Critical: Correct Initial Password
The password you enter during vaulting MUST match the current AD password for the account. If incorrect, heartbeat will immediately flag it as a mismatch and rotation will fail. Coordinate with the account owner to obtain the current credential securely.
04
Assign to the Correct Folder and Set Ownership
Use a folder structure like:
Service Accounts → [Domain] → [Application Team]. Assign the secret Owner to the application team group (not an individual). Set View/Edit permissions for the PAM team. Do not leave the secret in the root folder — folder-level policies and permissions are the primary governance control.05
Verify the Secret Saves and Heartbeat Begins
After saving, the secret page should show a Heartbeat status indicator. Within 5 minutes of creation, heartbeat will run its first check. If the password is correct, status shows ● Success. If not, ● Failed — indicating a password mismatch that must be resolved before rotation can proceed.
Path B — Manual Secret Creation
When to Use Manual Creation
Use manual creation for accounts that Delinea discovery did not surface — such as local accounts, accounts in unusual OUs, or accounts discovered via config file scanning. The process is identical to Path A but without the pre-populated fields.
# Recommended structure — apply permissions at each level Service Accounts/ ├── CORP.CONTOSO.COM/ │ ├── Database/ # Owned by: DBA Team group │ │ ├── svc_sqlprod01 ● Vaulted ✓ │ │ ├── svc_sqlagent02 ● Vaulted ✓ │ │ └── svc_ssrs_report ● Vaulted ✓ │ ├── Web Platform/ # Owned by: Web Ops group │ │ ├── svc_iiswebapp ● Vaulted ✓ │ │ └── svc_appcache ● Vaulted ✓ │ ├── Identity/ # Owned by: Identity Team group │ │ └── svc_adconnect ● Vaulted ✓ │ └── _Orphaned/ # Quarantine folder — pending investigation │ └── svc_legacy_backup ● Under Review
Avoid
Never place service account secrets in personal folders or the root. Always use group-owned team folders so access survives personnel changes.
| Role | View Secret | Edit Secret | Rotate Password | View Password |
|---|---|---|---|---|
| PAM Admin Team | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Application Owner (Group) | ✓ Yes | Limited | With Approval | With Approval |
| Auditors | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Helpdesk | ✗ No | ✗ No | ✗ No | ✗ No |
| Service (API/automation) | API Only | ✗ No | ✗ No | API Only |
You import a service account via the Discovery flow and save the secret. Two minutes later, heartbeat shows "Failed." What is the most likely cause and correct first response?
✓ Correct. A heartbeat failure immediately after initial vaulting almost always indicates a password mismatch. Option D is dangerous — rotating before you know the correct current password can lock out the service account, causing an outage. Always verify and correct the vaulted password first, confirm heartbeat passes, then proceed to configure rotation.
Configuring the
Password Changer
What the Password Changer Does
The password changer is the engine that executes credential rotation. For AD service accounts, it authenticates to the domain controller, changes the account password, then updates the secret in the vault — atomically. Dependencies (services, tasks) are updated after the vault write succeeds.
Secret Server
Generates New
Password
Generates New
Password
Changer Connects
to DC via
LDAP/ADSI
to DC via
LDAP/ADSI
AD Password
Changed
on Account
Changed
on Account
New Password
Written to
Vault
Written to
Vault
Dependencies
Updated
(Ch. 04)
Updated
(Ch. 04)
Heartbeat
Confirms
Success
Confirms
Success
Global Password Changer Settings
Remote Password Changing — Global Configuration
Admin → Remote Password Changing → Configure
● All settings nominal
Enable Remote Password Changing
Master switch — must be ON for any rotation to occur. Off by default in new installations.
Enable Password Change Logging
Logs every rotation attempt, success, and failure to the audit trail. Required for compliance environments.
Allow Immediate Password Change on Secret Create
If enabled, rotation fires immediately when a secret is created. Recommended: OFF for service accounts until dependencies are mapped.
Check Password Changed Externally (Heartbeat)
Enables the system to detect unauthorized out-of-band password changes. Must be ON. Covered in Chapter 05.
Send Email Notification on Password Change
Notifies the secret owner when rotation completes or fails. Requires SMTP configured under Admin → Configuration → Email.
Per-Secret Rotation Configuration
Secret → Remote Password Changing Tab
Configure on each service account secret after vaulting
Must be Enabled for scheduled rotation. Disable only during planned freeze windows — document the reason in the secret's Notes field.
90 days aligns with most compliance frameworks. Shorter intervals require verified dependency automation.
For human-use accounts only. Leave Disabled for service accounts — checkin-triggered rotation breaks running services.
The account Delinea uses to perform the change. Must have "Reset Password" rights on the target account in AD.
Auto-calculated from schedule. Can be manually overridden for coordinated rotation windows.
Service accounts should use passwords significantly stronger than human accounts. 25+ character random passphrases are recommended — the application doesn't need to memorize it.
Rotation Schedule Preview
Computing next rotation dates...
Password Changer Troubleshooting
The Distributed Engine cannot reach a DC. Check in order:
# 1. Verify Distributed Engine site assignment Admin → Distributed Engine → Engine Sites — Confirm the engine for the target subnet is assigned and Online # 2. Test DC connectivity from the engine host Test-NetConnection dc01.corp.contoso.com -Port 389 # LDAP Test-NetConnection dc01.corp.contoso.com -Port 636 # LDAPS Test-NetConnection dc01.corp.contoso.com -Port 3268 # GC # 3. Verify the RPC privileged account has "Reset Password" right Get-ACL "AD:\CN=svc_sqlprod01,OU=ServiceAccounts,DC=corp,DC=contoso,DC=com" | Select-Object -ExpandProperty Access | Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" }
The generated password violates the target domain's password policy — most often Fine-Grained Password Policies (FGPPs) applied to service accounts.
# List all FGPPs and the accounts/groups they apply to Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, MinPasswordLength, PasswordHistoryCount, MaxPasswordAge, Precedence | Format-Table -AutoSize # Check which FGPP applies to a specific account Get-ADUserResultantPasswordPolicy -Identity svc_sqlprod01
Fix
Update the Secret Server Password Requirements policy assigned to this secret to match or exceed the FGPP requirements. Never lower the FGPP to match Secret Server — always align SS policy upward.
Common on accounts with many dependencies (50+ service instances). The dependency update phase runs synchronously and can exceed the default timeout.
| Setting | Location | Recommended Value |
|---|---|---|
| RPC Timeout | Admin → Remote Password Changing → Timeout | 120 seconds (default: 30) |
| Dependency Timeout Per Host | Admin → Discovery → Dependency Timeout | 60 seconds |
| Max Concurrent Dependencies | Engine Site settings | 10 (reduce if hosts are slow) |
You configure automatic rotation on a service account secret and set "Allow Immediate Password Change on Secret Create" to Enabled globally. The rotation fires immediately after the secret is saved — before you've mapped any dependencies. What is the likely outcome?
✓ Correct. Secret Server has no knowledge of dependencies until you explicitly map them. A rotation without mapped dependencies changes only the AD password and the vault — Windows services and scheduled tasks continue using the now-stale password, causing authentication failures. This is one of the most common causes of post-rotation outages. Always complete dependency mapping (Chapter 04) before enabling automatic rotation.
Mapping Account
Dependencies
The Most Critical Configuration Step
Unmapped dependencies are the primary cause of PAM-related outages. Every Windows service, IIS application pool, scheduled task, or COM+ application running under this account must be mapped before the first automated rotation occurs. This chapter covers how to find and map all of them.
Windows Services
Services with "Log on as" configured to a domain account. Password stored in the Windows Services Control Manager (SCM). Secret Server updates SCM directly on rotation.
IIS Application Pools
Pools with identity type "Custom Account." Password stored in the IIS configuration (applicationHost.config). SS writes the new password to IIS and recycles the pool.
Scheduled Tasks
Tasks with "Run As" set to a domain account. Credential stored in the Windows Credential Manager on the host. SS uses the Task Scheduler API to update the stored credential.
COM+ / DCOM Applications
Older middleware components with a configured identity. Less common in modern environments but present in legacy infrastructure. SS uses the COM+ catalog API.
Interactive Dependency Mapper — Practice Tool
Dependency Register — svc_sqlprod01 @ CORP.CONTOSO.COM
No Windows Services mapped yet. Add dependencies above.
No IIS Application Pools mapped yet.
No Scheduled Tasks mapped yet.
No other dependencies mapped yet.
Total dependencies mapped: 0
Secret Server Dependency Types Reference
| Dependency Type | SS Template Name | Required Rights on Target | Restart Behavior |
|---|---|---|---|
| Windows Service | Windows Service | Local Admin or Service Control Manager rights | Service is stopped, credential updated, service restarted |
| IIS Application Pool | IIS App Pool | Local Admin on IIS host | Pool is stopped, credential updated, pool started |
| Scheduled Task | Scheduled Task | Local Admin or Task Scheduler access | Task is paused, credential updated — does NOT restart task |
| COM+ Application | Windows COM+ | Local Admin | Application stopped, updated, restarted |
| PowerShell Script | PowerShell Script | WinRM / remote execution rights | Custom — defined by the script |
| SSH Command | SSH | SSH access to host | Custom command sequence |
Before First Rotation: Dependency Verification Checklist
(1) All Windows services running under this account are mapped. (2) All IIS app pools are mapped. (3) All scheduled tasks on all hosts are mapped. (4) Test rotation in a non-production environment first. (5) Confirm the PAM privileged account (svc_delinea_rpc) has local admin on all dependency hosts. (6) Schedule the first production rotation during a defined maintenance window.
After adding dependency mappings in Secret Server, you trigger a manual test rotation. The rotation succeeds and the vault password updates. However, one Windows service on PROD-SQL02 fails to start after the rotation. What is the most likely cause?
✓ Correct. The dependency update for Windows services requires the Delinea privileged account to have local administrator rights on every host where a dependency is mapped. If the account lacks rights on one host, the AD password changes but the Service Control Manager on that host retains the old credential — causing the service to fail authentication on restart. Always verify the privileged account's local admin rights across all dependency hosts before the first rotation.
Configuring
Heartbeat
What Heartbeat Detects
Heartbeat periodically authenticates to the target system using the vaulted credential. If authentication fails, it means the password was changed outside of Secret Server — either by an admin, a script, or an attacker. This is your primary control for detecting unauthorized credential changes.
Out-of-Band Change Alert
If someone resets the AD password manually (ADUC, PowerShell, etc.), heartbeat will detect the mismatch within its configured interval and raise an alert — before the next rotation cycle.
Continuous Validation
Even without a rotation event, heartbeat confirms the vaulted credential still works. Catches account lockouts, disablements, and unexpected domain policy changes.
Compliance Evidence
Heartbeat logs provide auditable proof that credentials were continuously validated — a key requirement for PCI-DSS, SOC 2, and NIST 800-53 controls.
Heartbeat Configuration
Heartbeat Settings — Per Secret
Secret → Security Tab → Heartbeat section
Enable Heartbeat
Activates periodic credential validation for this secret. Should be ON for all service accounts without exception.
4-hour intervals balance detection speed against system load. For Tier-0 accounts (DA, schema admin service accounts), use 1-hour intervals.
"Alert Only" is recommended for initial rollout. Escalate to "Disable Checkout" once your team is comfortable with the alert volume.
Run Heartbeat After Password Change
Forces a heartbeat check immediately after every rotation. Confirms the rotation was successful before the next scheduled check. Strongly recommended.
Alert on Failure via Email
Sends email to the secret owner and PAM admin distribution list on heartbeat failure. Requires SMTP configuration.
Create Incident on Failure (ITSM Integration)
If ServiceNow or similar ITSM is integrated, automatically opens a Priority 2 incident on heartbeat failure. Enables SLA tracking.
Live Heartbeat Simulator
Heartbeat Monitor — svc_sqlprod01
Monitoring Active
--:--:-- --/--/----
INFO
Heartbeat monitor initialized. Use controls above to simulate events.
0
Successful Checks
0
Failures Detected
0
Rotations Triggered
100%
Credential Uptime
Heartbeat Failure Response Runbook
01
Acknowledge the Alert — Don't Rotate Immediately
A heartbeat failure means the vaulted password doesn't match what's in AD. Immediately triggering a rotation will write the vaulted (now-wrong) password to the vault and rotate to a new one — potentially breaking services if the AD change was intentional and already applied to services.
02
Determine the Source of the Password Change
Check AD audit logs (Event ID 4723 = self-change, 4724 = admin reset) to identify who changed the password and when. If change was authorized (emergency reset by the app team), obtain the new password from them.
# Search Security log for password change events on a specific account Get-WinEvent -ComputerName dc01 -FilterHashtable @{ LogName = 'Security' Id = 4723, 4724 # 4723=self, 4724=admin reset StartTime = (Get-Date).AddDays(-7) } | Where-Object {$_.Message -match 'svc_sqlprod01'} | Select-Object TimeCreated, Id, Message | Format-List
03
Remediate — Resync the Vault or Escalate
If authorized change: Update the secret with the new current password. Heartbeat will pass on next check. Schedule a rotation through Secret Server to bring it back under full management.
If unauthorized change (potential breach): Escalate to security. Do not simply resync. Treat as a security incident — investigate who changed it, review all systems this account touches, and follow your incident response playbook.
If unauthorized change (potential breach): Escalate to security. Do not simply resync. Treat as a security incident — investigate who changed it, review all systems this account touches, and follow your incident response playbook.
04
Document and Prevent Recurrence
After resolution, add a note to the secret documenting the incident. If the change was authorized but done outside SS, work with the team to require all future changes go through Secret Server. Consider adding the account to an AD audit policy with real-time SIEM alerting for password change events.
Heartbeat fails on svc_adconnect at 02:14 AM. AD audit logs show Event ID 4724 (admin-initiated reset) at 02:10 AM, initiated by helpdesk\admin01 — an account with no documented access to that service account. What is the correct classification and first action?
✓ Correct. A helpdesk account resetting a sensitive identity sync service account (Azure AD Connect) at 2 AM without documented authorization is a significant anomaly. This is the scenario heartbeat is designed to catch. Option D is tempting but wrong — rotating immediately destroys the forensic state and could cause further disruption. Option A is dangerous — treating this as routine ignores a clear red flag. Escalate, investigate, then remediate.
Module 04 Complete
You've walked through the complete end-to-end lifecycle for bringing a service account under PAM management — from template design and initial vaulting through rotation automation, dependency mapping, and continuous heartbeat validation. These five chapters form the operational foundation for every service account your organization vaults in Delinea Secret Server.