Copyright © 2012, Thycotic Software Ltd. Last Updated: August 4, 2014

Secret Server Best Practices

I. Getting Started ............................................................................................................................................... 3

1. Get Installed ................................................................................................................................................................. 3

2. Get Licenses.................................................................................................................................................................. 3

3. Terminology ................................................................................................................................................................. 3

II. What sensitive data or passwords do you want to store? .............................................................. 4

4. Secret Templates........................................................................................................................................................ 5

5. Things to consider ..................................................................................................................................................... 5

a. Password Requirements ................................................................................................................................................ 5

b. Secret Expiration .............................................................................................................................................................. 6

c. Soft Deletes .......................................................................................................................................................................... 6

d. Password History .............................................................................................................................................................. 6

e. Session Launcher .............................................................................................................................................................. 6

f. Override Settings at the Secret .................................................................................................................................. 6

g. Limit Secret Template Administrators ................................................................................................................... 7

h. Use Descriptive Secret Template Names ............................................................................................................... 7

i. Create All Your Secret Templates Before Rollout .............................................................................................. 7

j. Create New Secret Templates Correctly ................................................................................................................ 7

k. Implement Naming Patterns ...................................................................................................................................... 7

l. Deactivate Unused or Retired Templates .............................................................................................................. 7

m. Don’t Forget Your Files .................................................................................................................................................. 7

III. Who will manage these passwords and sensitive data? ................................................................. 8

6. Use Active Directory Integration ......................................................................................................................... 8

7. Use Local Groups and Users .................................................................................................................................. 8

IV. How will you control access to Secrets? ............................................................................................... 8

8. AD Groups or Local Groups? ................................................................................................................................. 9

a. Using Existing AD Groups ............................................................................................................................................. 9

b. Creating New AD Groups .............................................................................................................................................. 9

c. Creating New Local Groups and Using AD Users ............................................................................................... 9

d. Using Local Users and Local Groups ........................................................................................................................ 9

9. Using Folders to Control Access (Inherit Permission) ............................................................................... 9

Page 2

10. Deciding on your Folder Structure ................................................................................................................... 10

V. Controlling Access to Features using Roles ...................................................................................... 11

11. Things to consider ................................................................................................................................................... 11

a. Export ................................................................................................................................................................................. 11

b. Unlimited Administrator Mode ............................................................................................................................... 11

c. Role Definition and Assignment ............................................................................................................................. 12

d. Group Assignment ......................................................................................................................................................... 12

e. Secret Templates ........................................................................................................................................................... 12

f. Event Subscriptions ...................................................................................................................................................... 12

12. Locking Down the Unlimited Administrator Mode ................................................................................... 12

a. How it works .................................................................................................................................................................... 12

b. The Problem ..................................................................................................................................................................... 13

c. The Solution ..................................................................................................................................................................... 13

VI. How do I secure my Secret Server? ..................................................................................................... 14

13. Things to consider ................................................................................................................................................... 14

a. General ............................................................................................................................................................................... 14

b. Database ............................................................................................................................................................................ 14

c. Application Server - Web ........................................................................................................................................... 15

d. Application Server – Operating System and File System ............................................................................ 15

e. Application Settings ..................................................................................................................................................... 16

VII. Further Resources ..................................................................................................................................... 17

VIII. Suggestions? ................................................................................................................................................ 17

Page 3

I. Getting Started

This document was written after helping many customers successfully deploy Secret Server in their

organizations. It covers the issues that most customers tackle as they consider which data to store, who

needs access, what permissions to apply and how to organize all their sensitive data. This document is

not meant to cover everything; please see the Further Resources section if your question is still

unanswered.

Think of Secret Server as a platform for your organization to store all of its passwords and sensitive data.

This means that it can be configured to work in many different ways depending on your industry,

compliance requirements and ultimate end goals. The trick is to decide on your objectives and then

match the capabilities and best practices to your situation.

1. Get Installed

Secret Server is distributed as an MSI (setup.exe) which installs the web application (a zip file option is

also available if needed but not recommended as the setup.exe is much easier). To install Secret Server,

simply run the setup.exe. For more detailed information on setting up the prerequisites (IIS, ASP.NET,

and connecting to Microsoft SQL Server), please see the System Requirements, download the software

and follow the Installation Guide.

2. Get Licenses

Once Secret Server is installed, you will need to install either your purchased or evaluation licenses. If

you need evaluation licenses, request your free evaluation licenses here. Then install them under

Administration | Licenses | Install New License in Secret Server.

3. Terminology

Throughout this user guide, certain terms are used to refer to specific features or concepts within Secret

Server.

Administrator

All the features within Secret Server can be separated out into different Roles. Administrator is

one of the default Roles that comes installed with Secret Server. This Role can be customized to

have different permissions. In this guide, 'Administrator' will be used when referring to the

user(s) who manage the system. Administrators have control over the global security and

configuration settings. Note that Administrators in Secret Server DO NOT automatically have

access to all data stored in the system – access to data is still controlled by explicit permissions

on that data.

Secret

A Secret is any sensitive piece of information (typically a password) that you would like to

manage within Secret Server. Secrets are derived from customizable Secret Templates. Typical

Secrets include, but are not limited to, privileged passwords on routers, servers, applications,

Page 4

and devices. Files can also be stored in Secrets allowing for storage of private key files, SSL

certificates, license keys, network documentation info or even a Microsoft Word or Excel

document.

Secret Template

Used for creating Secrets, Secret Templates allow you to customize and format Secrets to meet

your company's needs and standards. Examples include: Local Administrator Account, SQL

Server Login, Oracle Login, Credit Card and Website Logins. Templates can contain passwords,

user names, notes, uploaded files, and drop-down list values. Templates can be customized and

new Secret Templates can also be created.

Role-based Security

Secret Server uses Role Based Access Control (RBAC). All features in Secret Server map to

permissions which can then be assigned to Roles. Users and groups can then be given one or

more Roles. Role Based Security provides Administrators the ability to set strict, granular

permissions for each user.

Unlimited Administration Mode

This is the emergency ("break-the-glass") feature. When this mode is enabled, Administrators

are able to access all content within the system regardless of explicit permissions. Access to the

Unlimited Administration Mode is controlled using Roles.

Remote Password Changing

Secret Server can automatically change passwords on remote devices and various platforms

including: Windows Accounts, various database logins, Active Directory accounts,

UNIX/Linux/Mac accounts (including root passwords), network appliances/devices and more.

II. What sensitive data or passwords do you want to store?

Do a quick brainstorming session and try to think of all the types of sensitive data that need to be

securely stored and managed. Where are the pain points for your teams?

Here are some guidelines to get you started:

Think of all privileged passwords:

o These are passwords that don’t identify an individual (for example: Administrator, root,

enable, shared accounts, service accounts, etc.).

o These should all be randomized passwords and should be changed frequently.

Every password in your organization should be the different.

Any password that could be needed should an employee quit or be fired.

Any password that could be needed in an emergency or outside of regular business hours or

when someone is on vacation.

Page 5

Typical passwords and sensitive data being stored in Secret Server:

Windows local Administrator passwords.

UNIX, Linux, Mac root and local user passwords.

Active Directory service account passwords.

Database passwords (MS SQL, Oracle, MySQL, etc.).

Network equipment passwords (router, switches, firewalls, phones, appliances, etc.).

Application passwords (SAP, custom apps, etc.).

Website passwords (cloud services, DNS, Amazon AWS, vendor passwords).

Sensitive files (private key files, SSL certificates, network documentation info, etc.).

Software license keys, serial numbers, personnel data, Wi-Fi passwords.

4. Secret Templates

Secret Templates in Secret Server define the types of data (“Secrets”) that can be stored. Review the

available templates by going to Administration | Secret Templates. You can decide which Secret

Templates should be available to your users and you can customize the existing templates (rename

fields, change fields, add fields). You can also create new Secret Templates to match your types of data

if needed. You can basically store *any* type of sensitive data in Secret Server.

Secret Templates are the way that you control which data can be stored in your Secret Server and the

settings for that data.

5. Things to consider

a. Password Requirements

Password Requirements determine the password compliance rules (for example, 16 characters, 1 upper,

1 lower, 1 symbol and 1 number). Password requirements can be customized and then applied to

passwords at the Secret Template level. This will control the complexity of the passwords generated by

Secret Server and can be enforced by the system and also can be viewed for password compliance in

reports. This also allows you to have different complexity rules for different types of passwords if

needed (Oracle, SQL, Windows, UNIX, etc.). Also, choose to have Secret Server enforce the Password

Requirements on add/edit by turning on validation on the Secret Template.

Talk to your security management, auditors and industry experts – find out the best password

complexity settings for your environment. Don’t be afraid to dial up the settings (e.g., 100 character

random generated passwords with symbols, alphanumeric and upper/lower) – using a platform like

Secret Server makes it easy to work with passwords so length won’t matter (launchers, copy to

clipboard, autochange). 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 the Character Sets to use. Some

systems may not work well with certain characters; for example, underscores can be problematic in

Page 6

certain mainframe environments. You can create your own Character Sets (Administration | Secret

Templates | Character Sets) for use in Password Requirements. These can then be used when passwords

are generated by Secret Server.

b. Secret Expiration

Secret Server uses Secret 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 means that

the password should be changed. Passwords can either be automatically changed by Secret Server (this

will change the password on the account across the network if configured to do so) or can be manually

updated by an Administrator on expiration.

You can also control which field is used for expiration (it doesn’t have to be the password). 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.

c. Soft Deletes

Secret Server uses soft deletes rather than hard deletes (data is marked as inactive rather than actually

deleted). This is essential for auditing since data cannot just be removed from the system causing all

audit activity to be lost. Secrets and Secret Templates can be inactivated but not deleted. This is

something to bear in mind when configuring your Secret Server.

d. Password History

Secret Server will automatically keep all history on all fields on a Secret Template. This means that all

previous values for machine, username, password and any other fields will be kept. This is helpful in

ensuring that previous passwords can be found if needed.

e. 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 .exe; for example, MS SQL Management Studio, SSH clients, FTP tools and more. This can also

be used with the “Hide Launcher Password” (Secret | Security tab) to allow Administrators to launch

tools without revealing the password.

f. Override Settings at the Secret

Many of the settings at the Secret Template can also be overridden at the Secret; for example, if you

create a Secret for your AD service accounts with a 30-day expiration but need 90 days for one particular

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.

Page 7

g. Limit Secret Template Administrators

Changing Secret Templates should be limited to only a small subset of the 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.

h. Use Descriptive Secret Template Names

Make sure your Secret Template names are descriptive and use terms your users will 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 Active Directory Account, change it to match the

organization’s language.

i. Create All Your Secret Templates Before Rollout

It is worth spending time in the beginning to get your Secret Templates the way you want them before

users start adding data. When an Administrator goes to create a new Secret, it will be clear which Secret

Template to use and not try to fit the Secret into another template because the right Secret Template

does not exist yet. You can use Secret Convert later to change a Secret from one to another but it is a

lot easier to just plan ahead before your Administrators start adding data.

j. Create New Secret Templates Correctly

When creating new Secret Templates, make sure you wire up Remote Password Changing, Password

Requirements, Secret Expiration and the Session Launcher.

k. Implement Naming Patterns

Secret Server supports Naming Patterns for Secret Templates. 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 Expression and allow you to enter a descriptive error message. Use this error

message to describe your naming standard to your Administrators. The most common naming standard

used is RESOURCE\ACCOUNT (for example, server0001\administrator).

l. Deactivate Unused or Retired Templates

Secret Server 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 will remain when a Secret Template is deactivated but no one will be able to create

new Secrets for that Secret Template.

m. Don’t Forget Your Files

Don't forget files. You can have fields on your Secret Template that are for file attachments. This can be

used for storing license key files, private keys, SSL certificates, even Microsoft Word or Excel documents

that contain sensitive data.

Page 8

III. Who will manage these passwords and sensitive data?

Now that you know which data you will be managing in Secret Server, the next step is to decide who will

use Secret Server to manage that data. Start by thinking about which privileged passwords need the

most attention first – maybe Windows local Administrator passwords, service accounts, UNIX root

passwords, network equipment passwords or others? The Administrators who manage those passwords

and need access to them on a regular basis will need to access your Secret Server.

There are few different options for configuring access to Secret Server for your Administrators:

6. Use Active Directory Integration

Use Active Directory Integration to allow use of AD accounts to access Secret Server:

a) These accounts can be created manually (one by one) by adding an AD Domain to Secret Server

and then adding users to that Domain within Secret Server (see Adding an AD Domain, and

Creating an AD User).

OR

b) These accounts can be synchronized with one or more AD groups with Secret Server so that

users in those groups automatically have access to Secret Server. This can be done by adding a

Domain to Secret Server, then choosing which AD groups to synchronize (see Adding an AD

Domain, and Choosing AD Synchronize Groups).

7. Use Local Groups and Users

Use local users and groups within Secret Server. These users and groups have to be created and

managed manually (not integrated with Active Directory) but it provides the most security since users,

groups and group membership can be controlled entirely through Role Based Access Control (RBAC)

within Secret Server.

IV. How will you control access to Secrets?

You have different sets of passwords that should only be viewed by particular Administrators. You may

also have certain passwords that should be read-only to some Administrators, editable by others and

not even visible to other Administrators. All of these options are possible to configure using the

permissions within Secret Server.

Permissions can be allocated at the individual user level but it tends to be easier to manage over time if

you allocate your permissions at the group level. You will need to decide if your existing AD groups

could work for these permissions or if you need to create new AD groups or if you want to create and

manage local groups in Secret Server.

Page 9

8. AD Groups or Local Groups?

a. Using Existing AD Groups

Review your teams that need access and the corresponding groups in your Active Directory. If your AD

groups map to ways you want to separate out access to Secrets and levels of access (View / Edit /

Owner) then you can synchronize your AD groups into Secret Server. Go to Active Directory |

Synchronize Groups. By using your existing AD groups, you can effectively manage access to Secret

Server and to the Secrets stored within Secret Server completely from AD by changing AD group

membership. Many customers choose this option as they maintain control in AD and don’t have to

worry about any user or group maintenance within Secret Server.

Note This option is easy for user maintenance but it does limit the security of your Secret Server to the

level of security of your Active Directory. This may be fine but be sure to consider the question.

b. Creating New AD Groups

If your AD groups don’t really match the way you want to break out your access to Secrets, then you will

need to create new AD groups to match the permission levels needed.

c. Creating New Local Groups and Using AD Users

Another option is to grant access to AD users in Secret Server by creating their accounts manually or by

synchronizing one or more AD groups BUT then create local groups in Secret Server to match the levels

of access needed. The AD users can then be added to the local groups and all access is controlled in

Secret Server. This approach requires more maintenance since group membership has to be controlled

in Secret Server but it does provide the benefit that users are still managed in AD and they can use their

AD credentials to authenticate to Secret Server. Many customers who use this approach simply create a

single AD group (for example, “SecretServerUsers”) and then synchronize that group in Secret Server.

Note This hybrid approach is more secure than using AD groups and AD users but an adversary could

still reset an AD account password to gain access to your Secret Server. However this is more likely to

be noticed by the user whose password is reset but only after the fact.

d. Using Local Users and Local Groups

Creating local users and groups within Secret Server provides a lot of flexibility since you can tailor the

groups and access to your exact needs but it also requires more maintenance than the other options.

9. Using Folders to Control Access (Inherit Permission)

You can apply permissions (View / Edit / Owner) at the Secret level. This allows you to apply very

granular permissions on a single Secret if needed. Managing permissions on each Secret is powerful for

situations where you need that flexibility but it tends to be harder to manage over hundreds or

thousands of Secrets. Instead, you should consider using Folders to control permissions for most

Secrets. This can be done by creating a folder structure that best represents your organization, teams or

Page 10

data being stored; then apply permissions (View / Edit / Owner) on the folders, using inheritance across

folders where appropriate. Secrets placed in a folder can then inherit the permissions of the folder.

10. Deciding on your Folder Structure

The folder structure creates a hierarchy for organization and permissions. This means that folders near

the root level need to break out access in high level terms and then get more specific permissions

(typically breaking inheritance) as you move down to the “leaf level” sub-folders.

For example:

Information Technology

o Technical Services

Systems

Windows

UNIX

Network Infrastructure

Database

Oracle

SQL Server

o Development Services

Programmers

Vendors

Human Resources

Customers

The most typical configuration is to break out the folders based on the teams that need to use those

folders with the most restrictive permissions at the outer most “leaf” folders of the tree.

An Oracle DBA might have the following permissions on the above folders:

Information Technology (VIEW)

o Technical Services (VIEW)

Database (VIEW)

Oracle (VIEW / EDIT / OWNER)

SQL Server (VIEW / EDIT)

Note A user will not be able to see the full folder structure unless they have View permissions on all the

parent folders of a particular folder. For example, a user with View on the “Oracle” folder, would also

need View on “Database”, “Technical Services” and “Information Technology” to be able to see the full

folder path.

Page 11

There are settings in Administration | Configuration to control whether inheritance on Folders and

Secrets should be turned on and also whether users should always see all folders. There are many ways

to configure this for your organization.

The most common approach is:

Use inheritance.

Don’t allow users to see folders unless they explicitly have View permissions.

Require all Secrets to have a Folder.

This allows different teams or even different departments within your organization to use the same

Secret Server instance independently.

V. Controlling Access to Features using Roles Secret Server Administrators do not automatically have access to all data stored in your Secret Server.

Secrets are only visible based on the explicit permissions assigned. This ensures that the data is safe and

cannot be easily viewed by the Administrators. However, there are still features within Secret Server

that need to be controlled and even monitored for use or abuse.

Access to features within Secret Server can be controlled using the Role Based Access Control (RBAC).

Features in Secret Server have corresponding Role Permissions which can be assigned to different Roles.

Roles can be customized and new Roles can be created as needed.

Secret Server comes with three (3) Roles by default: Administrator, User and Read Only. You should

review these roles and also decide if your organization needs further Roles for third party consultants or

auditors or if you need to break out the Administrator Role into several Roles.

11. Things to consider

a. Export

Exporting Secrets from your Secret Server as cleartext is very helpful for meeting regulations in certain

industries (Secrets can then be printed to paper and locked in a physical safe). It can also be used as

another Disaster Recovery option but access to exporting data from the Secret Server should be tightly

controlled. You could create a separate Role with just that permission for anyone needing to perform

exports.

b. Unlimited Administrator Mode

Unlimited Administrator Mode allows anyone with the Unlimited Administrator Role Permission to see

all Secrets in the Secret Server. This mode is very helpful for recovering passwords in emergencies or

when staff are terminated. You can tightly control access to this feature by splitting out the Role

Permissions for Administer Unlimited Administrator and Unlimited Administrator into two different

Roles. This allows you to create the “two key effect” for access to use this feature.

Page 12

c. Role Definition and Assignment

Once you have defined your Roles, they will seldom need to be changed. Access to modify and assign

roles should be tightly controlled.

d. Group Assignment

If Roles are assigned to groups then assignment of the groups also needs to be controlled. Often very

sensitive Role Permissions are assigned at the user level to limit the risk of granting group assignment

permissions.

e. Secret Templates

As mentioned in the section on Secret Templates, you should control access to modifying your Secret

Templates. Anyone with this access can change the definitions of the data being stored and this access

should be tightly controlled. Once again, your Secret Templates are unlikely to need changing once you

have defined them so limiting access to a select number of individuals should be fine.

f. Event Subscriptions

Another option when protecting roles is to configure Event Subscriptions to notify appropriate staff in

the event that Roles are changed or assigned. Event Subscriptions are email alerts that can be sent to

users, groups or specific email addresses, based on different events in Secret Server. There are also

events available around Unlimited Administrator to further protect its use.

12. Locking Down the Unlimited Administrator Mode

The Unlimited Administrator role permissions are all assigned to the Administrator Role when you first

install Secret Server. This works for teams where a single highly trusted individual (or a few) will control

all the Administrative functions of Secret Server (for example, single IT team or MSP).

For larger enterprise environments where more control is needed or there are compliance

requirements, you will need to split out the Administrator role. Customers often struggle with how to

adequately lock down the Unlimited Administrator feature because there are lots of loopholes such as

manipulating roles, role assignment and even group assignment that could allow a malicious

Administrator to get access to Unlimited Administrator.

a. How it works

Unlimited Administrator is a Role Permission that can be assigned to a Role (an existing Role or you

could create a new Role if needed). Users and groups can then be assigned to this Role. Anyone who

has this Role either by direct assignment to their user account or through their group membership can

then see all Secrets in Secret Server when Unlimited Administrator Mode is turned on (it is turned off by

default but can be turned on by going to Administration | Configuration | Unlimited Administrator

Mode).

Page 13

There is another Role Permission named Configure Unlimited Administrator which allows access to turn

the Unlimited Administrator Mode on or off. This can be separately assigned to a Role and given to

other users. Separating the Unlimited Administrator and Configure Unlimited Administrator Role

Permissions makes it possible to split the ability to use Unlimited Administrator to more than one

person for dual verification.

b. The Problem

Although these role permissions make it easy to separate and control access to Unlimited Administrator,

there are loopholes since an Administrator who can change Role definitions or who can assign roles

could just assign both role permissions to their own user account.

c. The Solution

The solution is to find all the ways through which an Administrator could manipulate Unlimited

Administrator Mode and lock them down accordingly.

Here are the recommended guidelines:

1) Split out the Unlimited Administrator and Administer Configuration Unlimited Admin Role

Permissions into two separate Roles and assign them to the appropriate trusted individuals who

will need to collaborate to use Unlimited Administrator Mode. Add the View Configuration

permission to the role containing Administer Configuration Unlimited Admin permission (to

allow for the user to access the setting from the Configuration page). Assign at the user level,

not at the group level, so that group management does not come into scope). These individuals

do not have to be regular users of Secret Server but will need to be available in emergencies

should Unlimited Administrator be needed.

2) Review the “User” role and adjust or customize as needed. This should be the default Role for

new users and should be assigned to the Everyone group.

3) Create another role (something like “Role Administrator”) and put all the role permissions that

effect roles into that Role.

a. Administer Role Assignment

b. Administer Roles

4) Make sure that your “Administrator” Role no longer has the above role permissions or the

Unlimited Administrator role permissions.

5) “Role Administrator” should only be assigned to a very limited number of trusted individuals

(ISO, Executive, or Senior Manager). The Role should be assigned directly to their user accounts,

not to a group; otherwise, group management comes into the scope of this problem). This Role

should very seldom be used since it is only needed to change role assignments or change role

definitions.

6) Create a new Event Subscription (under Administration | Event Subscriptions) to notify via email

the appropriate people when suspicious things happen and target the following events:

a. Role > Assign User or Group

b. Role > Create

Page 14

c. Role > Unassign User or Group

d. Role Permission > Add To Role

e. Role Permission > Removed From Role

f. Unlimited Administrator > Enable

g. Unlimited Administrator > Disable

h. Configuration > Edit (this is recommended since changing mail server settings could

prevent emails from being sent)

Other events to consider:

i. Secret > View (for any very sensitive Secrets)

j. User > Login Failure (in case someone is trying to brute force the password of another

User)

VI. How do I secure my Secret Server?

Security is a process, not a product, so it is critical to build a secure process around your Secret Server

implementation. This needs to include a layered approach to security (defense in depth) starting at the

operating system, software updates, access to physical systems, protocols, system settings, backups and

personnel procedures.

13. Things to consider

a. General

i) Keep Windows up-to-date

Microsoft regularly releases security patches that resolve vulnerabilities in Windows operating systems.

We recommend keeping your server up to date.

ii) Backup At Least Daily

Consider your Disaster Recovery plan. Review Business Continuity and Disaster Recovery Planning (KB

article) for more information.

iii) Review System Log for Errors

It is important to periodically check the System Log for any recurring errors. After an upgrade, check for

any errors in the System Log (Administration | System Log).

b. Database

i) Limit access to your Secret Server database

When you create your Secret Server database, you should limit access to as few users as possible. We

recommend you disable the “sa” account in the SQL instance that contains Secret Server.

Page 15

ii) Limit access to other databases

When you create a database account for use by Secret Server, you should ensure it only has access to

the Secret Server database. Also consider limiting access to sensitive system databases such as master –

refer to Restricting Access to Master Database in SQL Server (Microsoft Support KB) for details.

iii) Use Windows Authentication for database access

Windows Authentication is much more secure than SQL authentication. For a detailed explanation of

why this is true, please refer to Choose an Authentication Mode (TechNet article).

To use Windows Authentication in Secret Server, you will need to create a service account. For details

on how to do this, please refer to Using Windows Authentication to access SQL Server (KB article).

iv) Limit access to your database backups

Database backups are critical for disaster recovery, but they also carry a risk if someone gains access.

The Secret Server database is encrypted but you should still limit access to ensure you are following

“defense in depth”. Make sure to limit access to database backups to as few individuals as possible.

v) Don't store the database on a SQL instance that contains less sensitive databases

Putting the database on a server with other less secure database instances can open up vulnerabilities.

For example, an attacker could potentially use SQL injection on another application to access your

private Secret Server database.

c. Application Server - Web

i) Use SSL / HTTPS

Secure Sockets Layer (SSL) is required to ensure that all communication between the web browser and

Secret Server is encrypted and secure (and not cleartext travelling across your network). We

recommend you install a third-party certificate, domain certificate, or self-signed certificate on your

Website. For information on creating and installing a self-signed certificate, please see Installing a Self-

Signed SSL/HTTPS Certificate (KB article).

ii) Force SSL / HTTPS

Even after you install an SSL certificate, users may still be able to access Secret Server through HTTP. To

prevent access via HTTP, enable the Force HTTPS/SSL option in Secret Server (Administration |

Configuration).

d. Application Server – Operating System and File System

i) Limit access to your Secret Server directory

It is very important to limit access to your Secret Server directory. This contains the Secret Server

encryption key as well as the database connection information. (These values are encrypted but

remember “defense in depth”. Try to grant access to as few users as possible.)

Page 16

ii) Limit logon rights to the Application Server

Administrators accessing the Application Server directly could attempt to monitor memory in use on the

server. Secret Server does several things to protect application memory but the best safeguard is to

limit access to the Application Server to as few users as possible.

iii) Protect your encryption key

Use DPAPI to encrypt your encryption.config file. Go to Administration | Configuration | Security tab |

Encrypt Key Using DPAPI. This will use machine specific encryption to encrypt the file - make sure you

backup the original file before turning on this option.

The encryption key for secret server is contained in the encryption.config file, which resides in your

Secret Server directory. This file is obfuscated and encrypted, but defense in depth would require

limiting access to the file. To further protect the file, you can enable EFS encryption. EFS (Encrypting File

System) is a Microsoft technology that allows a user or service account to encrypt files with login

passwords. For more details, please read Protecting Your Encryption Key Using EFS (KB article).

Note When setting up clustering, it will be necessary to copy a version of your encryption.config file

that is NOT encrypted to the additional server. Once Secret Server is up and running on that server, you

can then DPAPI-encrypt the encryption.config file by logging into Secret Server locally and turning on

DPAPI.

e. Application Settings

i) Review the Security Hardening Report

Go to Reports | Security Hardening Report in Secret Server. Review each setting and get as many to

“green” as feasible for your environment. These recommendations will help to secure your Secret

Server at the application settings level.

ii) Use DoubleLock for your most sensitive Secrets

DoubleLock is a feature in Secret Server that allows Secrets to be protected with additional AES256 bit

encryption keys. Each Administrator gets their own public/private key when using DoubleLock. Their

private key is protected by an additional password (user specific--not a shared password) that each

Administrator must enter when using DoubleLock. DoubleLock protects from situations where you

accidentally assign someone to the wrong AD group or an attacker gains full access to both your

database and web server - they still will not be able to access DoubleLocked secrets. For more

information, refer to Using DoubleLock (KB article).

iii) Use Two Factor Authentication

In the event that a password gets compromised, you can protect yourself by enabling two factor

authentication (TFA). Secret Server currently supports two forms of two-factor authentication. First, you

can use your email address as an extra form of identification. Second, you can use a RADIUS compliant

device (such as an RSA or CryptoCard token), as an extra form of authentication. For more details, please

refer to the following KB articles:

Page 17

How does Two Factor Authentication work?

Enabling RADIUS Two-Factor Authentication

iv) Secure the Local Admin Account

When you create the first user in Secret Server, it will be a privileged Admin account that you can use

when your domain is down. We recommend that you choose a non-obvious name for this account and

protect it with a very strong password. This password should be stored in a physical safe with limited

access (there is no need to use this account except in emergencies where other accounts are not

working if AD is down or some other reason).

v) Review Activity Reports

It is a good practice to regularly review the activity and permissions reports. This can help find anomalies

in Secret permissions and login failures.

vi) Use Event Subscriptions to notify of any security anomalies

Event Subscriptions can be used to send email alerts on various events in the system. This could be used

to notify Administrators if there are failed login attempts or if certain Secrets are viewed, etc.

VII. Further Resources

Please review these resources for more information:

Secret Server User Guide

Secret Server Installation Guide

Secret Server Knowledge Base

Secret Server Video Tutorials

Secret Server Customer Forums

Thycotic Blog

VIII. Suggestions?

Please let us know if you are still unable to find the answer to a question after reviewing this document

and the resources listed above. Please send an email to support@thycotic.com with your suggestions.