This document describes how you can configure Cloud Identity orGoogle Workspaceto useMicrosoft Entra ID (formerly Azure AD) as IdP and source for identities.

The document compares the logical structure of Microsoft Entra ID with the structure usedby Cloud Identity and Google Workspace and describes how you canmap Microsoft Entra ID tenants, domains, users, and groups.

Implement federation

Google Cloud usesGoogle identitiesfor authentication and access management. Manually maintaining Google identitiesfor each employee can add unnecessary management overheadwhen all employees already have an account in Microsoft Entra ID. Byfederating user identities between Google Cloud and your existing identitymanagement system, you can automate the maintenance of Google identities and tietheir lifecycle to existing users in Microsoft Entra ID.

Setting up federation between Microsoft Entra ID and Cloud Identity orGoogle Workspace entails two pieces:

• Provisioning users: Relevant users and groups aresynchronized periodically from Microsoft Entra ID to Cloud Identity orGoogle Workspace. This process ensures that when you create a new userin Microsoft Entra ID or synchronize a new user from Active Directory to Microsoft Entra ID,it's also made available in Google Cloud so that it can be referencedin Google Cloud even before the associated user has logged in for thefirst time. This process also ensures that user deletions are beingpropagated.

  Provisioning works one way, which means changes in Microsoft Entra ID arereplicated to Google Cloud but not vice versa. Also, provisioningdoesn't include passwords.

• Single sign-on (SSO): Whenever a user needs to authenticate, Google Clouddelegates the authentication toMicrosoft Entra ID by using the Security Assertion Markup Language (SAML)protocol. Depending on your Microsoft Entra ID configuration, Microsoft Entra ID might do one ofthe following:

  • Perform authentication itself.
  • Use pass-through authentication or password hash synchronization.
  • Delegate authentication to an on-premises AD FS server.

Having Cloud Identity or Google Workspace delegate authenticationto Microsoft Entra ID not only avoids having to synchronize passwords toGoogle Cloud, it also ensures that any applicable policies or multi-factorauthentication (MFA) mechanisms you have configured in Microsoft Entra ID or AD FS areenforced.

Note: This document refers to theGoogle Cloud/G Suite Connector by Microsoft gallery app from the Microsoft Azure Marketplace.This app is a Microsoft product and is not maintained or supported by Google.

Logical structure of Microsoft Entra ID

When you use Azure, you use one or more Microsoft Entra ID tenants (also referred toasdirectories). Microsoft Entra ID tenants are a top-level structure. They areconsidered administrative boundaries, and serve as containers for users, groups,as well as resources and resource groups.

Each Microsoft Entra ID tenant has at least one DNS domain associated with it. This DNSdomain is reflected in usernames (also referred to asUser Principal Names orUPNs), which take the form ofname@domain,wheredomain is one of the DNS domains associated withthe corresponding tenant.

An enterprise might maintain multiple Microsoft Entra ID tenants. Common reasons forhaving multiple tenants include distinguishing between different parts of theorganization, separating production resources from development and testingresources, and using separate tenants to integrate multiple forests from anon-premises Active Directory.

Logical structure of Google Cloud

In Google Cloud,organizations serve as containers for all resources, and they can be furthersegmented by using folders and projects.However, except forservice accounts,organizations aren't used to manage users and groups, makingorganizations different from Microsoft Entra ID tenants.

For managing users and groups, Google Cloud relies on Cloud Identityor Google Workspace. ACloud Identity or Google Workspace accountserves as a private directory for users and groups. As an administratorof the account, you can control the lifecycle and the configuration of usersand groups and define how authentication can be performed.

When you create a Cloud Identity or Google Workspace account,a Google Cloud organization is created automatically for you. The Cloud Identity orGoogle Workspace account and the Google Cloud organization that'sassociated with it share the same name and are tied to each other. However, aGoogle Cloud organization is allowed to reference users and groups fromother Cloud Identity or Google Workspace accounts.

Integrate Microsoft Entra ID and Google Cloud

Despite certain similarities between the logical structure of Microsoft Entra ID andGoogle Cloud, no single mapping between the two structures works equallywell in all scenarios. Instead, the right approach to integrating the twosystems and mapping the structure depends on multiple factors:

• How to map Microsoft Entra ID tenants to Cloud Identity orGoogle Workspace accounts
• How to map DNS domains
• How to map users
• How to map groups

The following sections look at each of these factors.

Google Cloud interacts only with Microsoft Entra ID, not with your on-premisesActive Directory. So the way you've mapped forests and domains of youron-premises Active Directory to Microsoft Entra ID is of minor concern.

Map Microsoft Entra ID tenants

The following sections describe how to map Microsoft Entra ID tenants for thesescenarios:

• Single tenant
• Multiple tenants
• External users

Single tenant

If you use only a single Microsoft Entra ID tenant, you can map the tenant to a singleCloud Identity or Google Workspace account and set up federationbetween the two. This Cloud Identity or Google Workspace accountthen provides the basis for a single Google Cloud organization that you canuse to manage all Google Cloud resources.

Multiple tenants

In larger organizations, it's not uncommon to have more than one Microsoft Entra IDtenant. Multiple tenants might be used to differentiate between testing andproduction environments, or to differentiate between different parts of anorganization.

It's possible to map multiple Microsoft Entra ID tenants to a singleCloud Identity or Google Workspace account, and to set up userprovisioning and single sign-on accordingly. However, such an N:1 mapping canweaken the isolation between Microsoft Entra ID tenants: If you grantmultiple Microsoft Entra ID tenants permission to create and modify users ina single Cloud Identity or Google Workspace account, then thesetenants can interfere and tamper with each other's changes.

Typically, a better approach to integrate with multiple Microsoft Entra ID tenantsis to create a separate Cloud Identity or Google Workspace accountfor each tenant and set up federation between each pair.

In Google Cloud, a separate organization is created for eachCloud Identity or Google Workspace account. BecauseGoogle Cloud allows resources to be organized usingprojects andfolders within a single organization, having more than one organization is oftenimpractical. However, you can select one of the organizations andassociate it with the other Cloud Identity or Google Workspace accounts,effectively creating an organization that is federated with multiple ActiveDirectory forests. The other organizations remain unused.

External users

WithMicrosoft Entra ID B2B,you can invite external users as guests to your Microsoft Entra ID tenant. A new useris created for each guest and Microsoft Entra ID automatically assigns a UPN to theseguest users. The UPN that Microsoft Entra ID generates uses a prefix derived from theinvitee's email address, combined with the tenant's initial domain:prefix#EXT#@tenant.onmicrosoft.com.

Provisioning guest users from Microsoft Entra ID to Cloud Identity orGoogle Workspace is subject to certain limitations:

• You cannot map the UPN of guest users to email addresses inCloud Identity or Google Workspace becauseonmicrosoft.comis a domain that cannot be added and verified in Cloud Identity orGoogle Workspace. You therefore have tomap users by using an attribute other than theUPN.
• If a guest user is suspended in its home tenant, then the correspondinguser in Cloud Identity or Google Workspace might remain activeand access to Google Cloud resources might not be properly revoked.

A better way to deal with guest users that originate from a different Microsoft Entra IDtenant is to create multiple Cloud Identity or Google Workspaceaccounts as outlined in the previous section, each federated with a differentMicrosoft Entra ID tenant. For more information, seeMicrosoft Entra ID B2B user provisioning and single sign-on

To grant an external user access to certain Google Cloud resources, it'snot a prerequisite for the user to have a user account in Cloud Identityor Google Workspace. Unlessrestricted by policy,you can alsoadd the external user directly as a member to the respective projects, folders, or organization, provided thatthe user has a Google identity.

Map DNS domains

DNS plays a crucial role, both for Microsoft Entra ID and for Cloud Identity andGoogle Workspace. The second factor to look at when planning to federateMicrosoft Entra ID and Google Cloud is how you can share or map DNS domains betweenMicrosoft Entra ID and Google Cloud.

Usage of DNS domains in Google Cloud

Google Sign-In,which Google Cloud relies on for authentication purposes, uses emailaddresses to identify users. Using email addresses not only guarantees that theyare globally unique, but also enables Google Cloud to send notificationmessages to the addresses.

Google Sign-In determines the directory or identity provider to usefor authenticating a user based on the domain part of the email addresses, whichfollows the@. For an email address that uses thegmail.com domain, forexample, Google Sign-In uses the directory of Gmail users forauthentication.

When you sign up for aGoogle Workspace orCloud Identity account, you're creating a private directory that Sign-Incan use for authentication. In the same way that the Gmail directory isassociated with thegmail.com domain, Google Workspace andCloud Identity accounts need to be associated with a custom domain.Three different kinds of domains are used:

• Primary domain: This domain identifies the Cloud Identity orGoogle Workspaceaccount and is used as the name for the organization in Google Cloud.When signing up for Cloud Identity or Google Workspace, youmust specify this domain name.
• Secondary domain: Along with the primary domain, you can associateother, secondary domains with a Cloud Identity orGoogle Workspace account. Eachuser in the directory is associated with either the primary domain orone of the secondary domains. Two users,johndoe@example.com andjohndoe@secondary.example.com, are considered separate users ifexample.com is the primary domain andsecondary.example.com is asecondary domain.
• Alias domain: An alias domain is analternate name for another domain.That is,johndoe@example.com andjohndoe@alias.example.com refer to the same user ifalias.example.com is set up as an alias domain forexample.com.

All domains must satisfy the following requirements:

• They must be valid, global DNS domain names. During setup, you mightneed administrative access to the respective DNS zones in order to verifydomain ownership.
• A domain, such asexample.com, can refer only to a single directory.However, you can use different subdomains, such assubdomain.example.com,to refer to different directories.
• Primary and secondary domains should have a valid MX record so thatmessages sent to email addresses that are formed by using this domain namecan be delivered properly.

Usage of DNS domains in Microsoft Entra ID

The way Cloud Identity and Google Workspace uses DNS is similar tohow Microsoft Entra ID relies on DNS to distinguish Microsoft Entra ID tenants and associateusernames with tenants. But be aware of two notable differences:

1. Initial domains: When you create a Microsoft Entra ID tenant, the tenant isassociated with aninitial domain, which is a subdomain ofonmicrosoft.com. This domain is different from anycustom domain name that you might register in that you don't own the domain and that you don'thave administrative access to the respective DNS zone.

   Cloud Identity doesn't have an equivalent of an initial domain andinstead requires that you own all domains that you associate with aCloud Identity account. This requirement means that you cannotregister anonmicrosoft.com subdomain as a Cloud Identity domain.

2. Domains used in user identifiers: Microsoft Entra ID distinguishes betweenemail addresses MOERAs (Microsoft Online Email Routing Addresses) and UPNs.Both follow an RFC 822 format(user@domain), but they serve differentpurposes: Where UPNs are used to identify users and are used in the sign-onform, only MOERAs are used for delivering email.

   The domain suffix used by UPNs is required to match one of the registereddomains of your Microsoft Entra ID tenant—the same requirement does not apply toemail addresses.

   Cloud Identity and Google Workspace doesn't rely on theconcept of a UPN and instead use a user's email address as an identifier.Consequently, the domain used by the email address must match one of theregistered domains of the Cloud Identity or Google Workspaceaccount.

A Microsoft Entra ID tenant and a Cloud Identity or Google Workspaceaccount can use the same DNS domains. If using the same domains isn't possible,you can configure user provisioning and single sign-on to substitute domainnames.

Considering the two differences outlinedabove, you should base your domain mapping on how you plan to map users betweenMicrosoft Entra ID and Cloud Identity or Google Workspace.

Map users

The third factor to look at when planning to federate Microsoft Entra ID andGoogle Cloud is how to map users between Microsoft Entra ID andCloud Identity or Google Workspace.

Successfully mapping Microsoft Entra ID users to users in Cloud Identity orGoogle Workspace requires two pieces of information for each user:

1. A stable, unique ID that you can use during synchronization to trackwhich Microsoft Entra ID user corresponds to which user in Cloud Identity orGoogle Workspace.
2. An email address for which the domain part corresponds to aCloud Identity primary, secondary, or alias domain. Because thisemail address will be used throughout Google Cloud, the address shouldbe human-readable.

Internally, Microsoft Entra ID identifies users by ObjectId, which is a randomlygenerated, globally unique ID. While this ID is stable and therefore meets thefirst requirement, it's meaningless to humans and doesn't follow the format ofan email address. To map users, the only practical options are to map by UPN orby email address.

If the user enters an email address that belongs to a Cloud Identity orGoogle Workspace account that is configured to use single sign-on withMicrosoft Entra ID, the user is then redirected to the Microsoft Entra ID sign-on screen.

Microsoft Entra ID uses UPNs, not email addresses, to identify users, so the sign-onscreen prompts the user to provide a UPN.

If the Microsoft Entra ID tenant is configured to use AD FS for sign-on, another redirecttakes the user to the AD FS sign-on screen. AD FS can identify users either bytheir Active Directory UPN or by their Pre–Windows 2000 logon name(domain\user).

If the email address used for Cloud Identity or Google Workspace,the UPN used by Microsoft Entra ID, and the UPN used by Active Directory all differ, thesequence of sign-on screens can easily become confusing for end users. Incontrast, if all three identifiers are the same as in the example screenshots(johndoe@example.com), then users aren't exposed to the technical differencesbetween UPNs and email addresses, minimizing potential confusion among yourusers.

Map by UPN

From a user-experience perspective, mapping Microsoft Entra ID UPNs toCloud Identity or Google Workspace email addresses might beconsidered the best option. Another benefit of relying on UPNs is that Microsoft Entra IDguarantees uniqueness so that you avoid the risk of naming clashes.

However, in order to map Microsoft Entra ID UPNs to Cloud Identity emailaddresses, you must meet these requirements:

• The Microsoft Entra ID UPNs should be valid email addresses so that anynotification emails sent by Google Cloud are correctly delivered tothe user's mailbox. If this isn't the case already, you might be able toconfigure alias email addresses to ensure that the user receives such email.
• The UPNs of all relevant users in Microsoft Entra ID must use a custom domain assuffix (user@custom-domain). UPNs thatuse the Microsoft Entra ID initial domain(user@tenant.onmicrosoft.com) cannot bemapped to email addresses in Cloud Identity, because the initialdomain isn't owned by you, but by Microsoft.
• All custom domains used by Microsoft Entra ID for UPNs must be registered inCloud Identity as well. This requirement means that you must haveaccess to the respective DNS zones in order to perform domain validation.To avoid overriding existingTXT DNS records you might have created forverifying domain ownership in Microsoft Entra ID, you can use aCNAME record toverify domain ownership in Cloud Identity.

Map users by email address

If mapping Microsoft Entra ID UPNs to Cloud Identity or Google Workspaceemail addresses isn't an option, you can map users by email address.

When you specify an email address in Active Directory, it's stored in themail attribute of the respectiveuser object and Microsoft Entra ID Connect willsynchronize the value to theMail attribute in Microsoft Entra ID. Microsoft Entra ID also makesthe attribute available for user provisioning so that you can map it to theemail address in Cloud Identity or cloudid_name_short.

Crucially, the Microsoft Entra IDMail attribute currently isn't shown in the Azureportal and can only be viewed and edited through APIs or PowerShell. Althoughthe user interface lets you specify an email address and an alternate emailaddress, neither of these values is stored in theMail attribute, so theycan't be used for provisioning to Cloud Identity or cloudid_name_short.As a result, mapping users of an email address is practical only when you domost of your user creation and editing in Active Directory, not in Microsoft Entra ID.

Mapping users by email address requires that you meet the following additionalrequirements:

• Email assignments must be complete. All users that are subjectto synchronization must be assigned an email address. Especially when usersare synchronized from an on-premises Active Directory, this might not bethe case becausemail is an optional user attribute in Active Directory.Users that lack an email address in the Microsoft Entra IDMail attribute aresilently ignored during synchronization.
• Email addresses must be unique across the Microsoft Entra ID tenant. AlthoughActive Directory doesn't check uniqueness on user creation, Microsoft Entra IDConnect detects collisions by default, which might cause thesynchronization of affected users to fail.
• The domains used by email addresses don't need to be registered in Microsoft Entra ID,but they must be registered in Cloud Identity orGoogle Workspace. Thisrequirement means that you must have access to the respective DNS zones inorder to perform domain validation, and it rules out the use of emailaddresses with domains that you don't own (likegmail.com).

Map the user lifecycle

After you've defined a mapping between Microsoft Entra ID users and users inCloud Identity or Google Workspace, you must decide whichset of users you want to provision. Refer to ourbest practices on mapping identity sets for guidance on making this decision.

If you don't want to provision all users of your Microsoft Entra ID tenant, you can enableprovisioning for a subset of users by usinguser assignments orscoping filters.

The following table summarizes the default behavior of Microsoft Entra ID provisioning,and shows how enabling or disabling provisioning for a user controls whichactions Microsoft Entra ID will perform in Cloud Identity orGoogle Workspace.

Provisioning enabled for Microsoft Entra ID user	User state in Cloud Identity or Google Workspace	Action performed in Microsoft Entra ID	Action performed in Cloud Identity or Google Workspace
No	(does not exist)	Enable provisioning	Create new user (*)
No	Exists (active)	Enable provisioning	Update existing user
No	Exists (suspended)	Enable provisioning	Update existing user, keep suspended
Yes	Exists	Modify user	Update existing user
Yes	Exists	Rename UPN/email address	Change primary email address, keep previous address as alias
Yes	Exists	Disable provisioning	Suspend user
Yes	Exists	Soft-delete user	Suspend user

(*) If a consumer account with the same email address exists, the consumer accountisevicted.

Map groups

The fourth factor to look at when you are planning to federate Microsoft Entra IDand Google Cloud is whether to synchronize groups between Microsoft Entra IDand Google Cloud and how to map them.

In Google Cloud,groups are commonly used as a way to manage access efficiently across projects. Ratherthan assigning individual users to IAM roles in eachproject, you define a set of groups that model common roles in yourorganization. You then assign those groups to a set of IAM roles.By modifying the membership of the groups, you can control users' access to anentire set of resources.

Mapping groups between Microsoft Entra ID and Google Cloud is optional. Once you'veset up user provisioning, you can create and manage groups directly inCloud Identity or Google Workspace, which means that ActiveDirectory or Microsoft Entra ID remains the central system for identity management but notfor Google Cloud access management.

To maintain Active Directory or Microsoft Entra ID as the central system for identitymanagement and access management, we recommend that you synchronize groups fromMicrosoft Entra ID instead of managing them in Cloud Identity orGoogle Workspace. With this approach, you can set up IAM sothat you can use group memberships in Active Directory or Microsoft Entra ID to controlwho has access to resources in Google Cloud.

Groups in Cloud Identity and Google Workspace

In Cloud Identity and Google Workspace, there is only a singletype of group. Groups in Cloud Identity and Google Workspacearen't confined to the scope of the Cloud Identity orGoogle Workspace account where they were defined. Instead, they caninclude users from different Cloud Identity or Google Workspaceaccounts, support being referenced and nested in other accounts, and be usedacross any Google Cloud organization.

As they do with users, Cloud Identity and Google Workspaceidentify groups by email address. The email address doesn't have to correspondto an actual mailbox, but it must use one of the domains registered for therespective Cloud Identity account.

When working with groups in IAM, you often need to specifygroups by email address rather than by name. So it's best for groups to have notonly a meaningful name, but a meaningful and recognizable email address.

Groups in Microsoft Entra ID

Microsoft Entra ID supportsmultiple types of groups,each catering to different use cases. Groups are scoped to a single tenant andidentified by an Object ID, which is a randomly generated, globally unique ID.Groups can be nested and can contain either users from the same tenant or usersinvited from other tenants by using B2B collaboration. Entra ID also supports dynamicgroups, whose members are determined automatically based on a query.

In the context of integrating Microsoft Entra ID with Cloud Identity orGoogle Workspace, two properties of groups are of primary interest—whethera group is mail-enabled and whether it is security-enabled:

• Asecurity-enabled group can be used to manage access to resourcesin Microsoft Entra ID. Any security-enabled group is therefore potentially relevantin the context of Google Cloud.
• Amail-enabled group has an email address, which is relevant becauseCloud Identity and Google Workspace require groups to beidentified by an email address.

In Microsoft Entra ID, you can create groups of type Security or Office 365 (sometimescalled unified groups). When synchronizing groups from an on-premises ActiveDirectory or when using the Office 365 type, you can also create groups of typeDistribution list.

The following table summarizes the differences between these different kinds ofgroups regarding being mail-enabled or security-enabled, and how they map toActive Directory group types, assuming a default Microsoft Entra ID Connectconfiguration:

Source	Active Directory group type	Microsoft Entra ID group type	Mail-enabled	Security-enabled
Microsoft Entra ID	-	Office 365 group	Always	Optional
Microsoft Entra ID	-	Security group	Optional	Always
on-premises	Security group (with email)	Security group	Yes	Yes
on-premises	Security group (without email)	Security group	No	Yes
on-premises	Distribution list (with email)	Distribution list	Yes	No
on-premises	Distribution list (without email)	(ignored by Microsoft Entra ID Connect)

Unlike for users, Microsoft Entra ID requires that email addresses assigned to groups usea domain that has been registered as a custom domain in Microsoft Entra ID. Thisrequirement results in the following default behavior:

• If a group in Active Directory uses an email address that uses a domainthat has previously been registered in Microsoft Entra ID, then the email address isproperly maintained during synchronization to Microsoft Entra ID.
• If a group in Active Directory uses an email address that has not beenregistered in Microsoft Entra ID, then Microsoft Entra ID auto-generates a new email addressduring synchronization. This email address uses the tenant's defaultdomain. If your tenant uses the initial domain as the default domain, theresulting email address will be in the form of[name]@[tenant].onmicrosoft.com.
• If you create an Office 365 group in Microsoft Entra ID, then Microsoft Entra ID alsoauto-generates an email address that uses the tenant's default domain.

Map group identities

Successfully mapping Microsoft Entra ID groups to Cloud Identity orGoogle Workspace groups requires a common identifier, and this identifiermust be an email address. On the Microsoft Entra ID side, this requirement leaves you withtwo options:

• You can use the email address of a group in Microsoft Entra ID and map it to aCloud Identity or Google Workspace email address.
• You can derive an email address from the name of the group in Microsoft Entra IDand map the resulting address to an email address in Cloud Identityor Google Workspace.

Map by email address

Mapping groups by email address is the most obvious choice, yet it requires youto meet several requirements:

• All groups that are subject to synchronization must have an emailaddress. In practice, this means that you can only synchronize mail-enabledgroups. Groups that lack an email address are ignored during provisioning.
• The email addresses must be unique across the tenant. Because Microsoft Entra IDdoesn't enforce uniqueness, you might have to implement custom checks orpolicies.
• The domains used by email addresses must be registered in both Microsoft Entra IDand Cloud Identity or Google Workspace. Any groups with emailaddresses that use domains not registered inCloud Identity or Google Workspace, including thetenant.onmicrosoft.com domain, will fail tosynchronize.

If all relevant groups meet these criteria, identify the domains that are usedby these email addresses and ensure that the list of DNS domains registered inCloud Identity or Google Workspace covers these domains.

Map by name

Meeting the criteria required to map groups by email address can be challenging,particularly if many of the security groups you intend to provision toCloud Identity or Google Workspace aren't mail-enabled. In thiscase, it might be better to automatically derive an email address from thegroup's display name.

Deriving an email address presents two challenges:

1. An email address derived from a group's name might clash with an emailaddress of a user.
2. Microsoft Entra ID doesn't enforce uniqueness for group names. If multiple groupsin your Microsoft Entra ID tenant share the same name, email addresses derived fromthis name will clash, causing only one group to synchronize successfully.

You can overcome the first challenge by using a domain for the generated emailaddress that is different than any of the domains used by users. For example, ifall your users use email addresses withexample.com as the domain, then youcould usegroups.example.com for all groups. Registering subdomains inCloud Identity or Google Workspace doesn't require domainverification, so the DNS zonegroups.example.com doesn't even have to exist.

You can overcome the second challenge, duplicate group names, only technicallyby deriving the group email address from the Object ID. Because the resultinggroup names are rather cryptic and difficult to work with, it's better toidentify and rename duplicate group names in Microsoft Entra ID before setting upprovisioning to Cloud Identity or Google Workspace.

Map the group lifecycle

After you've defined a mapping between Microsoft Entra ID groups and groups inCloud Identity or Google Workspace, you must decide whichset of groups you want to provision. Similar to users, you can enableprovisioning for a subset of groups by usinggroup assignments orscoping filters.

The following table summarizes the default behavior of Microsoft Entra ID provisioning,and shows how enabling or disabling provisioning for a group controls whichactions Microsoft Entra ID will perform in Cloud Identity orGoogle Workspace.

Provisioning enabled for Microsoft Entra ID group	Group state in Cloud Identity or Google Workspace	Action performed in Microsoft Entra ID	Action performed in Cloud Identity or Google Workspace
No	(does not exist)	Enable provisioning	Create new group
No	Exists	Enable provisioning	Add member, retain all existing members
Yes	Exists	Rename group	Rename group
Yes	Exists	Modify description	Update description
Yes	Exists	Add member	Add member, retain all existing members
Yes	Exists	Remove member	Remove member
Yes	Exists	Disable provisioning	Group left as-is (incl. members)
Yes	Exists	Delete group	Group left as-is (incl. members)

Note: When you delete a group in Microsoft Entra ID, Microsoft Entra ID doesn't propagate thedeletion to Cloud Identity or Google Workspace. Similarly, if youenable provisioning for a group and later disable provisioning, the group inCloud Identity or Google Workspace remains active. This behaviorcan result in users inadvertently retaining access rights in Google Cloud.To prevent this from happening, remove all members from a group first, wait forchanges to be propagated, and only then delete the group in Microsoft Entra ID or disableprovisioning for the group in Microsoft Entra ID.

What's next

• Read aboutbest practices for planning accounts and organizations andbest practices for federating Google Cloud with an external identity provider.
• Learn how toconfigure provisioning and single sign-on between Microsoft Entra ID and Cloud Identity.
• Learn aboutbest practices for managing super administrator accounts.