VMware vCloud Director can use three different authentication mechanisms for subscriber authentication to the VCD portal. The portal is accessed using the URL https://<cloud-url>/cloud/org/<organisation>. In this post, I’ll try to highlight some of the authentication options that a subscriber can use to access the VCD portal.
|Platform||LDAP Server||Authentication Methods|
|Windows Server 2003||Active Directory||Simple, Simple SSL, Kerberos, Kerberos SSL|
|Windows Server 2008||Active Directory||Simple|
|Windows 7 (2008 R2)||Active Directory||Simple, Simple SSL, Kerberos, Kerberos SSL|
|Linux||OpenLDAP||Simple, Simple SSL|
A provider can configure a subscriber to use three different authentication mechanisms as highlighted by Figure 1.
Figure 1 – VCD LDAP Options
This is the simplest authentication method, selecting this radio button when configuring a new Organization will not use any kind of LDAP service. Instead, new users will need to be configured using the VCD GUI or the VCD API, and these users will be stored within the VCD database. Some of the disadvantages when using the local authentication are:
Selecting this will force the Organization to use the same LDAP service as the LDAP service that is used by the VCD system (Provider). Although, a separate OU can be used for each Organization, this is not the ideal model to use for large cloud deployments. Some of the disadvantages when using the VCD system LDAP service are:
Selecting this will allow the Organization to use its own private LDAP service. What this means is for each Organization, a completely separate and unique LDAP service can be used for that Organization, an Organization does not need to use the same service as the VCD system but can use its own LDAP service. This can be a completely separate unique Active Directory Forest for example, with no network links to any other AD Forest.
Consider this following example:
I run a Public Cloud so I am a Provider of cloud services, my VCD system authenticates to a Microsoft Active Directory Forest with a domain name of HUGO.LOCAL. This allows me as a System Administrator to log into my VCD portal as a user on HUGO.LOCAL.
As the System Administrator, I first configure an LDAP service for the VCD System:
Figure 2 – VCD System LDAP
Then, a new Security Group called SG_VCD.System.Administrators is created in the HUGO.LOCAL domain, with the user HUGO.LOCAL\HPhan as a member of that group.
Figure 3 – VCD System Administrators Group
The new Security Group SG_VCD.System.Administrators is then added to the System Administrator role in VCD.
Figure 4 – Import LDAP group into VCD role
Now I can log into my cloud as a System Administrator with my domain user HUGO\HPhan.
Figure 5 – System LDAP
So pretty easy and straightforward so far right? What happens when a subscriber comes along and wants to use my cloud services? Let’s do another example.
A new organization let’s say Coke, wish to use their own LDAP service to authenticate with the VCD portal. In much the same way as how the System LDAP was configured, an Organization LDAP service is configured in similar ways.
As a System Administrator, I first configure a LDAP service for the Coke Organization, instead of using the HUGO.LOCAL LDAP service, I now direct this Organization’s LDAP service to a unique LDAP service for Coke. This can be a LDAP service hosted by me (the Provider) and managed by Coke (think co-lo), or a LDAP service managed by Coke in Coke’s datacentres (think MPLS/IPVPN):
Figure 6 – Organization LDAP
Then a new Security Group called Organization Administrators is created in the COKE.LOCAL domain, with the user COKE.LOCAL\John.Smith as a member of that group.
Figure 7 – VCD Organization Administrators Group and Members
The new Security Group Organization Administrator is then added to the Organization Administrator role in Coke’s Organization.
Figure 8 – Assign LDAP Group to VCD Role
John Smith can log into the Coke Organization as an Organization Administrator with the domain user COKE\John.Smith.
Figure 9 – LDAP User logged into VCD
So what happens when another Organization joins the party? Extending our example above, let’s say Pepsi also want to use my cloud services. In much the same way that the Coke Organization is configured to use its own LDAP service, we do the same for the Pepsi Organization – an Organization Administrator group is created in the PEPSI.LOCAL domain, and a user named Peter.Smith is a member of that group, Peter Smith can also log into Pepsi’s Organization as an Organization Administrator.
Figure 10 – Another LDAP User logged into VCD
In summary the provider will use the System LDAP, all other (subscribers) Organizations could also use the System LDAP (either with a separate OU or not) if required, however, you can also configure each Organization to use its own LDAP Service.
For each Organization, a single LDAP Service for that Organization will need to be configured as a Custom LDAP to authenticate to. To enable this functionality, the vCloud Director Cell must be able to connect to ALL LDAP servers over TCP 389 or 636. The VMware vCloud Security Hardening Guide gives good recommendations on how Service Providers can host Subscribers’ LDAP servers and also how to maintain connectivity to Subscribers’ LDAP servers if hosted remotely over MPLS/VPN etc.
It is therefore important that the vCD Cell is secured and network connectivity to each organization’s LDAP services are also secured. The following extract from the VMware vCloud Security Hardening Guide explains the connectivity options for subscriber’s LDAP services:
Connectivity from the VMware 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 VMware vCloud Director cells, potentially through the enterprise datacenter’s own DMZ (see Shared Resource Cloud Service Provider Deployment above).
In all of these circumstances, opening the appropriate ports through the various firewalls in the path between the cells and the LDAP 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 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 VMware 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 VMware 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.
Figure 11 – Multiple Custom LDAP in VCD
Note: The use of Coke and Pepsi are used as an example of multi tenancy within a public cloud and the use of the names on this blog are for information purposes only.
To unistall the vCD agent (vslad) on an ESXi host:
VMware vCloud Director (vCD) automatically creates a URL for each organisation that is created in vCD. There is a slight bug which does not create the URL properly and will cause the URL that is displayed under Customer | Administration | Settings | General to be incorrect.
For example, if you create an organisation called Customer1, the default URL that is created will be:
This is of course wrong and if you clicked on the link you would see a page similar to this:
So how do we fix this?
Simple, just add cloud into the URL so the new URL will be:
This WILL work but you will have to do this for every new customer and also remember to publish the correct URL.
However, there is a better way, being much more intelligent, amend the system VCD public URL under System | Administration | System Settings | Public Addresses
This will automatically add cloud into all organisation VCD public URLs.
Most administrative changes to vShield Manager can be done using the command line interface (CLI) by initiating a console session to the vShield Manager virtual machine. You can log in to the CLI by using the default user name admin and password default.
You can also access the CLI by enabling SSH.
manager# configure terminal
manager(config)# ssh start
manager(config)# cli ssh allow
vShield Manager uses manager as the default hostname but there is no easy way to change the hostname using the web interface or the vSphere plugin. You can only change vShield Manager’s hostname using the CLI.
manager# configure terminal
manager# hostname newhostname
More to follow….
A VMware vCloud Director (vCD) cluster contains one or more vCD servers, these servers are referred to as “Cells” and form the basis of the VMware cloud. A cloud can be formed of multiple cells.
This diagram is a good representation of the vCD Cluster concept.
To enable multiple servers to participate in a cluster, the same pre-requisites exist for a single host as for multiple hosts but the following must be met:
This shared storage could be a NFS mount, mounted to all participating servers with rw access for root. It is important that prior to configuring the first server, a decision must be made on whether a cluster is required. If you intend to use a vCD Cluster, configure the shared transfer server storage before executing the vCD installer.
Check out the vCloud Director Installation and Configuration Guide for pre-requisites.
For this post, I’ve setup an NFS volume on Freenas and given rw permissions for all cluster members to the volume. It is assummed that you have a completely clean installation of RHEL 5 x64 (or if like me you are running this in a lab CENTOS 5 x64), with all the latest updates and pre-requisite packages.
Now to mount the volume on all hosts:
Now you are ready to install vCD onto the first host, making sure that you have met all the pre-requisites as detailed in the vCloud Director Installation and Configuration Guide. Once completed you should have a working cell with its shared transfer server storage folder located on the NFS volume.
At this point you should already have a working cell with the vCD shared transfer server storage located on the NFS volume. Before you install vCD onto a server the following must be done:
The installer will automatically complete most prompts for you, but you will still need to select the correct eth adapter for the http and consoleproxy services, everything else will be automatic.
Go ahead and have a play and maybe even deploy a load balancer on top.
Here’s a screenshot of my two cells working side by side connecting to the same shared transfer server storage, oracle database and managing the same vCenters.
For more information read the overview at Yellow Bricks which also includes links to the product pages.