The following diagram illustrates the RAS user connection flow through Tenant Broker:
Shared RAS Secure Gateways installed in Tenant Broker are able to work with multiple concurrent user sessions in multiple Tenant farms. On the diagram above, you can see two users (1 and 2) connecting to different Tenant Farms (Tenant 1 Farm and Tenant 2 Farm). Both connections are tunneled through the same Gateway and then delivered to the correct Tenant Farm.
The connection flow consists of the following steps:
(1A), (2A) — A user initiates a RAS connection to a public address registered in the Tenant Broker. The (1A) connection goes to the Tenant 1 public address; the (2A) connection goes to the Tenant 2 public address.
(1B), (1C) — The shared Gateway makes a decision where to forward a user connection based on a hostname used in the initial connection (1A, 2A). After that each client establishes a RAS session with a Connection Broker of their respective Tenant Farm. Tenant's Connection Broker authenticates the user against Active Directory of the Tenant. After that, the user receives the list of published applications available to him or her.
(1D), (2D) — A user start a Remote User Session to a published application. The shared Gateway requests from Tenant's Connection Broker an address of a server to forward the remote session to and forwards it.
The mapping of public addresses to Tenants is configured on shared Gateways by the Tenant Broker Connection Broker.
The following is an implementation overview of the RAS multi-tenant architecture:
Tenants are deployed as separate individual Farms or Sites. Tenants deployed as separate Farms are completely independent and never communicate with each other. If tenants are deployed as Sites, every Site must join the Tenant Broker separately.
Shared resources include RAS Secure Gateways (including User Portal) and High Availability Load Balancers (HALB).
A Tenant Farm doesn't need its own RAS Secure Gateways and HALB. However, deployments with Gateways and HALB are possible if you need them for internal connections. For example, if you have different policies for internal and external connections, you might want to install a Gateway and HALB to serve local users.
The network configuration of a Tenant requires the Tenant Connection Broker to Tenant Broker Connection Broker connectivity. Additionally, shared RAS Secure Gateways need to communicate with servers hosting published resources and the Tenant's Connection Broker. Depending on the implemented network architecture, it might require a VLAN to VLAN connectivity, VPN, etc. These communications require only a limited number of open ports. For the complete list, see Communication ports.
Communications with a Tenant domain are always performed from a local Tenant Connection Broker and never from the Tenant Broker infrastructure.
Every Tenant must have a unique public domain address, which can be assigned a number of different ways. For example, a service provider can register a subdomain (e.g. Tenant1.Service-Provider.com) and assign it to a Tenant. Another approach could be using a private domain address (e.g. RAS.Tenant1.com) and have it routed to RAS Secure Gateways in the Tenant Broker. Note that different public domain addresses can resolve to the same IP address if needed.
When a Tenant is joined to the Tenant Broker, shared RAS Secure Gateways become aware of the Tenant and its configuration and can connect to the Tenant's RAS Connection Broker(s). A route must be set for the incoming Tenant's traffic from the Internet to RAS Secure Gateways (or HALB) in the Tenant Broker.
Tenant Broker comes with its own RAS Console allowing you to manage shared resources, Tenant objects and certificates, monitor Tenant performance, and carry out standard RAS administration tasks.
All Tenant Themes are made available in the Tenant Broker. When user connects via a shared RAS Secure Gateway in the Tenant Broker, the corresponding Tenant Theme is presented to the user.
Different SSL certificates can be used for different Tenants.
Tenant Broker doesn't need a license. Licenses are managed on a Tenant level.
Parallels RAS multi-tenant architecture is available in Parallels RAS 17.1 and newer. The following limitations apply when using older versions of Parallels RAS:
Parallels Clients older than RAS 17.1 are incompatible with shared gateways and therefore cannot be used to connect to a Tenant Farm via the Tenant Broker.
Parallels RAS installations older than RAS 17.1 are incompatible with Tenant Broker and cannot be joined as Tenants.
The following diagram illustrates a typical Parallels RAS deployment that uses the RAS multi-tenant architecture.
Firewalls and HALB are installed in a DMZ and are shared by Tenants.
Tenant Broker is a special RAS installation that hosts shared RAS Secure Gateways and HALB, and can also use RAS access layer. Tenant Broker is installed using the Parallels RAS Tenant Broker option in the Parallels RAS installer. Tenant Broker can be installed in its own domain or outside of a domain.
Tenant farms are deployed just like traditional on-premises RAS environments and are joined to the Tenant Broker. Each Tenant Farm has its own RAS Connection Brokers and servers hosting published resources (VDI, RD Session hosts, or Remote PCs). No local RAS Secure Gateways and HALB (or third-party load balancers) are needed.
Tenants are joined to the Tenant Broker and each Tenant is represented as a Tenant object in the Tenant Broker.
Parallels Clients (both platform-specific and Web) connect to shared gateways in the Tenant Broker. When a client connects to User Portal, a Theme from the corresponding Tenant is always used depending on which Tenant the client belongs to.
