Knowledge

• Identify configuration files related to network security
  
• Identify virtual switch security characteristics

Skills and Abilities

• Add/Edit Remove users/groups on an ESXi host
  
• Customize SSH settings for increased security
  
• Enable/Disable certificate checking
  
• Generate ESXi host certificates
  
• Enable ESXi lockdown mode
  
• Replace default certificate with CA-signed certificate
  
• Configure SSL timeouts
  
• Configure vSphere Authentication Proxy
  
• Enable strong passwords and configure password policies
  
• Identify methods for hardening virtual machines
  
• Analyze logs for security-related messages
  
• Manage Active Directory integration
  

Add/Edit Remove users/groups on an ESXi host

vSphere Security Guide, Chapter 4 “Authentication and User Management”, Section “Managing vSphere Users / Groups”, page 42.

A user is an individual authorized to log in to either ESXi or vCenter Server.

ESXi users fall into two categories: those who can access the host through vCenter Server and those who can access by directly logging in to the host from the vSphere Client, a third-party client, or a command shell.

The user list that ESXi maintains locally is separate from the users known to vCenter Server, which are either local Windows users or users that are part of the Windows domain. If Active Directory authentication has been configured on the host, then the same Windows domain users known to vCenter Server will be available on the ESXi host.

Best Practices for vSphere Users
Use best practices for creating and managing users to increase the security and manageability of your vSphere environment.
VMware recommends several best practices for creating users in your vSphere environment: 

• Do not create a user named ALL. Privileges associated with the name ALL might not be available to all users in some situations. For example, if a user named ALL has Administrator privileges, a user with ReadOnly privileges might be able to log in to the host remotely. This is not the intended behavior.
  
• Use a directory service or vCenter Server to centralize access control, rather than defining users on individual hosts.
  
• Choose a local Windows user or group to have the Administrator role in vCenter Server.
  
• Because of the confusion that duplicate naming can cause, check the vCenter Server user list before you create ESXi host users to avoid duplicating names. To check for vCenter Server users, review the Windows domain list.
  

Add a Local User
Adding a user to the users table updates the internal user list that the host maintains.

Procedure 

• Log in to ESXi using the vSphere Client.
  
• Click the Local Users & Groups tab and click Users.
  
• Right-click anywhere in the Users table and click Add to open the Add New User dialog box.
  
• Enter a login, a user name, a numeric user ID (UID), and a password.
  NOTE Do not create a user named ALL. Privileges associated with the name ALL might not be available to all users in some situations. For example, if a user named ALL has Administrator privileges, a user with ReadOnly privileges might be able to log in to the host remotely. This is not the intended behavior.
  
  • Specifying the user name and UID are optional. If you do not specify the UID, the vSphere Client assigns the next available UID.
    
  • Create a password that meets the length and complexity requirements. The host checks for password compliance using the default authentication plug-in, pam_passwdqc.so. If the password is not compliant, the following error appears: A general system error occurred: passwd: Authentication token manipulation error.
    
• To change the user’s ability to access ESXi through a command shell, select or deselect Grant shell access to this user.
  NOTE To be granted shell access, users must also have an Administrator role for an inventory object on the host.
  In general, do not grant shell access unless the user has a justifiable need. Users that access the host only through the vSphere Client do not need shell access.
  
• To add the user to a group, select the group name from the Group drop-down menu and click Add.
  
• Click OK.
  

Modify the Settings for a User on the Host
You can change the user ID, user name, password, and group settings for a user. You can also grant a user shell access.

Procedure

1. Log in to ESXi using the vSphere Client.
   
2. Click the Local Users & Groups tab and click Users.
   
3. Right-click the user and click Edit to open the Edit User dialog box.
   
4. To change the user ID, enter a numeric user UID in the UID text box.
   The vSphere Client assigns the UID when you first create the user. In most cases, you do not have to change this assignment.
   
5. Enter a new user name.
   
6. To change the user’s password, select Change Password and enter the new password.
   Create a password that meets the length and complexity requirements. The host checks for password compliance using the default authentication plug-in, pam_passwdqc.so. If the password is not compliant, the following error appears: A general system error occurred: passwd: Authentication token manipulation error.
   
7. To change the user’s ability to access ESXi through a command shell, select or deselect Grant shell access to this user.
   NOTE To be granted shell access, users must also have an Administrator role for an inventory object on the host.
   In general, do not grant shell access unless the user has a justifiable need. Users that access the host only through the vSphere Client do not need shell access.
   
8. To add the user to a group, select the group name from the Group drop-down menu and click Add.
   
9. To remove the user from a group, select the group name from the Group membership box and click Remove.
   
10. Click OK.
    

Remove a User from a Host
You can remove a user from the host.
CAUTION Do not remove the root user.

If you remove a user from the host, they lose permissions to all objects on the host and cannot log in again.

NOTE Users who are logged in and are removed from the domain keep their host permissions until you restart the host.

Procedure 

1. Log in to ESXi using the vSphere Client.
   
2. Click the Local Users & Groups tab and click Users.
   
3. Right-click the user to remove and select Remove.
   Do not remove the root user for any reason.
   

Removing or Modifying vCenter Server Users
When you remove users from vCenter Server, you also remove permissions granted to those users. Modifying a user or group name causes the original name to become invalid.
To remove users from vCenter Server, you must remove them from the domain or Active Directory users list.
If you remove users from the vCenter Server domain, they lose permissions to all objects in the vSphere environment and cannot log in again.
NOTE Users who are logged in and are removed from the domain keep their vSphere permissions until the next validation period. The default is every 24 hours.
Removing a group does not affect the permissions granted individually to the users in that group or permissions granted as part of inclusion in another group.
If you change a user’s name in the domain, the original user name becomes invalid in the vCenter Server system. If you change the name of a group, the original group becomes invalid after you restart the vCenter Server system.

Customize SSH settings for increased security

Official Documentation:
VMware KB 2004746 “Using ESXi Shell in ESXi 5.x”

Enabling ESXi Shell access using the vSphere Client
Use the vSphere Client to enable local and remote access to the ESXi Shell: 

1. Log into a vCenter Server system using the vSphere Client.
   
2. Select the host in the inventory panel.
   
3. Click the Configuration tab and click Security Profile.
   
4. In the Services section, click Properties.
   Select ESXi Shell from this list:
   ESXi Shell
   SSH 
5. Direct Console UI
   
6. Click Options and select Start and stop manually.
   Note: When you select Start and stop manually, the service does not start when you reboot the host. If you want the service to start when you reboot the host, select Start and stop with host.
   
7. Click Start to enable the service.
   
8. Click OK.
   

Enabling ESXi Shell access using the Direct Console User Interface
Use the direct console user interface to enable the ESXi Shell:

1. From the Direct Console User Interface, press F2 to access the System Customization menu.
   
2. Select Troubleshooting Options and press Enter.
   
3. From the Troubleshooting Mode Options menu, select Enable ESXi Shell.
   

   Enable ESXi Shell
   Enable SSH
   

4. Press Enter to enable the service.
   

Configuring the timeout for the ESXi Shell

By default, the timeout setting for the ESXi Shell is 0 (disabled). The timeout setting is the number of minutes that can elapse before you must log in after the ESXi Shell is enabled. After the timeout period, if you have not logged in, the shell is disabled.

Note: If you are logged in when the timeout period elapses, your session persists. However, the ESXi Shell is disabled and it prevents other users from logging in.

• To set the ESXi Shell timeout from the Direct Console User Interface:
  
  • From the Direct Console User Interface, press F2 to access the System Customization menu.
    
  • Click Troubleshooting Mode Options.
    
  • Modify ESXi Shell and SSH timeouts and press Enter.
    
  • Enter the timeout in minutes.
    
  • Press Enter.
    
  • Press Esc until you return to the main menu of the Direct Console User Interface.
    
• To set the ESXi Shell timeout from vSphere Client:
  
  • Log into a vCenter Server system using the vSphere Client.
    
  • Select the host in the inventory panel and click Configuration tab.
    
  • Under Software, click Advanced Settings.
    
  • In the left panel, click UserVars.
    
  • In the UserVars.ESXiShellTimeOut field, enter the timeout setting.
    
  • Click OK.
    

Note: If ESXi Shell and SSH are enabled, the option to modify the timeout value is grayed out. To change the timeout value, ensure both ESXi Shell and SSH are disabled. This is by design and is intended to indicate when the timeout values would take effect.

Other references:

• VMware KB 2003637 “Cluster warning for ESXi Shell and SSH appear on an ESXi 5 host”
  

Enable/Disable certificate checking

Official Documentation:

vSphere Security Guide, Chapter 5 “Encryption and Security Certificates for ESXi and vCenter Server”, section “Enable Certificate Checking and Verify Host Thumbprints”, page 70.
To prevent man-in-the-middle attacks and to fully use the security that certificates provide, certificate checking is enabled by default. You can verify that certificate checking is enabled in the vSphere Client.

NOTE vCenter Server certificates are preserved across upgrades.

Procedure

1. Log in to the vCenter Server system using the vSphere Client.
   
2. Select Administration > vCenter Server Settings.
   
3. Click SSL Settings in the left pane and verify that Check host certificates is selected.
   
4. If there are hosts that require manual validation, compare the thumbprints listed for the hosts to the thumbprints in the host console.
   To obtain the host thumbprint, use the Direct Console User Interface (DCUI).
   
   1. Log in to the direct console and press F2 to access the System Customization menu.
      
   2. Select View Support Information.
      The host thumbprint appears in the column on the right.
      
5. If the thumbprint matches, select the Verify check box next to the host.
   Hosts that are not selected will be disconnected after you click OK.
   
6. Click OK.
   

Generate ESXi host certificates

Official Documentation:

vSphere Security Guide, Chapter 5 “Encryption and Security Certificates for ESXi and vCenter Server”, section “Generate New Certificates for ESXi”,  page 72.

You typically generate new certificates only if you change the host name or accidentally delete the certificate.

Under certain circumstances, you might be required to force the host to generate new certificates.

Procedure

1. Log in to the ESXi Shell and acquire root privileges.
   
2. In the directory /etc/vmware/ssl, back up any existing certificates by renaming them using the following commands.
   

   mv rui.crt orig.rui.crt
   

   mv rui.key orig.rui.key
   

   NOTE If you are regenerating certificates because you have deleted them, this step is unnecessary.
   

3. Run the command /sbin/generate-certificates to generate new certificates.
   
4. Restart the host after you install the new certificate.
   Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.
   
5. Confirm that the host successfully generated new certificates by using the following command and comparing the time stamps of the new certificate files with orig.rui.crt and orig.rui.key.
   

   ls -la

The certificate consists of two files: the certificate itself (rui.crt) and the private-key file (rui.key).

Default Location of ESXi and vCenter Server Certificate Files

Enable ESXi lockdown mode

Official Documentation:

vSphere Security Guide, Chapter 6 “Lockdown Mode”, page 81.

To increase the security of your ESXi hosts, you can put them in lockdown mode.

When you enable lockdown mode, no users other than vpxuser have authentication permissions, nor can they perform operations against the host directly. Lockdown mode forces all operations to be performed through vCenter Server.

When a host is in lockdown mode, you cannot run vSphere CLI commands from an administration server, from a script, or from vMA against the host. External software or management tools might not be able to retrieve or modify information from the ESXi host.

NOTE The root user is still authorized to log in to the direct console user interface when lockdown mode is enabled.

Enabling or disabling lockdown mode affects which types of users are authorized to access host services, but it does not affect the availability of those services. In other words, if the ESXi Shell, SSH, or Direct Console User Interface (DCUI) services are enabled, they will continue to run whether or not the host is in lockdown mode.

You can enable lockdown mode using the Add Host wizard to add a host to vCenter Server, using the vSphere Client to manage a host, or using the direct console user interface.

NOTE If you enable or disable lockdown mode using the Direct Console User Interface (DCUI), permissions for users and groups on the host are discarded. To preserve these permissions, you must enable and disable lockdown mode using the vSphere Client connected to vCenter Server.

Lockdown mode is only available on ESXi hosts that have been added to vCenter Server.

Lockdown Mode Behavior

Enabling lockdown mode affects which users are authorized to access host services.

Users who were logged in to the ESXi Shell before lockdown mode was enabled remain logged in and can run commands. However, these users cannot disable lockdown mode. No other users, including the root user and users with the Administrator role on the host, can use the ESXi Shell to log in to a host that is in lockdown mode.

Users with administrator privileges on the vCenter Server system can use the vSphere Client to disable lockdown mode for hosts that are managed by the vCenter Server system. Root users and users with the

Administrator role on the host can always log directly in to the host using the Direct Console User Interface (DCUI) to disable lockdown mode. If the host is not managed by vCenter Server or if the host is unreachable, you must reinstall ESXi.

NOTE Lockdown mode does not apply to root users who log in using authorized keys. When you use an authorized key file for root user authentication, root users are not prevented from accessing a host with SSH when the host is in lockdown mode.

Different services are available to different types of users when the host is running in lockdown mode, compared to when the host is running in normal mode. Non-root users cannot run system commands in the

ESXi Shell.

Lockdown Mode Behavior

Lockdown Mode Configurations

You can enable or disable remote and local access to the ESXi Shell to create different lockdown mode configurations.

The following table lists which services are enabled for three typical configurations.

CAUTION If you lose access to vCenter Server while running in Total Lockdown Mode, you must reinstall ESXi to gain access to the host.

Enable Lockdown Mode Using the vSphere Client

Enable lockdown mode to require that all configuration changes go through vCenter Server. You can also enable or disable lockdown mode through the Direct Console User Interface (DCUI).

Procedure

1. Log in to a vCenter Server system using the vSphere Client.
   
2. Select the host in the inventory panel.
   
3. Click the Configuration tab and click Security Profile.
   
4. Click the Edit link next to lockdown mode.
   The Lockdown Mode dialog box appears.
   
5. Select Enable Lockdown Mode.
   
6. Click OK.
   

Enable Lockdown Mode from the Direct Console User Interface

You can enable lockdown mode from the Direct Console User Interface (DCUI).

NOTE If you enable or disable lockdown mode using the Direct Console User Interface, permissions for users and groups on the host are discarded. To preserve these permissions, you must enable and disable lockdown mode using the vSphere Client connected to vCenter Server.

Procedure

1. At the Direct Console User Interface of the host, press F2 and log in.
   
2. Scroll to the Configure Lockdown Mode setting and press Enter.
   
3. Press Esc until you return to the main menu of the Direct Console User Interface.
   

Replace default certificate with CA-signed certificate

Official Documentation:

vSphere Security Guide, Chapter 5 “Encryption and Security Certificates for ESXi and vCenter Server”, section “Replace a Default Host Certificate with a CA-Signed Certificate”, page 71.

The ESXi host uses automatically generated certificates that are created as part of the installation process. These certificates are unique and make it possible to begin using the server, but they are not verifiable and they are not signed by a trusted, well-known certificate authority (CA).

Using default certificates might not comply with the security policy of your organization. If you require a certificate from a trusted certificate authority, you can replace the default certificate.

NOTE If the host has Verify Certificates enabled, replacing the default certificate might cause vCenter Server to stop managing the host. If the new certificate is not verifiable by vCenter Server, you must reconnect the host using the vSphere Client.

ESXi supports only X.509 certificates to encrypt session information sent over SSL connections between server and client components.

NOTE For information about replacing default certificates on a vCenter Server system, see the vSphere Examples and Scenarios documentation.

Prerequisites

All file transfers and other communications occur over a secure HTTPS session. The user used to authenticate the session must have the privilege Host.Config.AdvancedConfig on the host. For more information on ESXi privileges, see Chapter 4, “Authentication and User Management,” on page 39.

Procedure

1. Log in to the ESXi Shell and acquire root privileges.
   
2. In the directory /etc/vmware/ssl, rename the existing certificates using the following commands.
   

   mv rui.crt orig.rui.crt
   

   mv rui.key orig.rui.key
   

3. Copy the new certificate and key to /etc/vmware/ssl.
   
4. Rename the new certificate and key to rui.crt and rui.key.
   
5. Restart the host after you install the new certificate.
   Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.
   

Configure SSL timeouts

Official Documentation:

vSphere Security Guide, Chapter 5 “Encryption and Security Certificates for ESXi and vCenter Server”, Section “”Configure SSL Timeouts”, page 73.

You can configure SSL timeouts for ESXi.

Timeout periods can be set for two types of idle connections:

• The Read Timeout setting applies to connections that have completed the SSL handshake process with port 443 of ESXi.
  
• The Handshake Timeout setting applies to connections that have not completed the SSL handshake process with port 443 of ESXi.
  

Both connection timeouts are set in milliseconds.

Idle connections are disconnected after the timeout period. By default, fully established SSL connections have a timeout of infinity.

Procedure

1. Log in to the ESXi Shell and acquire root privileges.
   
2. Change to the directory /etc/vmware/hostd/.
   
3. Use a text editor to open the config.xml file.
   
4. Enter the <readTimeoutMs> value in milliseconds.
   For example, to set the Read Timeout to 20 seconds, enter the following command.
   <readTimeoutMs>20000</readTimeoutMs>
   
5. Enter the <handshakeTimeoutMs> value in milliseconds.
   For example, to set the Handshake Timeout to 20 seconds, enter the following command.
   <handshakeTimeoutMs>20000</handshakeTimeoutMs>
   
6. Save your changes and close the file.
   
7. Restart the hostd process:
   /etc/init.d/hostd restart
   

Configure vSphere Authentication Proxy

Official Documentation:

vSphere Security Guide, Chapter 4 “Authentication and User management”, section “Using vSphere Authentication Proxy” page 65.

When you use the vSphere Authentication Proxy, you do not need to transmit Active Directory credentials to the host. Users supply the domain name of the Active Directory server and the IP address of the authentication proxy server when they add a host to a domain.

Install the vSphere Authentication Proxy Service

To use the vSphere Authentication Proxy service (CAM service) for authentication, you must install the service on a host machine.

You can install the vSphere Authentication Proxy on the same machine as the associated vCenter Server, or on a different machine that has a network connection to the vCenter Server. The vSphere Authentication Proxy is not supported with vCenter Server versions earlier than version 5.0.

The vSphere Authentication Proxy service binds to an IPv4 address for communication with vCenter Server, and does not support IPv6. vCenter Server can be on an IPv4-only, IPv4/IPv6 mixed-mode, or IPv6-only host machine, but the machine that connects to vCenter Server through the vSphere Client must have an IPv4 address for the vSphere Authentication Proxy service to work.

Prerequisites

• Verify that you have administrator privileges on the host machine where you install the vSphere Authentication Proxy service.
  
• Verify that the host machine has Windows Installer 3.0 or later.
  
• Verify that the host machine has a supported processor and operating system. The vSphere Authentication Proxy supports the same processors and operating systems as vCenter Server.
  
• Verify that the host machine has a valid IPv4 address. You can install vSphere Authentication Proxy on an IPv4-only or IPv4/IPv6 mixed-mode host machine, but you cannot install vSphere Authentication Proxy
  
• on an IPv6-only host machine.
  
• If you are installing vSphere Authentication Proxy on a Windows Server 2008 R2 host machine, download and install the Windows hotfix described in Windows KB Article 981506 on the support.microsoft.com
  
• Web site. If this hotfix is not installed, the Authentication Proxy Adapter fails to initialize. This problem is accompanied by error messages in camadapter.log similar to Failed to bind CAM website with CTL
  
• and Failed to initialize CAMAdapter.
  

Gather the following information to complete the installation:

• The location where you will install the vSphere Authentication Proxy, if you are not using the default location.
  
• The IP address or host name, HTTP port, and credentials for the vCenter Server system that the vSphere Authentication Proxy will connect to.
  
• The host name or IP address to identify the vSphere Authentication Proxy host machine on the network.
  

Procedure

1. On the host machine where you will install the vSphere Authentication Proxy service, install the .NET Framework 3.5.
   
2. Install vSphere Auto Deploy.
   You do not have to install Auto Deploy on the same host machine as the vSphere Authentication Proxy service.
   
3. Add the host machine where you will install the authentication proxy service to the domain.
   
4. Use the Domain Administrator account to log in to the host machine.
   
5. In the software installer directory, double-click the autorun.exe file to start the installer.
   
6. Select VMware vSphere Authentication Proxy and click Install.
   
7. Follow the wizard prompts to complete the installation.
   During installation, the authentication service registers with the vCenter Server instance where Auto Deploy is registered.
   

The authentication proxy service is installed on the host machine.

NOTE When you install the vSphere Authentication Proxy service, the installer creates a domain account with appropriate privileges to run the authentication proxy service. The account name begins with the prefix CAMand has a 32-character, randomly generated password associated with it. The password is set to never expire.

Do not change the account settings.

Configure a Host to Use the vSphere Authentication Proxy for Authentication

After you install the vSphere Authentication Proxy service (CAM service), you must configure the host to use the authentication proxy server to authenticate users.

Prerequisites

Install the vSphere Authentication Proxy service (CAM service) on a host as described in “Install the vSphere Authentication Proxy Service,” on page 63.

Procedure 

1. Use the IIS manager on the host to set up the DHCP range.
   Setting the range allows hosts that are using DHCP in the management network to use the authenticationproxy service.
   

1. If a host is not provisioned by Auto Deploy, change the default SSL certificate to a self-signed certificate or to a certificate signed by a commercial certificate authority (CA).
   

Authenticating vSphere Authentication Proxy to ESXi

Before you use the vSphere Authentication Proxy to connect ESXi to a domain, you must authenticate the vSphere Authentication Proxy server to ESXi. If you use Host Profiles to connect a domain with the vSphere Authentication Proxy server, you do not need to authenticate the server. The host profile authenticates the proxy server to ESXi.

To authenticate ESXi to use the vSphere Authentication Proxy, export the server certificate from the vSphere Authentication Proxy system and import it to ESXi. You need only authenticate the server once.

NOTE By default, ESXi must authenticate the vSphere Authentication Proxy server when using it to join a domain. Make sure that this authentication functionality is enabled at all times. If you must disable authentication, you can use the Advanced Settings dialog box to set the UserVars.ActiveDirectoryVerifyCAMCertifcate attribute to 0.

Export vSphere Authentication Proxy Certificate To authenticate the vSphere Authentication Proxy to ESXi, you must provide ESXi with the proxy server certificate.

Prerequisites

Install the vSphere Authentication Proxy service (CAM service) on a host as described in “Install the vSphere Authentication Proxy Service,” on page 63.

Procedure

1. On the authentication proxy server system, use the IIS Manager to export the certificate.
   

Option	Action
For IIS 6	Right-click Computer Account Management Web Site. Select Properties > Directory Security > View Certificate.
For IIS 7	Click Computer Account Management Web Site in the left pane. Select Bindings to open the Site Bindings dialog box. Select https binding. Select Edit > View SSL Certificate.

1. Select Details > Copy to File.
   
2. Select the options Do Not Export the Private Key and Base-64 encoded X.509 (CER).
   

Import a vSphere Authentication Proxy Server Certificate to ESXi

To authenticate the vSphere Authentication Proxy server to ESXi, upload the proxy server certificate to ESXi.

You use the vSphere Client user interface to upload the vSphere Authentication Proxy server certificate to ESXi.

Prerequisites
Install the vSphere Authentication Proxy service (CAM service) on a host as described in “Install the vSphere Authentication Proxy Service,” on page 63.
Export the vSphere Authentication Proxy server certificate as described in “Export vSphere Authentication Proxy Certificate,” on page 65.

Procedure

1. Select a host in the vSphere Client inventory and click the Summary tab.
   
2. Upload the certificate for the authentication proxy server to a temporary location on ESXi.
   
   1. Under Resources, right-click a datastore and select Browse Datastore.
      
   2. Select a location for the certificate and select the Upload File button.
      
   3. Browse to the certificate and select Open.
      
3. Select the Configuration tab and click Authentication Services.
   
4. Click Import Certificate.
   
5. Enter the full path to the authentication proxy server certificate file on the host and the IP address of the authentication proxy server.
   Use the form [datastore name] file path to enter the path to the proxy server.
   
6. Click Import.
   

Use vSphere Authentication Proxy to Add a Host to a Domain

When you join a host to a directory service domain, you can use the vSphere Authentication Proxy server for authentication instead of transmitting user-supplied Active Directory credentials.

You can enter the domain name in one of two ways:

• name.tld (for example, domain.com): The account is created under the default container.
  
• name.tld/container/path (for example, domain.com/OU1/OU2): The account is created under a particular organizational unit (OU).
  

Prerequisites

• Verify that the vSphere Client is connected to a vCenter Server system or to the host.
  
• If ESXi is configured with a DHCP address, set up the DHCP range as described in “Configure a Host to Use the vSphere Authentication Proxy for Authentication,” on page 64.
  
• If ESXi is configured with a static IP address, verify that its associated profile is configured to use the vSphere Authentication Proxy service to join a domain so that the authentication proxy server can trust
  
• the ESXi IP address.
  
• If ESXi is using a self-signed certificate, verify that the host has been added to vCenter Server. This allows the authentication proxy server to trust ESXi.
  
• If ESXi is using a CA-signed certificate and is not provisioned by Auto Deploy, verify that the CA certificate has been added to the local trust certificate store of the authentication proxy server as described in
  
• “Configure a Host to Use the vSphere Authentication Proxy for Authentication,” on page 64.
  
• Authenticate the vSphere Authentication Proxy server to the host as described in “Authenticating vSphere Authentication Proxy to ESXi,” on page 65.
  

Procedure

1. In the vSphere Client inventory, select the host.
   
2. Select the Configuration tab and click Authentication Services.
   
3. Click Properties.
   
4. In the Directory Services Configuration dialog box, select the directory server from the drop-down menu.
   
5. Enter a domain.
   Use the form name.tld or name.tld/container/path.
   
6. Select the Use vSphere Authentication Proxy check box.
   
7. Enter the IP address of the authentication proxy server.
   
8. Click Join Domain.
   
9. Click OK.
   

View vSphere Authentication Proxy Settings

You can verify the IP address and the port where the proxy server listens.

After you set up a vSphere Authentication Proxy service on a host machine, you can view the host machine address and port information in the vSphere Client.

Procedure

• In the vSphere Client, select Inventory > Administration > vSphere Authentication Proxy.
  The VMware vSphere Authentication Proxy page is displayed.
  

Enable strong passwords and configure password policies

Official Documentation:

vSphere Security Guide, Chapter 7 “Best Practices for Virtual Machine and Host Security”, section “Host Password Strength and Complexity”, page 90.

By default, ESXi uses the pam_passwdqc.so plug-in to set the rules that users must observe when creating passwords and to check password strength.

The pam_passwdqc.so plug-in lets you determine the basic standards that all passwords must meet. By default, ESXi imposes no restrictions on the root password. However, when nonroot users attempt to change their passwords, the passwords they choose must meet the basic standards that pam_passwdqc.so sets.

A valid password should contain a combination of as many character classes as possible. Character classes include lowercase letters, uppercase letters, numbers, and special characters such as an underscore or dash.

NOTE When the number of character classes is counted, the plug-in does not count uppercase letters used as the first character in the password and numbers used as the last character of a password.

To configure password complexity, you can change the default value of the following parameters.

• retry is the number of times a user is prompted for a new password if the password candidate is not sufficiently strong.
  
• N0 is the number of characters required for a password that uses characters from only one character class.
  For example, the password contains only lowercase letters.
  
• N1 is the number of characters required for a password that uses characters from two character classes.
  
• N2 is used for passphrases. ESXi requires three words for a passphrase. Each word in the passphrase must be 8-40 characters long.
  
• N3 is the number of characters required for a password that uses characters from three character classes.
  
• N4 is the number of characters required for a password that uses characters from all four character classes.
  
• match is the number of characters allowed in a string that is reused from the old password. If the pam_passwdqc.so plug-in finds a reused string of this length or longer, it disqualifies the string from the
  
• strength test and uses only the remaining characters.
  

Setting any of these options to -1 directs the pam_passwdqc.so plug-in to ignore the requirement.

Setting any of these options to disabled directs the pam_passwdqc.so plug-in to disqualify passwords with the associated characteristic. The values used must be in descending order except for -1 and disabled.

NOTE The pam_passwdqc.so plug-in used in Linux provides more parameters than the parameters supported for ESXi.

For more information on the pam_passwdqc.so plug-in, see your Linux documentation.

Change Default Password Complexity for the pam_passwdqc.so Plug-In

Configure the pam_passwdqc.so plug-in to determine the basic standards all passwords must meet.

Procedure

1. Log in to the ESXi Shell and acquire root privileges.
   
2. Open the passwd file with a text editor.
   For example, vi /etc/pam.d/passwd
   
3. Edit the following line.
   password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4
   
4. Save the file.
   

Example: Editing /etc/pam.d/passwd
password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=12,9,8,7,6
With this setting in effect, the password requirements are:

• retry=3: A user is allowed 3 attempts to enter a sufficient password.
  
• N0=12: Passwords containing characters from one character class must be at least 12 characters long.
  
• N1=9: Passwords containing characters from two character classes must be at least nine characters long.
  
• N2=8: Passphrases must contain words that are each at least eight characters long.
  
• N3=7: Passwords containing characters from three character classes must be at least seven characters long.
  
• N4=6: Passwords containing characters from all four character classes must be at least six characters long.
  

Identify methods for hardening virtual machines

Official Documentation:

vSphere Security Guide, Chapter 7 “Best Practices for Virtual Machine and Host Security”, section “Virtual Machine Recommendations”, page 85.

There are several safety precautions to consider when evaluating virtual machine security and administering virtual machines.

Installing Antivirus Software

Because each virtual machine hosts a standard operating system, consider protecting it from viruses by installing antivirus software. Depending on how you are using the virtual machine, you might also want to

install a software firewall.

Stagger the schedule for virus scans, particularly in deployments with a large number of virtual machines.

Performance of systems in your environment will degrade significantly if you scan all virtual machines simultaneously.

Because software firewalls and antivirus software can be virtualization-intensive, you can balance the need for these two security measures against virtual machine performance, especially if you are confident that your virtual machines are in a fully trusted environment.

Limiting Exposure of Sensitive Data Copied to the Clipboard

Copy and paste operations are disabled by default for hosts to prevent exposing sensitive data that has been copied to the clipboard.

When copy and paste is enabled on a virtual machine running VMware Tools, you can copy and paste between the guest operating system and remote console. As soon as the console window gains focus, non-privileged users and processes running in the virtual machine can access the clipboard for the virtual machine console.

If a user copies sensitive information to the clipboard before using the console, the user—perhaps unknowingly —exposes sensitive data to the virtual machine. To prevent this problem, copy and paste operations for the guest operating system are disabled by default.

It is possible to enable copy and paste operations for virtual machines if necessary.

Removing Unnecessary Hardware Devices

Users and processes without privileges on a virtual machine can connect or disconnect hardware devices, such as network adapters and CD-ROM drives. Therefore, removing unnecessary hardware devices can help prevent attacks.

Attackers can use this capability to breach virtual machine security in several ways. For example, an attacker with access to a virtual machine can connect a disconnected CD-ROM drive and access sensitive information on the media left in the drive, or disconnect a network adapter to isolate the virtual machine from its network, resulting in a denial of service.

As a general security precaution, use commands on the vSphere Client Configuration tab to remove any unneeded or unused hardware devices. Although this measure tightens virtual machine security, it is not a

good solution in situations where you might bring an unused device back into service at a later time.

Limiting Guest Operating System Writes to Host Memory

The guest operating system processes send informational messages to the host through VMware Tools. If the amount of data the host stored as a result of these messages was unlimited, an unrestricted data flow would provide an opportunity for an attacker to stage a denial-of-service (DoS) attack.

The informational messages sent by guest operating processes are known as setinfo messages and typically contain name-value pairs that define virtual machine characteristics or identifiers that the host stores (for example, ipaddress=10.17.87.224). The configuration file containing these name-value pairs is limited to a size of 1MB, which prevents attackers from staging a DoS attack by writing software that mimics VMware Tools and filling the host’s memory with arbitrary configuration data, which consumes space needed by the virtual machines.

If you require more than 1MB of storage for name-value pairs, you can change the value as required. You can also prevent the guest operating system processes from writing any name-value pairs to the configuration file.

Prevent the Guest Operating System Processes from Sending Configuration Messages to the Host

You can prevent guests from writing any name-value pairs to the configuration file. This is appropriate when guest operating systems must be prevented from modifying configuration settings.

Configuring Logging Levels for the Guest Operating System

Virtual machines can write troubleshooting information into a virtual machine log file stored on the VMFS volume. Virtual machine users and processes can abuse logging either on purpose or inadvertently so that large amounts of data flood the log file. Over time, the log file can consume enough file system space to cause a denial of service.

To prevent this problem, consider modifying logging settings for virtual machine guest operating systems.

These settings can limit the total size and number of log files. Normally, a new log file is created each time you reboot a host, so the file can grow to be quite large. You can ensure new log file creation happens more frequently by limiting the maximum size of the log files. VMware recommends saving 10 log files, each one limited to 100KB. These values are large enough to capture sufficient information to debug most problems that might occur.

Each time an entry is written to the log, the size of the log is checked. If it is over the limit, the next entry is written to a new log. If the maximum number of log files exists, the oldest log file is deleted. A DoS attack that avoids these limits could be attempted by writing an enormous log entry, but each log entry is limited in size to 4KB, so no log files are ever more than 4KB larger than the configured limit.

Securing Fault Tolerance Logging Traffic

When you enable Fault Tolerance (FT), VMware vLockstep captures inputs and events that occur on a Primary VM and sends them to the Secondary VM, which is running on another host.

This logging traffic between the Primary and Secondary VMs is unencrypted and contains guest network and storage I/O data, as well as the memory contents of the guest operating system. This traffic can include sensitive data such as passwords in plaintext. To avoid such data being divulged, ensure that this network is secured, especially to avoid “man-in-the-middle” attacks. For example, use a private network for FT logging traffic.

Analyze logs for security-related messages

Official Documentation:

VMware KB2004201 “Location of ESXi 5.0 log files”

ESXi 5.0 Host Log Files

Logs for an ESXi 5.0 host are grouped according to the source component:

• /var/log/auth.log: ESXi Shell authentication success and failure.
  
• /var/log/dhclient.log: DHCP client service, including discovery, address lease requests and renewals.
  
• /var/log/esxupdate.log: ESXi patch and update installation logs.
  
• /var/log/hostd.log: Host management service logs, including virtual machine and host Task and Events, communication with the vSphere Client and vCenter Server vpxa agent, and SDK connections.
  
• /var/log/shell.log: ESXi Shell usage logs, including enable/disable and every command entered. For more information, see the Managing vSphere with Command-Line Interfaces section of the vSphere 5 Command Line documentation and Auditing ESXi Shell logins and commands in ESXi 5.x (2004810).
  
• /var/log/sysboot.log: Early VMkernel startup and module loading.
  
• /var/log/boot.gz: A compressed file that contains boot log information and can be read using zcat /var/log/boot.gz|more.
  
• /var/log/syslog.log: Management service initialization, watchdogs, scheduled tasks and DCUI use.
  
• /var/log/usb.log: USB device arbitration events, such as discovery and pass-through to virtual machines.
  
• /var/log/vob.log: VMkernel Observation events, similar to vob.component.event.
  
• /var/log/vmkernel.log: Core VMkernel logs, including device discovery, storage and networking device and driver events, and virtual machine startup.
  
• /var/log/vmkwarning.log: A summary of Warning and Alert log messages excerpted from the VMkernel logs.
  
• /var/log/vmksummary.log: A summary of ESXi host startup and shutdown, and an hourly heartbeat with uptime, number of virtual machines running, and service resource consumption. For more information, see Format of the ESXi 5.0 vmksummary log file (2004566).
  

Note: For information on sending logs to another location (such as a datastore or remote syslog server), see Configuring syslog on ESXi 5.0 (2003322)

Logs from vCenter Server Components on ESXi 5.0

When an ESXi 5.0 host is managed by vCenter Server 5.0, two components are installed, each with its own logs:

• /var/log/vpxa.log: vCenter Server vpxa agent logs, including communication with vCenter Server and the Host Management hostd agent.
  
• /var/log/fdm.log: vSphere High Availability logs, produced by the fdm service. For more information, see the vSphere HA Security section of the vSphere 5.0 Availability Guide.
  

Note: If persistent scratch space is configured, many of these logs are located on the scratch volume and the /var/log/ directory contains symlinks to the persistent storage location. Rotated logs are compressed at the persistent location and/or at /var/run/log/. For more information, see Creating a persistent scratch location for ESXi (1033696).

Manage Active Directory integration

Official Documentation:

vSphere Security Guide, Chapter 4 “Authentication and User Management”, section “Using Active Directory to Manage Users and Groups”, page 61.

You can configure ESXi to use a directory service such as Active Directory to manage users and groups.

When you use Active Directory, users supply their Active Directory credentials and the domain name of the Active Directory server when adding a host to a domain.

Configure a Host to Use Active Directory

You can configure the ESXi host to use a directory service such as Active Directory to manage users and groups.

Prerequisites

• Verify that you have an Active Directory domain. See your directory server documentation.
  
• Verify that the host name of ESXi is fully qualified with the domain name of the Active Directory forest.
  fully qualified domain name = host_name.domain_name
  

Procedure

1. Synchronize the time between ESXi and the directory service system using NTP.
   ESXi supports synchronizing time with an external NTPv3 or NTPv4 server that is compliant with RFC 5905 and RFC 1305. The Microsoft Windows W32Time service does not meet these requirements when running with default settings. See the VMware Knowledge Base for information about how to synchronize ESXi time with a Microsoft Domain Controller.
   
2. Ensure that the DNS servers you configured for the host can resolve the host names for the Active Directory controllers.
   
   1. In the vSphere Client, select the host in the inventory.
      
   2. Click the Configuration tab and click DNS and Routing.
      
   3. Click the Properties link at the top right of the panel.
      
   4. In the DNS and Routing Configuration dialog box, verify that the host name and DNS server information for the host are correct.
      

Other exam notes

• The Saffageek VCAP5-DCA Objectives http://thesaffageek.co.uk/vcap5-dca-objectives/
  
• Paul Grevink The VCAP5-DCA diaries http://paulgrevink.wordpress.com/the-vcap5-dca-diaries/
  
• Edward Grigson VCAP5-DCA notes http://www.vexperienced.co.uk/vcap5-dca/
  
• Jason Langer VCAP5-DCA notes http://www.virtuallanger.com/vcap-dca-5/
  
• The Foglite VCAP5-DCA notes http://thefoglite.com/vcap-dca5-objective/
  

VMware vSphere official documentation

Disclaimer.
The information in this article is provided “AS IS” with no warranties, and confers no rights. This article does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.