Understanding Policies

Introduction

The mechanism EPM uses for elevating the privilege of a process is based on the application of policies.

For end users, EPM operates in a similar way to 'Run as administrator'. Users simply right click on a process and choose the 'Run as administrator using EPM' option from the menu. The user is then presented the Windows User Account Control prompt where they enter their own credentials to confirm they want to run a process as an administrator, assuming the policy you've established allows them to do so.

User context is maintained while privilege is elevated. As a result, any files created will be owned by the user's account and any 'save' or 'open' dialog will default to the user's standard locations. This produces a seamless experience for users to elevate privileges on demand.

EPM allows organisations to remove local admin rights from their users while still allowing those users the ability to run the elevated processes they need.

By default, EPM blocks any process from being run as Administrator. You will need to manually create policies or use the Learning Mode tool to create a set a policies in order to give users administrator access to the specific processes they need. The Rolling Out guide can help you to identify which roll-out path is appropriate for your organisation.

Policies

Policies are based on any combination of process path, hash, and signer.

• Path: The policy applies to processes within a matching path, paths can lead to an exact process and can be wildcarded using *.

  • E.g. Z:\Internal Tools\* , C:\Program Files\Osirium\devtoools\devtools.exe, *\internal_tool.exe

• Signer: The policy applies to proccesses with a matching signer.

Individual policies are applied to an AD/Azure AD security group. There are two possible actions that exist in a policy file:

• Allow: In cases where an allow policy is in place, EPM shows process information. The user must then enter their user name and password to start the process with elevated privileges.

• Deny: In cases where a process has no matching policy or a deny policy, a deny dialog is triggered.

Note

A 'deny' policy always takes precedence over an 'allow' policy. You can use this behaviour to target specific processes you want denied in an otherwise allowable directory.

For example, suppose your organisation has a set of tools deployed at Z:\Internal Tools\* that your users need to be able to run with elevated privileges. However, there are a few tools in the folder that shouldn't be run with elevated privileges. Rather than creating individual allow policies for each tool that is required, it's more convinient to simply make a policy to allow Z:\Internal Tools\* and another policy to deny Z:\Internal Tools\FirewallConfiguration.exe.

The same logic applies to groups in Learning Mode, where a deny policy can be used to override learning mode's permissive policy.

Learning Mode

Learning Mode is designed for a smooth roll-out of EPM in organisations where users still have local admin rights. Once EPM is configured, users can have their local admin rights removed with minimal disruption to their daily work by using Learning Mode. When a group is placed in Learning Mode, they can elevate any process via the EPM Client (other than those explicitly denied by policy). These elevations are logged and a policy is automatically created matching on the exact path and signer of the process.

Automatically created policies should then be reviewed in the EPM Management Interface and adjusted as required. At the end of the learning mode period, policies will have been created that largely cover all the processes your users need to elevate to get their work done.