Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/solutions/patterns-for-using-active-directory-in-a-hybrid-environment below:

Patterns for using Active Directory in a hybrid environment | Cloud Architecture Center

Last reviewed 2024-06-26 UTC

This document discusses requirements to consider when you deploy Active Directory to Google Cloud and helps you choose the right architecture.

By federating Active Directory with Cloud Identity or Google Workspace (see Patterns for authenticating workforce users in a hybrid environment), you can enable users from your existing Active Directory domains to authenticate and access resources on Google Cloud. You can also deploy Active Directory to Google Cloud if you plan to use Active Directory to manage Windows servers on Google Cloud or if you rely on protocols that are not supported by Google Cloud.

Before you deploy Active Directory to Google Cloud, you must first decide which domain and forest architecture to use and how to integrate with your existing Active Directory forest.

Active Directory supports a range of domain and forest architectures. In a hybrid environment, one option is to extend a single Active Directory domain across multiple environments. Alternatively, you can use separate domains or forests and connect them using trusts. Which architecture is best depends on your 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.

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

In your on-premises environment, you might have segmented your network into multiple security zones—for example, by using separate VLANs or subnets. In a network that's been segmented into security zones, communication within a security zone is either unrestricted or subject to only lightweight firewall and auditing policies. In contrast, any communication across security zones is subject to strict firewall, auditing, or traffic inspection policies.

The intent of security zones is more far-reaching than just constraining and auditing network communication, however—security zones should implement trust boundaries.

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

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

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

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

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

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

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 all systems in that boundary are compromised. This assumption suggests that smaller trust boundaries are better. The smaller the trust boundary, the fewer systems are compromised and the more boundaries an attacker must clear for an attack to spread.

The zero-trust model takes this idea to its logical conclusion: Each machine in the network is treated as a unique security zone and trust boundary. All communication 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 using firewall rules to restrict traffic and VPC flow logs and firewall rules logging to analyze traffic. At the application level, you must ensure that all applications consistently and securely handle authentication, authorization, and auditing.

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

By using group policies, you can prevent users from accessing certain machines or constrain their rights on certain machines. Once a machine has been compromised, however, an attacker might be able to steal passwords, password hashes, or Kerberos tokens of other domain users signed on to the same machine. The attacker can then leverage 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 a trust security boundary.

Compared to domain boundaries, whose purpose is to control replication and granting administrative autonomy to different parts of the organization, forest boundaries can provide stronger isolation. Forests can serve as a trust boundary.

Assuming the forest as the trust boundary influences the design of security zones. If a forest extends across two security zones, it's easier for an attacker to clear the boundary between these security zones. As a result, the two 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 a separate security zone. Deploying Active Directory in such a network undermines this concept and widens the effective security boundary to include all machines of the Active Directory forest.

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

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

• Extend an existing security zone to Google Cloud. You can extend one or more of your existing security zones to Google Cloud by provisioning Shared VPC on Google Cloud and connecting it to the existing zone by using Cloud VPN or Cloud Interconnect.

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

  As an example, consider an existing network that has a development perimeter network and production perimeter network as security zones with a separate Active Directory forest in each security zone. If you extend the security zones to Google Cloud, then all deployments on Google Cloud are also part of one of these two security zones, and can use the same Active Directory forests.

• Introduce new security zones. Extending a security zone might not be applicable—either because you don't want to further expand a zone, or because the security requirements of your existing security zones don't match the requirements of your Google Cloud deployments. You can treat Google Cloud as additional security zones.

  As an example, consider an on-premises environment that has a perimeter network, but doesn't distinguish between development and production workloads. To separate these workloads on Google Cloud, you can create two Shared VPCs and consider them new security zones. You then deploy two additional Active Directory forests to Google Cloud, one per security zone. If necessary, you can establish trust relationships between forests to enable authentication across security zones.

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

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

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

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

• Two disjoint Active Directory forests: You can isolate the two environments by using two separate Active Directory forests that don't share a trust relationship. To enable administrators to authenticate, you maintain a separate set of user accounts for them in the Google Cloud forest.

  Maintaining a duplicate set of user accounts increases administrative effort and introduces the risk of forgetting to disable accounts when employees leave the company. A better approach is to provision these accounts automatically.

  If user accounts in your on-premises Active Directory are provisioned by a Human Resources Information System (HRIS), you might be able to use a similar mechanism to provision and manage user accounts in the Google Cloud forest. Alternatively, you can use tools such as Microsoft Identity Manager to synchronize user accounts between environments.

• Two Active Directory forests with cross-forest trust: By using two Active Directory forests and connecting them with a cross-forest trust, you can avoid having to maintain duplicate accounts. Administrators use the same user account to authenticate to both environments. Although the level of isolation between environments can be considered weaker, using separate forests lets you maintain a trust boundary between your on-premises and Google Cloud environment.

Your use case might be more complex. For example:

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

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

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

Certain workloads, including Virtual Desktop Infrastructure (VDI) deployments, might require heavy interaction between on-premises resources and resources deployed on Google Cloud. When resources across environments are closely coupled, trying to maintain a trust boundary between environments might not be practical 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 sharing it across environments.

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

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

Separating responsibilities among different teams requires granting each team some administrative autonomy. In Active Directory, you can grant teams the authority to manage resources by using delegated administration or by using separate domains.

Delegated administration is a lightweight way to delegate administrative duties and grant some autonomy to teams. Maintaining a single domain might also help you ensure consistency across environments and teams.

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

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

When using Kerberos for authentication, a user needs to interact with an Active Directory 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 requires communicating with a single domain controller only—a domain controller of the domain that the user is a member of.

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

• If the resource is located in the same domain as the user, the user can use the same domain controller (or a different domain controller of the same domain) to complete the authentication process.
• If the resource is located in a different domain, but there is a direct trust relationship with the user's domain, the user needs to interact with at least two domain controllers: One in the resource domain and one in the user's domain.
• If the resource and user are part of different domains and there is only an indirect trust relationship between these domains, then a successful authentication requires communicating with domain controllers of every domain in the trust path.

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

Considering the potential impact of Active Directory topology on availability, we recommend aligning your Active Directory topology with your hybrid strategy.

To capitalize on the unique capabilities of each computing environment, you might use a hybrid approach to distribute workloads across those environments. In such a setup, the workloads you deploy to Google Cloud are likely to depend on other infrastructure or applications running on-premises, which makes highly available hybrid connectivity a critical requirement.

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

If you use Google Cloud to ensure business continuity, your workloads on Google Cloud mirror some of the workloads in your on-premises environment. This setup enables one environment to take over the role of the other environment if a failure occurs. So you need to look at every dependency between these environments.

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

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

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

The following sections describe each pattern.

In the synchronized forests pattern, you deploy a separate Active Directory forest to Google Cloud. You use this forest to manage any resources deployed on Google Cloud as well as the user accounts required to manage these resources.

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

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

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

Advantages:

• The synchronized forests pattern lets you maintain strong isolation between the two Active Directory environments. An attacker who compromises one environment might gain little advantage in attacking the second environment.
• You don't need to set up hybrid connectivity between your on-premises and Google Cloud networks to operate Active Directory.
• The Google Cloud-hosted Active Directory is unaffected by an outage of your on-premises Active Directory. The pattern is well-suited for business-continuity use cases or other scenarios requiring high availability.
• You can grant a high level of administrative autonomy to teams that manage the Google Cloud-hosted Active Directory forest.
• This pattern is supported by Managed Service for Microsoft Active Directory.

Best practices:

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

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

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

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

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

Advantages:

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

Best practices:

• Connect the two Active Directory forests using a one-way trust so that the Google Cloud-hosted Active Directory trusts your existing Active Directory, but not the other way around.
• Use selective authentication to limit the resources in the Google Cloud-hosted Active Directory that users from the on-premises Active Directory are allowed to access.
• Use redundant Dedicated Interconnect, Partner Interconnect, or Cloud VPN connections to ensure highly available network connectivity between your on-premises network and Google Cloud.

In the extended domain pattern, you extend one or more of your existing Active Directory domains to Google Cloud. For each domain, you deploy one or more domain controllers on Google Cloud, which causes all domain data as well as the global catalog to be replicated and made available on Google Cloud. By using separate Active Directory sites for your on-premises and Google Cloud subnets, you ensure that clients communicate with domain controllers that are closest to them.

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

• Your intended use of Google Cloud fits one of the redundant deployment patterns, and you want to avoid runtime dependencies between your on-premises environment and Google Cloud.
• You expect heavy interaction between Active Directory—managed resources on-premises and on Google Cloud.
• You want to speed up authentication for applications that rely on LDAP for authentication.

Advantages:

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

Best practices:

• If you replicate all domains, the communication between your on-premises network and Google Cloud network are limited to Active Directory replication between domain controllers. If you replicate only a subset of your forest's domains, domain-joined servers running on Google Cloud might still need to communicate with domain controllers of non-replicated domains. Make sure that the firewall rules that apply to communication between on-premises and Google Cloud consider all relevant cases.
• Be aware that replicating across sites happens at certain intervals only, so updates performed on an on-premises domain controller surface to Google Cloud only after a delay (and vice versa).
• Consider using read-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 outage of on-premises domain controllers. However, the security benefits of using an RODC over a regular domain controller are limited. If you disable password caching, a compromised RODC might only pose a limited risk to the rest of your Active Directory, but you lose the benefit of Google Cloud remaining unaffected by an outage of on-premises domain controllers.

In the extended forest pattern, you deploy a new Active Directory domain on Google Cloud, but integrate it into your existing forest. You use the new domain to manage any resources deployed on Google Cloud and to maintain a minimal set of administrative user accounts for managing 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 access resources managed by the Google Cloud-hosted Active Directory domain.

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

• Your intended use of Google Cloud fits one of the distributed deployment patterns, and a dependency between your on-premises environment and Google Cloud is acceptable.
• The resources you plan to deploy to Google Cloud require a different domain configuration or structure than your existing domains provide, or you want to grant a high level of administrative autonomy to teams who administer the Google Cloud-hosted domain.
• You expect moderate to heavy interaction between Active Directory–managed resources on-premises and on Google Cloud.
• You have many users who need to access resources deployed to Google Cloud—for example, to web applications that use IWA for authentication.

Advantages:

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

Best practices:

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

The resource forest with extended domain pattern is an extension of the resource forest pattern. The resource forest pattern lets you maintain a trust boundary between environments and providing administrative autonomy. A limitation of the resource forest is that its overall availability hinges on the availability of on-premises domain controllers and reliable network connectivity to your on-premises data center.

You can overcome these limitations by combining the resource forest pattern with the extended 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-hosted resources even when on-premises domain controllers are unavailable or network connectivity is lost.

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

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

Advantages:

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

Best practices:

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

• Find out more about Managed Microsoft AD.
• Review best practices for deploying an Active Directory resource forest on Google Cloud.
• Learn how to deploy a fault-tolerant Active Directory environment to Google Cloud.
• Review our best practices on VPC design.
• For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4