2.3.2 Configuring Identity Sources
System administrators and Organization users have the option of importing users from an LDAPv3 directory or using an external Identity Provider (IdP), such as SafeNet. It is important to understand the differences between the user types. Local users are stored in the vCloud Director for Service Providers Oracle database with the hashes of their passwords. Those users are authenticated against their hashed entry in the database. Limited management functionality is available—database users can only be enabled or disabled and assigned to roles. A six-character password minimum is enforced for local database user accounts.
System LDAP users are stored in the LDAPv3 directory configured at the system level, and references to them are imported into the vCloud Director for Service Providers database where roles are assigned. LDAP users’ passwords are managed and maintained in the LDAPv3 directory, and authentication occurs against that directory using the settings specified in the LDAP configuration screen. All of the LDAPv3 directory’s controls for authentication and passwords are preserved, including authentication failure lockouts, password expiration, history, complexity, and so on, and are specific to the directory chosen. If an organization is configured to use the system LDAP, its users come from the OU specifically configured in that organization’s vCloud Director for Service Providers System LDAP Service settings.
Organization, or custom, LDAPv3 directories are unique to a specific organization and can be hosted in the cloud provider’s infrastructure or at the organization’s enterprise data center. A reference to these users is imported into the database as in the previous example.
VMware strongly recommends that the system administrators and organization users come from a directory server. At this time, users in the Oracle database are not managed with the password and authentication controls typically available in a directory, including authentication failure controls, password expiration, complexity and history, and integration with enterprise identity management systems. Creating local users adds additional management tasks when users change job functions or leave the company. Instead of managing those users using a single LDAPv3 directory, you must remember to change roles and disable users immediately upon a change in their roles or their termination. As an alternative, an enterprise identity management system can be extended to manage local users through the vCloud Admin API, the details of which are outside the scope of this document. For more information on the vCloud API, see the VMware vCloud API Programming Guide.
Some cloud providers might choose to allow organizations to use an OU within the system LDAP or to host the organization’s LDAP directory. In either case, appropriate management access to that directory must be provided so that users can be managed by the organization administrator. The lack of such control would provide an extra burden on the system administrator and hinder the organization from easily and properly controlling access to their virtual data centers. In the absence of such management controls, an organization must use only a private LDAPv3 directory that they themselves host and manage.
Finally, the VMware vCloud Director for Service Providers documentation recommends having at least one local user for the system and each organization so that if the LDAPv3 server is not accessible, administrators can still access the system. Organizations must carefully weigh the benefits and risks of such an approach. As mentioned earlier, local users do not have password strength or authentication lockout controls. Those users are thus open, if accessible from the Internet, to attacks. The cloud provider must carefully control which source IP addresses can authenticate to an organization’s cloud URL if local users are configured. Another alternative is the use of the system LDAP or locally-hosted LDAP system. If high availability is a concern, an alternative is the use of a replicated LDAP server, fronted by a load balancer, so as to reduce the possibility of the directory becoming unreachable.