Product Reviews

ScriptLogic Privilege Authority: Boosting User Productivity

Users gain some needed control over their applications without surrendering security or stability.

• By Derek Schauland
• 09/01/2011

Microsoft Windows has come a long way with the release of Windows 7, especially in driving users -- and in some cases, administrators -- crazy with functions like User Account Control (UAC). Best practice states that you should leave these features enabled to cut down the likelihood that malware or viruses (or users) can get access to areas of the system that they shouldn't have.

When UAC is in use, doing anything that modifies the system will prompt for credentials. But ScriptLogic Corp. has developed an application that will allow administrators to return some control back to the user. Privilege Authority allows rules to be configured and applied through custom Group Policies that give some control of the OS back to users.

Privilege Authority uses a console (installed on a server in your environment) and an agent (installed on client machines). The rules are defined inside the console as Group Policy Objects (GPOs) and linked to domains and containers just as other GPOs would be (see Figure 1).

[Click on image for larger view.]

Figure 1. The Privilege Authority console.

The GPOs created for these rules are specific to Privilege Authority. When I was testing this application within my organization, I was unable to see any of the details outside of the Privilege Authority console. Because the application provides all the tools needed to create and manage the rules, this is a good thing, as it prevents most management and configuration changes outside of the console.

When I began using Privilege Authority, I installed the console on a member server within my domain. Once the Remote Server Administration Tools, or RSAT, were installed (or the Administration Tools Pack for Windows Server 2003 on Windows XP), I installed the console on an administrative workstation and it worked great.

Creating Rules
For the application to work, you need to define rules that specify which apps will be checked and which privileges they will be assigned. To create a rule, complete the following steps:

1. Open the Privilege Authority console.
2. Highlight the domain for which you wish to create GPO Rules.
3. Click New GPO.
4. Enter a Title and a Description for the GPO and click Finish.
5. Select All GPOs from the Local Rules section console.
   Because no rules have been added to the new GPO, it will not be displayed in the GPOs with Rules list.
6. Select your newly minted GPO from the list.
7. Click New Rule in the left pane of the console. This will open the Create Rule Wizard.
8. Enter a name and description for the rule.
   If you wish to share this rule with the community, check the box labeled "on completion open a dialog to share this rule with the community." Doing this will allow others to use rules you've created simply by importing them, rather than forcing them to create all rules from scratch.
9. Choose the type of application you wish to apply this rule to. The choices are as follows (see Figure 2):
   • By Path to the executable. Enter the path to the executable and any arguments required. If you use a literal path, like c:\application.exe, you'll be prompted to create a hash for the path to help ensure the application is valid when the rule executes. If you don't know the explicit path to the executable, you can enter a wildcard path such as *\application.exe. Doing this allows that application to be elevated regardless of its location -- but use wildcards wisely. You can also specify a certificate for signed applications where the rule should be applied.

     [Click on image for larger view.]

     Figure 2. Select an application type.

   • By Folder Path. Choosing this application type will apply the elevated privileges to the folder you specify. In addition, you can choose to apply the privilege to sub-folders and child processes.
   • By ActiveX Rule. Use this application type for ActiveX applications, such as browser add-ons and other things that request elevation.
   • By Digital Certificate. Use this application type to verify the digital certificate for an application. This prevents spoofing and also continues to work even if the application name changes. When used, the digital certificate will be verified before the program can run, ensuring secure elevation.
10. On the next tab of the wizard, select the privilege to allow or deny. The first option applies the local Administrators group Security Identifier (SID) to this rule, but you can specify domain-level groups as well.
11. Next, select the platform the rule should apply to; this way, you can prevent applications from installing on servers or specific OSes. Simply leave them unchecked to exclude them.
12. Finally, you can use validation rules to further control where the rules are applied. If you link the GPO containing the rule to the Customer Service Organizational Unit (OU) but then only want one computer within the OU to receive the rule, validation logic helps with this. It can control rule application by computer name, computer group, computer OU and ranges of IP4 and IP6 addresses; it can also control rule application based on the existence of files or registry keys. Additionally, all validation rules can be negated so that items not matching a particular entry can receive the privilege elevation.

There are some additional features available when the advanced options box is checked that allow specific privileges to be used, rather than giving an administrator full control; they also provide a way for the integrity of the application to be specified. These options are generally not needed for the privilege-elevation techniques to work but exist for specialized cases where this might be needed.

Because of the specialized nature of the rules, I advise creating a new GPO for each rule created. This also helps keep things manageable.

Application of Rules in the Registry
Being a bit of a pessimist when it comes to things that aren't visible to me right away, and not wanting to run around to every workstation following a deployment, I was unsure of how I could check to see if a rule was actually applied. I was confident rules would work, as they did when tested on a couple of computers, but Murphy's Law seems to prevail when one presumes the tested outcome will always be correct.

I talked with ScriptLogic technical support about this issue, and they provided a quick way to check for applied rules using the registry.

When looking in HKEY-LOCAL-MACHINE on the remote system, you should be able to find the following keys:

HKey_Local_Machine\Software\Scriptlogic Corporation\Privilege Authority\CSE\CSEHost\<SID-Identifier>\<Application Identifier>\0 for x86 machines and HKey_Local_Machine\Software\Wow6432Node\Scriptlogic Corporation\Privilege Authority\CSE\CSEHost\<SID-Identifier>\ <Application Identifier>\0, which is for x64 machines.

When you select the key in the registry, the details, including application name, should appear in the results pane.

Overall, the first month or so that I've been working with Privilege Authority have been very straightforward. The ability to elevate privileges in Windows has been lacking for a long time in the OS. Most of the time, things run just fine for the general population, but occasionally there's a need and a good reason to elevate specific applications. With Privilege Authority, you can do just that and not worry about overextending a specific user's access to the system._