vRealize Automation enables IT providers, to set up multiple tenants, or organizations, within each deployment. Providers can set up multiple tenant organizations and allocate infrastructure within each deployment. Providers can also manage users for tenants. Each tenant manages its own projects, resources, and deployments.

In a vRealize Automation multi-organization configuration, providers can create multiple organizations, and each tenant organization uses its own projects, resources and deployments. While providers cannot manage tenant infrastructure remotely, they can log in to tenants and manage infrastructure within their tenants.

Multi-tenancy relies on coordination and configuration of three different VMware products as outlined below:
  • Workspace ONE Access - This product provides the infrastructure support for multi-tenancy and the Active Directory domain connections that provide user and group management within tenant organizations.
  • vRealize Suite Lifecycle Manager - This product supports the creation and configuration of tenants for supported products, such as vRealize Automation. In addition, it provides some certificate management capabilities.
  • vRealize Automation - Providers and users log in to vRealize Automation to access tenants in which they create and manage deployments.

When configuring multi-tenancy, users should be familiar with all three of these products and their associated documentation.

For more information about working with vRealize Suite Lifecycle Manager and Workspace ONE Access, see the following.

Administrators with vRealize Suite Lifecycle Manager privileges create and manage tenants using the Lifecycle Manager Tenanats page located under the Identity and Tenant Management service. Tenants are constructed using an Active Directory IWA or LDAP connection, and they are supported by the associated VMware Workspace ONE Access instance that is required for vRealize Automation deployments. See the associated documentation for information about using Lifecycle Manager.

When configuring multi-tenancy, you start with a base, or master tenant. This tenant is the default tenant that is created when the underlying Workspace ONE Access application is deployed. Other tenants, known as sub-tenants, can be based upon the master tenant. vRealize Automation currently supports up to 20 tenant organizations with the standard three node deployment.

Before enabling vRealize Automation for multi-tenancy, you must first install the application in a single organization configuration, and then use Lifecycle Manager to set up a multi-organization configuration. A Workspace ONE Access deployment supports the management of tenants and the associated Actice Directory domain connections.

When you initially set up multi-tenancy, a provider administrator is designated in Lifecycle Manager. You can change this designation or add administrators later if desired. Under multit-organizartion configurations, vRealize Automation users and groups are managed primarily through Workspace ONE Access.

After organizations are created, authorized users can log in to their applications to create or work with projects and resources and create deployments. Administrators can manage user roles in vRealize Automation.

Setting up for a multi-organization configuration

You can enable a multi-organization deployment after completing a vRealize Automation installation. When setting up a multi-organization configuration, you must configure your external Workspace ONE Access for multi-tenancy use and then use Lifecycle manager to create and configure tenants. This applies to both new and existing deployments. As an initial step to setting up tenants, you must use Lifecycle Manager to set an alias for the master tenant that was created by default on Workspace ONE Access. Sub-tenants that you create based on this master tenant inherit the Active Directory domain configurations from this master tenant.

In Lifecycle Manager, you assign tenants to a product, such as vRealize Automation, and to a specific environment. When setting up a tenant, you must also designate a tenant administrator. By default, multi-tenancy is enabled based on tenant hostname. Users can elect to manually configure tenant name by DNS name. During this procedure you must set several flags to support multi-tenancy, and you must configure the load balancer as well.

If you use a clustered instance, both the Workspace ONE Access and vRealize Automation tenant based hostnames will point to the load balancer.

If your clustered vRealize Automation and Workspace ONE Access load balancers do not use wildcard certificates, then users must add tenant hostnames as SAN entries on the certificates. for every new tenant that is created.

You cannot delete tenants in vRealize Automation or in Lifecycle Manager. If you need to add tenants to an existing multi-tenancy deployment, you can do this using Lifecycle Manager, but it will necssitate downtime of three to four hours.

Refer to the documentation links at the beginning of this topic for more information about using vRealize Suite Lifecycle Manager Workspace ONE Access.

Hostnames and multi-tenancy

In prior versions of vRealize Automation, users accessed tenants with URLs that were based on directory path. In the current multi-tenancy implementation, users access tenants based on hostname.

Also, the hostname format that vRealize Automation users will use to access tenants differs from the format that is used to access tenants within Workspace ONE Access. For example, a valid hostname would look like the following: tenant1.example.eng.vmware.com as opposed to vidm-node1.eng.vmware.com.

Multi-tenancy and certificates

You must create certificates for all components involved in a multi-organization configuration. You will need one or more certificates for Workspace ONE Access, Lifecycle Manager, and vRealize Automation, depending on whether you are using a single node configuration or a clustered configuration.

When configuring certificates, you can use either wildcards with the SAN names or dedicated names. Using wildcards will simplify certificate management somewhat as certificates must be updated whenever you add new tenants. If your vRealize Automation and Workspace ONE Access load balancer do not use wildcard certificates, then you must add tenant hostnames as SAN entries on the certificates for every new tenant that is created. Also, if you use SAN, certificates must be updated manually if you add or delete hosts or change a hostname. You must also update DNS entries for tenants.

Note that Lifecyle Manager does not create separate certificates for each tenant. Instead it creates a single certificate with each tenant hostname listed. For basic configurations, the tenant's CNAME uses the following format: tenantname.vrahostname.domain. For high availablity configurations, the name uses the following format: tenantname.vraLBhostname.domain.

If you are using a clustered Workspace ONE Access configuration, note that Lifecycle Manager cannot update the load balancer certificate, so you must update it manaully. Also, if you need to re-register products or services that are external to Lifecycle Manager, this is a manual process.