How to Secure vCenter SSO User Accounts

As with other systems incorporating authentication schemes, vCenter Server comes with a password, and a corresponding, lockout policy. As the saying goes, security is only as strong as your weakest link. All it takes is a highly privileged account with a weak password to bring your infrastructure down to its knees. Today’s post introduces these two policies along with some basic testing to ensure that settings such as password complexity and account lockout are being enforced to better secure your vCenter SSO user accounts.

For a more general read on vSphere security, have a look at An Introduction to vSphere Security Hardening.

The Password Policy

All password policies have commonalities such as;

• Password lifetime: The period after which a user account’s password expires from when it was last set. Typically this is set to anywhere between 60 and 90 days.
• Password reuse: This refers to the minimum number of password changes before a previously used password can be reused.
• Password length: This is typically set to 8-20 characters. In general, longer passwords are preferred due to increased entropy (uncertainty).
• Password complexity: A mix of special, alpha-numeric, upper and lowercase characters. Mitigates against dictionary and brute force attacks.

That said, it is interesting to note that old paradigms such as forcing users to change passwords periodically – irrespective of whether a user account has been compromised or not – are now being challenged as discussed in this post. Here’s another interesting article that is also worth a read.

With vCenter Server 6.5, you can use the vSphere Web client to manage the Password Policy. This is accessed from the Administration -> Single Sign-On -> Configuration -> Polices tab as shown in Fig.1

The settings shown in Fig.1 are the default ones and apply to all accounts created within the vSphere SSO domain. As the default configuration stands, a user account’s password length must be in the range of 8-20 characters and comprise of a mix of alphanumeric and special characters. Also by default, a password can only have a maximum of 3 identical consecutive characters. This means that something like four4444 will be rejected.

Furthermore, passwords have a 90-day expiration day and a user is prevented from using any of 5 previously used passwords. If you find these restrictions to stifling, you can always relax them a bit by hitting the Edit button (Fig.1). It’s best, however, to stick with these settings if you have multiple admins and users with access to vCenter Server. On top of that make sure to use named accounts – a dedicated user account per administrator and users; rather than giving out the password to administrator@vsphere.local to all and sundry.

Note: VMware’s documentation states that the administrator@vsphere.local account and other system accounts are exempt from the policy. I am not 100% sure if this applies to all the policy enforced settings. What I’m sure of is that you definitely cannot assign non-complex passwords to the administrator account as Fig.2 illustrates. Of course, you can always edit the policy to override this setting. Also note that the administrator password will not expire.

The Lockout Policy

The lockout policy is accessible from the tab next to the Password Policy one. This policy keeps track of failed login attempts and will lock user accounts if the specified number of consecutive failed attempts is reached. A locked user account is eventually automatically unlocked unless the Unlock Time value has been set to 0, in which case an administrator must manually unlock the account. The default settings are as shown in Fig. 3a. These can be changed via the Edit button and Edit Lockout Policy dialog box.

NOTE:

• “The lockout policy applies only to user accounts, not to system accounts such as administrator@vsphere.local“.
• “The password policy applies only to user accounts, not to system accounts such as administrator@vsphere.local.”
• “Starting with vSphere 6.0, the vCenter Single Sign-On domain administrator, administrator@vsphere.local by default, is not affected by the lockout policy. The user is affected by the password policy.”

Testing time!

It’s always a good idea to first test any security policy you’re planning on deploying before moving on. This helps you rule out conflicting settings, misconfiguration and even product glitches that could unknowingly dampen your security hardening efforts.

Back to Fig.2, we know already that a user is not allowed to change or create a new password unless it meets the password complexity criteria set. What I’m really after, however, is to ensure that users accounts do get locked when after X number of failed attempts.

To test this out, I modified the Lockout Policy as per Fig.3b, setting the failed attempts limit to 3. I then created a user account called Jason from the vCenter Users and Groups page. Using PowerCLI, I then simulated a failed login attempt event by looping the Connect-VIServer commandlet with an incorrect password as follows;

To check out if a user account is locked or not, highlight the user account in vCenter Users and Groups using vSphere Web client, and look at the padlock icon. If the padlock is grayed out, the account is unlocked. The user account is otherwise locked if the padlock is active. To unlock it, just click on the padlock icon and click on Yes (see Fig. 5).

If you go to the Events screen, you’ll see a number of entries corresponding to the failed login attempts along with a description, at the bottom, for each. You could use something like vRealize Log Insight to alert you anytime events of this type are generated.

NOTE: Changes made to both the Password and Lockout policies take root immediately.

Wrap Up

Reviewing and tweaking password and lockout policies on vCenter Server is something you should include in any security hardening exercise with the ultimate aim being to better protect your vSphere environment. If you have Active Directory deployed, you might also want to look at adding vCenter Server, and ESXi, to further tighten up security as I explain in How to join a vCenter Server instance to Active Directory.