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)
- Rule name
- 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.
Additional Resources:
- Dane Smart
| Share this post : |
|
|
|
|
|
|
|
|
<br/>