Google Workspace

(formerly G Suite)


Connecting to Google Workspace

We recommend that you connect Google Workspace to Trelica using a Super Admin role. This article explains why, and what the compromises are if you use a user with normal Google Workspace admin role.

Trelica connects to Google Workspace using OAuth2. This is a common protocol which controls Authorization (controlling what Trelica is allowed to do with the Google Workspace APIs).

OAuth2 uses something called "Scopes" which lets Trelica ask for specific access rights.

When you connect Trelica and Google Workspace, you get asked by Google Workspace for permission to grant these scopes to Trelica.

Aligned with the principle of least privilege, Trelica requests the most limited set of scopes it can, for the functionality it needs. So, for users, Trelica asks for read-only access, as that's all Trelica needs for basic operations.

We encourage you to use a dedicated user account for integrating Google Workspace with Trelica, and assigning the user account the Super Admin role.

Creating a custom Google role

IT teams sometimes want to limit the usage of Super Admin roles. The alternative approach is to create a custom Google Workspace role.

If you do this then you will need to assign the following privileges

Admin Console:

  • Reports

Admin API:

  • Organization Units > Read
  • Users > Read
  • Groups > Read
  • User Security Management
  • Schema Management > Schema Read
  • License Management > License Read
  • Domain Management

Note that when you select Admin API privileges, Google Workspace automatically assigns corresponding Admin Console privileges.

For Provisioning and Deprovisioning you must enable the following:

  • Users (all)
  • Groups > Create
  • Groups > Update
  • Data Transfer

Google privileges are relatively coarse, so bear in mind that these are just the privileges that are given to the user you create. When you connect Trelica we request very specific scopes, which further restricts the access we are granted (e.g. read-only access to domain data).

Limitations of connecting with a non super-admin role

There is a slight limitation imposed by Google if you use a non super-admin role.

Trelica uses two sources for data about OAuth token use (i.e. apps where users have used 'Sign in with Google' to connect):

  • The audit log report (https://www.googleapis.com/admin/reports/v1/activity/users/xxxxx/applications/token)
  • The current tokens endpoint (https://www.googleapis.com/admin/directory/v1/users/xxxxx/tokens)

OAuth tokens might have been issued months ago, so the current tokens endpoint immediately provides the most up to date information about token use. Data from the audit log report will accumulate over time.  

A non Super admin user (even if the role is cloned from the Super admin role) cannot access the current tokens endpoint for other administrators.

This means that if you don't use a Super admin role, access data for administrators will take several months to build up once you've made the connection.

This limitation is due to the way Google's API works.

Explanation for lack of OAuth data for other administrators

In Google Workspace, OAuth2 scopes generally exist in pairs - one for read access, and one for read/write access, e.g.

OAuth2 Scope Description
auth/admin.directory.user Read/write operations on users
auth/admin.directory.user.readonly Read only operations on users

One of these scopes is called auth/admin.directory.user.security.

This scope is used so that Trelica can get list of current OAuth2 tokens for users, which lets Trelica see where users have used OpenID Connect (commonly known as "Sign in with Google", or "social logins") to connect to other applications and websites.

Unfortunately, this particular scope does not exist with a "read-only" version. It allows "access to all application-specific password, OAuth token, and verification code operations" (https://developers.google.com/admin-sdk/directory/v1/guides/authorizing).

For security reasons, Google enforces a rule that users with this scope cannot use it in relation to user accounts of other users with Administrative privileges, even if the actual API call is read-only.

The exception to this rule is if the user account that connects to Trelica is part of the super admin role.

Deprovisioning

Basics

When you deprovision a Google user through Trelica, you can:

Revoke access. This will:

  1. Sign the user out from Google
  2. Reset the user's password to a random string
  3. Revoke all OAuth tokens
  4. Revoke any application-specific passwords
  5. Revoke any 2FA verification codes

Clear user settings. This will:

  1. Remove the user from the global address list
  2. Clear the recovery email and recovery phone fields for the user
  3. Remove the user from all groups
  4. Remove all email aliases

You may also want to:

  1. Assign the user to a different org unit
  2. Suspend access
  3. Archive the user
  4. Delete the user 

Email

There are two main approaches to reassigning email:

1. Keep the mailbox open (and optionally set a vacation message). You can either:

  • Grant others access to the mailbox
  • Forward new emails to others

These options require you to grant domain wide delegation to Trelica.

Disadvantages: you need to pay for a full Google license.

2. Close the mailbox, but create a group with the same name. Assigned users have emails forwarded to them. If no users are assigned, mails are stored with the group so that members can be subsequently added, and the messages will be available.

Advantages: no additional cost.

Disadvantages: you end up creating lots of groups

The group is created with the following permissions:

  • "Who can join" - Organization users can request to join
  • "Who can view group" - All Members can view
  • "Who can invite" - All Managers can invite
  • External members not allowed

How to keep emails

You have two options:

1. Assign an archive license

Advantages: Google Vault can still be used for searching / legal holds.

Disadvantages: you have to pay for archive licences.

2. Save the emails in an archive file

Advantages: no additional cost.

Disadvantages: it's harder to grant people access to these emails.

Google Drive files and Calendar entries

You can transfer ownership of Google resources like Drive files and Calendar entries to the person's line manager, or a nominated Google account.

If you transfer calendar entries, we also release all calendar resources booked in events organised by the user. Only future non-private events with at least one guest/resource will be transferred:  https://support.google.com/a/answer/7399420

If you transfer files, the following takes place (from https://support.google.com/a/answer/1247799?hl=en)

  • A transfer folder is created in the new owner’s My Drive with the following contents:

    • Transferred folders and files that were in the previous owner’s My Drive.
    • Transferred Computers folders if the previous owner used a Drive sync client (for example, Drive for Desktop).
    • Shortcuts to the previous owner’s files whose parent folders are not shared with the new owner.

    If no files change ownership, no transfer folder is created.

  • If a file was in someone else’s My Drive but owned by the previous owner, and that file was in a folder that's shared with the new owner, ownership transfers, but the file remains in the existing folder. The file isn't in the transfer folder and no shortcut is created. Sometimes, a separate empty transfer folder is also created.

  • Even if the previous owner's account no longer exists, you can find a file's ownership history in the file's version history or, for recent ownership changes, the Drive log event

Shared drives

Suspended users remain as members of shared drives.

Archiving or deleting a user will remove them from shared drives.

If you need to assign someone else to a Shared drive, go to the main Google Admin console > Apps > Google Workspace > Drive and Docs > Manage Shared Drives.

FAQs

I get an "Error 400: admin_policy_enforced" error when connecting

This means that your Google Workspace administrator has blocked OAuth apps requesting consent. A Google Workspace super admin can either connect to Trelica or they must alter app access settings to allow Trelica to connect.

To do this go to Security > Access and data control > API controls in the Google Workspace Admin console.

  • Ensure that Block all third-party API access is unchecked.
  • Click Manage third-party app access.
  • Under Configured apps, add a filter for ID 702299011990-8mjrfmoi101u51l4cnv4vgm145c8iukv.apps.googleusercontent.com
  • Make sure Access is set to Trusted

It can take several minutes for changes to come into effect.

An "invalid_grant" error is shown, caused by a "reauth related error (invalid_rapt)"

Google supports reauthentication policies. When the configured session length expires, an application is forced to require the user to re-authenticate — similar to what would happen if an admin revoked the OAuth refresh tokens for that application.

This means that your Google Workspace connection may fail after a period of time. You can configure this as a Google Workspace admin by going to:

https://admin.google.com/ac/security/reauth/admin-tools

You should ensure that Exempt Trusted apps is ticked.

Trelica should also be marked as a trusted app under Apps Access Control (there's a link to this on the Google Cloud session control settings panel).

The Trelica client ID is 702299011990-8mjrfmoi101u51l4cnv4vgm145c8iukv.apps.googleusercontent.com

How is the person type determined?

The person type is determined by the following logic:

  1. If the Google "Type of employee" field is set then it is mapped as follows:

    • Employee, Full-time, or Fulltime => Employee
    • Contractor => Contractor
    • Consultant, Vendor or External => External
    • ServiceAccount, Service Account => Service Account

  2. If the Employee Type is not set, then if any of the following fields have a value, the person is marked as an Employee:

    • Employee ID
    • Manager's email
    • Cost center
    • Department

Which employee attributes does Trelica store?

By default Trelica pulls the following employee information from Google Workspace:

  • Employee ID
  • Job title
  • Type of employee
  • Manager's email
  • Department
  • Cost center
  • Building ID

Trelica also extracts the Google groups that each user is a member of.

How do I take data from custom Google schemas, or remap data?

If you need support for mapping custom schema items, or other changes, please contact support@trelica.com.

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.