This document discusses requirements to consider when you deploy ActiveDirectory to Google Cloud and helps you choose the rightarchitecture.

By federating Active Directory with Cloud Identity or Google Workspace (seePatterns for authenticating workforce users in a hybrid environment),you can enable users from your existing Active Directory domains to authenticateand access resources on Google Cloud. You can also deploy ActiveDirectory to Google Cloud if you plan to use Active Directoryto manage Windows servers on Google Cloud or if you rely on protocols thatarenot supported by Google Cloud.

Before you deploy Active Directory to Google Cloud, you must first decidewhich domain and forest architecture to use and how to integrate with yourexisting Active Directory forest.

Assessing requirements

Active Directory supports a range of domain and forest architectures.In a hybrid environment, one option is to extend a single Active Directorydomain across multiple environments. Alternatively, you can use separate domainsor forests and connect them using trusts. Which architecture is best depends onyour requirements.

To choose the best architecture, look at these factors:

• Alignment with existing security zones
• Interaction between on-premises and Google Cloud resources
• Administrative autonomy
• Availability

The following sections discuss these factors.

Alignment with existing security zones

Start by reviewing the design of your on-premises network.

In your on-premises environment, you might have segmented your network intomultiplesecurity zones—forexample, by using separate VLANs or subnets. In a network that's been segmentedinto security zones, communication within a security zone is either unrestrictedor subject to only lightweight firewall and auditing policies. In contrast, anycommunication across security zones is subject to strict firewall, auditing, ortraffic inspection policies.

The intent of security zones is more far-reaching than just constraining andauditing network communication, however—security zones should implement trustboundaries.

Trust boundaries

Each machine in a network runs several processes. These processes mightcommunicate with one another locally by using interprocess communication, andthey might communicate across machines by using protocols such as HTTP. In thisweb of communication, peers don't always trust each other to the same extent.For example, processes might trust processes that are running on the samemachine more than processes that are running on other machines. And somemachines might be considered more trustworthy than others.

A trust boundary enforces discriminating between communicationparties—trusting one set of communication parties more than another set ofparties.

Trust boundaries are critical for containing the impact of an attack. Attacksrarely end once a single system has been compromised—whether that system is asingle process or an entire machine. Instead, an attacker is likely to try toextend the attack to other systems. Because systems in a trust boundary don'tdiscriminate between each other, spreading an attack inside that trust boundaryis easier than attacking systems across a trust boundary.

Once a system in a trust boundary has been compromised, all other systems inthat trust boundary must be assumed to be compromised. This assumption can helpyou identify trust boundaries or validate whether a certain system boundary is atrust boundary, for example:

Suppose an attacker has achieved the highest level of accessto target A (for example, Administrator or root access to a machine orapplication). If they can leverage these privileges to gain the same levelof access to target B, then A and B are, by definition, within the sametrust boundary. Otherwise, a trust boundary lies between A and B.

By constraining network communication, security zones can help implementtrust boundaries. For a security zone to become a true trust boundary, however,the workloads across each side of the boundary must discriminate betweenrequests that originate from the same security zone and requests that originatefrom different security zones—and scrutinize the latter more closely.

Zero-trust model

The zero-trust model is the preferred networking model on Google Cloud.

Given a single compromised system in a trust boundary, you can assume that allsystems in that boundary are compromised. This assumption suggests that smallertrust boundaries are better. The smaller the trust boundary, the fewer systemsare compromised and the more boundaries an attacker must clearfor an attack to spread.

The zero-trust model takes this idea to its logical conclusion: Each machine inthe network is treated as a unique security zone and trust boundary. Allcommunication between machines is subject to the same scrutiny and firewalling,and all network requests are treated as originating from an untrusted source.

On the networking level, you can implement a zero-trust model by usingfirewall rules to restrict traffic andVPC flow logs andfirewall rules logging to analyze traffic. At the application level, you must ensure that allapplications consistently and securely handle authentication, authorization, andauditing.

Trust boundaries in Active Directory

In an Active Directory domain, machines trust domain controllers to handleauthentication and authorization on their behalf. Once a user has proven theiridentity to one of the domain controllers, they can log on by default to allmachines of the same domain. Any access rights that the user is granted by thedomain controller (in the form of privileges and group memberships) apply tomany machines of the domain.

By using group policies, you can prevent users from accessing certain machinesor constrain their rights on certain machines. Once a machine has beencompromised, however, an attacker might be able tosteal passwords, password hashes, or Kerberos tokens of other domain users signed on to the same machine. The attacker can thenleverage these credentials to spread the attack to other domains in the forest.

Given these factors, it's best to assume that all machines in a forest are in atrust security boundary.

Compared to domain boundaries, whose purpose is to controlreplication and granting administrative autonomyto different parts of the organization, forest boundaries can providestronger isolation.Forests canserve as a trust boundary.

Aligning Active Directory forests and security zones

Assuming the forest as the trust boundary influences the design of securityzones. If a forest extends across two security zones, it's easier for anattacker to clear the boundary between these security zones. As a result, thetwo security zones effectively become one and form a single trust boundary.

In a zero-trust model, each machine in a network can be thought of as aseparate security zone. Deploying Active Directory in such a network underminesthis concept and widens the effective security boundary to include all machinesof the Active Directory forest.

For a security zone to serve as a trust boundary, you must ensure that theentire Active Directory forest is in the security zone.

Impact on extending Active Directory to Google Cloud

When you plan a deployment to Google Cloud that requires Active Directory,you must decide between two options to align the deployment with your existingsecurity zones:

• Extend an existing security zone to Google Cloud. You canextend one or more of your existing security zones to Google Cloud byprovisioning Shared VPC on Google Cloud and connecting it tothe existing zone by using Cloud VPN or Cloud Interconnect.

  Resources deployed on-premises and on Google Cloud that share a commonzone can also share a common Active Directory forest, so there's no need todeploy a separate forest to Google Cloud.

  As an example, consider an existing network that has a developmentperimeter networkand production perimeter network as security zones with a separate ActiveDirectory forest in each security zone. If you extend the security zones toGoogle Cloud, then all deployments on Google Cloud are alsopart of one of these two security zones, and can use the same ActiveDirectory forests.

  

• Introduce new security zones. Extending a securityzone might not be applicable—either because you don't want to furtherexpand a zone, or because the security requirements of your existingsecurity zones don't match the requirements of your Google Clouddeployments. You can treat Google Cloud as additionalsecurity zones.

  As an example, consider an on-premises environment that has a perimeternetwork, but doesn't distinguish between development and productionworkloads. To separate these workloads on Google Cloud, you cancreate two Shared VPCs and consider them new security zones. You thendeploy two additional Active Directory forests to Google Cloud, oneper security zone. If necessary, you can establish trust relationshipsbetween forests to enable authentication across security zones.

  

Interaction between on-premises and Google Cloud resources

The second factor to consider when you extend your Active Directory toGoogle Cloud is the interaction of users and resources between on-premisesand Google Cloud. Depending on your use case, this interaction might beanywhere from light to heavy.

Light interaction

If the sole purpose of using Active Directory on Google Cloud is to managea fleet of Windows servers and to enable administrators to sign in to theseservers, the level of interaction between environments is light:

• The set of employees interacting with resources on Google Cloud islimited to administrative staff.
• Applications deployed to Google Cloud might not interact withon-premises applications at all or might do so without relying on Windowsauthentication facilities such as Kerberos and NTLM.

In a light scenario, consider integrating your on-premises andGoogle Cloud environments in one of the following two ways:

• Two disjoint Active Directory forests: You can isolate the twoenvironments by using two separate Active Directory forests that don'tshare a trust relationship. To enable administrators to authenticate, youmaintain a separate set of user accounts for them in the Google Cloudforest.

  Maintaining a duplicate set of user accounts increases administrativeeffort and introduces the risk of forgetting to disable accounts whenemployees leave the company. A better approach is to provision theseaccounts automatically.

  If user accounts in your on-premises Active Directory are provisioned by aHuman Resources Information System (HRIS), you might be able to use asimilar mechanism to provision and manage user accounts in theGoogle Cloud forest. Alternatively, you can use tools such asMicrosoft Identity Manager to synchronize user accounts betweenenvironments.

• Two Active Directory forests with cross-forest trust: By using twoActive Directory forests and connecting them with a cross-forest trust, youcan avoid having to maintain duplicate accounts. Administrators use thesame user account to authenticate to both environments. Although the levelof isolation between environments can be considered weaker, using separateforests lets you maintain a trust boundary between youron-premises and Google Cloud environment.

Moderate interaction

Your use case might be more complex. For example:

• Administrators logging in to Windows servers deployed onGoogle Cloud might need to access file shares hosted on-premises.
• Applications might use Kerberos or NTLM to authenticate and communicateacross environment boundaries.
• You might want to enable employees to useIntegrated Windows Authentication (IWA) to authenticate to web applications deployed on Google Cloud.

In a moderate scenario, operating two disjoint Active Directory forests mightbe too limiting: You cannot use Kerberos to authenticate across the two forests,and using NTLMpass-through authentication requires that you keep user accounts and passwords in sync.

In this case, we recommend using two Active Directory forests with across-forest trust.

Heavy interaction

Certain workloads, including Virtual Desktop Infrastructure (VDI) deployments,might require heavy interaction between on-premises resources and resourcesdeployed on Google Cloud. When resources across environments are closelycoupled, trying to maintain a trust boundary between environments might not bepractical and using two forests with a cross-forest trust can be too limiting.

In this case, we recommend using a single Active Directory forest and sharingit across environments.

Administrative autonomy

The third factor to consider when you extend your Active Directory toGoogle Cloud is administrative autonomy.

If you plan todistribute workloads across on-premises and Google Cloud,the workloads you are going to run on Google Cloud might be very differentthan the workloads you keep on-premises. You might even decide that differentteams should manage the two environments.

Separating responsibilities among different teams requires granting each teamsome administrative autonomy. In Active Directory, you can grant teams theauthority to manage resources by usingdelegated administration or by using separate domains.

Delegated administration is a lightweightway to delegate administrative duties and grant some autonomy to teams.Maintaining a single domain might also help you ensure consistency acrossenvironments and teams.

You can't delegate all administrative capabilities, however, and sharing asingle domain might increase the administrative overhead of coordinating betweenteams. In such a case, we recommend using separate domains.

Availability

The final factor to consider when you extend your Active Directory toGoogle Cloud is availability. For each domain in an Active Directoryforest, the domain controller serves as the identity provider for users in thatdomain.

When using Kerberos for authentication, a user needs to interact with an ActiveDirectory domain controller at various points:

• Initial authentication (obtaining a ticket-granting ticket).
• Periodic reauthentication (refreshing a ticket-granting ticket).
• Authenticating with a resource (obtaining a service ticket).

Performing the initial authentication and periodic reauthentication requirescommunicating with a single domain controller only—a domain controller of thedomain that the user is a member of.

When authenticating with a resource, it might be necessary to interact withmultiple domain controllers, depending on the domain the resource is in:

• If the resource is located in the same domain as the user, the user canuse the same domain controller (or a different domain controller of thesame domain) to complete the authentication process.
• If the resource is located in a different domain, but there is a directtrust relationship with the user's domain, the user needs to interact withat least two domain controllers: One in the resource domain and one in theuser's domain.
• If the resource and user are part of different domains and there is onlyan indirect trust relationship between these domains, then a successfulauthentication requirescommunicating with domain controllers of every domain in the trust path.

Locating users and resources in different Active Directory domains or forestscan constrain overall availability. Because authenticating requires interactingwith multiple domains, an outage of one domain can impact the availability ofresources in other domains.

Considering the potential impact of Active Directory topology onavailability,we recommend aligning your Active Directory topology with your hybridstrategy.

Distributed workloads

To capitalize on the unique capabilities of each computing environment, youmight use a hybrid approach todistribute workloads across those environments.In such a setup, the workloads you deploy to Google Cloud are likely todepend on other infrastructure or applications running on-premises, which makeshighly availablehybrid connectivity a critical requirement.

If you deploy a separate Active Directory forest or domain to Google Cloudand use a trust to connect it to your on-premises Active Directory, you addanother dependency between Google Cloud and your on-premises environment.This dependency has a minimal effect on availability.

Redundant workloads

If you use Google Cloud to ensure business continuity, your workloadson Google Cloud mirror some of the workloads in youron-premises environment. This setup enables oneenvironment to take over the role of the other environment if afailure occurs. So you need to look at every dependency between theseenvironments.

If you deploy a separate Active Directory forest or domain to Google Cloudand use a trust to connect it to your on-premises Active Directory, you mightcreate a dependency that undermines the purpose of the setup. If theon-premises Active Directory becomes unavailable, all workloads deployed onGoogle Cloud that rely on cross-domain or cross-forest authentication mightalso become unavailable.

If your goal is to ensure business continuity, you can use separateActive Directory forests in each environment that are not connected to oneanother. Or you can extend an existing Active Directory domain toGoogle Cloud. By deploying additional domain controllers toGoogle Cloud and replicating directory content between environments, youensure that the environments operate in isolation.

Integration patterns

After you've assessed your requirements, use the following decision tree tohelp identify a suitable forest and domain architecture.

The following sections describe each pattern.

Synchronized forests

In thesynchronized forests pattern, you deploy a separate Active Directoryforest to Google Cloud. You use this forest to manage any resourcesdeployed on Google Cloud as well as the user accounts required to managethese resources.

Instead of creating a trust between the new forest and an existing, on-premisesforest, you synchronize accounts. If you use an HRIS as the leading system tomanage user accounts, you can configure the HRIS to provision user accounts inthe Google Cloud-hosted Active Directory forest. Or you can use tools suchas Microsoft Identity Manager to synchronize user accounts betweenenvironments.

Consider using the synchronized forests pattern if one or more of thefollowing applies:

• Your intended use of Google Cloud fits one of theredundant deployment patterns,and you want to avoid runtime dependencies between your on-premisesenvironment and Google Cloud.
• You want to maintain a trust boundary between your on-premises ActiveDirectory environment and the Google Cloud-hosted Active Directoryenvironment—either as adefense-in-depthmeasure or because you trust one environment more than the other.
• You expect light to no interaction between Active Directory–managedresources on-premises and on Google Cloud.
• The number of user accounts you need in the Google Cloud-hostedActive Directory environment is small.

Advantages:

• The synchronized forests pattern lets you maintain strongisolation between the two Active Directory environments. An attacker whocompromises one environment might gain little advantage in attacking thesecond environment.
• You don't need to set up hybrid connectivity between your on-premisesand Google Cloud networks to operate Active Directory.
• The Google Cloud-hosted Active Directory is unaffected by anoutage of your on-premises Active Directory. The pattern iswell-suited for business-continuity use cases or other scenarios requiringhigh availability.
• You can grant a high level of administrative autonomy to teams thatmanage the Google Cloud-hosted Active Directory forest.
• This pattern is supported byManaged Service for Microsoft Active Directory.

Best practices:

• Don't synchronize user account passwords between the two ActiveDirectory forests. Doing so undermines the isolation between the environments.
• Don't rely onpass-through authentication,because it requires synchronizing user account passwords.
• Make sure that when an employee leaves the company, their accounts inboth Active Directory environments are disabled or removed.

Resource forest

In theresource forest pattern, you deploy a separate Active Directory forestto Google Cloud. You use this forest to manage any resources deployed toGoogle Cloud as well as a minimal set of administrative user accountsrequired for managing the forest. By establishing a forest trust to yourexisting, on-premises Active Directory forest, you enable users from yourexisting forest to authenticate and access resources managed by theGoogle Cloud-hosted Active Directory forest.

If necessary, you can evolve this pattern into a hub and spoke topology withyour existing Active Directory forest at the center, connected to many resourceforests.

Consider using the resource forest pattern if one or more of the followingapplies:

• Your intended use of Google Cloud fits one of thedistributed deployment patterns,and a dependency between your on-premises environment and Google Cloudis acceptable.
• You want to maintain a trust boundary between your on-premises ActiveDirectory environment and the Google Cloud-hosted Active Directoryenvironment—either as a defense-in-depth measure or because you considerone environment more trusted than the other.
• You expect a moderate level of interaction between ActiveDirectory–managed resources on-premises and on Google Cloud.
• You have a large number of users who need to access resources deployedon Google Cloud—for example, to web applications that use IWA forauthentication.

Advantages:

• The resource forest pattern lets you maintain a trust boundarybetween the two Active Directory environments. Depending on how the trustrelationship is configured, an attacker who compromises one environmentmight gain little to no access to the other environment.
• This pattern is fully supported byManaged Microsoft AD.
• You can grant a high level of administrative autonomy to teams thatmanage the Google Cloud-hosted Active Directory forest.

Best practices:

• Connect the two Active Directory forests using a one-way trust so thatthe Google Cloud-hosted Active Directory trusts your existing ActiveDirectory, but not the other way around.
• Useselective authenticationto limit the resources in the Google Cloud-hosted Active Directorythat users from the on-premises Active Directory are allowed to access.
• Use redundantDedicated Interconnect,Partner Interconnect,orCloud VPN connections to ensure highly available network connectivity between youron-premises network and Google Cloud.

Extended domain

In theextended domain pattern, you extend one or more of your existingActive Directory domains to Google Cloud. For each domain, you deploy oneor more domain controllers on Google Cloud, which causes all domain data aswell as the global catalog to be replicated and made available onGoogle Cloud. By using separateActive Directory sites for your on-premises and Google Cloud subnets, you ensure that clientscommunicate with domain controllers that are closest to them.

Consider using the extended domain pattern if one or more of the followingapplies:

• Your intended use of Google Cloud fits one of the redundantdeployment patterns, and you want to avoid runtime dependencies betweenyour on-premises environment and Google Cloud.
• You expectheavy interaction between Active Directory—managed resources on-premises and onGoogle Cloud.
• You want to speed up authentication for applications that rely onLDAP for authentication.

Advantages:

• The Google Cloud-hosted Active Directory is unaffected by anoutage of your on-premises Active Directory. The pattern iswell-suited for business-continuity use cases or other scenarios thatrequire high availability.
• You can limit the communication between your on-premises network andGoogle Cloud. This can potentially save bandwidth and improve latency.
• All content of the global catalog is replicated to Active Directoryand can be efficiently accessed from Google Cloud-hosted resources.

Best practices:

• If you replicate all domains, the communication between youron-premises network and Google Cloud network are limited to ActiveDirectory replication between domain controllers. If you replicate only asubset of your forest's domains, domain-joined servers running onGoogle Cloud might still need to communicate with domain controllersof non-replicated domains. Make sure that the firewall rules that apply tocommunication between on-premises and Google Cloud consider allrelevant cases.
• Be aware that replicating across sites happens atcertain intervals only, so updates performed on an on-premises domain controller surface toGoogle Cloud only after a delay (and vice versa).
• Consider usingread-only domain controllers (RODCs) to maintain a read-only copy of domain data on Google Cloud,but be aware that there's a trade-off related to caching of user passwords.If you allow RODCs to cache passwords and prepopulate the password cache,resources deployed on Google Cloud can remain unaffected by an outageof on-premises domain controllers. However, the security benefits of usingan RODC over a regular domain controller are limited. If you disablepassword caching, a compromised RODC might only pose a limited risk to therest of your Active Directory, but you lose the benefit ofGoogle Cloud remaining unaffected by an outage of on-premises domaincontrollers.

Extended forest

In theextended forest pattern, you deploy a new Active Directory domain onGoogle Cloud, but integrate it into your existing forest. You use the newdomain to manage any resources deployed on Google Cloud and tomaintain a minimal set of administrative user accounts formanaging the domain.

By extending the implicit trust relationships to other domains of the forest,you enable your existing users from other domains to authenticate and accessresources managed by the Google Cloud-hosted Active Directory domain.

Consider using the extended forest pattern if one or more of the followingapplies:

• Your intended use of Google Cloud fits one of the distributeddeployment patterns, and a dependency between your on-premises environmentand Google Cloud is acceptable.
• The resources you plan to deploy to Google Cloud require adifferent domain configuration or structure than your existing domainsprovide, or you want to grant a high level of administrative autonomy toteams who administer the Google Cloud-hosted domain.
• You expect moderate to heavy interaction between ActiveDirectory–managed resources on-premises and on Google Cloud.
• You have many users who need to access resources deployedto Google Cloud—for example, to web applications that use IWA forauthentication.

Advantages:

• All content of the global catalog will be replicated to ActiveDirectory and can be efficiently accessed from Google Cloud-hostedresources.
• Replication traffic between your on-premises network andGoogle Cloud is limited to global catalog replication. This might helplimit your overall bandwidth consumption.
• You can grant a high level of administrative autonomy to teams thatmanage the Google Cloud-hosted Active Directory domain.

Best practices:

• Use redundant Dedicated Interconnect,Partner Interconnect, or Cloud VPN connections toensure highly available network connectivity between your on-premisesnetwork and Google Cloud.

Resource forest with extended domain

Theresource forest with extended domain pattern is an extension of theresource forest pattern. The resource forest pattern lets you maintain a trust boundarybetween environments and providingadministrative autonomy. A limitation of the resource forest isthat its overall availability hinges on the availability of on-premises domaincontrollers and reliable network connectivity to your on-premises data center.

You can overcome these limitations by combining the resource forest patternwith theextended domain pattern.By replicating the domain, your user accounts are located in Google Cloud,and you can ensure that users can authenticate to Google Cloud-hostedresources even when on-premises domain controllers are unavailable or networkconnectivity is lost.

Consider using the resource forest with extended domain pattern if oneor more of the following applies:

• You want to maintain a trust boundary between your main ActiveDirectory forest and the resource forest.
• You want to prevent an outage of on-premises domain controllers or loss ofnetwork connectivity to your on-premises environment from affecting yourGoogle Cloud-hosted workloads.
• You expect moderate interaction between Active Directory–managedresources on-premises and on Google Cloud.
• You have many users from a single Active Directory domainwho need to access resources deployed on Google Cloud—for example, toweb applications that use IWA for authentication.

Advantages:

• Google Cloud-hosted resources are unaffected by an outage ofyour on-premises Active Directory. The pattern is well-suited forbusiness-continuity use cases or other scenarios that require high availability.
• The pattern lets you maintain a trust boundary between the twoActive Directory forests. Depending on how the trust relationship isconfigured, an attacker who compromises one environment might gain littleto no access to the other environment.
• Communication between your on-premises network and Google Cloudnetwork is limited to Active Directory replication between domaincontrollers. You can implement firewall rules to disallow all othercommunication, strengthening the isolation between environments
• You can grant a high level of administrative autonomy to teams thatmanage the Google Cloud-hosted Active Directory forest.
• You can useManaged Microsoft AD for the resource forest.

Best practices:

• Deploy domain controllers for the extended domain into a separateGoogle Cloud project andVPC in order to separate these components from the components of the resourceforest.
• UseVPC peering to connect the VPC to Shared VPC or to the VPC used by the resourceforest andconfigure firewalls to restrict communication to Kerberos user authentication and forest trust creation.
• Connect the two Active Directory forests using a one-way trust so thatthe Google Cloud-hosted Active Directory trusts your existing ActiveDirectory forest, but not the other way around.
• Use selective authentication to limit the resources in the resourceforest that users from other forests are allowed to access.
• Be aware that replicating across sites happens at certain intervalsonly, so updates performed on an on-premises domain controller surface toGoogle Cloud only after a delay (and vice versa).
• Consider using RODCs for the extended domain, but be sure to allowcaching of passwords to preserve the availability advantagescompared to the resource forest pattern.

What's next

• Find out more aboutManaged Microsoft AD.
• Reviewbest practices for deploying an Active Directory resource forest on Google Cloud.
• Learn how todeploy a fault-tolerant Active Directory environment to Google Cloud.
• Review ourbest practices on VPC design.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.