Solving LUA Problems with Avecto Privilege Guard

(For more resources on Microsoft products, see here.)

Configuring applications to run with elevated privileges on-the-fly

Despite all the possible workarounds to launch an application or set of commands with elevated privileges from a standard user account, Windows doesn't provide any built-in means of allowing system administrators to configure a particular application to launch as the currently logged in standard user, but with an administrative token. Consider a situation where you don't have time to fix an application that won't run as a standard user, but don't want to grant administrative privileges just for the sake of one application. While it may be possible to start the application using a secondary logon, this is impractical in most cases.

Solving LUA problems with Avecto Privilege Guard

Privilege Guard is a third-party solution, from Microsoft Gold Partner Avecto, that allows system administrators to dynamically add or remove privileges by modifying the logged in user's access token as it's assigned to new processes. The client-side component, provided as an .exe or .msi file for GPSI deployment, is implemented as a user-mode service and supports Windows XP (or Windows Server 2003) and later. Privilege Guard is licensed on a trust model, so it doesn't adhere to a strict object count in Active Directory.

Client settings are deployed with User or Computer Group Policy using a flexible architecture that separates policies, applications, messaging and access tokens. Programs can also be grouped together to minimize the number of policies applied.

Defining application groups

For each Application Group, you can define one or more programs using the following categories:

  • Executables
  • Control Panel Applets
  • Management Console snap-ins
  • Windows Installer Packages
  • Windows Scripting Host (WSH), PowerShell scripts and batch files
  • Registry Editor files
  • ActiveX controls (matched by URL or CLSID)

Application Templates can also be used to quickly locate built-in Windows tools such as Performance Monitor or System Restore. In the screenshot that follows, I used an Application Template to locate the Disk Management console (diskmgmt.msc) in Windows 7. The default setting is to match processes by file or folder name, but processes can also be matched by command line switch, file hash, publisher or any combination thereof. Privilege Guard supports matching by publisher certificate when Windows binaries are indirectly signed using Windows Security Catalogs.

Additional options include:

  • The ability to match processes if Privilege Guard detects that an application will trigger UAC.
  • To determine whether child processes spawned by the matched parent process inherit the privileges of the user's modified access token.
  • To suppress elevated privileges on File Open/Save common dialogs to prevent users from modifying protected files.

Defining access tokens

We can define the rights allotted to access tokens in Privilege Guard based on the privileges assigned to Windows built-in groups. Rights can also be added or removed on an individual basis. The access token below uses the built-in Administrators group as the basis for assigning privileges.

An access token's integrity level can also be overridden.

Any combination of groups, privileges or integrity levels can be added or removed in an access token.

Configuring messages

While it may be preferable in many situations to silently elevate privileges when a user starts a legacy application, organizations can use Privilege Guard to generate fully customizable messages, in multiple languages if necessary, that are displayed when applications are blocked, or if users are required to confirm their credentials or provide a reason for launching a process with elevated privileges.

The drop-down menu under Message Type can be set to Allow or Block Execution, and determines not only the type of message that's displayed, but enforces the corresponding block/allow action.

Defining policies

The final task is to define a policy to bring the entire configuration together and determine how it is applied. Here we can choose to apply our policy to all users (using the built-in Everyone group), or select individual users and groups; set the application group, access token and optionally message included in the policy. We can configure multiple sets of actions for application groups, access tokens, messages and auditing (Application Group Actions and Auditing).

Optional settings include the ability to configure Privilege Guard shell integration for specified application groups so that a process can be launched from Explorer's context menu with a modified access token, allowing advanced users to elevate applications on demand. System administrators can also enable logging options for the purposes of software metering or monitoring privilege use.

Solving LUA problems with Privilege Manager

BeyondTrust's Privilege Manager provides system administrators with a solution that allows them to define applications or processes that launch as the logged in user, but with an administrative-level access token. Privilege Manager is divided into client and server software. The server software, or snap-in software as it's referred to, installs on a server in your organization and updates Group Policy Object Editor for policy configuration and provides Group Policy Management Console integration. The client software installs on each device to which Privilege Manager policies will apply.

Let's take a simple example of how Privilege Manager might be used. We'll configure a policy that allows standard users to start Notepad with administrative rights.

Defining Privilege Manager rules

We start by deciding what kind of rule we want to apply, in a similar vein to Software Restriction Policy (or AppLocker in Windows 7), but the options for targeting applications are slightly expanded:

Privilege Manager Rules:

Rule name Function
Path rule Target an application by its program file path
Hash rule Target an application by a hash of its file
Folder rule Target all applications in a folder
MSI Path rule Target installations by MSI file path
MSI Folder rule Target installations by MSI file folder
ActiveX rule Target an IE ActiveX control installation
Certificate rule Target an application by its certificate
Shell rule Target any application started from Explorer
CD\DVD rule Target a CD-ROM or DVD

Once we've chosen the rule type, we can enter the path to our application manually or use the browse button to choose from a list of predefined Windows applications, control panel applets, and wizards.

Per-Computer or Per-User Policies
Policy Maker policy settings can be applied to the computer or to specific users. Additionally, Policy Maker can be used with local policy settings or Group Policy.

Two additional options require users to enter their credentials again before the process or application is launched (apply rule only if user can authenticate) or require users to provide an explanation for launching the application, which is logged by Privilege Manager (require user to enter text justification).

Assigning permissions

Here we get to choose the permission level with which the process or application will launch. You can choose to add or remove a group from the logged in user's access token.

Adding or removing individual privileges

The Privileges tab gives us more granular control to add or remove individual rights.

Specifying integrity levels

We have the opportunity to specify the integrity level with which the process should launch under Vista and Windows 7.


In this article, we have examined Avecto Privilege Guard, one of the third-party tools available for solving Least Privilege Security problems.

Further resources on this subject:

You've been reading an excerpt of:

Least Privilege Security for Windows 7, Vista and XP

Explore Title