Data Center Virtualization Certification: VCP6.5-DCV Exam Guide

5 (2 reviews total)
By Andrea Mauro , Paolo Valsecchi
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Free Chapter
    Configuring and Administering vSphere 6.x Security

About this book

This exam guide enables you to install, configure, and manage the vSphere 6.5 infrastructure in all its components: vCenter Server, ESXi hosts, and virtual machines, while helping you to prepare for the industry standard certification.

This data center book will assist you in automating administration tasks and enhancing your environment’s capabilities. You will begin with an introduction to all aspects related to security, networking, and storage in vSphere 6.5. Next, you will learn about resource management and understand how to back up and restore the vSphere 6.5 infrastructure. As you advance, you will also cover troubleshooting, deployment, availability, and virtual machine management. This is followed by two mock tests that will test your knowledge and challenge your understanding of all the topics included in the exam.

By the end of this book, you will not only have learned about virtualization and its techniques, but you’ll also be prepared to pass the VCP6.5-DCV (2V0-622) exam.

Publication date:
August 2018


Configuring and Administering vSphere 6.x Security

Security has become a critical aspect of every infrastructure, but for virtual environments, there are some advantages compared to the traditional infrastructures.

One of the main pillars of system virtualization is the Virtual Machine (VM) isolation principle, which protects a VM from other VM attacks, while also protecting the virtualization host from possible VM attacks. Of course, the isolation properties don't work for the network layer; other solutions are required to increase network security, such as VMware NSX.

While isolation protects the host level from the VM level, in some cases, it's also necessary to protect the VM level from the underlying infrastructure; for example, in a public cloud infrastructure, the consumer might have some concerns about how the provider manages the security and privacy of their data.

VMware vSphere 6.5 has introduced some important new security features, such as VM encryption, encrypted vMotion, and Secure Boot Support for VMs and ESXi.

Practicing what you learn in this chapter will be key to reinforcing your skills and your preparation for the exam. The last part of HOL-1811-01-SDC (vSphere v6.5 - What's New) and the lab HOL-1811-04-SDC (vSphere Security - Getting Started) include the encrypted VM and encrypted vMotion features.

The following topics will be covered in this chapter:

  • Understanding role-based access control in vSphere
  • Tuning and hardening guidelines for vCenter, ESXi, and VMs
  • Working with encryption and secure VMs


Objective 1.1 – Configure and administer role-based access control

Role-based access control (RBAC) is a common approach to managing authorizations and permissions, based on specific roles assigned to specific users or groups.

In VMware vSphere, roles are just sets of privileges used to authorize users (or groups) for specific vSphere inventory objects.

VMware vSphere provides the following four categories of permissions, from the most general to the most specific:

  • Group membership in the SSO domain: Some users of the vCenter Single Sign-On (SSO) domain, such as the default administrator, have specific, implicit permissions. For more information, refer to Objective 1.3.
  • Global permissions: These permissions are applied to a global root object, and can propagate to all objects. Also, they can span across different VMware products (for example, vSphere and vRealize Orchestrator).
  • vCenter permissions: This is the main model used by vSphere Server to assign granular permissions to objects in different inventories.
  • ESXi local permissions: Each ESXi host has local permissions, local rules, and local users. For hosts managed by vCenter, vCenter permissions are usually used. But local permissions still exist, and they are the only permission model for standalone ESXi hosts.

This chapter will mainly focus on vCenter and global permissions, as required by the exam questions. Objective 1.3 will provide more information about SSO-related concepts. ESXi local permissions are not covered in detail, but the RBAC model is quite similar to the one used by the vCenter permissions.

Objective 1.1 for VCP65-DCV and VCP6-DCV is the same, because there weren't any major changes in role-based access control from vSphere 6.0 to vSphere 6.5.

The official vSphere 6.5 Security Guide contains detailed information about authentication, authorization, and different permission configurations, and can be accessed at

Compare and contrast propagated and explicit permission assignments

The VMware vSphere RBAC model is based on the following concepts:

  • Inventory: A collection of multiple virtual or physical objects managed by vCenter, in a hierarchical organization. In vCenter Server, there are four different types of inventories, with different types of objects. For more information, refer to Table 1.1.
  • Object: Each object in the vCenter inventory has associated permissions, or inherits them from its parent object.
  • User and Group: In vCenter Server, users are authenticated through the SSO component; in ESXi, users are authenticated with a local authentication or AD authentication (refer to Objective 1.3). Note that you can only assign privileges to authenticated users, or groups of authenticated users.
  • Privilege: This is the ability to access or execute specific functions, tasks, and operations.
  • Role: Roles are just groups of privileges, used to make permissions management much easier.
  • Permission: Permissions specify which role matches a specific group of users, for a specific object.

The following table summarizes the types of inventories, with the different types of objects:

vCenter inventory

Related objects

Hosts and clusters

  • vCenter Servers
  • Data centers
  • Folders
  • Clusters
  • Hosts
  • Resource pools
  • vApps
  • VMs

VMs and templates

  • vCenter Servers
  • Data centers
  • Folders
  • vApps
  • VMs
  • Templates

Storage (Data stores and data store clusters)

  • vCenter Servers
  • Data centers
  • Folders
  • Data store clusters
  • Data stores


  • vCenter Servers
  • Data centers
  • Folders
  • Portgroups
  • Distributed Virtual Switches
  • Distributed Portgroups
  • Distributed Uplinks
Table 1.1: Permission, role, user/group, and object

VMware vCenter permissions are assigned to objects in the vCenter inventory hierarchy by specifying which user or group has which privileges on that object. Then, to specify the privileges, you use specific roles.

The same concepts are used for ESXi local permissions, but with some limitations; for example, the predefined roles are limited, and users/groups are limited to local ESXi and/or Active Directory (AD) domains. Also, there is only a single inventory.

The different vCenter inventories can be used to provide different levels of object hierarchies, and to group objects in different ways. Note that some objects (such as VMs) can exist in multiple inventories.

Later sections in this chapter will help you to understand how permissions are propagated through the object hierarchy.

It is a good practice to assign only those permissions that are required to increase the security, and to have a clear permissions structure.

Global permissions are applied to a global root level, instead of a specific object. In this way, a global permission grants privileges for all objects in all inventories, but only if you assign a global permission by selecting the Propagate to children option. Without the propagation, a user will only have access to some global functionalities, such as creating roles. Also, remember that global permissions can span different VMware products.

Note that vSphere tags are a specific vCenter object type, with their own permission propagation model. This is because a tag object is not a child of vCenter, but is created at the vCenter root level. If you have multiple vCenter Servers in linked mode, then all tag objects will be shared across all vCenter Server instances. To learn how permissions are applied to tag objects, you can refer to the vSphere 6.5 Security Guide (

View/sort/export user and group lists

User and group lists can be displayed and sorted from the vCenter Web Client in the Users and Groups menu, located via Home | Administration | Single Sign-On.

Note that you need an SSO admin privilege to access this page. For more information about SSO, refer to Objective 1.3.

You can choose a specific domain (identity source, as described later). The Users tab will show the users, and the Groups tab will show the groups.

To sort a column, just click on the column heading. To change the order direction (ascending or descending), just click on it again. To show or hide a column, right-click on any of the column headings and select or deselect the name of the relevant column.

You can export the displayed list to a file (in a Comma-Separated Values (CSV) format) by selecting the Export button, as follows:

Figure 1.1: User lists in the vsphere.local domain

Add/modify/remove permissions for users and groups on vCenter Server inventory objects

As described previously, a permission is a match between an object in the vCenter object hierarchy, a user (or a group), and a role.

With vSphere Web Client, you can manage vCenter permissions for users or groups by selecting one object from one of the vCenter inventories and then clicking on the Permissions tab:

Figure 1.2: vCenter permissions on a specific object

With the selected toolbar, you can add, edit, or remove selected permissions.

For Global Permissions, the toolbar remains the same, but you must select the Global Permissions menu that is located at Home | Administration | Access Control:

Figure 1.3: Global permissions
You will need an SSO admin privilege to access this page. For more information about SSO, refer to Objective 1.3.

Remember that global permissions can span more vCenter servers in the same SSO domain.

When you add or modify a permission, you need to select one or more users (or groups), a specific role, and whether the permission will be propagated in the objects hierarchy (refer to the next section for more information):

Figure 1.4: Modifying global permissions
In order to assign users or groups sets of privileges, you will need the vCenter Modify.permissions privilege.

For more information, refer to the vSphere 6.5 Security Guide (

Determine how permissions are applied and inherited in vCenter Server

If you assign a permission to an object, it can be propagated down the objects hierarchy. The propagation is enabled by default, but you can disable propagation for each permission by checking the Propagate to children checkbox, as follows:

Figure 1.5: Disabling permissions propagation

VMware vCenter objects are hierarchical. This means that permissions (with the Propagate to children option) will be inherited (all child objects inherit from their parent objects). The following diagram, from the vSphere Security Guide, shows the entire objects hierarchy:

Figure 1.6: vCenter objects hierarchy

Also, the global permissions can be propagated, or not propagated, and the different inventories, which happens with the vCenter permissions in the objects hierarchy.

Note that propagation is not necessarily enforced. The resultant permission is always more specific in the hierarchy. A permission defined at the child object level always overrides a permission propagated from parent objects.

Note that some objects can exist in different inventories (such as VMs in Hosts and Cluster, VMs, and Templates inventories). This means that different permissions can be applied in different views.

What are the differences between global permissions and vCenter permissions applied at the vCenter object level, if you are using propagation in both cases? The vCenter object exists in all four of the inventories, so the vCenter permissions will only be propagated on specific objects of the selected inventory. With global permissions, the propagation is on all objects!

For more information, refer to the vSphere 6.5 Security Guide (

Create/clone/edit vCenter Server Roles

In VMware vCenter, there are different types of roles, as follows:

  • Default roles: These are predefined on vCenter Server, and cannot be modified or deleted.
  • Sample roles: These are also predefined, and are used to manage certain types of tasks. They can be cloned, modified, or removed.
  • Custom roles: These can be defined by the administrators, and are created from scratch or cloned from existing roles.

The following table summarizes the predefined roles:



System role

  • Administrator role
  • No cryptography administrator role
  • No access role
  • Read-only role

Sample role

  • VM power user role
  • VM user role
  • Resource pool administrator role
  • VMware consolidated backup user role
  • Data store consumer role
  • Tagging admin role
  • Network administrator role
  • Content library administrator role
Table 1.2: vCenter predefined roles

Usually, role names are quite descriptive about what kinds of tasks will be permitted, but you can edit them to see the complete list of privileges.

You can manage the vCenter roles using the vSphere Web Client by selecting the Roles menu and navigating to Home | Administration | Access Control:

Figure 1.7: Managing vCenter roles

The selected toolbar will allow you to create, clone, modify, or delete a role.

To create a new role from scratch, just click on the Create role action icon, type a name for the new role, and then select the right privileges for the role.

To clone an existing role into a new role, just select the desired source role and click on the Clone role action icon, then type a name for the new role. At that point, you can modify it with the Edit action icon.

Instead of creating a new role from scratch, in order to avoid potential permissions mistakes, VMware suggests cloning an existing role.

For more information, you can refer to the vSphere 6.5 Security Guide (

Configure VMware Identity Sources

When a user logs in to a vSphere environment, the vCenter SSO will validate the user's credentials through one of the configured identity sources.

If the user also specifies the domain name (using the domain\user or [email protected] format), the authentication will match the specific identity source.

For more information on the SSO components, you can refer to Objective 1.3.

Identity sources are some kind of centralized user and group system, usually some type of authentication domains, and vSphere supports the following:

  • SSO domain: This is a default identity source, created with the configuration of the PSC.
  • AD (native): When the SSO is joined to an AD domain, it is possible to use the domain or the forest as an authentication source.
  • LDAP (AD): The users are defined on an AD domain, but you don't have to join the SSO to the AD domain.
  • LDAP (OpenLDAP): The users are defined on an OpenSource LDAP server.
  • Local OS: The users are defined in the SAM file (for Windows-based SSO) or the /etc/passwd and /etc/shadow files (for Linux-based SSO).
Note that the SSO domain is always enabled, and is included in the available identity sources.

You can add new identity sources or remove existing ones, and you can also change the default source.

Note that you must have vCenter SSO administrator privileges in order to manage the identity sources.

From the vSphere Web Client, just select the Configuration menu, located at Home | Administration | Single Sign-On. Then, select the Identity Sources tab:

Figure 1.8: SSO identity sources

To configure a new identity source, select Identity Sources and click on the plus icon (+). Then, choose the proper identity source type and enter the specific identity source settings.

For example, for AD, you will see a screen like the following:

Figure 1.9: Adding an AD domain as a new identity source
When an identity source is added, all users and groups in the new domain can be authenticated by SSO. However, in vCenter, they will have the No access role.

For more information about authentication, see the Platform Services Controller (PSC) 6.5 Administration Guide (

Apply a role to a user/group and to an object or group of objects

Once a role has been defined, you can use it to assign specific authorizations to authenticated users or groups.

Whenever possible, it's recommended to assign permissions to groups instead of users, for better and more flexible permissions management.

The entire procedure was described previously, in the Adding/modifying/removing permissions for users and groups in vCenter Server inventory objects section.

You will need the Permissions.Modify privilege for the specific objects to modify the permissions and roles.

Note that some objects may reference other objects, such as VMs that include data store objects (for the virtual disk locations) and network objects (for the connected portgroups). In those cases, you will need to apply for the right roles in all of the different inventories.

Change permission validation settings

As described previously, the SSO component can have different identity sources. When a directory service (such as AD or LDAP) is used, the SSO regularly validates users and groups on the directory domain. This validation occurs at regular intervals, specified in the vCenter Server settings.

You can view or change these settings with the vSphere Web Client by selecting your vCenter Server in the vSphere object navigator and then selecting the Configure tab and clicking on General under Settings.

Select the User directory area, and view or change the values as needed:

Figure 1.10: vCenter Server settings—User directory

There are different options and settings, as follows:

  • User directory timeout: This is the maximum amount of time, in seconds, that SSO allows a search to run on the selected domain source. For large domains, this can be increased.
  • Query limit: This helps you to define whether there must be a maximum number of users and groups that vCenter can display.
  • Query limit size: This is the maximum number of users and groups that vCenter displays in the Select Users or Groups dialog box. If you enter 0 (zero) or remove the previous option, all users and groups will appear.
  • Validation: This is used to define whether validation is enabled or disabled.
  • Validation period: This is how often, in minutes, validation is performed.

For more information, refer to the vCenter Server and Host Management Guide (

Determine the appropriate set of privileges for common tasks in vCenter Server

Many tasks require permissions on multiple objects in the inventory. Without all of them, the task cannot be completed successfully.

The vSphere 6.5 Security Guide ( contains several examples of combined sets of permissions required for common tasks, with some hints on how to manage permissions to perform generic tasks.

The following table, from the VMware guide, shows some examples of common VM administration tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used (instead of configuring the single privileges):


Required privileges

Applicable role

Create a VM

On the destination folder or data center:

  • Virtual machine | Inventory | Create new
  • Virtual machine | Configuration | Add new disk (if creating a new virtual disk)
  • Virtual machine | Configuration | Add existing disk (if using an existing virtual disk)
  • Virtual machine | Configuration | Raw device (if using an RDM or SCSI pass-through device)


On the destination host, cluster, or resource pool, navigate to Resource | Assign virtual machine to resource pool

Resource pool administrator or administrator

On the destination data store or the folder that contains the data store, navigate to Datastore | Allocate space

Data store consumer or administrator

On the network that the VM will be assigned to, navigate to Network | Assign network

Network consumer or administrator

Power on a VM

On the data center in which the VM is deployed, navigate to Virtual machine | Interaction | Power On

VM power user or administrator

On the VM or the folder of VMs, navigate to Virtual machine | Interaction | Power On

Deploy a VM from a template

On the destination folder or data center, navigate to Virtual machine | Inventory | Create from existing or Virtual machine | Configuration | Add new disk


On a template or folder of templates, navigate to Virtual machine | Provisioning | Deploy template

On the destination host, cluster, or resource pool, navigate to Resource | Assign virtual machine to resource pool

On the destination data store or folder of data stores, navigate to Datastore | Allocate space

Data store consumer or administrator

On the network that the VM will be assigned to, navigate to Network | Assign network

Network consumer or administrator

Take a VM snapshot

On the VM or a folder of virtual machines, navigate to Virtual machine | Snapshot management | Create snapshot

VM power user or administrator

Install a guest operating system on a VM

On the VM or folder of VMs, navigate to:

  • Virtual machine | Interaction | Answer question
  • Virtual machine | Interaction | Console interaction
  • Virtual machine | Interaction | Device connection
  • Virtual machine | Interaction | Power Off
  • Virtual machine | Interaction | Power On
  • Virtual machine | Interaction | Reset
  • Virtual machine | Interaction | Configure CD media (if installing from a CD) or
    Configure floppy media (if installing from a floppy disk)
  • Virtual machine | Interaction | VMware Tools install

VM power user or administrator

On a data store that contains the installation media ISO image, navigate to Datastore | Browse datastore (if installing from an ISO image on a data store)

On the data store to which you upload the installation media ISO image, navigate to Datastore | Browse datastore or Datastore | Low level file operations

Migrate a VM with vMotion

On the VM or folder of VMs, navigate to:

  • Resource | Migrate powered on virtual machine
  • Resource | Assign Virtual Machine to Resource Pool (if the destination is a different resource pool from the source)

Resource pool administrator or administrator

On the destination host, cluster, or resource pool (if they are different from the source), navigate to:

  • Resource | Assign virtual machine to resource pool

Cold migrate (relocate) a VM

On the VM or folder of VMs, navigate to:

  • Resource | Migrate powered off virtual machine
  • Resource | Assign virtual machine to resource pool (if the destination is a different resource pool from the source)

Resource pool administrator or administrator

On the destination host, cluster, or resource pool (if different from the source), navigate to:

  • Resource | Assign virtual machine to resource pool

On the destination data store (if it is different from the source), navigate to Datastore | Allocate space

Data store consumer or administrator

Migrate a VM with Storage vMotion

On the VM or folder of VMs, navigate to Resource | Migrate powered on virtual machine

Resource pool administrator or administrator

On the destination data store, navigate to Datastore | Allocate space

Data store consumer or administrator

Table 1.3: Required privileges for common tasks

These are just examples, but in most cases, you will need to build your own custom role (or set of roles).

Other software or solutions based on vSphere may specify the right privileges that are needed in order to build custom roles with minimum privileges.

Compare and contrast default system/sample roles

As described in the Creating/cloning/editing vCenter Server roles section, there are two different types of predefined roles:

  • System roles (cannot be modified or deleted):
    • Administrator role: With this role, you can correspond to all privileges. By default, users with this role are the SSO administrator, the vCenter root (or administrator) user, and ESXi vpxuser (used by the vCenter agent).
    • No cryptography administrator role: This role has the same privileges as the administrator role, except for cryptographic operations privileges. This means that users cannot encrypt or decrypt VMs, or access encrypted data.
    • Read-only role: With this role, it's possible to view the details of the object, but it's not possible to change anything.
    • No access role: With this role, it's not possible to view or change the object in any way. By default, new users and groups are assigned to this role.
  • Sample roles (can be cloned, modified, or removed):
    • VM administrator: This role allows for complete and total control of a VM, including some related host operations.
    • VM power user: This role grants rights only to a VM, including changing the settings or creating snapshots.
    • VM user: This role grants access rights exclusively to VMs, with limited functions, such as powering on, powering off, or resetting the VM, or running media from the virtual discs.
    • Resource pool administrator: This role is permitted to create resource pools and assign those pools to VMs.
    • Data center administrator: This role permits adding new data center objects.
    • VMware consolidated backup user: This role is required for the old VCB framework, but is a good starting point for other backup products.
    • Data store consumer: This role allows using space on a data store.
    • Network consumer: This role allows assigning a network to a VM or a host.

For more details, see Table 1.2 or the vSphere 6.5 Security Guide (

Determine the correct permissions needed to integrate vCenter Server with other VMware products

Sample roles can match specific integration requests. Also, Table 1.3, from the vSphere 6.5 Security Guide, showed some examples of common tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used.

However, for other VMware products (and third-party products), you may need a specific set of permissions, and this list is usually provided by the related product documentation.

Also, remember that global permissions can span different VMware products. For example, for vCenter Orchestrator, you can use global permissions.


Objective 1.2 – Secure ESXi and vCenter Server 2

To increase the security of ESXi, vCenter, and other vSphere components, you will need to use different approaches, as follows:

  • Protecting the physical layer: For example, for the networking part, use dedicated VLAN for different traffic.
  • Securing network communications: This at least applies to infrastructural components. By default, management traffic is already encrypted. Note that one new feature of vSphere 6.5 is the ability to also encrypt vMotion traffic.
  • Applying the minimum privileges: Limit all the services, permissions, access to minimize the attack surface.
Objective 1.2 for VCP65-DCV and VCP6-DCV is quite different, due to the security and hardening changes from vSphere 6.0 to vSphere 6.5.

Hardening is a process that enhances the security of a system, a service, or an entire infrastructure, by reducing the attack surface and minimizing the possible vulnerabilities and related risks.

VMware has built in a set of Security Hardening Guides (, including one related to the vSphere environment. The vSphere 6.5 Security Configuration Guide is a spreadsheet file with several possible hardening actions and guidelines, each classified with a risk profile. There are also some example scripts, for enabling security automation.

The vSphere 6.5 Security Configuration Guide isn't a compliance tool; it can be used to reach compliance, but it's not automatically enforced. It's a set of guidelines that attempts to explain security risks, but there are other solutions for mitigating them.

The Security Guide contains in-depth information on how to secure ESXi hosts ( and vCenter components (

Configure encrypted vMotion

This is a new option in vSphere 6.5 (but only for the Enterprise Plus edition), in order to secure the vMotion network traffic.

The vMotion encryption feature isn't simply an encrypting of the entire network channel for the vMotion traffic; it's a per-VM setting. There aren't certificates to manage or import on the infrastructural side.

This will be discussed later, in Objective 1.4, because it's related to the VM options.

On the infrastructural side, you will need to configure the proper key servers (as described in Objective 1.3).

Describe ESXi Secure Boot

Unified Extensible Firmware Interface (UEFI) is a replacement for the traditional BIOS firmware, and is supported for VM from virtual hardware 7.

Secure boot is part of the UEFI firmware standard, where the UEFI firmware validates the digital signature of the operating system and its bootloader, to ensure that the bootstrap sequence starts only a properly signed system, including drivers and applications.

Starting with vSphere ESXi 6.5, it's possible to have secure boot for both ESXi and VMs.

For ESXi, the secure boot can verify each VIB by using its digital sign. At boot time, the already validated ESXi VMkernel will validate each VIB against the firmware-based certificate:

Figure 1.11: ESXi secure boot
For more information on how to enable this feature, and also some possible issues (during the upgrade process, for example), see

For the secure boot options for VMs, see Objective 1.4.

Harden ESXi hosts

To increase the protection of ESXi hosts against possible attacks and unauthorized access, consider the following options:

  • Limit user privileges and access: One aspect is using the RBAC model (described in Objective 1.1) to limit user privileges. But, you also have to use a centralized authentication, limit the authorized users, restrict access to ESXi management adapter, and enforce security policies (such as password expiration and password complexity).
  • Limit shell access: ESXi shell and ESXi SSH access have several privileged accesses, and permit executing several commands from the CLI. For this reason, this type of access must be closed or limited. Lockdown mode (as described later) can be effective for limiting that type of access.
  • Limit services: By default, ESXi only runs essential services, and any services that are not needed are stopped. Note that third-party services, such as some hardware vendor agents, should be limited, or at least validated.
  • Limit network connections: ESXi has a built-in firewall (starting from ESXi 5.0), and, by default, it is closed on most ports. When you enable a service, it also opens the right ports. The personal firewall does not protect from DoS attacks, so keep your ESXi VMkernel interfaces on protected networks, and continue to use perimeter firewalls.
  • Use secure connections: By default, most of the communications are secured by the SSL layer, and all weak ciphers are disabled (this can vary in the different builds of vSphere). Also, VMware vSphere 6.0 introduced a certification authority (described in Objective 1.3) to help with certification management.
  • Update your environment: VMware Update Manager (VUM) can simplify host patching. With the VCSA, the vCenter management can also be simplified (using VAMI).
  • Check the VMware Security Advisories ( This site has a list of possible security vulnerabilities for VMware products, and related remediation or mitigation.

Also, in order to mitigate security risks in ESXi, there are some built-in security settings, as follows:

  • Shell access: ESXi Shell and SSH are disabled, by default. It is usually safe to keep both ESXi Shell and SSH access disabled, preventing direct access to the ESXi CLI. Note that in this case, you can still use esxcli remotely, as well as other remote CLI tools!
  • Firewall: Usually, there are a few ports open by default, and ports are automatically open on the firewall if there are some services that need specific ports. Although you can manually open ports or build custom ESXi firewall rules, try to keep the management automatic.
  • Services: Following the minimum privilege approach, ESXi only runs required services, and new services are automatically started if a specific feature requires them.
  • Secure protocols: By default, weak ciphers are disabled, and communications from clients are secured by SSL. Starting with vSphere 6.5, the TLS protocol versions 1.0, 1.1, and 1.2 are enabled, by default. Also, see VMware KB 2147469 (—Managing TLS protocol configuration for vSphere 6.5.
  • Web server: A custom Tomcat web service is used to provide access from the web client. The service has been hardened to improve its security.
  • Bugs: VMware usually releases security patches, in case of possible security issues affecting ESXi (or other components). With VUM, you can easily apply those patches.
  • Secure Boot: VMware ESXi 6.5 supports secure booting, as described previously.

Enable/configure/disable services in the ESXi firewall

As stated previously, only the required ports are open on the ESXi firewall. But, using the vSphere Web Client, it's possible to manage incoming and outgoing firewall rules. Usually, firewall rules are related to specific ESXi services.

It's possible to manage service settings and/or firewall rules in the Security Profile menu, under the Configure tab of each host:

Figure 1.12 ESXi security profile

The first part (Firewall) shows all active incoming and outgoing rules, with their corresponding firewall ports.

Firewall rules can be modified by clicking on the Edit button in the Firewall section:

Figure 1.13 Editing the security profile—firewall rules

You can enable or disable a specific firewall rule, and you can also specify which logical network address is authorized to use the selected service.

Until vSphere 6.0, it was also possible to build custom firewall rules, but not from the UI. For more information, see KB 2008226 (—Creating custom firewall rules in VMware ESXi 5.x.

The second part (Services) shows all of the configured services, and their statuses. It's possible to manage them with the Edit button, in the Services section:

Figure 1.14: Editing security profile—services

In the Service Details section, you can see the status, and also perform some tasks:

  • Manage the services status: Use the Start, Stop, or Restart buttons
  • Define how services are started: With the Startup Policy, you can choose how each service must be started, with one of the following three startup policies:
    • Start and stop with host
    • Start and stop manually
    • Start and stop with port usage
Starting a service automatically opens the network ports that are required by the service.

For more information, see the vSphere 6.5 Security Guide (

Change ESXi default account access

ESXi permissions management has a local RBAC model, with some predefined local system roles, such as the following:

  • Administrator role: With all privileges, like the administrator role in vCenter.
  • Read-only role: Allows for viewing objects associated with ESXi host, but not making any changes, like the read-only role in vCenter.
  • No access role: No privileges at all, like the no access role in vCenter. This is the default role for new users.

As with vCenter permissions, it's possible to define new custom roles.

ESXi roles and local users can be managed through the Host UI interface; both are located in the Security & users tab, in the Host | Manage menu:

Figure 1.15: ESXi user and role management

You can find local user management in the Users menu, and local role management in the Roles menu.

Local permissions can be managed via the Host | Action button, in the Permissions menu:

Figure 1.16: ESXi permissions
If a user exists in both ESXi host and SSO (or one of its identity sources), there can be two different users with the same login on the different authentication sources. The full login name must be [email protected] to avoid confusions.

On each ESXi, there are some default local users:

  • Root user: This is a built-in user with the administrator role. You can remove or change the role of the root user, but be sure to first add another user with the administrator role. Note that this is the only built-in user that is reported in the ESXi user management interface, but there are also other users.
  • vpxuser user: This user is used by vCenter to manage ESXi hosts, after they have been connected. Note that this user also has an administrative role. This user must be managed by the vCenter Server; don't change it in any way (such as changing its password or permissions).
  • dcui user: The primary purpose of this user is to configure hosts for lockdown mode, from the Direct Console User Interface (DCUI).
For audit purposes, be sure to assign named accounts to all accounts with the administrator role.

For more information, see the vSphere 6.5 Security Guide (

The next section will describe how to add an ESXi to an AD domain, in order to use external users and groups.

Also, remember that if your ESXi host is managed by a vCenter Server, it might be better to manage authentication and authorization tasks through the vCenter permissions.

Add an ESXi Host to a directory service

To use centralized users (and groups) instead of local accounts, it's possible to join an ESXi to an AD domain. When the host is added to AD, the ESX Admins domain group has the administrator role on the ESXi host.

It's possible to join an ESXi host to an AD domain if it is a standalone host, or if it's managed by a vCenter Server. But, if your ESXi is already managed by a vCenter Server, authentication and authorization with the vCenter permissions might be enough; there's no need to also use ESXi roles.

If ESXi is managed by vCenter, you can use the vSphere Web Client to join ESXi to an AD domain. Use the Join Domain button in the Authentication Services menu, under the Configure tab of a specific host, as in the following screenshot:

Figure 1.17: Joining an ESXi to an AD domain

Enter the full AD domain name (in a DNS format), and the credentials of an AD user with enough permissions to join a computer to the domain.

To add a standalone ESXi to an AD domain, you will need the Host UI. In this case, just select the Host | Manage menu, go to the Security & users tab, and select Authentication.

For more information, see the vSphere 6.5 Security Guide (

Apply permissions to ESXi Hosts using Host Profiles

Host profiles are only available in the Enterprise Plus edition, and are used to provide a standard configuration for multiple ESXi hosts. You can create a new host profile from a reference host and apply the host profile to all hosts that share similar characteristics with the reference host (like a homogeneous hardware configuration).

To apply permissions to ESXi using a host profile, you need to modify it with the vSphere Web Client in Home | Policies and Profiles | Host Profiles. Select a specific host profile and click on the Configure tab, and then click on the Edit Host Profile... button, or select Edit settings in the host profile contextual menu:

Figure 1.18 Editing a host profile

The security setting and the permissions rules are in the Security and Services menu.

Note that, in the same menu, you can also configure ESXi firewall rules and domain service integration, as discussed previously.

For more information, see the vSphere 6.5 Security Guide (

Objective 8.2 will provide more information on how to create, manage, and apply host profiles.

Enable Lockdown Mode

To harden ESXi connected to a vCenter Server, one option is to use lockdown mode, which disables a direct connection to ESXi host. The host will only be accessible through the vCenter Server, or, depending on the lockdown mode, through the DCUI.

It's possible to modify lockdown mode in the host settings or from the DCUI (the usual method).

In vSphere 6.x, lockdown mode has different levels of protection; the following are the different configuration options available:

  • Disabled: Lockdown mode is disabled.
  • Normal: Lockdown mode is enabled, DCUI is not blocked, but the Host UI, ESXi shell, or ESXi SSH is disabled.
  • Strict: Lockdown mode is enabled, and all local services are disabled (including the DCUI that is stopped). ESXi is only accessible through the vCenter Server.

You can configure ESXi lockdown mode from the vSphere Web Client, when you add a new host. It's also possible to change the setting later; in that case, select the Security Profile menu in the Configure tab of the desired ESXi.

Find the Lockdown Mode area (after Services), and click on the Edit... button, as follows:

Figure 1.19: Configuring lockdown mode

In vSphere 6.x, there is a new feature for lockdown mode: the Exception Users list. Those users (or solutions) will be excluded from lockdown mode (if Normal mode is used). Exception users cannot be managed from the DCUI.

From the DCUI, press F2 and log in, then select Configure Lockdown Mode and press Enter:

Figure 1.20: Configuring lockdown mode from the DCUI

For more information, see the vSphere 6.5 Security Guide (

Control access to hosts (DCUI/Shell/SSH/MOB)

Lockdown mode, as described previously, can be used to limit and control access to ESXi by using DCUI (in strict mode), or ESXi Shell and ESXi SSH.

There are also other ways to limit access to an ESXi host. For example, there is the Managed Object Browser (MOB) interface, which provides a view of the VMkernel objects. Usually, it's recommended to disable it in production systems.

Starting with vSphere 6.0, the MOB interface is disabled by default. However, for some specific cases, you may need to enable it again.

You can enable and disable the MOB interface by using the vSphere Web Client. Select the desired host, choose the Configure tab, and go to the Advanced System Settings menu (in the System section).

Check the value of Config.HostAgent.plugins.solo.enableMob, and change it as needed.

Harden vCenter Server

Depending on your type of vCenter deployment, you may have internal or external PSC (see Objective 1.3), and you may also have Windows-based servers or Linux-based virtual appliances.

Note that, in the new major release of vSphere, there will only be the virtual appliance (or vCenter Virtual Appliance (VCSA)) option, and the Windows-based installation will no longer be available.

There are some generic security best practices that are valid for both versions, as follows:

  • Use named accounts, and minimize permissions
  • Monitor privileges of vCenter Server administrator users
  • Limit vCenter Server network connectivity
  • Verify certificates
  • Keep the vCenter OS and services updated

By using the VSCA, from VMware for vSphere 6.5 and later, you can use the same VM hardening suggestions (see Objective 1.4). But note that the VCSA is already based on a hardened operating system (in vSphere 6.5, the VCSA is based on the VMware PhotonOS platform).

By default, on VCSA, the shell access is disabled. A remote shell with SSH can be enabled during the deployment, but note that by default this shell has a limited set of commands (but it's also easy to enable the full shell).

The PSC security best practices are quite simple:

  • Check password expirations: Remember that the default SSO password lifetime is 90 days.
  • Use NTP for time sync: All systems must use the same time source. Time synchronization is essential for authentication, and also for certificate validity.

For more information, see the vSphere 6.5 Security Guide (

Control datastore browser access

Data store browsing is provided by different roles, but it is mainly provided by the Datastore.Browse privilege. It can be dangerous, because users with this privilege can view, delete, copy, upload, or download files directly from data stores.

Be sure to assign this privilege only to users or groups that really need it, in order to follow the minimum privilege principle.

VM file encryption (see Objective 1.4) can help to minimize some risks in data confidentiality if a user can browse the data store.

Create/Manage vCenter Server Security Certificates

Network communications between vSphere components are usually encrypted using TLS/SSL protocols. At a minimum, all management traffic is secured by default.

However, in vSphere 5.5 and earlier, the TLS/SSL communications were only authenticated with a username, password, and basic certification verification (thumbprint). Starting with vSphere 6.0, vCenter uses certificates for authentication, to increase the security of communications.

VMware vSphere 6.x supports the following certificate modes:

  • VMware Certificate Authority (default): The PSC acts as a top-level CA (or as an intermediate CA) and provisions certificates to ESXi hosts and other endpoints that require them.
  • Custom Certificate Authority: In this case, custom certificates signed by third-party or enterprise CAs are used. Unless you change the certificate mode to Custom Certificate Authority, the PSC might replace custom certificates.
  • Thumbprint Mode: Certificates are checked for the correct format, but without verifying the validity of the certificate. This mode was used until vSphere 5.5, but it is still available as a compatible option in vSphere 6.x.

For more information about the VMware Certification Authority, see Objective 1.3.

Control MOB access

MOB access was already discussed in the section on hardening ESXi hosts. The Managed Object Browser (MOB) is a web-based server application that can permit access to some data and represent a security risk.

Remember that, starting with vSphere 6.0, the MOB is disabled by default.

Change vCenter default account access

User management was already discussed in Objective 1.1.

The default role for new users or new identity sources is No access. However, there are also the local users (of the vCenter OS), which can have some privileges and, for example in previous vCenter Server Windows based system local administrator was also added as a vCenter Administrator.

Starting with vSphere 6.0, the local administrator of the PSC (user root for VCSA, or administrator for Windows-based) does not have the full administrative vCenter permissions.

For the VCSA, the root user (the password of which is defined during the installation) can, of course, access the VAMI interface.

Restrict administrative privileges

Due to the minimum privilege principle, not all administrative users must have the administrator role. A good practice is to create a custom role with an appropriate set of privileges, and assign it to other administrators.

For more information and an example, see Objective 1.1.

Understand the implications of securing a vSphere environment

During the hardening process, you have to find the right balance between security and manageability. Some changes related to increasing the security of the vSphere environment can have an impact on its manageability (for example, see the Enabling lockdown mode section).


Objective 1.3 – Configure and Enable SSO and Identity Sources

The SSO, introduced in vSphere 5.1, is the authentication broker of a vSphere environment.

Using a secure token mechanism, different vSphere components can communicate with each other. Both the internal components and the vSphere users are authenticated with SSO, with its different identify sources (different authentication domains, as described in Objective 1.1).

Objective 1.3 for VCP65-DCV and VCP6-DCV is similar, because there weren't major changes in SSO authentication from vSphere 6.0 to vSphere 6.5.

For more information about authentication, see the PSC 6.5 Administration Guide (

Describe PSC architecture and components

From vSphere 6.0, the vCenter components are grouped into two separated roles, as follows:

  • The vCenter Server: Also called the management node, used to provide specific vCenter-related services.
  • The Platform Services Controller: Also called the infrastructure controller, used to provide common infrastructure services for different VMware products:
Figure 1.21: PSC and vCenter

Each role groups different types of services and functions, according to the following table:

Platform Service Controller

vCenter Server

Single Sign-On
Custom roles
Global permissions
Certificate Authority
VMware Certificate Service
VMware Identity Management Service
VMware Directory Service
VMware License Service
VMware Appliance Management Service (VAMI), on VCSA only

vCenter Server
Inventory Service
Profile-Driven Storage
HTML5 / vSphere Web Clients Server
Auto Deploy
Content Library
Syslog Collector
ESXi Dump Collector
Optional: VMware Update Manager
Optional: Embedded DB (PostgreSQL)

Table 1.4: PSC and vCenter node services and functions

Both components can be based on a Windows Server OS (installable version), or in a virtual appliance form (VCSA). For version 6.5, mixed environments are supported (in the future, it is likely that only the VCSA will be supported).

Note that the PSC uses limited resources, as compared to the management nodes (just 2 vCPU and 4 GB of RAM).

The PSC is an important component in the design, providing services not only for vCenter Server and vSphere, but for the VMware products in general. SSO, for example, can be shared with other VMware products (for example, vRealize Orchestrator and vRealize Automation), to provide a centralized user authentication.

The main core services provided by the PSC discussed in this objective are:

  • SSO: Solves the problem of mutual authentication between different components, and also the authentication in an environment with different identity sources (this will be described later). The SSO provides an internal authentication domain; in vSphere 5.5, the default name was vsphere.local. With vSphere 6.0 and later, you can choose the name of the SSO domain.
  • Certificate management: Also called VMware Certificate Authority (VMCA), it manages digital certificates, and can act as a Certification Authority (CA).

Depending on your environment and infrastructure design, the vCenter Server and PSC roles can be deployed in two different ways:

  • Embedded: The same machine has both vCenter Server and PSC. This deployment model supports a good scaling in terms of hosts or VMs, like an external deployment (with a single vCenter), but does not provide enhanced linked mode (unless using vSphere 6.5, Update 2). Note that vCenter High Availability is supported for embedded deployments in vSphere 6.5.
  • External: The vCenter Server and PSC roles are on different machines. This is the only configuration that supports complex topology.

The following table summarizes the pros and cons of each deployment model:

Embedded PSC

External PSC


2,000 hosts per vCenter

25,000 VMs per vCenter (powered-on)

2,000 hosts per vCenter

25,000 VMs per vCenter (powered-on)

More with linked mode



More servers to be managed



First update all PSCs, and then vCenter


No outages caused by connectivity and name resolution issues between vCenter and PSC

Possible outages caused by connectivity and name resolution issues between vCenter and PSC


VCSA: vCenter HA
Windows: Failover Cluster

For vCenter, same solutions
For PSC, load balancer


VMware Cloud for AWS
Enhanced linked mode (for VCSA 6.5U2 or later)

Enhanced linked mode



Enhanced linked mode

Table 1.5: Embedded and external PSC

VMware recommends six high-level PSC topologies, as follows:

  • vCenter Server with embedded PSC
  • vCenter Server with external PSC
  • PSC in replicated configuration
  • PSC in HA configuration
  • vCenter Server deployment across sites
  • vCenter Server deployment across sites, with load balancer

For more information, see KB 2147672 (—Supported and deprecated topologies for VMware vSphere 6.5.

Also, note that vCenter Server can have an embedded or external database server. And, if VCSA supports external databases, it is highly recommended to use the embedded one:

Embedded DB

External DB


For VCSA: 2,000 hosts or 25,000 VMs (powered-on)

For Windows: 20 hosts or 200 VMs

2,000 hosts or 25,000 VMs (powered-on)

More with linked mode



More servers to be managed



More dependencies


No outages caused by connectivity issues between vCenter and DB

Possible outages caused by connectivity issues between vCenter and DB


VCSA: vCenter HA
Windows: Failover Cluster

DB requires a specific solution, such as clustering

Table 1.6: Embedded and external databases

Differentiate available authentication methods with VMware vCenter

As previously stated, SSO is an authentication broker and security token exchange infrastructure.

In vSphere 5.1 and 5.5, SSO was a specific role, but starting with vSphere 6.0, SSO is a part of the PSC role.

As described in Objective 1.2, SSO supports multiple identity sources, including external directory services, such as AD.

Using AD for user authentication simplifies permission management, ensures password complexity, and allows for using the same security policies for AD, to minimize the risk of unauthorized access.

To improve authentication security, multi-factor authentication (MFA) is preferable to simple username/password methods. Two-factor authentication (2FA) is a type of multi-factor authentication that uses two components.

Starting with vSphere 6.0 Update 2, it is possible to use two-factor authentication, as follows:

  • Smart card (UPN-based Common Access Card (CAC))
  • RSA SecurID token
Note that vCenter SSO only supports native SecurID, and does not support RADIUS authentication. For more information about authentication, see the PSC 6.5 Administration Guide (

Perform a multi-site PSC installation

Multi-site PSC is only possible with an external PSC deployment. In this configuration, an SSO domain will span multiple sites. You will have one single SSO domain, but with multiple sites, as illustrated in the following diagram:

Figure 1.22: Multi-site PSC deployment
To provide high availability for the PSC, it's recommended to have at least two PSCs on each site, with a third-party load balancer.

Site membership can be specified during the installation of the PSC (Stage 2), as follows:

Figure 1.23: PSC deployment

Configure/manage identity sources

Consider the topic described in Objective 1.1; in this section, we will consider the AD case.

To assign vCenter permissions to AD users or groups, you must first join the PSC to the AD domain. This allows the AD users to log in to the vCenter Server using the Windows session authentication (SSPI).

The procedure to join the vCenter Server to an AD domain depends on how the vCenter and the PSC have been deployed:

  • Embedded PSC: Join the vCenter to the AD domain
  • External PSC: Join the PSC to the AD domain
Only a writable Domain Controller can be used to join the AD domain. A Read-Only Domain Controller (RODC) is not supported.

For Windows-based vCenter or PSC, just join the Windows machine to the AD domain.

For VCSA, to join the PSC or the vCenter to the AD, follow this procedure:

  1. From the vSphere Web Client, log in with the right SSO admin account.
  2. Select Home | Administrator | Deployment | System Configuration and choose the proper node (the PSC or the vCenter, depending on the deployment).
  3. In the Manage tab, select the Advanced | Active Directory menu, then click on the Join button to enter the details to join the AD.
  4. Enter the Domain to join, and optionally the Organizational unit. Specify the AD username in UPN format ([email protected]), with the privileges to join the PSC to the domain.
  5. After the process has completed, the joined domain will be listed in the Domain field, and a new Leave... button will be displayed:
Figure 1.24: AD membership
  1. You need to reboot the node to enable the changes.
  2. When the node has been rebooted, navigate to Configuration | Identity Sources to add the AD domain. Click Add to open the Add Identity Source wizard.
  1. Select the Active Directory (Integrated Windows Authentication) option, and enter the joined FQDN domain name, if it's not displayed automatically.
  2. Select the Use machine account option to use the local machine account as the SPN. If you expect to rename the machine, don't use this option, because it will break the authentication process. Click on OK to confirm the specified AD domain as the new identity source.
  3. On the Identity Sources tab, the joined AD domain is now displayed. Now, you can assign permissions to users/groups to be members of the AD domain.
To prevent authentication conflicts, don't use a username that is used by other identity sources, such as OpenLDAP or Microsoft AD.

Configure/manage platform services controller (PSC)

The PSC appliance (like the VCSA appliance) can be managed by using the vCenter Server Appliance Management Interface (VAMI).

However, to manage specific PSC services, you can use the Platform Services Controller UI; or, for some tasks (such as certificates management), you can also use the vSphere Web Client. Some services, such as smart card authentication, are only configurable from the Platform Services Controller UI.

The following table summarizes the different user interfaces (UIs) available for the PSC:

Web interface


VAMI (only for VCSA appliances)


Platform Services Controller UI


vSphere Web Client


Table 1.7: UI interfaces for PSC

In this table, "PSC" is the IP address or the FQDN of the PSC (if external) or the vCenter Server (if embedded).

Configure/manage VMware Certificate Authority (VMCA)

Starting with vSphere 6.0, the new PSC component includes not only the SSO part, but also the VMCA. The VMCA is used for the certification management of all vSphere infrastructural elements.

This not only simplifies the certification management (with auto-enrollment for expired certificates), but also improves the security of the different network connections (as described before).

Using VMCA mode (see Objective 1.2 for different modes for managing certificates), the PSC will generate and issue all certificates needed by the different vSphere components. Certificates are stored by the vSphere Endpoint Certificate Store (VECS).

To avoid browser warnings, you need to trust VMware's CA, but first, you have to gain that certificate. You can simply download it from the vCenter home page, under Download trusted root CA certificates:

Figure 1.25: vCenter Server home page

You will download a simple file that contains both the CA certificate and the revocations list.

To import the certificate in a Windows system, you can use different approaches, as follows:

  • Import manually: For Internet Explorer, Edge, or Chrome, you can simply double-click on the certificate and import it into the trusted CA. Note that Firefox has a different certificates repository.
  • Import by using GPO: Under Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Trusted Publishers, you can import existing certificates. Be sure to import them into the Trusted Root Certification Authorities store.
  • Trust from another CA: Add it as an intermediate CA in your existing CA authority.

Otherwise, you can replace the CA certificate of VMCA; or, just don't use it at all, and manage all of the certificates as you did in the past.

For more information, see KB 2097936 (—How to use vSphere 6.x Certificate Manager.

For more information about authentication, see the PSC 6.5 Administration Guide (

Enable/disable SSO users

You can enable and disable accounts from the vSphere Web Client or the PSC UI; in both cases, you need SSO admin privileges.

With the vSphere Web Client, from Home | Administration, just select the Users and Groups menu under the Single Sign-On section. Select a user account and click on the Disable icon, as shown in the following screenshot:

Figure 1.26: Disable SSO users

To enable the user again, right-click on the username and select Enable.

If you disable (or delete) the administrative user in the SSO domain, you cannot manage the SSO domain (unless you previously created another user with SSO admin privileges).

For more information about authentication, see the PSC 6.5 Administration Guide (

Upgrade a single/complex PSC installation

If you have a complex vSphere environment with more external PSCs, and perhaps with multi-site deployment, the upgrade process can be a little more critical.

To upgrade a vSphere environment, there is a general order that must be followed. For the basic vSphere components, perform the following:

  1. External PSC: Upgrade each SSO or PSC, one by one. Applicable only in external PSC deployments.
  2. vCenter Server: Upgrade each vCenter Server, one by one.
  3. ESXi hosts: Upgrade each ESXi host, one by one.
In environments with more VMware products, the upgrade/update sequence is much more complex. See VMware KB 2147289 (—Update sequence for vSphere 6.5 and its compatible VMware products.

For the PSC components, it's usually preferable to upgrade them during the maintenance windows, to avoid authentication issues. But, if all external PSCs are configured in a high availability configuration, with external load balancers, you can perform upgrades on PSCs one by one, without interruptions.

For more information about each transitional step, including diagrams, see the Upgrade or Migration Order and Mixed-Version Transitional Behavior for Multiple vCenter Server Instance Deployments section in the vSphere Upgrade Guide (

For the vCenter Server appliance (for both vCenter and PSC), the update and upgrade process can be managed from the VAMI UI. The update is quite simple (for example, using an external URL), and the upgrade requires the VCSA 6.5 ISO.

The VCSA GUI upgrade is a two-stage process (like the installation). The first stage is a deployment wizard that deploys the OVA file of the new appliance on the target ESXi host or vCenter Server instance. After the virtual appliance deployment finishes, you are redirected to the second stage of the process, which sets up and transfers the services and configuration data from the old appliance to the newly deployed appliance.

For more information, see KB 2147686 (—Best practices for upgrading to vCenter Server 6.5.

Configure SSO policies

The vCenter SSO policies enforce security rules related to the SSO users defined in your environment. There are three main types of SSO policies: password policies, lockout policies, and token policies.

You can manage SSO policies from the vSphere Web Client (with SSO admin privileges) or the PSC UI.

With the vSphere Web Client, in Home | Administration, just select the Configuration menu in the Single Sign-On section. Then, select the Policies tab and choose the right category of policies, as follows:

Figure 1.27: SSO policies

Note that there are password expiration rules for the virtual appliance local users, if you are using VCSA for vCenter and/or the PSC components. Be sure to check those settings. By default, vCenter Single Sign-On passwords expire after 90 days. Starting with version 6.0, the password policy only applies to SSO user accounts, not to SSO system accounts (usually [email protected]).

If you are using AD users, both for hosts and vCenter, then the password policies are enforced by AD GPO.

For more information about authentication, see the PSC 6.5 Administration Guide (

Add an ESXi host to an AD domain

This task was described in Objective 1.2, in the host hardening options.

For more details, see KB 2075361 (—Configuring ESXi host with AD authentication.

Remember to synchronize the proper time between ESXi and the directory service system.

Configure and manage KMS for VM encryption

In vSphere 6.5, to encrypt VM disks, you will need to configure a Key Management Server (KMS), or, better yet, a cluster of KMS.

You can use the vSphere Web Client, as follows:

  1. Select the vCenter Server in the inventory, then select the Configure tab. Expand More, and select Key Management Server to access the KMS management section.
  1. Click on the Add KMS... icon to add the KMS server (you must have one in your network). Specify the required parameters, and click on OK to save the configuration:
Figure 1.28: Adding a new KMS
  1. Once the KMS server is successfully added to the vCenter Server, the Connection Status will be displayed as Normal. Having configured the KMS server, you can start encrypting VMs.
KMS are mandatory for VM encryption, but are not required for vMotion encryption.

For more information, see the vSphere 6.5 Security Guide ( or the StarWind blog post at


Objective 1.4 – Secure vSphere Virtual Machines

The hardening guide describes a lot of specific VM options, but, starting with ESXi 6.0 Patch 5, many of the advanced VM settings are now set to be Secure By Default.

This means that the desired values in the Security Configuration Guide are the default values for all new VMs, and you don't have to manually set them anymore.

For more information, see the blog post at

For virtual networking, NSX can provide a micro-segmentation capability, to enforce network security directly at the VM virtual NIC level.

Also, at VMworld 2017, a new product was announced: VMware AppDefense, a data center endpoint security product that protects applications running in virtualized environments. AppDefense works inside of the VM (compared to NSX, which only works at the network level), and understands how applications are normally supposed to work, monitoring any changes that could indicate a threat.

Objective 1.4 is totally new for VCP65-DCV, but it contains some parts of Objective 1.2, from the VCP6-DCV exam preparation guide.

Enable/disable VM encryption

VMware vSphere 6.5 added the possibility to encrypt VM files (such as .vmx and swap files) and virtual disks (VMDK), making the stored VM data more secure. For example, they are inaccessible with a simple data store browsing operation.

To allow VM encryption, the following components are needed:

No additional or specific hardware is required for the encryption/decryption operations, but processors with support of the AES-NI instruction set are recommended, in order to improve the performance. AES-NI should be enabled in the host BIOS.

VM encryption is controlled by VM storage policies (see Chapter 3, Configure and Administer vSphere 6.x Storage, for more information). To change the storage policy of a VM, follow this procedure:

  1. From the vSphere Web Client, right-click on the VM to encrypt. Navigate to VM Storage Policies | Edit VM Storage Policies.
  1. From the VM storage policy drop-down menu, select the VM Encryption Policy option to encrypt the VM:
Figure 1.29: Encrypting a VM
  1. When the encryption process has completed, the VM Hardware area in the VMs Summary tab will display the Encryption field that indicates which components are encrypted.

There are different recommendations when using encrypted VMs, but the most important are as follows:

  • If PSC or vCenter are implemented as VMs, don't encrypt them.
  • Never edit the .vmx files or .vmdk descriptor files of encrypted VMs; otherwise, the VMs will become unrecoverable.

To perform the preceding operations, you will need the required privileges, as follows:

  • Cryptographic operations.Encrypt new
  • Cryptographic operations.Decrypt
  • Cryptographic operations.Register host (if the host encryption mode is not enabled)

Note that encrypted VMs can be a challenge for native backup programs, but there is a way to permit backup of the encrypted files in a clear format, to allow for indexing and granular restore. Several backup products already support this feature.

For more information, see the vSphere 6.5 Security Guide (

Describe VM Secure Boot

As described in Objectve 1.2, Unified Extensible Firmware Interface (UEFI) is a replacement for the traditional BIOS firmware, and secure boot uses the UEFI firmware to validate the digital signature of the operating system and its bootloader.

With vSphere ESXi 6.5, you can use secure boot with both ESXi and VM. For ESXi secure boot description, see Objective 1.2.

VM secure boot has some important requirements, as follows:

  • Virtual hardware version 13 or later
  • EFI firmware in the VM boot options
  • VMware Tools version 10.1 or later
  • A guest operating system that supports UEFI secure boot:
    • Some examples of supported operating systems are Windows 8 and Windows Server 2012 or newer, VMware ESXi 6.5 and Photon OS, RHEL/Centos 7.0, and Ubuntu 14.04

You can enable secure boot on a VM by using the vSphere Web Client, in the VM options of the desired VM, as follows:

Figure 1.30: VM secure boot
You cannot upgrade a VM that uses BIOS boot to a VM that uses UEFI boot. If a VM already uses UEFI boot and the operating system supports UEFI secure boot, you can simply enable secure boot.

You will need VirtualMachine.Config.Settings privileges to enable or disable UEFI secure boot for the VM.

For more information, see the vSphere 6.5 Security Guide (

Harden virtual machine access

As described in Objective 1.2, VMware has provided some Security Hardening Guides ( to provide guidance on how to increase security in a vSphere environment.

VMware suggests some security best practices to increase the security of VMs running in a vSphere environment, as follows:

  • Use templates: Instead of manually installing guest operating systems and applications, prefer templates or other provisioning systems to enforce security baselines.
  • Limit console access: Be sure to protect and limit access to the VM console, for the confidentiality of data (by default, more users can see the same VM console sessions).
  • Limit remote access: Remote protocols used for management (such as SSH or RDP) must be secured, controlled, and limited.
  • Limit resources: Without proper resource management (such as resource pools), more VMs can consume most of the host resources, with a possible denial-of-service (DoS) scenario.
  • Minimize services: Any service that is running in a VM is a potential target for attacks. Be sure to disable services or system components that are not necessary.
  • Minimize hardware: Disconnect or remove unused devices, such as CD/DVD drives, floppy drives, and USB adapters. This also helps with VM migration. Note that CD/DVD drives may be needed for VMware Tools installation/upgrade.
  • Limit VMware Tools functions: Disable unused functionality, such as unused display features or host guest file systems (HGFSs). Some of those functions will be discussed in the next section.
Because a VM is almost equivalent to a physical server, it is possible (in most cases) to apply the same security approaches and solutions.

For more information, see the vSphere 6.5 Security Guide (

Control VMware Tools installation

VMware Tools installation and upgrade is performed by using the virtual CD/DVD drive. This means that, without it, you cannot perform those operations from the vSphere Web Client.

Another option for disabling VMware Tools installation is to change the role and remove the privilege required to install VMware Tools (Virtual machine .Interaction.VMware Tools install).

Note that both tricks do not work with standalone VMware Tools if they are installed from the binaries files in the guest OS.

Control VM data access

VMware provides some functions to permit data access inside of the VM:

  • HGFS: This is used to transfer files between the host and the VMs. Note that this capability is actually only leveraged on Workstation/Player/Fusion, and it's not implemented in ESXi.
  • Copy and paste between the guest OS and remote console: By default, this feature is disabled, as recommended for a secure environment. If copy and paste is enabled and the VM has VMware Tools installed, you can copy and paste between the guest operating system and the remote console.

You can control those features by using the vSphere Web Client: select a VM, right-click on the VM, and click on Edit Settings. In the VM Options tab, click on Advanced, and click on Edit Configuration.

At this point, check the specific rows (if they exist) or create new rows. The following table summarizes some possible parameters:

VM advanced parameter

Recommended value



Disable HGFS file transfer


Disable copy operations


Disable paste operations


Disable VMware Tools options from the guest

Table 1.8: Hardening VM advanced settings

If you make changes to the preceding configuration parameters, restart the VM to load the changes.

Note that all of those four settings are disabled by default starting ESXi 6.5 update 1, in ESXi 6.0 Patch 5 and 5.5 Update 3 Patch 11.

The vSphere 6.5 Security Guide ( reports other settings that are not exposed in vSphere, but could cause vulnerabilities, as follows:

VM advanced parameter

Recommended value








Table 1.9: Other hardening VM advanced settings

Configure virtual machine security policies

Some VM security policies have already been discussed; others, related to DoS attacks, will be discussed in the next section.

Harden a virtual machine against DoS attacks

One or more VMs may consume too many resources on a single host, causing a possible DoS scenario. To minimize this possibility, a proper configuration of the VM resource management is needed; also, remember that each VM has implicit limits, due to resources configured in the VM settings.

Other possible DoS situations are as follows:

  • Virtual disk shrinking: Shrinking a virtual disk reclaims the disk's unused space. This operation can be performed by a non-administrative user in the guest operating system, and multiple operations can cause a DoS on the virtual disk. To disable the ability to shrink virtual disks, you must use two VM advanced settings, and, as described in KB 1002019 (—Growing, thinning, and shrinking virtual disks for VMware ESX and ESXi.
This operation is not supported in ESXi, but it is supported in Workstation/Player/Fusion.
  • Informational messages from VM to VMX files: A DoS can happen if you do not control the size of a VMs VMX file, and the amount of information in it exceeds the data store capacity. By default, the file limit is 1 MB, and you can change it with the tools.setInfo.sizeLimit VM advanced option. For more information, see the vSphere 6.5 Security Guide (
  • Unnecessary hardware devices: Any connected device represents a potential attack channel. As described previously, it's a good practice to remove or disable all unneeded or unused devices. Note that, by default, users and processes with local privileges on a guest OS can connect or disconnect some hot-plug hardware devices (such as the virtual NIC).

Control VM-VM communications

The Virtual Machine Communication Interface (VMCI) provides a communication channel between a VM and the host, or between two or more VMs on the same host. In vSphere 6.5, VMCI is disabled by default.

Of course, each VM can talk to others by using the virtual network, so be sure to enforce network segregation with VLAN at the portgroup level, or, if possible, micro-segmentation with NSX.

Control VM device connections

As described previously, any device can represent a potential attack channel, and a good practice is to remove or disable unnecessary devices.

Using VMware Tools, it's possible to connect or disconnect devices, potentially causing a DoS, but this feature is disabled by default. For more information, see the vSphere 6.5 Security Guide (

Note that VMware provides some devices that are hot-pluggable (such as the virtual NIC). In this case, users and processes with local guest OS privileges (root or administrator) can disconnect those types of devices from the OS. For more information, see KB 1012225 (—Disabling the HotAdd/HotPlug capability in ESXi 6.x, 5.x and ESXi/ESX 4.x VMs.

The following table summarizes some parameters for controlling the VM device connections:

VM advanced parameter

Recommended value




Disable the connection of devices



Disable copy operations



Disable device hotplug

Table 1.10: Hardening VM advanced settings

Configure network security policies

Standard and distributed virtual switches (described in Chapter 2, Configure and Administer vSphere 6.x Networking) both have specific security policies:

  • Promiscuous mode: Promiscuous mode permits a virtual NIC to capture all frames on the virtual switch portgroup. Of course, it can represent a security risk for the confidentiality of the data.
  • MAC address changes: The guest OS can change the MAC address of the virtual NIC, and this can be used by a spoofing attack.
  • Forged transmits: Any outgoing frame with a source MAC address that is different from the one currently set on the VMX file.

By default, on distributed virtual switches, all of the previous policies are rejected. On standard virtual switches, only the promiscuous mode is rejected; in that case, you can change the settings with the vSphere Web Client, by selecting the Configure tab on the desired host, and then the Virtual switches menu. Then, select the desired virtual switch, click the Edit settings icon, and choose the Security menu:

Figure 1.31: Network security policies

For more information, see the vSphere 6.5 Security Guide (

Configure VM encrypted vMotion

Protecting stored data is only one element of security; you also need to encrypt the network connections. For the infrastructure part, all of the communication between vCenter and the hosts is usually encrypted. However, some other infrastructural network traffic usually is not protected; for example, iSCSI or NFS traffic (and also vMotion, until vSphere 6.5).

As described in Objective 1.2, there is now a new feature to encrypt vMotion traffic.

Encryption of vMotion traffic is per-VM; when the VM is migrated, a one-time 256-bit key is randomly generated by vCenter Server (note that it does not use the KMS).

Settings are per-VM, but only for VMs with virtual hardware 13. You can view or change the settings by right-clicking on the VM and selecting Edit Settings..., then selecting the VM Options tab in the Encrypted vMotion section:

Figure 1.32: Encrypted vMotion settings

The different options are as follows:

  • Disabled: Do not use encrypted vMotion for this VM.
  • Opportunistic (default): Use encrypted vSphere vMotion only if the source and destination hosts can support it (ESXi versions 6.5 and later).
  • Required: Force the use of encrypted vMotion. If the source or destination host does not support encrypted vMotion, then the migration will not be possible.

You can disable vMotion encryption, unless the VM is encrypted; in that case, it is always enforced.

In vSphere 6.5, migration across vCenter Server systems is not supported for encrypted VMs.

For storage vMotion or vMotion without shared storage, the disks are transmitted as they are, as follows:

  • For encrypted disks, the data is transmitted encrypted.
  • For disks that are not encrypted, Storage vMotion encryption is not supported.

For more information, see the vSphere 6.5 Security Guide (


What is missing

The official VCP65-DCV Exam Preparation Guide covers a lot of security topics, but the vSphere 6.5 Security Guide has richer information and more topics. For example, the following aspects are not considered in the preparation guide:


Review questions

For more questions, see Chapter 11, Mock Exam 1, and Chapter 12, Mock Exam 2:

  1. What are the requirements for implementing VM secure boot? (Choose three)
    • A: Guest operating system that supports UEFI secure boot
    • B: VMware Tools version 10.1 or later
    • C: VM virtual hardware 13 or later
    • D: VM virtual hardware 10 or later
    • E: VMware Tools version 10 or later

A, B, C - See Objective 1.4

  1. Which sentence about virtual network security policies is true?
    • A: Only promiscuous mode is disabled on standard switches by default.
    • B: Only MAC changes are disabled by default.
    • C: Only forged transmissions are disabled by default.
    • D: All are disabled by default.

A - See Objective 1.4



Following VMware's vision, the five pillars of cyber hygiene are as follows:

  • Least privilege: This is the common, and most reasonable, approach; it applies to user accounts, service accounts, and services in general (for example, used ports).
  • Micro-Segmentation: Using NSX, it's finally possible to bring network control to the VM level, with granular security rules. Considering the new product (AppDefense), VM security can be enforced at both the network and application levels.
  • Encryption: Data must be protected at each level, and for the physical level, encryption is the only way to ensure good protection.
  • Authentication: Authentication is usually the weakest part, primarily due to simple passwords (or passwords that are not changed periodically).
  • Patching: Keeping your software components up to date is crucial for the security aspect, but it's also very important for implementing new features. Upgrading and patching will be discussed in Objective 4.

Chapter 2, Configure and Administer vSphere 6.x Networking, will check your virtual networking knowledge.

About the Authors

  • Andrea Mauro

    Andrea Mauro has more than 20 years of experience in IT, both in industry and the academic world. He works as a solutions architect and is responsible for infrastructure implementation, architecture design, upgrades, and migration processes. He is a virtualization and storage architect, specializing in VMware, Microsoft, Citrix, and Linux solutions. His first virtualized solution in production was built around ESX 2.x, several years ago. His professional certifications include not only several VMware certifications, but also other vendor-related certifications. He is also a VMware vExpert (2010-18), Nutanix NTC (2014-19), and Veeam Vanguard (2016-19), and he was a Microsoft MVP (2014-16).

    Browse publications by this author
  • Paolo Valsecchi

    Paolo Valsecchi has worked in the IT industry for more than 20 years, and he currently works as a system engineer mainly focused on VMware vSphere, Microsoft technologies, and backup/DR solutions. His current role involves covering all tasks related to ensuring IT infrastructure availability and data integrity (including implementation, upgrades, and administration).

    He holds the VMware VCP65-DCV and Veeam VMCE professional certifications, and he has been awarded the VMware vExpert title (2015-18) and the Veeam Vanguard title (2016-19).

    Browse publications by this author

Latest Reviews

(2 reviews total)
Very good purchase, I'm really satisfied.
Great Authors. Content is very helpful for DC-V exam.
Data Center Virtualization Certification: VCP6.5-DCV Exam Guide
Unlock this book and the full library FREE for 7 days
Start now