Auto Deploy – bulk licensing and Authentication Proxy.

There are great many resources on vSphere Auto Deploy you can find on the Web. Artur wrote about it more than a year ago, I can also recommend step-by-step tutorial on Wojciech’s blog.

In this post I would like to share my experience about two topics that are in fact fine-tuning of your Auto Deploy and make the whole deployment process almost completely “hands-off” (that’s a good thing!).

1.     First – bulk licensing for Auto Deploy.

By default auto-deployed vSphere hosts receive a 60-day evaluation license (so, no license at all in fact 😉 ) and you need to assign them with your target (volume) license manually (via Web or vSphere Client).
Fortunately it is really easy to associate your license key with a “host container” (like vSphere datacenter, host cluster or folder – if you happen to group your datacenters/clusters/hosts in folders).
You need to use UpdateAssociatedLicenseData() method of LicenseDataManager object to create this association between “host container” of your choice and LicenseData object that contains proper LicenseKeyEntry.

For my home lab datacenter (SeBa-Lab) the PowerCLI sequence of commands looks like this:

You need to be connected to your vCenter as pre-requisite and the license key is of course obfuscated ;).

Nothing really complex here as you can see, yet it gets your hosts licensed automatically. Just remember that if you need to associate your (volume) license key with cluster or folder you need to use appropriate cmdlet first (get-cluster or get-folder respectively). You can of course have different license keys per datacenter/cluster/folder, you can even go as granular as specifying different keys per host (but this idea is against general concept of auto deployment 😉 ). To verify the key association simply execute the query method:
$licenseDataManager.QueryAssociatedLicenseData($DataCenter.Uid).

2.     The second topic is a bit more complex and unfortunately a poorly documented one – it’s vSphere Authentication Proxy.

I really like the idea of adding your vSphere hosts to AD domain, but not so much the concept of saving any AD credentials in host profile (even if it is MD5 encrypted there).
vSphere Authentication Proxy is the tool created to help you with that and it helps indeed – provided you are able to get it running ;).

Let’s see the steps I had to follow to make it work (no warranty, expressed or implied is given, that repeating this sequence in your environment will yield you any success 😉 ).

First of all – the system where you install Authentication Proxy needs to be (quite obviously) member of AD domain you want to authenticate against, other prerequisites are Microsoft IIS and Microsoft .NET 3.5 SP1 installed.
That second condition limits your choices a little, as you can’t install Authentication Proxy on your vCenter Server (which I tried) for example, cause you get conflict over TCP 80 (since it is used by vCenter).

What is not listed as a pre-requisite – you will also need some IIS components that are not installed with IIS by default, in the picture below you can see the dependencies I got during my first attempted installation on Windows 2008 SP1. These dependencies will probably vary depending on the Windows version you’re using.

proxy02_cut

Once you fulfill all the requirements, the installer will ask you for path where to install binaries. Do not use paths that contain “non-ASCII” characters or you will face “Unknown error” as described in this KB.

I my case I installed Authentication Proxy binaries into (not really creative) d:\vmware\auth-proxy\ folder.

Next step looks trivial but it can be really misleading, when installer asks you about vCenter Server address and credentials.

proxy03_cut

The thing here is that installer needs administrative (or elevated – whatever you call them) privileges in vCenter, on localhost and in your AD.

This is because an extension (Authentication Proxy plug-in) needs to be registered in vCenter, a special account for Authentication Proxy (named CAM-<random-8char-string>) is created in Windows domain (this account will ultimately create your vSphere hosts computer accounts in AD) and a “Computer Account Management” website is installed on top of local IIS.

[Update as of August 9th, 2014] Just to elaborate a little on the CAM-* account. Once created it is member of Domain Users group in your AD (which is enough to create computer accounts for vsphere hosts) and vSphere  Authentication Proxy service runs with credentials of CAM-* account. No other “elevated” privileges are granted to this account (at least I wasn’t able to discover any 😉 ) [/End of Update]

It is important to remember, that during installation, you need to be logged-on to Windows with account (like Domain Admins group member) that has all Windows-related privileges. The reason for that is the fact, that installer process (which executes Windows part of configuration changes) inherits privileges from your Windows session, while the “Administrator” account you see in above picture is only used for vCenter plug-in registration.
If the account you are logged-on to Windows doesn’t have privilege to create accounts in your AD (for example) – you will end up with “Unknown error” again (been there, done that…).

Next tricky step is specifying “how vSphere Authentication Proxy should be identified on the network“.

proxy10

You are offered a drop-down list where you can choose between the FQDN and IP address of your system and it seems that using FQDN would be more elegant, but reality bites again and if you want your proxy to work – you have to select IP address here. This is a bug in installer code, that was discovered by Kenneth in version 5.1 already and apparently it wasn’t fixed (yet?) in version 5.5 (at least at the time of writing this post).

If you reached that far, the installer should complete its tasks w/o any errors, but just to make sure you’re on the right track I’d recommend you to do the 3 following checks.

Check %programdata%\VMware\vSphere Authentication Proxy\logs\camadapter.log logfile, if everything worked fine it should look like this (more or less).

You can see that vSphere host certificates are retrieved to authenticate with proxy as last steps of installation. I’ve got exactly 5 hosts in my lab and all of them use certificates signed by “some CA”, which means “self signed” in this case ;). This is perfectly fine for home lab, but you should think about properly signed certificates for your production environment(s).

Check if CAM-* account has been successfully created in your AD.

proxy06_cut

Last but not least – check if CAM plug-in is enabled in vCenter.

proxy11_cut

In the picture above you can see that, because TCP 51914 was blocked by Windows Firewall, the plug-in failed to initialize during my first attempt to install Authentication Proxy, so keep in mind that TCP 51914 and 51915 both need to be opened for the proxy to function.

OK – if all three checks are successful the chances are good your Authentication Proxy will work!
But… you still need to configure your IIS server to accept communication from your vSphere hosts 🙂
Luckily, that’s really simple – you just need to open IIS manager, browse to CAM ISAPI  website (must be there! we’ve just installed it, right?) and select IPv4 Address and Domain Restrictions to Add Allow Entry… like in example below.

proxy05_cut

Aaaand… That’s it! vSphere Authentication Proxy is ready to use!

Now, to use it with Auto Deploy it is just as easy as to edit the host profile(s) you are using for deployment. In Authentication configuration sub-profile you need to provide AD domain name and Authentication Proxy IP address. In example below you can see that I’m using vmhosts OU in my lab domain as AD container for vSphere hosts computer accounts. If vmhosts wasn’t a top-level OU the string specified could look like seba.local/level1-OU/level2-OU/vmhosts, or you can just use domain name alone if you want your vSphere hosts computer accounts to be created in default (so Computers) AD container.

proxy08-0

And this is how I forced vSphere Authentication Proxy to work hand in hand with Auto Deploy for me, it’s a really nice feature and I think it would be used more often than I see it in use, had it been properly documented.

On the other hand – Auto Deploy is in fact the only real-life use case for Authentication Proxy, in theory you can also use it when adding your hosts to AD manually, but…

As you could see hosts certificates are imported during Authentication Proxy installation. To make this trust relationship mutual the proxy certificate needs to be imported to all hosts under control of given vCenter.
When a host is Auto Deploy-ed this certificate import is done using the same transport mechanism as the host profile is applied, in case you would like to use Authentication Proxy to manually add host to AD, you would need to first import the proxy certificate manually (ever noticed that “Import certificate” link in host’s Authentication services configuration tab of vSphere Client?). Prior to importing it, you’d have to export the certificate from IIS where your Authentication Proxy is hosted and you’d need to export it to a file that is visible by all hosts, so to a shared datastore…

Quite a lot of work to achieve a goal, that can be reached just by providing valid AD credentials in “Directory Services Configuration” dialog 😉

I hope you find this post helpful, feel free to share and provide your feedback!

Sebastian Baryło

Successfully jumping to conclusions since 2001.