In this article I’d like to show how we can use Windows AppLocker in Windows 10 Enterprise to allow only a small subset of programs to run in an enterprise environment. As you already may know AppLocker rules function as an “allow” list meaning that you’re allowed to run only those applications which have the corresponding allow rules in the AppLocker policy.
Suppose our goal is to restrict users to run only a single third-party application installed by an administrator, for example 7Zip. Theoretically we must use a sample PC with the needed applications installed for creating an Applocker policy locally and then exporting it to Active Directory GPO, but for the sake of this test I will create my Applocker policy using 7Zip installed on my DC.
To start with, let’s take a look at my client computer – Win10Ent (Applocker policies may be applied only to enterprise OS versions!):
As we see there’re two recently installed programs – 7Zip and MS Excel Viewer – I’ve installed them under the TestCompany\ExAdmin account. Now I want any other non-administrative users to run only one of these programs – 7Zip and NOT MS Excel Viewer. As I’d like to have the same policy for all of my clients I’ll create a GPO in AD and deploy it for the CLIENTS OU:
The first default rule that allows everyone to run programs located in the Program Files folder must be deleted – otherwise MS Excel Viewer will be implicitly allowed to run for all users.
As for AppLocker policy to be enforces on a computer the Application Identity service must be running, let’s add to the Applocker GPO the enabelment of the Application Identity service in the …\Preferences\Control Panel\Service section:
After restarting my client Win10Ent (or running gpupdate /force ) – up to two times as group policy might just be read after the first restart/gpupdate and only after the second be applied – the policy must be applied and Application Identity service must be running:
Now it’s time to test the policy: I will try to do the following under I) Domain\Admin (TestCompany\ExAdmin) account II) Domain\User1 (TestCompany\User1) account:
a) run allowed 7Zip
b) run MS Excel which was installed by the administrator and
* c) run built-in Calculator
II-a) User1 can run 7Zip:
Again, all works as expected. But let’s try to run the built-in Calculator as Admin and User1 and look at the results:
II-c) User starts the built-in Calc:
– there’s the default rule allowing everyone to run any files located in the Windows folder so why User1 has not succeeded in running Calc.exe? If you take a closer look at the Calc item in the Windows\System32 folder you will definitely notice that Calculator in Windows 10 is a Metro-style app which will eventually be run from the Program Files\WinApps folder (for example you can run it by typing CALCULATOR:// into the Run box), the Calc.exe in the System32 folder is just a wrapper that refers to the Program Files\WinApps\Microsoft.WindowsCalculator_… subfolder.
Given that there’s no AppLocker rule that would allow TestCompany\Domain Users to run programs from WinApps folder this behaviour is by design.
Although there’s the explicit allow rule for Built-in\Administrators for all folders (including Program Files\WinApps) this administrator (TestCompany\ExAdmin) could not run the built-in Calculator.
Furthermore, if we look in the AppLocker log we’ll see that blocking Calculator produces the “Allow” event (both for Administrator’s and User1’s accounts):
Whatever the reason is for blocking the built-in Calculator Windows should not register “allow” event 8002 instead of “deny” 8004 event – this is the first bug in Applocker/Windows 10 Enterpise configuration.
The second is the obviously incorrect Applocker handling of the metro style applications, which leads not only to blocking allowed applications but to non-functioning Start menu and desktop customizations as well (cause they’re the metro style apps themselves).