This article provides an overview of the Microsoft Active Directory (AD) requirements and configuration in a Remote Desktop Services (RDS) deployment created by the itopia Cloud Automation Stack (CAS).

itopia CAS provisions and manages RDS deployments in each customer's Google Cloud Platform (GCP) project. Microsoft RDS requires Active Directory and leverages it for several key functions.

At its core, Active Directory is an authentication mechanism for Windows environments. An Active Directory domain stores information about users, computers, groups, and other resources; other systems and services rely on Active Directory to authenticate credentials, store and access data, and enforce security controls.

Remote Desktop Services is dependent on Active Directory in order to maintain secure connectivity between the various servers and roles that are part of RDS, as well as to authenticate user sessions and authorize their access to resources such as file shares and printers. RDS cannot be deployed without Active Directory.

When creating a Remote Desktop Services deployment in itopia CAS, you have several options for fulfilling the Active Directory requirement; the option you choose depends on the level of integration-- or in some cases isolation-- that is desired for the CAS deployed environment.

The CAS Admin Portal (cas.itopia.com) allows administrators to perform common management tasks such as creating users and managing group membership. In a traditional environment, these tasks would be performed using Active Directory management tools such as the Active Directory Administrative Center or Active Directory Users and Computer.

In addition to these management tasks, CAS also performs "behind-the-scenes" AD management for managing user assignments to Collection Pools, adding or removing Session Hosts to the deployment, and assigning group policy objects (GPOs) to enforce various configuration options.

When creating a new CAS deployment, you have several options for the Active Directory requirement:

CAS deployments can create a "traditional" Active Directory domain (what Microsoft calls Active Directory Domain Services or AD DS). This option creates a new AD domain (and corresponding AD forest) using one or more GCP VM instances configured as domain controller servers.

The AD DS environment is unmanaged, meaning that you are responsible for the overall health of your domain environment, such as OS patching and security hardening policies. This option provides the greatest flexibility and freedom to configure your Active Directory environment as desired; CAS deploys a standards-compliant Active Directory domain and performs a minimal configuration to support the RDS deployment (and CAS administrative actions).

During the initial deployment configuration, you can specify a few options such as the domain name and the number of domain controllers to deploy in each geographic region. For business-critical deployments, itopia recommends deploying redundant domain controllers in each region to ensure robust availability of Active Directory services and protect against server failures.

Choose this for: CAS deployments that require a lot of flexibility, very advanced configurations, and/or a high level of isolation. New domains using AD DS do not impose any limitations or restrictions on the AD environment, and administrators have unfettered access to their domain controllers and the advanced configuration and customization of their AD environment.

Be aware that: New domains using AD DS are unmanaged, so AD security and stability are up to you. OS patching, security hardening, and CPU/RAM scaling must all be performed by your organization. New domains using AD DS are subject to the compute fees for GCP VM instances for domain controllers.

CAS deployments can also create a new Active Directory domain using GCP's Managed AD service, Google Managed Service for Microsoft Active Directory (Managed Microsoft AD). Managed Microsoft AD provides a simplified Active Directory administration experience by eliminating the need to manage domain controllers or their associated services, such as AD DNS.

With Managed Microsoft AD, a full Microsoft Active Directory instance is provisioned, configured, and updated by Google Cloud; your VMs use Google Cloud DNS to locate the Active Directory endpoints and connect to the domain controllers across your internal Virtual Private Cloud (VPC) network.

Although it can be used in many scenarios, Managed Microsoft AD is an ideal option for smaller CAS deployments that do not require the advanced capabilities of a full Microsoft Active Directory environment. Managed Microsoft AD delivers a pre-hardened Active Directory domain and standard administration tasks such as monitoring, patching, and upgrading are handled automatically by Google Cloud. It is well-suited for organizations that do not have an existing Active Directory and only wish to fulfill the AD requirements for Remote Desktop Services or other AD-integrated systems.

CAS deployments with Managed Microsoft AD can be configured to use an Active Directory trust (discussed below). There are some limitations with Managed Microsoft AD compared to a traditional (AD DS) Active Directory environment, but these limitations would not affect most common deployment scenarios.

For more information, refer to our Help Center article: RDS Deployments with Google Managed Service for Microsoft Active Directory

Choose this for: Deployments that do not have complex Active Directory requirements. Although Managed Microsoft AD offers most features of an AD DS domain, some differences exist and might interfere with very advanced configurations. However, in most scenarios Managed Microsoft AD provides a great, lower-cost option for quickly deploying AD using a secure, maintenance-free solution.

Be aware that: New domains using Managed Microsoft AD are subject to GCP fees for the managed service, as well as for a lightweight "bastion" VM instance that is created to allow CAS to manage the AD domain.

CAS can leverage an existing Active Directory domain for the RDS deployment. In this scenario, you would establish network connectivity from the new CAS deployment to your existing AD domain (either in GCP via VPC peering or on-premises via a VPN or interconnect) and provide CAS with administrator credentials and preferred domain controllers for the domain; CAS will then configure RDS and other servers to use the specified domain controllers for Active Directory services.

With Existing Active Directory, you continue to manage your Active Directory environment as you normally do; CAS can import existing users and groups from your domain and the users log in to their Cloud Desktops with their existing AD credentials.

Choose this for: The most integration with your existing environment. CAS creates all resources (users, groups, organizational units [OUs], and GPOs) in your existing domain, allowing you to manage many aspects of the deployment like other systems in your environment. CAS does not modify your Active Directory topology, allowing you to manually define your AD site topology and domain controller placement. This is a good option if you already have adequate Active Directory infrastructure in the same (or nearby) GCP regions as your CAS deployment.

Be aware that: Using Active Directory domain controllers that are located on-premises requires a fast, low-latency, and reliable connection between GCP and your on-premises or co-located network. For business-critical applications, it is recommended to have redundant VPN tunnels or a Cloud Interconnect with adequate bandwidth; for more information refer to Choosing a Network Connectivity Product. Similarly, when using domain controllers located on a peered VPC network within Google Cloud, itopia recommends using domain controllers within the same GCP region.

For multi-region CAS deployments, itopia recommends configuring your network topology and Active Directory sites configuration to allow each region to access the closest domain controllers using the most direct route possible.

If these requirements cannot be met, itopia recommends using the Extended Active Directory option to deploy additional domain controllers specifically for the CAS RDS infrastructure.

Using an AD trust is not supported in Extended AD deployments.

CAS can leverage an existing Active Directory domain for the RDS deployment. In this scenario, you would establish network connectivity from the new CAS deployment to your existing AD domain (either in GCP via VPC peering or on-premises via a VPN or interconnect) and provide CAS with administrator credentials for the domain; CAS will deploy additional domain controllers for this domain (to ensure good connectivity) and update the AD site topology to include each GCP region that is part of the CAS deployment.

With Extended Active Directory, you continue to manage your Active Directory environment as you normally do; CAS can import existing users and groups from your domain and the users log in to their Cloud Desktops with their existing AD credentials.

Choose this for: The most integration with your existing environment. CAS creates all resources (users, groups, organizational units [OUs], and GPOs) in your existing domain, allowing you to manage many aspects of the deployment like other systems in your environment. Some customers might choose this option when they want to migrate their Active Directory Infrastructure on to Google Cloud Compute Engine.

Be aware that: Extended AD promotes additional domain controllers and modifies your AD site topology to support the GCP regions that are part of your deployment. Using an AD trust is not supported in Extended AD deployments.

Deployments created using either of the "New Domain" options (AD DS or Managed Microsoft AD) can be configured to support an Active Directory trust for accessing user and group accounts in an existing AD domain.

This model creates a new Active Directory domain as described above; an administrator then configures an AD trust between the new domain and an existing domain, and CAS is then configured to read user and group objects from the trusted domain. CAS resources are maintained in the new Active Directory domain, but user and group resources can be read from the trusted domain, allowing users to leverage a single identity and credentials across the organization.

NOTE: itopia CAS does not create or configure the AD trust. Because creating a trust is a "security sensitive" operation, the trust must be configured by an administrator using native Active Directory tools. Once the trust has been created, the administrator can enable Trust support in CAS.

CAS deployments support two-way and one-way trusts and does not require elevated permissions in the trusted domain. All CAS operations in the trusted domain are read-only; users and groups cannot be created from the CAS console in the trusted domain, only imported. Users and groups can still be created in the new domain from the CAS console.

The Trusted AD model requires reliable network connectivity between the CAS environment and trusted Active Directory using either VPC peering (if the trusted domain has domain controllers in Google Cloud) or a VPN or Dedicated Interconnect (if the trusted domain is outside of Google Cloud). This model provides a good balance between integration and isolation.

AD models with deeper integration provide greater convenience, whereas models with more isolation have the potential to provide stronger security. Administrators should evaluate the implications of each model for their specific organization and make a decision prior to creating the CAS deployment.

Learn more about using AD trusts in a CAS deployment: Support for AD Trusts in CAS Deployments.

Regardless of the Active Directory option you choose, CAS will create several objects in the Active Directory domain in order to manage the deployment:

Active Directory is a hierarchical directory system that allows administrators to create a structure of cascading sub-objects for security and logical organization. The security hierarchy consists of the AD forest, domains, and security groups; the logical hierarchy consists of AD sites, container objects, and groups.

The most common container object type is an organizational unit (OU). OUs allow administrators to arrange objects in a way that resembles the organization's structure in managerial or geographical terms, or with whatever other criteria is necessary.

CAS deploys one organizational unit (OU) in the root of the AD domain and creates a sub-OU structure beneath this OU. The root OU is named based on the deployment code and deployment name in the CAS console and contains computer accounts, security groups, and end-user accounts as provisioned in the CAS console.

Group Policy Objects
​
In Active Directory, group policy objects (GPOs) are used to define and enforce various settings on computers and user accounts in the domain. GPOs can define security controls, settings for the operating system and supported software, and user experience customizations.

In each deployment, CAS creates a set of GPOs that define various settings for the RDS environment; these GPOs are assigned only to the OUs and sub-OUs created by CAS and only affect the resources created by CAS. When certain settings are configured in CAS, CAS may link or unlink GPOs to the appropriate OU to enforce those settings on the resources in the deployment.

You can create additional GPOs in your Active Directory environment to enforce certain settings in the RDS environment as long as the settings do not interfere with RDS functionality. For example, certain GPOs that enforce very strict security parameters may disrupt CAS management connectivity or end-user authentication. Any manual changes to the RDS environment should be performed in a controlled manner, with each individual change being fully tested before being applied to the production environment.

It is not supported to manually edit the GPOs created by CAS; while it may be possible to do so, CAS is unaware of any modifications and this may result in unintended consequences when CAS links or unlinks GPOs as part of regular administration.

Customers can also bring their own GPOs to their CAS deployment by specifying these GPOs during deployment. Learn more about this feature here. 

When creating and managing an RDS deployment, itopia CAS provisions a set of service accounts within the AD domain. These accounts are used to perform various administrative functions within the operating system (OS), AD domain, and the RDS environment. These accounts, referred to as itoadmin accounts, are created in the default “Users” container of the Active Directory (AD) domain in each CAS deployment.

The service accounts are programmatically generated and used by the itopia Proxy Execution Service (PES) using the unique deployment key stored in Google Cloud KMS (see this section for more details). The accounts' credentials are encrypted and periodically rotated in accordance with itopia's Key Vault design.

Details about the service accounts created by CAS are provided here: Service Accounts used by itopia CAS.