External Domain Names

This article explains how CAS configures external domain names for RDS deployments and how to configure customer-owned domain names.

Reisbel Machado avatar
Written by Reisbel Machado
Updated over a week ago

Overview

When an RDS deployment is created in CAS, CAS assigns the deployment with a default external domain name for each region in the deployment. The external domain name is how users will connect to their Cloud Desktops and administrators to the RDS infrastructure. The external domain name of each region points to the public interface of the RD Gateway in that region, or to the public interface of the GCP load balancer if redundant RD Gateways are deployed.

This default external domain name is created as a subdomain of cloudvdi.net. The naming convention is as follows:

  • In a single-region deployment, the external domain name is <Deployment ID>.cloudvdi.net

  • In a multi-region deployment, the external domain name is <Deployment ID>-<GCP Region>.cloudvdi.net

For example, a single-region CAS deployment with Deployment ID "ibo" would have an External Domain Name of ibo.cloudvdi.net. If the deployment were multi-region in the GCP regions us-east1 and europe-west4, the External Domain Names would be ibo-us-east1.cloudvdi.net and ibo-europe-west4.cloudvdi.net.

CAS creates the DNS A record(s) for this external domain name to point to the RD Gateway or RD Gateway load balancer in each region. CAS also imports and configures the SSL certificates that are required in order to encrypt the connection between the user’s end-point and their Cloud Desktop. These SSL certificates are automatically renewed and maintained by itopia at no additional cost to the customer.

Using Custom External Domain Names

After an RDS deployment is created, a CAS administrator can change the external domain name for each region to a custom value. For example, a multi-region deployment could be configured as remote.contoso.com and remote-backup.contoso.com, or even as remote.contoso.com and remote.fabrikam.com.

Prerequisites

When configuring a custom external domain name, you will need the following:

  • Approximately 10-15 minutes of downtime, during which users cannot connect to their Cloud Desktop, and existing connections may be disconnected

  • A public DNS domain your organization owns

  • Access to create DNS A records in your domain

  • Server names for each region

  • An SSL certificate for the External Domain Names in PFX format. See additional information on certificate requirements below.

SSL Certificate Requirements

The type of SSL certificate depends on your deployment and the external domain names you are configuring:

  • For a single-region deployment, a standard "single-subject" SSL certificate is adequate, with the subject matching the External Domain Name you have chosen for your deployment such as remote.contoso.com

  • For a multi-region deployment where all regions will use the same DNS domain, a wildcard or subject alternative name (SAN) certificate can be used. For example, if all regions will use external domain names in the contoso.com domain, you may either use a wildcard certificate for *.contoso.com or a SAN certificate with the specific external domain name for each region, such as remote-us-east.contoso.com, remote-us-west.contoso.com, remote-europe.contoso.com

  • For a multi-region deployment where regions will use different DNS domains, a subject alternative name (SAN) certificate can be used. For example, if your chosen external domain names are remote.contoso-us.com and remote.contoso-europe.com, you can use a SAN certificate with each of these names explicitly defined as either the subject or a subject alternative name.

In every scenario above, you must upload the certificate separately for each region; you could therefore use different SSL certificates for each region, rather than using wildcard or SAN certificates. For ease of management, itopia recommends using a single certificate for all regions, but this is not required.

itopia recommends using the newer ECC SSL certificate type rather than RSA SSL certificates; ECC is a newer algorithm that is more secure and more efficient. However, very old operating systems such as Windows XP and Windows Server 2003 do not support ECC; if you may have end-users connecting from older operating systems (10+ years), you should continue to use RSA certificates. itopia recommends a minimum RSA-2048 or ECC-256 certificate.

NOTE: Remember that wildcard SSL certificates do not apply to subdomains. For example, a wildcard certificate for *.contoso.com WILL NOT be valid for remote.us.contoso.com and remote.europe.contoso.com. This is an inherent and intended limitation of SSL certificates.

Configure a Custom External Domain Name

  1. Log into the CAS portal (cas.itopia.com) as a Deployment Editor or Owner.

  2. Go to the deployment’s Dashboard.

  3. In the bottom-left section of the Dashboard, click the ⚙️Settings Module.

  4. Select Regions and click on your desired region.

  5. In the External DNS Name field, enter your chosen custom name.

  6. Copy the External IP Address value. You will need this value to create the DNS A record later.

  7. Click Upload and locate your SSL certificate on your local device.

  8. A new Password field will appear. Enter the SSL certificate password.

  9. Click Save.

  10. Create a DNS A record in your public DNS zone for your chosen domain name. The A record should point to the IP address you noted in Step 6.

  11. Repeat this process for other regions as desired.

CAS will begin updating the configuration for that region, resulting in approximately 5-15 minutes of service disruption; this may be longer if your new DNS records require time to propagate across public DNS servers around the world. If any failures occur, the CAS admin will be notified in the Notifications module in the CAS portal.

Important!

If any users had saved their RDP connection file prior to this change, the settings in those files will continue to point to the prior External Domain Name (cloudvdi.net) which will no longer exist. Please make sure that after changing the deployment's external domain names, users download new RDP connection files at myrdp.download.

Did this answer your question?