Goal: Only allow compliant devices to access Google Workspace apps.
Before any device is allowed access to company resources on Google Workspace apps, such as Gmail, Google Calendar, and Google Drive, the device must pass Zero Trust checks. These checks should include device trust requirements such as contain security and compliance policies, approved and trusted corporate certificates, and more.
These Zero Trust requirements imply that the device first needs to be registered or enrolled into a corporate device management tool which can scan the device and validate the requirements, prior to allowing access to secure resources.
Enforcing Device Trust also ensures that unsecure (or unknown) devices cannot access secure corporate resources through the Google Workspace apps, even though a user may have the necessary password and credentials.
Device Trust enables multiple factor authentication: something a user knows (credentials) and something a user has (secure device).
Google Workspace customers are presented with an implementation challenge when enabling Device Trust for Android devices.
We have already established that all devices need to first enroll into a device management tool to validate device posture. The issue becomes clear when we understand that Android devices need to authenticate into Google Workspace to enroll into any device management tool. However, they are unable to prove they are a trusted device when prompted by Google Workspace for registration and enrollment.
To put it another way : For Android devices to enroll, they need to authenticate into Google Workspace. To authenticate, they need a certificate. To receive the certificate, they need to enroll! It is an endless cycle.
For iOS devices, this is not a problem, as users can enroll their devices into the device management tool by authenticating directly with that tool or with an Identity Provider, without authenticating into Google Workspace.
For this conversation, we will focus on Mobile platforms only: Android and iOS devices.
The requirement is to federate authentication for Google Workspace to an Identity Provider. For the below example we will be using Workspace ONE Access, but this solution should work with any Identity Provider that is able to separate authentication policies for mobile traffic (such as Okta Identity products).
For iOS devices, we will rely on Identity Management tool to validate device compliance prior to authenticating.
iOS devices that are registered and enrolled into device management – such as Workspace ONE UEM – can be validated for the device compliance requirements, marked as “compliant” and receive a corporate certificate to present during authentication.
If the device becomes non-compliant, the certificate can be revoked, and the device marked as “non-compliant.”
When the device tries to access any Google Workspace app, the authentication is federated to an Identity Provider – such as Workspace ONE Access – with policies to validate Device Trust by either (a) asking for a certificate during authentication, or (b) asking for device compliance.
It is important to note that there should not be a fallback authentication option such as Username/Password, as this would allow iOS devices to bypass the Device Trust validations.
This flow now enforces Device Compliance for iOS devices.
As discussed at the start of this article, Android poses a chicken-and-egg problem with Google Workspace. Android devices need to authenticate into Google Workspace to register and enroll, but at that moment they are still unknown and unapproved devices.
The solution is to allow unknown Android devices to authenticate into Google Workspaces only for enrollment purposes, and in addition enable policy enforcement for access to the corporate apps.
The steps to accomplish this are straightforward in the Google Admin console:
The result is that Android devices can authenticate without passing Device Trust policies, but still cannot access the corporate resources and Workspace apps until after proving Device Trust.
Enable Android EMM Registration in the Workspace ONE UEM Console, under Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration. This integration will register Workspace ONE UEM as your Enterprise Mobility Management (EMM) provider with Google and is required before you start enrolling Android devices. Please reference the VMware Docs for Workspace ONE UEM to learn more about how to complete the Registration. https://docs.vmware.com/en/VMware-Workspace-ONE-UEM
Once you register Workspace ONE UEM as your EMM provider with Google, you will need to enable the checkbox to “Enforce EMM policies on Android devices” in the Google Workspace Admin Console Third-Party integrations, under Manage EMM provider for Android > General Settings > Android > Enforce EMM policies on Android devices.
This flow now enforces Device Compliance for Android devices.
Note: Google recommends that you transition off Google Sync, given there are more secure alternatives available.
This protocol will allow devices using the Native Mail apps or other third-party Mail apps to connect via ActiveSync and access corporate email, calendar, and more. To block access to this protocol, the best course of action is to disable it completely, under Devices > Mobile and endpoints > Universal settings > Data Access > Google Sync > Allow work data to sync via ActiveSync > OFF.
In Workspace ONE UEM, enable MEM via Integrate Direct Model Using Directory APIs.
Enable “Mobile Management,” for ‘Google Sync’ ONLY. Do not enable Mobile Management for the other platforms, as they are already enabled for Device Trust via the previous above steps.
Check “Require admin approval” in the Google Workspace Admin Console.
By following the steps in this article, we have improved security by enabling a Device Trust approach to access. In addition, we have also enhanced the user experience by enabling passwordless authentication into Google Workspace apps via Mobile SSO, and we have improved the adoption of mobile devices.
The next step is to enable data protection on Laptops and Desktop devices. We will cover how to approach a Zero Trust framework for Endpoint devices on a separate article.