How to Whitelist apps using Applocker in Intune

-

Windows AppLocker is a technology that has been around since Windows 7 days. In enterprise environments, it is typically configured via Group Policy, however one can leverage the XML it creates to easily build your own custom policies that perform many of the same tasks with Microsoft Intune. The only thing that one needs to be mindful of is whether you want to Deny or Allow access to a list of executables. Each of the methods have their own advantages and disadvantages, but with Allow (Whitelisting), one needs to apply extra caution as it can result in breaking of the system and cause all sort of functionality issues.

I implemented a whitelist applocker policy in 2020, but never blogged about it so this is coming straight out of the archives.

What all is involved?

  1. Identify a list of apps that you want to Whitelist in the XML.
  2. Model the policy that you want to implement using AppLocker in Group Policy Editor and export the XML.
  3. Use the XML to create a custom Windows 10 Device Configuration policy in Intune and deploy it.

Identifying a List of Apps

I used the following parameters to identify a list of apps.

  • Add rules for default OS apps.
  • Add rules for apps being managed by Intune.
  • Add rules for a specific list of apps that are being used across the organization (if applicable).

Application

Intune Managed

Citrix Workspace App

Yes

Google Chrome

Yes

MS Teams

Yes

Powerpoint

Yes

Skype for Business

Yes

Excel

No

Applocker xml

AppLocker enforces rules by grouping enforcement for different types of files. AppLocker includes five different types of rules collections:

  • Executable files: .exe and .com
  • Windows Installer files: .msi, mst, and .msp
  • Scripts: .ps1, .bat, .cmd, .vbs, and .js
  • DLLs: .dll and .ocx
  • Packaged apps and packaged app installers: .appx
Open Local Security Policy Editor. Type secpol.msc, click Run as administrator.


Expand Application Control Policies, click on AppLocker, and click on the Configure rule enforcement on the right side.


You can configure the enforcement setting to Enforce rules or Audit only on the rule collection.

In case of Enforce, rules are enforced for the rule collection and all events are audited.

In case of Audit only, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
 
Check the Configured box under file types and click on Apply then OK.

The three primary rule conditions are publisher, path, and file hash.

This helps you to determine in which the AppLocker rule is based. what condition, controls are available and how it is applied.

Publisher – Publisher conditions can only identify digitally signed applications. It is easier to maintain compare to file hash rule as it doesn’t need to update frequently and a single rule can be implemented for the entire product suite.

Path – Path conditions are best for known paths such as program files and windows. It provides less security compared to other rules as if a rule that is configured to use a folder path holds subfolders that are writable by the local users.

File hash – File hash rules use a cryptographic hash system of the identified file for files that are not digitally signed. It is more secure compare to path rules.

Expand Application Control Policies under AppLocker. Right click on Executable Rules and click on Create Default Rules.


In left pane under AppLocker right-click on Executable Rules then select Create New Rule.

Click on Next.

Since I am whitelisting, I am selection Allow option. When selected, you can then specify which files can run for a particular user or groups of users in your environment.


On the Conditions page, either select Publisher or Path condition and then click Next.


Browse to the executable and select it. Leave the version out to accommodate for future versions.

Click Next.


Repeat the steps for all other executables that you want to include and move on to next step for exporting the xml.

In order to export, from the AppLocker console, right click AppLocker, and then click Export Policy. 

The exported xml will look something like this. Make a note of the executables needed for Teams to run and function properly.

<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>

    <FilePathRule Id="28aab472-7e3a-49e4-9e88-23d79c5299e0" Name="%PROGRAMFILES%\Citrix\*" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

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

      </Conditions>

    </FilePathRule>

    <FilePublisherRule Id="9af949af-396a-49b1-a8ec-1e99f591c239" Name="MICROSOFT TEAMS, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT TEAMS" BinaryName="*">

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

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

    <FilePublisherRule Id="eeb81d2b-a70f-4879-b221-c486d15547fb" Name="MICROSOFT TEAMS UPDATE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT TEAMS UPDATE" BinaryName="*">

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

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

    <FilePublisherRule Id="d08d2914-d2b5-4b6b-9aea-ecd0d3fb1c38" Name="CHROME.EXE, in GOOGLE CHROME, from O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <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="8825c32f-28aa-4a09-9d71-582763cf7429" Name="POWERPNT.EXE, in MICROSOFT OFFICE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT OFFICE" BinaryName="POWERPNT.EXE">

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

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

    <FilePublisherRule Id="b929b79c-ff49-4c4c-a351-ced1ab10c15f" Name="EXCEL.EXE, in MICROSOFT OFFICE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT OFFICE" BinaryName="EXCEL.EXE">

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

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

    <FilePublisherRule Id="656b90db-f13b-4172-a73a-ffd3bef39bde" Name="LYNC.EXE, in MICROSOFT OFFICE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">

      <Conditions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT OFFICE" BinaryName="LYNC.EXE">

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

        </FilePublisherCondition>

      </Conditions>

    </FilePublisherRule>

  </RuleCollection> 

Intune Device Configuration Policy

We will use the values from the exported XML to create the CSP policy as shown below –

  1. Sign-in to the https://endpoint.microsoft.com
  2. Browse to Devices – Windows – Configuration Profiles
  3. Click Create Profile
  4. Select Platform as Windows 10 and later
  5. Select Profile as Custom
  6. Use the following values for the fields in the custom profile and assign to a device based group:

Name: AllowedApps01

Description: Only the allowed executables & paths are allowed to run.

OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/AllowedApps01/EXE/Policy

Data Type: String

Value: Copy the contents of the XML file between < RuleCollection> </RuleCollection> as highlighted in yellow above and make sure it gets displayed without any error and then assign to a group of users or devices.

Testing & User Experience

All AppLocker events are logged to Applications and Services event logs under the path Microsoft\Windows\AppLocker

  • Microsoft-Windows-AppLocker/EXE and DLL
  • Microsoft-Windows-AppLocker/MSI and Script
  • Microsoft-Windows-AppLocker/Packaged app-Deployment
  • Microsoft-Windows-AppLocker/Packaged app-Execution

Event ID – 8001, indicates that the AppLocker policy was successfully applied to the computer.

Event ID – 8004, indicates The .exe or .dll file cannot run.


When you run an exe that is not allowed to run as per the exported XML, then the user will see a message like this –

Until next time..

Comments

  1. hubertApril 9, 2022 at 5:51 AM

    It's a good work and efforts for this article. This is really helpful for me in my problem solving. Thanks a lot for Shearing! You also shear it to any one.
    Search Hear

    ReplyDelete
  2. AnonymousOctober 18, 2023 at 12:31 AM

    Thank you so much for this guide and it is really helpful to finalize my work.

    ReplyDelete

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $P...
Read more