Secret Server can integrate with Active Directory by allowing users to use their Active Directory credentials to login to Secret Server. Secret Server synchronizes Active Directory users from a Group in a Domain at a periodic interval. Specify the Domain to Synchronize groups from, then select the groups and users for Secret Server to pull in.

You may also create all of your Active Directory users manually from the user screen.

	Note
	Active Directory Integration requires an additional add-on license. Please contact sales for a trial or a quote.

Active Directory configuration can be enabled by a user with the "Administer Active Directory" role.

Figure 2.1. Active Directory Configuration

The configuration screen offers several options:

Before synchronizing or creating users, specify which domains Secret Server will be able to authenticate against. From the Active Directory Configuration page, click Edit Domains and then Create New to add a new Active Directory Domain. Username and Password are only required for connecting to the Domain when synchronizing users.

Active Directory users can be created manually by a user that has the "Adminster Users" role. You can do this by going to Administration » Users, then clicking the "Create New" button.

Figure 2.2. Creating an Active Directory user

From the Administration page, navigate to Secret Templates. On this page, select a Template to edit, or create a new one. If creating a new template, a prompt will appear to specify the name of the new template. The Secret Edit page provides all the options for configuring a Secret Template as well as which fields will appear on any Secret created from that template.

Figure 3.1. Template Designer Page

Secret Server supports naming patterns for Secret Templates. Naming patterns are a way for administrators to maintain consistancy for Secret names and can help ease both browsing and grouping Secrets by name. Patterns are created as regular expressions. Regular expressions are a formal set of symbols commonly used to match text to patterns.

An example regular expression is ^\w+\\\w+$, which would allow "NTDOMAIN01\USER3454" but not "USER3454 on NTDOMAIN01". Here the "^" symbolizes the beginning of the text. "\w" specifies alpha-numeric characters plus the "_" character, while "+" indicates one or more occurances of the previous symbol. In this case "+" means one or more alpha-numeric characters ("\w"). The "\\\" is used to denote a single "\". In regular expresssions special characters are escaped with a "\", so to try and match a single slash requires extra escape characters. Lastly the "$" signals the end of the text.

Figure 3.2. Template Designer Edit

Templates allow expiration on certain fields. When the Expiration Enabled option is turned on, a time length can be specified for a selected field using the drop down menu. With this option enabled and a time duration specified, Secret Server will begin providing alerts if a Secret field is not changed within the specified expiration requirements.

If Secret Name History is enabled, Secret Server will keep the specified number of entries for viewing. This feature creates a record of every name used when a new Secret is created.

If a Template is no longer relevent or outdated, it can be inactivated. This can be done in bulk or from a specific Template's designer page. From the Secret Templates page Set Active will display all the Templates in Secret Server. Each template can be set as active or inactive. Once the Templates are correctly configured, saved changes will bring the Templates into effect immediately.

Figure 3.3. Bulk Template Activation

An individual Template can be inactivated by changing the header information from the Secret Template Designer. Set the Active option to the desired value and Save the change.

Template fields can be customized in a variety of ways.

Templates define what fields will appear on a Secret. Each field can be specified as one of several different types to enhance customization.

The Remote Desktop Launcher provides a simple and convienent way to run Microsoft Remote Desktop connections from a Secret page. A Secret's fields automatically complete the authentication information that is required to establish the connection.

Secrets can be configured for the Remote Desktop Launcher from within the Secret Template Designer page. Configure Remote Desktop Launcher displays the options for editing the launcher. The Enable Remote Desktop Launcher must be checked to allow editing of the Launcher mapping options.

For a Remote Desktop Connection to work properly Secret Server requires the appropriate logon information. The Launcher credentials are taken from specified Secret fields. Fields must be assigned their corresponding credentials from the drop down list.

Figure 3.4. Remote Desktop Configuration

Secret Server's RDP launcher opens a connection to the remote computer using the Secret's credentials. While this provides a convienent method of opening RDP connections, it also circumvents users being required to know their passwords. A user can still gain access to a needed machine, but is not required to view or copy the password out of Secret Server.

RDP can be launched from any Secret created from a properly configured Template. For more information see the section on setting up Remote Desktop Launcher - Template Configuration. Enable Launcher must also be checked wihin the Configuration Settings for the launcher icon to appear on allowed Secrets.

Figure 4.1. Launching RDP

Firefox requires a helper add on application to run the RDP launcher. There are two available add ons, the recommended option is the FFClickOnce application. Microsoft has also released an add on called Microsoft .NET Framework Assistant 1.0 in the .NET framework version 3.5 SP1. If .NET 3.5 SP1 is installed as well as FFClickOnce, the RDP launcher will not run correctly.

	Note
	Firefox add-ons can be checked by opening Manage Add-Ons from the Options page.

Figure 4.2. Configuring Firefox

SSL must be set up properly for the RDP launcher to work correctly. If Secret Server is using SSL certificates, they must be trusted at the user's computer. This will only be an issue with self created certificates.

The Remote Password Changing (RPC) add-on allows properly configured Secrets to automatically update a corresponding remote account. Secrets can be set for automatic expiry and when they expire Secret Server will automatically generate a new strong password and change the remote password to keep all accounts synchronized.

If Secret Server fails to change a remote password, an alert will appear notifying that there are Secrets out of sync.

RPC is configured from the Secret Template Designer. Enable Remote Password changing must be turned on for Secrets created from the template to make use of this feature. Select the password type for the account and map the fields to be used for authenticating to the remote server.

Figure 5.1. Configure Password Changing Mapping

Secret Server makes use of the following list of ports to access the remote server. In order for RPC to work when the target computer is behind a firewall, verify that the correct ports are properly configured.

The Checkout feature forces accountability on Secrets by granting exclusive access to a single user. If a Secret is configured for Checkout, a user can access it, but after checking it in Secret Server automatically forces a password change on the remote machine. No other user can access a secret while it is checked out unless Unlimited Administrator Mode is enabled. This guarantees that if the remote machine is accessed using the Secret, the user who had it checked out was the only one with proper credentials at that time.

	Note
	The exception to the exclusive access rule is the Unlimited Administrator role permission. If Unlimited Administration is enabled users with that role permission can access checked out Secrets.

Secret and User Auditing provides trails within Secret Server. It doesn't prevent the case where users write down passwords and use them at a later time without accessing the Secret. If that happens no audit record is generated and there is no quick way to verify which user had access to the credentials at that time.

To configure Checkout navigate to the RPC administration page and select Enable Secret Checkout. If RPC is turned off it will need to be enabled before Checkout can be configured. Once RPC and Checkout are enabled, certain Secrets can be configured for Checkout.

Figure 5.2. Enable Checkout

Each Secret must be individually set to require Checkout. From the Secret View page open the Checkout tab to modify a Secret's Checkout setting. The Secret needs to be configured for RPC before Checkout can be set. If RPC is correctly configured Require Checkout to force users to Checkout the Secret before gaining access.

Figure 5.3. Configuring a Secret For Checkout

After Require Checkout is enabled users will be prompted for Checkout when attempting to view that Secret.

Figure 5.4. Exclusive Access

Any user attempting to view a checked out Secret will be directed to a notification dialog informing them when the Secret will be available next.

Figure 5.5. Exclusive Access

Secret Server automatically checks in Secrets after 30 minutes. Users can choose to check in a Secret earlier from the Secret's page.

For a user to be an Unlimited Administrator they must be assigned a role with the Unlimited Administrator Permission and Unlimited Administration Mode must be set in Configuration.

To navigate to the Unlimited Administration Mode secetion, you will need to click the Administration link on the header navigation bar, then click the Configuration link, then click the Change Administration Mode button.

	Note
	Changes to Admininstration mode are logged in an audit grid. The grid shows the user, time of the change, and any notes made by the user.

Figure 6.1. Configuring Unlimited Administration

Secret Server allows administrators to manage users through groups. Users can belong to different groups and receive the permissions attributed to those groups. This setup simplifies the management of the various permissions and roles that can be assigned to a user. Additionally, groups can be synchronized with Active Directory to further simplify management.

You can create and edit groups from the Groups page. By either selecting an already existing group from the list, or clicking the "Create New" button, you can modify or add the group.

Figure 7.1. Groups Page

On the Group page users can be added and removed from groups. Use the arrow buttons to move users into and out of the current group. If needed a group can also be enabled or disabled from this page. When you have finished with your changes, click "Save" and your new group members will be incorporated.

Figure 7.2. Group Page

Group membership can also be handled on the Group Assignment page, which can be navigated to by clicking the "Assign Groups" button on the Groups page. Here you can assign users to groups and groups to users.

Figure 7.3. Group Assignment

Secret Server uses different types of encryption to ensure data security. Every field on a Secret is encrypted at the database level with the Advanced Encryption Standard (AES) 256 bit algorithm. Database encryption prevents unauthorized access of sensitive data on the server.

The AES encryption algorithm provides a high level of security for sensitive data. The creation of AES was instigated by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) to find a replacement for the Data Encryption Standard (DES), which had numerous issues, namely small key size and efficiency.

	Note
	Encryption algorithms use keys to obfuscate the data. While DES only had a key size of 56 bits, AES can have a key size of 128, 192 or 256 bits. Larger keys provide more security as their size makes brute force attacks infeasible.

To address concerns from the cryptographic community, the NIST embarked on a transparent selection process. During the selection process the NIST solicited designs from the global cryptographic community and voted for a winner from within fifteen finalists. The eventual winner was a team of Belgian cryptographers with their submission of the Rigndael encryption method.

For more information about the technical specifications of AES, please see the official standard.

Secret Server user's passwords are hashed in the database using the SHA 512 hashing function. A hash function differs from an encryption method such as AES because a hash function is practically impossible to reverse. Hashing algorithms are mathematical functions to replace inputted text values with numerical ones. If the input text is the same, the final hashed value will also be the same. The input text of "fox" will always produce the same hashed value. Minor changes in the input value will radically alter the hashed output, as shown in the examples below.

Secret Server can be configured to run using Secure Sockets Layer (SSL) certificates. It is strongly recommended that Secret Server installations run using SSL. Not using SSL will significantly reduce the security of the contents of Secret Server since browsers viewing the site will not be using an encrypted connection.

Two Factor Authentication is a method of strong authentication that requires two different forms of identifaction instead of the traditional single password. Secret Server uses this design by allowing Administrators to require Two Factor Authentication through a confirmation email for designated users. For additional information on Two Factor Authentication please see http://en.wikipedia.org/wiki/Two-factor_authentication.

Users who access Secret Server from laptops or other mobile devices are more vunerable to having a device stolen. Requiring multiple forms of authentication provides additional security against theft or attempts to crack a user's password.

From the Users administration page, select a user to configure for Two Factor Authentication. Edit the selected user and enable the Two Factor Authentication option. Verify that the correct email address information is set, as that address is where the confirmation email will be sent.

Figure 10.1. User Edit Page

The next time that user attempts to login to the system, a unique confirmation code will be emailed to them. The user will then be required to enter a new confirmation code at each login.

Figure 10.2. Confirmation Code Prompt

Secret Server requires that a connection to a SMTP server be properly configured to send out confirmation code emails. Enter the SMTP server information and an email address that will be used to send notifications.

Figure 10.3. SMTP Configuration

When configuring Secret Server to an SMTP server, the server's availability can be verified through Telnet.

In the command prompt run the following : "telnet servername 25", servername being the SMTP server, and 25 being the port Secret Server attempts to connect through. An example command would look like "telnet smtp.somesite.com 25".

If virus protection is running, a rule to allow aspnet_wp.exe to send e-mails may be needed.

Secrets are individually named sets of sensitive information derived from Secret Templates. Flexibiilty in templates allows Secrets to address a broad spectrum of secure data. Secret security can be centrally managed through view/edit settings for each individual Secret. Additionally, the folder structure allows one or more secrets to inherit permissions from a parent folder. All Secret field information is securely encrypted within the database.

Secrets are initially created from the home page. From the Create New Secret dialog, create a Secret using one of the Secret Templates found within the drop down menu.

The New Secret page will display the corresponding fields of the Secret Template selected. Fill in the relevant information for the new Secret and Save when finished.

	Note
	Depending on the particular Template settings of the Secret, some fields may be required. All required fields throughout Secret Server are marked with a blue "*".

Figure 11.1. New Secret Page

To view and edit a specific Secret, simply search or browse for it on the home page, then select the specific Secret from the results grid.

Due to auditing concerns, Secrets cannot be completely deleted from the system. Instead, Secret Server allows users to mark Secrets as inactive. Inactive Secrets do not show up in searches - unless specified - and are not autochanged when they expire. Inactive Secrets are practically non-existant within the system.

From the Secret Edit page, uncheck the Active option to inactivate a Secret. Simply re-check the option to reactivate the Secret.

With the Remote Password Changing add-on, Secrets can be configured to automatically change upon expiration. A Secret Template that is set up for password changing has the option to Autochange. When any Secret created from the configured Template expires, Secret Server automatically generates a new strong password and changes the remote account.

Secrets also offer the option to force a password change regardless of expiration settings. From the Secret page, Change Password Remotely will immediately schedule the Secret for password change. Change Password Remotely differs from expiration in that it dictated by the user rather than a scheduled change. Forcing a password change also generates a specific audit record that indicates the change was not initiated by expiration.

Sharing passwords is crucial for information technology teams. Due to the sensitive nature of sharing secure information, Secret Server takes all necessary security measures to ensure that shared passwords are tracked and guarded.

There are three different levels of permission to choose from when sharing secrets with another user or group of users: View, Edit and Share.

For example, Administrators need Edit permissions to the router password, but a contractor doing network upgrades might only need View (read only) access on that same Secret.

Secrets can be shared with either Groups or individual Users. From the Secret View page, Share allows Secrets to be configured for access.

Figure 11.2. Sharing Secrets

Sharing a particular Secret with the desired Users or Groups can be adminstered from the Group/User drop down list. Permissions for each entity are set on the grid displaying everyone that has access to the Secret.

To further simplify the process of Sharing, Secrets can automatically inherit permissions from the folder they are located within. By simply selecting the option, Inherit Permissions from Folder, a Secret will inherit all the parent folder's Share permissions.

	Note
	In a similar way, permission management on Folders can be simplified by setting Folders to inherit permissions from their parents. For more on Folder security, see the section on Folder configuration.

Folders allow you to create categories based on region, customers, branch offices, business partners, departments, etc. Folders can be nested within other folders to create further sub-categories for each set of classification. Secrets can be assigned within these folders and sub-folders.

Figure 11.3. Folder Tree View

From the Folders Administration page, create a New Folder. By default, a new folder will be created at the root level. To create a nested folder, select the parent folder from the folder tree before creating the New Folder. When a new folder is created, specify its name and whether it should Inherit Permissions from Parent.

Figure 11.4. Creating A Folder

Folders have the same permission structure as Secrets: Edit, View and Share. To create folders, users must have the Administer Folders role permission and have Share permissions on the parent folder. Folders are invisible to any user that doesn't have View permissions. This allows users to create and manage their own folders without being visible to all users. Users also require Edit permission on a folder to be able to add secrets to it.

Nested Folders can inherit permission settings from the parent folder. This can either be set when the Folder is first created, or by editing a specific Folder from the Folder Administration page. A user must have Share permissons on the Folder in order to grant other users to have permissions on the Folder. Once inheritance is set, that Folder has the same access rights as the parent.

Figure 11.5. Editing Folder Permissions

From the Backup Administration page, specify the correct folder paths for the IIS Secret Server file directory and the database backups to go. The backup path must be local to the server where the Secret Server database or file directory exists. The folders must also have the proper permissions to allow Secret Server to automatically place backups in them. The account that needs permissions will be displayed as an alert on the page.

There are numerous options to consider when backing up Secret Server. Backups can be scheduled to run on a specific time interval. To prevent the directory from growing too large, the number of backups to keep can be defined as well. Depending on size constraints or preferences of the DBA who would be administrating a disaster recovery scenario, the database backup can either truncate the transaction log or keep it intact.

From within the Export Administration page, select the folder that needs to be exported. By default, all Secrets will be exported if a folder is not selected. In the event that no particular folder is selected, all Secrets will be exported by default. The administrative password must be entered, as it is a security measure to verify the permission of the user performing the export.

Note

Internet Explorer requires a change to the browser in order to have the Administration Export work properly. Your Secret Server instance needs to be added to the Trusted Site zone, then edit the trusted site zone by selecting the "Trusted Site" and click "Custom Level ..." and enable "Automatic Prompting for File Downloads". Firefox requires Secret Server to be added to the "Allowed Sites - Popups". Please note that regardless of the browser, all popup blockers must be disabled for the export to work correctly.

Exports can be configured further with options to Export With Folder Path and Export Child Folders. Export With Folder Path adds the full folder path to the export. Folder paths in the export file provide organizational structure if Secrets need to be imported at a later date.

By default, the option to Export Child Folders is active. While this option is enabled, any export of a specified folder will also export content located in folders beneath the inital selection.

Figure 12.1. Configuring An Export

Secrets are exported as a comma separated file (csv), which can be easily handled in Excel or other spreadsheet applications. The file is grouped by Secret Templates and each cluster of Secrets has a header row that contains the Template field names and is followed by all the exported Secrets of that Template.

Secrets are exported in the exact structure as a Secret Import. As long as exports are maintained, an installation of Secret Server can be completely reproduced on a seperate instance by applying the exported file.

Secret Server's Import feature simplifies integration with legacy systems and allows users to easily add large numbers of Secrets from an Excel or csv/tab delimited file. Secrets are batch imported by Template, so multiple types of input data will need to be imported in several batches.

From the Tools page, Import Secrets to begin the process. A Template corresponding to the type of data in the input file must then be selected, then Continue to add the Secrets.

Paste the Secrets for import directly into the text area in the Import Secrets dialog. The order of the fields being imported will be listed depending on the Template selected. A few items to note when importing Secrets :

There are two options for importing Secrets, Ignore Duplicate Secrets and Import With Folder. Ignore Duplicate Secrets will prevent importing any Secrets with the same Name of an already existing Secret. Import With Folder allows an additional field in the import text specifying a fully qualified folder name for the Secret to be created in. Secret Server will display a preview of the new Secrets prior to being imported.

Figure 13.1. Sharing Secrets

Secrets can be located either at the root level or in a user created folder. Secrets can be added while creating a folder or by editing an existing folder. When creating or editing a Secret, select the Folder field to display a Folder Picker dialog. Choose the desired location from the folder tree and then select Save on the Secret to apply the new location. Users must have Edit permissions on a folder in order to add Secrets to that particular folder.

Figure 13.2. Picking a Folder

Secrets can be searched for in multiple ways. Search parameters are defined from the Secret Search dialog on the Home page. To make searches more precise, secrets can be searched by templates or sorted to exclude Inactive Secrets. Searches will only index the Secret name field if the Search Indexer is not turned on.

The option of searching within a folder is available from the Home page. Selecting and highlighting a folder from the Search By Folder dialog will filter the search result to items within the selected folder. If Include Subfolders is turned on in the Secret Search, the search will return Secrets in the subfolders of the highlighted folder as well.

	Note
	Browse All is a quick way to view all active Secrets available regardless of folders or search parameters.

Figure 13.3. Searching Secrets

The Search Indexer allows searching on all fields within a Secret. From the Search Indexer administration page, select Edit to configure and enable the indexing service. Save any changes and the Indexer will start indexing all the Secrets. The progress is displayed on the Search Indexer administration page and indexing may take some time depending on the size of the installation. The indexer runs in the background to avoid the undesirable effect of decreased performanace caused by using full server resources.

Figure 13.4. Search Indexer Administration

Standard Search mode is the default search mode. Standard searching creates indexes on the values of each field, however it will only search on whole words on a field value. For example, a secret with a field value of "Thycotic" would only match a search for "Thycotic".

Extended search allows searching on whole words, or a partial word by up to three letters. For example, a secret with a field value of "Thycotic" would match on a search for "Thycotic" or "thy", or "cotic". This allows for more fine grained search results, but may impact search perfomance and will also create a larger index table.

Figure 13.5. Search Indexer Edit

Secret Server is a highly customizable application. Administrators can increase site security through various configuration settings such as force inactivity timeouts and specifying a SMTP server. This level of configuration allows Secret Server to be altered to meet the needed requirements for the instance.

Administrators can specify requirements for local login passwords. Due to the fact that Secret Server holds sensitive information, it is a best practice to make sure User's passwords meet well defined strength requirements. Passwords can be strengthened through five available options.

Secret Server can restrict user access by preventing certain IP addresses from entering the site. IP restrictions increase security by guaranteeing certain sets of computers cannot gain access to the instance. For example, an Administrator might want to only allow access of IP addresses originating from developer machines. The administrator could in turn block out entire ranges of IP addresses, such as help desk computers or publicly accessible workstations.

To add a new set of addresses, Create New ranges from the IP Address administration page.

Figure 14.1. Configuring An IP Address Range

Add the IP address with the minimum value as the Start IP Address and the highest IP as the End IP Address.

Once an IP address range is set, it will need to be applied to specific users to take effect. From the User Edit page, Change Restrictions to apply a range to a user.

Secret Server offers a variety of usage reports. These reports allow Administrators to better understand how users are utilizing Secret Server.

The Secret Expiration Health report shows the number of secrets within the system in various stages of expiration. Colors displayed are red to green which correspond in range from expired secrets to secrets that will only expire in more than 60 days. This is a good indicator for the overall health of the secrets in terms of age (frequently changed passwords are more secure).

The Secret Template Distribution report shows the percentage and number of secrets based on their Secret Template within the system. This typically indicates the most popular types of information being stored.

The Secret Server Usage report shows the number of secret audit activity records (view, edit, sharing) over the year (defaults to current year). This report is an indicator of overall usage of the system.

The Top Ten Viewers report shows the ten users who have viewed the most secrets over a date period (defaults to year to date).

Figure 15.1. Administrative Reports Page

Secret Server implements a detailed tracking system for actions made on secrets. Auditing users is an indispensable component of any password management system. The audit trail allows Administrators to know which Secrets were accessed and ensures that Secrets are being properly used. Additionally, the User Audit report helps SEC regulated companies comply with the Sarbanes Oxley Act of 2002 as well as other regulatory compliance mandates.

From the Reports page, on the Reports - User Audit dialog select a User and a date range to view, then Search History to view the user's audit trail.

Figure 16.1. User Audit

The audit search displays results for all of the Secrets the selected user has viewed or edited during the selected time period. The administrator has the option of expiring all of the viewed Secrets, to notify users to change sensitive information, or to force password changing (if the Remote Password Changing add-on is configured).

To get a full view of the actions taken on a particular Secret, select that Secret from the results list. The Secret Audit displays the specific user actions for a Secret.

Secret auditing provides a detailed view of each change or view on a Secret. Secret Audits are taken for the following user actions:

For certain audit items, action notes are added providing additional details. For example, if permissions are edited, an audit record is generated detailing which users or groups gained or lost permissions. Detailed audit records add accountibility to sensitive Secrets where auditors or administrators need to know exactly what was modified.

Figure 16.2. Secret Audit

Secret Server's licensing model allows for scalability and enhanced core functionality in the form of add ons and user packs. Licenses can be purchased for these items:

Once a license is obtained, it can be installed by copying the license name and code into the corresponding fields on a new License page.

Figure 18.1. License Installation

By default Secret Server is set to a 'slate' theme unless specified within the Configuration settings. Secret Server comes with three other bundled themes: Classic, Corporate and Blue Chrome. To enable theming, Allow user to select theme must be checked on the Configuration page.

Figure 19.1. Themes

Themes may be downloaded through the Secret Server Gimmies program. Users with support are invited to take advantage of the Gimmie program's regularly downloadable content, including free themes. Additionally, support allows voting for features -including new themes - through Wishlist.

Themes are controlled from style sheets and a central image directory within a theme folder. A guide for creating new themes is available in the form of a CSS document noting how each line affects specific aspects of Secret Server's appearance. CSS help, properties and tags are listed with examples at www.w3schools.com.

Prior to downloading Secret Assistant, make sure that webservices are enabled in Secret Server. Webservices are controlled from the Configuration Settings. To watch a video of setting up Secret Assistant, please see the movie posted to the Thycotic site.

Webservice methods are provided if there is a need to integrate third party applications with Secret Server. Webservices allow access to a limited portion of Secret Server's functionality. Secret Assistant is an application that makes use of Secret Server's webservices.

Webservice access to Secret Server is controlled from the Configuration page. If webservices need to be allowed the Enable Webservices option should be checked.

To view the webservice methods, navigate to the Secret Server instance and replace the page with "webservices/SSWebservice.asmx". For example if the site is http://localhost/SecretServer, the address for the webservice page is "http://localhost/SecretServer/webservices/SSWebservice.asmx". Each method is defined and can be tested on that page. The available methods are as follows :