In-Depth

vSphere 6.0 Account Management

The upgrades are aimed at tightening security.

• By James Green
• 08/27/2015

One of the under-publicized enhancements VMware Inc. included with the release of vSphere 6.0 is bolstered account management functionality. These enhancements primarily have to do with increased security and manageability.

There are three areas where you can clearly identify improvements: new ESXCLI commands for managing user accounts, newly available "account lockout" policies, and an easier way to change password complexity rules than in the past. Thanks to these additions, vSphere is easier than ever to configure in such a way as to pass audit requirements and meet compliance standards.

ESXCLI Commands
In 5.x versions of vSphere, local users on ESXi could be managed via the vSphere Client, the vicfg-user tool, and via PowerCLI. Clearly missing was the ability to use an ESXCLI namespace to manage user accounts.

In vSphere 6.0, VMware has added a new namespace called account under the system tree. So now users can be listed and modified from the namespace esxcli system account [command]. As of the time of this writing, there are four commands available for managing user accounts:

• esxcli system account add
• esxcli system account set
• esxcli system account list
• esxcli system account remove

The Add, List and Remove commands need little explanation. Simply pass them the proper parameters and the respective command will take care of the rest. The set command is used to set the user's description, the user ID and the password. Set could be thought of as a command for "modify."

An account isn't much good without some permissions tied to it! To that end, there's another namespace called esxcli system permission. Using this namespace you can list, set or unset permissions for a given user or group. Assuming that the ESXi host has been joined to an Active Directory domain, this namespace can be used to grant access to AD users and groups. Using AD permissions to access ESXi hosts is a VMware best practice for security and auditability reasons; using "root" should be avoided if possible.

Three accounts exist on ESXi 6.0 by default: dcui, root and vpxuser. These accounts are used by the system, and local accounts should be created and assigned the proper role for anyone (or anything -- for example, service accounts) who will be accessing the system.

Account Lockout
With previous versions of ESXi, an unauthorized user could bang away at a host with bad passwords until their fingers bled, and there was no policy to prevent this. In vSphere 6.0, account locking is introduced. This includes configurable settings for the number of failed attempts before the lockout, as well as the lockout time (time before the account automatically unlocks).

This setting is changed by modifying an ESXi Advanced Setting. Security.AccountLockFailures will change the number of failures before locking the account. The default value is 10. Security.AccountUnlockTime will change the time until the account is automatically unlocked. The default value for that is 2 minutes.

This is a nice feature, but there's a major caveat: For obvious reasons, the root account (as well as the dcui account) can't be locked out. Because everyone knows that for the last decade, the root account has been the primary method of accessing ESXi, I don't see why an attacker wouldn't still just sit there and hack away at the root account. So as helpful as a lockout policy might be in an audit situation, I don't feel it's actually that helpful from a security standpoint.

Password Complexity
The ability to change password complexity requirements in ESXi isn't new. In 5.x versions, it was possible to modify complexity requirements by modifying the values passed to pam_passwdqc.so (the complexity module) in /etc/pam.d/passwd. This method was somewhat painful, especially when attempting to modify hosts en masse. The process is dramatically easier in 6.x, thanks to the ability to use the VIM API to modify the complexity rules (via the OptionManager.updateValues method). The setting is also exposed as an Advanced Setting called Security.PasswordQualityControl. This can be modified from the GUI using PowerCLI. No matter which route is taken: either by API or by PowerCLI/GUI, modifying password complexity rules is a cinch now.

With all the updates to vSphere 6.0 in the area of account management, passing compliance audits is easier for the VM admin. This can save your business money, and makes one less thing for administrators to want to pull their hair out over.