This article provides an overview of the Microsoft Active Directory (AD) requirements and configuration in a Remote Desktop Services (RDS) or Windows 10 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.

When creating a new CAS deployment, you have several options for fulfilling 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 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.

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 the Existing Active Directory option without extending the domain into your CAS deployment requires fast, reliable connectivity to your existing AD domain controllers. itopia strongly recommends that your AD domain has domain controllers in the same GCP regions as your CAS deployment. If you do not have domain controllers in GCP, it is possible to use a redundant VPN or Direct Interconnect to your on-premises environment that contains your domain controllers; however, this scenario may encounter unexpected behavior if connectivity is interrupted or has low bandwidth or high latency.

Extended Active Directory is similar to the Existing Active Directory option, except that CAS will deploy additional Active Directory domain controllers into your CAS environment for each GCP region. This ensures reliable, performant connectivity between your Cloud Desktop and Active Directory.

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.

CAS deployments require a two-way trust; one-way trusts are not supported due to limitations of the RD Gateway role. CAS does not require any 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.

itopia protects the security of AD accounts by ensuring the passwords for each is a minimum of 8 characters, sufficiently complex (a combination of uppercase, lowercase, numbers, and special characters). In addition, the service accounts (itoadmin) used by CAS for orchestration of the deployments rotates passwords every 90 days using cryptographically-generated passwords that rely on Google KMS for storage and use.

itopia CAS deployments are compatible with a number of third-party multi-factor authentication (MFA) solutions. Depending on the specific product, these solutions may be implemented in slightly different ways; however, most options "hold" the end-user's connection until an MFA verification occurs, at which time the connection is authorized in RDS and the user can continue to login to their Cloud Desktop.

For more information, refer to Using Third-Party Multi-Factor Authentication (MFA) with CAS Deployments

When creating and managing a Remote Desktop Services (RDS) deployment, itopia CAS provisions a set of service accounts within the Active Directory (AD) domain. These accounts are used to support various administrative functions of the operating system , Active Directory domain, and RDS infrastructure.

The service accounts are programmatically generated for each CAS deployment. The accounts' credentials are encrypted and periodically rotated leveraging the Google Cloud Key Management System.

The service accounts are implemented using the principle of least privilege. These accounts only have the limited AD access/permissions required to perform their specific functions, and the least-privileged account is used to perform each specific task.

The CAS admin console provides a comprehensive audit log of all administrator actions performed within the console, including logons, user creation, and deployment configuration changes. Additionally, the CAS console provides an audit log of all Active Directory actions performed by the itoadmin service accounts. These logs are enabled by default and cannot be cleared or disabled by administrators.

The Active Directory domain used for your deployment can be synchronized with Microsoft Azure AD using Azure AD Connect. Users will still authenticate to their Cloud Desktop using their Active Directory credentials, but advanced features such as Azure MFA can be enabled for additional security when the domain is synchronized.

Despite its name, Azure AD is not an Active Directory domain and does not fulfill the AD requirement for RDS on its own. Your CAS deployment must use one of the AD options described above, but additional integration with Azure AD is possible.

CAS maintains a secure, encrypted backend database that contains records that correspond to the users, groups, and servers in the deployment. These records contain a minimal set of metadata and have no security information such as passwords; they are essentially a "pointer" record to the authoritative object in Active Directory.

When a user or group is created (or imported) in CAS, CAS stores basic metadata like the first name, last name, email address, and AD object ID (i.e. username). No additional attributes are stored in the CAS database, including AD passwords or credentials.

No, objects are not synchronized in any meaningful way. When a trust is established, users in Domain A can be assigned permissions to resources in Domain B. When this happens, Domain B creates a "pointer record" to the user object in Domain A and uses that record when setting permissions. When a user tries to access that resource, AD looks at the pointer record, follows it across the secure trust to the object in Domain A, and then passes along the user's credentials to Domain A for authentication; if authentication is successful, Domain B is notified and the user is granted access to the resource.

The pointer record contains a minimal set of metadata to allow Domain B to locate the object in Domain A. No attributes are copied or synced, and passwords are not stored in Domain B; Domain A is always responsible for authentication.

Depending on the AD model you choose for your deployment, you can further reduce CAS' access to the AD environment as follows:

New Domain (Active Directory Domain Services)

The highest-privileged service account, itoadmin, is only used during the initial creation of the environment. Once the deployment is created, this account can be disabled or deleted.

The secondary account itoadmin04 is required only for adding or removing regions in a deployment (in order to create/delete the corresponding AD sites). You may disable the account during normal operations and re-enable it when needed.

The remaining service accounts are tightly-scoped and are configured with the least permissions required to perform their functions.

New Domain (Managed Microsoft AD)

Google's Managed Service for Microsoft Active Directory (Managed Microsoft AD) is hardened by default, and highly-privileged accounts such as Enterprise Admins and Domain Admins are not available. The CAS service accounts use the Cloud Service Administrator group to perform AD administration tasks.

Extended Active Directory

Similar to the configuration for new domains, CAS provisions several service accounts. The highest-privileged of these accounts, itoadmin and itoadmin04, can be deleted or disabled once the environment is provisioned.

Domain Admin permissions are required for the ongoing management of users, security groups, OUs, and GPOs.

Trusted AD

Using the Active Directory trust model, CAS requires the least amount of permissions in your existing AD. Within the new domain that is created, CAS creates service accounts as described above. Within the trusted domain (i.e. your existing domain that contains your user accounts), CAS requires either no permissions (with a two-way trust) or a single service account with Domain Users membership to perform read-only operations.

In a Trusted AD, the service account is only used to query users and groups to be imported into CAS. CAS only queries the organizational units (OUs) you specify as part of the trust configuration in the CAS console.