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. itopia CAS deployments require a two-way Active Directory trust.
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, use the information in Creating an Active Directory Trust to establish a two-way trust between your deployment's AD domain and your existing accounts domain.
NOTE: Because AD trusts are an important security control, CAS does not perform the creation or configuration of the Active Directory trust. Administrators must configure the AD trust using native Active Directory management tools.
With the AD trust created and validated, you can then configure your CAS deployment to use the trust.
From your deployment's Dashboard, use the left-hand menu to navigate to Settings > Active Directory.
In the Active Directory Trust section, enable the setting This deployment uses an Active Directory trust. CAS will query your deployment's AD domain to detect any compatible trusts that are configured. If compatible trusts are found, configure the following settings:
Select the Trusted domain from the drop-down menu
Optionally, Preferred Domain Controller FQDN in the accounts domain (e.g. srv-gcp-dc01.contoso.com). CAS will attempt to use this domain controller for reading data in the trusted domain; if the domain controller is unavailable, CAS will attempt to use any available domain controller.
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 Cloud VDI Portal. Thus, any UPNs that your users will have must be associated with your specific CAS deployment
The Users OU and Groups OU 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)
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
The Trusted AD Model in itopia CAS requires a two-way trust. Due to a limitation of the RD Gateway role, one-way trusts are not supported.
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.