Group Policy Analytics role in moving User authentication to Azure AD

Context

When I meet with customers one of the conversations I typically have is that organisations would like to start joining new devices (either Autopilot or ConfigMgr deployed) to Azure AD joined and shift their user authentication process into the cloud. This has many benefits, not least the mitigation of having to rely on a VPN back to their on-prem domain controllers to perform the authentication. As the conversation progresses we talk through using Azure AD Connect to synchronise identities, and how that will work with NTFS file shares, then we hit a snag. Group Policies.

Its worth prefixing this post with the fact that typically I work with medium to large organisations with 500+ devices that have many years of GPOs, possibly created and deployed by admins no longer with the company and no clear understanding of what every GPOs purpose is let alone the specific settings in the GPO.

Up until now I have had to explain that these GPOs will no longer apply as the devices will not be joined (or Hybrid Joined) to the existing on-prem Active Directory, and Azure AD does not provide support for GPOs. The migration path would necessitate converting their GPOs to Intune Configuration profiles, enrolling their device to Intune and then deploying the profiles. So far so good… then the killer line “there is no way to convert GPOs to Configuration profiles and this would be a manual process”. At this point they start to estimate the effort involved in analysing these existing GPOs and deciding which ones to migrate and which are stale or no longer required, and they start to favor Hybrid joining the devices just to hang on to what they know as they see it as less effort. This means they miss out on the benefits of Azure AD joining the devices and keep the reliance on their VPN and line-of-sight connectivity to a Domain Controller.

Now we have a new tool to assist with this conversation, Group Policy Analytics in the Endpoint Manager admin center.

Group Policy Analytics allows us to export our existing GPOs to a .xml file and then upload this file to the Endpoint Manger admin center for automatic analysis of all the configuration contained with the GPO. This will then tell us which of the settings can be migrated to Configuration profiles, which are not supported and which are depreciated.

Lets see the workflow in action

Process

Firstly, we need to connect to open Group Policy Management Console on a domain joined device and locate a GPO we would like to test for conversion. We then right-click on the policy and choose ‘Save Report’. Save the .xml file to a temporary location which is easily accessible.

Open Group Policy management and save a GPO as an XML file report.

Then in the Endpoint Manage admin center navigate to Devices > Group Policy Analytics (Preview), select Import and choose the .xml file we previously exported. For my demonstration I am choosing to import the Microsoft provided Windows 10 2004 security baseline GPOs as I know these contain multiple settings and are a good example of complex GPOs.

The admin center then processes the .xml and provides us with a report showing the migration possibility for every individual setting as well as a summary for what percentage of every policy can be migrated to Configuration profiles. We also get a summary showing the total number of settings and migration counts across all GPOs.

Clicking on the percentage column shows us the individual settings included in the GPO and which can be migrated to Configuration profiles.

Summary

This is a big step forward for simplifying the analysis of the workload required in the migration from GPOs to Configuration profiles, and with it helping companies to move to the cloud for user authentication. There would still be additional work to be performed to work through the ‘Not Supported’ and ‘Depreciated’ settings to determine what the impact would be and if any mitigations need to be put in place, but this is a much simpler process than anything that has come before.

However, there are some things still to consider:

Organizational Units to security groups – GPOs by design are deployed to OUs and a computer can only exist in a single OU. Configuration profiles are deployed to security groups. There is currently no way to map OU membership to security groups without writing custom PowerShell scripts and executing these on a regular basis.

Automatic creation of Configuration profile – After the GPO has been analysed by Endpoint Manager it is currently necessary to manually create the Configuration profile. Hopefully Microsoft will introduce a method for automatically creating the required profile with settings ready for deployment.

Intune enrollment – For the propose of this blog I have assumed the the devices in question will be enrolled in Intune and therefore will support Configuration profiles.

Author: Andrew Stalker

I am an IT consultant currently working in Sydney, Australia. I specialise in Microsoft infrastructure technologies, specifically System Centre and Azure Cloud computing including EMS & Office 365.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s