Since itopia WorkAnywhere automates the provisioning of Microsoft Remote Desktop Services (RDS) in the Google Cloud, customers can leverage Microsoft technologies and tools such as Active Directory.
Overview
An Active Directory trust (AD trust) is a method of connecting two distinct Active Directory domains (or forests) to allow users in one domain to authenticate against resources in the other. In simplest terms, it is the process of extending the security boundary of an AD domain (or forest) to include another AD domain (or forest).
There are multiple parameters to configuring an Active Directory trust that will not be discussed in this article; itopia recommends that administrators research AD trusts to gain a full understanding of their impact and implications before proceeding. Concepts like transitivity, implicit trusts, SID filtering, and scoping are not covered in this article but are important aspects of defining the impact of a trust relationship.
It is important to understand several terms that will be used in this article:
Resource Domain - This is the AD domain that contains the resources users need to access. In the context of itopia, this is the new domain that is created by CAS that contains the Cloud Desktop servers. This is often called the "trusting" domain.
Accounts Domain - This is the AD domain that contains the user accounts with which users log in. In the context of itopia, this your existing AD domain that contains the user accounts that will authenticate to Cloud Desktop. This is often called the "trusted" domain.
Directional Trusts
AD trusts relationships are directional; a trust can be configured as a one-way or two-way trust. In a one-way trust, one domain is specified as the Accounts domain and the other is the Resource domain; in Microsoft's confusing terminology, the trust is incoming to the Accounts domain and outgoing from the Resource domain. A two-way trust is effectively two one-way trusts; each domain is configured as both the Accounts domain and the Resource domain, so users in either domain can access resources in the other domain.
NOTE: It is important to understand that the phrase "can access resources" does not mean that Accounts users have any implicit access to the resources in the trusting (Resource) domain; it is more accurate to say that Accounts users "can be granted access to resources" in the Resource domain.
Prerequisites for Establishing an AD Trust
In order to create an AD trust between two Active Directory domain, the following requirements must be satisfied:
Network Connectivity - domain controllers from each domain must be able to communicate with one another. Servers and other resources in the Resource domain must also be able to communicate with the domain controllers in the Accounts domain
DNS Name Resolution - domain controllers from each domain must be able to resolve DNS records for the other domain's AD environment
Accounts Domain Service Account - an AD user account in the Accounts domain is required so that itopia CAS can read user and group objects in that domain. This is required for one-way trusts; for two-way trusts, implicit read-only access is provided by default and a service account is not required. The service account does not require any special permissions; it simply needs to be a member of the Domain Users group in the Accounts domain.
Network Connectivity
To support the AD trust, the domain controllers in each domain must be able to communicate over a number of network ports. For Cloud Desktop, this requires:
Creating a VPC peering (if your Accounts domain has domain controllers in Google Cloud) or a VPN or Interconnect (if your Accounts domain only has domain controllers outside of Google Cloud). Refer to Google Cloud documentation for detailed instructions on these processes.
Configuring firewall rules to permit AD traffic between the Accounts domain and the Resource domain. These rules typically need to be configured in multiple places: on the VPC network for your Cloud Desktop environment and on the VPC network (or the firewall for on-premises environments) that contains the domain controllers for the Accounts domain. Refer to Google Cloud documentation and/or your firewall vendor's documentation for instructions on these processes.
The table below provides the minimum network ports that are required for Active Directory trust functionality. Additional information is available in Microsoft's documentation.
DNS Name Resolution
Once network connectivity has been established, both Active Directory domains must be configured with DNS forwarding rules so that they can access each other's Active Directory DNS records.
The most common way to achieve this is to create conditional forwarders for each domain's FQDN on the other domain's DNS servers. Consider the following example:
The Resource domain is contoso.local and has two AD domain controllers / DNS servers with the IPs 10.0.1.10 and 10.0.1.11
The Accounts domain is fabrikam.local and has two AD domain controllers / DNS servers with the IPs 192.168.1.10 and 192.168.1.11
Once network connectivity is established between these two domains (as described above), an administrator for each domain would configure the following:
On the DNS servers for contoso.local, create a conditional forwarder for the domain fabrikam.local that points to 192.168.1.10 and 192.168.1.11
On the DNS servers for fabrikam.local, create a conditional forwarder for the domain contoso.local that points to 10.0.1.10 and 10.0.1.11
To create a conditional forwarder:
Open the DNS Manager utility on your DNS server
Expand the DNS server name, and select the Conditional Forwarders menu item.
Right-click and select New Conditional Forwarder
For DNS Domain, specify the FQDN of the other AD domain. For IP addresses, provide at least one IP address of a DNS server for the other domain
For simplicity, it is recommended to enable Store this conditional forwarder in Active Directory; otherwise, you will need to create the forwarder locally on each DNS server.
Save the forwarder.
NOTE: There are other methods of establishing DNS name resolution between domains, and in some cases these other methods may be necessary. For example, if one domain resides behind a Network Address Translation (NAT) interface, the IP addresses returned by its DNS servers will not match the IPs that the other domain must use to communicate. In this scenario, you would need to create a DNS zone for the other domain's FQDN, manually create DNS A records for the domain controllers (and the domain name itself) using the NAT IP addresses, and then delegate the _msdcs.<domain FQDN> subdomain to the domain controllers in the other domain.
Creating an AD Trust
Once the prerequisites have been established and verified, you can proceed to create an AD trust. As mentioned at the beginning of this article, there are several important security decisions that must be made prior to creating a trust, and analysis of these decisions is beyond the scope of this article. itopia recommends that you research and understand AD trusts before proceeding.
In the example below, we will configure the following:
Resource domain: contoso.local
Accounts domain: fabrikam.local
Trust type: One-way, non-transitive
We will initiate the trust creation from the Resource domain (contoso.local) and configure the New Trust Wizard to create the trust in both domains; if this is not possible in your environment, you can run the New Trust Wizard separately in each domain and configure it not to create the trust in the other domain.
Log into a domain controller in the Resource domain contoso.local using an account that is a member of the Domain Admins group.
Open the Active Directory Domains and Trusts utility.
Expand the left-hand tree menu, right-click the object representing the domain contoso.local, and select Properties.
Navigate to the Trusts tab and click New Trust
Proceed through the New Trust Wizard.
For Trust Name, provide the FQDN of the Accounts domain, fabrikam.local
For Trust Type, select External trust; this means the trust is only for the two domains being configured. If contoso.local or fabrikam.local had any child domains, they would not be able to use this trust and would need to create their own trusts.
For Direction of Trust, select Two-way. This will configure both an incoming and an outgoing trust in each of the Account and Resource domains.
For Sides of Trust, select Both this domain and the specified domain. This will create the trust configuration in both domains at the same time. If you do not have Domain Admins credentials for the other domain, you can select This domain only and then run the New Trust Wizard at a later time to complete the trust. Note that if you do this, you would reverse the configuration values to provide the FQDN of the Resource domain and you would select One-way: incoming.
For User Name and Password, provide the credential for an account with Domain Admins membership in the Accounts domain.
For Outgoing Trust Authentication Level - Local Domain, select Domain-wide authentication. This greatly simplifies the permission configuration.
For Outgoing Trust Authentication Level - Specified Domain, select Domain-wide authentication. This greatly simplifies the permission configuration. NOTE: If greater security is required, Selective authentication can be enabled for this setting. Contact itopia support for more information.
On the Trust Selections Complete screen, review the configuration summary and click Next.
On the Trust Creation Complete screen, review the status to ensure the trust was created successfully and click Next.
For Confirm Outgoing Trust, select Yes, confirm the outgoing trust.
For Confirm Incoming Trust, select Yes, confirm the incoming trust.
On the Completing the New Trust Wizard, review the status to ensure the trust was successfully confirmed. Click Finish.
If you see a pop-up message that SID filtering is enabled, you may safely discard this message. SID filtering is a default security measure that will not affect the trust functionality for Cloud Desktops.
Summary
This article provides a basic overview of the steps to create a simple Active Directory trust. The process defined above may not be suitable for every environment; it is important to understand the implications of an AD trust and to confer with your Security and Directory teams before deciding on the trust configuration that is appropriate for your environment.