6.0.3

See “Conguring Smart Card Authentication for ESXi,” on page 196.
ESXi Account Lockout
Starting with vSphere 6.0, account locking is supported for access through
SSH and through the vSphere Web Services SDK. The Direct Console
Interface (DCUI) and the ESXi Shell do not support account lockout. By
default, a maximum of ten failed aempts is allowed before the account is
locked. The account is unlocked after two minutes by default.
See “ESXi Passwords and Account Lockout,” on page 157.
Security considerations for standalone hosts are similar, though the management tasks might dier. See the
vSphere Administration with the vSphere Client documentation.
Securing vCenter Server Systems and Associated Services
Your vCenter Server system and associated services are protected by authentication through vCenter Single
Sign-On and by authorization through the vCenter Server permissions model. You can modify the default
behavior, and you can take additional steps to protect access to your environment.
As you protect your vSphere environment, consider that all services that are associated with the
vCenter Server instances must be protected. In some environments, you might protect several
vCenter Server instances and one or more Platform Services Controller instances.
Harden All vCenter Host
Machines
The rst step in protecting your vCenter environment is hardening each
machine on which vCenter Server or an associated service runs. Similar
considerations apply to a physical machine or a virtual machine. Always
install the latest security patches for your operating system and follow
industry standard best practices to protect the host machine.
Learn about the vCenter
Certificate Model
By default, the VMware Certicate Authority provisions each ESXi host, each
machine in the environment, and each solution user with a certicate signed
by VMCA. The environment works out of the box, but if company policy
requires it, you can change the default behavior. See Chapter 3, “vSphere
Security Certicates,” on page 65.
For additional protection, be sure to explicitly remove expired or revoked
certicates and failed installations.
Configure vCenter
Single Sign-On
vCenter Server and associated services are protected by the vCenter Single
Sign-On authentication framework. When you rst install the software, you
specify a password for the [e-mail] user, and only that
domain is available as an identity source. You can add other identity sources,
either Active Directory or LDAP, and set a default identity source. Going
forward, users who can authenticate to an identity source can view objects
and perform tasks if they are authorized to do so. See Chapter 2, “vSphere
Authentication with vCenter Single Sign-On,” on page 19.
Assign Roles to Users
or Groups
For beer logging, associate each permission you give on an object with a
named user or group and a predened role or custom role. The vSphere 6.0
permissions model allows great exibility through multiple ways of
authorizing users or groups. See “Understanding Authorization in vSphere,”
on page 136 and “Required Privileges for Common Tasks,” on page 150.
Be sure to restrict administrator privileges and the use of the administrator
role. If possible, do not use the anonymous Administrator user.
Set up NTP
Set up NTP for each node in your environment. The certicate infrastructure
requires an accurate time stamp and does not work correctly if the nodes are
out of sync.
Chapter 1 Security in the vSphere Environment
VMware, Inc. 13