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.
Active Directory Options in a CAS Deployment
When creating a new CAS deployment, you have several options for fulfilling the Active Directory requirement:
- Create a new Active Directory domain (and corresponding forest) and use AD accounts in that domain
- Create a new Active Directory domain (and corresponding forest) and use AD accounts in an existing domain using an AD trust
- Use an existing Active Directory domain and extend it to the CAS deployment in GCP
New Domain - Active Directory Domain Services
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.
New Domain - Google Managed Service for Microsoft Active Directory
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.
Extended Active Directory
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.
Trusted Active Directory
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.
Security & Compliance
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.
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.
Compatible Third-Party Solutions
itopia implicitly supports any third-party MFA solution designed for Microsoft RDS. The solutions below are commonly implemented by our customers in CAS deployments and have been verified by itopia.
Azure Multi-Factor Authentication
Microsoft Azure MFA supports integration with the RD Gateway role. End-users can be verified using many methods supported by Azure MFA including push notifications, one-time passcodes (OTP) and device compliance policies for Intune-managed devices.
Duo offers two different MFA models for RDS: the RD Gateway option supports a limited number of MFA challenges but offers slightly greater security, whereas the Windows Credential Provider option supports all MFA challenges provided by Duo but allows the user connection to reach the Session Host before the MFA challenge is validated.
Okta offers a Windows Credential Provider plugin that can perform an MFA challenge before the user is authenticated to their Cloud Desktop.
Additional third-party solutions
RDS environments can support many other MFA products, many of which may be offered as Windows Credential Provider plugins. The RD Gateway role can also integrate with many RADIUS-compatible systems for performing compliance scanning on client devices.For more information, refer to the documentation for your specific MFA provider
Service Account Hardening
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.
Can I integrate an itopia deployment with Azure AD?
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.
What AD data does itopia CAS store?
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.
Are AD objects synchronized in an AD Trust?
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.
How can I grant CAS the least amount of access to my AD environment?
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.
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.