{
	"id": "c9bb2fd3-9726-44c4-91b8-d609c3cd4d32",
	"created_at": "2026-04-06T01:31:42.782433Z",
	"updated_at": "2026-04-10T03:21:09.412529Z",
	"deleted_at": null,
	"sha1_hash": "6943346c2f2fe8226ff1f32d6d141779f7beda2f",
	"title": "Federate Google Cloud with Active Directory",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 249341,
	"plain_text": "Federate Google Cloud with Active Directory\r\nArchived: 2026-04-06 00:26:49 UTC\r\nLast reviewed 2024-06-26 UTC\r\nThis document describes how you can configure Cloud Identity or Google Workspace to use Active Directory as\r\nIdP and authoritative source.\r\nThe document compares the logical structure of Active Directory with the structure used by Cloud Identity and\r\nGoogle Workspace and describes how you can map Active Directory forests, domains, users, and groups. The\r\ndocument also provides a flowchart that helps you determine the best mapping approach for your scenario.\r\nThis document assumes that you're familiar with Active Directory.\r\nImplement federation\r\nGoogle Cloud uses Google identities for authentication and access management. Manually maintaining Google\r\nidentities for each employee can add unnecessary management overhead when all employees already have an\r\naccount in Active Directory. By federating user identities between Google Cloud and your existing identity\r\nmanagement system, you can automate the maintenance of Google identities and tie their lifecycle to existing\r\nusers in Active Directory.\r\nSetting up federation between Active Directory and Cloud Identity or Google Workspace entails two pieces:\r\nProvisioning users: Relevant users and groups are synchronized periodically from Active Directory to\r\nCloud Identity or Google Workspace. This process ensures that when you create a new user in Active\r\nDirectory, it can be referenced in Google Cloud even before the associated user has logged in for the first\r\ntime. This process also ensures that user deletions are being propagated.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 1 of 14\n\nProvisioning works one way, which means changes in Active Directory are replicated to Google Cloud but\r\nnot the other way around. Also, provisioning does not include passwords. In a federated setup, Active\r\nDirectory remains the only system that manages these credentials.\r\nSingle sign-on: Whenever a user needs to authenticate, Google Cloud delegates the authentication to\r\nActive Directory by using the Security Assertion Markup Language (SAML) protocol. This delegation\r\nensures that only Active Directory manages user credentials and that any applicable policies or multi-factor\r\nauthentication (MFA) mechanisms are being enforced. For a sign-on to succeed, however, the respective\r\nuser must have been provisioned before.\r\nTo implement federation, you can use the following tools:\r\nGoogle Cloud Directory Sync (GCDS) is a free Google-provided tool that implements the synchronization\r\nprocess. GCDS communicates with Google Cloud over Secure Sockets Layer (SSL) and usually runs in the\r\nexisting computing environment.\r\nActive Directory Federation Services (AD FS) is provided by Microsoft as part of Windows Server. With\r\nAD FS, you can use Active Directory for federated authentication. AD FS usually runs within the existing\r\ncomputing environment.\r\nBecause APIs for Google Cloud are publicly available and SAML is an open standard, many tools are available to\r\nimplement federation. This document focuses on using GCDS and AD FS.\r\nLogical structure of Active Directory\r\nIn an Active Directory infrastructure, the top-level component is the forest. The forest serves as a container for one\r\nor more domains and derives its name from the forest root domain. Domains in an Active Directory forest trust\r\neach other, allowing users who are authenticated in one domain to access resources that are in another domain.\r\nUnless forests are connected by using cross-forest trusts, separate forests don't trust each other by default, and\r\nusers who are authenticated in one forest cannot access resources that are in a different forest.\r\nActive Directory infrastructure.\r\nActive Directory domains are containers for managing resources and are considered administrative boundaries.\r\nHaving multiple domains in a forest is one way to simplify administration or enforce additional structure, but\r\ndomains in a forest don't represent security boundaries.\r\nLogical structure of Google Cloud\r\nIn Google Cloud, organizations serve as containers for all resources, and they can be further segmented by using\r\nfolders and projects. Organizations, folders, and projects therefore serve a purpose similar to Active Directory\r\ndomains.\r\nActive Directory treats users as resources, so user management and authentication are tied to domains. In contrast,\r\nGoogle Cloud doesn't manage users in an organization, except for service accounts. Instead, Google Cloud relies\r\non Cloud Identity or Google Workspace to manage users.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 2 of 14\n\nA Cloud Identity or Google Workspace account serves as a private directory for users and groups. As an\r\nadministrator of the account, you can control the lifecycle and the configuration of users and groups and define\r\nhow authentication can be performed.\r\nLogical structure of Google Cloud.\r\nWhen you create a Cloud Identity or Google Workspace account, a Google Cloud organization is created\r\nautomatically for you. The Cloud Identity or Google Workspace account and the Google Cloud organization that's\r\nassociated with it share the same name and are tied to each other. However, a Google Cloud organization is\r\nallowed to reference users and groups from other Cloud Identity or Google Workspace accounts.\r\nIntegrate Active Directory and Google Cloud\r\nDespite certain similarities between the logical structure of Active Directory and Google Cloud, no single\r\nmapping between the two structures works equally well in all scenarios. Instead, the right approach to integrating\r\nthe two systems and mapping the structure depends on multiple factors:\r\nHow to map domains and forests to Cloud Identity or Google Workspace accounts\r\nHow to map DNS domains\r\nHow to map users\r\nHow to map groups\r\nThe following sections look at each of these factors.\r\nMap forests\r\nEspecially in larger organizations, you often use more than one Active Directory domain to manage identities and\r\naccess across the enterprise. When you are planning to federate Active Directory and Google Cloud, the first\r\nfactor to look at is the topology of your Active Directory infrastructure.\r\nSingle forest, single domain\r\nSingle forest, single domain.\r\nWhen a forest includes just one domain, you can map the entire Active Directory forest to a single Cloud Identity\r\nor Google Workspace account. This account then provides the basis for a single Google Cloud organization that\r\nyou can use to manage your Google Cloud resources.\r\nIn a single-domain environment, domain controllers and global catalog servers both provide access to all objects\r\nthat are managed in Active Directory. In most cases, you can run a single instance of GCDS to synchronize user\r\naccounts and groups to Google Cloud, and to maintain a single AD FS instance or fleet to handle single sign-on.\r\nSingle forest, multiple domains\r\nSingle forest, multiple domains.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 3 of 14\n\nWhen a forest contains multiple Active Directory domains, you can organize them in one or more domain trees. In\r\nboth cases, you can map the entire forest to a single Cloud Identity or Google Workspace account. This account\r\nthen provides the basis for a single Google Cloud organization that you can use to manage your Google Cloud\r\nresources.\r\nIn a multi-domain environment, there is a difference between what information can be retrieved from a domain\r\ncontroller and what can be queried from a global catalog server. While domain controllers serve data only from\r\ntheir local domain, global catalog servers provide access to information from all domains in the forest. Crucially,\r\nthe data that is served by global catalog servers is partial and lacks certain LDAP attributes. This limitation can\r\naffect how you configure GCDS to synchronize groups.\r\nDepending on how you plan to map groups, federating a multi-domain forest with Google Cloud requires one or\r\nmore GCDS instances but only a single AD FS instance or fleet to handle single sign-on.\r\nMultiple forests with cross-forest trust\r\nMultiple forests with cross-forest trust.\r\nIn larger organizations, it's not uncommon to have more than one Active Directory forest, often as a result of a\r\nmerger or acquisition. You can combine these forests by using a two-way, cross-forest trust so that users can share\r\nand access resources across the boundaries of a single forest.\r\nIf all forests have a bidirectional trust relationship with another forest, you can map the entire environment to a\r\nsingle Cloud Identity or Google Workspace account. This account provides the basis for a single Google Cloud\r\norganization that you can use to manage your Google Cloud resources.\r\nAlthough global catalog servers provide access to data from multiple domains, their scope is limited to a single\r\nforest. So in a multi-forest environment, you must query multiple domain controllers or global catalog servers to\r\nobtain, for example, a complete list of users. As a result of this limitation, federating a multi-forest environment\r\nwith Google Cloud requires at least one GCDS instance per forest. Cross-forest trusts enable user authentication to\r\nwork across forest boundaries, so a single AD FS instance or fleet is sufficient to handle single sign-on.\r\nIf your environment spans multiple forests without cross-forest trust, but all Active Directory domains that are\r\nrelevant for federation with Google Cloud are connected through external trusts, then the same considerations\r\napply.\r\nMultiple forests without cross-forest trust\r\nMultiple forests without cross-forest trust.\r\nIn the environment illustrated here, it's not possible to authenticate or access resources across the forest\r\nboundaries. It's also not possible for a single AD FS instance or fleet to handle single sign-on requests for users\r\nfrom all forests.\r\nTherefore, it's not possible to map multiple forests that lack cross-forest trusts to a single Cloud Identity or Google\r\nWorkspace account. Instead, each forest must be mapped to a separate Cloud Identity or Google Workspace\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 4 of 14\n\naccount, which involves running at least one GCDS instance and one AD FS server or fleet per forest.\r\nIn Google Cloud, a separate organization is created for each Cloud Identity or Google Workspace account. In most\r\ncases, you don't need to maintain multiple, separate organizations. You can select one of the organizations and\r\nassociate it with the other Cloud Identity or Google Workspace accounts, effectively creating an organization that\r\nis federated with multiple Active Directory forests. The other organizations remain unused.\r\nMap DNS domains\r\nDNS plays a crucial role both in Active Directory and for Cloud Identity and Google Workspace. The second\r\nfactor to look at when you're planning to federate Active Directory and Google Cloud is how to share or map DNS\r\ndomains between Active Directory and Google Cloud.\r\nUsage of DNS domains in Active Directory\r\nIn an Active Directory forest, DNS domains are used in multiple places:\r\nActive Directory DNS domains: Each Active Directory domain corresponds to a DNS domain. This\r\ndomain might be global, like corp.example.com , or can be a local domain name like corp.local or\r\ncorp.internal .\r\nMail exchange (MX) domains: Email addresses use a DNS domain. In some cases, this domain is the\r\nsame as the Active Directory DNS domain, but in many cases, a different, often shorter, domain such as\r\nexample.com is used. Ideally, users in Active Directory have the email address that is associated with the\r\noptional mail attribute.\r\nUPN suffix domains: These domains are used for User Principal Names (UPN). By default, the Active\r\nDirectory DNS domain of the user's domain is used to build a UPN. For a user john in the domain\r\ncorp.example.com , the default UPN therefore reads john@corp.example.com . However, you can\r\nconfigure a forest to use additional DNS domains as UPN suffixes that correspond to neither Active\r\nDirectory DNS domains nor MX domains. UPNs are optional and are stored in the userPrincipalName\r\nfield of the user.\r\nEndpoint domains: Public-facing servers such as AD FS servers are usually assigned a DNS name, such\r\nas login.external.example.com . The domain that is used for these purposes can overlap with the MX,\r\nUPN suffix, or Active Directory DNS domain, or it can be an entirely different domain.\r\nUsage of DNS domains in Google Cloud\r\nGoogle Sign-In, which Google Cloud relies on for authentication, uses email addresses to identify users. Using\r\nemail addresses not only guarantees that they are globally unique, but also enables Google Cloud to send\r\nnotification messages to the addresses.\r\nGoogle Sign-In determines the directory or identity provider to use for authenticating a user based on the domain\r\npart of the email addresses, which follows the @ . For an email address that uses the gmail.com domain, for\r\nexample, Google Sign-In uses the directory of Gmail users for authentication.\r\nUsage of DNS domains in Google Cloud.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 5 of 14\n\nWhen you sign up for a Google Workspace or Cloud Identity account, you're creating a private directory that\r\nSign-In can use for authentication. In the same way that the Gmail directory is associated with the gmail.com\r\ndomain, Google Workspace and Cloud Identity accounts need to be associated with a custom domain. Three\r\ndifferent kinds of domains are used:\r\nPrimary domain: This domain identifies the Cloud Identity or Google Workspace account and is used as\r\nthe name for the organization in Google Cloud. When signing up for Cloud Identity or Google Workspace,\r\nyou must specify this domain name.\r\nSecondary domain: Along with the primary domain, you can associate other, secondary domains with a\r\nCloud Identity or Google Workspace account. Each user in the directory is associated with either the\r\nprimary domain or one of the secondary domains. Two users, johndoe@example.com and\r\njohndoe@secondary.example.com , are considered separate users if example.com is the primary domain\r\nand secondary.example.com is a secondary domain.\r\nAlias domain: An alias domain is an alternate name for another domain. That is, johndoe@example.com\r\nand johndoe@alias.example.com refer to the same user if alias.example.com is set up as an alias\r\ndomain for example.com .\r\nAll domains must satisfy the following requirements:\r\nThey must be valid, global DNS domain names. During setup, you might need administrative access to the\r\nrespective DNS zones in order to verify domain ownership.\r\nA domain, such as example.com , can refer only to a single directory. However, you can use different\r\nsubdomains, such as subdomain.example.com , to refer to different directories.\r\nPrimary and secondary domains should have a valid MX record so that messages sent to email addresses\r\nthat are formed by using this domain name can be delivered properly.\r\nIn order to enable synchronizing between the directories, some mapping is required between the Active Directory\r\ndomains and the domains that Cloud Identity or Google Workspace uses. Determining the right mapping depends\r\non how you use Active Directory and requires a closer look at how users are identified in an Active Directory\r\nforest and how they can be mapped to Cloud Identity or Google Workspace.\r\nMap users\r\nThe third factor to look at when planning to federate Active Directory and Google Cloud is how to map users\r\nbetween Active Directory and Cloud Identity or Google Workspace.\r\nIdentify users in Active Directory\r\nInternally, Active Directory uses two identifiers to uniquely identify users:\r\nobjectGUID : This globally unique ID is generated when a user is created, and never changes.\r\nobjectSID : The SID, or security identifier, is used for all access checks. While this ID is unique and\r\nstable within a domain, it's possible that when moved to a different domain in the forest, a user might be\r\nassigned a new SID.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 6 of 14\n\nNeither of these IDs is meaningful to users, so Active Directory offers two human-friendly ways to identify users:\r\nUPN ( userPrincipalName ): The preferred way to identify a user is by UPN. UPNs follow the RFC 822\r\nformat of email addresses and are created by combining the username with a UPN suffix domain, as in\r\njohndoe@corp.example.com . Despite being the preferred way to identify users, UPNs are optional, so\r\nsome users in your Active Directory forest might lack a UPN.\r\nAlthough it's considered a best practice that UPNs be valid email addresses, Active Directory does not\r\nenforce this practice.\r\nPre–Windows 2000 logon name ( sAMAccountName ): This name combines the NetBIOS domain name and\r\nusername by using the format domain\u003cvar\u003euser , as in corp\\johndoe . Although these names are\r\nconsidered legacy, they are still commonly used and are the only mandatory identifier of a user.\r\nNotably, Active Directory does not use the user's email address ( mail ) to identify users. Consequently, this field\r\nis neither mandatory nor required to be unique in a forest.\r\nAll of these identifiers can be changed at any time.\r\nMap user identities\r\nMapping Active Directory users to Cloud Identity or Google Workspace users requires two pieces of information\r\nfor each user:\r\nA stable, unique ID that you can use during synchronization to track which Active Directory user\r\ncorresponds to which user in Cloud Identity or Google Workspace. On the AD side, the objectGUID is\r\nperfectly suited for this purpose.\r\nAn email address for which the domain part corresponds to a primary, secondary, or alias domain of your\r\nCloud Identity or Google Workspace account. Because this email address will be used throughout Google\r\nCloud, make sure the address is meaningful. Deriving an address from the objectGUID is impractical, as\r\nare other automatically generated email addresses.\r\nFor an Active Directory user, two fields are candidates for providing a Cloud Identity or Google Workspace email\r\naddress: userPrincipalName and mail .\r\nMap by user principal name\r\nUsing the userPrincipalName field requires that two criteria be met for all users that are subject to\r\nsynchronization:\r\nUser principal names (UPNs) must be valid email addresses. All domains that are used as UPN suffix\r\ndomains also must be MX domains and must be set up so that an email that is sent to a user's UPN is\r\ndelivered to their email inbox.\r\nUPN assignments must be complete. All users that are subject to synchronization must have a UPN\r\nassigned. The following PowerShell command can help you find users that lack a UPN:\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 7 of 14\n\nGet-ADUser -LDAPFilter \"(!userPrincipalName=*)\"\r\nIf these two criteria are met, you can safely map UPNs to Cloud Identity or Google Workspace email addresses.\r\nYou can use one of the UPN suffix domains as the primary domain in Cloud Identity or Google Workspace and\r\nadd any other UPN suffix domains as secondary domains.\r\nIf one of the criteria is not met, you can still map UPNs to Cloud Identity or Google Workspace email addresses,\r\nbut the following caveats apply:\r\nIf UPNs are not valid email addresses, users might not receive notification emails that are sent by Google\r\nCloud, which might cause users to miss important information.\r\nUsers without UPNs are ignored during synchronization.\r\nYou can configure the synchronization to replace the UPN suffix domain with a different domain. When\r\nyou're using multiple UPN suffix domains in a forest, this approach can create duplicates, however,\r\nbecause all UPN suffix domains will be replaced by a single domain. In case of duplicates, only a single\r\nuser can be synchronized.\r\nA major advantage of using UPNs to map users is that UPNs are guaranteed to be unique across a forest, and they\r\nuse a curated set of domains, which helps avoid potential synchronization problems.\r\nMap by email address\r\nUsing the mail field requires meeting the following criteria for all users that are subject to synchronization:\r\nEmail assignments must be complete. All users that are subject to synchronization must have the mail\r\nfield populated. The following PowerShell command can help you find users for which this field is not\r\npopulated:\r\nGet-ADUser -LDAPFilter \"(!mail=*)\"\r\nEmail addresses must use a curated set of domains, all of which are owned by you. If some of your users\r\nuse email addresses that refer to partner companies or consumer email providers, those email addresses\r\ncannot be used.\r\nAll email addresses must be unique across the forest. Because Active Directory does not enforce\r\nuniqueness, you might have to implement custom checks or policies.\r\nIf all relevant users meet these criteria, you can identify all domains that are used by these email addresses and use\r\nthem as primary and secondary domains in Cloud Identity or Google Workspace.\r\nIf one of the criteria is not met, you can still map email addresses to Cloud Identity or Google Workspace email\r\naddresses, with the following caveats:\r\nDuring synchronization, users without email addresses will be ignored, as will users with email addresses\r\nthat use domains that are not associated with the Cloud Identity or Google Workspace account.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 8 of 14\n\nWhen two users share the same email address, only one user will be synchronized.\r\nYou can configure the synchronization to replace the domain of email addresses with a different domain.\r\nThis process can create duplicates, in which case only one user will be synchronized.\r\nMap groups\r\nThe fourth factor to look at when you're planning to federate Active Directory and Google Cloud is whether to\r\nsynchronize groups between Active Directory and Google Cloud and how to map them.\r\nIn Google Cloud, groups are commonly used as a way to manage access efficiently across projects. Rather than\r\nassigning individual users to IAM roles in each project, you define a set of groups that model common roles in\r\nyour organization, and then assign those groups to a set of IAM roles. By modifying the membership of the\r\ngroups, you can control users' access to an entire set of resources.\r\nActive Directory distinguishes between two kinds of groups: distribution groups and security groups. Distribution\r\ngroups are used to manage email lists. Synchronizing distribution groups is relevant when you're migrating from\r\nMicrosoft Exchange to Google Workspace, so GCDS can handle both regular and dynamic distribution groups.\r\nDistribution groups aren't a concern in identity and access management for Google Cloud, however, so this\r\ndiscussion focuses exclusively on security groups.\r\nMapping groups between Active Directory and Google Cloud is optional. Once you've set up user provisioning,\r\nyou can create and manage groups directly in Cloud Identity or Google Workspace, which means that Active\r\nDirectory remains the central system for identity management but not for access management. To maintain Active\r\nDirectory as the central system for identity management and access management, we recommend that you\r\nsynchronize security groups from Active Directory instead of managing them in Cloud Identity or Google\r\nWorkspace. With this approach, you can set up IAM so that you can use group memberships in Active Directory\r\nto control who has access to certain resources in Google Cloud.\r\nSecurity groups in Active Directory\r\nSecurity groups play a foundational role in Windows security and Active Directory access management. This role\r\nis facilitated by three different types of Active Directory groups: domain local groups, global groups, and\r\nuniversal groups.\r\nSecurity groups in AD.\r\nDomain local groups\r\nThese groups are relevant only within the scope of a single domain and cannot be referenced in other\r\ndomains. Because their list of members does not need to be replicated across the forest, domain local\r\ngroups are the most flexible with respect to the types of members that they can include.\r\nGlobal groups\r\nThese groups are surfaced to and can be referenced in other domains. Their member list is not replicated,\r\nhowever. This limitation restricts the types of members that these groups can include. These groups can\r\nonly include users and other global groups from the same domain.\r\nUniversal groups\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 9 of 14\n\nThese groups, along with their member lists, are replicated across the forest. They can therefore be\r\nreferenced in other domains and can include not only users and other universal groups but also global\r\ngroups from all domains.\r\nIf your Active Directory forest contains only a single domain, you can synchronize all three types of security\r\ngroups by using GCDS. If your Active Directory forest uses more than one domain, the type of a group determines\r\nwhether and how it can be synchronized to Cloud Identity or Google Workspace.\r\nBecause domain local and global groups aren't fully replicated across a forest, global catalog servers contain\r\nincomplete information about them. Although this limitation is deliberate and helps to speed up directory\r\nreplication, it's an obstacle when you want to synchronize such groups to Cloud Identity or Google Workspace.\r\nSpecifically, if you configure GCDS to use a global catalog server as a source, then the tool will be able to find\r\ngroups from all domains across the forest. But only groups that are in the same domain as the global catalog server\r\nwill contain a membership list and be suitable for replication. To synchronize domain local or global groups in a\r\nmulti-domain forest, you must run a separate GCDS instance per domain.\r\nBecause universal groups are fully replicated across the forest, they don't have this restriction. A single GCDS\r\ninstance can synchronize universal groups from multiple domains.\r\nBefore concluding that you need multiple GCDS instances to synchronize multiple Active Directory domains to\r\nCloud Identity or Google Workspace, keep in mind that not all groups might need to be synchronized. For this\r\nreason, it's worthwhile to look at how different types of security groups are typically used across your Active\r\nDirectory forest.\r\nUsage of security groups in Active Directory\r\nThe following sections describe the types of security groups that are used in Active Directory.\r\nResource groups\r\nWindows uses an access model based on access control lists (ACLs). Each resource like a file or LDAP object has\r\nan associated ACL that controls which users have access to it. Resources and ACLs are very fine grained, so there\r\nare many of them. To simplify the maintenance of ACLs, it's common to create resource groups to bundle\r\nresources that are frequently used and accessed together. You add the resource group to all affected ACLs once,\r\nand manage further access by altering membership of the resource group, not by altering the ACLs.\r\nThe resources that are bundled this way typically reside in a single domain. Consequently, a resource group also\r\ntends to be referenced only in a single domain, either in ACLs or by other resource groups. Because most resource\r\ngroups are local, they are usually implemented by using domain local groups in Active Directory.\r\nRole and organization groups\r\nResource groups help simplify access management, but in a large environment, you might need to add a new user\r\nto a large number of resource groups. For this reason, resource groups are commonly complemented by role\r\ngroups or organization groups.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 10 of 14\n\nRole groups aggregate the permissions that a specific role requires in the organization. A role group that is named\r\nEngineering Documentation Viewer, for example, might give members read-only access to all engineering\r\ndocumentation. Practically, you would implement this by creating a role group and making it a member of all\r\nresource groups that are used to control access to various kinds of documentation.\r\nIn a similar way, organization groups aggregate the permissions that are required by departments within an\r\norganization. For example, an organization group that is named Engineering might grant access to all resources\r\nthat members of the Engineering department commonly require.\r\nTechnically, there is no difference between role groups and resource groups, and the two are commonly used in\r\nconcert. Unlike resource groups, however, role and organization groups can have relevance beyond the boundaries\r\nof a domain. To allow such groups to be referenced by resource groups in other domains, role and organization\r\ngroups are usually implemented by using global groups, which are constrained to members of a single domain,\r\nand sometimes complemented by universal groups, which allow members from different domains.\r\nThe following diagram shows a nesting pattern that is commonly used in multi-domain Active Directory\r\nenvironments.\r\nNesting pattern used in multi-domain AD environments.\r\nGroups in Cloud Identity and Google Workspace\r\nIn Cloud Identity and Google Workspace, there is only a single type of group. Groups in Cloud Identity and\r\nGoogle Workspace aren't confined to the scope of the Cloud Identity or Google Workspace account where they\r\nwere defined. Instead, they can include users from different Cloud Identity or Google Workspace accounts,\r\nsupport being referenced and nested in other accounts, and be used across any Google Cloud organization.\r\nAs it does with users, Cloud Identity and Google Workspace identifies groups by email address. The email address\r\ndoesn't have to correspond to an actual mailbox, but it must use one of the domains registered for the respective\r\nCloud Identity account.\r\nUnlike Active Directory groups, members of a Cloud Identity or Google Workspace group are not implicitly\r\ngranted permission to list other members of the same group. Instead, querying group membership generally\r\nrequires explicit authorization.\r\nUsage of groups in Google Cloud\r\nGoogle Cloud uses a role-based access model instead of an ACL-based access model. Roles apply to all resources\r\nof a certain type that fall within a certain scope. For example, the Kubernetes Engine Developer role has full\r\naccess to Kubernetes API objects inside all clusters in a given project. Due to the nature of roles, there is little\r\nneed to maintain resource groups on Google Cloud, and rarely a need to synchronize resource groups to Google\r\nCloud.\r\nRole groups and organization groups are just as relevant in Google Cloud as they are in Active Directory, because\r\nthey make it easier to manage access for large numbers of users. Synchronizing role and organization groups helps\r\nmaintain Active Directory as the primary place for managing access.\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 11 of 14\n\nSynchronizing role and organization groups.\r\nIf you consistently implement resource groups as domain local groups, and role and organization groups as global\r\nor universal groups, you can use the group type to ensure that only role and organization groups are synchronized.\r\nThe question of whether it's sufficient to run a single GCDS instance per multi-domain forest or whether you need\r\nmultiple GCDS instances then becomes the question of whether you use global groups. If you implement all your\r\nrole and organization groups by using universal groups, a single GCDS instance is sufficient; otherwise, you'll\r\nneed a GCDS instance per domain.\r\nMap group identities\r\nMapping Active Directory security groups to Cloud Identity or Google Workspace groups requires a common\r\nidentifier. In Cloud Identity and Google Workspace, this identifier must be an email address for which the domain\r\npart corresponds to a the primary, secondary, or alias domain of the Cloud Identity or Google Workspace account.\r\nBecause this email address will be used throughout Google Cloud, the address must be human-readable. The email\r\naddress doesn't need to correspond to a mailbox.\r\nIn Active Directory, groups are identified either by their common name ( cn ) or by a pre–Windows 2000 logon\r\nname ( sAMAccountName ). Similar to user accounts, groups can also have an email address ( mail ), but email\r\naddresses are an optional attribute for groups, and Active Directory does not verify uniqueness.\r\nYou have two options for mapping group identities between Active Directory and Cloud Identity or Google\r\nWorkspace.\r\nMap by common name\r\nThe advantage of using the common name ( cn ) is that it's guaranteed to be available and, at least within an\r\norganizational unit, unique. However, the common name is not an email address, so it needs a suffix @DOMAIN\r\nappended to turn into an email address.\r\nYou can configure GCDS to automatically take care of appending a suffix to the group name. Because Active\r\nDirectory ensures that group names and user names don't conflict, an email address that is derived this way is also\r\nunlikely to cause any conflicts.\r\nIf your Active Directory forest contains more than a single domain, the following caveats apply:\r\nIf two groups in different domains share a common name, the derived email address will conflict, causing\r\none group to be ignored during synchronization.\r\nYou can only synchronize groups from domains of a single forest. If you synchronize groups from multiple\r\nforests by using separate GCDS instances, the email addresses that are derived from the common name\r\ndon't reflect which forest they correspond to. This ambiguity will cause a GCDS instance to delete any\r\ngroup that has previously been created from a different forest by another GCDS instance.\r\nYou cannot map groups by common name if you use domain substitution for mapping users.\r\nMap by email address\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 12 of 14\n\nUsing the email address ( mail ) to map group identities means you must satisfy the same criteria as when using\r\nthe email address to map users:\r\nEmail assignments must be complete. Although it's common for distribution groups to have an email\r\naddress, security groups often lack this attribute. To use the email address for mapping identities, security\r\ngroups that are subject to synchronization must have the mail field populated. The following PowerShell\r\ncommand can help you find accounts for which this field is not populated:\r\nGet-ADGroup -LDAPFilter \"(!mail=*)\"\r\nEmail addresses must use a curated set of domains, all of which you own. If some of your users use email\r\naddresses that refer to partner companies or consumer email providers, you cannot use those addresses.\r\nAll email addresses must be unique across the forest. Because Active Directory does not enforce\r\nuniqueness, you might have to implement custom checks or policies.\r\nIf all relevant groups meet these criteria, you can identify all domains that are used by these email addresses and\r\nensure that the list of DNS domains registered in Cloud Identity or Google Workspace covers these domains.\r\nIf one of the criteria is not met, you can still map UPNs to Cloud Identity or Google Workspace email addresses,\r\nwith the following caveats:\r\nGroups without email addresses will be ignored during synchronization, as will email addresses that use\r\ndomains that aren't associated with the Cloud Identity or Google Workspace account.\r\nWhen two groups share the same email address, only one of them will be synchronized.\r\nMapping groups by email address is not supported if your Active Directory forest contains more than a single\r\ndomain and you use domain substitution for mapping users.\r\nMap organizational units\r\nMost Active Directory domains make extensive use of organizational units to cluster and organize resources\r\nhierarchically, control access, and enforce policies.\r\nIn Google Cloud, folders and projects serve a similar purpose, although the kinds of resources that are managed\r\nwithin a Google Cloud organization are very different from the resources that are managed in Active Directory. As\r\na result, an appropriate Google Cloud folder hierarchy for an enterprise tends to differ significantly from the\r\nstructure of organizational units in Active Directory. Automatically mapping organizational units to folders and\r\nprojects is therefore rarely practical and not supported by GCDS.\r\nUnrelated to folders, Cloud Identity and Google Workspace support the concept of organizational units.\r\nOrganizational units are created to cluster and organize users, similar to Active Directory. But unlike in Active\r\nDirectory, they apply only to users, not to groups.\r\nGCDS offers the option of synchronizing Active Directory organizational units to Cloud Identity or Google\r\nWorkspace. In a setup where Cloud Identity is merely used to extend Active Directory identity management to\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 13 of 14\n\nGoogle Cloud, mapping organizational units is usually not necessary.\r\nChoose the right mapping\r\nAs noted at the beginning of this document, there is no single best way to map the structures of Active Directory\r\nand Google Cloud. To help you choose the right mapping for your scenario, the following decision graphs\r\nsummarize the criteria that were discussed in the previous sections.\r\nFirst, refer to the following chart to identify how many Cloud Identity or Google Workspace accounts, GCDS\r\ninstances, and AD FS instances or fleets you will need.\r\nDecision graph to determine number of fleets or instances needed.\r\nThen refer to the second chart to identify the domains to configure in your Cloud Identity or Google Workspace\r\naccount.\r\nDecision graph.\r\nWhat's next\r\nRead about best practices for planning accounts and organizations and best practices for federating Google\r\nCloud with an external identity provider.\r\nConfigure GCDS to synchronize Active Directory users and groups to Cloud Identity.\r\nConfigure single sign-on between Active Directory and Google Cloud.\r\nLean about best practices for managing super administrator accounts\r\nSource: https://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nhttps://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/solutions/federating-gcp-with-active-directory-introduction"
	],
	"report_names": [
		"federating-gcp-with-active-directory-introduction"
	],
	"threat_actors": [],
	"ts_created_at": 1775439102,
	"ts_updated_at": 1775791269,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6943346c2f2fe8226ff1f32d6d141779f7beda2f.pdf",
		"text": "https://archive.orkl.eu/6943346c2f2fe8226ff1f32d6d141779f7beda2f.txt",
		"img": "https://archive.orkl.eu/6943346c2f2fe8226ff1f32d6d141779f7beda2f.jpg"
	}
}