Google Workspace

Google Workspace is your organization’s directory and, for many, its device management. This connector brings in your Workspace users and the devices registered to them: Chromebooks, Windows, Mac and Linux computers running Endpoint Verification, and managed Android and iOS devices.

Beta. This connector was built from Google’s documentation and hasn’t been verified against a live account yet. It may return incomplete data or fail in ways we haven’t seen. If something looks wrong, contact support@chartingcyber.com.

At a glance

Required permissions

Three read-only scopes, authorized for the service account in your Admin console:

Navigator never writes to your Workspace. Each scope is used independently, so leaving one out only removes that data, not the rest.

Why a service account with domain-wide delegation

Google only lets an application read a Workspace directory unattended through a service account that a super administrator has explicitly authorized. There is no lighter app-only option for the Directory API. Navigator signs a short-lived token with the account’s key and acts as the admin you name, but only within the three read-only scopes above.

Setup

1. In the Google Cloud console, choose (or create) a project and enable two APIs: the Admin SDK API and the Cloud Identity API.
2. Under IAM & Admin → Service Accounts, create a service account. It needs no project roles.
3. Open the account, then Keys → Add key → Create new key → JSON. A .json file downloads. Keep it safe.
4. Copy the service account’s numeric Client ID (shown in its details).
5. In the Google Admin console, go to Security → Access and data control → API controls → Manage Domain Wide Delegation. You must be a super administrator.
6. Click Add new, enter the Client ID, and add the three scopes above, comma-separated. Click Authorize. Changes can take a while (up to 24 hours, usually much less).
7. In Navigator, go to Connectors → Add a Connector → Google Workspace.
8. Enter the Admin email to impersonate and paste the entire contents of the JSON key file, then save.

Google’s own guide: Control API access with domain-wide delegation.

Which admin? Use a dedicated admin account for the integration rather than a person’s, so the connection doesn’t break when someone leaves. It needs permission to read users and devices.

If your organization blocks service account key creation (the iam.disableServiceAccountKeyCreation policy), an administrator needs to allow it for this project.

What data this connector provides

• Users: every user in every domain of your account, with email, name, job title and phone, whether the account is active (suspended and archived accounts are shown as disabled), whether they are a super admin, and whether they are enrolled in 2-step verification.
• Chromebooks: serial number, model, ChromeOS version, MAC addresses, memory (when Google reports it), lifecycle status (active, disabled, deprovisioned), last sync and first enrollment time.
• Other managed devices (Windows, Mac, Linux, Android, iOS): hostname, serial number, manufacturer, model, operating system, Wi-Fi MAC addresses, encryption and compromised status, whether company-owned or personal, management state and last sync. Devices come from both the company inventory and devices users have signed in on.

Known limitations

• Chromebooks have no hostname in Google’s data, so they match other tools’ records by serial number.
• If the Cloud Identity scope isn’t delegated or the API isn’t enabled, Navigator still syncs users and Chromebooks and records a note that other devices were skipped.
• If the user or Chromebook scope is missing, that sync reports an error until it is added.
• Chromebook IP addresses aren’t collected, and Windows/Mac/Linux version details are the single OS string Google provides.
• Group membership, admin roles other than super admin, and Google Workspace apps and licenses are not shown in Navigator yet.