Deploy Microsoft Defender Application Control policies without forcing a reboot

by

This week is all about Microsoft Defender Application Control (MDAC). More specifically, about configuring MDAC policies on Windows 10 devices by using Microsoft Intune without forcing a reboot. MDAC, often still referred to as Windows Defender Application Control (WDAC), restricts application usage by using a feature that was previously already known as configurable Code Integrity (CI) policies. To make the history lesson complete, configurable CI policies was one of the two main components of Windows Defender Device Guard (WDDG). History aside, CI policies help with protecting Windows 10 devices by checking apps based on the attributes of the code signing certificates and the app binaries, the reputation of the app, the identity of the process that initiated the installation (managed installer) and the path from which the app is launched. In this post I won’t focus on how MDAC technically works, but I want to focus on creating a custom MDAC policy and deploying that policy by using Microsoft Intune, without triggering a reboot. The same steps are actually applicable to deploying any custom MDAC policy by using Microsoft Intune. I’ll end this post by having a look at the end-user experience.

Create Code Integrity policy

The first action is to create a custom MDAC policy, which was formerly known as a Code Integrity policy. However, as a lot in the configuration is still referring to Code Integrity, or CI, I’ll keep referring to it in this post as a Code Integrity policy. Luckily, Windows already contains a few examples that can be used as the starting point (in a folder named CodeIntegrity). As this post is not focussed on constructing a custom Code Integrity policy, I’ll use DefaultWindows_Enforced.xml as my custom Code Integrity policy. That policy enforces the rules that are necessary to ensure that Windows, 3rd party hardware and software kernel drivers, and Windows Store apps will run and is also used as the basis for all Microsoft Endpoint Manager (MEM) policies.

PowerShell can be used to make all kinds of adjustments to a Code Integrity policy (the .xml policy file), by using the ConfigCI module. From that module the Set-RuleOption cmdlet can be used to modify the rule options in a Code Integrity policy. The configured rule options appear under the Rules property in the .xml policy file. Currently there are 19 different rule options that can be configured and those rule options are documented here. For this post the most important rule option, is rule option 16. That rule option can be used to allow future updates to the Code Integrity policy without requiring a system reboot. Below is an example of how to add rule option 16 to the Code Integrity policy. Using that same example with the -Delete parameter, will remove the no reboot information again. 

Set-RuleOption -FilePath .\DefaultWindows_Enforced.xml -Option 16

Below in Figure 1, with number 2, is an example of the information that will be added to the .xml policy file, after adding rule option 16 to the Code Integrity policy.

  • Figure 1: MDAC configuration XML example

Note: The detailed reader might notice that I’ve removed some default rule options in Figure 1 that are normally already configured by default. That is correct, because I wanted Figure 1 to focus on the specific settings of this post.

Transform Code Integrity policy

The second action is to transform the Code Integrity policy, so it can be distributed by using Microsoft Intune. To distribute the Code Integrity policy, it must be converted from a .xml policy file to .bin file. From the earlier mentioned PowerShell module, the ConverFrom-CIPolicy cmdlet can be used to convert a Code Integrity policy into a binary format. That binary version of the policy can be installed on Windows 10 devices and can be distributed via Microsoft Intune. Below is an example of how to convert the .xml policy file.

ConvertFrom-CIPolicy -XmlFilePath ".\DefaultWindows_Enforced.xml" -BinaryFilePath "DefaultWindows.bin"

Distribute Code Integrity policy

The third action is to distribute the Code Integrity policy, by using Microsoft Intune. To distribute the binary version of the Code Integrity policy, a custom device configuration profile can be used to achieve that. That requires the correct OMA-URI.

Construct OMA-URI

To distribute a custom Code Integrity policy, the ApplicationControl CSP can be used. This CSP was added with Windows 10, version 1903, and provides extended diagnostics capabilities, support for multiple policies and it supports rebootless policy deployment. The latter is the main difference with the AppLocker CSP. Unlike the AppLocker CSP, the ApplicationControl CSP detects the presence of no-reboot option. The following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/{PolicyID}/Policy. In that OMA-URI, the PolicyID should actually be an existing value and not a self-generated value, like with most other policies that are configured. In this case the PolicyID should be the PolicyID of the Code Integrity policy. That PolicyID can be found in the .xml policy file, as shown in Figure 1, with number 1, and should be used without the curly brackets. For this example that means that the following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy.

Create custom device configuration policy

To actually distribute a custom Code Integrity policy, Microsoft Intune can be used to configure the constructed OMA-URI on Windows 10 devices. The following nine steps walk through the process of creating a new custom device configuration profile that configures a single OMA-URI setting.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom device configuration profile
  • Description: (Optional) Provide a valid description for the custom device configuration profile
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name for the OMA-URI setting
  • Description: (Optional) Provide a valid description for the OMA-URI setting
  • OMA-URI: ./Vendor/MSFT/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy
  • Data type: Select Base64 (file)
  • Value: Select the created binary file
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this CSP for version 1903 and later) and click Next
  4. On the Review + create page, verify the configuration and click Create
  • Figure 2: OMA-URI configuration example

End-user experience

Now let’s end this post by having a look at the end-user experience, once the Code Integrity policy is distributed and applied to the Windows 10 device of the user. The first thing that the user might notice is that the device doesn’t request a reboot. When the user now wants to start an application that doesn’t comply with the configured Code Integrity policy, the user will be prevented from starting the application. Figure 3 shows an example of a user that wants to start an application that was manually installed and the user receives a clear message that the app is blocked by Windows Defender Application Control.

  • Figure 3: Example of the end-user experience

More information

For more information about deploying WDAC policies, refer to the docs about deploying Windows Defender Application Control policies by using Microsoft Intune.

Discover more from All about Microsoft Intune

Subscribe to get the latest posts sent to your email.

33 thoughts on “Deploy Microsoft Defender Application Control policies without forcing a reboot”

  2. Hi Peter,

    Great article, was wondering if you could help as my Google-Fu is failing. Can WDAC be used if Windows Defender is disabled ( auto disabled ) due to a 3rd party AV like Cisco AMP being installed ?

    Thanks Tony

    Reply

    • Hi Tony,
      I can’t say for sure, as I haven’t used it without Windows Defender Antivirus, but I would think that it should technically work. Just in the bigger scheme of products (Microsoft Defender for Endpoint) it might less efficient.
      Regards, Peter

      Reply

  3. Hi Peter, great article.

    However, when implementing this (and adding in Option 14 for ISG), on an Autopilot device the Office 365 installer in Device Setup no longer works. If I remove the policy from the device, the Intune process works without issue. Has anyone come across this type of behavior for Autopilot devices?

    Reply

      • Hi Peter, the installation logs are saying:

        Error: CodeIntegrity
        EventID: 3077

        “Code integrity determined that a process (..\OfficeClickToRun.exe) attempted to load (..\ClickToRun\msvcp140.dll) that did not meet the Enterprise signing level requirement or violated code integrity policy (PolicyID:{a2443…}).

        EventID 3033 also shows the same error but just the Enterprise signing level requirements part.

        I have shortened some of the filepaths in the error logs.

        Is there somewhere in the XML file that needs to state Enterprise signing level values for certain apps?

        Reply

  4. Hi Peter,

    You have mentioned Microsoft Defender Application Control in this article more than once, I assume you are referring to Windows Defender Application Control (WDAC)? This seems to be the correct product name nowadays.

    Or am I mistaken and is there another product you are referring to?

    Kind Regards,
    Laurens

    Reply

  5. Hey Peter , We are testing a POC with End point manager and SCCM .We have set SCCm in co-management and assigned a collection . the devices have enrolled in end point manager but when they did a pop up shows “Your about to be signed out .Windows will shut done in 10 minutes “”

    We don’t know where this is coming from as we have no policy stating to do this ? thoughts ?

    Reply

  6. we have Created WDAC policy and deployed enforce mode , for testing i trayed install some old application
    Eg. vlc086h.exe, 7z1900-x64.exe

    still its allowing to install the old apps, what could be the reason

    Reply

  7. Hi. If activating Application Control normally requires a reboot to activate Hyper-V for it to function correctly, then how does this method activate the required Hyper-V feature without the reboot?

    Reply

  8. Hi Peter, thanks very much for this, I know with config manager there is a tick box you can use to avoid reboot

    Is this the only workaround for ensuring there is no reboot? Just asking as there doesnt appear to be a lot of up to date blogs on it

    Thanks again,

    Bill

    Reply
  9. Pingback: Using Smart App Control as starting point for Windows Defender Application Control – All about Microsoft Endpoint Manager

  10. Hi Peter, thanks again, testing WDAC no reboot policy as above, is there a way that this policy prevents reboot of other instances

    Testing Symantec Uninstall group (symantec installed through Intune , using uninstall option) and Defender install group

    Both these on their own create a reboot, hoping to test WDAC no reboot with them to ensure that no reboot happens, is this possible? Is there a time that WDAC needs to be implemented in order for this to happen?

    Reply

      • Thanks Peter it was forcing a reboot, (there was a service account updating members of the group so KB4052623 was being triggered) WDAC was being used as well, I have used a device config to onboard defender and it doesnt reboot…Just looking to test if this is because of the custom OMA-URI bin file as above.

        Reply

        • Ah, okay. When using this configuration (especially the rule option 16) it will make sure that WDAC doesn’t force a reboot (the reboot is still needed to finalize the configuration). That, to my knowledge, doesn’t suppress any other reboot.
          Regards, Peter

          Reply

  11. hello Peter,
    if you push it out trough a custom policy, if you enable all defender settings afterwards, also the defender application guard settings in audit mode trough intune.

    Will it enable the settings without a reboot?

    thank you

    Reply

  12. Hello Peter,

    Thanks for this. Do you know how to deploy a signed CI policies(base policy with some supplemental policies) through Intune for Windows devices? When I tried it, it make my devices fail to boot at next restart. Could you help me?

    Thank you very much for all your shared work.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.