Serve Two Google Cloud Identity Domains with One Azure Active Directory Tenant

If your organization federates user identities in Google Cloud through an existing identity management system, such as Azure Active Directory, and has multiple tenants through that system, you can set up separate Google Cloud organizations for each tenant, if desired. However, this begs the question of whether or not it’s possible to set up separate Google Cloud organizations from a single existing Active Directory tenant, and how to go about configuring this type of set up for an organization.

In this article, we’ll explain the best practices for configuring a secondary organization in Google Cloud without having to create a new Azure Active Directory tenant.

What is Cloud Identity?

Google Cloud Identity is a customer identity and access management platform that allows organizations to centrally manage users, groups, and devices. It is an Identity as a Service (IDaaS) and enterprise mobility management (EMM) product. You can use Cloud Identity to manage your users, apps, and devices from a central location — the Google Admin console.

What is an Organization in Google Cloud?

The Organization resource is the root node in the Google Cloud resource hierarchy, and is the hierarchical super node of all projects. All projects and resources in Google Cloud are contained within an Organization.

How do Organizations relate to Cloud Identity?

Each Cloud Identity account is associated with exactly one Organization resource in Google Cloud. You can think of Cloud Identity as the place where you grant users access to your Google Cloud Organization.

What is an Azure Active Directory Tenant?

An Azure AD tenant is a reserved Azure Active Directory service instance that an organization receives and owns once it signs up for a Microsoft cloud service such as Azure, Microsoft Intune, or Microsoft 365. Each tenant represents an organization, and is distinct and separate from other Azure AD tenants.

Organizations can federate access to Google Cloud for their users with their current active Azure AD tenant, in order to avoid the management overhead of manually maintaining Google identities for each employee, when all employees already have an account in Azure AD. By federating user identities between Google Cloud and the existing identity management system, organizations automate the maintenance of Google identities and tie their lifecycle to existing users in Azure AD.

When organizations choose to federate Google Cloud identities for their users from an existing Azure AD tenant, they can have one Google Cloud organization for each tenant in Azure AD. However, it is possible to have multiple Google Cloud Organizations tied to a single Azure AD tenant if you want additional GCP Organizations without having to create additional Azure AD tenants, and that’s what we will discuss in this article.

We’ve seen our Google Cloud customers interested in this type of set up when they are already established with all their users in a single Google Cloud Organization (that is identity federated with Azure AD), and they want to set up a second Google Cloud Organization for experimentation, without the restrictions they’ve set in their primary Google Cloud Organization.

Let’s walk through an example of an organization wanting to set up a secondary experimentation organization in Google Cloud, in addition to their current primary production organization.

Step 1: Create a new Cloud Identity Account

In order to create a separate Google Cloud organization, you must first create a dedicated Cloud Identity account.

Step 2: Create a new Google Cloud Organization

Once you have created your Cloud Identity account and associated it with a domain, your Organization resource will be automatically created for you, once you log in to the Google Cloud console and accept the terms and conditions.

Step 3: Grant users from your primary Google Cloud Organization access to the new Organization

Once this new experimentation organization is created, instead of creating a new Active Directory instance to recreate all your users from the Cloud Identity admin page, you can grant the users from your primary organization access to the secondary organization via Cloud IAM.

From the Cloud IAM console of your secondary organization, you can grant user access and permissions in the way you wish, using users and groups from your primary organization. For example, if I have a primary organization (primary-org.com) and a secondary organization (secondary-org.com), I can grant permissions to a group from my primary organization (testgroup@primary-org.com) from the Cloud IAM page of my secondary organization.

First, navigate to the Cloud IAM page for the secondary organization, and select “+GRANT ACCESS”

In the “New principals” field, enter the user(s) and/or group(s) from your primary organization you want to grant access to, and assign the role you would like to apply to these users. (Optional: you may want to grant access for your entire primary organization into your secondary organization. To do this, enter the domain for your primary organization as the principal at this step.)

In this example, we are granting the “Project Creator” role to a group from the primary organization (testgroup@primary-org.com)

After hitting save, your changes will be reflected in the IAM page, and access will be granted.

You may find more guidance on granting permissions to Google Cloud resources in the documentation linked here, as well as a list of the predefined IAM roles here.

This entire process can be handled without disrupting the way your users currently access Google Cloud, and users with the appropriate permissions will be able to view and use the new secondary experimentation organization directly from their Google Cloud console.

Conclusion

Users from your primary Google Cloud organization now have access to a new, secondary organization that can be used for experimentation with new Google Cloud features and services, with no change to your Google Cloud sign-on process for any users. On the back end, a new Cloud Identity account associated with the new secondary organization is unused, and your users experience no change to their sign on experience.