Customizing Roles For Your Company – Part Two

31 05 2013

In Part One of this two-part series we discussed setting custom Roles inside of Secret Server. In this section we will discuss the three ways to set Permissions on Secrets within Secret Server.

Roles give a user the ability to perform actions inside Secret Server, whereas Permissions dictate the level of control a user has within Secret Server. There are three Permissions within Secret Server:

  1. View, which allows a user to see a Secret/Folder.
  2. Edit, which allows a user to change Secret/Folder information.
  3. Owner, the highest level of control which grants a user the ability to change advanced security settings for a Secret/Folder.

Permissions can be bulk-assigned by Folder. By default Secrets inherit the Permissions of the Folder where it is created. This set up requires two steps. First, create a folder structure that is separated by Permission level. Typically, this would follow your company’s team structure. For example, you could configure folders in the hierarchy:

  • IT Management Team
    • Server Admins
      • Server Admins
  • Finance Management Team
    • Staff Accountants
      • Book Keepers

Second, assign Permissions to each folder based on the users that need access to that information. Now, when a Secret is created inside a folder it will automatically be assigned the Permissions of that Folder.

Permissions can be individually assigned to specific Secrets. When setting up Permissions in this way, Folders are used primarily as an organization tool and typically are named in a much more general manner, such as:

  • Servers
    • Windows Servers
    • LINUX / UNIX
    • Apache
  • Databases
    • MS SQL
    • MySQL
    • Oracle

When assigning Permissions to individual Secrets, the Secret will not inherit Folder Permissions and can be placed in a Folder alongside Secrets that have different levels of Permissions. To ensure Secrets do not inherit Permissions from the Folder, update your product settings by going to Administration > Configuration and setting the Default Secret Permissions to “Only Creator Has Permissions to New Secrets”.

Permissions can be bulk AND individually assigned. It is also possible to set up Secret Permissions through a combination of the options above. In this case, you would use the Folder to push Permissions to the Secrets through inheritance when a Secret is created. Once this is complete, Secrets do not have to stay within that Folder. Inheritance can be turned off for individual Secrets afterward to allow assignment of custom Permissions.





Breaking the Glass With Unlimited Administration Mode

28 05 2013

What happens when a user creates Secrets and does not share them with anyone else, or if you are administrating Secret Server and need to re-organize your Secrets?

Secret Server’s “break the glass” feature, Unlimited Administration Mode, can help in those situations.

The Unlimited Administrator Mode allows designated users to manage Secrets they would normally not have access to. Administrators with the “Administer Unlimited Admin Configuration” role permission can enabled this by going to Administration > Configuration and selecting “Change Administration Mode”. Administrators can enter any optional notes explaining why they are enabling or disabling it, as well as creating an audit trail of this setting. A banner also appears in the header indicating to other users that Unlimited Administration Mode is turned on.

Unlimitedadmin2
When enabled, users that have the “Unlimited Administrator” role permission can now access all Secrets and folders (with the exception of DoubleLocked Secrets), regardless of permissions, and all features of the Secret Server. Having a separate role permission allows administrators to specifically assign which users will be affected by the setting. Typically these should be very trusted people in the organization.

Unlimited Administration Mode is powerful, and can be locked down by to prevent abuse by ensuring no user has both permissions “Administer Role Permissions” and “Administer Unlimited Admin Configuration”. If no role has the “Unlimited Administrator” permission by default, then it will take two users to effectively turn Unlimited Administration Mode on: One user to enable it in configuration, and the other user to grant the permission to users or groups.

You can also have administrators notified by email when Unlimited Administration Mode is turned on or off by using event subscriptions. Our Knowledge Base article, How to protect the Unlimited Admin Mode using Event Subscriptions, details how to set that up.





Customizing Roles For Your Company – Part One

10 05 2013

Secret Server uses Roles and Permissions to control access to various capabilities within the system.

In this two part blog post we will review how to set up customized roles and permissions to meet your company’s security policy.

Roles in Secret Server control what a user is allowed to do in the tool. Secret Server ships with three default Roles:
1. Administrator, which has the ability to perform any task.
2. User, which allows basic functions such as create, edit and viewing of Secrets.
3. Read Only User, which only allows a user to view Secrets and Audit Reports without edit capabilities.
Although Secret Server can be used right out of the box with these default Roles, each company should personalize the Roles to fit individual company needs.

Role

The default Roles can be edited and new Roles can also be created. For example, administration tasks can be delegated to different Administrators without giving them full control of the system (for example: Backup Administrator, Secret Template Administrator, Role Administrator and so on). An Auditor Role can also be created to give a user limited access to the system – such as to view Reports and to check compliance settings without having access to sensitive information. For more information on Roles, see our Secret Server Best Practices Guide (requires valid support).

Auditor Role

In the next part of this post we will go over how to set up permissions to control access to Secrets and Folders.





Restricting User Input for Launcher

3 05 2013

A new feature in Secret Server is the ability to control which servers users are able to connect to using a Launcher. This can be done by specifying a list of machines or servers on a Secret in a notes field. This list can either be a whitelist or a blacklist of servers the Launcher is able to connect to.

When configured as a whitelist, a list of possible servers will be presented for users to select to launch. This prevents users from logging in to places they should not be, and adds convenience by not having to remember the name of each server.

When configured as a blacklist, this allows users to enter the machine or server name as they normally would, however would prevent them from connecting to those machines which are blacklisted. This will prevent unauthorized use of credentials in your environment.

RDP1

Enabling this feature is simple through Secret Server. Navigate to Administration, Secret Templates, then select any template with a Launcher attached such as the Active Directory Account or Windows Account Template and click Edit. There, you can select Configure Launcher, and Edit.

In the Advanced section, enable Restrict User Input by checking the checkbox, and configure accordingly. When mapping a field to Restrict By Secret Field, specify a field from the template. The values for the whitelist or blacklist will be based on that field for Secrets, and can be comma separated to specify multiple machines or servers.

RDP2

Then it’s configured.








Follow

Get every new post delivered to your Inbox.

Join 30 other followers