Wednesday, December 30, 2020

Wrapping VMware's Workspace ONE Security Around G Suite Consumption

Recently I helped design an integration between G Suite (Google Workspace) and VMware's Workspace ONE.  A key objective of the design is to secure G Suite on mobile devices by requiring UEM enrollment for access to services like Gmail or Google Drive.  While phones in a BYOD scenario are a primary focus, the solution accommodates an entire enterprise and range of endpoints including tablets, desktops, and laptops.  Overall, the challenge of securing G Suite across multiple domains and various device types is met through a combination of WS1 Access and UEM, with an option to layer on additional security and automation through WS1 Intelligence.  

The solution traverses a well-traveled and documented path for WS1, essentially the same strategy we'd employ for securing any SAML compliant application with WS1. Look at the graphic above.  Replace the images of G Suite with a logo for Office 365, Salesforce, ServiceNow, Workday, Slack or Zoom.  The relevant steps, strategies and capabilities are generally the same: perform a SAML federation, leverage mobile SSO, and use conditional access policies to judiciously enforce relevant security.  It's a standard WS1 formula for enabling traditional IT shops to securely embrace SaaS adoption. 

An Overview Of The Solution

When it comes to the more advanced security capabilities of Workspace ONE, SAML is the star of the show.  Fortunately, most modern SaaS solutions, including G Suite, support SAML and so stand to gain tremendously from Workspace ONE.  Typically, an integration occurs directly between WS1 Access and the SaaS solution, however, it can also happen through the intermediary of a 3rd party IDP such as Okta, Ping or ADFS.  Regardless, from the user's perspective the end result is usually the same: they're able to leverage their on-premises AD identity and associated authentication methods for secure access to a SaaS based solution.  This article will initially focus on a direct integration between WS1 and G Suite,  then elaborate on options for 3rd party IDPs a bit later on. 

The basic idea with SAML is to have a trust established between an identity provider (IDP) and service provider (SP) through an exchange of metadata and a cert.   Then, going forward, whenever anyone wants access to the service provider they must first prove their identity to the IDP through whatever authentication methods it accepts and enforces.  It could be as simple as basic AD authentication or as complex as Mobile SSO based on device compliance.  Regardless, once the user's identity has been proven to the satisfaction of the identity provider, the IDP will issue the user agent, typically a browser, a SAML assertion that is then forwarded to the service provider in exchange for access to the service.  An absolutely amazing overview of SAML by Peter Pjork called, SAML 2.0: Technical Overview, is available on YouTube as well as VMware's TechZone.   Below is one of my favorite graphics from this enablement.   

In the G Suite integration detailed in this post WS1 Access is the identity provider while the G Suite tenant is the service provider.   This SAML federation is the absolute backbone of the integration, first and foremost enabling users to access G Suite with their AD credentials.  Further, it provides SSO and opens up G suite to a wide range of authentication methods, most notably conditional access based on device posture and compliance.  In a nutshell most of the goodness discussed in this post is rooted in this SAML federation.   The flow of this article is structured accordingly, starting with the G Suite SAML federation, then working through Mobile SSO, conditional access polices, device trust, and WS1 intelligence.   It will also review some of the finer points of the integration particular to G Suite.    Here's the basic outline for this post: 

  • SAML Integration Between G Suite (Google Workspace) And WS1 Access 
  • Mobile SSO for iOS and Android
  • Conditional Access Policies 
  • Device Trust And 3rd Party IDPs
  • WS1 Intelligence
  • G Suite Specific Considerations:
    • Pushing Out Email Profiles To Mobile Devices
    • Token Revocation 
    • DLP

With that said, I'll start with a review of the initial federation between G Suite and WS1 Access. 

SAML Integration Between G Suite (Google Workspace) And WS1 Access

For guidance on a direct SAML integration between G Suite and WS1 Access, I turned to the blog, "How To Integrate G Suite With Workspace ONE Access?",  by Aamir Khan.  Following the steps detailed in this article was relatively straight forward and having it's guidance as a tailwind was extremely helpful. Lining up the pre-requisites was significantly more work than the actual SAML integration.  Steps like getting a test domain setup, deploying a WS1 Access Connector and signing up for a G Suite eval tenant took me an evening, while the actual SAML integration itself was less than a 20 minute affair.  The article breaks down the SAML integration into these 3 major steps: 
  1. Configuring the Google App within WS1 Access
  2. Downloading the Signing Certificate From WS1 Access
  3. Configuring SSO In The Google Admin Console 
While these steps aren't exactly intuitive or for the faint of heart, the blog post lays things out quite nicely. Executing the recipe involved switching back and forth between Aamir's blog post, my WS1 tenant and my Google Admin console.   Essentially it was all plug 'n chug, replacing variables with the specifics of my environment like the G Suite primary domain name and the WS1 Access tenant url.  For instance, here's a screenshot of me updating the preconfigured Google App template in WS1 Access with info about my G Suite tenant at 

Plug and chug, plug and chug:  

Then, downloading the signing certificate was a matter of navigating to Catalog --> Web Apps --> Settings ---> SAML Metadata on my WS1 Access tenant.  From there you can just hit the download button and you'll have the signing certificate. 

Finally, there's the configuration of the WS1 Access tenant as an identity provider for G Suite. Again, just some plug 'n chug, updating the G Suite tenant with info about my WS1 Access tenant and uploading the signing certificate.  

With the integration between WS1 Access and G Suite complete I had the full breadth of the WS1 Access tenant's authentication methods and conditional access policies at my disposal   That's no small thing and something I'm going to elaborate on in a bit.   However, I want to first zero in on the mobile use case and SSO for G Suite applications.     At this point, without further configuration on the UEM side of the equation, mobile G Suite user's are handed off to the WS1 Access tenant for authentication, similar to your normal desktop and laptop users.   Here's a quick demo of what that looks like: 

While this is fine and good, we can certainly enhance this mobile G suite experience using Mobile SSO for iOS and Android. 

Mobile SSO For iOS And Android 

Mobile SSO is a solution from VMware that offers SSO for mobile applications on iOS or Android.   It enables the use of certificate authentication for mobile apps with backends that have been federated with WS1 Access through SAML.  Through a combination of WS1 UEM and WS1 Access, certificate authentication is completely managed and secured on behalf of the mobile app.  Peter Bjork offers a wonderful review of this feature 5 minutes into the video, "Workspace ONE. Access: Feature Walk Through."   Mobile SSO enables VMware customers to overcome traditional challenges with leveraging certificate authentication for mobile apps, "offering near 100% application support," for any mobile solutions that have been federated with WS1 Access. 

When it's implemented for a mobile app, at login time, once a username has been provided, Mobile SSO will kick in, completing the login process for the user.  By enabling certificate use for mobile apps Mobile SSO arguably achieves the remarkable feat of both increasing usability and security.   In the context of a G Suite deployment, particularly in regard to Gmail, it absolutely shines, enabling a simpler user experience accessing email through either the Gmail mobile app or native iOS mail client. Here's a demo of the login process:

While Mobile SSO is a mature and proven solution, it can be a little intimidating to setup.  For guidance on Mobile SSO for iOS, check out this post I published a couple years ago, "Configuring Mobile SSO For iOS In Workspace ONE UEM."  There's also the official guidance from the Workspace ONE Access side of the house, Configuring Mobile SSO for iOS Authentication In Workspace ONE Access.  For Android, I found the article, "Breaking Down Workspace One's Android SSO", at very interesting.

A final step for getting Mobile SSO enabled is the configuration of conditional access policies on WS1 Access.  This involves simply assigning Mobile SSO as an authentication method or paring it up with device compliance policies.   Either way, conditional access policies are a very relevant topic and I'll be covering them next. 

Conditional Access Policies

Workspace ONE conditional access policies can be used to secure G suite access once a WS1 Access tenant has been configured as an identity provider within the Google admin console.  These policies define security requirements while taking into account a users context or device posture.  Circumstances like AD group membership, network range, device enrollment or posture drive the enforcement of authentication methods across different scenarios and uses cases.   The range of authentication methods to choose from can be quite broad in a mature WS1 deployment, enhancing G Suite security from both on-premises and cloud based solutions.  After a user has proven their identity to the satisfaction of these conditional access policies, they're granted a SAML assertion for access to G Suite services. 

In a nutshell, conditional access policies map out different authentication requirements and fall bak methods required for G Suite access under various scenarios.  For instance, you might spell out that Win10 users leverage kerberos on-premises, while requiring AD credentials, certificates or 2FA for off-premises access.  Further, you may have different priorities and mechanism for iOS, Androids or Macs and can configure policies accordingly.  Below is a sample policy configured for a single app in my lab. 

For a more extensive overview of conditional access policies, check out this tutorial, part of a 3 part series on WS1 Access in healthcare.

While a G Suite deployment stands to gain from the entire range of WS1 authentication methods available, Mobile SSO is particularly relevant.   Along with offering convenience for users it also provides a way of mandating device enrollment for G Suite access.  We can further extend this functionality by leveraging device compliance policies to take into consideration the security posture of an underlying device someone is trying to consume G Suite from.  In this manner, access is not only predicated on enrollment, but also device posture in regard to security concerns such as encryption status or OS version. 

We're essentially taking conditional access policies and juicing them with privileged information gained through device enrollment in WS1 UEM.  What constitutes compliance or non-compliance is configured on the WS1 UEM side of the house through device compliance policies.  The various attributes that inform these compliance polices vary from platform to platform.  Below is an example of the options for iOS.  

This fusion of identity and MDM marks a highpoint of WS1, an innovation embraced and well received by most customers.  Fortunately, we can extend this device insight into other 3rd party IDPs like Okta, ADFS and Ping, a feature that's often referred to as device trust.      

Device Trust And 3rd Party IDPs

Conditional access based on device compliance has been a marquee feature of the WS1 suite for some time now.  Fortunately this capability can be extended to 3rd party IDPs by daisy chaining them with WS1 Access tenants.  The WS1 Access tenant, through it's built-in integration with WS1 UEM, can lend device insight to your 3rd party IDP's policies, a capability usually referred to as, "device trust."  An excellent example is the integration offered for WS1 and Okta.  After establishing WS1 Access as a trusted IDP for Okta,  Okta's routing rules can be informed by device posture information known through WS1 UEM.   The details of this integration can be found in the document entitled, "Integrating VMware Workspace ONE With Okta."  

While Okta in particular offers some compelling enhancements for WS1 integrations, as far as basic functionality goes, this device trust capability is something offered to 3rd party IDPs across the board.  For example, similar to the Okta integration, VMware offers guidance for an integration between ADFS and WS1 Access in a document entitled, "Integrating VMware Workspace ONE Access With Active Directory Federation Services."  

This device trust option generally available for all 3rd party IDPs provides VMware customers flexibility and an easier path forward for WS1 adoption.  You don't have to rip and replace an IDP you may have already invested time, money and processes into.  Instead you can simply enhance it with device trust, fortifying what you already have in place with minimal disruption.  In the case of a G Suite deployment, you can continue to have desktops or laptops leverage ADFS or Okta, but then beef up security for mobile iOS and Android use cases.  A next step could be extending device trust to Win10 and MacOS through modern management.  From there you could even begin a transition to a zero trust model.  So, iOS and Android today, modern management use cases tomorrow, and then complete zero trust further years out.  Along the way, you could eventually migrate away from your 3rd party IDP or continue down this federated path indefinitely. 

WS1 Intelligence 

So far, the focus of this post has been on mature components of the WS1 suite.  For a more innovative approach to securing G Suite we can introduce risk scores and advanced automation from WS1 Intelligence.   

Risk scores generated by WS1 intelligence can further enhance conditional access policies.  So far we've talked about using conditional access policies to adjust authentication requirements based on device and identity context.  With WS1 Intelligence Risk scores we can add a 3rd dimension to this model, informing conditional access policies with advanced analytics and machine learning from WS1 Intelligence. 

These risk scores are automatically generated by WS1 Intelligence based on users behavior. They take into consideration actions like delaying critical updates or disabling firewalls and antivirus. They're also impacted by Carbon Black events.   Regularly updated and maintained for each of your users, risk scores are leveraged by conditional access policies to judiciously right size and enforce authentication requirements.
Along with informing our conditional access policies, risk scores can be used to drive WS1 Intelligence's automation engine.  For instance, based off risk scores we can automate actions like enterprise wipes or app removal through WS1 UEM.  Or, on the less negative side of things, we can automate remediation of devices through other WS1 UEM functionality like the assignment of profiles.  

However, automated responses can extend even further through WS1 Intelligence.   Using custom connectors we can integrate with any 3rd party solutions that support REST APIs.  In a nutshell, if you can make it happen with a single request within Postman, you can automate it in WS1 Intelligence.  This opens up a whole world of opportunities. Not only can you execute actions within UEM, but you can create a ticket within ServiceNow or send a message through Teams or Slack.  All this automation can be driven through risk scores or triggered by events detected through the advanced reporting capabilities of WS1 Intelligence.  For more info on automation through REST APIs and WS1 Intelligence, check out this article, "Workspace ONE Intelligence Custom Connector Samples."

G Suite Specific Considerations

The last leg of this post will focus on the G Suite specific considerations of the design.  While WS1 capabilities discussed so far are applicable to a wide range or applications, there's definitely some G Suite specifics and challenges worth noting.  

Pushing Out Email Profiles To Mobile Devices

Traditionally ActiveSync, or Google Sync for Gmail, has been the mechanism of choice for pushing out email configs through WS1 UEM. However, with a shift to modern auth ActiveSync profiles are no longer an option.  By default, when initially configuring email in a modern auth scenario, users will have to navigate wizards to get their email configured.  This will involve launching the email client, selecting an email service, entering in an email addresses and providing authentication.   Android and iOS offer different options to facilitate this process, each with their own caveats and varying degrees of success. For iOS, it’s the relatively new, “Google Account,” payload. For Android there’s a special EMM Registration option for WS1 UEM leveraging a managed Google domain.  

Email Config For iOS

The Google Account iOS payload offers a way to simplify access to Gmail from the native iOS mail client. It provides a mechanism for pre-configuring a user’s G Suite account for use by the native client so that the user need only authenticate successfully to complete the configuration.

If a user is able to follow some basic instructions, the process is fairly convenient and they don't have to select an email service or punch in their email address.  The main requirement is that upon the first launch of their native client, undeterred by an initial error message, they click on a, "details," hyperlink and follow the prompts.  If they do that, they can have their profile configured pretty easily, especially if Mobile SSO for iOS is in place to authenticate on behalf of the user.  Here's a demo of the what the process looks like: 

While this Google Account payload solution for email configuration isn’t completely on par with the convenance of an ActiveSync profile, it certainly offers a worthy alternative. ActiveSync, to say the least, is a bit long in the tooth. It was scheduled for deprecation October of this year, along with Google Sync, though a temporary reprieve was issued by Microsoft and Google due to challenges of Covid-19. That said, the writings on the wall: the future is not with ActiveSync and folks need to get off of it. Using the Google Account payload with modern auth provides a path forward. 

Unfortunately, while the Google Account payload helps with the native iOS client, it doesn’t assist with the Gmail Mobile App on iOS.  When first running the Gmail mobile client on iOS the user will have to select an email service, then punch in their email address. They'll then get redirected to WS1 Access, at which point Mobile SSO for iOS can take the wheel. It's not a horrible experience, just not on par with the connivence of an ActiveSync configured profile. 

Email Config For Android 

While configuration for the Gmail mobile app on iOS is a challenge, on Android there's a very compelling option.  If Workspace ONE is registered as the Android EMM with a managed Google domain, access to Gmail on your Android device is automated and fluid. When a device is registered the users G Suite credentials are associated with the Work Profile and access through Gmail is a snap.   Here's a demo:

There is one major caveat though.  While this offers really simplified access to G Suite mobile apps, it circumvents WS1 Access entirely, preventing the use of conditional access policies for G Suite mobile apps on Android.  So there's a trade off.   In exchange for simplified access you loose conditional access policies for G Suite mobile apps on Android.   However, you're still meeting the bare requirement of UEM enrollment.  This may or may not be an acceptable trade-off depending on your use cases and priorities.  

Token Revocation 

A real world G Suite challenge I recently observed has to do with token revocation on unenrolled devices.  Again, we have a situation where iOS devices present a challenge not experienced on Android. On iOS, after an enterprise wipe the G Suite token is still active and will continue to allow access to email until it's expired.   For most folks, this contradicts the expected behavior of having G Suite access completely  removed from an enterprise wipe.  On Android the challenge is completely circumvented by the default behavior of Work Profiles, but for iOS additional steps are required.

Fortunately, there's a work around available using the old Google Sync MEM configuration.  By creating a MEM configuration but not actually pushing out an ActiveSync profile we can leverage the token revocation feature traditionally used with Google Sync MEM management, while avoiding the pitfalls of ActiveSync.  Essentially it involves going through the motions of a traditional Google Sync configuration, but not actually pushing out the ActiveSync profile.   It's a clever way of harvesting this desirable token revocation feature that's traditionally paired with Google Sync while progressing to the use of modern auth. 

With token revocation enabled, when there's an enterprise wipe the user's token will be removed from all devices.   To continue using G Suite the user's will have to re-authenticate on a remaining device or re-enroll a device into WS1 UEM.   Here's a demo of what happens to email access when a device is unenrolled and this token revocation feature is enabled. 

Overall, I'd say it's a nifty, though non-intuitive, hack for security conscious folks to tap into.  It might not seem significant at first glance, but if you're knee deep in a G Suite deployment with WS1, it's highly relevant.

DLP Considerations

With mobile applications like Google Drive in the mix, DLP is of pressing concern with a G Suite deployment.   While G Suite offers some advanced DLP capabilities through license enhancements, there's some DLP capabilities that WS1 UEM offers out of the box for any application it delivers.  For iOS, there's the ability to prevent the exchange of data with non-managed apps on the device.  While this might not be as granular as folks want, it is something and at least limits access to the data to other applications managed by UEM.  

With Android, once again, through Work Profiles, we have clearer cut delineation between work and personal worlds.   You can fine tune the details of the delineation through the restrictions profile for Android.  

Again, G Suite does offer it's own DLP functionality with additional licensing.  I've reviewed these built in capabilities of WS1 UEM just to add some context. 

BeyondCorp Alliance

An alternative solution that's currently baking will involve a direct integration option between G Suite and Workspace ONE UEM, without WS1 Access.  This has been recently discussed in the blog post, "Democratizing Zero Trust With An Expanded BeyondCorp Alliance."   I'm not fully aware of all the benefits this model will offer beyond the SAML integration covered in this post, but for those who are looking to exclusively protect G Suite it will offer an alternative.   While I'm not certainly when this option will be available, I'm certainly looking forward to seeing what it has to offer.  If nothing else, it could offer a simpler path forward for G Suite adoption when a customer doesn't have WS1 Access already in place. 


It was an absolute blast helping design this solution for a customer.   I haven't had a lot of exposure supporting G Suite, so watching it's deployment secured by traditional WS1 capabilities was certainly a sight to behold.  Again, these are processes and capabilities that WS1 can offer any SAML based solution.  It just so happens that, in this case, the SAML application was the incredibly impressive and feature rich G Suite solution.  Further, while this current deployment model satisfied a real and immediate need, it also laid the ground for the customer's future cloud adoption.  Typically, as folks of the vSphere generation, when we visualize cloud adoption we think of sucking VM's up in the cloud.  However, practically speaking the path of lease resistance is just purchasing services from SaaS vendors instead.  Well, with WS1 infrastructure in place, securely pivoting to these services is a lot simpler.  

Monday, June 22, 2020

Workspace ONE UEM Alternatives To AD Group Policies: Get Yourself Free

Modern management promises the ability to administer desktops and laptops without requiring they have membership to a domain or even connectivity to a corporate network. A common techie response to this proposition is, "what about GPOs?" IT shops have managed desktops with AD based GPOs for decades now, a process that's been pretty much boiled down to a science.  However, when it comes to switching from AD based GPOs to modern management the path forward is far less prescriptive or codified, with a wide range of options and room for creativity.  At the risk of being crude I'd say there's 50 Ways To Leave Your Lover and over 10 ways to leave your AD GPOs while embracing modern management with Workspace ONE.

There are 5 different Configuration Service Provider (CSP) based options alone, including WS1's native Win10 profiles, AirLift exports and Policy Builder. Then there's WS1 Baselines, which under the hood is an amalgamation of 3 different non-CSP based strategies. Finally, there's the GPO migration tool, customized scripts and various imaginable DIY permutations.

This post is a primer on transitioning from AD based GPOs to Workspace ONE's modern management alternatives.  It will review and prioritize various guidance and strategies, with particular focus on the recently released tutorial, Understanding Windows 10 Group Policies: VMware Workspace ONE Operation Tutorial. While providing brief descriptions of the different alternatives I want to zero in on a few key decision points along the path from traditional AD GPOs to modern management.  

Do You Have An AD Legacy To Preserve?

With all the migration options available, overlapping capabilities, caveats and all, sorting out an optimal path forward is tough.  While discussing this challenge a colleague of mine, Jason Walker, made an excellent point. "Well, if someones asking, 'which route should I take,' the first question to asks is, 'who are you and what's your normal role/technical back ground?'"  So are you an MDM guy who's looking for some basic management or are you a grizzled AD administrator who's managed GPOs for decades?  To further refine the question, “does your enterprise have a heavy investment and reliance on GPOs?  Is there a GPO legacy you absolutely need to port over to modern management?"  Getting this question answered elucidates a path forward.  

For the traditional MDM guy or someone who doesn't have the luggage of an extensive AD GPO legacy, start with a careful investigation of WS1's native Win10 capabilities, then move on to WS1 UEM Baselines.  On the other hand, if you have an AD legacy to preserve and extend to modern management, start with AirLift.  The reporting capabilities of AirLift alone are worth the price of admission, providing key information for GPO rationalization.  With this info in hand scan the built in Win10 profiles for overlapping functionality, then turn to WS1 Baselines or AirLift's export capabilities to fill in the gaps.  Finally, in both scenarios, there's an option to fall back to various customized SyncXML alternatives or scripting strategies.

Whichever path you're on an investigation of WS1 UEM's built-in profiles is in your future, so I'm going to cover that next. 

WS1 Win 10 Management Out Of The Box

Before diving into all the alternatives you should first investigate the built-in native Windows 10 payloads.   These payloads map to specific Configuration Service Providers (CSPs), essentially Microsoft's APIs for Windows 10 modern management.  Out of the box there are 30 payload types that configure hundreds of settings.  When you eyeball these payloads there's significant overlap with traditional AD GPOs.   Examples include payloads for password settings, BitLocker, Defender, Windows updates and Windows Firewall.

These built-in WS1 Win10 payloads aren't a complete substitute for the thousands of GPO settings known to mankind.   However, when you think tactically about what’s really essential for Win10 mobile management, what they do cover is formidable.  Given they are built-in capabilities, both easy to implement and maintain, it makes sense to exhaust them fully before exploring alternatives.

For a short but sweet description of WS1 Windows 10 modern management capabilities, check out this video by Chris Halstead, VMware Workspace ONE: Windows 10 Modern Management - Technical Introduction.  For a very dense and comprehensive overview, check out this video by Pat Linsky: VMware Workspace ONE UEM: Windows 10 Modern Management - Technical Overview.

The delta between WS1's built-in Win10 management capabilities and traditional AD GPO settings reminds me of a scene in Monty Python's Life Of Bryant.  While the revolutionaries rant about, "what have the romans ever done for us," they realize, oh yeah, they have done a lot, huh?  Likewise, while WS1 out of the box doesn't have full parity with traditional AD based GPOs, a lot of relevant GPO functionality has been addressed.  "Alright, but apart from Windows Updates, Anti-Virus, BitLocker, Firewall, certificates and settings associated with the other 23 built-in payloads, what has WS1 UEM ever done to replace traditional AD GPOs?"  Well, there's plenty of alternatives to explore, with Workspace ONE Baselines shining brightest.

Bazooka Baselines - The Duck-Billed Platypus Of WS1 GPO Alternatives

Workspace ONE Baselines, a component of WS1 Advanced edition, is, to say the least, one odd duck!  Essentially, it's an offering of 3 very different methods for pushing out settings to Windows 10 devices: Baseline Templates, Custom Baseline and a service catalog of ADMX-backed settings.  Through Baseline templates you apply 100's of settings at a time based off the Windows 10 Security Baseline or CIS Benchmarks.  This is useful for situations where you really want to heavily lock down a Windows 10 device according to industry standards and best practices.  It's ideal for a scenario where someone is looking to manage a Windows 10 device more like a purpose built mobile device.  We're talking about a wad of settings here, 380+ regarding Windows 1809 for example, so there's certainly some commitment involved, with a lot of settings you may have vet.  At first glance it can seem a bit unwieldy,  however you can disable or tweak out values for these settings individually as needed.

This solution offers some very compelling compliance reporting.   Each device with a Baseline assigned to it will report back as Compliant, Intermediate Compliance or Non-Compliant. Compliant represents having 100% of the settings actively applied while Intermediate Compliance represents having 99% to 85% of the settings implemented.  Anything less will report back as Non-Compliant.  By default Compliance status is reported at intervals of every 6 hours, so you get a fairly up to date reflection of the actual state of the device.  Even more impressive is the ability to zero in on a specific device and drill down into which particular settings are currently implemented versus settings that are non-compliant.

This granular reporting really sets the solution apart from other modern management alternatives. With other methods you can always test an individual device with tools like Policy Analyzer or RSoP, but with Baselines we're getting that functionality and insight built right into the UEM console.  Further, there's an option to leverage a registry setting that will force the reapplication of Baselines at a defined interval, ensuring your desired settings remain enforced.  This registry setting can get pushed out through a custom settings payload or manual registry edit, as specified in the latest guidance.

WS1 Baselines also offers a Custom Baseline option which involves pushing out an exported GPO rather than an industry standard template.  You can use Group Policy Manager or LGPO.exe to export a GPO from your current environment, then upload a zipped copy of that backup to the console.  Baselines will then go on to import that GPO on a target device using a local instance of LGPO.exe. 

Custom baselines are a nice little option to have in your back pocket.  If all else fails, do an export of your current AD GPOs and then just blast it out to your target devices.  However, there's two caveats.   One, you're not getting any kind of lifecycle management built into the UEM console.  If you want to make a change to a GPO setting getting pushed out, you'd have to go back to your AD environment, edit the original GPO, do another export, then do another import to Baselines. Also, you don't get the benefit of compliance reporting like you do with Baseline templates.  The latest guidance addresses these short coming quite succinctly with the statement, "You will find that custom baselines lack the ability for full lifecycle management such as, reporting and making edits directly via the console." 

Finally, a third capability of this solution involves a built in cloud based ADMX catalog.  Whether you're going with Baseline Templates or a custom Baseline, you have the option to add additional settings from this catalog.  Honestly, in my mind, this corollary to Baseline or Custom Baseline should be seen as it's own separate solution and represents the closest thing to an, "easy button," for configuring individual GPO settings with WS1.  We're talking a very extensive catalog, with some 4300 group policy settings to choose from. 

After you make your selection, the tool actually leverages functionality traditionally associated with Dynamic Environment Manager, what used to be called, "User Environment Manager."  It's really interesting to see how VMware has harnessed this traditional Horizon tool to round out WS1 Baselines.   Fortunately, this subset of Dynamic Environment Manager's capabilities it built right into the WS1 agent and doesn't require any additional installs.  Another piece of good news is that, like with Baseline templates, you do get compliance reported back regarding these ADMX-backed settings, so that's pretty awesome too.

To wrap things up, here are the three different mechanisms offered by WS1 Baselines:

I told you, this thing is weird, like Weird Al Yankovic weird.  Like a street performer playing Crocodile Rock on 9 separate musical instruments kind of weird.  That said, it sure does cast a wide net.  It's hard to imagine a GPO setting you couldn't theoretically push out with this tool one way or another.  

For a greenfield deployment or situation without a GPO legacy to mind, WS1 Baselines are a dream come true.  For that matter, it's still a very relevant and viable option for those looking to preserve a GPO legacy, with one major caveat.  It doesn't really look backwards at your environment or offer any analysis of what you're currently doing with GPOs.  So for an AD guy looking to preserve a legacy, even if you're determined to use Baselines, you'll still want to run AirLift for it's reporting capabilities.   I'm going to detail AirLift's Policies features next.

For additional info on Baselines, check out:

Official documentation: Using Baselines
Fantastic video: VMware Workspace ONE UEM: Baselines - Feature Walk-through
Latest Tech Zone guidance: Modernizing Group Policies Using Workspace ONE Baselines

AirLift - It's Not Just For SCCM Migrations

The release of AirLift 2.x in 2019 introduced assistance with GPO migrations, making it relevant to pretty much all WS1 customers, not just SCCM admins.  Sure, it's primarily focused on migrating folks from SCCM to WS1 UEM.  However, the subset of it's functionality that addresses AD group policies, Workspace ONE AirLift Policies, is applicable to any customer who has AD group policies they want to port over to modern management.   Further, it's free, with very minimal requirements that are well worth the price of admission.  After standing AirLift up and pointing it to your domain controllers you get an exhaustive report of all the GPOs within your domain, along with their associated settings.  Useful information returned includes which OUs these GPOs are assigned to so you know their current scope within your environment.  Most notably, you get feedback on why or why not such settings are suitable for modern management, as well as whether AirLift can automate the export of these GPO settings to UEM profiles for you.  This reporting functionality is invaluable for planning and GPO rationalization, something I'll come back to shortly.

Again, AirLift also offers an option to export group policies directly from Active Directory to your WS1 UEM environment.  This process is dependent on whether or not a specific GPO setting has a corresponding Configuration Service Provider (CSP).  CSPs represent Microsoft efforts to make Windows 10 a modern mobile operating system.  They're essentially APIs for configuring GPO settings on Win 10 through XML, what's called SyncML.  The Configuration Service Provider reference states, "A configuration service provider (CSP) is an interface to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files." Rumor has it that Microsoft has an army of geeks seeking to create CSPs for all relevant GPOs, but with over 3,000 group policy settings for Windows 10 and 1,800 IE settings, there's plenty of work to be done.

In a nutshell, where it's possible, AirLift generates custom SyncML required to set the GPO settings through supported CSPs.  This SyncML in turn is configured as the payload in a custom Windows 10 UEM profile that can then be assigned to your target devices through Smart Groups.  If you like, the utility offers the option to combine multiple exportable GPOs as a a payload into a single custom profile.  Further, it can also export some 3rd party ADMX policies such as Google or Office.

Before charging ahead with AirLift's export capabilities, you should first leverage it's reporting capabilities for some critical GPO rationalization.  That's a topic I'm going to review next.

For additional info on AirLift, check out:

Official Documentation:  Introduction to VMware Workspace ONE AirLift
Great Video: VMware Workspace ONE AirLift: Windows 10 Migration - Expert Panel
Latest Tech Zone Guidance: Using Workspace ONE AirLift to Analyze Group Policies

GPO Rationalization 

GPO Migration Strategy [Graphic]. (2018). Retrieved June 2020 from Developing A Modern Management Adoption Process

With AirLift reporting in hand you're well positioned to begin rationalizing your GPOs.  As with house moving, it's best to throw away as much as you can rather than get caught up transporting stuff you really don't need.  Perhaps a GPO setting is inherently dependent on domain membership.  Maybe a GPO setting isn't applicable to the latest version of Windows 10, remote users or is just a vestige that's no longer relevant to your enterprise.  Whatever the reason,  if it doesn't have a place in the world of mobile Windows 10 management you need to let it go.  So, rather than trying to port everything over, "just in case," it's best to start with some house cleaning.

After zeroing in on the GPO's that matter to you, the next question to ask is, "what of these settings are accommodated by the native capabilities of WS1 UEM?"  This essentially amounts to, "of these settings which ones are both supported by CSPs AND WS1's built-in Win10 profiles?"  WS1's built-in profiles are reliant on CSPs, so for anything AirLift reports as not being supported by a CSP, you can spare yourself the search.  However, for any settings reported as exportable you'll want to search for a match in the UEM console or Windows Desktop Device Management guide.

For functionality not covered by the built-in UEM profiles, there's a judgement call to be made between leveraging WS1 Baselines or AirLift's policy export option.  

Baselines or AirLift Exports? Another Key Decision Point

If a GPO setting isn't supported by a CSP WS1 Baselines is probably your best bet. However, let's say there's a GPO setting that isn't accommodated by native WS1 UEM functionality, but does have support from CSPs.  Let's take it a step further and say not only is it supported by a CSP, but it's also reported by AirLift as exportable.  Should you proceed with the AirLift export option or should you investigate Baselines?  The latest VMware guidance describes this dilemma as making a choice between, "Modernize or Migrate."  

A lot of the decision hinges on what kind of administrative and lifecycle capabilities you'll need going forward.  There's also a question of how much time and energy you have in the short term.  If all you your settings are supported by the AirLift export option, you're just a few clicks away from a migration.  With Baselines there's probably going to be more up front work, as you manually map out your GPO settings or vet excess settings associated with the templates,  but you get a big fat gui at your disposal from start to finish.  In the future this gui provides a straight forward process for pushing out updates or changes to your policy.  Further, you get granular and up to date compliance reporting on all these settings, along with the ability to reinforce them.  The case is very different if you choose to leverage AirLift's export functionality.  While AirLift may provided a very fast and automated method for migrating your GPOs, it doesn't offer a mechanism for managing these settings going forward.  Essentially, you get your GPO setting, or settings plural, combined into a big wad of SyncML that in turn is added as a payload to a custom profile.

Now, should you want to tweak out the settings pushed out by this profile you'll have two major options going forward.  One, you can edit the SyncML manually or through the assistance of Policy Builder, both of which require some skill.  It's doable, but not for the faint of heart.  A second option would be to edit the original AD GPO, then attempt a new export with AirLfit.  That's a bit unsavory and hardly feels like freedom from AD GPOs.  It feels more like a trial separation at best.  Contrast this with making an update on an existing Baseline, where you make gui guided edits on the UEM console directly, push the new settings out, then later receive confirmation the settings have been implemented.

From the user's perspective there's no perceivable difference between a setting pushed out with a CSP versus Baselines.  What's really a stake is administrative overhead and lifecycle capabilities going forward. With the AirLift export option you get something akin to an easy button for migrating your AD GPOs where CSPs support them, but limited manageability moving forward.  With a transition to WS1 Baselines their might be more work up front,  but there's simpler on-going manageability and a more promising shot at freedom from on-premises dependencies.  Where possible, I would recommend aiming for Baselines adoption, assuming you have the WS1 Advanced licenses required for it.  However, the ideal path forward for you is going to depend on your circumstances. 

For a really interesting analysis on this decision point check out the section titled, Choosing The Correct Policy Delivery Model, in the latest Tech Zone guidance.

Additional CSP Options

If AirLift isn't feasible or it's export function needs customization or augmentation, VMware's documentation calls out 3 other CSP based options.  All involve tweaking out SyncML that's delivered through a Custom Settings profile.   One option is to leverage sample SyncML from the VMware Sample Exchange.  Another is to generate it using a Fling called Policy Builder.   Finally, a third option is to leverage the Microsoft CSP Development Suite.   Of these 3 choices, I find Policy Builder the most accessible and promising. 

To get access to Policy Builder, navigate to and login with your My VMware account.  After selecting which version of Windows 10 you're focusing on you'll get presented with relevant CSPs. 

There's a very wide range of depth and capabilities amongst these different CSPs.  For example, the Accounts CSP has only two configurations options.  On the other hand the Policy CSP has an absolutely mind blowing range of options.  If you browse to Microsoft's Configuration Service Provider reference and select the Policy CSP, you'll see that the settings go on for days. Go ahead. I dare you. See how many scrolls it takes to get through the entire list.  It's a whole lot of configuration options at your finger tips.

For this example, while configuring the Policy CSP within Policy Builder navigate to Device --> Config --> Start.   Here you'll find a boat load of start menu settings.  Zero in on the options to hide the sign out and sleep options from the start menu.  By researching these specific settings within the CSP service provider reference you'll discover that a value of 1 enables these settings.   After punching in the number 1, SyncML is automatically generated on the right hand side of the page.  Clicking the ADD button updates the SyncML to what's required for implementing this setting.   The process is the same for the Hide Sleep option.

Copy this generated SyncML into the Custom Settings payload of a new profile.  For the remove settings, simply go back to Policy Builder and click on the Delete button instead of Add.   The SyncML will change on the right accordingly, replacing <Add> with <Delete>.  Copy this SyncML into the Remove Settings section.  

After assigning this profile to an endpoint you'll see the desired results.  As expected, there's no sleep option on the power button and no sign-on off option on the user start menu option.

Again, when you consider the vastness of something like the Policy CSP, this Policy Builder option is definitely worth more than an honorable mention.  Yeah, it's not as nice as the completely supported processes offered by WS1 Baselines or AirLift.  However, if you're someone who likes to tinker, oh boy!  There's a lot to work with here.

For additional info on Policy Builder, check out:

Latest Tech Zone Guidance: Modernize Group Policies Using VMware Policy Builder
Excellent Overview:  Introducing VMware Policy Builder: The Quick and Simple Way To Build Your Windows 10 Custom Settings

But wait, there's more! 

So if for some reason you just have to say no to AirLift, Baselines or CSPs, no worries, there's more options.   One is the GPO Migration tool, an alternative that's been around for a couple years now.  This tool is similar to the Custom Baseline option in that it leverages GPO backups that are then pushed out to target devices.  While this isn't a fully supported tool, it's certainly an interesting fall back option.  If nothing else, it's a wonderful example of what can be done if someone rolls up their sleeves and decides to get-er-done.  

With WS1 provisioning packages in our back pocket we essentially have an elevated command prompt available on any of our managed Win10 devices.  Well, there's an awful lot that can be done with a command prompt and script if you put your mind to it.  Further, there's an option to push out registry changes directly from a Custom Settings profile in UEM.   This option gets called out in the appendix of the latest guidance, which references the blog post, "How To Set Registry Values Using The Custom Setting Profile In Workspace ONE UEM."   Given that a large majority of GPO settings essentially map out to registry settings, there's a lot of ground you could cover with this option alone.  

Additional Resources For Reporting On GPOs

If you can't run AirLift, need to augment AirLift reporting or just want a quick look at a specific policy with minimal overhead, there's Microsofts own MDM Migration Analysis Tool, MMAT. Unlike AirLift, it wont give you an exhaustive enterprise view of all your GPOs and applicable modern management equivalents.  However, on whatever target system you run it on it will analyze the GPOs currently assigned to that system and report back on the feasibility of migrating them to modern management.  Also, as previously mentioned, there's Microsoft's Configuration service provider reference that details the Windows 10 CSPs developed for modern management.  If there's a specific setting you're interested in making customized SyncML for it makes sense to dive into this reference.

And Get Yourself Free

The subject of WS1's modern management alternatives for GPO settings sits at the intersection of two very different worlds.  On one end of the spectrum you have an MDM admin who, though possibly a brilliant tech, has never touched a production domain controller in their life.  At the other end of the spectrum you've got a grizzled AD veteran who's managed enterprises desktops with GPOs for decades.  They're two very different kinds of people with different expectations and priorities when it comes to AD GPOs.  That their needs for GPO settings overlap may very well be the only thing they have in common.  Accordingly, they're likely to require different paths on the journey to modern management.

For the traditional MDM guy or someone who doesn't have an AD legacy to preserve, I'd say start with a careful investigation of all built-in WS1 capabilities, then move on to to fill in any gaps through Baselines.   On the other hand, if you're in an organization with significant investment in GPOs and need to port that legacy to modern management, the path ideally begins with AirLift. With that reporting you get your arms around what's going on in your environment, size up your challenges and rationalize your GPOs.  Then thoroughly investigate the built in capabilities of UEM.  You may find a lot of what you need is already built into the tool.  From there, investigate Baselines and then fall back to AirLift's export capabilities.  If there's still challenges, you can turn to the other CSP options,  the GPO Migration Tool or various other DIY alternatives imaginable.