Support Tip: Using AppLocker to create custom Intune policies for Windows 10 apps
Published Mar 12 2019 09:05 AM 82K Views
Microsoft

Hi everyone, today we have another article from Intune Support Engineer Mohammed Abudayyeh where he shows us how we can leverage AppLocker to create custom Intune Device Configuration policies to control Windows 10 modern apps. His example demonstrates just how easy it is to create a quick Intune policy that can be used in lots of different ways to control Windows apps in your environment.

 

=====

 

Windows AppLocker is a technology first introduced in Windows 7 that allow you to restrict which programs users can execute based on the program's attributes. In enterprise environments it is typically configured via Group Policy, however we can leverage the XML it creates to easily build our own custom policies that perform many of the same tasks with Microsoft Intune.

 

The process flow goes like this: We first model the policy we want to implement using AppLocker in Group Policy Editor. We then export the XML for that policy and use it to create a new, custom Windows 10 Device Configuration policy in Intune. Once the custom policy is deployed, the same policy behavior we modeled with AppLocker in Group Policy Editor is then applied to our targeted Windows 10 devices.

 

You can find all of our documentation on Windows AppLocker here, and in this post I’ll walk you through an example using this process to block the built-in Mail app on Windows 10 computers.

 

Generating the XML

The first step is to generate the XML we need for Intune by modelling the policy on a Windows 10 computer.

 

1. On a computer running Windows 10 Enterprise, start Group Policy Editor (GPEdit).

2. Under Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker, right-click and select Properties, then enable Packaged app Rules and select Enforce rules. This turns on our AppLocker rules. Once done, click OK.

 

98594 - jch1.png

 

3. Next we need to create two Packaged app Rules: one default rule to allow all apps to run, and another rule to block our particular app. First, right-click Packaged app Rules and select Create default Rules. This will create a rule that allows all signed apps to be executed. Note that this setting only applies to Modern Apps and not Win32 applications.

 

98594 - jch2.png

 

4. Now create another new Package app Rule by right-clicking Packaged app Rules and selecting Create New Rule. This will start the Create Packaged app Rules wizard. Click Next to continue.

 

98594 - jch3.png

 

5. In this example we want to deny everyone access to the Mail app, so on the next screen select Deny and specify Everyone, then click Next.

 

98594 - jch4.png

6. Select Use an installed packaged app as a reference and click Select.

 

98594 - jch5.png

 

7. Here is where we select the app we want to block. In our example we’ll choose the one with Package Name = microsoft.windowscommunicationsapp which is the Windows Mail app. Once selected, click OK and Create.

 

98594 - jch6.png

 

8. Now we have a local policy created that blocks the built-in mail app. This will be our template.

 

98594 - jch7.png

 

9. Next we need to export that policy so we can use it in Intune. Right-click AppLocker and select Export policy. Save the file on a share so you can access it from the computer you will be using to create the policy in Intune.

 

98594 - jch8.png


10. When exporting the policy, an XML file will be generated that looks something like this:

 

<AppLockerPolicy Version="1">

  <RuleCollection Type="Exe" EnforcementMode="Enabled">

    <FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the Program Files folder." UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePathCondition Path="%PROGRAMFILES%\*" />

      </Conditions>

    </FilePathRule>

    <FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePathCondition Path="%WINDIR%\*" />

      </Conditions>

    </FilePathRule>

    <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

      <Conditions>

        <FilePathCondition Path="*" />

      </Conditions>

    </FilePathRule>

  </RuleCollection>

  <RuleCollection Type="Msi" EnforcementMode="NotConfigured" />

  <RuleCollection Type="Script" EnforcementMode="NotConfigured" />

  <RuleCollection Type="Dll" EnforcementMode="NotConfigured" />

  <RuleCollection Type="Appx" EnforcementMode="NotConfigured">

    <FilePublisherRule Id="65bd6e53-0bf6-43dc-a85d-9668f66bf9dd" Name="microsoft.windowscommunicationsapps, version 16005.11029.0.0 and above, from Microsoft Corporation" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">

      <Conditions>

        <FilePublisherCondition PublisherName="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ProductName="microsoft.windowscommunicationsapps" BinaryName="*">

          <BinaryVersionRange LowSection="16005.11029.0.0" HighSection="*" />

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

  </RuleCollection>

</AppLockerPolicy>

 

It’s important to note that if we use all of the XML in our Intune policy then the policy will fail because it includes other NotConfigured rules for things like MSI, Script, DLL and APPX. What we need to do is take only the configured RuleCollection element of our XML for use in our policy, like this:

 

<RuleCollection Type="Exe" EnforcementMode="Enabled">

    <FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the Program Files folder." UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePathCondition Path="%PROGRAMFILES%\*" />

      </Conditions>

    </FilePathRule>

    <FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePathCondition Path="%WINDIR%\*" />

      </Conditions>

    </FilePathRule>

    <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

      <Conditions>

        <FilePathCondition Path="*" />

      </Conditions>

    </FilePathRule>

  </RuleCollection>

 

Creating the Policy

Once we have our XML, the next step is to create our policy in Intune and deploy it to users.

 

1. In the Intune admin portal, select Device configuration-> Profiles-> Create profile.

2. Enter the following settings:

  • Name: Enter a name for the profile, such as Block Mail App.
  • Description: Enter a description for the profile.
  • Platform: Choose Windows 10 and Later.
  • Profile type: Choose Custom.

98594 - jch9.png

3. On the Custom OMA-URI Settings screen, select Add then enter the following settings:

  • Name: Give it a unique name so you can easily identify it.
  • Description: Enter a brief description that describes the setting.
  • OMA-URI: Enter the OMA-URI you want to use as a setting. In this case it is ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/Native/StoreApps/Policy. This comes from the AppLocker CSP and you an find our documentation on that here.
  • Data type: Choose String
  • Value: Enter the XML from your exported policy. In our example this is the green text above.

98594 - jch10-2.png

4. Select OK to save your changes, then OK and Create to create the policy. Your profile will be shown in the Device configuration - Profiles list:

 

98594 - jch11.png

 

5. Lastly, assign your new profile to the groups of your choice. Once applied, when a targeted user attempts to launch the Mail app they will receive the following message:

 

98594 - jch12.png

 

IMPORTANT On the Windows 10 PCs that will be assigned the Intune policy, the Application Identity service must be running. This is the default, however if you’ve disabled this service for any reason, or if you have an issue where the policy is not being applied as expected, check the service and make sure it’s configured correctly. To do this, run services.msc and find the Application Identity service, then make sure Startup Type is set to Automatic and the Status is Running.

 

98594 - jch13.png

Summary

In this post I showed how you can easily leverage the XML generated by AppLocker to create custom Windows 10 Device Configuration policies in Intune. While the example I used demonstrated how to block the native Mail app on Windows 10, this same process can be used to control application execution for a variety of apps in many different ways. Be sure to check our complete documentation on AppLocker to learn more about the types of rules you can create for Windows 10 devices in your environment.

 

Mohammed Abudayyeh

Intune Support Engineer

12 Comments
Copper Contributor

Hey 

i am trying to restrict my company users to use only edge by blocking all the other browsers. I have created an Custom OMA-URI setting under                  "./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/Grouping/EXE/Policy". 

Value : String 

But when its executes it blocks all the application in my client machine instead of only the listed application. Please help me out. 

<RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePublisherRule Id="1eae04f8-5cd3-4745-9feb-162225b53e1c" Name="FIREFOX.EXE, in FIREFOX, from O=MOZILLA CORPORATION, L=MOUNTAIN VIEW, S=CALIFORNIA, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MOZILLA CORPORATION, L=MOUNTAIN VIEW, S=CALIFORNIA, C=US" ProductName="FIREFOX" BinaryName="FIREFOX.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="d0f46b8e-ae6b-495a-b405-09cd62eaebc4" Name="CHROME.EXE, in GOOGLE CHROME, from O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US" ProductName="GOOGLE CHROME" BinaryName="CHROME.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="04e1ad9b-c486-4d67-b025-969830887180" Name="IEXPLORE.EXE, in INTERNET EXPLORER, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="INTERNET EXPLORER" BinaryName="IEXPLORE.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="ba49526f-c1a2-4017-86f5-f7b97a6fea15" Name="OPERA INTERNET BROWSER, from O=OPERA SOFTWARE AS, L=OSLO, C=NO" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=OPERA SOFTWARE AS, L=OSLO, C=NO" ProductName="OPERA INTERNET BROWSER" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
</RuleCollection>
Copper Contributor

@shabinBS 

I got the same error as above. did you able to find any solution?

Please help.

 

Looking at the xml above.. it's totally wrong...  You must define allow all other files first! and create exceptions on that allow list

 

Just like I did with cmd.exe powershell.exe etc

 

Where the Wild Applocker Rules Are - Call4Cloud

Copper Contributor

Overall, this worked well, but we are having the oddity that Teams.exe is now blocked only on some PC's. 

 

Any ideas anyone?

 

Thanks. 

Copper Contributor

JC thank you. But the explanation was not clear: the lines, highlighted in green, are only the programs that were authorized.

 

Where are the APPX lines that block the Mail app?

 

Answer: I tested it with the @Rudy_Ooms_MVP  tips and it worked.

 

@Rudy_Ooms_MVP your work is excellent, thank you so much for sharing.

 

Question: the exceptions will be added within the same rule, for example: in the EXE policy, in Intune, I add from one FilePublisherRule to another, correct?

 

ERRATA: 

 

"The Applocker policy itself is hardened with the Lolbas Project in mind. Looking a little bit closer to the policy itself, you will notice that I added exclusions to the default allow paths. Let me explain why… When configuring your applocker XML, you need to make sure all locations that are “writable” from the user context are excluded from the allowed paths!"

 

Source: https://call4cloud.nl/2020/06/applocker-a-la-minute/#:~:text=The%20Applocker%20policy,the%20allowed%...!

 

Thanks for your time.

 

 

Iron Contributor

Is this suitable to replace applocker GPOs? It looks difficult to maintain, eg blocking or whitelisting additional apps/EXEs. Not to mention difficult to quickly understand rules at a glance (Applocker GPOs are pretty simple to read). Thanks

Copper Contributor

Anyone have experience with updating applocker rules once implemented in Intune? We've got the MS store blacklisted for our school with some apps whitelisted, when we add further apps to the whitelist the store still says "installation blocked by company policy" if you reimage the device it picks up the new rules fine. It's rather odd...

When you change that policy are you also seeying it ending up on the device? Also make sure there is only 1 applocker mdm folder in that device.

 

Did you changed rhe config you still had or did you cooy pasted (and changed) the config from the intune xml?

Copper Contributor

It ends up in the C:\Windows\System32\AppLocker\...\...\...\MDM folder. exe and msi rules update fine, its only store apps that wont install - makes me wonder if the store has a list somewhere that needs to be refreshed. wsreset.exe didn't help though so I'm back to square one.

Iron Contributor

Microsoft we are really missing a nice a easy way to maintain and update our AppLocker Policy in Intune - compared to how to maintain a AppLocker in GPO, the .xml for OMA-URI is really a hazzle.

 

I guess I am not the only one thinking so. 

Copper Contributor

I am using AppLocker along with WDAC. The WDAC policy seems to work fine, it is a device level policy and affects all users by design.

 

However, I created an AppLocker policy to block edge browser and assigned to a single user in Intune. However, even when I switch the user on the same device, the edge browser is getting blocked. 

 

is it because I chose everyone for users and groups while creating the deny policy in local security policy.

 

Copper Contributor

Block all third-party browsers except Edge.

"I'd like to share my experience with exporting XML to Intune. I encountered similar issues, such as the blocking of Microsoft Teams and some laptops experiencing clicking on the Windows start icon. I found an alternative solution by accessing the Intune console directly and creating a Device Configuration policy. Within the setting catalog, I selected 'Don't run specified application' in system settings. After specifying a list of applications (chrome.exe, firefox.exe, opera.exe), all third-party browsers mentioned on the 'don't allow' list were successfully blocked. This method worked effectively for me."

Version history
Last update:
‎Mar 12 2019 09:05 AM
Updated by: