This section describes multi-tenancy model explaining how tenants can be accessed through tenant FQDNs and the importance of enabling multi-tenancy along with the certificate, and DNS requirements by using vRealize Suite Lifecycle Manager.
Enabling Multi-Tenancy
The master tenant is now referred to as primary tenant. Even though on day-0, the out-of-the-box VMware Workspace ONE Access includes a primary tenant already available, this is kept at a minimal configuration and further creation of tenants below the primary tenant is not possible. A sequence of configurations and API calls are to be performed on the VMware Workspace ONE Access to enable multi-tenancy. There must be an alias name created for the primary tenant when you enable multi-tenancy. For more information on enabling multi-tenancy, see Enable multi-tenancy.
For example, a VMware Workspace ONE Access with FQDN 'idm1.vmwlab.local' can already have a primary tenant with name 'idm1'. Before enabling multi-tenancy, it is mandatory to create an alias for the primary. For example, 'master-tenant' set and use the same alias name everywhere the primary tenant is referred.
Tenant FQDNs
By default, tenants created on VMware Workspace ONE Access are accessed through tenant URLs which are nothing but FQDNs mapped to the VMware Workspace ONE Access server. Every tenant has its own tenant FQDN. For example, on a single node VMware Workspace ONE Access with hostnameidm1.vmwlab.local, with the primary tenant name (idm1) and primary tenant alias (master-tenant), the primary tenant should be accessed through its FQDN master-tenant.vmwlab.local. If a new tenant (tenant1) is created, then it must be accessed only through tenant1.vmwlab.local.
Since every tenant requires a dedicated FQDN, creating tenants on VMware Workspace ONE Access mandatorily requires a A-type DNS record mapping the tenant FQDN to the VMware Workspace ONE Access server IP address. For a clustered VMware Workspace ONE Access deployment, every tenant FQDN must be having an A-type record mapping to the VMware Workspace ONE Access load balancer IP address.
The same model applies to vRealize Automation as well. When vRealize Automation is associated with a tenant, the vRealize Automation tenant must be accessed by vRealize Automation tenant FQDNs. For example, VMware Workspace ONE Access with FQDN idm1.vmwlab.local having a tenant 'tenant1' accessible through tenant1.vmwlab.local and vRealize Automation 8.1 vra1.vmwlab.local integrated with this VMware Workspace ONE Access and associated with 'tenant1'. As mentioned, vRealize Automation tenant and VMware Workspace ONE Access tenant maps 1:1, so the primary tenant vRealize Automation can still be accessed by vra1.vmwlab.local and 'tenant 1' vRealize Automation must be accessed by tenant1.vra1.vmwlab.local.
Similar to VMware Workspace ONE Access, even vRealize Automation tenant FQDNs require DNS mapping. But for a vRealize Automation it should be CNAME type record mapping the vRealize Automation tenant FQDNs to the vRealize Automation server FQDN. For a clustered vRealize Automation deployment, all vRealize Automation tenant FQDNs must be having a CNAME type DNS record pointing to the vRealize Automation load balancer FQDN.
Apart from having DNS mappings as a mandatory pre-requisite, certificates are also mandatory for tenancy to work. Both VMware Workspace ONE Access, vRealize Automation servers and its load balancers depending on the deployment architecture should have their corresponding certificates holding all the required tenant FQDNs.
- VMware Workspace ONE Access Node: idm1.vmwlab.local
vRealize Automation Node: vra1.vmwlab.local
Primary tenant alias name: master-tenant
Tenants: tenant-1, tenant-2
| Tenant Names | VMware Workspace ONE Access Tenant FQDNs | vRealize Automation Tenant FQDNs |
|---|---|---|
| master-tenant | https://master-tenant.vmwlab.local | https://vra1.vmwlab.local |
| tenant-1 | https://tenant-1.vmwlab.local | https://tenant-1.vra1.vmwlab.local |
| tenant-2 | https://tenant-2.vmwlab.local | https://tenant-2.vra1.vmwlab.local |
- VMware Workspace ONE Access Load balancer: idm-lb.vmwlab.local
VMware Workspace ONE Access Nodes: idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
vRealize Automation Load balancer: vra-lb.vmwlab.local
vRealize Automation Nodes: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Primary tenant alias name: master-tenant
Tenants: tenant-1, tenant-2
| Tenant Names | VMware Workspace ONE Access Tenant FQDNs | vRealize Automation Tenant FQDNs |
|---|---|---|
| master-tenant | https://master-tenant.vmwlab.local | https:// vra-lb.vmwlab.local |
| tenant-1 | https://tenant-1.vmwlab.local | https://tenant-1.vra-lb.vmwlab.local |
| tenant-2 | https://tenant-2.vmwlab.local | https://tenant-2.vra-lb.vmwlab.local |
Mandatory Certificate Requirements
- When you change the certificates on VMware Workspace ONE Access to enable multi-tenancy or creating tenants, this brings down the service and leads to a downtime. If VMware Workspace ONE Access certificate is changed, then it goes for a service downtime. The products or services integrated with VMware Workspace ONE Access for their authentication purpose cannot use VMware Workspace ONE Access auth log-in during the downtime. Also, changing VMware Workspace ONE Access certificate requires retrust on all product or services which again lead to a downtime for the products.
- For every new tenant that is created and associated with vRealize Automation, even vRealize Automation certificates must be changed and this causes service downtime for vRealize Automation.
- To avoid service down-times on vRealize Automation, VMware Workspace ONE Access and other products or services integrated with VMware Workspace ONE Access, it is generally recommended to have wild-card certificates. For a new tenant, any change made in the VMware Workspace ONE Access certificate or vRealize Automation certificate, can create a downtime in vRealize Automation.
- If wild-card certificates are not used, then specific SAN entries are to be created for each tenant FQDN on all required certificates.
- The vRealize Suite Lifecycle Manager locker service helps in managing certificates on the VMware Workspace ONE Access and vRealize Automation server nodes. With vRealize Suite Lifecycle Manager, when you replace VMware Workspace ONE Access certificate, the retrust of VMware Workspace ONE Access certificate on all products is performed automatically.
- Products or services external to vRealize Suite Lifecycle Manager is handled manually. Locker service does not handle updating load balancer certificates. They are to be done by the user manually. Whenever load-balancer certificates are changed, the same had to be re-trusted on the products.
- For VMware Workspace ONE Access, the VMware Workspace ONE Access Certificate update or replace operation in vRealize Suite Lifecycle Manager internally makes sure the VMware Workspace ONE Access load balancer certificate is re-trusted before updating the VMware Workspace ONE Access server certificates. So, it is recommended to first change the VMware Workspace ONE Access load balancer certificate manually and then do a VMware Workspace ONE Access certificate to update or replace through vRealize Suite Lifecycle Manager locker service.
- For a vRealize Automation 8.x, when SSL is terminated at vRealize Automation load balancer and load balancer certificate is changed manually, then make sure to click 'Re-trust Load Balancer' under the vRealize Automation 8.x product card to re-trust the load-balancer certificate in vRealize Automation. For more details, see Day 2 operations with other products in vRealize Suite Lifecycle Manager.
Mandatory DNS Requirements
For a single node VMware Workspace ONE Access, you require A-type DNS records highlighting the tenant FQDNs to the VMware Workspace ONE Access server IP address. And for a clustered VMware Workspace ONE Access, A-type DNS records are required pointing the tenant FQDNs to the VMware Workspace ONE Access load-balancer IP address.
For vRealize Automation, for a single node, CNAME type DNS records are required pointing vRealize Automation tenant FQDNs to the vRealize Automation server FQDN. And for a clustered vRealize Automation, CNAME type DNS records pointing vRealize Automation tenant FQDNs to the vRealize Automation load-balancer FQDN.
Requirements for multi-tenancy
 |
|
|
|
