Happy Monday everyone. It’s Day Nineteen of our Launch Series, which means that there are only three more days until Windows 7 appears on store shelves! Today, we’re going to provide a really quick overview of AppLocker, which is a new feature in Windows 7 and Windows Server 2008 R2. AppLocker replaces the Software Restriction Policies (SRP’s) that many of you are probably familiar with. With AppLocker, an administrator has the ability to control how users run all types of applications – scripts, excecutables, Windows Installer files (.msi and .msp files) and Dynamic Link Libraries (DLL’s). Seasoned admins have probably made use of SRP’s in the past, but some of you may be wondering why this is even an issue.
Most of us on the Performance team were IT Administrators at one time or another prior to joining Microsoft. Believe me when I tell you that we all have our fair share of horror stories. We’ve all been in environments where end-users have brought in software from home or downloaded some sort of shareware or freeware and installed it on their machine. In most of these cases, there was no real business need for these apps – let’s face it, is having a “cool” screensaver really a justifiable business application? Probably not in the vast majority of cases. Of course, almost inevitably, the software would cause other issues – leading to more helpdesk calls, some fairly angry end-users and of course, some really angry IT folks. Enter SRP’s, where administrators could create rules and policies to block the installation of some of the more … popular … pieces of unauthorized software. We’re really not going to get into the workings of Software Restriction Policies – if you need more information, refer to
this TechNet Article
Getting back to AppLocker, there are several enhancements:
Ability to define rules based on attributes derived from a file’s digital signature, including the publisher, product name, file name and file version. SRP supports certificate rules, but they are less granular and are a bit more difficult to define
More intuitive enforcement model – only a file specified in an AppLocker rule will be allowed to run
Audit-Only enforcement mode that allows administrators to determine which files would be prevented from running if the policy were in effect
New interface accessed through an MMC snap-in extension to the Local Policy and Group Policy snap-ins. The Software Restriction Policies snap-in is still available in Windows 7 / Windows Server 2008 R2 for compatibility reasons.
AppLocker requires the Application Identity Service. This service performs all of the rule conversions for the AppLocker policy. In order for an AppLocker policy to be evaluated on the system, the services has to be started. The Application Identity is set to Manual by default.
The effects of AppLocker rules may be viewed in the AppLocker Operational event channel in Event Viewer. Each event in the AppLocker operational log contains the following information:
The file affected and the path of the file
Whether the file was allowed or blocked
The rule type (path, file, hash or publisher)
SID for the user targeted in the rule
Something to note – AppLocker rule and Software Restriction Policy rules are completely separate. You cannot use AppLocker rules to manage pre-Windows 7 systems. If you define any AppLocker rules in a GPO, only those rules will be applied. In other words, you should define your AppLocker rules in a separate GPO from your SRP rules to ensure interoperability.
And that’s all for AppLocker. The resources below have more information. Tomorrow, Jerry Ciferri will provide a quick overview of Windows Federated Search.