2.7.1 AppLocker (part 1)
By Val Bakh
AppLocker is a new type of Group Policy; it has been introduced in Windows 7 and Windows Server 2008 R2 and supersedes legacy software restriction policies (SRPs). In the Group Policy object (GPO) namespace, Applocker is located in a folder named Application Control Policies (ACPs). There is nothing else in that folder. Perhaps Microsoft is planning to add other types of ACPs in future versions of Windows, but for now, AppLocker is the one and only ACP.
AppLocker is a computer-specific policy, and as far as Windows 7 is concerned, it works in only the Enterprise and Ultimate editions. In Windows 7 Professional, AppLocker appears in GPOs and can be configured but doesn’t work; the operating system ignores any AppLocker policies in any GPOs targeting the computer.
An AppLocker policy contains four rule collections: executable, Windows Installer, scripts, and DLL. Each collection can include zero or more rules of the corresponding type. Each rule defines criteria that control whether files of the corresponding type are allowed to run. To target applications, rules include conditions, such as path conditions, publisher conditions, or file hash conditions. Additionally, each rule targets one specified security principal: either a user or a group. Initially, when no AppLocker rules exist, all applications are allowed to everyone. Once the first rule in a collection has been created, only the specified user or group can run only the explicitly allowed applications in the rule’s category. For example, if the first executable rule that you created in a GPO is a Deny rule, no one will be able to run any applications on any computers targeted by the GPO. Therefore, you should always configure rules in such a way that the operating systems on the targeted computers can function. To help you avoid an accidental lockdown, Microsoft provides optional preconfigured default rules in each rule collection. The default executable rules allow members of the local Administrators group to run any applications and allow standard users to run applications that reside in the \Windows or \Program Files folders.
For rules to take effect on a targeted computer, the Application Identity service must be running. As an additional precaution against an accidental lockdown, by default, this service is not running and is configured to be started manually. Microsoft recommends that you configure this service to start automatically in at least one of the GPOs that contain AppLocker policies.
If multiple GPOs target the same computers, all AppLocker rules in those GPOs are combined and, by default, are implicitly enforced. To configure explicit enforcement settings, you should first right-click the AppLocker node in a GPO and select Properties. On the Enforcement tab of the AppLocker Properties dialog box, you can configure enforcement settings for each rule collection. If you enable the Configured option for a collection, two enforcement options become available for the collection. If you select the Enforce rules option, the rules in the collection are explicitly enforced. If the Audit only option is selected, the rules are evaluated and the relevant events are recorded in the AppLocker log, but the rules do not affect users’ ability to run applications. Explicit enforcement settings always override implicit enforcement, and any conflicts among explicit settings that are configured in different GPOs are resolved in accordance with the usual GPO precedence rules.
That was a brief summary of AppLocker’s basic functionality. Next month, we’ll take a look at several interesting AppLocker use scenarios.