Featured Post

Using VMware's Horizon Performance Tracker For Rudimentary Blast Optimization

Recently updated for Horizon 7.10, the  VMware Blast Extreme Optimization Guide  focuses on, "two key configurable components: the tran...

Sunday, March 7, 2021

A Quick And Easy Win Along The Path To Zero Trust: Workspace ONE's Certificate Authentication For Windows 10 And macOS

I was recently introduced to an elegant solution for enabling certificate authentication on Windows 10 and macOS devices through VMware's Workspace ONE.   By leveraging WS1 UEM's built in certificate authority WS1 admins benefit from a self-contained, entirely cloud based, end to end solution for both certificate authentication and distribution.  It provides an efficient and wieldy means for enforcing cert auth in modern management use cases, enabling a significant leap forward on the journey to Zero Trust.  While the required steps are a bit advanced, with the right expertise and access requirements, they can be easily implemented in less than an hour.   Once completed, Horizon desktops or apps, SAML federated apps,  or the Workspace ONE portal itself can benefit from certificate authentication on Windows 10 or macOS.  


In and of itself certificate based authentication improves security while simplifying access for users.  More notably, in the context of Workspace ONE modern management it lays the ground work for leveraging WS1 UEM's device compliance policies.  Conditional access based on device compliance ensures that apps integrated with WS1 are only accessed from devices that have earned our trust through WS1 enrollment and compliance, regardless of network location.  Trust is earned and verified at an on-going basis as device posture is regularly incorporated into conditional access policies applied to protected apps.  As a result, clear progress along the path to Zero Trust is achieved given that a guiding principal of Zero Trust adoption is the need for continuous authentication and authorization of endpoint devices.   



















Very arguably the proliferation of mobile devices has played a major role in forcing traditional IT shops to embrace Zero Trust principals and adoption.  Fortunately, capabilities developed supporting these devices within the enterprise are easily extended to Windows 10 and macOS through WS1.  Conditional access based on device compliance is a prime example of this.  For nearly half a decade this feature has been wildly popular among AirWatch customers supporting iOS and Android devices.  As a result, it's a very mature and proven capability that modern managed devices stand to benefit from.  Just as with mobile devices, UEM admins can define proper security posture for Win10 devices and macOS devices, then control access to apps accordingly. 

























When WS1 UEM device compliance policies are leveraged by WS1 Access policies, trust is constantly earned, as WS1 regularly monitors the posture of the underlying device. A device that is suitable for access today may be rejected tomorrow should it fail to maintain security posture defined and enforced through WS1 UEM.  For example, an enforced requirement could be for devices to be both enrolled and and running anti-virus in order for them to gain access to Office 365. 


To further progress across the Zero Trust spectrum we can additionally inform conditional access policies with Risk Scores from Workspace ONE Intelligence.   These Risk Scores not only factor in user behavior across enterprise devices, but can also incorporate insights from Carbon Black.  

Regardless of whether you own WS1 Intelligence or not, the path to Zero Trust through WS1 modern management can begin with a very accessible and easy to implement process for enforcing certificate authentication.  Considering the required effort versus the impact of this solution, the juice is definitely worth the squeeze.  It shifts Zero Trust away from a lofty theoretical concept to something well within reach using mature and proven Workspace ONE capabilities.  


The Recipe 


I was introduced to this recipe while training on support of Zero Trust with Workspace ONE.  Though I'd love to simply share that course curriculum directly in this post it would be morally dubious to say the least.  Fortunately, I found publicly available guidance that's damn near identical to what I received in my training.   This guidance is called, "Windows 10 Certificate Single Sign On Using An AirWatch Certificate authority."  Further, while scouring the internet for additional information I happened upon this personal blog post, "Workspace ONE - Windows And macOS Certificate."  It's a lovely post, completely in line with the training I received, while also providing guidance on macOS.

Since folks can already access these resources for step by step specifics, here I'm simply going to present an outline of the recipe while calling out some highlights. 

Implementing Certificate Auth On Workspace ONE:
  • Export issuer certificate from UEM
  • Enable Certificate Authentication on WS1
    • Upload issuer certificate from UEM
    • Enable Cert Auth On Appropriate IDPs
  • Create SCEP User Based Profiles on UEM
  • Create Conditional Access Policies 
  • Disable certificate prompts

After following the above steps, you'll have the basic use of certificate authentication available across your modern management use cases for Windows 10 and macOS.  You can mandate certificate authentication for access to your WS1 portal, or on a more granular level, make certificate authentication a requirement for specific applications using conditional access policies.  


Major Steps


What really helps simplify the whole strategy is leveraging the built-in CA of your Workspace ONE UEM tenant.   Assuming your WS1 UEM tenant is already integrated with WS1 Access, navigate to Groups & Settings->All Settings->System->Enterprise Integration->Workspace ONE Access->Configuration.   If Workspace ONE UEM certificate provisioning isn't already enabled, then enable it.  Then export the issuer certificate.  
















Next, you're going to scoot on over to your WS1 Access administrator console, navigating to, "Authentication Methods," under, "Identity And Access Management."  Here you're going to enable the, "Certificate (cloud deployment)," method, uploading the issuer certificate just obtained from the WS1 UEM console.  


















You'll need to ensure the Certificate (cloud deployment) authentication method is enabled for your Built-in identity provider or any other relevant IDP configured for your environment, the same you would for any other authentication method.  After that you need to configure your SCEP payloads to distribute and manage certs on your endpoint devices.   These are going to be user based profiles for Win10 and macOS devices.  



















With Certificate authentication enabled and certs getting distributed through SCEP, a final step is configuring the enforcement of this authentication method through conditional access policies. 


Creating Your Conditional Access Policies 


When it comes to configuring conditional access policies a main consideration is whether you're going to combine certificate authentication with device compliance policies. If you just want any enrolled devices to have access, regardless of device posture, you can simply select Certificate (cloud deployment) as the primary auth method, along with any fall backs. Otherwise, if you want to predicate successful certificate auth on compliance with UEM device compliance policies, then choose to combine cert auth with device compliance.   



















In the sample above, compliant devices will gain access to the application through certificate auth, while non-compliant devices will fall back to 2FA with VMware verify.  Devices not enrolled in WS1 UEM or not assigned the proper SCEP policy won't have access at all.  It's an example of where you might go with things if you wanted tighter security.  Along those lines, if you wanted to layer WS1 Intelligence on top of this model, you might go with something like this:















In the example above, Risk Scores are incorporated into your conditional access policies, allowing us to adjust authentication requirements with analysis from Workspace ONE Intelligence.  If a device is compliant and the user has a healthy risk score, they'll have a smooth access experience logging in.  However, if their device meets compliance requirements but the user has a poor risk score, they'll be forced to provide a 2nd factor of authentication with VMware Verify.   

For a nice overview of conditional access policies here's some enablement I recently collaborated with some colleagues on called, "WS1 Access Series Episode 2 Office 365 Integrations And Conditional Access." In the video I spend about 25 minutes reviewing conditional access policies and device compliance.  Further, if you're interested in getting deeper on the subject, I highly recommend this comprehensive and fairly new post, "Workspace ONE Access: Best Practices In Policy Management."


Removing The Certificate Prompt



While the visible certificate prompts at login are useful for initial setup and troubleshooting, long term it's more desirable to have cert selection automated.  Fortunately, there are ways to achieve this on both Win10 and macOS devices across various browsers. 


Windows 10 Certificate Prompts

On Windows 10 devices, when leveraging Chrome for WS1 Access it's all about the
AutoSelectCertificateForUrls Chrome policy. To take this feature out for a very quick test spin you can create the registry edit manually by first adding the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoSelectCertificateForUrls

Then, create a string value of 1, with the catch all syntax of:

{"pattern":"[*.]","filter":{}}










You could fine tune this syntax with something a bit more specific, for example: 

{"pattern":"https://cas-aws.vmwareidentity.com/","filter":{}}

For the Microsoft Edge browser, not surprisingly, we have a very similar process for handling the certificate prompts.  Essentially, we have the same pattern format for catching the cert, just under a different key.   

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoSelectCertificateForUrls

For more specifics check out the official Microsoft documentation for AutoSelectCertificateForUrls.   Below is a screenshot from my own lab. 












Finally, when it comes to IE, there's an easy to use option from internet settings. You can navigate to Security Settings under Internet Options, then enable the policy, "Don't prompt for client certificate selection when only one certificate exists." 























Getting These Win 10 Settings Pushed Out Through UEM


To get these registry settings automatically pushed out to your endpoint devices, if your Win10 endpoints are domain joined, you could always turn to AD GPO settings for Edge and Google Chrome. Here’s a screenshot from my lab:



While using AD GPO’s is certainly an option, it doesn’t feel very modern management-ish, does it? A lot of us turn to modern management to break away from dependency on AD domains, so finding an alternative for delivering these settings through UEM is more desirable. Fortunately, when it comes to migrating away from AD GPOs to WS1 UEM delivery, there’s like 17 ways to skin that cat. One option is to leverage Workspace ONE Baselines to deliver the GPO settings through a Custom Baseline. In my own lab this started by exporting the GPO using the Group Policy Management tool. Then, after zipping up this backup, I uploaded it to a Custom Baseline.


























Then, for extra credit I went ahead and added the option for configuring cert selection on Internet Explorer. (The backed up GPO already included settings from Chrome and Edge.)













After pushing this Baseline out to my Win10 endpoints I was in business and had the desired behavior.   

Again, because we're talking about Windows 10 and WS1 UEM, there's a lot of ways to approach getting these settings pushed out.  For instance, there's this option for pushing out registry settings with a custom profile.  Also, there's this post on pushing out these setting via a reg file and UEM's product provisioning capabilities.  Hell, you could even use AirLift to export your Google Chrome GPOs to a custom profile.   Along those lines, using CSPs to configure Chrome settings is detailed in this older article, Windows 10 - Chrome ADMX.  


macOS Certificate Prompts

To rid yourself of certificate prompts on macOS for Safari we can use the Identity Preference option in the SCEP profile.  By entering in the CAS URL, we can have the cert automatically selected when it comes times for cert authentication.  


For more details on this Identity Preference setting check out the official macOS Device Management Guide.   

When it comes to disabling certificate prompts for Google Chrome, once again, it's all about the AutoSelectCertificateForUrls Chrome policy.  For macOS, this can be configured through a custom payload.  Below is an example from my own lab:


For additional guidance on this macOS policy, you can check out VMware's guidance in this TechZone article, Managing Identity Preferences To Streamline Single Sign-On For macOS.   

East Bound And Down!!!!!


During my recent training it became clear that Zero Trust is a worthy goal and destination, though the march towards it probably wont be fun or glorious.   For most organizations it's not going to be a straight path but rather a series of bursts and stalls, as immediate needs are balanced with long term security objectives.  Further, most organizations will never quite be completely, "there."  That said, there's definitely examples of progress, with Workspace ONE certificate authentication being one of them. It's a clear win, a successful battle, in the long drawn out war that is Zero Trust adoption.  Further, it's a quick win.   To a dorcus malorkus such as myself, it feels swashbuckling, folksie, edgy and, most notably, wildly effective.  When implementing the process for the first time I felt like Jerry Reed in Smokey And The Bandit, barreling across the Zero Trust spectrum with blinding efficiency.

 

Adding A 3rd Party CA Later On 


One of my favorite aspects of this recipe is that it leverages Workspace ONE's built-in CA.  Overall, this makes the entire solution much more accessible and easy to wrap your head around.   When you start talking about 3rd party CA's, a lot of times, folks eyes begin to glaze over as hope drains away.  Pulling off an integration between WS1 Access, WS1 UEM and your various endpoint devices is already daunting enough.   Throw in a 3rd party CA that an WS1 admin probably doesn't have control of and things can get overwhelming.   All that said, I've had brainier folks tell me there's scenarios where using a 3rd party CA is more flexible and appropriate for production.  If that sounds like your situation, you can always start off with the basic recipe called out in this post, then move on to a 3rd party CA when you're ready.   Steveidm details what the process could look like in the article, "Setting Up A 3rd Party CA With Workspace ONE In Your Lab Environment." 

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 BellflowerBlues.com. 




















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 mobile-jon.com 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. 


Conclusion



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.