Quick tip: Easy method for constructing settings of ingested ADMX-files

This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.

  1. The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
  1. While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
  1. After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
  1. The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.

I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.

Working with Attack Surface Reduction rules to reduce the attack surface of applications

This week is al about Attack Surface Reduction (ASR) rules. ASR rules are originally introduced as one of the four main features of Windows Defender Exploit Guard. Windows Defender Exploit Guard was introduced as a major update to Microsoft Defender Antivirus, in Windows 10 version 1709, and was the successor of Enhance Mitigation Experience Toolkit (EMET). Nowadays ASR rules are just part of the attack surface reduction controls of Microsoft Defender, but many configuration paths will still refer to Windows Defender Exploit Guard. In this post I’ll have a closer look at configuring ASR rules by using Microsoft Intune. I’ll start with a short introduction about licensing and the different configuration options, followed by the steps for configuring ASR rules and showing the actual configuration. I’ll end this post with showing the end-user experience.

Licensing for the usage of attack surface reduction rules

ASR rules target specific types of behavior that is typically used by malware and malicious apps to infect devices. That includes protection against files and scripts used in Office apps, suspicious scripts, unexpected behavior of apps and more. However, it’s good to keep in mind that the full set of ASR rules is only supported in combination with an Enterprise license for Windows 10. Some ASR rules might work without an Enterprise license, as the Defender\AttackSurfaceReductionRules node of the Policy CSP is also available with a Pro edition, but the usage is not officially supported. Also, keep in mind that Microsoft Defender ATP is not required for the usage of ASR rules. With that, I’m referring to the configuration and the local alerting. When an organization wants more, like for example insights and reporting, Microsoft Defender ATP will be required. Besides the licensing, it’s also good to keep in mind that the usage of Microsoft Defender Antivirus is required in combination with ASR rules.

Introducing the attack surface reduction rules configuration options

When looking at the configuration options for ASR rules, it’s clear that currently many options are available within Microsoft Intune. Depending on the organizations preferences, there will be a method for everyone. Now let’s go through these different options:

  • Endpoint protection configuration profile – An Endpoint protection configuration profile can be used to control the security of Windows devices, including BitLocker and Microsoft Defender. The latter category includes the Microsoft Defender Exploit Guard subcategory, which contains an Attack Surface Reduction subcategory. That subcategory contains nearly all currently available ASR rules. This is also the profile type that the Microsoft Defender ATP documentation is referring to. The challenge with this profile type is that the names of the settings don’t correspond with the recommendations of Microsoft Defender ATP.
  • MDM Security baseline profile – A MDM Security baseline profile can be used to apply pre-configured groups of Windows settings that help organization to configure default values that are recommended by the different relevant security teams. That includes the Microsoft Defender category. That category contains nearly all currently available ASR rules. The names of the settings also correspond to the recommendations of Microsoft Defender ATP.
  • Attack surface reduction rules profile – An Attack surface reduction rules profile can be used to specifically configure settings for attack surface reduction rules that target behaviors that malware and malicious apps typically use to infect computers. Nothing more, nothing less. This category also contains nearly all currently available ASR rules and the names of the settings also correspond to the recommendations of Microsoft Defender ATP. Based on the recent introduction of this profile in the Endpoint security section, this profile might be the future.
  • Custom configuration policy – A Custom configuration profile can be used to configure most of the settings that are available in Windows 10 via Configuration Service Provider (CSP). Nearly all MDM-settings are available via CSPs. That includes the ASR rules that can be configured via the Defender node in Policy CSP. This enables an organization to configure all the available ASR rules that are recommended via Microsoft Defender ATP. It does require a bit more work.

Configuring attack surface reduction rules

When looking at configuring attack surface reduction rules, I’ll show how to do that by using the relatively new Attack surface reduction rules profile that’s available in the Endpoint security section in Microsoft Intune. When that profile doesn’t provide enough configuration options, probably none of the other policies and/or profiles does either. Except creating a Custom configuration policy. For that reason, I’ll also show the required information for creating a custom configuration policy for the attack surface reduction rules. That being said, configuring attack surface reduction rules by using an Attack surface reduction rules profile can be achieved by following the next eight steps.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Endpoint security  > Attack surface reduction to open the Endpoint security | Attack surface reduction blade
  2. On the Endpoint security | Attack surface reduction blade, click Create Profile to open the Create profile wizard
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  4. On the Basics page, provide the following information for the ASR rules profile and click Next
  • Name: Provide a valid name for the Attack surface reduction profile
  • Description: (Optional) Provide a valid description for the Attack surface reduction profile
  • Platform: Windows 10 and later
  1. On the Configuration settings page, configure the required ASR rules and click Next
  2. On the Scope tags page, configure the applicable scopes for the ASR rules profile and click Next
  3. On the Assignments page, configure the assignment for the ASR rules profile and click Next
  4. On the Review + create page, verify the configuration and click Create

Once the configuration is applied on a Windows device, the Event Viewer can be used to see what exactly is applied. The DeviceManagement-Enteprise-Diagnostics-Provide > Admin log provides all the information regarding the applied (mobile) device management configurations. That includes this ASR rules configuration. A successful configuration shows an Event ID 814 about the AttackSurfaceReductionRules policy in the Defender area with a configuration string and an Event ID 814 about the AttackSurfaceReductionRulesOnlyExclusion policy in the Defender area with a configuration string.

In other words, when configuring ASR rules by using a custom configuration profile, the AttackSurfaceReductionRules policy, which is an ADMX-backed policy, can be used. The different required GUIDs are documented here and a GUID can be set to 0 (disable), 1 (block) or 2 (audit). An example of the required information that would configure all the currently available rules is mentioned below.

  • OMA-URI: ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules
  • Data type: String
  • Value: {BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550}=1|{D4F940AB-401B-4EFC-AADC-AD5F3C50688A}=1|{3B576869-A4EC-4529-8536-B80A7769E899}=1|{75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84}=1|{D3E037E1-3EB8-44C8-A917-57927947596D}=1|{5BEB7EFE-FD9A-4556-801D-275E5FFC04CC}=1|{92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B}=1|{01443614-cd74-433a-b99e-2ecdc07bfc25}=1|{c1db55ab-c21a-4637-bb3f-a12568109d35}=1|{9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2}=1|{d1e49aac-8f56-4280-b9ba-993a6d77406c}=1|{b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4}=1|{26190899-1602-49e8-8b27-eb1d0a1ce869}=1|{7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c}=1|{e6db77e5-3df2-4cf1-b95a-636979351e5b}=1

Verifying the configured attack surface reduction rules

Now let’s end this post by verifying the configured ASR rules, by looking at the Event Viewer and the actual end-user experience. For testing purposes the demo scenarios of Microsoft Defender ATP can be used. That contains a specific section for testing the different ASR rules that includes sample files to trigger each of the ASR rules. When the user is performing an action that is not allowed, like running malicious macro code in a Word-document, the user will receive a notification that the action is blocked (as shown with number 1, in Figure 3). Besides the notification to the user, an entry will be logged in the Event Viewer, in the Windows Defender > Operational log, with Event ID 1121 (as shown with number 2, in Figure 3). That event provides information about the blocked action.

More information

For more information about (configuring) attack surface reduction rules, refer to the following documents:

Configuring the usage of Bluetooth encryption via Windows 10 MDM

This week a short blog post about configuring Bluetooth on Windows 10 devices that are managed via Microsoft Intune. More specifically, about configuring the Bluetooth encryption strength that is required for pairing Bluetooth devices. Last year there was a vulnerability regarding the Bluetooth encryption key negotiation that was addressed with an update to Windows and a specific configuration that should be performed to required a specific encryption strength. By default Windows allows all Bluetooth traffic, but with this vulnerability in mind some organizations might want to enforce a minimal encryption key size to be required for Bluetooth traffic. Even if that means that some Bluetooth devices won’t work, or stop working. In this post I’ll start with showing how to configure the Bluetooth encryption key size and I’ll end by showing the applied configuration.

Overview of the Bluetooth configuration options

Let’s start with an overview of the Bluetooth configuration options. Windows 10 already provides multiple configurations options regarding Bluetooth, via the Bluetooth policies in the Policy CSP. Most of these policies are already available via a Device restriction policy in the Cellular and connectivity section. That section contains nearly all available policies, with the exception of the latest policy, the ability to configure the encryption key size. That policy is recently introduced with Windows 10, version 2004, and will probably eventually also end-up in the UI.

That doesn’t mean that we can’t configure the Bluetooth encryption key size at this moment. Like with any available setting within the Policy CSP, it’s always possible to configure it by using a custom configuration profile. The only required information is the policy node and the available configuration values. Below is an overview of the required policy node within the Bluetooth section of the Policy CSP and the available configuration values.

PolicyDescription
SetMinimumEncryptionKeySizeThis policy setting helps with preventing weaker devices cryptographically being used in high security environments, as there are multiple levels of encryption strength when pairing Bluetooth devices. The default configuration is 0 and allows all Bluetooth traffic. Number 1 can be used to always enforce Bluetooth encryption and ignoring the precise encryption key size. Any number from 2 through 16 can be used to always enforce Bluetooth encryption and in that case that number also represents the bytes used in the encryption process.

Configuration of the Bluetooth encryption key size

After being familiar with the available policy settings and the possible values, it’s time to take a look at the steps for configuring the Bluetooth encryption key size policy setting. The nine steps below walk through the configuration of a new custom device configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the device configuration profile will be assigned to the selected users and/or devices.

  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/Policy/Config/Bluetooth/SetMinimumEncryptionKeySize
  • Data type: Select Integer
  • Value: 7
  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 setting for only the BusinessEnterprise and Education edition and the existence of this setting for only the 2004 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Result of the Bluetooth encryption configuration

Let’s end this post by showing the result of the Bluetooth encryption configuration. This time I’ll do that by simply looking at the Event Viewer and the MDM Diagnostic Report and relating the information seen at both locations. In both overviews the following corresponding information is seen of the successfully applied configuration.

  1. Policy setting: SetMinimumEncryptionKeySize
  2. Policy area: Bluetooth
  3. Policy value: 7
  4. Policy scope: Device
  5. Policy ID: 5C71E17A-2715-47C6-B338-4EE-07C445339

More information

For more information about the different configuration options for Bluetooth, refer to the Bluetooth policies in the Policy CSP documentation.

Creating a custom look-and-feel across Android Enterprise fully managed devices

This week is all about Android Enterprise fully managed devices. More specifically, this week is all about creating a single look-and-feel across all Android Enterprise fully managed devices by using the Microsoft Launcher app. Similar to working with Android Enterprise dedicated devices and using the Managed Home Screen app. The Microsoft Launcher app provides many configuration options that can be configured by using an app configuration policy. That in combination with the recently introduced feature to configure the Microsoft Launcher app as the default launcher, enables the administrator to create a custom look-and-feel across all Android Enterprise fully managed devices. In this post I’ll show how to add the Microsoft Launcher app, how to configure the Microsoft Launcher app and how to configure the default launcher app. All the required actions for configuring a custom look-and-feel across all Android Enterprise fully managed devices. I’ll end this post by showing the end-user experience.

Configure a custom look-and-feel across Android Enterprise fully managed devices

Let’s start with the steps that are specific to creating a custom look-and-feel across Android Enterprise fully managed devices. For that I will assume that the enrollment of Android Enterprise fully managed devices is already configured and I’ll focus on the steps that are specifically related to configuring that custom look-and-feel. Those steps are: 1) adding the Microsoft Launcher app, 2) creating a custom look-and-feel for the Microsoft Launcher app, and 3) configuring the Microsoft Launcher app as the default launcher. More details of these steps are described below.

Add the Microsoft Launcher app

The first step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to add the Microsoft Launcher app as an app to Microsoft Intune and to assign it to the required users or devices. The Microsoft Launcher app can be set to a specific background and can be configured as the custom launcher on Android Enterprise fully managed devices. The following seven steps walk through the simple process of adding the Microsoft Launcher app as a Managed Google Play store app.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > Android to open the Android | Android apps page
  2. On the Android | Android apps, click Add to open the Select app type page
  3. On the Select app type page, select Managed Google Play app as the App type and click Select to open the Managed Google Play store
  4. In the Managed Google Play store, search for the Microsoft Launcher app, select the app and click Approve to open the Microsoft Launcher permissions dialog
  5. On the Microsoft Launcher permissions dialog, click Approve to switch to the Notifications tab
  6. On the Notifications tab, select Keep approved when app requests new permissions and click Done to return to the Managed Google Play store
  7. Back in the Managed Google Play store, click Sync to create apps that are added in Managed Google Play when the sync completes

Configure a custom look-and-feel for the Microsoft Launcher app

The second step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create an app configuration policy for the Microsoft Launcher app that is assigned to the required users or devices. The app configuration policy can be used to configure a custom look-and-feel for the Microsoft Launcher app. The custom look-and-feel in the Microsoft Launcher app can be used to configure a custom look-and-feel across the Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app to at least show a custom background across the Android Enterprise fully managed devices. That will help with recognizing company devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > App configuration policies to open the Apps | App configuration policies page
  2. On the Apps | App configuration policies, click Add > Managed devices to open the Create app configuration policy wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the app configuration policy
  • Description: (Optionally) Provide a valid description for the app configuration policy
  • Device enrollment type: Managed devices (already greyed out based on the initially selection)
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner Only
  • Targeted app: Select Microsoft Launcher
  1. a) On the Settings page, configure any additional required permissions by clicking Add as shown below in Figure 1.
  1. b) Also on the Settings page, perform the actual app configuration settings to set a custom device wallpaper in the Microsoft Launcher app by clicking Add and creating something similar as shown below in Figure 2.
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

Configure the Microsoft Launcher app as the default launcher

The last step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create a device restrictions policy for configuring the default launcher that is assigned to the required users or devices. The device restrictions policy can be used to configure the Microsoft Launcher app as the default launcher on Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app as the default launcher on the Android Enterprise fully managed devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Android > Configuration profiles to open the Android | Configuration profiles page
  2. On the Android | Configuration profiles, click Create profile to open the Create a profile page
  3. On the Create a profile page, select the following information and click Create to open the Device restrictions wizard
  • Platform: Android Enterprise
  • Profile: Device restrictions
  1. On the Basics page, provide a valid name and (optionally) description for the device restriction policy and click Next
  2. On the Configuration settings page, configure at least the following settings in the Device restrictions sections (as shown in Figure 1) and click Next
  • Enrollment profile type: Fully managed
  • Make Microsoft Launcher the default launcher: Enabled
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

End-user experience

Now let’s end this post by having a look at the end-user experience. This post was mainly focussed on creating a custom look-and-feel across all Android Enterprise fully managed devices by configuring a custom device wallpaper. The result of that configuration and the experience for the end-user, is shown on the right in Figure 4.

It’s good to know that this is just an example of the possibilities that are currently available via the Microsoft Launcher app as a custom launcher. Besides this basic, but most notable adjustment, the Microsoft Launcher app also provides configurations options for more adjustments, like the following:

  • Grid Size – The administrator can define the grid size for apps to be positioned on the home screen.
  • Feed – The administrator can enable the launcher feed on the device when the user swipes to the right on the home screen.
  • Search Bar – The administrator can specify the placement of search bar on the home screen.
  • Dock Mode – The administrator can enable the dock on the device when the user swipes to the right on the home screen.
  • Home Screen Apps – The administrator can define the set of apps that are visible on the home screen from amongst the apps installed on the device. 
  • Home Screen App Order – The administrator can specify the app order on the home screen
  • Home Screen Web Links – The administrator can pin websites to the home screen as quick launch icon.

More information

For more information about configuring the Microsoft Launcher app and configuring the default launcher, refer to the following articles:

Microsoft MVP 2020-2021!

Awesome! A few hours ago I received that great email that I’m awarded with the 2020-2021 Microsoft MVP Award for my contributions in the Enterprise Mobility technical communities! That’s number 6!

To me this is always worth a small post. On one hand because I’m very honored, very proud and very exited of receiving my sixth award in a row, but on the other hand even more because I just need to let everyone know that it’s made possible by my great family. Without their support, this blog wouldn’t exist! Without their support I wouldn’t be able to contribute the way I am! Like every year, a really big thank you to my awesome wife and our super kids for giving met time to do my “thing”.

Me and my family are ready for another community driven year!