The vCloud Director integrated identity provider supports several popular LDAP services.

See the vCloud Director Release Notes for a list of supported LDAP services.

vCloud Director allows the system administrator to define a systemwide LDAP service that can be used by all tenants. Tenant user accounts are imported into the vCloud Director database where vCloud Director roles are assigned. LDAP users' passwords are managed and maintained in the LDAP directory, and authentication occurs against that directory using the settings specified in the LDAP configuration screen. All of the LDAP directory's controls around authentication and passwords are preserved, including authentication failure lockouts, password expiration, history, complexity, and so on, and are specific to the LDAP service 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 System LDAP Service settings.

Cloud providers may choose to allow tenant organizations to use an OU within the system LDAP or to host their own LDAP directory service. 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 VDCs. In the absence of such management controls, an organization should only use a private LDAP directory that they themselves host and manage.

Connectivity from vCloud Director cells to the system LDAP server and any organization LDAP servers must be enabled for the software to properly authenticate users. As recommended in this document, the system LDAP server must be located on the private management network, separated from the DMZ by a firewall. Some cloud providers and most IT organizations will run any organization LDAP servers required, and those too would be on a private network, not the DMZ. Another option for an organization LDAP server is to have it hosted and managed outside of the cloud provider's environment and under the control of the organization. In that case, it must be exposed to the vCloud Director cells, potentially through the enterprise datacenter's own DMZ.

In all of these circumstances, opening the appropriate ports through the various firewalls in the path between the cells and the LDAP server, as described in LDAP over TLS/SSL, is required. Also, a concern that arises when the organization is hosting their own LDAP server is exposing it through their DMZ. It is not a service that needs to be accessible to the general public, so steps should be taken to limit access only to the vCloud Director cells. One simple way to do that is to configure the LDAP server and/or the external firewall to only allow access from IP addresses that belong to the vCloud Director cells as reported by the cloud provider. Other options include systems such as per-organization site-to-site VPNs connecting those two sets of systems, hardened LDAP proxies or virtual directories, or other options, all outside the scope of this document.

Conversely, cloud providers should be aware that organization-hosted LDAP servers managed by unscrupulous customers could be used as part of an attack against other organizations. For example, one might conceive of an organization requesting an organization name that is a common misspelling of another organization's name and using the similar-looking login URL in a phishing attack. The provider can take steps to protect against this and similar intertenant attacks by both limiting the source IP addresses of requests when possible to avoid inter-organization logon attempts as well as ensuring that organization names it assigns are never too similar to one another.


It is highly recommended that you configure a LDAPv3 directory for user authentication. vCloud Director must be configured to connect to LDAP servers over SSL in order to properly protect the passwords being validated against those servers. See "Configure an LDAP Connection" in the vCloud Director Administrator's Guide for details. The most secure LDAP configuration specifies Use SSL and requires an SSL certificate provided by the LDAP service.

If the signed certificate of the LDAP server is not available, then the certificate of the CA that signs the LDAP server certificate must be imported into the system or organization JCE Key Store (JCEKS). LDAP configurations that specify a JCEKS Key Store are also secure, but can be subject to misconfiguration when lots of CA certificates (or even a lot of specific server certificates) are trusted. In addition, it is preferable to choose an LDAP provider that supports Kerberos authentication.

Connectivity to the LDAP server is required. While plain (non-SSL) LDAP runs over port 389/TCP, servers that support LDAP over SSL use port 636/TCP by default; however, this port is also configurable. Please note that vCloud Director supports the legacy LDAP over SSL (LDAPS) approach and does not support negotiating TLS within an LDAP connection using the StartTLS command.

Finally, the LDAP-enabled directory server must be properly configured with an SSL certificate. How that is done is beyond the scope of this document..

Importing Groups

The purpose of importing groups into vCloud Director is to allow you to avoid manually importing individual users all with the same role. When LDAP users log in, their session gets assigned the roles that are mapped to the groups of which they are members. As users' group memberships change based on changes to their duties within their organizations, the roles assigned to those users change automatically based on the group to role mapping. This allows organizations to easily integrate cloud roles with internal organization groups/roles and the systems that provision and manage them.

As an example, an organization may decide to initially grant LDAP users the "Console Access Only" role to limit users' rights. To do so, all users that need this basic role are added to a single LDAP group, and when that group is imported, the organization administrator assigns it the Console Access Only role. Then, those users with additional job duties they need to perform could be added to other LDAP groups, also imported to vCloud Director and assigned to these more privileged roles. For instance, users with a need to create Catalogs could be added to the "Org A Catalog Author" group in the organization's LDAP server. Then the organization administrator for Org A would import the "Org A Catalog Author" group and map it to the predefined Catalog Author role in vCloud Director. This is accomplished by following the Import a Group instructions in the vCloud Director User's Guide.