These days I am working on a bunch of new vCloud products that are currently in private beta and I found myself in need to create an Organization on vCloud Director (vCD from now on) with authentication backed by an Active Directory. As you may know, when you create a new vCD Organization you have three choices:
With the first option you are telling the cloud to create Organization users inside the Oracle database that is backing the vCD cell(s).
The second option allows the cloud admin to specify a local LDAP/AD where to host all Organization users. The cloud admin can configure the parameters to connect to this LDAP/AD system in the Administration tab and then System Settings -> LDAP. This configuration is cloud-wise i.e. all Organizations that are backed by “VCD system LDAP service” will have their users hosted on this centralized LDAP/AD service.
The third option -the one I’d like to talk about- is about configuring an Organization to point back to an LDAP/AD service that is managed by the Organization itself. For example, in case of a public cloud, ACME could subscribe with a vCloud service provider for a given amount of compute power and the service provider would create the ABC Organization linking it back to the ABC LDAP/AD server (for example ldap.abc.com or ad.abc.com). In my example I am trying to create an Organization called ACME and I want to link it back to an AD deployment I have here in the lab.
When you choose this option the Org creation wizard adds an additional page that you need to fill with the LDAP/AD parameters. This page is not required if you use the Oracle integrated database for hosting users or if you use the cloud-wise LDAP/AD integration (simply because you have already configured these parameters previously at the cloud level). The way you fill this is pretty straightforward:
I am not using any sort of security in the lab so my connection is pretty easy. Note that my AD domain name is labvmware.com and my Active Directory server is ad.labvmware.com. One important thing to note is that ad.labvmware.com is an address that needs to be reachable by the vCloud Director cell(s). This means that special caution needs to be used when configuring this connection. In real life public cloud scenario, an option would be to place a replica of the ACME LDAP/AD database in a DMZ and configuring secure access to it so that only the vCloud Director cell(s) IP addresse(es) can reach it. Secure design suggestions are beyond the scope of this brief post.
I am using the Administrator account to connect to the Active Directory. Remember to add the domain suffix (in my case it’s @labvmware.com) otherwise the connection will fail. If you have done things properly you should be able to test the connection. This is what you may see:
Note that some of the fields are being left blank simply because they are empty in my Active Director lab setup.
Once you have established the connection, vCD requires you to specify at least one NON-LDAP/AD user. This will allow you to login into the Organization even if the directory service is momentarily down. I usually add an admin user to each Organization with an Organization Administrator role associated.
When you are done creating the Org this is how its Administration -> Users view would look like:
Note the Type of the admin user: Local. That calls out that it is hosted in the “local” Oracle database. Note also the buttons on the up left corner: the typical + button allow you to add traditional users hosted in the Oracle database. The new icon (in the red circle) allows you to import a user from the Active Directory we have connected to.
Now I am going to add the Active Directory Administration user:
Note I have associated the Organization Administrator role to this Active Directory user. In other words Active Directory is responsible to validate the userid and password of the user, vCD is responsible to say what that user is entitled to do (in the vCloud Organization context).
I am also going to add one of my test accounts in the same Organization and I am adding it with a vApp User role.
This is how the list of users in the Org now looks like:
Note the Type column: we now have two LDAP users.
And now the last thing is to try to login with one of the LDAP users:
Note that I am now pointing my URL to the ACME Organization and I am logging in as mreferre2 which is one of my users defined in my Active Directory.
The following pictures outlines what this user can do:
Since mreferre2 has been associated with the vApp User role he can only deploy existing vApp from an existing catalog. If you want to know more how vCD catalogs work read this blog post.
In summary, using Active Directory (or in general LDAP) integration you can solve the burden of ongoing management of the users within an organization offloading this task to an external source. Within vCD you only need to associate a cloud role to an existing users that is managed outside of the context of the cloud.