This document describes how you can configure Cloud Identity or Google Workspaceto useActive Directory as IdP and authoritative source.

The document compares the logical structure of Active Directory with the structureused by Cloud Identity and Google Workspace and describes how you canmap Active Directory forests, domains, users, and groups. The document also provides aflowchart that helps you determine the best mapping approach for your scenario.

This document assumes that you're familiar with Active Directory.

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 Active Directory. 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 Active Directory.

Setting up federation between Active Directory and Cloud Identity orGoogle Workspace entails two pieces:

• Provisioning users: Relevant users and groups are synchronizedperiodically from Active Directory to Cloud Identity orGoogle Workspace. This process ensures that when you create a new userin Active Directory, it can be referenced in Google Cloud even beforethe associated user has logged in for the first time. This process alsoensures that user deletions are being propagated.

  Provisioning works one way, which means changes in Active Directory arereplicated to Google Cloud but not the other way around. Also,provisioning does not include passwords. In a federated setup, ActiveDirectory remains the only system that manages these credentials.

• Single sign-on: Whenever a user needs to authenticate, Google Clouddelegates the authentication toActive Directory by using the Security Assertion Markup Language (SAML)protocol. This delegation ensures that only Active Directory manages usercredentials and that any applicable policies or multi-factor authentication(MFA) mechanisms are being enforced. For a sign-on to succeed, however, therespective user must have been provisioned before.

To implement federation, you can use the following tools:

• Google Cloud Directory Sync (GCDS) is a free Google-provided tool that implements the synchronization process.GCDS communicates with Google Cloud overSecure Sockets Layer (SSL) and usually runs in the existing computingenvironment.
• Active Directory Federation Services (AD FS) is provided by Microsoftas part of Windows Server. With AD FS, you can use Active Directory forfederated authentication. AD FS usually runs within the existingcomputing environment.

Because APIs for Google Cloudare publicly available and SAML is an open standard, many tools are available to implement federation.This document focuses on using GCDS and AD FS.

Logical structure of Active Directory

In an Active Directory infrastructure, the top-level component is theforest.The forest serves as a container for one or more domains and derives its namefrom the forest root domain. Domains in an Active Directory forest trust eachother, allowing users who are authenticated in one domain to access resourcesthat are in another domain. Unless forests are connected by using cross-foresttrusts, separate forests don't trust each other by default, and users who areauthenticated in one forest cannot access resources that are in a differentforest.

Active Directory domains are containers for managing resources and areconsidered administrative boundaries. Having multiple domains in a forest is oneway to simplify administration or enforce additional structure, but domains in aforest don't represent security boundaries.

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.Organizations, folders, and projects therefore serve a purpose similar to ActiveDirectory domains.

Active Directory treats users as resources, so user managementand authentication are tied to domains. In contrast, Google Cloud doesn'tmanage users in an organization, except forservice accounts.Instead, Google Cloud relies on Cloud Identity orGoogle Workspace to manage users.

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 or Google Workspace accountand the Google Cloud organization that's associated with it share the same name andare tied to each other. However, a Google Cloud organization is allowed toreference users and groups from other Cloud Identity or Google Workspace accounts.

Integrate Active Directory and Google Cloud

Despite certain similarities between the logical structure of Active Directoryand Google Cloud, no single mapping between the two structures worksequally well in all scenarios. Instead, the right approach to integrating thetwo systems and mapping the structure depends on multiple factors:

• How to map domains and forests to Cloud Identity or Google Workspace accounts
• How to map DNS domains
• How to map users
• How to map groups

The following sections look at each of these factors.

Map forests

Especially in larger organizations, you often use more than one ActiveDirectory domain to manage identities and access across the enterprise. When youare planning to federate Active Directory and Google Cloud, the firstfactor to look at is the topology of your Active Directory infrastructure.

Single forest, single domain

When a forest includes just one domain, you can map the entire Active Directoryforest to a single Cloud Identity or Google Workspace account.This account then provides the basis for a single Google Cloud organizationthat you can use to manage your Google Cloud resources.

In a single-domain environment, domain controllers and global catalog serversboth provide access to all objects that are managed in Active Directory. In mostcases, you can run a single instance of GCDS tosynchronize user accounts and groups to Google Cloud, and to maintain asingle AD FS instance or fleet to handle single sign-on.

Single forest, multiple domains

When a forest contains multiple Active Directory domains, you can organize themin one or more domain trees. In both cases, you can map the entire forest to asingle Cloud Identity or Google Workspace account. This accountthen provides the basis for a single Google Cloud organization that you canuse to manage your Google Cloud resources.

In a multi-domain environment, there is a difference between what informationcan be retrieved from a domain controller and what can be queried from a globalcatalog server. While domain controllers serve data only from their localdomain, global catalog servers provide access to information from all domains inthe forest. Crucially, the data that is served by global catalog servers ispartial and lacks certain LDAP attributes. This limitation can affect how youconfigure GCDS tosynchronize groups.

Depending on how you plan to map groups, federating a multi-domain forest withGoogle Cloud requires one or more GCDS instances butonly a single AD FS instance or fleet to handle single sign-on.

Multiple forests with cross-forest trust

In larger organizations, it's not uncommon to have more than one ActiveDirectory forest, often as a result of a merger or acquisition. You cancombine these forests by using a two-way, cross-forest trust so that users canshare and access resources across the boundaries of a single forest.

If all forests have a bidirectional trust relationship with another forest, youcan map the entire environment to a single Cloud Identity orGoogle Workspace account. This account provides the basis for a singleGoogle Cloud organization that you can use to manage your Google Cloudresources.

Although global catalog servers provide access to data from multiple domains,their scope is limited to a single forest. So in a multi-forest environment,you must query multiple domain controllers or global catalog servers to obtain,for example, a complete list of users. As a result of this limitation,federating a multi-forest environment with Google Cloud requires at leastone GCDS instance per forest. Cross-forest trusts enableuser authentication to work across forest boundaries, so a single AD FSinstance or fleet is sufficient to handle single sign-on.

If your environment spans multiple forests without cross-forest trust, but allActive Directory domains that are relevant for federation with Google Cloudare connected through external trusts, then the same considerations apply.

Multiple forests without cross-forest trust

In the environment illustrated here, it's not possible to authenticate oraccess resources across the forest boundaries. It's also not possible for asingle AD FS instance or fleet to handle single sign-on requests for usersfrom all forests.

Therefore, it's not possible to map multiple forests that lack cross-foresttrusts to a single Cloud Identity or Google Workspace account.Instead, each forest must be mapped to a separate Cloud Identity orGoogle Workspace account, which involves running at least oneGCDS instance and one AD FS server or fleet per forest.

In Google Cloud, a separate organization is created for eachCloud Identity or Google Workspace account. In most cases, youdon't need to maintain multiple, separate organizations. You can select one ofthe 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.

Map DNS domains

DNS plays a crucial role both in Active Directory and for Cloud Identityand Google Workspace. The second factor to look at when you're planning tofederate Active Directory and Google Cloud is how to share or map DNSdomains between Active Directory and Google Cloud.

Usage of DNS domains in Active Directory

In an Active Directory forest, DNS domains are used in multiple places:

• Active Directory DNS domains: Each Active Directory domain correspondsto a DNS domain. This domain might be global, likecorp.example.com, orcan be a local domain name likecorp.local orcorp.internal.
• Mail exchange (MX) domains: Email addresses use a DNS domain. Insome cases, this domain is the same as the Active Directory DNS domain, butin many cases, a different, often shorter, domain such asexample.com isused. Ideally, users in Active Directory have the email addressthat is associated with the optionalmail attribute.
• UPN suffix domains: These domains are used forUser Principal Names(UPN). By default, the Active Directory DNS domain of the user's domainis used to build a UPN. For a userjohn in the domaincorp.example.com, the default UPN therefore readsjohn@corp.example.com.However, you can configure a forest to use additional DNS domains as UPNsuffixes that correspond to neither Active Directory DNS domains nor MXdomains. UPNs are optional and are stored in theuserPrincipalName fieldof the user.
• Endpoint domains: Public-facing servers such as AD FS servers areusually assigned a DNS name, such aslogin.external.example.com. Thedomain that is used for these purposes can overlap with the MX, UPN suffix,or Active Directory DNS domain, or it can be an entirely different domain.

Usage of DNS domains in Google Cloud

Google Sign-In,which Google Cloud relies on for authentication, uses email addresses toidentify users. Using email addresses not only guarantees that they are globallyunique, but also enables Google Cloud to send notification messages to theaddresses.

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 Workspace account and is used as the name for the organizationin Google Cloud. When signing up for Cloud Identity orGoogle Workspace, you must 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.

In order to enable synchronizing between the directories, some mapping isrequired between the Active Directory domains and the domains thatCloud Identity or Google Workspace uses. Determining the rightmapping depends on how you use Active Directory and requires a closer look athow users are identified in an Active Directory forest and how they can bemapped to Cloud Identity or Google Workspace.

Map users

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

Identify users in Active Directory

Internally, Active Directory uses two identifiers to uniquely identify users:

• objectGUID: This globally unique ID is generated when a user iscreated, and never changes.
• objectSID: TheSID,or security identifier, is used for all access checks. While this ID isunique and stable within a domain, it's possible that when moved to adifferent domain in the forest, a user might be assigned a new SID.

Neither of these IDs is meaningful to users, so Active Directory offers twohuman-friendly ways to identify users:

• UPN (userPrincipalName): The preferred way to identify a useris by UPN. UPNs follow the RFC 822 format of email addresses and arecreated by combining the username with a UPN suffix domain, as injohndoe@corp.example.com. Despite being the preferred way to identifyusers, UPNs are optional, so some users in your ActiveDirectory forest might lack a UPN.

  Although it's considered a best practice that UPNs be valid emailaddresses, Active Directory does not enforce this practice.

• Pre–Windows 2000 logon name (sAMAccountName): This name combines theNetBIOS domain name and username by using the formatdomain<var>user, as incorp\johndoe.Although these names are considered legacy, they are still commonly used andare the only mandatory identifier of a user.

Notably, Active Directory does not use the user's email address (mail) toidentify users. Consequently, this field is neither mandatory nor required to beunique in a forest.

All of these identifiers can be changed at any time.

Map user identities

Mapping Active Directory users to Cloud Identity orGoogle Workspace users requires two pieces of information for each user:

• A stable, unique ID that you can use during synchronization to trackwhich Active Directory user corresponds to which user inCloud Identity or Google Workspace. On the AD side, theobjectGUID is perfectly suited for this purpose.
• An email address for which the domain part corresponds to aprimary, secondary, or alias domain of your Cloud Identity orGoogle Workspace account. Because thisemail address will be used throughout Google Cloud, make sure theaddress is meaningful. Deriving an address from theobjectGUID isimpractical, as are other automatically generated email addresses.

For an Active Directory user, two fields are candidates for providing aCloud Identity or Google Workspace email address:userPrincipalName andmail.

Map by user principal name

Using theuserPrincipalName field requires that two criteria be met for allusers that are subject to synchronization:

• User principal names (UPNs) must be valid email addresses. All domains thatare used as UPNsuffix domains also must be MX domains and must be set up so that anemail that is sent to a user's UPN is delivered to their email inbox.

• UPN assignments must be complete. All users that are subject tosynchronization must have a UPN assigned. The following PowerShell commandcan help you find users that lack a UPN:

  Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

If these two criteria are met, you can safely map UPNs to Cloud Identityor Google Workspace email addresses. You can use one of the UPN suffixdomains as the primary domain in Cloud Identity orGoogle Workspace and add any other UPN suffix domains as secondarydomains.

If one of the criteria is not met, you can still map UPNs toCloud Identity or Google Workspace email addresses, but thefollowing caveats apply:

• If UPNs are not valid email addresses, users might not receive notificationemails that are sent by Google Cloud, which might cause users to missimportant information.
• Users without UPNs are ignored during synchronization.
• You can configure the synchronization to replace the UPN suffix domainwith a different domain. When you're using multiple UPN suffix domains ina forest, this approach can create duplicates, however, because all UPNsuffix domains will be replaced by a single domain. In case of duplicates,only a single user can be synchronized.

A major advantage of using UPNs to map users is that UPNs are guaranteed to beunique across a forest, and they use a curated set of domains, which helps avoidpotential synchronization problems.

Map by email address

Using themail field requires meeting the following criteria for all usersthat are subject to synchronization:

• Email assignments must be complete. All users that are subjectto synchronization must have themail field populated. The followingPowerShell command can help you find users for which this field is notpopulated:

  Get-ADUser -LDAPFilter "(!mail=*)"

• Email addresses must use a curated set of domains, all of which areowned by you. If some of your users use email addresses that refer topartner companies or consumer email providers, those email addresses cannotbe used.

• All email addresses must be unique across the forest. Because ActiveDirectory does not enforce uniqueness, you might have to implement customchecks or policies.

If all relevant users meet these criteria, you can identify all domainsthat are used by these email addresses and use them as primary and secondarydomains in Cloud Identity or Google Workspace.

If one of the criteria is not met, you can still map email addresses toCloud Identity or Google Workspace email addresses, with thefollowing caveats:

• During synchronization, users without email addresses will be ignored, aswill users with email addresses that use domains that are not associatedwith the Cloud Identity or Google Workspace account.
• When two users share the same email address, only one user will besynchronized.
• You can configure the synchronization to replace the domain of emailaddresses with a different domain. This process can create duplicates,in which case only one user will be synchronized.

Map groups

The fourth factor to look at when you're planning to federate Active Directoryand Google Cloud is whether to synchronize groups between Active Directoryand 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, and 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.

Active Directory distinguishes between two kinds of groups: distribution groupsand security groups. Distribution groups are used to manage email lists.Synchronizing distribution groups is relevant when you're migrating fromMicrosoft Exchange to Google Workspace, so GCDScan handle both regular and dynamic distribution groups. Distribution groupsaren't a concern in identity and access management for Google Cloud,however, so this discussion focuses exclusively on security groups.

Mapping groups between Active Directory 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 remains the central system for identity management but not for accessmanagement. To maintain Active Directory as the central system for identitymanagement and access management, we recommend that you synchronize securitygroups from Active Directory instead of managing them in Cloud Identityor Google Workspace. With this approach, you can set up IAMso that you can use group memberships in Active Directory to control who hasaccess to certain resources in Google Cloud.

Security groups in Active Directory

Security groups play a foundational role in Windows security and ActiveDirectory access management. This role is facilitated by three different typesof Active Directory groups:domain local groups,global groups, anduniversal groups.

Domain local groups

These groups are relevant only within the scope of a singledomain and cannot be referenced in other domains. Because their list ofmembers does not need to be replicated across the forest, domain localgroups are the most flexible with respect to the types of members that theycan include.

Global groups

These groups are surfaced to and can be referenced in other domains. Theirmember list is not replicated, however. This limitation restricts the typesof members that these groups can include. These groups can only include usersand other global groups from the same domain.

Universal groups

These groups, along with their member lists, are replicated across theforest. They can therefore be referenced in other domains and can includenot only users and other universal groups but also global groups from alldomains.

If your Active Directory forest contains only a single domain, you cansynchronize all three types of security groups by usingGCDS. If your Active Directory forest uses more than onedomain, the type of a group determines whether and how it can be synchronized toCloud Identity or Google Workspace.

Because domain local and global groups aren't fully replicated across a forest,global catalog servers contain incomplete information about them. Although thislimitation is deliberate and helps to speed up directory replication, it's anobstacle when you want to synchronize such groups to Cloud Identity orGoogle Workspace. Specifically, if you configureGCDS to use a global catalog server as a source, then thetool will be able to find groups from all domains across the forest. But onlygroups that are in the same domain as the global catalog server will contain amembership list and be suitable for replication. To synchronize domain local orglobal groups in a multi-domain forest, you must run a separateGCDS instance per domain.

Because universal groups are fully replicated across the forest, they don't havethis restriction. A single GCDS instance can synchronizeuniversal groups from multiple domains.

Before concluding that you need multiple GCDS instancesto synchronize multiple Active Directory domains to Cloud Identity orGoogle Workspace, keep in mind that not all groups might need to besynchronized. For this reason, it's worthwhile to look at how different types ofsecurity groups are typically used across your Active Directory forest.

Usage of security groups in Active Directory

The following sections describe the types of security groups that are used inActive Directory.

Resource groups

Windows uses an access model based on access control lists (ACLs). Eachresource like a file or LDAP object has an associated ACL that controls whichusers have access to it. Resources and ACLs are very fine grained, so there aremany of them. To simplify the maintenance of ACLs, it's common to createresource groups to bundle resources that are frequently used and accessedtogether. You add the resource group to all affected ACLs once, and managefurther access by altering membership of the resource group, not by altering theACLs.

The resources that are bundled this way typically reside in a single domain.Consequently, a resource group also tends to be referenced only in a singledomain, either in ACLs or by other resource groups. Because most resource groupsare local, they are usually implemented by using domain local groupsin Active Directory.

Role and organization groups

Resource groups help simplify access management, but in a large environment,you might need to add a new user to a large number of resource groups. For thisreason, resource groups are commonly complemented byrole groups ororganization groups.

Role groups aggregate the permissions that a specific role requires in theorganization. A role group that is named Engineering Documentation Viewer, forexample, might give members read-only access to all engineering documentation.Practically, you would implement this by creating a role group and making ita member of all resource groups that are used to control access to various kindsof documentation.

In a similar way, organization groups aggregate the permissions that arerequired by departments within an organization. For example, an organizationgroup that is named Engineering might grant access to all resources that membersof the Engineering department commonly require.

Technically, there is no difference between role groups and resource groups,and the two are commonly used in concert. Unlike resource groups, however, roleand organization groups can have relevance beyond the boundaries of a domain. Toallow such groups to be referenced by resource groups in other domains, role andorganization groups are usually implemented by using global groups, which areconstrained to members of a single domain, and sometimes complemented byuniversal groups, which allow members from different domains.

The following diagram shows a nesting pattern that is commonly used inmulti-domain Active Directory environments.

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 it does with users, Cloud Identity and Google Workspaceidentifies 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.

Unlike Active Directory groups, members of a Cloud Identity orGoogle Workspace group are not implicitly granted permission to list othermembers of the same group. Instead, querying group membership generallyrequires explicit authorization.

Usage of groups in Google Cloud

Google Cloud uses a role-based access model instead of an ACL-based accessmodel. Roles apply to all resources of a certain type that fall within a certainscope. For example, the Kubernetes Engine Developer role has full access toKubernetes API objects inside all clusters in a given project. Due to the natureof roles, there is little need to maintain resource groups on Google Cloud,and rarely a need to synchronize resource groups to Google Cloud.

Role groups and organization groups are just as relevant in Google Cloudas they are in Active Directory, because they make it easier to manage accessfor large numbers of users. Synchronizing role and organization groups helpsmaintain Active Directory as the primary place for managing access.

If you consistently implement resource groups as domain local groups, and roleand organization groups as global or universal groups, you can use the grouptype to ensure that only role and organization groups are synchronized.

The question of whether it's sufficient to run a singleGCDS instance per multi-domain forest or whether you needmultiple GCDS instances then becomes the question ofwhether you use global groups. If you implement all your role and organizationgroups by using universal groups, a single GCDS instanceis sufficient; otherwise, you'll need a GCDS instance perdomain.

Map group identities

Mapping Active Directory security groups to Cloud Identity orGoogle Workspace groups requires a common identifier. InCloud Identity and Google Workspace, this identifier must be anemail address for which the domain part corresponds to a the primary, secondary,or alias domain of the Cloud Identity or Google Workspace account.Because this email address will be used throughout Google Cloud, theaddress must be human-readable. The email address doesn't need to correspond toa mailbox.

In Active Directory, groups are identified either by their common name (cn)or by a pre–Windows 2000 logon name (sAMAccountName). Similar to useraccounts, groups can also have an email address (mail), but email addressesare an optional attribute for groups, and Active Directory does not verifyuniqueness.

You have two options for mapping group identities between Active Directory andCloud Identity or Google Workspace.

Map by common name

The advantage of using the common name (cn) is that it's guaranteed to beavailable and, at least within an organizational unit, unique. However, thecommon name is not an email address, so it needs a suffix@DOMAIN appended to turn into an email address.

You can configure GCDS to automatically take care ofappending a suffix to the group name. Because Active Directory ensures thatgroup names and user names don't conflict, an email address that is derived thisway is also unlikely to cause any conflicts.

If your Active Directory forest contains more than a single domain, thefollowing caveats apply:

• If two groups in different domains share a common name, thederived email address will conflict, causing one group to be ignored duringsynchronization.
• You can only synchronize groups from domains of a single forest. If yousynchronize groups from multiple forests by using separateGCDS instances, the email addresses that are derivedfrom the common name don't reflect which forest they correspond to. Thisambiguity will cause a GCDS instance to delete anygroup that has previously been created from a different forest by anotherGCDS instance.
• You cannot map groups by common name if you use domain substitution formapping users.

Map by email address

Using the email address (mail) to map group identities means you must satisfythe same criteria as when using the email address to map users:

• Email assignments must be complete. Although it's common fordistribution groups to have an email address, security groups often lackthis attribute. To use the email address for mapping identities, securitygroups that are subject to synchronization must have themail fieldpopulated. The following PowerShell command can help you find accounts forwhich this field is not populated:

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Email addresses must use a curated set of domains, all of which you own. Ifsome of your users use email addresses that refer to partner companies orconsumer email providers, you cannot use those addresses.

• All email addresses must be unique across the forest. Because ActiveDirectory does not enforce uniqueness, you might have to implement customchecks or policies.

If all relevant groups meet these criteria, you can identify all domains thatare used by these email addresses and ensure that the list of DNS domainsregistered in Cloud Identity or Google Workspace covers these domains.

If one of the criteria is not met, you can still map UPNs toCloud Identity or Google Workspace email addresses, with thefollowing caveats:

• Groups without email addresses will be ignored during synchronization,as will email addresses that use domains that aren't associated with theCloud Identity or Google Workspace account.
• When two groups share the same email address, only one of them will besynchronized.

Mapping groups by email address is not supported if your Active Directoryforest contains more than a single domain and you use domain substitution formapping users.

Map organizational units

Most Active Directory domains make extensive use of organizational units tocluster and organize resources hierarchically, control access, andenforce policies.

In Google Cloud,folders and projects serve a similar purpose, although the kinds of resources that are managed withina Google Cloud organization are very different from the resources that aremanaged in Active Directory. As a result, an appropriate Google Cloudfolder hierarchy for an enterprise tends to differ significantly from thestructure of organizational units in Active Directory. Automatically mappingorganizational units to folders and projects is therefore rarely practical andnot supported by GCDS.

Unrelated to folders, Cloud Identity and Google Workspace supportthe concept oforganizational units.Organizational units are created to cluster and organize users, similarto Active Directory. But unlike in Active Directory, they apply only to users,not to groups.

GCDS offers the option of synchronizing Active Directoryorganizational units to Cloud Identity or Google Workspace. In asetup where Cloud Identity is merely used to extend Active Directoryidentity management to Google Cloud, mapping organizational units isusually not necessary.

Choose the right mapping

As noted at the beginning of this document, there is no single best way to mapthe structures of Active Directory and Google Cloud. To help you choose theright mapping for your scenario, the following decision graphs summarize thecriteria that were discussed in the previous sections.

First, refer to the following chart to identify how many Cloud Identityor Google Workspace accounts, GCDS instances, andAD FS instances or fleets you will need.

Then refer to the second chart to identify the domains to configure in yourCloud Identity or Google Workspace account.

What's next

• Read aboutbest practices for planning accounts and organizations andbest practices for federating Google Cloud with an external identity provider.
• Configure GCDS to synchronize Active Directory users and groups to Cloud Identity.
• Configure single sign-on between Active Directory and Google Cloud.
• Lean aboutbest practices for managing super administrator accounts