- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
Thycotic released the first version of its Secret Server privileged account management (PAM) solution in 2005, and the company's been on a proverbial "rocket ride" ever since. For example, at the PowerShell + DevOps Global Summit this year I was taken aback by (a) how many IT ops and developers I spoke to who use Thycotic Secret Server daily in their businesses and (b) how enthusiastically they spoke about the product.
The problem in a nutshell
A "privileged account," in Thycotic's nomenclature, is a non-human account that has significantly more privilege than a standard human user account does. Examples of privileged accounts include the following:
- Built-in Administrator and Domain Administrator accounts in Windows
- The root accounts in UNIX, Linux, and OS X
- Service accounts
- Database admin accounts (like sa in Microsoft SQL Server)
We all know that the best passwords are those that are as close to random as possible. For instance, I myself use LastPass to manage all my online account credentials. I instruct LastPass to auto-generate strong passwords, and I never need to know what they are. In fact, it's better that I don't remember the passwords myself.
In business, it can be a major pain in the neck to remember complex passwords for privileged accounts. It's even more difficult to rotate the passwords on any kind of regular basis.
Thus, the counterbalance of high security and administrator convenience defines the problem set. Now we'll examine how Thycotic Secret Server can solve the problem directly.
Install Thycotic Secret Server
Technically speaking, Thycotic Secret Server is an on-premises ASP.NET Web application. This means two things right off the bat:
- You'll need at least one Windows Server box running IIS and SQL Server.
- Administrators and end users interact with Secret Server principally through a Web console; there is no agent software required.
Thycotic allows you to download a full-featured 30-day trial with access to support; head on over to the Thycotic web site and register. After submitting your contact information, you'll receive an e-mail message from Thycotic Sales and Support that contains evaluation license keys and a link to the .msi installation package.
Installing the binaries was pretty easy. Keep the following points in mind. You'll need to:
- Point the software to a SQL Server instance; this can be the full version of SQL Server Express 2012 or later.
- Specify a database account for Thycotic Secret Server to us. My SQL Server runs in mixed-mode, so I used the built-in sa account, but a less privileged account can be used as well.
- Ensure that the server's default database collation is SQL_Latin1_General_CP1_CI_AS
Thycotic Secret Server is in many ways a "garden variety" ASP.NET web application that runs in IIS. This means, for instance, it's quite easy to secure the site with SSL.
If you can manage IIS, then you can manage Secret Server
Configure the environment
As you saw in the previous screenshot, Secret Server installs by default as a virtual directory under your default Web site. Of course, this location is customizable. Pop open your browser and navigate to http://localhost/SecretServer to complete the Secret Server Setup wizard, as shown in the next screenshot.
The Secret Server Setup wizard
Initial configuration involves the following three steps:
- Licensing: Paste in your trial keys here to activate Secret Server for 30 days.
- Email: Point Secret Server to your business's SMTP mail server so the product can send alerts and report messages.
- Groups: Organize the populations that will access the stored secrets. For instance, you may have an Admins group for IT administrators who need to access all secrets, a HelpDesk group for people who need access to some secrets, and an Auditors group for audit personnel who only need to see reports.
Thycotic defines a "Secret" as any data that you need to keep confidential. This embraces far more than high-privileged user and service accounts. You're likely to have hundreds of secrets built up in your Secret Server installation, so spending the time on the front end to define access groups is a good idea.
Moreover, all Secret Server users can populate their secrets in their personal folder hierarchies in the Web console. The following screenshot gives you a high-level walkthrough of the Secret Server Web console's home dashboard page:
The Thycotic Secret Server administration dashboard
- A: Personal secret folder(s).
- B: Global secret folder(s).
- C: A secret entry. Note that each secret is associated with a template (more on that in a moment).
- D: Secret details. We'll learn how to create secrets shortly, I promise!
- E: Top navigation bar, which is handy for global search, admin, reporting, and help.
- F: This is the Advanced view; there's also a much simpler Basic dashboard view.
- G: Create a new secret by opening this template list.
Let's create a new Secret! From the dashboard, we open the Create New Secret drop-down and choose a template. For instance, in this example, I'll choose Active Directory Account. To give you a feel for the breadth of credential support, let me list some other template choices:
- Cisco account (SSH or Telnet)
- Combination lock
- Contact
- Credit card
- Linux SSH key
- Office 365 account
- Unix root account (SSH or Telnet)
- Web password
And yes, in case you were wondering, you can in fact create your own secret templates. Specifically, a template not only defines the metadata fields that surround your secret but also attaches launcher options. (Once again, we'll get to launchers momentarily.). Check out the following screenshot, and I'll explain what's going on:
Defining a new Secret
A: Choose the appropriate template.
B: You can instruct Secret Server to auto-generate super-complex passwords. This is great security, and you don't need to remember the password anyway!
C: The Notes field can be helpful in compliance/audit scenarios.
D: Organize the secret into administrator-defined global folders, as previously mentioned.
E: Secret policy is immensely powerful. You can do stuff like approvals and automatic password rotations
It's beyond our scope to discuss this today, but Secret Server also supports Active Directory credential discovery. Read more about it in the Thycotic Secret Server documentation.
Use Secret Server in production
The question of the day is, "Okay. I've installed Secret Server, defined secrets, and organized access policy. Now how do I actually USE the stored secrets?" Well, I'm glad you asked.
One method is simply to view the secret's entry in the Web console and copy/paste the credentials to your target application. That's okay, but not very slick. What's nicer is that Secret Server includes a bunch of built-in launchers for different situations:
- Active Directory account secrets include an RDP session launcher.
- SQL Server account secrets include a SQL Server Management Studio launcher.
- Linux/UNIX SSH secrets include an SSH launcher (such as PuTTY).
In the Web console, click Tools > Launcher Tools to install the Web Password Filler bookmarklet and/or the Secret Server Protocol Handler extension. Since Secret Server is an extensible platform, you can of course author your own launchers.
The Secret Server launchers make using stored credentials easy
The launcher idea is cool because you never have to view the underlying secret credentials. For instance, the RDP launcher connects you to the target system and transparently injects the stored secrets.
The administrative scripter or programmer can access Secret Server programmatically via its RESTful APIs. Also, please check out Warren Frame's excellent Secret Server PowerShell module. Warren's module enables you to fetch secrets from Secret Server by using simple PowerShell syntax.
Finally, you'll want to click Reports from the Dashboard home page. Many (dare I say, most?) businesses are under some sort of industry and/or governmental compliance regulations nowadays. To that point, it's crucial for you to demonstrate your password policies and storage methods.
What I like about the Secret Server reporting engine is that the pre-configured reports are so intelligently designed. Take a look at the following screenshot and decide for yourself:
Secret Server reports are described in user friendly language
Closing details
Thycotic sells Secret Server licenses at three edition levels: Professional, Enterprise, and Enterprise Plus. Note that the pricing involves both the server license as well as user licenses.
Thycotic also has a scaled-back Secret Server Cloud Edition that's aimed at individuals and small businesses.
Subscribe to 4sysops newsletter!
I've met some of the people at Thycotic, and I admire this company very much. Additionally, like I said at the beginning of this article, the Secret Server users I encounter have a fierce loyalty to the product and its parent company.
How are the secrets/passwords protected at the DB level, are they encrypted? is an encrypted instance of SQL supported?
First result on a google search: https://thycotic.com/products/secret-server/features/aes-256-encryption/
Hi Ray. Yes, Secret Server encrypts all stored credentials using AES 256. More info here: https://thycotic.com/products/secret-server/features/aes-256-encryption/
Because Thycotic already encrypts its SQL Server database, it seems unnecessary to me to use another encryption method on it. Thanks for reading! Tim
Are IT organizations using secret server to store encryption keys?
You can store anything you want really. Secret Server supports customizeable templates that are essentially web forms. You can configure the fields you’d like to store, upload files, etc. The neat thing about storing encryption keys is that you can access them via an API (SOAP or REST) from your application to retrieve them automatically. If your app is Windows-based, integrated authentication is supported, so no credentials to store in a config file.
Regarding encryption, Secret Server also supports SQL Transparent Data Encryption for added security. You can configure SQL to use TLS for connectivity as well. Finally, you can double-encrypt the really sensitive stuff with a unique key configurable by each user.
Great Post! Does the API’s return secret from the secretserver in clear text or it has some level of security associated? I like the idea of built-in launchers but that’s useful only if someone try to access from the web. Are there any equivalent mechanism built for applications requesting for secrets programatically?
I cannot find anything in the Thycotic docs or in the videos that assures me that their secrets/launcher support the concept of a SQL Database contained user, meaning when I use the launcher for db1234 that is the only database out of the seventy on that SQL Database server to which I will be able to access via SSMS. In my “playing” with it I find that I have to create the login in master as well as my target database. This is approach means that secret could ultimately access all seventy databases with one secret.