This section describes the key concepts and terminologies required to be understood before starting with multi-tenancy.
Get Familiar with the Tenant Management Terms
- Tenant - It is the highest level in an organizational structure in VMware Identity Manager. All objects like directories, users, groups, third party IDPs are maintained individually for each tenant. Each tenant is isolated from the rest of the tenants and they do not share any resource with each other.
- Primary Tenant - There is always at least one tenant (primary, default or base) present in the VMware Identity Manager which is called as primary tenant.
For vRealize Automation 7.x users, this is the 'vsphere.local' that was present out of the box in a vRealize Automation 7.x deployments. The primary tenant in vRealize Automation 7.x was by default bootstrapped with 'vsphere.local' as its name. But this does not happen in a standalone deployment of VMware Identity Manager. The primary tenant name is formed based on the first VMware Identity Manager node that gets deployed and bootstrapped. For example, if 'idm1.vmwlab.local' is the first VMware Identity Manager node that gets deployed, then when you bootstrap VMware Identity Manager, primary tenant is created with name 'idm1'. Nodes further getting scaled-out like 'idm2.vmwlab.local' and 'idm3.vmwlab.local' does not effect. The primary tenant name is formed only once and remains the same in a single or clustered instance.
- Primary Tenant Alias - You cannot create sub tenants in VMware Identity Manager under the primary tenant until a few configurations are set and enabled. Setting an alias name for the primary tenant is one such important configuration. An alias must be created on the primary tenant and the primary tenant should always be accessed through the primary tenant alias FQDN on a single node or a clustered instance.
- Provider Admin - An admin who owns the management infrastructure, that includes VMware Identity Manager, vRealize Automation and other products. The admin creates and manages all the tenants and associates products with tenants. The vRealize Suite Lifecycle Manager admin user, 'admin@local' is the only provider admin and is authorized to perform tenant management functionalities.
- Tenant Admin - An admin with the highest level of administrative permission in each VMware Identity Manager tenant. This permission can be assigned to both local VMware Identity Manager users and Active Directory users present within the VMware Identity Manager tenant.
- Tenant Aware Products - Products that support multi-tenancy and maintains proper isolation with each logical tenant instance are tenant aware products. They have one to one mapping with VMware Identity Manager tenants. As of vRealize Suite Lifecycle Manager 8.1 release, only vRealize Automation 8.1 is tenant aware.
- vRealize Automation Organization and Organization Owner - In vRealize Automation 8.x, organization is the top-level construct and it maps 1:1 with VMware Identity Manager tenant. Organization Owner has administrative permission in the vRealize Automation Organization or tenant. While adding tenants and associating vRealize Automation with the newly added tenant, the VMware Identity Manager tenant admin becomes the organization owner for the new tenant. For more information on adding tenants, see #GUID-75A38F1B-F2BC-44C4-A97B-63A17646DB33.
- Directory - Directories are second level of objects in VMware Identity Manager. It represents an external identity store or provider like Active Directory (AD) or an OpenLDAP server. There are multiple variants of directory supported in VMware Identity Manager. You can add Active Directory Over LDAP and Active Directory with IWA in the Directory Management section.
- Directory Synchronization - While adding directories, configuration options are provided to filter and synchronize the required users and groups from the Identity Store or provider to the VMware Identity Manager database. Only after a successful sync, you can integrate the users and groups with VMware Identity Manager.
- Directories in tenant - Each tenant can contain several directories. The same directory configuration can be present in multiple tenants, however, it is considered a separate directory. For example: You have added Directory A in primary tenant with some directory configurations (User DNs, Group DNs, Sync configurations). And you have two sub-tenants named Tenant-1 and Tenant-2. The same directory configurations of directory A can be used on to add directories A1 and A2 on each of the sub-tenants respectively, so that the same set of users and groups are synced in sub-tenants - Tenant-1 and Tenant-2. After adding, any changes to the sync configurations of directory A in primary tenant will not affect directories A1 and A2 and its synced users and groups in Tenant-1 and Tenant-2. All three directories and its configurations are independent of each other. All three directories are affected only if the external identity store or provider changes. For example, if users or groups are getting removed directly from the Identity provider then it influences all three directories in all three tenants.