But Google Cloud Platform lets you solve this problem as an admin. Learn how.
Let’s assume your company email services are hosted on an on-premise Exchange server, Microsoft 365 or even a GoDaddy email service.
Someone in your company [email protected] wants to access Google services that require a Google user account. This can involve signing into YouTube to create a channel, reading a shared Google document, accessing and managing Google Analytics, running Google Ad campaigns or maybe even firing up a GCP project for testing purposes.
This employee creates a new personal, unmanaged or consumer Google user account with his current email address ([email protected]). Then comes the verification email, and there you go. This employee now has an unmanaged Google user account or identity attached to his email address with your company domain name suffix.
This Google user identity is totally invisible to your organization! As an admin, you can’t access this user’s password or disable it. You can’t even check out the activity logs. If you reset the password via your own system (Office 365, Exchange, Hosting, HR system, etc.), it won’t have any effect on this identity from the Google side of things.
The bigger surprise and a potential security issue is that even if you already registered your company domain name with a Corporate or Managed Google services subscription account (like Google Workspace or CloudIdentity) and you don’t have any other email provider for that domain, an employee can still register an unmanaged account with your company domain name as a suffix.
Simply put, you don’t have any ability to manage this user account!
To understand the aforementioned scenarios and before we proceed with this article, you need to understand three fundamental things:
- Email addresses are unique. Period.
- In cloud services, the email address is the username (identity) to be used to access services, log in and authenticate.
- There are three Google user account types:
* gmail.com user account,
* Personal\ individual\ consumer\ unmanaged user account,
* Managed user account.
How Do You Create Each Account?
Create a gmail.com address and get access to the personal email, drive, contacts and calendar services to be used as an identity to authenticate with other services such as YouTube, Google Analytics and more.
Input your own personal, consumer or unmanaged account with an email address that already exists (like Yahoo.com, Outlook.com or your company domain) to get a verification email. In this case, you are creating a Google identity, not a full end-to-end account with access to email or calendar. You do get drive access.
You do that by going via the same link, but this time clicking the “Use my current email address instead”. You will then get to a screen that asks you to enter the email address and select a password (it doesn’t have to be your email account password). You are creating a new identity in Google, after which you will need to confirm this address belongs to you.
These accounts can be used to be authenticated by Google while trying to access services and create GCP projects, thereby giving other personal, consumer or unmanaged user accounts (using the domain name email suffix) access to GCP projects or to Google Analytics. For the last one, you need to register your business or company domain name with a Corporate or Managed Google services subscription account (like Google Workspace or CloudIdentity).
An admin managing this subscription can create a user for you. These users are called “Managed” user accounts\ identities.
Wait, But There’s a Problem
Now let’s imagine the first scenario from its beginning . Your company has its emails hosted on an on-premise Exchange server, Microsoft 365 or even on a GoDaddy email service, But now there is a need to start managing all your Google accounts in one place to gain more control and visibility.
Maybe even to use Google Analytics or YouTube company accounts and use SSO, when disabling or deleting the user from your system, you want it to be removed from Google. So you register your domain with a company domain name with a Corporate or Managed Google services subscription account — like Google Workspace (Previously known as G-Suite) or CloudIdentity.
You verify that the domain is yours and start using the subscription account. You want to create [email protected]. But when you create it, the system says that this email is already taken. Remember the first rule: there can be only one email address .
You now have a Duplicate\ Conflicting Unmanaged user accounts problem!
Now let’s say you are the super admin of the company for a fully managed Google Workspace account. Let’s assume you have an admin who creates a default routing rule or a recipient address map via the Google admin console for your Google workspace subscription to route any email that is sent to [email protected] (private email address).
Now the same admin goes to the registration for an unmanaged user accounts link and registers the email address. A verification email will be sent to his company inbox, where it will be needed to be verified.
You now have an unmanaged Google user account that can theoretically sign up to Google Analytics, create YouTube channels with your company domain name and even can get unauthorized GCP access. To make things worse, you don’t have any knowledge about this user as an admin, nor can you reset the password, etc.
Currently, Google does not deny creating personal or consumer accounts via a registered domain name suffix. You also don’t have any admin console feature to prevent this from happening. If you contact Google support asking explicitly to deny this option for your Corporate G-Suite or Google Workspace account, they can’t do it and won’t try to.
Contain the Problem Before Solving It
The Solution
If you have a Google Workspace (G-Suite) account, you can go and create a catch-all address via the following link.
A catch-all address ensures that messages sent to an incorrect email address are still received by someone in the organization, who can can then look at them and decide what to do. It can help you identify users who try to activate an unmanaged Google user account. But in case it is an admin that sets a routing rule, let's say with a “Recipient address map”, a catch-all won’t help.
So the best solution that will be good as a workaround for any email system you have is to simply cut the communication between the verification process and the user. Create a content compliance rule with the following conditions (they all must exist — AND not OR):
Inbound direction AND Body match regex `^[0–9]{6}$` AND Body contains text “Verify this email is yours” AND Subject contains text “Verify your email address” AND sender header contains text “[email protected]”.
As long as Google won’t change this metadata, you are good to go. I also recommend not rejecting the verification emails. Change the recipient to an admin, same as the catch-all address, so you can monitor it or not reject emails that may answer the criteria but are not fit for this scenario.
You can also use more protection if needed. In GCP, you can set restriction sharing policy by domain — click here to see how.
This will not allow users outside the domain to be allowed in IAM for organizational projects. Keep in mind that it won’t work retroactively and you will not be able to add users with gmail.com users to your projects. Only managed users within your Google Workspace or CloudIdentity account will be able to be assigned IAM permissions.
Taking Care of the Unmanaged Accounts
First, you will need to have a “Super Admin” role in your Google Workspace or CloudIdentity subscription account to perform the following actions. When logging in to the Admin console, you will have the ability to open the “Transfer tool for unmanaged users”.
Or via the “Users” section by clicking on “More”:
When opening the transfer tool you might see a list of all unmanaged users with duplicate and conflicting user accounts. For each of them, you have the option to send an invite to transfer their unmanaged account to your company. When you send the invite, it’s up to the person (assuming the invite is indeed received) to either accept the transfer request or to deny it.
Once accepted, the username is assigned to your corporate account and will display in your user list. The user can continue authenticating as before, with the difference being that the account is subject to your company policy (2FA, services that are allowed or not, session timeout, etc.). In case this user had access to GCP projects , they can still be accessed.
In case of no response or a declined case, you have the option to make arrangements (create routing rules to route messages that are sent to these user accounts to an admin mailbox), send the invite again and accept it in the name of the user (you are the owner of the domain and MX records are pointing to your company account).
I suggest doing so with caution and try to track down the employee. Maybe it is a former worker that just forgot to close the account or was unaware of this task. You can also just go ahead and create the user.
When creating the user via the admin console — you will be presented with a screen asking you if you want to send a “transfer invite” to the user or to create it anyway — this will create a new managed identity within your corporate account subscription — and will rename the original user to something like “username%[email protected]”.
When the user wants to use his account to access a Google service, they will be presented with the option to choose “Work account”- the account you created, or “Personal account” — the “username%[email protected]”.
The user’s data will stay on the original account, while all related data like Google Analytics or YouTube channels will stay under their personal account. Data will not be accessible with with the new username you have created.
Following the login, the following message will be received:
Be aware that the API is used while using GCDS (Google Cloud Directory Sync) from on-premise MS-AD to Google, auto-provisioning users from MS-AAD (Microsoft Azure Active Directory) or third-party solutions like Okta. The API has no idea about personal, consumer and unmanaged accounts. It will just create the users automatically, and the personal unmanaged user will be renamed, without asking the admin to transfer first.
Conclusion
Google allows anyone to create unmanaged users that can use your company domain email suffix. You don’t have any control over these users, who can be given access to Google Cloud Platform (GCP) projects, create YouTube channels, use Google analytics and more. You have to understand that this is the reality and recognize this as a potential problem.
The good news is that you, as an admin, have the ability to work around this and stop the creation of those users and cancel the ones already created.
To stay connected, follow us on the DoiT Engineering Blog, DoiT Linkedin Channel and DoiT Twitter Channel. To explore career opportunities, visit https://careers.doit.com.
