+1-202-802-9399 (US)

Thycotic’s Cyber Security Publication

What’s New in Secret Server 8.9?

Written by Thycotic Team

August 26th, 2015

Secret Server 8.9 looks to answer a few important discussion points that have been around the application for a while now. First, a popular customer request – more granularity of permissions. Next, scalability and efficiency of network operations – the birth of Distributed Engine. And finally, a level of security for RDP launchers to match the SSH Proxy feature – the introduction of RDP Proxy.

Distributed Engine

This feature is a replacement of the current “Agent” feature in Secret Server. The concept is very similar – having other computers perform password changes or other features such as discovery, thereby utilizing their processing power to perform tasks that the server where Secret Server is installed would normally do. The difference is that Distributed Engine brings a lot more scalability to the table than Agent had, and can also perform discovery on remote networks. Currently, Agent performs a synchronous operation – when Secret Server assigns a task to an agent, the agent performs the task and reports back. Secret Server is waiting for the Agent to report back, so however long the task takes is however long Secret Server will be waiting before assigning any more tasks. Distributed Engine will be asynchronous – Engines can be grouped in “Sites” which they connect to in order to retrieve work (such as Password Changes, Heartbeat, and Discovery). Administrators can choose between MemoryMq and RabbitMq for their queuing service – the former requires no third-party dependencies other than .NET, while the latter is a third-party, robust queuing service that is open source and commonly used in many environments. A note about security – sites used for Distributed Engine can be configured to use SSL, and information transmitted is already encrypted both at rest and in transit; SSL is just another layer of encryption.

Advanced Permissions

Permissions are gaining more granularity as requested – the View, Edit, and Owner permissions have been around for a while, but in practice have proven to not be granular enough for the needs of some environments. A user or group’s permissions for a folder can now be set separately from the permissions he/she/it has on Secrets in that folder. For example, I could set a group to have View access to the folder, but Owner on all Secrets in the folder – this will allow the group’s members to see the folder and modify Secrets in it as they see fit, but they will not be able to rename the folder, move it, or change permissions on it. Two new permissions join View, Edit, and Owner – “Add Secret” for folders and “List” for Secrets. The former allows a user to add secrets to a folder, but not see what is in the folder. This is a common use case we have seen and represents a “drop box” scenario where for example a data entry person will need to add contacts to a folder, but not have access to view them after adding them (the principle of least privilege comes in here – what if the data entry person’s account got hacked?). In addition, the user could be given “None” as Secret permissions, meaning he/she won’t even be able to see that Secrets in a folder exist. The latter of those two, “List”, will allow users to see that Secrets exist and what they are named, but not their fields such as passwords, credit card numbers, etc. (see Figure 1 for what a user will see with just List permission on a Secret on Dashboard) If a user has the global role permission “View Secret Audit”, then he/she will be able to view the audit of a Secret he/she has List permission on. This is another common use case – auditors want to see the activity on a Secret, but should not be given access to its sensitive information. Permissions stack with each other, so users that have View permission on a folder are implicitly given the permission to add Secrets to that folder as well. For more granularity, look into assigning Roles and Role Permissions to users and groups – these globally affect the permissions that users and groups have all around Secret Server.

permissionblog

Figure 1: A user with List permission on a Secret will see this on Dashboard. Notice that because the user has the global role permission for “View Secret Audit”, he/she can view the audit without having access to the Secret’s sensitive information.

RDP Proxy

As a setting on Secrets themselves or on Secret Policy, Secrets using RDP Launcher can now have their connections proxied through Secret Server. RDP connects to Secret Server instance, then the Secret Server instance forwards the connection to the target Server in the Secret. This ensures that all incoming connections are forced through Secret Server, which helps for auditing and accountability – for example, you could force proxying for all Secrets for a machine and then set up firewalls to deny connections from anything except the Secret Server address. The sky is the limit with how you can set up your network and manage your machines, but now RDP Proxy is yet another tool in your inventory as an administrator.

IT Security should be easy. We’ll show you how.

Try Secret Server and experience how FAST & EASY
IT security products can be.

SHARE THIS


The following two tabs change content below.

Thycotic Team

We deploy smart, reliable, IT security solutions that empower companies to control and monitor privileged account credentials and identities.