Security has always been an overwhelming field for IT administrators. It’s something that can never really be defined in terms of percentage. When was the last time you heard an administrator say he or she is 100 percent secured? I’m guessing never. There’s always a burden of securing the network, securing the servers, installing important security patches across all machines, and cluelessly hoping one does not become a victim of a zero-day exploit.
Sometimes it’s inevitable, and bad things do happen. But what bothers me is when things go wrong because of the silliest of mistakes ending up in big blunders. As a precaution, I personally avoid installing third-party software unless and until it’s either from a reputed publisher or absolutely necessary. On the other hand, there are users who randomly run any executable they find lying around and bring in all sorts of infected flash drives they used at a cybercafé to send pictures of their new pet to all the family members. Dealing with browser toolbars, icon docks, and similar crapware like that is a nightmare for administrators like me with partial OCD. How do we deal with this?
Of course we can disable access to removable devices altogether from group policy and prevent users from installing any software. But doing that has an adverse effect on employee productivity, like users who may want to install genuine software for legitimate reasons. This is where AppLocker comes to the rescue. It allows you to maintain a fine balance between accessibility and security. Although this feature has been around since Windows Server 2008 R2, I’ve seen few people actually use it – probably because not many people are aware of how powerful this feature is. That’s why we’ll revisit this old friend and learn how to configure Applocker in Windows Server 2012 R2 in this post.
AppLocker is an application lockdown and control mechanism. It gives the administrator a very granular control over which applications are allowed to execute and which are blocked. This includes executables (.exe), Windows Installers (.msi & .msp), scripts, or Modern UI apps.
You have a three conditions to choose the basis for screening the application.
Publisher rule: If your application has been digitally signed by a publisher, then this is a viable option to go for. Here you can choose from a wide range of parameters like publisher name, product name, version, filename, etc., as basis to allow or deny execution. For example, you could either choose to block all Adobe software (publisher name), or just Adobe Flash (product name), or just version 184.108.40.206 (version), or files from Adobe named flash.exe (filename).
Path rule: When you want to block or allow access to executables only in a specified UNC path, you can choose this option. For example, you could block F:\Games and allow D:\CorpData.
File hash rule: If your application is not digitally signed by a publisher, you can use this option to block or allow access based on the file hash. For example, this could be any file that may not have a publisher name and could be anywhere in the file system.
To understand this better, let us consider a scenario: You want to implement a solution in which you can use removable devices to transfer documents and other files, but any executables on the removable device will prevented from running. Here’s how we go about it in Windows Server 2012 R2 in three parts:
In the first part we created all the rules needed for AppLocker in our demo scenario, but have not enforced the rules to take effect. We’ll do that here.
If you carefully read under the Configure Rule Enforcement section, it also says “For the AppLocker policy to be enforced on a computer, the Application Identity service must be running.” We’ll do this bit in this final part to bring AppLocker to life.
That’s it! Now wait for a couple minutes for all this to come into effect and you’re good to go. To test, try running an executable from any removable device. You’ll get this error message:
You’ll have no problems running any executable from your local disk. This solves the problem of unsolicited software in removable devices being executed voluntarily or involuntarily. Although what we configured here is only enforced on the local server, you can extend the same functionality of AppLocker to your domain computers by using Group Policy instead of the Local Security Policy console. It’s pretty much the same. I think I’ll leave that up to the readers to try that out and explore more about this.
If you have any questions, jot them in the comments section.