Privileged Access Management

Automated Credential
Rotation

vs. Manual Processes — A Comparative Lab

Understand why manual credential rotation creates organizational risk, then walk through hands-on simulations of Secret Server's automatic password changer for Windows, Linux, SQL Server, and network devices — including failure handling and retry logic.

Modules5
Est. Time45 min
LevelIntermediate
Lab Exercises4
COURSE PROGRESS
0%
The Case for Automation

Manual credential rotation sounds manageable — until you examine what actually happens in production environments under staffing pressures, competing priorities, and zero-day urgency. The risks are systemic, not accidental.

đŸ—“ī¸
Infrequent Rotation
Without enforcement, tickets pile up. Passwords set 18 months ago remain active. Security policies become aspirational, not operational.
CRITICAL
âš ī¸
Human Error
Copy-paste errors, wrong target systems, skipped dependent services — each manual step is a failure vector. One mistake can lock out production systems.
HIGH
đŸ–ī¸
Rotation Gaps
Who rotates credentials when the responsible admin is on PTO? In most orgs, nobody does. Staff absence creates predictable, exploitable windows.
HIGH
🔍
No Auditability
Spreadsheets and runbooks leave no forensic trail. When was this password last changed? By whom? Incident response starts blind.
MEDIUM
Side-by-Side Comparison

How manual and automated rotation compare across key operational dimensions.

Dimension
⚠ Manual Rotation
✓ Automated (Secret Server)
Rotation Frequency
Ad hoc; quarterly at best
Policy-enforced; hourly if required
Dependent Service Update
Manual, often forgotten
Auto-propagated to all dependents
Staff Dependency
Blocked when key staff absent
Zero human dependency
Audit Trail
None / ad hoc spreadsheet
Immutable timestamped log
Error Rate
5–15% of manual rotations
<0.1% (system-verified)
Compliance Evidence
Manual screenshot / attestation
Auto-generated compliance reports
Breach Response Time
Hours to days
Seconds (immediate rotation)
Scale
Breaks at ~50 accounts
Unlimited — tens of thousands
⚡
Verizon DBIR Finding: Over 80% of hacking-related breaches involve stolen or reused credentials. Long-lived static credentials dramatically increase exposure windows. Automated rotation directly shrinks the attack surface.
Audit Trail Demo

Automated rotation generates a forensically complete, tamper-evident record of every action. This is what incident responders see — vs. nothing with manual processes.

TIMESTAMPSECRETEVENTPERFORMED BYRESULT
2025-06-14 02:00:01svc_iis_prodAuto-rotation triggered (policy)SystemSUCCESS
2025-06-14 02:00:03svc_iis_prodPassword changed on ADSystemSUCCESS
2025-06-14 02:00:05svc_iis_prodIIS AppPool credential updatedSystemSUCCESS
2025-06-14 02:00:06svc_iis_prodVerification heartbeatSystemVERIFIED
2025-06-07 02:00:01svc_iis_prodAuto-rotation triggered (policy)SystemSUCCESS
2025-05-31 02:00:01svc_iis_prodAuto-rotation triggered (policy)SystemFAILED
2025-05-31 02:03:01svc_iis_prodRetry #1 (wait 3 min)SystemSUCCESS
Windows Account Rotation

Secret Server's Windows password changer communicates with Active Directory via LDAP/S to rotate local and domain accounts, then verifies the change and updates all dependent secrets and services automatically.

â„šī¸
Supported Account Types: Domain service accounts (AD), local admin accounts, Windows scheduled task accounts, IIS application pool identities, and Windows service logon accounts. All can be rotated and verified in a single workflow.
How the Password Changer Works
1
Policy-Triggered Initiation
Secret Server's rotation policy fires based on the configured schedule (e.g., every 30 days, or immediately on checkout expiry). The engine identifies all secrets due for rotation and queues them. For Windows domain accounts, it selects the privileged changer account with rights to reset passwords in the target OU.
2
Generate New Password
A cryptographically random password is generated according to your complexity template (length, character sets, exclusions). The new credential is staged internally — not yet applied anywhere — until every downstream dependency is accounted for.
3
LDAP/AD Password Reset
Using the privileged changer account, Secret Server connects to a Domain Controller via LDAPS (port 636) and executes the SetPassword operation on the target account object in AD. No PowerShell scripts are left behind on the target system.
4
Update Dependent Services
Any Windows Services, Scheduled Tasks, IIS Application Pools, or COM+ Applications registered as dependents in Secret Server are automatically updated with the new credential using the Windows Service Control Manager API and IIS admin APIs. No manual restart coordination required.
5
Heartbeat Verification
Secret Server attempts an authenticated connection using the new credential to verify the change was applied correctly. If the heartbeat fails, the rotation is marked as failed, the old credential is preserved in the vault (so nothing breaks), and alerts fire. No credential is ever committed without verification.
Lab Exercise — Windows Domain Account Rotation

Simulate rotating the CORP\svc_webapp service account. Watch the rotation steps execute and observe the heartbeat verification.

📋
Policy
Trigger
🔑
Generate
Password
đŸĸ
LDAP/AD
Reset
âš™ī¸
Update
Services
💓
Heartbeat
Verify
✅
Committed
to Vault
Secret Server — Rotation Engine Log
# Ready to simulate Windows domain account rotation # Click "Run Rotation" to begin   SS> status Secret: CORP\svc_webapp Last Rotated: 30 days ago Policy: Rotate every 30 days Status: ROTATION DUE  
Linux & SQL Server Rotation

SSH-based rotation for Linux accounts and SQL Server service account rotation each follow distinct protocols. Secret Server handles both natively, with per-type password changers configurable in the Admin panel.

🐧 Linux Accounts
SSH PASSWORD CHANGER

Secret Server SSHs into the target host using the privileged changer account, then invokes passwd or chpasswd depending on the template. Sudoers-based elevation is supported when direct root access is restricted.

✓ Root, service, and regular accounts
✓ SSH key rotation (alongside password)
✓ Sudo-based privilege escalation
✓ Post-rotation verification via SSH login
đŸ—„ī¸ SQL Server Accounts
SQL AUTHENTICATION CHANGER

For SQL Server logins, Secret Server connects via the SQL authentication changer (using ADO.NET), executes ALTER LOGIN, and verifies the new credential. Windows-authenticated service accounts are handled via AD rotation.

✓ SQL authentication logins
✓ sa account (with caution — best disabled)
✓ Application connection string updates
✓ Linked server credential propagation
Lab — Linux Root Account Rotation via SSH

Simulate rotating the root@db-prod-01.corp.local account. The changer connects via SSH, changes the password, and verifies with a new SSH session.

SSH Rotation — db-prod-01.corp.local
# Click "Run Linux Rotation" to simulate   SS> secret get --id 1042 Name: root@db-prod-01 Type: Unix Account (SSH) Last Rotated: 45 days ago Status: OVERDUE (policy: 30d)  
Lab — SQL Server Login Rotation

Simulate rotating appuser@SQLPROD01 via T-SQL. Secret Server uses an ADO.NET connection with an elevated SQL login to execute ALTER LOGIN.

SQL Rotation — SQLPROD01
# Click "Run SQL Rotation" to simulate   SS> secret get --id 2088 Name: appuser@SQLPROD01 Type: SQL Server Login Last Rotated: 22 days ago Status: OK (8 days until rotation)  
Network Device Rotation

Routers, switches, firewalls, and load balancers each have different management protocols. Secret Server includes purpose-built changers for the most common network device vendors, plus a scriptable custom changer for anything else.

🌐
Cisco IOS Router
SSH / TELNET CHANGER
Connects via SSH, enters enable mode, executes username global config commands.
SUPPORTED
đŸ”Ĩ
Palo Alto Firewall
REST API CHANGER
Uses PAN-OS REST API to update local administrator and service account credentials without CLI session.
SUPPORTED
âš–ī¸
F5 BIG-IP
TMSH / ICONTROL
iControl REST or TMSH shell commands update local and partition admin accounts on BIG-IP systems.
SUPPORTED
📡
Custom Device
SCRIPT-BASED CHANGER
PowerShell or SSH expect scripts let you build rotation for any vendor using Secret Server's custom password changer framework.
SCRIPTABLE
Lab — Network Device Rotation Simulation

Select a device type above, then run the rotation simulation to see the protocol-specific commands Secret Server executes.

Network Device Rotation — Cisco IOS
# Select a device type and click Run to simulate   SS> secret get --id 3001 Name: enable@core-rtr-01.corp.local Type: Cisco IOS (SSH) Last Rotated: 90 days ago Status: OVERDUE  
âš ī¸
Network Device Best Practice: Always configure a secondary "break-glass" local account on network devices that is rotated separately and stored in an offline vault. Never rotate the only management credential without a verified backup path — device misconfiguration can lock out remote management entirely.
Failure Handling & Retry Logic

Rotation will occasionally fail — the target system might be unreachable, the changer account may lack permissions, or a service dependency might be locked. What separates robust PAM from fragile automation is graceful failure: alert without breaking, retry intelligently, and never leave credentials in an unknown state.

Failure Response Flow
âš™ī¸
Rotation Attempt #1
Secret Server initiates the rotation against the target system. Times out after the configured threshold (default 30s).
❌
Failure Detected
Connection refused, authentication error, or timeout. The existing password in vault is preserved — nothing is changed on the target. The secret is NOT updated.
🔔
Alert Triggered
Email/Slack/Teams notifications fire to the secret owner, the assigned group, and optionally a SIEM via syslog. The failure is written to the audit log with full error detail.
âąī¸
Retry Wait (Exponential Backoff)
Wait period before retry: 3 min → 10 min → 30 min → 2 hr. Prevents hammering a degraded system and triggering account lockout policies.
🔄
Retry Attempts (up to 3)
Each retry uses a fresh connection. If the target system recovers, the rotation completes transparently. Success clears the failure flag and updates the audit log.
🚨
Max Retries Exceeded — Escalate
After all retries exhausted, the secret is marked "Rotation Error" in the dashboard. A high-priority ticket can be auto-created in ServiceNow/Jira. Manual intervention is queued.
Live Failure Simulation

Simulate a rotation failure scenario. The first two attempts will fail (target unreachable), then the third attempt will succeed — demonstrating retry logic and alert generation.

--:--:--INFOAlert log ready. Click "Simulate Failure" to begin.
Configuring Retry Settings
Secret Server — Remote Password Changing Configuration
# Admin > Remote Password Changing > Configure   Setting Enable Remote Password Changing = True Setting Days Until Expiry Warning Email = 14 Setting Minutes Between Retries = 3, 10, 30, 120 Setting Max Rotation Attempts = 3 Setting Notify on Failure = True (Email + Webhook) Setting Enable Heartbeat = True Setting Heartbeat Interval (minutes) = 60 Setting Create Ticket on Max Failure = True (ServiceNow)   [Config saved and active]
Knowledge Check

Test your understanding before completing the module.

1. When Secret Server's rotation attempt fails, what happens to the existing password stored in the vault?
A
It is immediately replaced with the new password to prepare for retry
B
It is preserved — the vault is not updated until rotation is verified as successful
C
It is deleted and the account is locked pending manual review
D
It is replaced but a backup copy is created in a recovery folder
2. Which of the following is the correct description of Secret Server's heartbeat function?
A
It sends a ping to check if the target host is online before rotation
B
It monitors CPU and memory on the target server
C
It periodically verifies that stored credentials can still authenticate to the target system
D
It schedules rotation on a set interval by counting time since last change
3. What is the primary risk of manual credential rotation during staff absence?
A
Rotation will proceed automatically but without logging
B
Passwords become more complex to satisfy policy
C
Rotation simply doesn't happen, leaving credentials static and vulnerable for the duration of the absence
D
Another staff member rotates credentials manually, creating duplicate entries