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.
Enabling Multi-Tenancy
The master tenant is now referred to as primary tenant. Even though on day-0, the out-of-the-box VMware Identity Manager 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 Identity Manager 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 Identity Manager 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 Identity Manager are accessed through tenant URLs which are nothing but FQDNs mapped to the VMware Identity Manager server. Every tenant has its own tenant FQDN. For example, on a single node VMware Identity Manager 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 Identity Manager mandatorily requires a A-type DNS record mapping the tenant FQDN to the VMware Identity Manager server IP address. For a clustered VMware Identity Manager deployment, every tenant FQDN must be having an A-type record mapping to the VMware Identity Manager 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 Identity Manager 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 Identity Manager and associated with 'tenant1'. As mentioned, vRealize Automation tenant and VMware Identity Manager 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 Identity Manager, 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 Identity Manager, vRealize Automation servers and its load balancers depending on the deployment architecture should have their corresponding certificates holding all the required tenant FQDNs.
- VMware Identity Manager Node: idm1.vmwlab.local
vRealize Automation Node: vra1.vmwlab.local
Primary tenant alias name: master-tenant
Tenants: tenant-1, tenant-2
| Tenant Names | VMware Identity Manager 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 Identity Manager Load balancer: idm-lb.vmwlab.local
VMware Identity Manager 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 Identity Manager 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 Identity Manager to enable multi-tenancy or creating tenants, this brings down the service and leads to a downtime. If VMware Identity Manager certificate is changed, then it goes for a service downtime. The products or services integrated with VMware Identity Manager for their authentication purpose cannot use VMware Identity Manager auth log-in during the downtime. Also, changing VMware Identity Manager 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 Identity Manager and other products or services integrated with VMware Identity Manager, it is generally recommended to have wild-card certificates. For a new tenant, any change made in the VMware Identity Manager 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 Identity Manager and vRealize Automation server nodes. With vRealize Suite Lifecycle Manager, when you replace VMware Identity Manager certificate, the retrust of VMware Identity Manager 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 Identity Manager, the VMware Identity Manager Certificate update or replace operation in vRealize Suite Lifecycle Manager internally makes sure the VMware Identity Manager load balancer certificate is re-trusted before updating the VMware Identity Manager server certificates. So, it is recommended to first change the VMware Identity Manager load balancer certificate manually and then do a VMware Identity Manager 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 Identity Manager, you require A-type DNS records highlighting the tenant FQDNs to the VMware Identity Manager server IP address. And for a clustered VMware Identity Manager, A-type DNS records are required pointing the tenant FQDNs to the VMware Identity Manager 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
 |
|
|
|
