Add To Vault
Add to Vault automation enables Hydden Discovery to automatically onboard discovered privileged accounts to Privileged Access Management (PAM) systems. Use classification-triggered workflows to vault accounts as soon as they're discovered, reducing manual administrative overhead and improving security posture.
Overview
Add to Vault workflows automatically create or discover accounts in PAM systems when classification rules are applied. This closed-loop integration enables:
- Automatic Account Onboarding: Vault newly discovered privileged accounts without manual intervention
- Classification-Based Vaulting: Trigger vaulting based on account classification rules
- Multi-PAM Support: Integrate with CyberArk Privilege Cloud, CyberArk Self-Hosted, and BeyondTrust Password Safe
- Rate Limiting: Controlled account creation (30 accounts per minute per collector) to prevent overwhelming PAM systems
- Template-Based Configuration: Use variables to dynamically populate vault fields from discovered account data
Supported PAM Systems
Hydden Discovery integrates with the following PAM platforms:
CyberArk
CyberArk Privilege Cloud (SaaS):
- REST API integration via
/PasswordVault/API/Accounts - Discovered accounts API via
/api/discovered-accounts - Account reconciliation and password management
- Platform and safe-based organization
- REST API integration via
CyberArk Self-Hosted (On-Premises):
- REST API integration (same endpoints as Cloud)
- Credential Provider (CCP) integration for password retrieval
- Platform and safe-based organization
- Custom platform support
BeyondTrust
- BeyondTrust Password Safe:
- REST API integration via
/BeyondTrust/api/public/v3/ - Managed accounts and managed systems
- Automatic password management
- Password check-out and check-in workflows
- REST API integration via
Prerequisites
Before configuring Add to Vault workflows:
- PAM System Integration: Configure CyberArk or BeyondTrust integration in Hydden Discovery (see CyberArk Integration or BeyondTrust Integration)
- PAM Credentials: Create credentials for PAM API access in Configuration > Settings > Credentials
- Classification Rules: Configure classification rules to identify accounts that should be vaulted (see Classification Rules)
- PAM Platforms: Ensure target platforms (e.g., Windows Domain, Unix) and safes/vaults exist in the PAM system
- Permissions: Verify PAM API credentials have permission to create accounts and access target safes
Add to Vault Provider Configuration
To add an Add to Vault provider:
- In Hydden, navigate to Configuration > Automate.
- On the Providers tab, click + Add New.
- From the Type drop-down, select Add To Vault.
- For Name, enter a descriptive provider name (e.g., "CyberArk Production Vault", "BeyondTrust PAM").
- For Description, provide an optional description of the provider's purpose.
- From the Credential drop-down, select the pre-configured PAM integration credential:
- For CyberArk: Select the CyberArk API credential
- For BeyondTrust: Select the BeyondTrust API credential
- The credential type determines which PAM provider is used
- Click Save.
The provider references the configured PAM integration (CyberArk or BeyondTrust) via the credential type. All vault connection details (endpoints, authentication) are configured in the PAM integration settings.
Add to Vault Workflow Configuration
Add to Vault workflows are typically triggered by classification rules. When a classification is applied to an account, the workflow automatically vaults the account.
To create an Add to Vault workflow:
- In Hydden, navigate to Configuration > Automate.
- On the Workflows tab, click + Add New.
- For Name, enter a descriptive workflow name (e.g., "Auto-Vault Linux Root Accounts", "Vault Windows Admins to CyberArk").
- For Description, provide an optional workflow purpose description.
- From the Trigger drop-down, select Classification Added.
- From the Classification Rule drop-down, select the classification that should trigger vaulting:
- Add to Vault: Default classification for general vaulting
- Auto Add to CyberArk: Default classification for CyberArk-specific vaulting
- Custom classification rules you've created
- See Classification Rules for creating custom rules
- From the Action drop-down, select your configured Add to Vault provider (e.g., "Add to CyberArk Production").
- From the Select Vault Connection drop-down, select your configured PAM integration:
- Lists available CyberArk and BeyondTrust integrations
- Integration must match the provider's credential type
- Configure workflow fields based on your PAM system (see platform-specific sections below).
- Click Save.
- Toggle the workflow switch to on to activate it.
NOTE
Under Configuration > Identify > Classification Rules, verify that the classification rule has the Allow Workflow Trigger option checked. Without this, the workflow will not execute when the classification is applied.
Common Workflow Fields
The following fields are common across all PAM platforms:
| Field | Description | Required | Template Support |
|---|---|---|---|
| Username | Account username | Yes | Yes (typically {Principal.Name} or {Name}) |
| Account Name | Display name for the account in PAM | No | Yes (pre-populated with template) |
| System | Operating system type | Yes | No (select from dropdown) |
| Platform | PAM platform identifier | Yes | No (select from dropdown) |
| Safe / Vault | Target safe or vault name | Yes | Yes (can use variable for dynamic safe assignment) |
| Address | Target system address (hostname, IP, domain) | Yes | Yes (typically {Address} or domain name) |
| Password | Account password (optional) | No | Yes |
| Automatic Password Management | Enable CPM/automatic password rotation | No | N/A (checkbox) |
CyberArk Workflow Configuration
CyberArk-Specific Fields
| Field | Description | Example Value | Template Variable |
|---|---|---|---|
| Username | Account username | root, admin | {Principal.Name} or {Name} |
| Account Name | Display name in CyberArk | root@prod-server-01 | Pre-populated template |
| System | Operating system | Windows, Unix, Linux | Select from dropdown |
| Platform | CyberArk Platform ID | UnixSSH, WinDomain | Select from dropdown |
| Safe | CyberArk Safe name | Linux-Servers, Windows-Admins | {classification} or fixed value |
| Address | Target system address | prod-server-01.corp.local | {Address} or domain |
| Allow Automatic Password Management | Enable CPM | Checked/Unchecked | N/A |
CyberArk Platform Selection
CyberArk workflows require selecting a Platform ID that defines how CyberArk manages the account. Common platforms:
Unix/Linux:
UnixSSH: SSH-based Unix/Linux accountsUnixSSHKeys: Unix accounts with SSH key authenticationUnixViaSSHTunnel: Unix accounts accessed through SSH tunnel
Windows:
WinDomain: Windows domain accountsWinServerLocal: Local Windows server accountsWinDesktopLocal: Local Windows desktop accounts
Database:
Oracle: Oracle database accountsMSSQLServer: Microsoft SQL Server accountsMySQL: MySQL database accounts
Cloud:
AWS: AWS IAM accountsAzure: Azure service principalsGCP: Google Cloud service accounts
TIP
If your required platform isn't listed, create it in CyberArk first, then it will appear in the dropdown.
CyberArk Safe Assignment
You can use template variables to dynamically assign accounts to safes:
- Fixed Safe: Enter a safe name directly (e.g.,
Linux-Privileged-Accounts) - Dynamic Safe: Use classification variable (e.g.,
{classification}resolves to the classification name) - Custom Logic: Use other variables (e.g.,
{Platform}-Accountscreates platform-specific safes)
CyberArk Unix/Linux Additional Options
For Unix and Linux platforms, additional options are available:
- Use SUDO on Reconcile: Enable if the account requires sudo for password changes
- Fetch SSH Keys: Enable to retrieve SSH keys for the account
Example CyberArk Workflow
Auto-Vault Linux Root Accounts:
Name: Auto-Vault Linux Root Accounts
Trigger: Classification Added
Classification Rule: Linux Privileged
Action: Add to CyberArk Vault
Vault Connection: CyberArk Production
Username: {Principal.Name}
System: Unix
Platform: UnixSSH
Safe: Linux-Privileged-Accounts
Address: {Address}
Allow Automatic Password Management: CheckedBeyondTrust Workflow Configuration
BeyondTrust-Specific Fields
| Field | Description | Example Value | Template Variable |
|---|---|---|---|
| Username | Account username | root, administrator | {Principal.Name} or {Name} |
| Account Name | Display name in BeyondTrust | root@server-01 | Pre-populated template |
| System | Managed System identifier | System ID from BeyondTrust | Select from dropdown |
| Platform | Account type | Password, SSH Key | Select from dropdown |
| Address | Target system address | prod-server-01.corp.local | {Address} |
| AutoManagementFlag | Enable automatic password management | True/False | Checkbox |
BeyondTrust System Selection
BeyondTrust workflows require selecting a Managed System that represents the target server or device. Managed Systems must be pre-configured in BeyondTrust Password Safe before they appear in the dropdown.
To prepare BeyondTrust for auto-vaulting:
- In BeyondTrust Password Safe, create Managed Systems for target servers
- Configure system details (hostname, IP address, platform type)
- Set up auto-management policies
- Verify Managed Systems appear in Hydden workflow dropdown
BeyondTrust Password Management
BeyondTrust supports automatic password management:
- AutoManagementFlag: Enable to allow BeyondTrust to automatically rotate passwords
- Change Frequency: Configured in BeyondTrust (default: first of month at 23:30)
- Release Duration: 10 minutes default
- Max Release Duration: 60 minutes default
Example BeyondTrust Workflow
Auto-Vault Windows Administrator Accounts:
Name: Auto-Vault Windows Admins
Trigger: Classification Added
Classification Rule: Windows Privileged
Action: Add to BeyondTrust Vault
Vault Connection: BeyondTrust Password Safe
Username: {Principal.Name}
System: [Select Managed System]
Platform: Password
Address: {Address}
AutoManagementFlag: CheckedTemplate Variables for Vaulting
Add to Vault workflows support template variables from the Classification Added trigger. Common variables:
| Variable | Description | Example Value |
|---|---|---|
{Name} | Account name | root, administrator |
{Principal.Name} | Principal username | jsmith, admin_prod |
{Address} | System address | prod-server-01.corp.local |
{Platform} | Source platform | Linux, Windows, ActiveDirectory |
{Site} | Site identifier | prod-datacenter-01 |
{classification} | Classification name | Add to Vault, Linux Privileged |
{classification_id} | Classification rule ID | auto-vault-linux |
{Collector.name} | Collector name | Linux Prod Collector |
See Triggers for complete variable lists.
Variable Usage Examples
Dynamic Safe Assignment:
Safe: {Platform}-{classification}
Result: Linux-Privileged-AccountsAccount Name Template:
Account Name: {Principal.Name}@{Address}
Result: root@prod-server-01.corp.localAddress with Domain:
Address: {Address}.corp.example.com
Result: server01.corp.example.comRate Limiting
Add to Vault workflows include rate limiting to prevent overwhelming PAM systems with account creation requests:
- Default Rate: 30 accounts per minute per collector
- Scope: Rate limit applies per collector (multiple collectors can vault in parallel)
- Implementation: Token bucket algorithm with configurable rate
- Backpressure: Workflows wait when rate limit is reached, then resume
Rate Limit Behavior
When the rate limit is reached:
- Workflow Pauses: Add to Vault workflow waits for available tokens
- Queuing: Pending vault requests are queued in order
- Resumption: Workflow resumes when tokens are available
- No Failures: Rate limiting does not cause workflow failures
Rate Limit Configuration
Rate limits are configured at the system level and cannot be modified per workflow. Contact your Hydden administrator if rate limits need adjustment.
Classification-Triggered Auto-Vaulting
Auto-vaulting is triggered by classification rules. When an account matches a classification rule with Allow Workflow Trigger enabled, the workflow executes.
Classification Rule Requirements
For auto-vaulting to work:
- Classification Rule Exists: Create classification rule in Configuration > Identify > Classification Rules
- Allow Workflow Trigger: Enable Allow Workflow Trigger checkbox on the classification rule
- Workflow Configured: Create Add to Vault workflow with the classification as trigger
- Workflow Enabled: Toggle workflow to "on" state
Common Classification Patterns
Linux Root Accounts:
Classification Name: Linux Privileged
Pattern: Name = "root" AND Platform = "Linux"
Allow Workflow Trigger: CheckedWindows Local Administrators:
Classification Name: Windows Admin
Pattern: Name CONTAINS "admin" AND Platform = "Windows"
Allow Workflow Trigger: CheckedService Accounts:
Classification Name: Service Accounts
Pattern: Name STARTS WITH "svc_" OR Name CONTAINS "service"
Allow Workflow Trigger: CheckedSQL SA Accounts:
Classification Name: SQL SA
Pattern: Name = "sa" AND Platform = "MSSQL"
Allow Workflow Trigger: CheckedManual vs. Auto-Vaulting
Auto-Vaulting (Classification-Triggered)
Accounts are automatically vaulted when classification rules match:
- Trigger: Classification Added
- Execution: Automatic when classification is applied
- User Interaction: None required
- Use Case: Continuous discovery and vaulting of privileged accounts
Manual Vaulting (User-Initiated)
Users manually vault accounts from the Hydden Discovery UI:
- Trigger: User action in UI
- Execution: User selects accounts and initiates vaulting
- User Interaction: Required
- Use Case: Ad-hoc vaulting or exceptions to auto-vaulting rules
Workflow Execution and Monitoring
Execution Flow
- Account Discovered: Data source collection discovers account
- Classification Applied: Account matches classification rule
- Workflow Triggered: Add to Vault workflow is initiated
- Rate Limit Check: Workflow checks available token capacity
- Preprocessing: Account data is enriched with collector and entity metadata
- Template Rendering: Workflow fields are rendered with variable substitution
- API Call: PAM system API is called to create/discover account
- Result Logging: Success or failure is logged
Success Criteria
A vault operation is considered successful when:
- PAM API returns HTTP 200/201 status code
- Account is created or discovered in PAM system
- No API errors occur
Failure Handling
When a vault operation fails:
- Logged: Failure is logged with error details
- No Retry: Vault operations are not automatically retried (to prevent duplicate accounts)
- Manual Retry: Users can manually re-apply classification to retry
- Investigation: Check logs for error details (authentication, permissions, etc.)
Monitoring Workflows
Monitor vault workflow execution through:
- Hydden Discovery Logs: Check application logs for vault API calls and responses
- PAM System Logs: Review PAM audit logs for account creation events
- Workflow Status: Verify workflows are enabled and executing
- Classification Application: Confirm classifications are being applied to accounts
Common Use Cases
Continuous Privileged Account Discovery
Scenario: Automatically vault all newly discovered privileged accounts
Configuration:
- Classification: "Privileged Account" rule matching admin patterns
- Workflow: Auto-vault to CyberArk safe "Discovered-Privileged"
- Platform: Multiple platforms (Linux, Windows, SQL)
Benefit: Immediate vaulting of privileged accounts as they're discovered
Platform-Specific Vaulting
Scenario: Vault accounts to different safes based on platform
Configuration:
- Classification: Platform-specific rules (Linux Privileged, Windows Privileged)
- Workflows: Separate workflows for each platform
- Safe Assignment: Dynamic using
{Platform}-Privilegedvariable
Benefit: Organized account management by platform type
Compliance-Driven Vaulting
Scenario: Vault accounts that require compliance controls
Configuration:
- Classification: "Requires Compliance" rule based on business criteria
- Workflow: Auto-vault with automatic password management enabled
- PAM Policy: Enforced password rotation and access logging
Benefit: Automated compliance control application
Service Account Management
Scenario: Vault discovered service accounts for credential rotation
Configuration:
- Classification: "Service Account" rule matching naming patterns (svc_, app_, etc.)
- Workflow: Auto-vault to "Service-Accounts" safe
- Platform: Application-specific platforms
Benefit: Centralized service account credential management
Troubleshooting
| Issue | Solution |
|---|---|
| Workflow not triggering | Verify classification rule has "Allow Workflow Trigger" enabled, check workflow is enabled, confirm classification is being applied |
| Authentication failure | Verify PAM credentials are valid, check API endpoint is accessible, confirm credential type matches PAM system |
| Platform not found | Verify platform exists in PAM system, check platform ID spelling, create platform in PAM if missing |
| Safe not found | Verify safe/vault exists in PAM system, check safe name spelling, create safe in PAM if missing |
| Permission denied | Verify PAM user has permission to create accounts in target safe, check PAM ACLs and policies |
| Rate limit delays | This is normal behavior - workflow will resume when capacity available, consider adjusting rate limits if needed |
| Duplicate accounts | Check if workflow triggered multiple times, review classification rule logic, implement deduplication in PAM |
| Variables not substituting | Verify variable names match trigger type (see Triggers), check syntax uses {Variable} format |
| Wrong safe/vault assigned | Verify template variable resolves correctly, check safe name template syntax, test with fixed safe name first |
Best Practices
Workflow Design
- Platform-Specific Workflows: Create separate workflows for each platform type (Linux, Windows, SQL, etc.)
- Safe Organization: Use logical safe names that reflect account categories
- Naming Conventions: Use consistent account naming templates across workflows
- Test First: Test workflows with a small set of accounts before broad deployment
Classification Strategy
- Specific Rules: Create targeted classification rules that match specific account types
- Avoid Over-Classification: Don't create rules that match too many accounts at once
- Incremental Rollout: Enable auto-vaulting for one account type at a time
- Review Regularly: Periodically review classification rules for accuracy
PAM System Preparation
- Pre-Create Safes: Create target safes/vaults in PAM before enabling workflows
- Platform Configuration: Configure all required platforms in PAM
- Test Connectivity: Verify Hydden can connect to PAM APIs
- Monitor Capacity: Ensure PAM system can handle account creation rate
Operational Management
- Monitor Workflows: Regularly check workflow execution logs
- Review Vaulted Accounts: Periodically audit accounts vaulted by automation
- Handle Exceptions: Have a process for accounts that shouldn't be auto-vaulted
- Document Configuration: Maintain documentation of workflows and classification rules
Related Topics
- Overview - Automation architecture and concepts
- Workflows - Creating and managing workflows
- Triggers - Available trigger types and variables
- Classification Rules - Account classification configuration
- CyberArk Integration - CyberArk PAM integration setup
- BeyondTrust Integration - BeyondTrust PAM integration setup
- Credentials - Managing credentials for PAM systems
- Using Webhooks - Alternative integration approach for custom PAM systems