VMware Aria Suite Lifecycle 8.16

8.18 8.16 8.14 8.12
Português (Brasil) 简体中文 Deutsch Español Français Italiano 日本語 한국어 Nederlands 繁體中文 English

Multi-tenancy model for
VMware Aria Suite Lifecycle
 products

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
.
There is a difference between
VMware Workspace ONE Access
 and
VMware Aria Automation
 tenant FQDNs. For a
VMware Workspace ONE Access
 instance, the tenant FQDN format is tenant name (tenant1) followed by the
VMware Workspace ONE Access
 domain name (
vmwlab.local
). For example,
tenant1.vmwlab.local
. Since it is tenant name followed by domain, it remains the same even for clustered
VMware Workspace ONE Access
. For a
VMware Aria Automation
, the
VMware Aria Automation
 tenant FQDN format is tenant name (tenant1) followed the
VMware Aria Automation
 server FQDN (
vra1.vmwlab.local
) For example,
tenant1.vra1.vmwlab.local
. For a clustered
VMware Aria Automation
 behind a load-balancer
vra-lb.vmwlab.local
, tenant1 must be accessed through
tenant1.vra-lb.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.
Tenant FQDNs on a single node setup
  • 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
Tenant FQDNs on a clustered setup
  • 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
After you enable multi-tenancy,
VMware Workspace ONE Access
 should only be accessed through its tenant FQDNs. The old FQDNs and hostnames (
idm1.vmwlab.local, idm2.vmwlab.local, idm3.vmwlab.local
 and
idm-lb.vmwlab.local)
 become invalid.

Mandatory Certificate Requirements

Depending on the deployment type of
VMware Workspace ONE Access
 and
VMware Aria Automation
, their corresponding server certificates should have all the tenant FQDNs present within itself. Since each tenant forms its own tenant FQDN (both
VMware Workspace ONE Access
 tenant FQDN and
VMware Aria Automation
 tenant FQDN), every created tenant requires its tenant FQDN to be added as part of both
VMware Workspace ONE Access
 and
VMware Aria Automation
 certificates. Enabling multi-tenancy on
VMware Workspace ONE Access
 also requires
VMware Workspace ONE Access
 certificates updated as the primary tenant gets a new alias name and primary tenant FQDN undergoes a change.
  • 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

Single node
Workspace ONE Access
and
VMware Aria Automation
Both
Workspace ONE Access
 and
VMware Aria Automation
 Cluster
Workspace ONE Access
 Single and
VMware Aria Automation
 Clustered
Workspace ONE Access Single and VMware Aria Automation Clustered screen
Workspace ONE Access
 Cluster and
VMware Aria Automation
 Single

Content feedback and comments