Controlling desktops with AppLocker and software restriction policies

Users like to download all sorts of software to enterprise desktops, including music, photos, "productivity tools," games and Internet browsers. This is a monumental headache for the IT staffers trying to limit exposure to viruses, keep software up to date, avoid license-policy violations and ensure that desktops are secure and have sufficient resources to run required software. Microsoft provides tools to help, but which one is best for you?

Some admins rely on User Account Control (UAC). This feature, introduced in Windows Vista, is infamous as a user pain point: Every time you want to do something, you are asked if you really want to do that. The tool seemed designed to make sure that you couldn't use your computer. However, for administrators, it was a great step forward to locking down the desktop.

Unfortunately, UAC doesn't prevent the installation of any given application. Yes, it will prevent some however, Microsoft built exceptions to UAC. That is, the company has told developers how to get around the UAC restriction. The User Account Control Team wrote in the MSDN blog that:

Independent software vendors who wish to have part or all of their software suite run during the startup process are encouraged to architect their applications to run AsInvoker so that all users (that is, administrators and standard users) can run the software without the need for a UAC elevation.

In addition, a FAQ gave the same UAC advice at Microsoft's TechNet.

So, what's an IT admin to do?

There are two options. In Windows 7 and Windows Server 2008 R2, there's AppLocker, and in Windows XP, Vista, and Server 2003 and 2008, there are software restriction policies.

Software restriction policies
Software restriction policies (SRP) are complex, a bit clunky and don't follow normal Group Policy processing rules. But they work if you use the following steps:

1. Create a Group Policy Object (GPO) -- call it software restriction policy for simplicity.
2. Go to Computer Configuration -- Windows Settings -- Security Settings -- Software Restriction Policies. If this is the first SRP created, you will need to right click on the Software Restriction Policies icon in the tree and select New Software Restriction Policies.
3. In the right pane, right click on Enforcement, and complete the Properties page as shown in Figure 1. This will deny access to all files by all users except administrators. No additional rules are needed.

   Figure 1: You can restrict file access to admins only. (Click to enlarge.)
   

• If you then attempt to install Firefox on Windows XP, as shown in Figure 2, Windows indicates that a rule has prevented this action. Attempting to install it on a Windows 7 machine will produce the error shown in Figure 2.

Figure 2: Windows displays an error message if you attempt to install software not allowed by an SRP. (Click to enlarge.)

• To allow certain software, create exceptions. Under the SRP icon, click Additional Rules. There are four options. Figure 3 shows how to use the Hash Rule. Simply browse for the program you want to allow and select the security level.

Figure 3: The Hash Rule allows admins to determine exceptions to SRP. (Click to enlarge.)

I call this use of the SRP the "closed door" method. You restrict everything, then create exceptions for what you want to allow. The other option is to do the opposite and leave it wide open, just creating rules for the files you want to restrict. This is fairly difficult to execute and very hard to do if you have multiple SRPs defined in multiple GPOs. I'd advise to define only one GPO with SRP to apply to any computer.

Note: Software restriction policies apply to Windows XP, Vista, 7, Server 2003, Server 2008 and Server 2008 R2 machines.

AppLocker
AppLocker, which was introduced in Windows 7 and Windows Server 2008 R2, is easier to define and more predictable than SRP. AppLocker can be invoked individually on Windows 7 and Windows Server 2008 R2 machines as well as defined in a GPO on a Windows 2008 R2 domain controller, but it will apply only to Windows 7 and Server 2008 R2 computers. To implement AppLocker, do the following:

1. Open a GPO on a Windows Server 2008 R2 domain controller (or edit the local security policy on a 2008 R2 server or Windows 7 client).

1. Go to Computer Configuration -- Security Settings -- Application Control Policies, and expand AppLocker.

1. There are three types of rules, shown in Figure 4. Right click on Executable Rules, and select Create New Rule to start the Create Executable Rules wizard.
   
   Figure 4: Starting the Create Executable Rules wizard. (Click to enlarge.)
   

1. On the Permissions page, select Deny, and then select the users/groups to apply the rule to.

1. On the Conditions page, the options are similar to the exceptions previously created in SRP. Rather than selecting an .exe or .vbs file, you can select a publisher. This will prevent any unsigned applications. We will use option this in our example.

1. In the next screen, shown in Figure 5, browse to find a file from Publisher, and the template will be populated (for newer apps). You can also modify this by sliding the bar on the left. Click Next.

Figure 5: Find a file from Publisher. (Click to enlarge.)

• On the Exceptions screen, add files that will be allowed. Simply click Add, and add .exe, .vbs and so on to the list. This should add exceptions to the rule so that certain apps can run. I have not been able to get this to work (see the "Allow Rule" procedure below).

• On the Name and Description screen, give the rule a name. Click Create.

• If this is the first rule, you'll get a pop-up asking if you want to create the default rules. These are the rules that allow files in Windows and Program Files directories to run. Answer yes.

• Note: Creating just one executable rule with the Deny option will restrict all files -- except those in the default rule paths -- from being installed and executed. You must create exceptions for any other apps to run. For example, creating the rule as shown in this procedure will prevent installation of Microsoft Office even though it was not specified. To allow Office to be installed, create another Executable Rule, use the Allow option, and specify the Adobe Reader executable in the same manner shown for the Deny rule. Create an Allow rule for each application you want to allow. See Figure 5 above for an example.

• Furthermore, to create the AppLocker rules, you just need to have the file from the publisher available somewhere so the wizard can find it for the rule.

Just remember that software restriction policies apply in Windows Server 2003, 2008 and 2008 R2, as well as Windows XP, Vista and 7. However, AppLocker applies only to Windows Server 2008 R2 and Windows 7.

Microsoft provides SRPs and AppLocker as tools for admins to control software on the desktop. User Account Control was never designed to do that; it is impossible to control and provide granular options, and Microsoft tells developers how to get around it. My recommendation is to move to Windows 7 clients with at least one 2008 R2 domain controller and use AppLocker because it is more reliable and easier to control than software restriction policies are.

ABOUT THE AUTHOR
Gary Olsen is a systems software engineer in Global Solutions Engineering at Hewlett-Packard. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Directory Services and formerly for Windows File Systems.