Security

Today I found out that in vSphere 5.1 the SSO administrator account (admin@system-domain) has a password that expires after 365 days. See KB2035864:

vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for admin@system-domain.

Awesome.

In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation)

There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ). My preferred route is to have it enabled but locked down.

Losing a root password isn’t something that happens often, but when it does it’s normally a really irritating time. I have to rotate the password of all hosts once a month for compliance, but sometimes a host drops out of the loop and the root password gets lost. Fortunately, as the vpxuser is still valid I can manage the host via vCenter - this lends itself to this little recovery process:

This is the second 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. The first article in this series was vSphere Security: Understanding ESXi 5.x Lockdown Mode .

Why would you want to join an ESXi host to an Active Directory domain? Well you’re not going to get Group Policies applying, what you’re really doing is adding another authentication provider directly to the ESXi host. You will see a computer object created in AD, but you will still need to create a DNS entry (or configure DHCP to do it for you). What you will get is a way to audit root access to your hosts, to give administrators a single sign on for managing all aspects of your virtual environment and more options in your administrative arsenal – for example, if you’re using an AD group to manage host root access, you don’t have to log onto however many ESXi hosts you have to remove a user’s permissions, simply remove them from the group. You can keep your root passwords in a sealed envelope for emergencies! 😉

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.5 and 5.1.

If you work in company with strict password compliance rules, for example under SOX, you might well have to change administrator passwords every month. Doing this on any more than a few hosts is tedious work – even on two hosts it seems like a waste of time logging on the host via SSH (or even enabling it first) before changing the password. Then we also need to audit the change, there’s no point making it for compliance reasons if we can’t then prove we did it!

It’s no secret that installing certificates from an internal CA is a pain in the…vCenter, but having just gone through the process of updating 3 vCenter installations with the 5-7 certificates required for each server I was asked “just why is it we need to do this again?”

Why does it require multiple certificates for my vCenter server?

In short, each service requires a certificate because it could feasibly be on a server (or servers) of it’s own - take this hypothetical design - each role is hosted on it’s own VM, and there are 7 certificates required - SSO, Inventory Service, vCenter Server, Orchestrator, Web Client, Log Browser and Update Manager. If you install all these services on one server you still have to create certificates for those individual services.

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.com/products/Win32OpenSSL.html  (I downloaded “Win32 OpenSSL v0.9.8y Light”, even though it’s a 64-bit server)

This is every file server admin’s nightmare: hundreds of shares, thousands of folders, hundreds of thousands of files - and custom or not inherited rights on many of them. Terabytes of data that need auditing - e.g. to find customer data, or credit card information. How do you go about accessing all the data in all the trees? What about backups failing because someone removed the System account? Of course you can seize control of the folder by taking ownership and pushing down from a top level - but how do you preserve the existing Access Control Lists?

I can’t plead ignorance: I should know better!

For years I have preached to users about the importance of strong passwords, regular password changes and non-proliferation of the same password, yet I’ve fallen foul of 2 of my own rules. My password is strong - 13 characters, random alpha-numeric, upper and lower case and including special characters - but has been re-used in a few places, and hasn’t been changed in a (long) while.