Understanding Overcee Permissions

Introduction

Overcee is about delegation, we want you to use it empower your Service Desk, and to achieve this we have developed an incredibly powerful permissions system so that you control who can do what.

Unfortunately, with great power comes great complexity (or something like that), and it would be all too easy to make one little mistake and grant too much power to people who shouldn’t have it. So to combat this, we’ve prepared this little guide the permission system so that you can be better prepared to make full use of it.

What are Permissions

Each container in Overcee (Active Directory, Computer or Tool) can have users or groups linked to them by way of granting a permission. The permissions vary depending on the container type, but typically consist of, for example, Read and Write permissions. Granting these permissions allow that user or members of that group to perform various actions, which we get into detail about below.

Inheritence

Containers can be set to inherit permissions from their parent. If that parent is also inheriting, then the permissions from the top level which is not inheriting are passed down. Setting a container to not inherit permissions effectively blocks these permissions from higher levels from being passed down.

You should be aware of two specific cases however:

1. Container Administrators (users who have the Container Administrator option set in their user profile) can always access and modify the permissions on all containers.
2. Users with Edit Permissions right to a container can override the permissions on all child containers of that container.

How are Permissions Organised

Permissions are organised by container type.

Computer Permissions (Active Directory)

Active Directory containers have the following permissions:

Read

Specifies that users can see the computers in this container, and they can import the computers into computer containers that they have write access to.

Write

Users can modify the description of these computers and, if the relevant options are set in the Overcee configuration, can move and delete Active Directory computer objects.

Edit Permissions

Users can add, remove and modify the permissions of other users for this container and its children.

Execute

Setting this option means that the user or group can execute tools and tool sequences against the computers in this container. This is a global permission for these computer objects, and users will only be able to add these computers to a job if they have this permission.

Computer Permissions (Computer Container)

Computer containers are treated very much like Active Directory containers. The primary difference, however, is that Execute permissions cannot be set on Computer containers as that is set only on the Active Directory object.

Tool and Tool Sequence Permissions

Tools and Tool Sequences are governed by permissions much the same as Active Directory containers.

Read

Users can view the tools and tool sequences in this container, and view their configuration.

Write

Users can create, modify and delete tools, and modify their configuration.

Edit Permissions

Users can add, remove and modify the permissions of other users of this container and its children.

Execute

Users can run this tool against computer objects that they also have Execute rights to. Importantly, any input to the tool which has its “Direct Run Options” set to “Value can be edited” can also be modified by users with this permission either when creating a job using it, or when adding the tool to a Tool Sequence, even if they don’t have write access.

For this reason, it is extremely important to review your tools input options prior to granting this permission.

Derive

When creating a tool based on another, or when duplicating a tool that users have this right to, but not “Write” permission, the tool is “derived” instead of directly duplicated. This means that specified inputs for the tool can be locked down for any tools based off of it.

For example, I want to make the Copy Directory tool available to a group of users. I want them to have the freedom to specify both source and destination directory, but due to concerns over disk space, I don’t want them to copy entire directories and their subfolders. To achieve this, I create a copy of the Copy Directory tool in a container that the users have Derive and Execute rights to, and I set the “Include Subfolders (Recursive)” input to false, and set its “Derived Tool Options” and “Direct Run Options” both to “Can be Viewed, but not edited”.

Now, not only can they run this new tool directly (without being able to change the “Include Subfolders” option, they can also create their own copies of the tool in other folders and have the ability to permanently configure those tools however they like, but they will never be able to modify that “Include Subfolders” option.

This can be quite a difficult concept to get your head around at first, but once you’ve used it a few times you’ll see just how powerful this can be.

Things to Avoid

This can all take a bit of getting used to, and we recommend having a test user account you can practice on before adding live user accounts.

While most tools in Overcee would be largely harmless or have limited scope for impact if the wrong permissions were given, we like to give special attention to the following.

1. Local Execute Program

This tool is used to run applications or scripts directly on the worker server. Suffice to say that giving free access to modify the inputs (either directly with Write access, or by not locking the inputs down and granting Execute permission) would give users the opportunity to cause great harm to the server, either intentionally or not. This tool, unmodified, would essentially grant Administrator rights to the server.

2. Remote Execute Program

Like the Local Execute Program tool, but for client devices. Giving write or execute permission to this tool essentially grants Administrator rights to any device the user also has Execute permission over. This tool is extremely powerful and useful, and makes up for 90% of the work Overcee is used for, but it should only ever be provided to non-administrators in a pre-configured, and locked down form. Further to this, non-administrators should never have Write access to this tool.

For example, I may want to create a Group Policy update tool and make it available to my users. I would set the Command Line to, for example, “C:\Windows\System32\gpupdate.exe”, the Parameters to “/Force” and leave all the other inputs as they are. But, I would set the “Derived Tool Options” and “Direct Run Options” for all inputs to either “Value can be viewed, but not edited” or “Value cannot be viewed or edited”. Then I could safely grant Execute rights to the new tool without fear of mis-use.

It is important to remember as well, if configuring either of the Execute Program tools to run “cmd.exe”, the Parameters field must also be locked down, otherwise any other application or script can also be run.

3. File Operations

It goes without saying that, for example, Delete Directory could cause much harm to a client device. So this and other file operation tools should be used with care.

4. User Operations

Granting rights to use, for example, the “Add User to Group” tool, essentially grants the user administrator rights to client devices as there would be nothing to stop them from adding themselves to the Local Administrators group.

However, there may, of course, be times when this is desirable. For these instances, we recommend using the “Add User to Group (Temporary)” tool instead. This tool is specifically designed for service desk use as it can be configured to automatically remove the user again after a specified number of seconds (1800 seconds, or 30 minutes, by default). That way if a service desk user wished to add themselves to a client device’s administrator group to investigate and fix a problem, then they can and this permission will be automatically revoked afterwards, meaning no manual cleanup is necessary.

Strict Mode

Overcee has a unique additional setting for user accounts which can further help you to secure its use.

Consider a scenario: Joe is a Service Desk Operator and has access to many of Overcee’s tools for running on client devices. Joe has recently been on training, and is now also responsible making sure that a critical system server is restarted daily. Joe already has access to the “Reboot” tool, and has used it to great affect on client devices. However, if Joe is granted Execute rights to the server, he will also have the ability to run all of the other Overcee tools on it, not just “Reboot”.

For this reason, we created Strict Mode.

The solution here is to add Joe to a security group called something like “Joe.ServerReboot”. This group is then added to Overcee and its Strict Mode option is set. Then the group is granted Read/Execute rights to both the server in question, and the reboot tool

Strict Mode works by ensuring that if a user is granted Execute permission via a Strict Mode group, they must also be granted Execute rights to a tool or tool sequence by that exact same group. If Joe tries to run another tool against that server, he will be unable to do so.

Conclusion

As you can see, Overcee’s permission system is both incredibly powerful, and scarily complex. But by mastering it, you can ensure your network is easily maintained without skimping on security.

Got any questions? Contact us.