Admin accounts training

🔑 The Core Concept

A "-a account" is a dedicated administrative account assigned to an individual alongside their standard user account. Named by convention — e.g., jsmith-a or john.smith-a — these accounts are used exclusively for privileged tasks, keeping admin activity separated from day-to-day operations.

🎯 Why Separate Admin Accounts?

🧱

Least Privilege Enforcement

Users operate from a standard account daily. The "-a" account is only invoked for tasks that genuinely require elevated privileges — minimizing the attack window.

🔍

Granular Audit Trails

All privileged actions are logged under the named "-a" account, giving you clear, attributable audit records that separate admin work from normal user activity.

🛡️

Credential Isolation

If a standard user account is phished or compromised, the attacker does not automatically gain admin rights — the "-a" credential is a separate, vaulted secret.

📋

Compliance Alignment

Frameworks like CIS, NIST, and ISO 27001 require separation of admin and standard accounts. "-a" accounts satisfy this control and simplify audit evidence.

🚨

Rapid Incident Response

When a compromise is detected, a single "-a" account can be disabled or its secret rotated instantly — without impacting the user's standard account or other services.

👤

Named Accountability

Unlike generic admin accounts (e.g., administrator), every "-a" account maps back to a specific individual — enabling precise accountability for every privileged action.

⚖️ "-a" Account vs. Standard Account — At a Glance

Attribute	Standard Account (jsmith)	Admin Account (jsmith-a)
Purpose	Day-to-day tasks, email, apps	System administration, privileged changes
Privilege Level	Standard user rights	Domain admin, local admin, elevated rights
Used for browsing?	✓ Yes	✗ Never
Vaulted in Secret Server?	Optional	✓ Mandatory
Password Rotation	User self-service or AD policy	Automated via Secret Server policy
Session Recording	Typically off	✓ Enabled
MFA Required	Standard MFA	✓ Stepped-up MFA
Checkout Required?	No	✓ Via Secret Server

⚠️ Common Risks Without "-a" Account Governance

Admin Credential Exposure via Email & BrowserHigh Risk

▾

Using an admin account for email exposes credentials to phishing, malicious attachments, and browser-based exploits
Browser password managers may silently cache admin credentials, creating persistent exposure
Web browsing with admin privileges means any drive-by download gains immediate elevated access
Secret Server mitigates this by keeping admin credentials off the endpoint entirely — checked out only when needed

Shared & Generic Admin AccountsHigh Risk

▾

Shared accounts like administrator or sysadmin make it impossible to attribute actions to specific individuals
When shared credentials are compromised, all users must be notified and impacted systems assessed
Password changes for shared accounts require coordination across teams, leading to rotation delays
"-a" accounts with Secret Server eliminate sharing — each admin has their own vaulted, rotated credential

Stale Admin Rights After Role ChangeMedium Risk

▾

When admins change roles or leave, their "-a" account may remain active with full privileges intact
Without a vault, these orphaned admin accounts are difficult to discover and remediate
Secret Server access reviews and discovery scans surface these quickly and enable rapid deprovisioning
Checkout policies ensure unused admin accounts generate no activity — making dormancy visible

ℹ️ What Does "Vaulting" Mean?

Vaulting an account means storing its credentials — username, password, any associated keys — inside Secret Server's encrypted vault. From that point on, no user ever needs to know the actual password. They check it out through the vault, use it for their task, and the password is automatically rotated afterward.

🏗️ Recommended Vault Structure for "-a" Accounts

Secret Server — Folder Hierarchy

📁 Administrative Accounts
└── 📁 Domain Admins
    ├── 🔐 jsmith-a  (John Smith — Domain Admin)
    ├── 🔐 mjones-a  (Mary Jones — Domain Admin)
    └── 🔐 tlee-a    (Tom Lee — Domain Admin)
└── 📁 Local Admins
    ├── 🔐 jsmith-a  (Local Admin — Server Group A)
    └── 🔐 mjones-a  (Local Admin — Server Group B)
└── 📁 Break-Glass Accounts
    └── 🔐 emergency-admin  (Dual-approval, session recorded)

📋 Secret Template Configuration

Recommended Template Fields for "-a" AccountsConfig

▾

Username: The full domain\jsmith-a format — ensures no ambiguity during checkout or RPC calls
Password: Masked field — users never see it; hooks and launchers inject it automatically
Domain: Target Active Directory domain for automated password change
Owner: Named individual this "-a" account belongs to — enables access reviews
Notes: Systems and scope this account has access to — living documentation
Expiry Date: Optional — trigger alerts when an account approaches decommission date

Access Control: Who Can Check Out?RBAC

▾

Owner permission: Assigned to the named individual (e.g., jsmith has Owner on jsmith-a secret)
View permission: Manager may view for audit purposes — password still masked
Edit permission: Reserved for PAM administrators only
Checkout: Enabled on the secret — forces single-user access and triggers rotation on checkin
Dual control: Optional for high-sensitivity accounts — requires a second approver before checkout
Access requests: Temporary access grants with reason capture and auto-expiry

Session Monitoring & LaunchersRecording

▾

Secret Server launchers (RDP, SSH, SQL) inject credentials automatically — user never touches the password
Session recording captures a full video audit trail of every privileged session tied to the "-a" account
Keystroke logging records all commands typed during elevated sessions for forensic capability
Session termination can be triggered remotely by a Security team member in real time
Recorded sessions are stored in encrypted format and linked to the checkout event and ticket number

✅ Vaulting Onboarding Steps

1

Create the "-a" account in Active Directory

Provision jsmith-a in the correct OU, assign required group memberships, and set an initial complex password. Disable interactive logon rights if this account will only be used through Secret Server launchers.

2

Create the Secret in the correct folder

Select the Active Directory Account template. Fill in username, initial password, domain, and owner. Save to the appropriate folder (Domain Admins, Local Admins, etc.).

3

Enable Checkout and configure checkout interval

Set the maximum checkout duration (typically 1–4 hours for admin tasks). Enable "Change Password on Checkin" to ensure automatic rotation after every use. Enable "Limit Checkout" for single-user access.

4

Assign the Password Change Policy

Link the secret to a Remote Password Changer and assign a Password Change Policy template (covered in Section 03). Secret Server will now own and rotate this credential.

5

Configure Hooks (Pre/Post)

Attach Pre-Checkout and Post-Checkin hooks to handle privilege elevation workflows, notification triggers, and any dependent system updates (covered in depth in Section 04).

6

Notify the account owner and decommission local knowledge

Communicate to jsmith that their "-a" password is now managed by Secret Server. They should no longer store or know the password — access is through checkout only. Rotate the initial password immediately.

✓ Why Automated Rotation Matters

Manual password changes for admin accounts are inconsistent, slow, and often skipped. Secret Server automates the entire lifecycle — generating cryptographically random passwords, pushing them to Active Directory, and logging every change — eliminating the human gap.

⚙️ Password Change Policy — Key Components

🎲

Password Generator Rules

Define minimum length (20+ chars recommended), required character classes (upper, lower, digit, symbol), and character exclusion lists for legacy system compatibility.

⏱️

Scheduled Rotation

Set a maximum age (e.g., rotate every 30/60/90 days) regardless of checkout activity. Ensures even rarely-used "-a" accounts stay fresh.

🔄

Change on Checkin

Trigger immediate rotation every time an "-a" account is checked back in — guaranteeing that each checkout uses a unique, previously-unknown password.

🔗

Remote Password Changer (RPC)

The RPC is the engine that actually pushes the new password to Active Directory, local SAM, or other target systems — fully automated with no manual steps.

📡

Heartbeat Verification

Secret Server periodically verifies that the stored credential still matches what's on the target system. Mismatches trigger alerts and can auto-remediate.

🔔

Failure Alerting

If a password change fails — due to network issues, locked accounts, or policy conflicts — Secret Server immediately alerts the admin team with full diagnostic context.

🛠️ Interactive Policy Builder

Configure a sample password change policy for "-a" accounts and see the resulting policy summary.

Password Change Policy Configuration Secret Server — Policy Editor

Rotation Trigger

Max Password Age

Password Length

Character Complexity

Heartbeat Interval

On Failure

Remote Password Changer

⚠️ Policy Design Considerations

Dependency Awareness Before RotationCritical

▾

Some "-a" accounts may also be used as service account dependencies — check before enabling aggressive rotation
Use Secret Server's dependency mapping to identify all Windows services, tasks, or IIS pools using this credential
Configure dependency changers alongside the RPC — Secret Server will update all dependents automatically after rotation
Test dependency changers in a staging environment before deploying to production "-a" accounts

Legacy System Password ConstraintsCompatibility

▾

Some legacy systems cap password length at 14 or 16 characters — configure a custom generator for these secrets
Systems that don't support symbols require an alphanumeric-only character set in the policy
Use Secret Server's "Custom" character set option to define exact allowed characters per target system
Document all constraint exceptions in the secret Notes field for future reference and audit purposes

⚡ The Power of Hooks

Secret Server hooks are scripts or API calls executed automatically at defined lifecycle points of a secret checkout. For "-a" accounts, this enables Just-In-Time (JIT) privilege elevation — the account has zero privileges at rest, and full admin rights are granted only for the duration of an active, approved checkout.

🔗 Hook Types Explained

⬆️

Pre-Checkout Hook

Runs before the credential is handed to the user. Used to add the account to privileged groups, enable the AD account, update firewall rules, or create a time-limited permission grant.

⬇️

Post-Checkin Hook

Runs after the user checks the secret back in. Used to remove the account from admin groups, disable the account, revoke firewall rules, and clean up any temporary access grants.

🔔

Pre-Rotation Hook

Fires before a password rotation event. Used to notify dependent systems, gracefully close sessions, or update configuration management databases before the credential changes.

✅

Post-Rotation Hook

Fires after a successful password change. Used to update SIEM/monitoring tools with the rotation event, confirm dependent systems accepted the new credential, and send audit notifications.

🎮 Interactive Hook Execution Simulator

Simulate a complete JIT privilege elevation flow for a "-a" account checkout using Secret Server hooks.

⚡ Hook Execution Engine — jsmith-a Checkout

Pre-Checkout

Add to Domain Admins Group

PowerShell adds jsmith-a to "Domain Admins" AD group via LDAP call

→

Active Session

Credential Checked Out

User receives credential via launcher. Session is recorded. Timer starts.

→

Post-Checkin

Remove from Domain Admins

PowerShell removes jsmith-a from group. Account returns to zero privilege state.

[ Simulation idle — press Run to execute ]

📝 Hook Script Examples

Pre-Checkout Hook — PowerShell: Add to Domain Admins

# Parameters injected by Secret Server
$username   = "$[1]$Username"   # From secret field
$domain     = "$[1]$Domain"     # From secret field
$adminGroup = "Domain Admins"

# Import AD module and add account to group
Import-Module ActiveDirectory
Add-ADGroupMember -Identity $adminGroup -Members $username

# Log the elevation event
Write-Output "[ELEVATED] $username added to $adminGroup at $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"

Post-Checkin Hook — PowerShell: Remove from Domain Admins

$username   = "$[1]$Username"
$adminGroup = "Domain Admins"

Import-Module ActiveDirectory
Remove-ADGroupMember -Identity $adminGroup -Members $username -Confirm:$false

# Trigger password rotation immediately
Write-Output "[DELEVATED] $username removed from $adminGroup at $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
# Secret Server auto-rotates password after this hook completes

🏗️ Advanced Hook Use Cases

ITSM Ticket Validation Before CheckoutGovernance

▾

Pre-checkout hook calls ServiceNow / Jira API to verify an open, approved change ticket exists
If no valid ticket is found, the hook returns a failure code — Secret Server blocks the checkout
Ticket number is captured and stamped against the checkout audit record automatically
This creates a closed-loop governance model: no admin access without an approved change request

Firewall Rule Provisioning & CleanupNetwork

▾

Pre-checkout hook creates a time-scoped firewall rule allowing RDP/SSH from the admin's workstation to the target
Post-checkin hook removes the rule immediately — the network path closes as soon as the session ends
Supports integration with Palo Alto, Cisco ASA, and AWS Security Groups via their APIs
Eliminates the need for always-open admin network paths — dramatically reduces lateral movement risk

SIEM / Monitoring NotificationObservability

▾

Pre-checkout hook sends a Syslog event to your SIEM (Splunk, Sentinel) marking the start of a privileged session
Post-checkin hook sends the session end event — enabling precise privileged session duration tracking in your SIEM
Hooks can include metadata: username, target system, ticket number, session recording link
Enables real-time alerting in SIEM if an admin session exceeds expected duration (potential incident indicator)

⚠️ Hook Failure Handling

Always configure a failure behavior for critical hooks. If a Pre-Checkout hook fails (e.g., can't reach AD), Secret Server can be configured to either (a) block the checkout entirely — safest for security — or (b) allow checkout with an alert. For elevation hooks, option (a) is strongly recommended.

🔄 Complete "-a" Account Lifecycle

Full Lifecycle — Provisioning to Decommission

PROVISION
  ├── Create jsmith-a in Active Directory (correct OU)
  ├── Vault credential in Secret Server (AD Account template)
  ├── Assign ownership + access controls (RBAC)
  ├── Attach Password Change Policy (RPC + rotation rules)
  └── Configure Pre/Post hooks (JIT elevation)

DAILY OPERATION
  ├── Admin requests checkout from Secret Server
  ├── Pre-checkout hook: adds to Domain Admins group
  ├── Launcher opens RDP/SSH — session recorded
  ├── Admin completes task, checks secret back in
  ├── Post-checkin hook: removes from admin group
  └── Password rotated automatically — credential invalidated

PERIODIC GOVERNANCE
  ├── Quarterly: Review all -a account checkouts (audit log)
  ├── Monthly: Verify heartbeat status — all green
  ├── Bi-annual: Access review — confirm ownership still valid
  └── Annual: Policy review — update complexity/rotation rules

DECOMMISSION
  ├── Disable -a account in Active Directory
  ├── Expire secret in Secret Server (locks checkout)
  ├── Export audit log for HR / compliance records
  └── Delete AD account after retention period

✅ Best Practice Checklist

Check each item as your organization implements it. Items are saved for this session.

Every administrator has a dedicated -a account — no shared admin credentials in use

All -a accounts are vaulted in Secret Server — no admin knows their own password

Password Change Policy applied: "Change on Checkin" + scheduled rotation (max 60 days)

Heartbeat monitoring active — all secrets showing green status; failure alerts configured

JIT elevation hooks deployed — -a accounts have zero standing admin group membership at rest

Session recording enabled for all -a account launcher sessions (RDP and SSH)

Quarterly access review process in place — ownership confirmed, dormant accounts deprovisioned

Decommission process documented — HR offboarding triggers automatic -a account expiry in vault

What Are "-a" Accounts?

Vaulting "-a" Accounts
in Secret Server

Password Change Policies

Hooks & On-the-Fly
Privilege Elevation

End-to-End Workflow
& Best Practices

Knowledge Check

Bert Blevins