Secret Templates

Secret templates in Verify Privilege Vault define the types of data (secrets) that can be stored, and the settings for that data. You can store just about any type of sensitive data in Verify Privilege Vault.

It is important to review the available templates and decide which ones should be available to your users as well as where you would like to make changes to the default templates included.

Configuring Templates

You can customize existing templates or create new templates if necessary. Many templates are included by default that cover common account types. For example, the AD Account template contains the following settings:

  • Domain, username, password, and notes fields
  • 30-day expiration period, applying to the password field
  • RDP launcher, requiring user input for computer to connect to
  • Password changing and heartbeat enabled
  • AD password changer, with default password requirements

These settings are typically sufficient for most organizations to use out-of-box. However, you may wish to enable other settings or change settings such as enforcement of a naming convention or more complex password requirements. In this case, you have the flexibility to either modify the existing template, copy the existing template to use as a base for a new template, or create a new template from scratch. The following sections cover some fundamental template settings available for you to customize.

One best practice we often recommend is simply leaving default templates the way they are and duplicating the templates you plan to use. Then customize the newly duplicated templates as needed. Name them something your employees will recognize and readily use.

File Attachments

Do not forget files. You can have fields on your secret template that attach files. This can be used for storing license key files, private keys, SSL certificates, even Microsoft Word or Excel documents that contain sensitive data. Add a file field to a template from the Fields tab — see Secret Template Fields.

For security, restrict which file types and sizes can be uploaded. File Restrictions (Admin > Configuration > Security tab > File Restrictions) lets you specify the allowed file extensions and a maximum file size, protecting users from being tricked into downloading a malicious attachment. We recommend enabling File Restrictions and keeping the maximum file size at or below 30 MB. See the Security Hardening Guide.

Naming Patterns

Verify Privilege Vault supports enforcement of naming patterns for secret names. Naming patterns allow you to maintain consistency for secret names and can help ease both browsing and grouping secrets by name. Naming patterns use regular expressions and allow you to enter a descriptive error message to describe your naming standard to users. The most common naming standard used is RESOURCE\ACCOUNT (for example, server0001\administrator). You can find this setting by clicking Edit from the template designer page. For the regular-expression syntax and worked examples, see Template Naming Patterns.

Password History

Password history in Verify Privilege Vault covers two related capabilities: tracking previous field values, and preventing reuse of previous passwords. These are configured in different places and apply to different operations, so they are described separately below.

History Tracking (Field-Level)

Secret Server keeps a history of all previous values for every field on a secret by default. This means previous passwords, usernames, and other field values are retained and can be retrieved if needed.

History tracking is controlled per field on the template:

  1. In Admin > Secret Templates, select a template.

  2. Click the Fields tab.

  3. Click the edit icon for the field you want to modify.

  4. Enable or disable All history for that field.

When All history is enabled (the default), Secret Server retains every previous value for that field. When disabled, no history is kept for that field.

Password Reuse Prevention (Global)

To prevent passwords from being reused across password changes — a common compliance requirement (for example, PCI DSS v4 section 8.3.7, which requires that the last four passwords not be reused) — configure the Secret Password History setting:

  1. Search for User Experience and click Edit.

  2. Set Secret Password History to the number of recent passwords that cannot be reused (for example, 4 for PCI DSS). Alternatively, select All Secret Password History to prevent reuse of any previous password.

  3. Click Save.

This setting is global and applies to all secrets. It enforces uniqueness during the change password and bulk change password actions and any operation that uses auto-generated passwords (Remote Password Changing, scheduled changes, and secret creation).

By default this setting does not apply to manually entered passwords. See the next section to extend enforcement to manual edits.

Enforcing Reuse Prevention for Manual Password Edits

To enforce the password reuse check when a user manually enters a password during a Change Password Now operation:

  1. In Admin > Secret Templates, select the template.

  2. On the General tab, click Edit in the Template Settings section.

  3. Enable Validate Password Requirements on Edit.

  4. Click Save.

This setting is per-template and extends the global Secret Password History enforcement to manually entered passwords.

There may be cases where reusing a previous password is necessary — for example, an account-recovery scenario where access to a resource is limited and a prior password is the only way to restore administrative access. Consider this before enabling the setting on a given template.

For more information about password complexity rules (length, character sets, and validation), see Template Password Requirements.

Password Requirements

Password Requirements determine the password compliance rules (for example, 16 characters, one uppercase, one lowercase, one symbol and one number). These can be customized and applied to passwords at the secret template level or per individual secret (under the Security tab). This controls the complexity of passwords generated by Verify Privilege Vault. Password requirements can also be enforced when users try to edit or create new passwords, and can be viewed for password compliance in reports. This allows you to have different complexity rules for different types of passwords if needed (such as Oracle, SQL, Windows, and UNIX). You can choose to have Verify Privilege Vault enforce the password requirements on add/edit by turning on validation on the secret template (click Edit from the template designer page).

We have added new password Template Password Requirements to recent versions of Verify Privilege Vault, which further helps create unique passwords. We also added Creating and Editing Custom Password-Exclusion Dictionaries that can help personalize which words may never be used as part of a password that is generated.

Talk to your security management, auditors and industry experts to find out the best password complexity settings for your environment. Do not hesitate to stipulate complex passwords, such as 100-character random-generated passwords with symbols, alphanumeric uppercase and lowercase)—using a platform like Verify Privilege Vault makes it easy to work with passwords so complexity and length do not matter (for launchers, copy-to-clipboard, and auto change). In fact, very large passwords can add to security since administrators will be far less likely to remember them or write them down or want to type them.

Another thing to consider when creating password requirements is which character sets should be used. Some systems may not work well with certain characters. For example, underscores can be problematic in certain mainframe environments. You can create your own character sets (Admin > Secret Templates > Character Sets) for use in password requirements. These can then be used when passwords are generated by Verify Privilege Vault.

Secret Expiration

Verify Privilege Vault uses expiration to ensure that passwords are changed on a regular basis. Secrets can be set to expire on an interval such as 30 days (or other intervals as needed). Expiration is often combined with automatic password changing (AutoChange, through Remote Password Changing) to control how often a password is changed (whenever it expires, Verify Privilege Vault will queue the secret up for a password change).

You can also control which field is used for expiration. This does not have to be the password field—you could use expiration on a license key and set expiration to when the license is going to expire. When a secret expires, you can then update the expiration field (say license key) and it will no longer be expired. This is a generic way to ensure that a specific field on a secret is changed on a regular basis.

Expiration is enabled per template on the General tab, in the Template Expiration section, and can be overridden on individual secrets. For the full procedure and expiration behavior, see Secret Expiration Overview and Setting up Secret Templates for Secret Expiration.

Session Launcher

The Launcher can be configured on the secret template to allow any tool to be launched using the secret such as Remote Desktop, PuTTY, Web launcher or a custom launcher you configure for a particular executable file, for example, MS SQL Management Studio, SSH clients, FTP tools and more. This can also be used with the "hide launcher password" setting to allow administrators to launch tools without revealing the password. Launchers are enabled and mapped per template — see Launcher Configuration and Support, Setting Up Secret Templates for RD Launchers, and Creating Custom Launchers.

Template Management

It is worth spending time in the beginning to get your secret templates the way you want them before users start adding data. Therefore, when a user goes to create a new secret it will be clear which secret template to use instead of selecting the wrong one and attempting to fit account information into an unsuitable template. You can use an option on the secret called "convert template" to later convert a secret to another template, but it is much simpler to plan before your organization begins adding data.

Basic Configuration

When creating new secret templates, make sure you configure Remote Password Changing, password requirements, secret expiration and the launcher. Ensure your secret template names are descriptive and use terms your users understand. For instance, if you have one template that expires and one that does not, make sure it is clear from the name. If your organization does not use the term AD account, change it to match the organization's language.

Deactivate Unused or Retired Templates

Verify Privilege Vault comes with many secret templates preconfigured. You should decide which you want to use and then deactivate the others. You can also retire secret templates if your requirements change over time—secrets remain when a secret template is deactivated but no one will be able to create new secrets for that secret template. Verify Privilege Vault SS uses soft deletes rather than hard deletes (data is marked as inactive rather than actually deleted), which is essential for auditing. Secrets and secret templates can be inactivated but not deleted.

Limit Secret Template Administrators

Changing secret templates should be limited to only a small subset of your Verify Privilege Vault admins. Create a separate role that has the "administer secret templates" role permission and remove it from administrator if you have a lot of administrators. Once you have secret templates configured, it is unlikely they will need to be changed frequently so very few people should need access.

Override Settings at the Secret

Many of the settings at the secret template can also be overridden at a secret based on that template. For example, if you create a secret for your AD service accounts with a 30-day expiration but need 90 days for a specific AD service account, you can set it to 90 days for that one secret. This gives some flexibility for secrets that need to behave differently than other secrets using the same secret template.