Objective 1.3: Enable SSO and Active Directory Integration

Configure/Manage Active Directory Authentication

Configuration of the VMware Single Sign-On service can only be completed via the vSphere Web Client.

  1. From within the vSphere Web Client Home screen, click Administration in the left hand navigation menu
  2. In the left hand pane under Single Sign-On select Configuration
  3. In the right hand pane select the Identity Sources tab
  4. Click the Green Plus Sign to add a new identity source
  5. Select the Identity Source Type and complete the remaining fields.

Configure/Manage Platform Services Controller (PSC)

The Platform Services Controller (PSC) is new to vSphere 6, though most of the components should be familiar from vSphere 5.x. The PSC is comprised of the following services:

–Single Sign-On™ –
VMware License Server –
Lookup Service –
Certificate Authority–
Certificate Store –
VMware Directory Services

Deploying vCenter Server with PSC is supported in one of two deployment methods and with varying topologies:

  • vCenter Server with an embedded PSC – All services bundled with the Platform Services Controller are deployed on the same virtual machine or physical server.
  • vCenter Server with an external PSC – The services bundled with the PSC and vCenter Server are deployed on different virtual machines or physical servers. You first must deploy the PSC on one virtual machine or physical server and then deploy vCenter Server on another virtual machine or physical server.

You cannot switch the models after deployment, you will have to do a complete reinstall.

Configure/Manage VMware Certificate Authority (VMCA)

When installing vSphere for the first time, the default certificates are deployed with 10 years of life span. The VMCA generates those self-signed certs during the installation process, and provisions each of the ESXi host with a signed certificate by this root certificate authority. Earlier versions of vSphere with self-signed certificates are automatically replaced by new self-signed certificates by VMCA.

There are three certificate modes supported in vSphere 6.x:

  • VMCA –  By default, the VMware Certificate Authority is used as the CA for ESXi host certificates. VMCA is the root CA by default, but it can be set up as the intermediary CA to another CA. In this mode, users can manage certificates from the vSphere Web Client. Also used if VMCA is a subordinate certificate.
  • Custom Certificate Authority – Some customers might prefer to manage their own external certificate authority. In this mode, customers are responsible for managing the certificates and cannot manage them from the vSphere Web Client.
  • Thumbprint Mode –  vSphere 5.5 used thumbprint mode, and this mode is still available as a fallback option for vSphere 6.0. Do not use this mode unless you encounter problems with one of the other two modes that you cannot resolve. Some vCenter 6.0 and later services might not work correctly in thumbprint mode.

If you want to the change the Certificate Mode from the default VMCA mode to either Custom orThumbprint complete the following:

  • Go to the  Hosts and Clusters view in the Web Client
  • In the left hand pane select the vCenter Server
  • In the right hand pane select the Manage tab select Settings ->Advanced Settings and click Edit
  • In the Filter box type in certmgmt to display only certificate management keys
  • Scroll down until you get to the setting vpxd.certmgmt.mode, here you change the value to either custom or thumbprint (the default setting is vmca)
  • Click OK after changing the key value
  • Restart the vCenter Server Service for the changes to be applied

Enable/Disable Single Sign-On (SSO) Users

The VMware SSO uses different configuration policy which can be found via vSphere Web client only:

Administration -> Single Sign-On -> Configuration Policies

  • Password Policy
  • Lockout Policy
  • Token Policy

You can configure the following password policy parameters:

  • Description – Password policy description
  • Maximum lifetime – Maximum number of days that a password can exist before it has to be changed
  • Restrict re-use – Number of the user’s previous passwords that cannot be set again
  • Maximum length – Maximum number of characters that are allowed in the password
  • Minimum length – Minimum number of characters required in the password
  • Character requirements – Minimum number of different character types required in the password
  • Identical adjacent characters – Maximum number of identical adjacent characters allowed in the

To add a SSO User with the following steps:

  • Log into the vSphere Web Client with administrative privileges
  • From the Home screen, select Administration
  • Expand Single Sign-On and select Users and Groups
  • Select the Users tab, click the Green Plus Sign to add a new user
  • Provide the User Name and Password
  • Provide First name, Last name, email address, and Description
  • Click OK to complete

To disable a SSO user account:

  • Select the user you wish to Disable from the list
  • Log into the vSphere Web Client with administrative privileges
  • From the Home screen, select Administration
  • Expand Single Sign-On and select Users and Groups
  • Select the Users tab, click the Disable User icon to disable the account

Identify available authentication methods with VMware vCenter

Single Sign-On Identity Sources are configured using the Web Client -> Administration -> Single Sign-On -> Configuration -> Identity Sources

SSO Identity Sources:

  • Active Directory Integrated
  • Active Directory LDAP
  • OpenLDAP
  • local OS

vCenter Single Sign-On can authenticate users from its own internal users and groups, or it can connect to trusted external directory services such as Microsoft Active Directory.


Objective 1.2: Secure ESXi, vCenter Server, and vSphere Virtual Machines

Enable/Configure/Disable services in the ESXi firewall

ESXi services and firewall are configured using Web Client -> Hosts and Clusters -> Selected Host -> Manage -> Settings -> Security Profile.  Services can be Started, Stopped, or Restarted. Services can be configured to Start and stop with host, Start and stop manually, or Start and stop with port usage.  Customizing ESXi Services from the Security Profile can be found in the vSphere Security Guide on page 155.

Enable Lockdown Mode

Lockdown mode is covered in the vSphere Security Guide on page 155.

Lockdown mode forces all operations to be performed through vCenter Server.  When you enable lockdown mode, no users other than vpxuser have authentication permissions.  The root user is still authorized to log in to the Direct Console User Interface (DCUI) when lockdown mode is enabled.

Lockdown mode can be enabled when adding a Host to vCenter Inventory or using Web Client -> Hosts and Clusters -> Selected Host -> Manage -> Settings -> Security Profile.

Lockdown Modes:

  • Normal Lockdown

1. Can no longer SSH to the box

2. Can no longer vSphere Client to the box

3. Can still get into the DCUI via Console

a. with root

b. or any account in DCUI.access

  • Strict Lockdown

1. You will have to reinstall the host if there are major issues

2. Should REALLY setup exception users

a. have access to SSH ONLY!!!  or 3rd party API

b. or any account in DCUI.access
  • Disabled

Configure network security policies

There are three network security policies:

  • Promiscuous mode – Default setting: Reject
    Setting this to Accept allows the guest operating system to receive all traffic observed on the connected vSwitch or PortGroup (think Hub instead of switch).
  • MAC address changes – Default setting: Accept
    Host accepts requests to change the effective MAC
    address to a different address than the initial MAC address.
  • Forged transmits – Default setting: Accept
    Host does not compare source and effective MAC addresses transmitted from a virtual machine.

Each of these can be set to Reject or Accept.  Network security policies can be set on the vSwitch or PortGroup.  The Override checkbox allows you to override the vSwitch setting when configuring Network security policies on a PortGroup.  Setting MAC address changes and Forged transmits to Reject protects against MAC address spoofing.

Add an ESXi Host to a directory service

A standalone ESXi host can be joined to an Active Directory domain using the vSphere Client -> ESXi host -> Configuration -> Authentication Services.

An ESXi host managed by vCenter can be joined to an Active Directory domain using the Web Client -> Hosts and Clusters -> ESXi host -> Manage -> Settings -> Authentication Services.

The root user and users with the Administrator role can access the ESXi Shell. Users who are in the Active Directory group ESX Admins are automatically assigned the Administrator role. By default, only the root user can execute system commands (such as vmware -v) using the ESXi Shell.

 Apply permissions to ESXi Hosts using Host Profiles

Host profiles allow you to set up standard configurations for your ESXi hosts and automate compliance to these configuration settings.  You can also use host profiles to monitor hosts for host configuration changes.

ESXi host users and permissions can be included in the Host Profile.  The administrator (root) password and user passwords that are included with host profile and host customization are MD5 encrypted.  If you are joining an ESXi host to Active Directory by using host profiles, the passwords for the user used to join the host to domain is stored in plain text.

Configure virtual machine security policies

Secure the guest OS and applications just as if they were running on a physical machine.

Virtual machine security best practices:

  • General Virtual Machine Protection
    Guest OS and application patching. Anti-virus scanning.
  • Use Templates to Deploy Virtual Machines
    Reduces the risk of mis-configuration during operating system installation.
  • Minimize Use of Virtual Machine Console
  • Prevent Virtual Machines from Taking Over Resources
  • Disable Unnecessary Functions Inside Virtual Machines
    Disable unused services. Disconnect/remove unused devices.
  • Remove Unnecessary Hardware Devices
    Disconnect/remove unnecessary hardware such as floppy drives, serial ports, parallel ports, USB controllers, and CD-ROM drives.
  • Disable Unused Display Features
  • Disable Unexposed Features
  • Disable host guest file system (HGFS) File Transfers
  • Disable Copy and Paste Operations Between Guest Operating System and Remote Console
    isolation.tools.copy.disable = true
    isolation.tools.paste.disable = true
  • Limiting Exposure of Sensitive Data Copied to the Clipboard
  • Restrict Users from Running Commands Within a Virtual Machine
    Remove Virtual machine -> Guest Operations privileges from Roles which do not require them.
  • Prevent a Virtual Machine User or Process from Disconnecting Devices
    isolation.device.connectable.disable = true
    isolation.device.edit.disable = true
  • Modify Guest Operating System Variable Memory Limit
  • Prevent Guest Operating System Processes from Sending Configuration Messages to the Host
    isolation.tools.setinfo.disable = true
  • Avoid Using Independent Nonpersistent Disks
    Evidence that a machine was compromised can be removed by shutting down or rebooting the system.

Create/Manage vCenter Server Security Certificates

The VMware Certificate Authority (VMCA) provisions vCenter Server components and ESXi hosts with certificates that use VMCA as the root certificate authority by default. <- New in vSphere 6

vCenter Server, the Platform Services Controller, and related services support certificates which are generated and signed by the VMCA, Enterprise certificates that are generated and signed by an internal PKI, and third-party CA-signed certificates that are generated and signed by an external PKI.

vCenter Certificate Utilities:

  • vSphere Certificate Manager utility – certificate replacement tasks from a command line utility.
  • Certificate management CLIs – dir-cli, certool, and vecs-cli command line utilities.
  • vSphere Web Client certificate management – view certificate information in the Web Client

The vSphere Certificate Manager utility can be used to generate CSRs.

Viewing Certificates in the Web Client -> Home -> System Configuration -> Nodes -> Node -> Manage -> Certificate Authority
In the Web Clinet you can view Active Certificates, Revoked Certificates, Expired Certificates, and Root Certificates.

When upgrading from earlier versions of vSphere the self-signed certificates are replaced with certificates signed by the VMCA.

vCenter Server monitors all certificates in the VMware Endpoint Certificate Store (VECS) and issues an alarm when a certificate is 30 days or less from its expiration. This threshold can be changed by setting the vpxd.cert.thresholdadvance option.

The VMCA can be used as an Intermediate Certificate Authority.

Objective 1.1: Configure and Administer Role-based Access Control

Identify common vCenter Server privileges and roles

Roles are a set of privileges (actions) that can be performed on objects.  There are three types of roles; system roles, sample roles and custom-built roles.

System Roles 



No access

Sample Roles

The sample roles are loaded by default and the roles end with (sample).  These include:

Resource pool administrator (sample)

Virtual machine user (sample)

Content library administrator (sample)

VMware Consolidated Backup user (sample)

Datastore consumer (sample)

Network administrator (sample)

Virtual machine power user (sample)

Custom Role

These roles are created by the administrator.

Describe how permissions are applied and inherited in vCenter Server

Objects are entities on which actions are performed.  Objects include datacenter, folders, clusters, hosts, vms, switches, detesters, etc. Permissions are assigned to objects on each objects permission tab.

Users and Groups are assigned permissions on the object using roles.  If the “Propagate to children” check box is deselected then the permissions are assign at that object only.  If it is checked then the permissions will flow down to the children objects.

These propagated permissions can be overridden further down by applying permission to a child object to the same user or group that was used.  If a user is a member of multiple groups assigned at the same object level with different permissions than the union of both permissions are made. If a user is a member of multiple groups that are applied at different object levels than the permissions set higher in the tree are overridden by the permissions set lower in the tree.  Finally if a user is a member of multiple groups assigned different permissions AND the user account is assigned permissions at the same level, then the permissions assigned to the user account will prevail.

Global permissions are new to vSphere 6 and allow you to assign permission to a solution (vCenter) at a root level (top level).

View/Sort/Export user and group lists

You can view, sort, and export lists of ESX users and groups to a file that is in HTML, XML, Microsoft Excel, or CSV format.

Using the VMware vCenter Web Client, you can View the Users or Groups that have been granted permissions to the object.  From the vCenter Web Client, select a give object, click on Manage in the action pane, then select the Permission tab.
Clicking on the column headers allows the ability to Sort each column, and by click in the bottom right hand corner you have the options of Exporting the list of assigned permissions

Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects

To remove or modify permissions on inventory object, follow these steps:

  • Select the object in the vCenter object hierarchy to which you want to Remove or Modify the permissions.
  • Click Manage in the action pane and select the Permissions tab
  • To Modify an existing permission, highlight the user or group and click the Pencil icon. Make the necessary changes
  • To Remove an existing permission, highlight the user or group and click the Red X icon

Create/Clone/Edit vCenter Server Roles

Cloning an existing vCenter Server role allows you to create a copy of the role and provide a new/different name to the role. Cloning a role is as easy as:

  • From the Home screen in the vSphere Web client, select Roles under Administration
  • Select the role you want to Clone and click the Clone Role Action icon
  • Provide a new name for the cloned role
  • Change or modify privileges assigned to the role
  • Click OK when complete

To Edit a role complete the following:

  • From the Home screen in the vSphere Web client, select Roles under Administration
  • Select the role you want to Edit and click the Pencil icon
  • Change or modify privileges assigned to the role
  • Click OK when complete

Determine the correct roles/privileges needed to integrate vCenter Server with other VMware products

Global permissions are applied to a global root object that spans solutions, for example, both vCenter Server and vCenter Orchestrator. Use global permissions to give a user or group privileges for all objects in all object hierarchies.

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

ESXTOP resources

In my continuing study and expansion of my knowledge of VMware I wanted to go more in-depth on the tools under the covers.  The most important tool for performance tuning and troubleshooting is ESXTOP, which is similar to the TOP command in Linux but is geared toward ESX and ESXi installations.  Instead of regurgitating and paraphrasing what I have found, I will supply the links to the appropriate pages.

First off I find Duncan Epping’s page on ESXTOP outstanding.  Not only does he go through and sum up the counters from the ESXTOP bible, but he also gives you recommended thresholds.  This way you have a point of reference of to help you spot issues right-away.  He also goes on explaining how to run ESXTOP in batch mode and then how to interpret the data using Excel, ESXPlot, and PerfMon.  This is my goto page for immediate reference.

Next up is the ESXTOP bible.  I found two versions of this: one for vSphere 4.0 and one for vSphere 4.1.  I have NOT compared both of them; I have focused mainly on the 4.1 version as this is the environment I am currently supporting.  This page does a deep dive into the counters explaining what they are and how they are derived.

Then I found a handy little reference card that give a short summary of the most important counters to know.

Finally, I found reference to a PowerShell commandlet that allows you to access this tool via a script.  When I looked for more information I found some articles by LucD going in-depth on how to use the commandlet.

Look at these great references and let me know if I missed any other.

Understand and apply LUN masking using PSA-related commands

Per knowledge base article 1009449.

  1. Look at the Multipath Plug-ins currently installed on your ESX with the command:

    # esxcfg-mpath -G

    The output indicates that there are, at a minimum, 2 plug-ins: the VMware Native Multipath Plug-in (NMP) and the MASK_PATH plug-in, which is used for masking LUNs. There may be other plug-ins if third party software (such as EMC PowerPath) is installed. For example:

  2. List all the claimrules currently on the ESX with the command:

    # esxcli corestorage claimrule list

    There are two MASK_PATH entries: one of class runtime and the other of class file.

    The runtime is the rules currently running in the PSA. The file is a reference to the rules defined in/etc/vmware/esx.conf. These are identical, but they could be different if you are in the process of modifying the /etc/vmware/esx.conf.

  3. Add a rule to hide the LUN with the command:

    # esxcli corestorage claimrule add –rule <number> -t location -A <hba_adapter> -C <channel> -T <target> -L <lun> -P MASK_PATH

    The parameters -A <hba_adapter> -C <channel> -T <target> -L <lun> define a unique path. You can leave some of them unspecified if the LUN is uniquely defined. The value for parameter –rule can be any number between 101 and 200 that does not conflict with a pre-existing rule number from step 2.

  4. Verify that the rule has taken with the command:

    # esxcli corestorage claimrule list

    The output indicates our new rule. It is only of class file. You must then load it into the PSA.

  5. Reload your claimrules with the command:

    # esxcli corestorage claimrule load

  6. Re-examine your claim rules and you verify that you can see both the file and runtime class. Run the command:

    # esxcli corestorage claimrule list

  7. Unclaim all paths to a device and then run the loaded claimrules on each of the paths to reclaim them. Run the command:

    # esxcli corestorage claiming reclaim -d <naa.id>

    where <naa.id> Is the naa id used in step 3. This device is the LUN being unpresented. This command attempts to unclaim all paths to a device and runs the loaded claimrules on each of the paths unclaimed to attempt to reclaim them.

  8. Verify that the masked device is no longer used by the ESX host.

    If you are masking a datastore, perform one of these options:

    • Connect the vSphere Client to the host and click HostConfigurationStorage, then click Refresh. The masked datastore does not appear in the list.
    • Rescan the host by navigating to HostConfigurationStorage Adapters > Rescan All.
    • Run the command:

      # esxcfg-scsidevs -m

      The masked datastore does not appear in the list.

      To verify that a masked LUN is no longer an active device, run the command:

      # esxcfg-mpath -L | grep <naa.id>