Overview
Google Workspace enrollment allows organisations and schools using Google as their primary identity provider to securely onboard and manage Windows devices.
Because the Windows operating system lacks a native, out-of-the-box identity integration for Google accounts (unlike its native Microsoft Entra ID framework), authentication is achieved via a secure, browser-based OAuth relay hosted by the Mobile Guardian enrollment server. End users authenticate inside a native web view using their existing Google credentials, completely bypassing the need for separate Mobile Guardian account management.
Prerequisites
| Requirement | Detail |
| Google Workspace Account | Users must possess an active Google Workspace or Google Workspace for Education account. Personal consumer Gmail accounts (@gmail.com) are automatically blocked. |
| User Sync Requirement | Target user accounts must be fully synchronised to the Mobile Guardian database prior to starting the enrollment process. Onboarding attempts will be rejected if the authenticating identity is missing from the directory. |
| OAuth Credentials | A Google Cloud project configured with an OAuth 2.0 client mapped to the Mobile Guardian MDM enrollment server. Mobile Guardian will issue the required client ID/secret or guide your project creation. |
Step-by-Step Implementation
Step 1: Authorize the Mobile Guardian OAuth Application
The organisation's Google Workspace Super Administrator must authorise the Mobile Guardian framework to access identity tokens within the domain.
- Log into the Google Admin Console (admin.google.com).
- Navigate to Security -> Access and data control -> API Controls.
- Under the Domain-wide delegation section (or the designated OAuth app approval workflow provided during your specific onboarding session), grant the application client scope permissions.
- Alternative Method: If provided a direct administrative consent URL by Mobile Guardian, open the link while authenticated as a Workspace Super Admin and click Allow to bind the enterprise relationship.
Step 2: Validate User Directory Sync Status
Before distributing devices to end users, verify that all student, teacher, or staff profiles are active within the platform directory.
- Cross-reference your Google Workspace user listings with the user catalogue inside the Mobile Guardian dashboard.
- If sync validation is required, contact Mobile Guardian support to ensure automated directory synchronisation is functional.
[!NOTE]
No Cloud Console URL Routing Required: Unlike Microsoft Entra ID deployments, the Google Admin Console does not feature an equivalent to Mobility (MDM and MAM) settings. No server paths or management URLs need to be saved inside your Google console.
The On-Device User Enrollment Flow
Because Google Workspace integration does not utilise automated back-end cloud queries during hardware provisioning, enrollment is initiated on demand by the end user via the standard Windows settings panel:
[User on Windows Device]
|
v
(Settings > Accounts > Access work or school > Enroll only in device management)
|
v
[Mobile Guardian Web View Pop-up] ---> (User enters Google Workspace Workspace Credentials)
|
v
[Google OAuth Endpoint] -------------> (Authenticates User & Issues Security Token)
|
v
[Mobile Guardian Server] <------------ (Validates Token against Local User Directory Sync)
|
v
(Local Client Certificate Installed & Management Pipeline Active)- On the Windows device, open Settings -> Accounts -> Access work or school.
- Click Enrol only in device management.
- When prompted for an enrollment email address, the user inputs their full organisational Google email address (e.g., user@school.edu).
- Windows launches a secure web view container pointing to the Mobile Guardian enrollment server relay.
- The user authenticates directly into the Google Login interface using their workspace password and any mandated Multi-Factor Authentication (MFA/2FA) prompts.
- Upon successful authentication, Google returns an authorised OAuth token back to the Mobile Guardian relay.
- Mobile Guardian verifies that the user exists in its directory, issues a localised client security certificate via its Certificate Authority (CA), and pushes the management payload package down to the Windows system.