Multi-organization tenancy vRealize Automation configurations rely on a coordinated configuration between several products, and you must ensure that DNS settings and certificates are configured correctly in order for your multi-organization tenancy configuration to function.

This multi-organization configuration assumes single node deployments for the following components:
  • Lifecycle Manager
  • Workspace ONE Access Identity Manager
  • vRealize Automation

Also, it assumes that you are starting with a default tenant, which is your provider organization, and creating two sub-tenants, called tenant-1 and tenant-2.

You can create and apply certificates using the Locker service in vRealize Suite Lifecycle Manager or you can use another mechanism. Lifecycle manager also enables you to replace or re-trust certificates on vRealize Automation or Workspace ONE Access.

DNS Requirements

You must create both main A type records and CNAME type records for system components as described below.
  • Create both main A type records for each system component and for each of the tenants that you will create when you enable multi-tenancy.
  • Create multi-tenancy A type records for each of the tenants you will create as well as for the master tenant.
  • Ccreate multi-tenancy CNAME type records for each of the tenants you will create, not including the master tenant.

Certificate requirements for single node multi-tenancy deployment

You must create two Subject Alternative Name (SAN) certificates, one for Workspace ONE Access and one for vRealize Automation.

  • The vRealize Automation certificate lists the hostname of the vRealize Automation server and the names of the tenants you will create.
  • The Workspace ONE Access certificate lists the hostname of the Workspace ONE Access server and the tenant names you are creating.
  • If you use dedicated SAN names, certificates must be updated manually when you add or delete hosts or change a hostname. You must also update DNS entries for tenants. As an option to simplify configuration, you can use wildcards for the Workspace ONE Access and vRealize Automation certificates. For example, *.example.com and *.vra.example.com.
    Note: vRealize Automation 8.x supports wildcard certificates only for DNS names that match the specifications in the Public Suffix list at https://publicsuffix.org. For example, *.myorg.com is a valid name while *.myorg.local is invalid.

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 availability configurations, the name uses the following format: tenantname.vraLBhostname.domain.

Summary

The following table summarizes DNS and certificate requirements for a single node Workspace ONE Access and single node vRealize Automation deployment.

DNS Requirements SAN Certificate Requirements
Main A Type Records

lcm.example.local

WorkspaceOne.example.local

vra.example.local

 Workspace One Certificate

Host Name:

WorkspaceOne.example.local, default-tenant.example.local, tenant-1.vra.example.local, tenant-2.vra.example.local
Multi-tenancy A Type Records

default-tenant.example.local

tenant-1.example.local

tenant-2.example.local
Multi-Tenancy CNAME Type Records

tenant-1.vra.example.local

tenant-2.vra.example.local

 vRealize Automation Certificate

Host Name:

vra.example.local, tenant-1.vra.example.local, tenant-2.vra.example.local