I often get asked about best practices when configuring Privilege Guard (Edit: now Defendpoint), so I thought I’d take the time to demonstrate some of the flexible ways the product can be used to implement least privilege.
Privilege Guard enables you to cater for a wide variety of use cases, as it includes highly configurable application rules and a comprehensive end user messaging system, which leads to a superior end user experience. I will demonstrate how these can be used to build a fairly sophisticated set of policies that you can fine tune or extend further to fit your environment.
One of the most important concepts to grasp when configuring Privilege Guard is that policies are processed in order of precedence. When an application matches a policy entry then it performs the relevant actions and does not process any further policy entries. Policy precedence is achieved by simply moving policies up and down (and likewise for the individual policy entries in the Application Privileges and Shell Integration sections of a policy). If multiple GPOs are applied to a computer or user then individual Privilege Guard policies within those GPOs are merged by the Privilege Guard client using standard Group Policy precedence rules. You can use Resultant Set of Policy (RSoP) to visualize how Privilege Guard policies are merged together when multiple GPOs have been applied.
The flowchart below shows the policies that I am going to define for a Task User and a Power User (not to be confused with the power users group in Windows). The basic premise is that we want the Task User to only have access to privileged applications that have been defined in policy and to only run authorized applications, while ensuring that the user receives meaningful messages when they attempt to access an application that is outside the scope of the policy. For the Power User, we want to set up a similar policy, but instead of blocking this user, we want to warn them of their actions and audit. We will also configure the Shell Extension section of the policy for the Power User, so that they may elevate applications on demand, which will be audited. A nice touch is to differentiate between signed and unsigned applications, so that we can show a different warning message for unsigned applications, as they may pose a greater risk. You will also notice the UAC triggered rules in both policies that can be used to either replace UAC with a blocking message for the Task User or a prompt for the Power User.
To build our policies we will need a set of application groups, as defined in the table below. Most of these application groups perform a generic match, e.g. All Signed UAC Apps. Two of the application groups will be specific to your environment, namely Admin Tasks and Trusted Apps. In this example I have added a couple of applications to the Admin Tasks group and used some simple folder rules in the Trusted Apps group to allow list all of the applications in Windows and Program Files. To simplify this example, I have assumed that all users have the same Admin Tasks, but in reality you will probably elevate different applications for each group of users, although there may be a common set of applications that are elevated for all users. You will need to add all of the applications and ActiveX controls that you want to elevate automatically into the Admin Tasks group.
After creating our application groups we need to create a set of messages that enable us to communicate with the users. The messaging system in Privilege Guard allows you to create any number of messages, which can be used to prompt, warn or block. By setting different message text and altering the appearance of the message, such as the header color, we can convey important information to the users. The messages have full multi-lingual support and a variety of options can be set, such as asking the user for a reason or forcing the user to re-authenticate. If you want to include your company logo in the image then you may want to create a set of different color banners that include your logo, but in this example I have simply used the default gradient colors.
We can now use these application groups and messages to define policies for the Task Users and Power Users. The screenshots below (click to enlarge) shows the Task User Policy in the management console, which matches the flowchart shown earlier.
You can download the policies and import them into the Privilege Guard management console (remember to add a license code). You will need to make changes in the accounts tab of the policies, as both policies are currently being applied to Everyone, and so the Power User Policy will always be applied, because it's at the top, so has the higher precedence. You will also want to refine the Admin Tasks and Trusted Apps groups for your environment. This example uses folder rules for the Trusted Apps group, but you may use a combination of rules to define the trusted base of applications. I recommend that you use broad concepts, where possible, such as folders, publishers and ownership, as this will be easier to maintain.
Here are a few tips for extending these policies further:
- Add an email button to the blocking messages to allow the user to email requests to the help desk for applications that have been blocked by policy.
- Create a set of different colored banner images that include your company logo, which will give a corporate look and feel to the end user experience.
- Create an application group of unauthorized operating system applications and insert it at the very top of the policy rules to block the user. This can be used to block system applications and tasks that users are not allowed to run. You should also add this to the top of the Shell Extension rules for the Power User.
- You may decide that blocking unauthorized applications is too restrictive for many users, so you may choose to warn and audit most users. Alternatively, you may decide to simply audit unauthorized applications without warning the user.
- You may define the Shell Extension for Task Users, but show a blocking message with a reason and email button, which enables users to request applications without trying to run them. Name the shell menu something like "Request Application"
I hope this post has demonstrated the flexibility of the Privilege Guard solution and how it can be configured to meet the requirements of different users, while promoting an extremely positive end user experience, which ensures the solution is embraced by your users.