In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.
The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution. However, I can envisage situations (similar to mine) when the SSO administrator account is not used for a long time and expired – that causes headaches.
To modify the SSO password policy log onto the vSphere Web Client as the SSO admin (admin@system-domain for 5.1 or firstname.lastname@example.org 5.5) and select Administration, then Sign-On and Discovery > Configuration. Select the Policies tab – you should see the default config:
Click edit and set the password policy as required. This only applies to SSO users (i.e. those in the System-Domain or vSphere.local domains). To set the password to never expire set the Maximum Lifetime to 0. IF you chose to do that, I’d beef up the complexity of your password policy to include upper, lower, numeric and special characters and increase the length from 8 to 13.
Similarly, you can edit the lockout policy which by default will lock you out if it has 3 failed attempts within 24 days. It will lock you out for 15 minutes. Setting the lockout time to 0 forces a manual unlock by an SSO admin.
The second option seems preferable to me (and Anthony and Grant) – that is to add some AD users or groups to the SSO administrators group. To do this, again log in as an SSO admin and select Administration, then Access > SSO Users and Groups, then the Groups tab. Select “__Administrators__” and click on the add principals button below. Select your AD domain from in the Identity Source field and search for your required user or group. Add them and click OK. Now those users, or group members have the ability to log on and reset or unlock the SSO admin account. AD accounts are obviously subject to your AD password policy, but can be reset independently of SSO and therefore don’t require you to use some command-line kung-fu to unlock.
vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for admin@system-domain.
In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation)
By default, vCenter Single Sign-On passwords, including the password for email@example.com, expire after 90 days.
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:
- Join the host to the domain (I’ve got a handy post for that here)
- Create the “ESX Admins” group in your AD and ensure that you are a member. The AD group will be given full administrator rights on the host automatically.
- Wait for replication, and the host to pick up the group and membership – it took about 15 minutes for me.
- You can now connect directly to the host using the vSphere Client – head on to the “Local Users & Groups” page and edit “root”:
- You should now be able to connect to the host using your new root password.
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.
The vSphere Security guide says (emphasis mine):
To increase the security of your ESXi hosts, you can put them in lockdown mode. In lockdown mode, all
operations must be performed through vCenter Server. Only the vpxuser user has authentication
permissions, no other users can perform operations against the host directly.
In short, lockdown mode means you can ONLY manage the host via vCenter. The only exception is via the DCUI.
With vSphere 5.5 being announced at VMworld San Francisco I was very eager to see what was new and after devouring all of the great blog posts out there of the guys in attendance I wanted to summarize in my own way the aspects I think are great!
- VMDK 2TB limitation removed! (also virtual mode RDMs)
This has to be one of the best pieces of news as it has been in the rear trying to accommodate really large VMs (changes affect both VMFS and NFS)
IMPORTANT - You need to be running ESXi 5.5
You cannot grow the VMDK "hot" the VMDK must be offline. Also you must use the web client to make the changes beyond 2TB ( you will get a funky error message if you try with the .NET client)
- vSphere Flash Read Cache
I have been keeping an eye (where possible) since I heard it announced way back as vFlash by Cormac hogan at a VMUG meeting last year, so I was chuffed to bits to see it made the cut in 5.5 (From what I have read though thus far it is not as straight forward to deploy and use as PernixData's excellent product which I have had the pleasure in looking at and testing.)
- vSphere maximums
While the days of needing to know the maximums for the exams have pretty much gone, VMware are still eager to impress and with HyperV hot on it's tail VMware have certainly upped the ante..
Apparently its not a re-branding of VSA (which was not particularly popular) VSAN is a new way to make use of HOST mounted storage whether it be SSDs or HDDs and create a data store accross 8 Hosts (8 hosts being the present maximum)
This solution is quite appealing for some of what I do on a day to day basis, but I have yet to see how VMware will license it or which suite (if any it will fall into)
If you want a really great overview of all the new features and changes I would recommend reading the following blog post at WahlNetwork
Also VMware have the following PDF
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
- No virtual machine resides on the datastore
- The datastore is not part of a Datastore Cluster
- The datastore is not managed by storage DRS
- Storage I/O control is disabled for this datastore
- The datastore is not used for vSphere HA heartbeat
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. If you have not had chance to get to one yet, do try, they are really worthwhile!
Also I was able to attend my very first #vBeers in Bath! (we really need to have another soon)
As a customer of VMware it's been interesting to see the launch of the Horizon suite (formally Project Octopus) of which Workspace is of great interest. It's solutions like this that really make sense to me especially with the arrival (like it or not) of BYOD. Other products such as View are also on my to-do list but one thing at a time!
As some of you know I was fortunate enough to win the recent V.I.T Competition so I shall be joining many others at VMworld in Barcelona in October. This will be a first for me and frankly I cannot wait! So expect me to be tweeting like a maniac with pictures of the event and me trying not to look too maniacally happy!
In recent weeks I have been wondering what is next for VMware concerning vSphere, I have heard very little save for rumors and speculation (vSphere 5.5 or 6.0? etc etc) traditionally they announce such things at VMworld so by the end of August we should have a better idea! I am sincerely hoping for significant improvements to the web client.. especially if they stick to their guns about retiring the .NET client.
I presently use VeeamOne and Veeam B&R both of which are incredible value for money. I recently sat in on a Veeam B&R v7 presentation (due out in August 2013) and wow.. these guys just keep making it better and I am convinced this is at least in part to their excellent attitude towards customer feedback either directly face-to-face or via their forums. Other vendors need to really take note, as from a customer point of view nothing gets your attention more than seeing your suggestions/queries taken seriously and responded to in a quick and timely fashion.
There is no question my two favorite words this year so far are VMware and Veeam. (some of my colleagues will testify to that with a distinct groan hah!)
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. It also can save on bandwidth if you’re running multiple vCenter Servers, which again was the case (though bandwidth isn’t really a constraint).
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.