Blocking apps with Intune and AppLocker CSP

Artikkeli
08/21/2018

Hello everyone,

Back with another experience to share with you all. This past week, a customer asked if it were possible to create policy to block certain applications from being able to be opened up on Windows 10 devices enrolled in Intune. At the time of writing this blog, such functionality is not available natively within Intune. As in, AppLocker is not an option for a Windows 10 profile type within the Intune portal. However, anytime there is an ask regarding policy that is not native to Intune, we need look no further than searching our CSP library to see if we have the ability to configure policy via OMA-URI. Sure enough, after a quick search, we see we have an AppLocker CSP. So naturally, it's time to review the documentation on the AppLocker CSP.

/en-us/windows/client-management/mdm/applocker-csp

We see from the documentation that our OMA-URI path for what we want to achieve looks like this:

./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/Grouping/EXE/Policy

Notice the word Grouping is bolded above. This is bolded because this is a grouping GUID that can literally be anything you want it to be. For my example, I'm going to use BlockedApps01 as my grouping GUID. So my OMA-URI path is going to look like this:

./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/BlockedApps01/EXE/Policy. This will be important for later when we create our policy in Intune.

Also note in the documentation, we have EXE, MSI, Script, StoreApps, DLL, and CodeIntegrity. Each of these represent the different AppLocker rules you can create as part of an AppLocker policy. For *.exe files, you'd use EXE as part of your OMA-URI path. For any *.appx or modern apps, you would use StoreApps as part of your OMA-URI path. Finally, we have Policy. This is where the actual XML value needs to be specified. And that value will be a string value in the policy. More on this later as we walk through creating the policy in Intune in a bit.

Creating the AppLocker Policy

Now it's time to take a look at creating the AppLocker policy on a test device so we can get our XML for the Policy string value as part of our policy. Now, there are a couple different approaches to creating AppLocker policies. You have whitelisting and blacklisting. Whitelisting is blocking all apps except for the ones you explicitly allow in your AppLocker policy. Blacklisting is allowing all apps and blocking only the apps you explicitly deny in your AppLocker policy. As a result, whitelisting is the far more restrictive method. However, depending on your requirements and how restrictive the policy, you may end up creating a lot more whitelisting rules than blacklisting rules.

This is a personal opinion of mine, but leveraging whitelisting implies that an administrator wants to lock down a device pretty tightly and only allow specific application activity. So rather than annoy your users with pop-ups saying they can't access an application due to policy, why not use an Assigned Access profile? I've worked with customers in the past where we did this via Intune and used Powershell scripts to push out an Assigned Access profile to achieve a similar result as whitelisting. You can also achieve such by leveraging the AssignedAccess CSP on Windows 10 1709 and later devices. Kiosk mode, once it's out of preview would also be a solution, but I digress. For this example, I'm going to be using the blacklisting approach and picking something simple like Notepad to block. Are you ready? Let's get started!

On a Windows 10 test device that has all the desired apps you wish to create an AppLocker policy for, open the local group policy editor. You can do this by clicking Start and typing in "edit group policy" and hitting enter. Once the Local Group Policy Editor opens up, navigate to Computer Configuration > Security Settings > Application Control Policies > AppLocker. Within the AppLocker node, you'll see the different types of rules you can create. Recall we briefly discussed this earlier looking at the AppLocker CSP OMA-URI path.
Since we are going to be using Notepad for our example, we are going to create a Executable Rule. If you wanted to block the built-in Calendar modern app, you would create a Packaged app Rule. Right-click on Executable Rules and select Create New Rule.
In the Create Executable Rules wizard, on the Before You Begin screen, click Next
On the Permissions screen, click the Deny radio button and click Next
On the Conditions screen, ensure the Publisher radio button is selected and click Next
On the Publisher screen, in the Reference file: field, click the Browse button. File Explorer will open. Browse to C:\Windows\System32\ and double-click on notepad.exe. The details of the file will be filled in for you. Click Next
On the Exceptions screen, click Create
You'll get a prompt to create default rules, click Yes.
In the left pane, click on the AppLocker node. Back in the right-pane, click the Configure rule enforcement link
The AppLocker Properties window will appear. Under Executable rules: check the Configured checkbox and select Enforce rules from the dropdown menu. Click OK to close the window
In the left pane, right-click on the AppLocker node and select Export Policy
File Explorer will open. Save the XML to a location on the test device and copy it to your primary machine

Working with the XML

So we've got our XML and earlier we mentioned we need the XML as it will be the Policy string value for our OMA-URI. If only it were that easy. What our docs don't tell you is if you were to copy and paste all of the XML file contents to the Policy string value for our OMA-URI and deploy it, it will fail. What we have to do is copy only a subset of the XML and use that as our Policy string value. Not sure why, but there is zero mention of this on the AppLocker CSP docs page. It took some trial and error and discussing with some colleagues to understand why this was failing for me at first because I was following the docs. Hence the reason for this blog, so you don't waste 8 hours wondering what the heck is going on. Let's take a look at the XML and I'll explain what subset is required for the policy to work properly.

Everything in the red text above represents what needs to be used for our Policy string value for our OMA-URI. The trick here is to ensure you are only copying the RuleCollection tag that shows as "Enabled" (bolded at the top of the XML) down to the closing RuleCollection tag (bolded at the bottom of the XML) just before the "NotConfigured" RuleCollection tags. Everything else should be omitted.

Ok, we've got what we need, now time to go to the Intune portal and let's create our policy.

Create and Deploy the AppLocker Policy in Intune Portal

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
In the Device Configuration - Profiles blade, click the Create Profile button
On the Create Profile blade, in the Name field, name the profile accordingly. In the Platform drop-down, choose Windows 10 and later. In the Profile type drop-down, choose Custom
The Custom OMA-URI Settings blade will appear. Click the Add button
On the Add Row blade, in the Name field, name the settings accordingly.
In the OMA-URI path, we will use what we mentioned earlier in the blog. Copy and paste ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/BlockedApps01/EXE/Policy
In the Data type drop-down, choose String
In the Value text box, copy and paste the XML subset we discussed above (everything in the red text above)
Click OK to close the Add Row blade
Click OK to close the Custom OMA-URI Settings blade and click Create to create your policy
Once created, click the policy. On the Policy blade, click Assignments
On the Assignments blade, in the Assigned to drop-down, select Selected Groups and then click Select groups to include
On the Azure AD Groups blade, choose the groups you want the policy to be applied to and click Select
On the Assignments blade, click Save

Alright, you've now deployed your AppLocker policy to your desired devices or users. Now it's time to see if it worked.

Validating the Result

Ok, you've worked hard thus far. Go grab a cup of joe and doughnut, you deserve it! No seriously, this step is crucial to give the policy time to get to your device. By the time you are done, your policy should be applied to your test device. Of course, you can expedite this process by syncing the device with Intune.

On your test device, click Start and type in notepad
Click on notepad to open it
You get the wonderful screen that was the picture for this blog. On legacy versions of Windows 10, such as 1607, you will not get a pop-up stating the application cannot be run. Instead, nothing will happen. If you were to then navigate to the actual file location and attempt to run the blocked application, then you will get a red X pop-up stating the application cannot run

Troubleshooting

If for some reason your AppLocker policy isn't working as expected, check the Device status for the policy in the Intune portal.

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
Click your AppLocker Policy. On the Policy blade, click Device status
On the Device status blade, review the results. If you see an error, click the entry to drill down. If the error comes back as Remediation Failed, you have a malformed XML string value. A good way to check to see if your XML is malformed or not, open up the XML file in Internet Explorer. If you don't see the familiar XML formatting, but rather a blank page, you have a malformed XML. Go back and review the XML value you copied into the policy. Review the section above that discusses working with the XML file to find the issue with your XML.If you see success, but the specific applications are still running, review your AppLocker policy default rules to understand if you are allowing something in your policy that you shouldn't be.

Wrap Up

Alright, that's it! I hope you got something from this blog. A quick note on whitelisting as I don't want to leave that approach out entirely. With a whitelist approach, the default rules that are mentioned earlier in this blog come into play. For example, with a whitelist approach, you would only retain the Allow > Everyone > (Default Rule) All files located in the Windows folder rule. This now means that the user will not be able to run any applications that does not reside within the Windows folder. Yep, that's right, they won't be able to run Notepad because it resides in the System32 subfolder. It also means that the majority of the modern apps will also be blocked; such as Paint3D and the XBOX app. Even the Microsoft Store app will be blocked. Keep this in mind. While a whitelist approach is more restrictive, it does mean you may end up creating a lot more rules than with a blacklist approach. Again, in lieu of a whitelist, consider using an Assign Access profile. I guess I have the topic for my next blog!

Until next time, happy AppLockering!

Comments

Anonymous
August 26, 2018
Excellent work!

Jaa