vCenter Server

This is the first article in a series of vSphere Security articles that I have planned. The majority of this article is based on vSphere/ESXi 5.1, though I will include any 5.5 information that I find relevant. I think lockdown mode is a feature that is rarely understood, and even more rarely used. Researching this article I’ve already encountered several different definitions that weren’t quite right. As far as I can see there are no differences between lockdown more in 5.

You’d be surprised how many times I see datastore that’s just been un-presented from hosts rather than decommissioned correctly – in one notable case I saw a distributed switch crippled for a whole cluster because the datastore in question was being used to store the VDS configuration. This is the process that I follow to ensure datastores are decommissioned without any issues – they need to comply with these requirements

It’s been a really great year so far and incredibly busy (no complaints though!) VMware products have featured very high on my to-do list so far this year, with new hosting and DR solutions either completed or well underway. The simplicity, resilience and strength of vSphere never gets old! I have also had the privilege to attend several London VMUG meetings all of which have been excellent! They have been superb opportunities to meet new people, put faces to Twitter names and learn more about current and forthcoming technologies orientated around visualization.

The vSphere UMDS provides a way to download patches for VMware servers that have an air-gap, or for some reason aren’t allowed to go out to the internet themselves – in my case a security policy prevented a DMZ vCenter Server from connecting to the internet directly. The solution is to use UMDS to download the updates to a 2nd server that was hosted in the DMZ and then update the vCenter Server from there.

A problem reared it’s head over the weekend with one of our hosts’ Fibre Channel HBAs negotiating it’s way down to 2GB, and consequently introducing massive latency for the LUNs behind it. Analysis showed that the drivers for the HBA were over a year out of date so the suggested fix from VMware was to update the drivers. This is fine to do manually for a few hosts, but would be a real pain for the 300+ hosts in the environment I manage.

Updating vCenter Server certificates has always been a pain - it has only got worse with the sheer number of services that are running under vSphere 5.1 - each service requiring a unique certificate and to be installed in many complex steps. Fortunately , with the release of the SSL Certificate Automation Tool, VMware have gone some way to reducing the headache. Gather all the components you need OpenSSL installer: http://slproweb.

This article originally started off life as a record of how I managed to get this working, as a lot of my posts do, but this time it appears I am foiled. Last week, I had 3 vCenter Servers that appeared to be happily talking to each other in Linked Mode sharing a singe Multi-site SSO domain without any real issues. I had a single-pane-of-glass view of all 3 and I could manage them all from the one client.

So VMware’s Support Assistant is pretty awesome and it’s free! I thought I’d do a quick run through of the installation and set up for anyone who was interested, it’s fairly straightforward and if you raise a lot of calls or have multiple calls on the go it’s a time saver! VMware’s official page for the Support Assistant is here - https://www.vmware.com/products/datacenter-virtualization/vcenter-support-assistant/overview.html The OVF deploy is so simple I’ve just taken screenshots:

While adding an additional vCenter Server to our Multi-Site Single Sign On instance I encountered a problem as I entered the details of the existing SSO. The error thrown was: User credentials are incorrect or empty. Provide correct credentials. After a couple of hours online with VMware support I took a guess at the problem. On the existing Single Sign On Configuration I have added the Active Directory domain DefinIT and in order to enable integrated authentication from the vSphere Client I moved it to the top of the list - this meant that System-Domain is no longer the default authentication domain.

VMware vSphere Single Sign On (SSO) can be installed in Multi-site mode to support local sign-on to vCenters that you want to be part of the same single sign on domain - for example, if you want to install Linked-Mode and have the advantage of a single pane of glass view, but can’t risk using a single SSO instance across the WAN. In other words, from VMware’s blog post: