Logging in to your vCloud Director organisation via the web portal can be achieved in a number of ways. You can use a database local to vCloud Director, your Active Directory, or another LDAP v3 compliant directory service (e.g. eDirectory), for authentication and group membership lookup.
(At the present time using your Oxford SSO Kerberos credentials is not supported. As it happens, vCloud Director itself does support Kerberos authentication against an external Kerberos realm and we have successfully completed proof-of-concept testing, but some reconfiguration of the Oxford KDCs is required before we can roll this out in production. This is coming soon and we will document the procedure when the necessary work has been completed).
The rest of this blog post will focus on secure Active Directory authentication. I’ve seen a few articles explaining how to set up AD connectivity in a lab environment, but they tend to suggest using unencrypted simple LDAP binds. These are a Very Bad Idea, especially in a production environment, as they pass the AD user credentials across the network in plain text. Simple LDAP binds can (and should) be encrypted using SSL. This is better (and your only other option if you are using eDirectory), but it is still preferable not to send the password at all, encrypted or not. To achieve this we can use Kerberos authentication. With Kerberos, no passwords cross the wire – just encrypted Kerberos tickets with a limited lifespan (ten hours by default).
1. Configuring the domain controllers
The first step is to turn on LDAP over SSL on your domain controllers. Even though we will use Kerberos for authentication, vCloud Director needs to look up group information in the AD. Again we don’t want these LDAP queries to be sent across the network in plain text, so we need to enable LDAP over SSL (LDAPS).
To do this, follow the steps in Microsoft Knowledgebase article KB 321051 (http://support.microsoft.com/kb/321051). When you create the CSR, make sure that the key length is at least 2048 bits and that the “Subject” line contains all the information required by the signing authority (e.g. Subject=”CN=myserver.oucs.ox.ac.uk, OU=IT Services, O=University of Oxford, L=Oxford, S=Oxfordshire, C=GB”). Ideally you should request a certificate for all your domain controllers, although vCloud Director can use only one.
Secondly, a service account must be set up in your AD. This account needs to have sufficient rights to read group memberships of user accounts in the Active Directory. By default, the Domain Users group has this right, so no special privileges are required in the AD.
Once your domain controllers accept LDAPS connections and the service account is set up, we (IT Services) will configure your vCloud Director organisation to authenticate against the AD using Kerberos.
As an organisation administrator, you won’t be able to see this in your organisation’s config, so the rest of this blog post is really for information.
2. Configuring vCloud Director for Kerberos authentication
From the screenshot you’ll see that we can only enter one domain controller, which is a bit of a flaw. Potentially we can fix this with round robin DNS, but we’ve not investigated this.
We would prefer to import the certificate that you used to enable LDAPS on your domain controller, rather than succumbing to the “Accept all certificates” temptation (perhaps not a great security risk, but let’s do it properly). So we’ll ask you to make this available to us.
(We leave “Use external Kerberos” unchecked, but when the OX.AC.UK KDCs are ready it’s this checkbox and some extra config that will allow us to use Oxford SSO).
The Edit All Realms button is necessary to define DNS to realm mappings, as well as the KDC for each realm. For AD, the KDCs are your domain controllers. So in the Realm tab, we add the Active Directory realm (this is the same as the DNS name, but Kerberos realms are in upper case to distinguish them from DNS domains) and the domain controllers for that realm:
We can leave “Allow lower-case realms” ticked – it doesn’t much matter whether this is on or off. Note that because we can enter multiple domain controllers here, we have redundancy in terms of authentication. However the main page from the first screenshot still only gives us the option to use one server to do LDAP lookups (i.e. the one listed in the Server field). So we still have a dependency on one domain controller.
In the DNS tab of the Edit Realms screen, we also define the DNS to realm mappings:
Back on the main screen (the first screenshot), we enter the AD service account username and password. Note that we must have the realm entered in upper case – this is a Kerberos convention, defining a realm principal. Put it in lower case and it won’t work.
That’s it – at this point, you can import users from your Active Directory into your vCloud Director organisation and set up their access rights. Once that’s done, they can log in to the portal using their AD credentials.
One last thing of note is that when vCloud Director imports users from AD, it maps certain attributes to locally displayed data (for example, it will display the AD “sn” attribute for a user account in the vCD “Surname” field. For the user name, it is worth noting that when Kerberos is used, the mapping is set to be from the AD userPrincipalName attribute (e.g. firstname.lastname@example.org) rather than the sAMAccountName (jsmith). This means that users will need to log in at the vCD portal with their full UPN (email@example.com) rather than the shorter version (jsmith). As such, it is preferable to edit the mappings so that the vCD User name attribute maps to the AD sAMAccountName attribute:
and then users can log in with their short name.
That’s pretty much it. There is a VMware Knowledgebase article that briefly covers Kerberos authentication to vCD (KB 2015986) but it doesn’t have much in the way of explanation as to what’s going on. It’s also worth mentioning that the setspn command mentioned in step 12 of that article isn’t necessary.