Avoid SSO Admin lockout – a.k.a. your first task after installing vSphere SSO
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 in 5.1, set the Maximum Lifetime to 0 – for vSphere 5.5 you need to set to 9999 (Thanks to Hywel for his comments). 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.
SSO Admin password reset with ssopass – SslHandshakeFailed – vSphere 5.1
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.
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.
Following KB2034608 to reset the admin@system-domain I came across an interesting error:
vSphere Security: Advanced SSH Configurations
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.
Note: VMware use the term “ESXi Shell”, most of us would term it “SSH” – the two are used interchangeably in this article although there is a slight difference. You can have the ESXi Shell enabled but SSH disabled – this means you can access the shell via the DCUI. For the sake of this article assume ESXi Shell and SSH are the same. (more…)
Recover ESXi Root Password using AD Authentication
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.
vSphere Security: Active Directory Authentication
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! 😉 (more…)
vSphere Security: Understanding ESXi 5.x Lockdown Mode
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. (more…)
Changing ESXi root passwords the smart way (via PowerCLI)
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! (more…)
Why secure your vSphere environment with valid SSL certificates?
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.
Using the VMware SSL Certificate Automation Tool with a Microsoft Certificate Authority
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. (more…)