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 VMware Aria Suite Lifecycle.
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 VMware Aria Suite Lifecycle products.
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, you must create an alias for the primary (example, primary-tenant) set and use the same alias name everywhere the primary tenant is referenced.
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 hostname idm1.vmwlab.local, with the primary tenant name (idm1) and primary tenant alias (primary-tenant), the primary tenant should be accessed through its FQDN primary-tenant.vmwlab.local. If a new tenant (tenant1) is created, it must be accessed only through tenant1.vmwlab.local.
Since every tenant requires a dedicated FQDN, creating tenants on VMware Workspace ONE Access 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 have an A-type record mapping to the VMware Workspace ONE Access load balancer IP address.
The same model applies to VMware Aria Automation. When VMware Aria Automation is associated with a tenant, the VMware Aria Automation tenant must be accessed by VMware Aria Automation tenant FQDNs. For example, VMware Workspace ONE Access with FQDN idm1.vmwlab.local has a tenant tenant1 accessible through tenant1.vmwlab.local and VMware Aria Automation vra1.vmwlab.local integrated with this VMware Workspace ONE Access and associated with tenant1. As mentioned, the VMware Aria Automation tenant and VMware Workspace ONE Access tenant maps 1:1, so the primary tenant VMware Aria Automation can still be accessed by vra1.vmwlab.local and tenant1 VMware Aria Automation must be accessed by tenant1.vra1.vmwlab.local.
Similar to VMware Workspace ONE Access, even VMware Aria Automation tenant FQDNs require DNS mapping. But for a VMware Aria Automation it should be CNAME type record mapping the VMware Aria Automation tenant FQDNs to the VMware Aria Automation server FQDN. For a clustered VMware Aria Automation deployment, all VMware Aria Automation tenant FQDNs must be having a CNAME type DNS record pointing to the VMware Aria 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, VMware Aria 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
VMware Aria Automation Node: vra1.vmwlab.local
Primary tenant alias name: primary-tenant
Tenants: tenant-1, tenant-2
| Tenant Names | VMware Workspace ONE Access Tenant FQDNs | VMware Aria Automation Tenant FQDNs |
|---|---|---|
| primary-tenant | https://primary-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
VMware Aria Automation Load balancer: vra-lb.vmwlab.local
VMware Aria Automation Nodes: vra1.vmwlab.local, vra2.vmwlab.local, vra3.vmwlab.local
Primary tenant alias name: primary-tenant
Tenants: tenant-1, tenant-2
| Tenant Names | VMware Workspace ONE Access Tenant FQDNs | VMware Aria Automation Tenant FQDNs |
|---|---|---|
| primary-tenant | https://primary-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 re-trust on all product or services which again lead to a downtime for the products.
For information about changing your VMware Identity Manager certificate, see Replace your Workspace ONE Access certificate by using VMware Aria Suite Lifecycle.
For related information about replacing certificates for VMware Aria Suite Lifecycle, see Replace certificate for VMware Aria Suite Lifecycle products.
- For every new tenant that is created and associated with VMware Aria Automation, even VMware Aria Automation certificates must be changed and this causes service downtime for VMware Aria Automation.
- To avoid service down-times on VMware Aria 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 VMware Aria Automation certificate, can create a downtime in VMware Aria 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 VMware Aria Suite Lifecycle locker service helps in managing certificates on the VMware Workspace ONE Access and VMware Aria Automation server nodes. With VMware Aria Suite Lifecycle, when you replace VMware Workspace ONE Access certificate, the re-trust of VMware Workspace ONE Access certificate on all products is performed automatically.
- Products or services external to VMware Aria Suite Lifecycle 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 VMware Aria Suite Lifecycle 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 VMware Aria Suite Lifecycle locker service.
- For VMware Aria Automation, when SSL is terminated at a VMware Aria Automation load balancer and the load balancer certificate is changed manually, you must click Re-trust Load Balancer under the VMware Aria Automation product card to re-trust the load-balancer certificate in VMware Aria Automation. For more details, see Day 2 operations with other products in VMware Aria Suite Lifecycle.
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 VMware Aria Automation, for a single node, CNAME type DNS records are required pointing VMware Aria Automation tenant FQDNs to the VMware Aria Automation server FQDN. And for a clustered VMware Aria Automation, CNAME type DNS records pointing VMware Aria Automation tenant FQDNs to the VMware Aria Automation load-balancer FQDN.
Requirements for multi-tenancy
 |
|
|
|
