Archive

Posts Tagged ‘Apps’

AppLocker

History
Allow me to start by telling you a story. A long while ago, I did some work for a travel agency. The project I was involved in was a desktop upgrade, rolling out NT 4.0 Workstation across the company. This included the computers in the agency retail outlets used to help sell flights and holidays. The company needed to limit the applications were allowed to run on the computers, as it hardly looked professional if a customer entered the shop to see an assistant playing Solitaire! Back in those days, we used Poledit.exe to customise what users could see and do on the desktop. So much has changed since then.

In more recent times, such as with Windows XP, Group Policy incorporated newer settings for administrators to manage desktops, and this included Software Restriction Policies (SRPs). SRPs allowed administrators to limit which applications users could run, based on rules such as path, and certificate publisher.

Today
Now with Windows 7 and Windows 8 Enterprise editions, administrators can now leverage a more modern set of tools via the Applocker feature in Group Policy. Applocker settings can be found in the following area as seen in figure 1.

clip_image002
Figure 1. Applocker settings in Group Policy.

You can configure the following types of rules in Applocker:

· Executable rules – rules that point to a folder containing executables, or a specific executable.

· Windows Installer Rules – rules which control which programs can be installed in the first place, rather than limit them running afterwards.

· Script Rules – increasingly, administrators use scripts like PowerShell scripts to manage desktops. The behaviour of scripts can now be controlled.

· Packaged App Rules – the newest to the collection. This is for Windows 8 Apps, or otherwise known as side-loaded apps. You can find out more about side-loading in the Windows 8 Jump Start video collection.

Why use Applocker?
One of the benefits for administrators is that Applocker allows very customisable rules that allow/disallow applications, scripts and installers, and not just system-wide like SRPs used to do, but per user or per group now as well. This gives a level of granularity that simplifies management, and the number of Group Policies that need to be deployed across an organisation.

Administrators should be interested in this feature to ensure security and licencing compliance needs are met, and to help reduce the TCO in managing applications that users might otherwise download and install.

How Does It Work?
Firstly an administrator will create/edit a Group Policy Object such as the one you’ve seen above. Based on the business needs, rules are created to permit/deny some applications/scripts/installers to run for different users or groups. In figure 2, I’ve created an executable rule by first creating the default rules that allow users to run all programs from ‘Program Files’ and ‘Windows’ folders, and administrators to be able to run all applications from all folders. I’ve then created a rule that specifically denies notepad.exe using a hash rule, meaning that even if the file is moved or renamed, the rule will still control access to that application. It’s also important to remember to configure rule enforcement, as by default no action is taken.

clip_image004

Figure 2. Executable rules configured in Applocker in Group Policy.

Once the policy applies to a Windows 7 or Windows 8 domain joined computer, the Application Identity service will use the deployed information whenever a request to launch an application takes place.

Summary
The desktop administrator today has more options than ever before to control Windows operating systems. When used in an Active Directory environment, Windows 7 and Windows 8 can be robustly managed to help ensure licencing compliance and security on the desktop with Applocker.

For more information on Applocker and Group Policy, visit the Springboard website.