2.3.3 Naming Service (LDAPv3) Connectivity
Connectivity from the vCloud Director for Service Provider cells to the system LDAP server and any Organization LDAP servers must be enabled for the software to properly authenticate users. VMware recommends that the system LDAPv3 server 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 for Service Provider cells, potentially through the enterprise data center’s own DMZ.
In all of these circumstances, opening the appropriate ports through the various firewalls in the path between the cells and the LDAPv3 server is required. By default, this port is 389/TCP for LDAP and 636/TCP for LDAPS. However, this port is customizable with most servers and in the LDAP settings in the Web UI. Also, a concern that arises when the organization is hosting their own LDAPv3 server is exposing it through their DMZ. It is not a service that needs to be accessible to the general public, so steps must be taken to limit access to only the VMware vCloud Director for Service Provider cells. One simple way to do this is to configure the LDAPv3 server and/or the external firewall to only allow access from IP addresses that belong to the vCloud Director for Service Provider cells as reported by the cloud provider. Other options include per-Organization site-to-site VPNs connecting those two sets of systems, hardened LDAP proxies or virtual directories, and so on.
Conversely, cloud providers must beware 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 attacks by both limiting the source IP addresses of requests when possible to avoid inter-organization login attempts as well as ensuring that organization names it assigns are never too similar to one another.