Select a language to translate this page!
Powered by Microsoft® Translator
Our guest blogger is Daniel Nerenberg. He is an MCT,MCSA,MCSE,MCTS,MVP, STEP Member and an independent consultant based in Montreal. He is also the President of the Montreal IT pro user group. Daniel has written and consulted on the topics of Windows deployment, application virtualization, and Windows infrastructure.
Window 7 RTM has been available for just a few weeks now, but already IT Pros everywhere are diving into great new features. One of the more exciting features introduced in Windows 7 is AppLocker. Many of you know about Software Restriction Policies, they allow you to block the execution of a program by file name or hash calculation. You probably also know how it was a race to block applications in our network with these methods. Users could change the name of the file, or applications updates so frequently that you would constantly need to generate new hash files.
AppLocker works under the premise that it’s easier to allow the applications you want, and block the rest. If you’re running a Windows 7 machine you can see AppLocker by typing gpedit.msc into your search bar and pressing enter.
You can define policies based on executables, Windows installers, and scripts. Creating a new policy is simple. Right-click on any of the 3 categories and click Create New Rule.
You can create a policy to allow or deny an executable. You can also select which groups the rule will apply to.
You can choose to create a rule based on a publisher (the program needs to be signed), a program path, or a file hash (usually a good choice if the program isn’t signed).
For this example I chose publisher. The Rule Wizard uses the information stored application signing certificate to learn about the application. You can adjust what level of information you’ll allow for an application.
In the above example the policy will only allow Internet Explorer 126.96.36.199 and above to run on the computer.
You can use the same steps to create exceptions for specific applications. One of the more convenient features is the ability to automatically generate rules. If you right click on any of the 3 categories and click Automatically Generate Rules you can quickly generate a list of rules based on applications that are already install on the computer (saving you a lot of work to get going with AppLocker!).
In this example, we scan your applications in the Program Files directory and create rules for those programs to run. Perfect for creating a baseline set of rules for applications on a gold image or group policy quickly.
So to summarize, AppLocker allows you from a high level (Publisher) to a granular level (Version) to choose what applications you would like to allow users to run (white listing) rather than creating long lists of what applications they cannot use (black listing).
@Stephen L Rose, but Basic user level introduced in Vista doesn't work for SRP in Professional?
So I understand what you’re saying about software restriction policies (SRP) offering the same possible functionality, but keep in mind what would be required. Once you have created the deny all you now have to create a policy to allow each individual application to run. There is a big difference between what is possible to do and what is effective to do.
With AppLocker you have much more granular control over the certificate policy. You also have a set of tools that allow you to quickly create the required rules to use an allow list philosophy. These are all new features in Windows 7.
Is there a way to import a hash into an AppLocker policy?? In this case, I only have the hash, not the actual executable and I want to deny access to this .exe.
Daniel, I understand what you're saying, i.e. that a whitelist is better than a blacklist, and I agree with that. However, this functionality isn't new to Windows 7; it's been around since Windows XP. For instance, take a look at this article on the Microsoft website:
"A more secure approach is to set the default rule to Disallowed and specify only the programs that are known and trusted to run."
Similarly, you can identify software from a particular publisher in XP, although the SRP uses different terminology for that ("Certificate rule" rather than "Publisher rule"). In other words, both things that you listed as advantages of AppLocker already exist!
I'm certainly not an expert in SRP or AppLocker, but I do think there are some key advantages to AppLocker.
1) It supports "audit only" mode. That means that you can set up your rules and keep an eye on Event Viewer to see whether any valid programs would have been blocked before you actually turn on the rules. That's certainly easier than turning on the rules and waiting for error messages to appear.
2) I haven't been able to get certificate rules working properly in SRP. The trusted publishers are fine for Office macros, but they don't allow extra programs to run. In AppLocker, the publisher rule does the job nicely. This may just mean that I was doing it wrong (rather than the software being broken), but at the very least it's easier to use.
3) In SRP, you get errors if you try to run programs from the Start menu, even when they're in a trusted location, as described here:
In AppLocker, that's not a problem.
Once I've investigated AppLocker in more detail I'll write my own blog entry about it. For now, I'm concerned that a Microsoft blog is giving out misinformation.
Hello everyone, first a big thanks for taking the time to read the blog post, and also to the folks who manage the Windows Team Blog for posting my article.
To reply to some of the previous comments
Using the publisher condition (when you create the AppLocker Rule) you can specify the version of the software you are allowing, and if you will allow future version or even previous versions. It's very flexible and makes dealing with the scenario you mentioned very easy.
Yes you can also set it up as a block list in that you can create rules that specifically deny software. This can be useful in the event you want to block a particular vendor's software for a particular class of user. (ex: you don't want receptionists installing expensive graphics editing software)
The idea is that in the majority of scenarios this philosophy of blocking applications will tend to lead to a cat and mouse game, whereby administrators are always chasing after users, trying to block the software download of the day.
Using the allow list approach typically leads to a lot less administrator overhead, and aching heads ;) In the end, the technology is designed to give you a great set of choices to suite the widest possible set of needs. In this case I think Microsoft did a terrific job!
AppLocker is available in the the Enterprise SKU and above.
SRP is available in the Windows 7 Professional SKU and above. AppLocker is in the Windows 7 Enterprise SKU and above.
Can someone point to a site which has some price estimates for a small (maybe 10-20) copies of the Enterprise version? I've been googling for a while, and I can't even get a ballpark. AppLocker sounds great, but it sounds like a lot will miss out on it since it's not a part of the Professional edition, unless of course Enterprise is a really good deal.
This will be in the Enterprise and Ultimate editions only. For a chart of versions and features check this out: en.wikipedia.org/.../Windows_7_editions
Is this an Ultimate Extra or will it be in all eight or nine versions of Windows 7?
I'm not sure whether the author realises this, but Software Restriction Policies also allow you to operate a whitelist rather than a blacklist. In GPO, go to:
Windows Settings\Security Settings\Software Restriction Policies\Security Levels
then right-click "Disallowed" and click "Set as default". Initially, "Unrestricted" is the default.
Also, a request - if you provide screenshots, could the hyperlinked versions be a bit bigger? I can see why you want small ones in the main body of the article, but it would be nice to get full size dialog boxes in a separate tab, rather than having to squint at something.
When is the Windows Team Blog going to fix its software? The error below has been recorded for months!! It's hardly a good advertisement for Microsoft services...
"Sorry, there was a problem with your last request!
Either the site is offline or an unhandled error occurred. We apologize and have logged the error. Please try your request again or if you know who your site administrator is let them know too."
It's a pity that you can't use policies to control when Windows Update does its downloads. In some countries ISPs have offpeak billing/download periods (for mine it's 2am-12noon) and it would be very helpful to have Update remain automatic but confine downloads to that period. At present you have to run it fully manually to accomplish this restriction - which is not ideal, especially for unskilled computer users (Windows Update options only allow you to specify install times, not download times.
Microsoft treated this issue as "not repro"(?!?!) for the Windows 7 beta.
Wow thats a long list of achievements "MCT,MCSA,MCSE,MCTS,MVP, STEP Member", title asside Applocker seems like a great idea, certainly easier than blacklisting.
I guess the real world effectiveness of this method will be how programs which automatically update themselves behave with Applocker rules in place. Perhaps Applockers configuration will make that easy to deal with, its hard to tell as the screenshots are small?
Software Restriction Policies (which were implemented through Group Policy) were included in Vista Business and above. Now AppLocker (which is SRPv2 and also implemented thru Group Policy) is not available in Windows 7 Professional SKU. Do Vista Business/XP Pro users lose a feature again after upgrading to Windows 7 Professional? I am concerned especially because Basic user level of SRPv1 doesn't work in any Windows SKU.