Microsoft Active Directory (AD) trusts enable one AD domain to be granted access to the resources (users, groups and computers) in another AD domain.

In itopia CAS, AD trusts can be used to enable users in an existing AD forest to quickly and easily access their Cloud Desktops with their existing corporate credentials (username + password).

Using the AD trust model, the Cloud Desktop environment can be deployed in a separate environment with minimal impact to your existing infrastructure, but Cloud Desktop users can access their resources (such as file and application servers) using the same credentials that they use for other resources.

AD Trust Model Overview

CAS support for AD trusts allows administrators to create a new CAS deployment using a standalone AD domain, using either Google Managed Service for Microsoft Active Directory or a traditional Windows Active Directory. After the initial deployment is created, the administrator will establish connectivity to their existing Active Directory domain and will build a standard Active Directory trust. We recommend a two-way non-transitive trust, but one-way trusts are supported as well (configured as an outgoing trust from the new Cloud Desktop domain).

Once the trust is established, you can import existing user accounts into CAS; CAS does not store any sensitive information about the accounts such as passwords or AD attributes. These imported users can then be managed through CAS and assigned to Collection Pools to access Cloud Desktop resources.

Considerations for AD Trust Model

In discussing this model we will use the standard terms to reference each domain:

  • Resource Domain - This is the new AD domain that will contain the Cloud Desktop servers
  • Accounts Domain - This is your existing AD domain that contains the user accounts that will authenticate to Cloud Desktop

When creating a new deployment with an AD trust, it is important to consider the following:

  • The new Cloud Desktop domain parameters must be unique - the domain name and UPN suffix you provide for the resource domain must not conflict with your account domain, or with any other domains with which your account domain has a trust. For example, if your accounts domain is named "contoso.com" and your users have a UPN suffix of "contoso.com", do not use these values for the resource domain you configure in CAS. Active Directory trusts cannot properly route authentication requests if domain names and UPN suffixes are not unique.
  • Resources in the accounts domain are not modified - CAS does not perform any "write" operations in the accounts domain. Users and groups are read into the CAS database and then they are added to a Collection Pool, their corresponding shadow principal in the resource domain is added to the appropriate AD groups in the resource domain. Therefore, trusted user information cannot be modified in the CAS console, and deleting users in the CAS console does not affect the user account in the accounts domain

Security and Sensitive Data

The Trusted AD model accesses a minimum amount of information in your accounts domain. CAS itself does not read or access any information in the accounts domain except when users or groups are being added to the deployment from the CAS console; when users or groups are added, CAS performs an AD query only in the OUs specified by an administrator in the AD Trust configuration (discussed below). CAS does not store any sensitive information or passwords for the user in the CAS database; only the user's first name, last name, and account name (username) are stored by CAS.

Similarly, with an AD trust, the resource domain does not "replicate" any sensitive information about users or groups from the accounts domain. Whenever a security principal (such as a user or security group) from the accounts domain is assigned to a resource in the resource domain, the resource domain creates a shadow principal that is effectively a "pointer record" to the object in the accounts domain. This shadow principal includes only the username and the distinguished name (DN) of the corresponding object in the accounts domain.

Administrators should understand Active Directory trusts and their security implications prior to implementing this solution for a CAS deployment. Although the Trusted AD model is designed to offer strong security while enabling access to an existing Active Directory domain, any AD trust is nevertheless an extension of an organization's security boundary and should be carefully planned to ensure best practices are followed.

Globally Unique UPN Suffixes

AD Trusts enable a deployment to have more than one UPN suffix. The deployment will support UPNs from the accounts domain as well as any users created directly in the CAS console. However, all UPNs in a deployment must be globally unique across CAS; this means that two deployments or two organizations cannot use the same UPN suffix, regardless of whether the suffix is for a resource domain or an accounts domain.

Configuring an AD Trust

During the initial deployment creation, an administrator selects one of these two Active Directory options to serve as the resource domain:

  • Create New Active Directory Domain
  • New Google Managed Service for Microsoft Active Directory instance

The remainder of the CAS deployment is configured as normal.

Once the deployment is finished provisioning, the administrator establishes network connectivity from the new Cloud Desktop environment in Google Cloud with their existing domain. Cloud Desktop resources are deployed into a unique VPC network within your GCP project; connectivity to the existing domain may require VPC peering (if the account domain's domain controllers are in Google Cloud) or a VPN tunnel (if the account domain's domain controllers are on-premises). For resiliency, we recommend that you deploy and maintain at least two domain controllers for your accounts domain in Google Cloud.

Next, firewalls must be configured to permit the necessary traffic between the domains. Refer to this Microsoft article for guidance on the necessary connectivity to support AD trusts.

With network connectivity established, the administrator then configures an Active Directory trust between the Cloud Desktop domain (resource domain) and their existing AD domain (accounts domain). For most scenarios, a two-way forest trust is the preferred configuration method; however, if a one-way trust must be used for security reasons, configure an outbound trust from the resource domain to the accounts domain.

With the AD trust created and validated, you can then configure your CAS deployment to use the trust. From your deployment's Dashboard, click the "cog" icon to access the Deployment Settings.

Scroll to the AD Trust section and configure the following parameters:

  • The fully qualified domain name (FQDN) of the accounts domain (e.g., contoso.com)
  • The FQDN of the preferred domain controller in the accounts domain (e.g. srv-gcp-dc01.contoso.com)
  • The distinguished name of the OUs or containers in the accounts domain for querying users and groups (e.g. OU=users,OU=corporate,DC=contoso,DC=com). If you have users in multiple OU structures, you can specify the root of the domain (e.g. DC=contoso,DC=com)
  • The UPN suffixes used by user accounts in the accounts domain. CAS uses UPN suffixes to identify the correct deployment for users when they access the MyRDP portal (myrdp.download). Thus, any UPNs that your users will have must be associated with your specific CAS deployment
  • Service account credentials for a user account in the accounts domain. This account requires no special permissions in the accounts domain other than "Domain Users" membership. It is used to perform read-only operations.

Hybrid Scenario (User Accounts in Accounts Domain and Resource Domain)

When using the Trusted AD model, users and groups can still be created in the itopia CAS domain (i.e., the resource domain). Any users that are created from the CAS console will be created in the resource domain and they will use the UPN suffix of the resource domain. These users and groups can coexist side-by-side with the imported users and groups.

Current Limitations

  • Users from the trusted domain cannot be added to shares or mapped drives in the Folders/Shares Module. The module will only display users from the Resource domain. This will be addressed in a future release.
  • Currently, there is no clear visual representation of whether a user is created in the Resource domain or is imported from the Account domain. Administrators can determine whether a user is from the local domain or the trusted domain based on the user's UPN suffix. The User Module will be updated to reflect this information in a future release.
  • Changes to user information in the accounts domain will not be reflected in the CAS console. For example, if a user's surname is changed in the accounts domain, that change will not be detected by CAS. CAS only reads user attributes when they are first imported into the console. However, because the user is accessing their Cloud Desktop using the actual account from the accounts domain, this change will be reflected in their Cloud Desktop; it is only the CAS console which will not be updated. If it is necessary for this information to be updated in the CAS console, the user may be deleted from CAS, re-imported, and assigned to the same Collection Pool; their Cloud Desktop will not be affected by this action.
  • In a future release, itopia CAS will gain support for auto-importing users from Active Directory on a scheduled basis. Administrators will be able to specify one or more AD groups, and the groups' members will be periodically imported into CAS and assigned to their corresponding Collection Pools. This feature will support AD trusts as well as standard deployments.

Related Articles

Active Directory in CAS

AD DNS Name

Using RDS Deployments with Google Managed Service for Microsoft Active Directory

Importing Users from local AD to an Extended AD in itopia + GCP

Did this answer your question?