Unlimited Administrator Mode Suggestions from a Secret Server Admin

20 08 2012

While responding to a different but related forum question, a Secret Server Admin made a good point:  Split the ability to enable Unlimited Administrator Mode and the ability to use it.  This is outlined in the Secret Server Best Practices Guide.  Here is a quote from the forum post:

1.) I encourage this on all SS installs. Separate the roles of both Enabling Unlimited Admin mode and Unlimited Admin from a user. Configure SS to require that one (or more) people are the only ones that can enable Unlimited Admin mode but not be an Unlimited Admin. The opposite for the Unlimited Admin, they shouldnt be able to put SS in Unlimited Admin mode. This prevents a single person from having the ability to flip the god switch.
2.) Setup event subscriptions/notifications that email all users of SS when Unlimited Admin mode is enabled.
3.) Direct all users to the appropriate report(s) that show what an Unlimited Admin did while that mode is enabled.

Splitting these roles into two different users or groups of users adds an additional layer of accountability to Secret Server.  One Administrator will not have the ability to authorize a switch to Unlimited Administrator Mode and consequently gain access to all of the secret data stored in the database.

Do you have questions, comments, and concerns about Unlimited Administrator Mode?  Please post in our forums:  http://www.thycotic.com/products_secretserver_forums.html

Secret Server SMTP Authentication

7 08 2012

As a tie-in to our previous blog post Secret Server and Secure LDAP, SMTP Authentication was another important feature released in Secret Server version 7.8.000036. SMTP Authentication was implemented as a direct result of customer requests. Many of our clients work in environments that require secure messaging. In this release and beyond, Secret Server now has the ability to authenticate to an SMTP server, use SSL, and even specify a custom port.

Some background: Notifications sent via email from Secret Server can contain sensitive information (but never passwords, of course.) The most common risks include spam, false or fraudulent claims, personal threats, social engineering risks (phishing, imposters, etc.), or even virus & malware propagation. While this solution does not offer protection against compromised accounts, it does severely limit the risks associated with running SMTP servers. In response, many organizations require SMTP authentication and SSL connections to their internal servers (as well as other requirements beyond the scope of Secret Server.)

We recommend using SMTP Authentication and SSL if possible. Enable SMTP Authentication is a short and simple process. You can access these settings in Secret Server with the following clicks:

Administration -> Configuration -> Email (see below)

SMTP Authentication options in Secret Server

SMTP Authentication was another important feature released in Secret Server version 7.8.000036. Access it via: Administration -> Configuration -> Email

As with any blog post, Secret Server, or general Thycotic Software question, please comment below or find support information here:  http://www.thycotic.com/products_secretserver_support.html.

Secret Server and Secure LDAP

23 07 2012

In April 2012, we released Secret Server v7.8.000036.  This was the first release to include support for Secure LDAP often referred to as LDAPS (and not to be confused with SLAPD!)  Subsequent releases of Secret Server will support LDAPS.  Since the release of LDAPS, it has remained a bit of an unintentional secret (no pun intended).  If you have Secret Server installed, check to see if you can enable Secure LDAP in your environment.

Using LDAPS:

Upon installation, Secret Server will use port 389 for LDAP traffic to Domain Controllers.  This does NOT mean passwords are transmitted in clear text.  It means that user and group names will be translated in clear text.  Passwords will be transmitted using Kerberos/NTLM.  However, with LDAPS available, all traffic including the user and group names will be encrypted.

Before enabling LDAPS, there is one feature that can potentially be affected.  If you are using a Domain Controller on Windows Server 2008 R2, Integrated Windows Authentication is supported with Secure LDAP.  However, if you are using Windows Server 2008 or older, Integrated Windows Authentication will have to be disabled when Secure LDAP is used.

How to enable LDAPS:

  1. Click on Administration -> Active Directory -> Edit Domains -> Select the domain you wish to edit (you can also create a new one here.)
  2. Click on Advanced as highlighted in the figure below.
  3. Put a check in the Use LDAPS box.
  4. Click Save And Validate.


Secret Server will now attempt to use LDAPS over port 636!  As with all Secret Server updates, the release notes are always published here:  http://www.thycotic.com/Secretserver_releasenotes.html.

Using the PuTTY launcher on custom ports

23 11 2011

Do you use custom ports for accessing your systems through SSH or telnet?  If you do, you’ll find that the launcher is configured for standard ports.  Configuring these ports requires the creation of a custom launcher and a few other steps.  This information is outlined in the Secret Server KnowledgeBase under the title: How can I run the PuTTY launcher on a different port?

This can be a useful tool for Secret Server users, especially in those situations that require a non-standard port.  While the jury is out on whether changing standard ports offers any real security, some situations may require them.  In Secret Server, creating a custom launcher for using custom ports will make life easier for Secret Server users.  The custom launcher will launch PuTTY, configure the client for SSH over the specified port, pass the credentials and grant access in one simple click!

Inheriting Permissions Based on Folders

29 07 2011

Inheriting Permissions based on Folders

It is possible for Secrets in Secret Server to inherit permissions from the folder where they are placed. For example, if you install a new managed switch in your network, instead of setting an Active Directory group or users for every network-based Secret, you set the Active Directory group or individual user accounts to the folder. That way, when an admin enters a new Secret into Secret Server they don’t have to worry about selecting all the people that need access. Instead, they can place it into the correct folder that already has the correct permission level. Not only does it save time, but it also ensures that everyone who needs access to a Secret has it.

Adding Permissions to a folder
First, move your mouse to the Administration tab, then select Folders.

Then select the folder you want to edit permissions on, select edit

From here you can add Active Directory groups and individual Secret Server users. They will have access to any Secret that inherits permissions with the level you select.

Having a Secret Inherit Permissions From a Folder

Click to expand the Secret, and then select view.

Now, select share.

From here, select edit.

Finally, check the “Inherit Permissions from folder” box.

That’s it! Now any user in the Active Directory group or one you manually added to the folder permissions will have access. You can also turn on this behavior by default with the “Default Secrets Inherit Permissions” setting on the configuration page. It is important to note that a user with folder-based permissions will have that level of access to any Secret in the folder .

Selection/Dropdown fields on Secrets

16 03 2011

Secret Server supports Selection/Dropdown fields but not many customers know about this feature.  In this example, you can capture the version of SQL Server as a dropdown field in your Secret.


Selection fields can be created by editing a Secret Template and adding a new field (Administration | Secret Templates | Edit).  Then choose the selection list icon on the Secret Template Designer screen.selection1

You can then add different field values … in our example, we added 2000, 2005, 2008 to represent the different versions of SQL Server for our SQL Server Account Secret Template.

Saved Searches in Secret Server Dashboard

14 03 2011

A little known feature in the new dashboard is the ability to “save searches”.  I didn’t know about this until one of the engineers showed me … it isn’t exactly a saved search but it is close.


  1. Drag the <All Folders> folder to the top to create a new tab. This will create a new tab with a Secret Explorer widget.
  2. Type your search term in the search bar and choose any other desired search parameters – in my case, I typed “cisco” and changed to only show “Cisco Router” templates.
  3. Click on the tab to rename it to match your search – in my case, I named my tab “Cisco”.


That’s it.  You now have a tab called Cisco that holds a saved search to find all your Cisco devices.  You can come back to this tab at any time to see the results of that search.



Sneak preview of the Secret Server app on Droid

7 07 2010

Here is a movie showing the basic proof of concept application working on the Android Phone simulator. It demonstrates authenticating to Secret Server, pulling down a list of Secrets. Then adding a Secret Server using the web browser and seeing it appear in the app.

This app should be available within 2-3 months.

The History of Searching in Secret Server

21 09 2008

[UPDATE 1/21/2010] Search term seperators no longer include period (as version 5.1). They are space, semi-colon, backslash, foward slash, and hypen.

In the recent month, we’ve had a lot of questions about how searching works in Secret Server, so I thought now would be a good time to answer as many questions about searching as possible.

Searching pre 5.0

Before the 5.0 edition of Secret Server searching was fairly limited. The only thing you could search on was the Secret’s name. Over time, the Search criteria grew a little, but still this main limitation was always there. As soon as you wanted to search on the actual values in the secrets, you were out of luck. The ability to search by the values in a secret was one of our most requested features.

Technical Limitations

The Secret Server development team has always had a keen sense to what customers wanted, and we typically implement feature requests based on feedback. However, this particular feature had a lot of technical barriers to solve before it could be implemented.

The main barrier we had to deal with was the concept of Secret Server itself. Secret Server is designed to be as secure as possible, and one of the pieces of this design is full data encryption. All of the values of a secret, aside from its name, are stored in the database encrypted. This makes searching the database impossible. If we wanted to perform a search, we would have had to pull back every secret from the database, decrypt it, and then search it. This clearly wouldn’t work from a performance angle, and didn’t scale well.

Searching as of 5.0

We realized we wouldn’t be able to do real-time searches on secrets. The barrier still remained though, how do we search secrets and not expose sensitive information? Our solution was a hash based index table.

A What?

Many systems, such as Windows and search providers like Google keep a search index. When you search Google, you really aren’t searching the entire Internet all at once, you are searching a dictionary of content that Google has built over time. Secret Server does something similar. The trick is to build an index but also keep it secure.

Secret Server 5.0 has a background monitor, the Search Indexer, that looks for changed secrets, about every 60 seconds it queries the database looking for unindexed secrets or changes in secrets. When you create or modify a secret, we flag that secret to tell the Search Indexer to re-index it.


The Search Indexer creates hashed terms from the values in a secret. More specifically for those technically interested, we use the HMAC-512 algorithm. A quick explanation of what this algorithm does is creates a one-way code. For example, if the word “book” was hashed, it would produce a unique output. However this output cannot be converted back into the original data, “book” in our case.

This technique is used when creating indexes. Let’s say we have a secret with a field called “Server” with a value of “OFFICE\Webserver01″. When the search indexer got around to indexing this secret, it would create a hashed value of “office\webserver01″. Whenever we create hashed terms, we always convert it to lowercase so that searching isn’t case-sensitive. This search index record would become associated with the secret.

Now, when a user does a search, we use the same hash algorithm to compute the hash term of what you are searching for (again converted to lowercase). We when search our index table for a match.

What About Partial Matches?

When we have a term like “OFFICE\Webserver01″, we produce hashes of “pieces” of the word. In this case, we would also produce specific hashes for “office” and “webserver01″. Notice that we split on the letter “\”. The same happens when a search is performed. This way if you searched for “OFFICE\Webserver02″, it would still come back with the OFFICE\Webserver01″ because the “OFFICE” term still matched. We do this for other letters as well, that includes spaces, backslashes, slashes, periods, commas, and semicolons.

Search Index Modes

The Search Indexer has two modes. Standard, and Enhanced. So far, all of the behavior I have described has been the “Standard” mode. The Enhanced mode works very similarly, however it also produces three letter partials. Using out “OFFICE\Webserver01″ example, we produce our hashes normally, but we also produce the partials. We would add hashes for “OFF”, “FFI”, “FIC”, “ICE”, etc. This allows partial matches to return.

So Many Results

The implementation sounds correct, but it has some room for improvement. Note that I said we split the terms on periods. That means if you searched for “foo@test.com”, it would return everything that had “com” in it, and chances are there are a lot of results. The splitting on the period seems to be the biggest culprit for undesired results coming back. Once you throw the Enhanced mode into the mix, it gets even more complicated.

Looking Forward

Nothing has been set in stone in terms of changes and when it will be implemented, but we have been kicking around a lot of ideas. The immediate one might be to consider removing the period from the characters that we split on. Another idea was ranking the results. Secret Server right now always returns secrets sorted by their name. It would make more sense if we returned results in order of the number of hash terms that matched and if the name matched as well.

I hope that clarifies some of the mystery surrounding search. If you have any additional feedback or questions, be sure to drop by our forums and let us know!

– Kevin

Sneak Peek: PuTTY Launcher

11 09 2008

putty1 One of a system administrator’s must-have items in his toolbox is PuTTY. PuTTY is a small, lightweight program that is perfect for telnet and SSH connections. It doesn’t require any installation, it’s just a single EXE file and you’re good to go.

A feature of Secret Server that I personally have always found extremely useful is the launching capability that we introduced with Remote Desktop. It’s very handy for starting Remote Desktop sessions. We decided to take it a step further and extend this functionality to PuTTY.

An initial obstacle that needed to be overcome was figuring out how to make sure PuTTY was on the client’s machine. The creators of PuTTY are generous, and fortunately they allow us to distribute PuTTY with Secret Server. Since the Remote Launcher capability is a Microsoft ClickOnce application, it seemed reasonable to distribute PuTTY with our application. This would avoid the need for users having to tell our application where to look for PuTTY, or us requiring that you have it in a certain location on the machine.

putty2 However, PuTTY is 500 kilobytes, and the initial application was a mere 12 kilobytes. 500K is small in today’s high tech world, but to reduce corporate bandwidth use, we only distribute it when you need it for the first time. That means when you make your first launch of PuTTY, we’ll download the application for you from your Secret Server installation, thus not needing an outside Internet connection, but after that it’s cached so you only need to download it once.

putty3Once PuTTY is downloaded successfully, the application will automatically start already logged in at the prompt. For the first release of the PuTTY launcher, we will only support SSH.

If you want to see additional launchers built into Secret Server, make sure you stop by our forums and let us know!

– Kevin


Get every new post delivered to your Inbox.

Join 30 other followers