In-Depth

Manage vSphere 6 Security Policy Via ESXCLI

New settings allow you to change account lockout and password complexity rules in minutes, saving huge amounts of time.

• By James Green
• 10/14/2015

Security is an ever-present consideration in modern IT. This year has seen major breaches of companies across all industries, including healthcare, finance and even security. That's right -- even security companies like Kaspersky Lab and LastPass suffered compromises to company and customer data. In light of the growing threat, it's vital that IT takes every measure available to protect itself and its customers' data.

In vSphere 6.0, VMware added capabilities regarding account lockout and password complexity requirements which can be configured via Advanced System Settings on the host. It was previously possible to change some -- but not all -- of these settings from the command line by editing configuration files directly. The addition of these Advanced Settings parameters means that updating these values across an entire organization will take minutes, as opposed to hours or days. It also means that it's simple to add these settings to a Host Profile, ensuring that all new hosts added in the organization have the same policies applied.

Account Lockout
Setting an account lockout policy is critical to ensuring that attackers aren't able to compromise a system. In earlier versions of vSphere, the local accounts (including ‘root') did not lock out. This meant that an attacker with SSH access to an ESXi host could sit and bang away at it all day with no consequences. With a weak enough password and enough allowed attempts, a vSphere system could certainly be brute-forced. This is why VMware's recommendation is to keep SSH disabled on ESXi hosts unless it's actively being used by administrators.

It's great that accounts can be locked out now, but what happens if the administrator fat-fingers his or her password a few times and suddenly can't access their own equipment? Never fear; the lockout policy only applies to SSH and the vSphere Web Services SDK. The DCUI (the interface you see when looking at a monitor directly connect to the ESXi host) and ESXi Shell (the command line you can access from being directly connected to the ESXi host) do not lock out. This means that if remote access becomes problematic because of a few password failures, one can always go directly to the host and get access. Hopefully, this can even be done via a lights-out management interface (we IT folks hate exercise).

There are two Advanced System Settings to be configured in regard to lockout. The first setting specifies how many failed attempts are allowed before the account is locked out. This value can be changed to a value from 1 to 100, and can also be set to 0 to disable lockout entirely.

The second setting specifies the amount of time that the account will stay locked for. After the timer expires, the account can be accessed again. This value is specified in seconds, and can be anything from 1 second to 3600 seconds (1 hour). Zero is not a valid value in this case.

The Advanced System Settings, seen in Figure 1, are:

• Security.AccountLockFailures
• Security.AccountUnlockTime

They can be accessed via the vSphere Web Client by highlighting a host, selecting the Manage tab, selecting the Settings button, and choosing Advanced System Settings from the menu on the left side of the work pane. Note that the field with all the values responds to keyboard input, so highlighting the list and typing ‘se' will navigate directly to this value.

Password Complexity
I mentioned in the last section that a password that was too weak could be compromised via a brute force attack. This is where an attacker just guesses passwords as fast as possible until they get it right.

In 2015, brute force attacks should be next to useless. Unfortunately, due to a lack of awareness on how to prevent them, they're still successful far too frequently. The first step in reducing the potential for success in a brute force attack is to set the account lockout policy. Consider the default policy in vSphere 6: after 10 attempts, the account will be locked for two minutes before allowing more attempts. With this setting, it would take roughly three weeks straight to attempt 100,000 passwords. That sounds like a lot, until you realize that a strong eight-character password has around 100 billion possible combinations.

I'm no mathematics Ph.D., but I do understand that increasing the length of a password by one character makes it literally exponentially harder to crack with brute force. This means that it's in an organization's best interest to enforce a password policy that not only requires a number of different character types (e.g., uppercase, lowercase, numbers, special characters) but also requires a certain length. vSphere 6.0 makes changing this requirement easier to do. And more importantly, the changes make it easier to automate the configuration of this across a large environment.

Administrators have already had the ability to modify the password complexity requirements by manually editing the file /etc/pam.d/passwd. Because the new Advanced System Settings parameter is only updating this file via the GUI, the values that need to be changed remain the same. In vSphere 6.0, the default settings for this value look like this:

retry=3  min=disabled,disabled,disabled,7,7

That's rather intimidating, isn't it? Fortunately, all the information needed to understand it can be found in the man page for the pam_passwdqc module. I'll break it down here, as it's really not as confusing as it looks.

• retry=3.  This setting is simply the number of times the module will ask for a new password if the user fails to provide a sufficiently strong password and enter it twice the first time.
• min=disabled…  This setting takes five positional parameters, each one representing a different kind of password complexity. The position reflects the level of complexity required, and the value reflects the length required:
• N0 is used for passwords consisting of characters from one character class only. The character classes: digits, lower-case letters, upper-case letters and other characters. There is also a special class for non-ASCII characters, which could not be classified, but are assumed to be non-digits.
• N1 is used for passwords consisting of characters from two character classes that do not meet the requirements for a passphrase.
• N2 is used for passphrases. Note that besides meeting this length requirement, a passphrase must also consist of a sufficient number of words (see the passphrase option below).
• N3 and N4 are used for passwords consisting of characters from three and four character classes, respectively.

Based on this information, I conclude that the default policy in vSphere 6.0 is that passwords must contain either three or four character classes, and they must be at least seven characters long. As mentioned earlier, changing this setting to eight or nine could substantially increase the strength of the passwords.

Figure 2 shows the value of the default configuration being viewed in the vSphere Web Client. Requiring passwords to be eight characters long instead of seven would be a simple matter of changing the sevens to eights.

Scripting the Changes
Although it's nice to be able to modify these settings from the GUI, the most value in my opinion comes from being able to automate these changes. It's historically been possible to do this with a Host Profile, and this makes doing it with a Host Profile simpler. But I'm a big fan of PowerCLI, and I'll show below that updating these settings across 200 hosts would be a simple matter of about 10 lines of PowerCLI.

I'll explain the steps first in pseudo-code, and then show a sample of a script that could complete the task at hand. The script that will follow will perform these steps:

• Connect to vCenter using stored credentials
• Create an array of ESXi objects (one for each host managed by the vCenter Server)
• Update the advanced configuration settings by piping the array of hosts to the Set-VMHostAdvancedConfiguration cmdlet

This took me about five minutes to whip up, and four of them were spent remembering how to create and store the credentials. This is why it's so exciting that these new configuration options are available. Here's the script, and a screenshot (Figure 3) of it running.

$creds = Get-VICredentialStoreItem -File C:\creds.xml

Connect-VIServer -Server $creds.Host -User $creds.User -Password $creds.Password

$hosts = Get-VMHost

$hosts | Set-VMHostAdvancedConfiguration Security.AccountLockFailures -Value 5
$hosts | Set-VMHostAdvancedConfiguration Security.AccountUnlockTime -Value 240
$hosts | Set-VMHostAdvancedConfiguration Security.PasswordQualityControl -Value "retry=3 min=disabled,disabled,disabled,8,8"

Figure 3 shows the results of the script. Note that the Set-VMHostAdvancedConfiguration cmdlet I'm using is apparently deprecated, and I should be using Set-AdvancedSetting. The problem is that the new cmdlet requires me to pass it an AdvancedSetting object, and I didn't want to go rewrite the script to get that.