post views: 4,284

Introduction

A new version of Microsoft 365 Apps for enterprise security baseline was released last week, delivering the latest recommended security configuration for the included applications.

Now, by the time of writing, not everything can be transitioned into Microsoft Intune natively. There are simply not MDM support for each and every setting. So for those settings without MDM support, you will have to leverage ADMX ingestion or PowerShell.

This post will give you insight on using Group Policy Analytics, as well as how to use ADMX ingestion and PowerShell to completely transition management of the security baseline into the cloud.

Security baseline

The security baseline for Microsoft 365 Apps for enterprise (long name, huh?) is being updated with a new version semi-annually (June and December). The real intention I believe, is to use this with Group Policy and this is probably also what most have done for quite a while.

Some hints on the Microsoft 365 road map, that the intentions are to bring this to Microsoft Intune natively: Microsoft 365 Roadmap | Microsoft 365

Now, Group Policy is something I personally want to avoid, even though my devices are hybrid joined. So what are your options, if you want to manage this solely with the cloud?

Export your current GPOs

What I did, was to import the baseline as outlined in the documentation.

You can find the download to the latest Security Baseline, including the documentation here: Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center

After import, I ended up with 6 new Group Policy Objects as shown below. This gave me an easy approach to browse each policy and make some minor tweaks.

After making the tweaks, I exported all 6 objects. I did that using below snippet of PowerShell:

Adjust as you see fit. Make sure you have the folder being exported to, and if you have renamed the objects, adjust the $m365Filter variable accordingly. 🙂

$domainName = "fqdn.domain.com"
$m365Filter = "*Microsoft 365 Apps*"
$exportPath = "C:\Temp"
$getGPOs = Get-GPO -All -Domain $domainName | Where-Object {$_.DisplayName -like $m365Filter}

foreach ($GPO in $getGPOs) {
    try {
        Get-GPOReport -Name $GPO.DisplayName -ReportType XML -Path "$exportPath\$($GPO.DisplayName).xml"
    }
    catch {
        Write-Verbose -Verbose -Message "Failed to export $($GPO.DisplayName)"
    }
}

Running the PowerShell code, will leave you with 6 .XML files similar to below:

Group Policy analytics

In the Microsoft Endpoint Manager admin center: https://endpoint.microsoft.com find and locate Group Policy analytics:

Within Group Policy analytics, you have the option to Import your exported Group Policy Objects:

Point to and select all the exported .XML files. The process should be similar to below screenshot:

Once imported, you will find the 6 Group Policy Objects listed in the UI.

The interesting part here, is the MDM support column. This illustrate how many of the included settings, that Microsoft Intune has support for natively. This being via Administrative Templates or the Settings catalog.

The 3 policies with 100% MDM support are easily migrated straight away.

Click on the 100% indicator for each policy. This will take you to a screen similar to below, where you have the option to Migrate the settings:

Select the setting you want to migrate to the cloud. You can select the settings individually or use the option ‘Select all on this page‘.

NOTE: The ‘Select all on this page‘ option comes handy, when you have a policy with a lot of settings. You will realize, when you are migrating some of the other policies. 🙂

Complete the migration wizard, give the new policy a name and assign to the relevant devices.

NOTE: For your inspiration, below is a snippet of some of my policies including the one being migrated above (DDE Block):

That was easy?

But what do you do, when there are missing MDM support for some of the settings, like with the ‘MSFT Microsoft 365 Apps v2206 – Computer‘ policy?

Again, clicking on the 99% indicator will take you to a screen similar to below. Here you will notice, that the setting ‘Block Flash activation in Office documents‘ is the one missing native MDM support.

What you also should notice, is that this setting in particular is covered by the MS Security Guide category, which means the setting is included in the Administrative Template of the same name (SecGuide.admx).

This adm. template is also included in the download of the actual security baseline: Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center

ADMX Ingestion

First of all, if you are new to this topic, I’m advising you to do some additional reading on top of this post.

I’m recommending that you do some more reading, as well as getting your hands dirty. You will need to try this for yourself, in order to fully get the grasp of it.

Here are some excellent posts on the topic. Read all of these, combined with hands-on:

SecGuide.admx

The first thing you want to do, is to ingest the actual SecGuide.admx file into your device. This is done via the Policy CSP and OMA-URI.

But before you do that, you will have to edit the actual SecGuide.admx, as it per default contains registry locations which Intune cannot write to.

More on that limitation here, explaining exactly what locations that Intune is permitted to write to: Win32 and Desktop Bridge app ADMX policy Ingestion – Windows Client Management | Microsoft Docs

Now, go open SecGuide.admx with your favorite text editor. I’m using Notepad++ in below screenshots.

The policy we want to KEEP, is the policy called: Pol_SecGuide_A001_Block_Flash. This policy is writing to HKLM\Software\Microsoft\Office\Common\COM Compatibility, which is NOT within the limited scope.

The Pol_SecGuide_A001_Block_Flash policy starts at line 329:

And ends at line 502:

Each policy is contained within a <policy> </policy> block. If using Notepad++ or similar, it’s quite easy to remove any other policy but the Pol_SecGuide_A001_Block_Flash.

You will essentially end up with a SecGuide.admx, which only has that one policy and therefore looks something similar to below:

Back in the Microsoft Endpoint Manager admin center: https://endpoint.microsoft.com. Browse to Devices -> Configuration profiles and Create profile:

In the ‘Create a profile‘ blade, select the option to create a custom profile as shown below:

Add two new custom OMA-URI settings:

Name: SecGuide Admx Ingestion
Description: Empty
OMAURI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/CustomSecGuideAdmx/Policy/CustomSecGuideAdmx
Data type: String
Value: The entire content from the modified SecGuide.admx

Name: Block Flash
Description: Empty
OMAURI: ./Device/Vendor/MSFT/Policy/Config/CustomSecGuideAdmx~Policy~Cat_SecGuide/Pol_SecGuide_A001_Block_Flash
Data type: String
Value: <enabled/><data id=”Pol_SecGuide_Block_Flash” value=”Block all Flash activation”/>

Putting together the value of the last OMA-URI setting (Block Flash), is the combination of various content from the SecGuide.admx.

I have highlighted all the various content which are used. As said earlier, this requires that you have some knowledge of this already.

NOTE: To understand how this is extracted and put together from the .ADMX file, I really recommend that you read the blog posts I mentioned in the beginning of this paragraph

Result on the device

The result on the device, is the creation of the registry keys referenced by the .ADMX file:

PowerShell

The more go-to option, is to configure the rest of the policies using PowerShell.

For that purpose, I have created 2 scripts which can be used with Proactive Remediations in Microsoft Intune.

Detect-Registry-Legacy-JScript.ps1

This script can be found on my GitHub repository here: PowerShell/Detect-Registry-Legacy-JScript.ps1 at master · imabdk/PowerShell (github.com)

This script replaces the entire GPO: MSFT Microsoft 365 Apps v2206 – Legacy JScript Block – Computer

NOTE: With this at hand, you are only minutes away from configuring the rest of the policies using PowerShell. The script is easily edited, to make changes to any other registry key.

Configure-Registry-Legacy-JSScript.ps1

This script can be found on my GitHub repository here: PowerShell/Configure-Registry-Legacy-JSScript.ps1 at master · imabdk/PowerShell (github.com)

This script replaces the entire GPO: MSFT Microsoft 365 Apps v2206 – Legacy JScript Block – Computer

NOTE: With this at hand, you are only minutes away from configuring the rest of the policies using PowerShell. The script is easily edited, to make changes to any other registry key.

Proactive Remediations

Use above 2 scripts with Proactive Remediations:

Result

The result on the device, once the scripts has run, is the creation of the registry keys and values referenced by the Group Policy:

ENJOY 🙂

1 thought on “Use Group Policy analytics to migrate Microsoft 365 Apps Security Baseline to the cloud”

Pingback: Hardening: Using LGPO to enforce non-Intune supported settings on AAD devices. ACSC example. – Colin Ford Blog