Saturday, May 26, 2012

Securing ESXi Host with Certificates - Obj 7.1 Part 1

I am covering here how to secure ESXi host. This include dealing with certificates (both default and CA assigned) and also some guidelines on what are the minimum steps you need to take to secure the VMware environment and make it a trusted one.

Generate New Certificates for ESXi

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.

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

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

Replace a Default Host Certificate with a CA-Signed Certificate

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.


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 About Users, Groups, Permissions, and Roles.


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.

Encryption and Security Certificates for ESXi and vCenter Server

ESXi and vCenter Server support standard X.509 version 3 (X.509v3) certificates to encrypt session information sent over Secure Socket Layer (SSL) protocol connections between components. If SSL is enabled, data is private, protected, and cannot be modified in transit without detection.

All network traffic is encrypted as long as the following conditions are true:
You did not change the Web proxy service to allow unencrypted traffic for the port.

Your firewall is configured for medium or high security.

Certificate checking is enabled by default and SSL certificates are used to encrypt network traffic. However, ESXi and vCenter Server use automatically generated certificates that are created as part of the installation process and stored on the server system. These certificates are unique and make it possible to begin using the server, but they are not verifiable and are not signed by a trusted-well-known certificate authority (CA). These default certificates are vulnerable to possible man-in-the-middle attacks.

To receive the full benefit of certificate checking, particularly if you intend to use encrypted remote connections externally, install new certificates that are signed by a valid internal certificate authority or purchase a certificate from a trusted security authority. Replacing vCenter Server certificates is described in the vSphere Examples and Scenarios documentation.

Note:      If the self-signed certificate is used, clients receive a warning about the certificate. To address this issue, install a certificate that is signed by a recognized certificate authority. If CA-signed certificates are not installed, all communication between vCenter Server and vSphere Clients is encrypted using a self-signed certificate. These certificates do not provide the authentication security you might need in a production environment.

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

Server                                                   Location____________________________________

ESXi 5.0                                               /etc/vmware/ssl/

vCenter Server (Windows 2008)           C:\Program Data\VMware\VMware VirtualCenter\SSL

vCenter Server (Windows 2003)           C:\Documents and Settings\All Users\Application
                                                             Data\VMware\VMware VirtualCenter\SSL

General Security Recommendations

To protect the host against unauthorized intrusion and misuse, VMware imposes constraints on several parameters, settings, and activities. You can loosen the constraints to meet your configuration needs, but if you do so, make sure that you are working in a trusted environment and have taken enough other security measures to protect the network as a whole and the devices connected to the host.

Consider the following recommendations when evaluating host security and administration.

             Limit user access.

To improve security, restrict user access to the management interface and enforce access security policies like setting up password restrictions.

The ESXi Shell has privileged access to certain parts of the host. Therefore, provide only trusted users with ESXi Shell login access.

Also, strive to run only the essential processes, services, and agents such as virus checkers, and virtual machine backups.

            Use the vSphere Client to administer your ESXi hosts.

Whenever possible, use the vSphere Client or a third-party network management tool to administer your ESXi hosts instead of working though the command-line interface as the root user. Using the vSphere Client lets you limit the accounts with access to the ESXi Shell, safely delegate responsibilities, and set up roles that prevent administrators and users from using capabilities they do not need.

             Use only VMware sources to upgrade ESXi components.

The host runs a variety of third-party packages to support management interfaces or tasks that you must perform. VMware does not support upgrading these packages from anything other than a VMware source. If you use a download or patch from another source, you might compromise management interface security or functions. Regularly check third-party vendor sites and the VMware knowledge base for security alerts.

               In addition to implementing the firewall, risks to the hosts are mitigated using other methods.

             ESXi runs only services essential to managing its functions, and the distribution is limited to the features required to run ESXi.

             By default, all ports not specifically required for management access to the host are closed. You must specifically open ports if you need additional services.

             By default, weak ciphers are disabled and all communications from clients are secured by SSL. The exact algorithms used for securing the channel depend on the SSL handshake. Default certificates created on ESXi use SHA-1 with RSA encryption as the signature algorithm.

             The Tomcat Web service, used internally by ESXi to support access by Web clients, has been modified to run only those functions required for administration and monitoring by a Web client. As a result, ESXi is not vulnerable to the Tomcat security issues reported in broader use.

             VMware monitors all security alerts that could affect ESXi security and, if needed, issues a security patch.

             Insecure services such as FTP and Telnet are not installed, and the ports for these services are closed by default. Because more secure services such as SSH and SFTP are easily available, always avoid using these insecure services in favor of their safer alternatives. If you must use insecure services and have implemented sufficient protection for the host, you must explicitly open ports to support them.

Cannot Configure vSphere HA When Using Custom SSL Certificates

After you install custom SSL certificates, attempts to enable vSphere High Availability (HA) fail.


When you attempt to enable vSphere HA on a host with custom SSL certificates installed, the following error message appears: vSphere HA cannot be configured on this host because its SSL thumbprint has not been verified.



In the vSphere Client, disconnect the host that has custom SSL certificates installed.
Reconnect the host to vCenter Server.
Accept the host's SSL certificate.
Enable vSphere HA on the host.

For more information on other security related issue, refer the online documentation and search the particular

There are other areas I could have covered here such as ESXi lock down mode,  authenticalion proxy, 
hardening virtual machines etc. etc. but it will be adding little complexity in the above subjects so may be 


Thursday, May 24, 2012

vSphere AutoDeploy PowerCLI cmdlets

I was reviewing the guide for Auto Deploy and on page 16 found this table which will be a good handy resource to memorize the PowerCLI commands to use with rule sets.



Returns a list of Auto Deploy cmdlets.

Creates a new rule with the specified items and patterns.

Updates an existing rule with the specified items and patterns.You cannot update a rule that is part of a rule set.

Retrieves the rules with the specified names.

Clones and updates an existing rule.

Adds one or more rules to the working rule set and, by default, also to the active  rule set. Use the NoActivate parameter to add a rule only to the working rule set.

Removes one or more rules from the working rule set and from the active ruleset. Run this command with the - Delete parameter to completely delete the rule.

Explicitly sets the list of rules in the working rule set.

Retrieves the current working rule set or the current active rule set.

Activates a rule set so that any new requests are evaluated through the rule set.

Retrieves rules matching a pattern. For example, you can retrieve all rules that apply to a host or hosts. Use this cmdlet primarily for debugging.


Checks whether the items associated with a specified host are in compliance with the active rule set.
Given the output of Test-DeployRulesetCompliance, this cmdlet updates the image profile, host profile, and location for each host in the vCenter Server inventory. The cmdlet might apply image profiles, apply host profiles, or move hosts to prespecified folders or clusters on the  vCenter Server system.

Associates the specified image profile with the specified host.

Retrieves the image profile in use by a specified host. This cmdlet differs from the Get-EsxImageProfile cmdlet in the Image Builder PowerCLI.

Use this cmdlet only if the Auto Deploy image cache is accidentally deleted.

Retrieves the attributes for a host that are used when the Auto Deploy server evaluates the rules.

If you want to find out the PDF its located under other resources on the main documentation page.

Enjoy reading for your VCAP.

Tuesday, May 22, 2012

VCAP5-DCD - Hot Target - Objective - 1.3

Objective 1.3 – Determine Risks, Constraints, and Assumptions


·         Identify appropriate best practices related to a proposed design.                      

* Associate a role to the information that needs to be collected.

·         Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.

Skills and Abilities

·         Given a business ask or request, determine whether it is a risk, a requirement, a constraint, or an assumption.

·         Given an organization, evaluate and respond to common inherent risks, constraints, and/or assumptions.


Scope – Identify the project scope in detail

·         Properly identifying the scope prevents unintended project expansion.

·         Example: The virtualization project includes only the London datacenter’s test and development servers. At this time, it does not include any production servers or remote offices.

Goals – Identify and list the overall project goals that the organization wants to achieve

·          The project goals should be derived from the business goals of the organization.

·          Each project goal should be specific, measurable, and actionable.

·          Example: The organization wants to achieve a 25 percent reduction in operational costs by the end of the year

Requirements – Identify and list the key business and technical requirements that must be achieved in the project

• Example: The organization must comply with Sarbanes-Oxley (SOX) regulations.

• Example: The underlying infrastructure for any service defined as strategic must support a minimum of four 9s of uptime (99.99 percent).

Assumptions – Identify and list the design assumptions

• Assumptions are design components that are assumed to be valid without proof.

• Example: The datacenter uses shared (core) networking hardware across production and nonproduction infrastructures.

• Example: The organization has sufficient network bandwidth between sites to facilitate replication.

• Example: Security policies dictate server hardware separation between DMZ servers and internal servers.
Constraints – Identify and list the design constraints

Constraints limit the design choices.

Example: Due to a preexisting vendor relationship, host hardware has already been selected. The hardware is …

A constraint could be a business process, a business policy, or a technical limitation. Clearly list the constraints so that they can be reviewed for accuracy and
referred to during the design project.

If a particularly goal, requirement, or constraint cannot be met or creates a risk, discuss the issue with the key stakeholders and SMEs. Discuss it as early as possible in the design project so that the best possible compromise can be reached early in the design process.

Discussing issues and risks early in the design project also reduces the number of surprises in the end design. Surprises in the end design increase the risk of not reaching an agreement to move forward with implementation.

Risks – Identify any risks that might prevent achieving the project goals

Example: The organization's main datacenter contains only a single core router, which is a single point of failure.

Example: The lack of executive sponsorship places at risk the goal of virtualizing 75 percent of the datacenter by the end of 2010

The conceptual design focuses on achieving the organization’s business goals and requirements.

Determine the entities that are affected by the project:

- Lines of business, users, applications, processes, management methods, physical machines, and so on

Determine how the goals, requirements, and constraints map to each entity.

Design the infrastructure that will be necessary to achieve each entity’s goals and requirements, while staying within the constraints.

- For example, where will you need availability, scalability, performance, security, manageability, and so on, while staying within cost and other constraints?

Document the conceptual design with diagrams, tables, and text.

Gathering information about your organization’s situation is part of the design methodology presented in this course. Choosing, and then interviewing, key technical personnel and project stakeholders to determine your organization’s situation is just as important as gathering workloadsizing information. The organization’s situation will affect your design.

Use interviews early in the design process to uncover things that affect the end design, such as project goals, budget constraints, hardware policy choices, and department boundaries. Sometimes, organizational boundaries and politics affect the achievable consolidation ratio. Key stakeholder and SME interviews help to uncover this information.

For example, one organization’s primary goal might be to reduce its datacenter footprint and the associated costs, while another organization’s goal might be to virtualize to meet the business continuity and disaster recovery (BC/DR) initiatives of its business.
The first organization might be seeking to achieve 10:1, 20:1, or higher consolidation ratios. The second organization, on the other hand, might be entirely satisfied with a 5:1 consolidation ratio, so long as the virtual infrastructure meets its disaster recovery requirements.

Organizational and political factors often affect the design, yet they are not strictly technical. Sometimes, resistance to virtualization exists due to the preconceptions and fears of decision makers. A feeling of control often accompanies owning physical hardware. The loss of physical hardware might result in a sense of loss of control. Decision makers might also have concerns about performance issues as well as concerns about the return on investment and total cost of ownership associated with virtualization. Resolving the doubts and fears of the decision makers is necessary to move quickly through the design process.

VCAP Study - Merged PDF Files

I have started preparing for the VCAP again and mainly I was using the online documentation for reference for the available blueprints.

For more details on both certifications, visit here.

I have tried reading the PDF files on my home PC, laptop and tablets (Touchpad and Playbook) using Octopus (BETA) and as a backup Dropbox. The only challenge I had was to look for the correct PDF files for certain subject/feature/configuration. It requires to open multiple PDF file/s one at a time and then do the search for the word/s.

One of my colleagues has given me a hint about merging the PDF files in to one. So I went ahead and merged almost all the PDF files which are necessary to study for VCAP certifications.

I have included the screenshot below for all the files I have merged in to one main PDF file which you can keep at the central location for easy access and to read while you are traveling, waiting or actually reading at midnight after the family falls asleep :-)

To merge the PDF files I have used the site

This site lets you make one PDF file of 32 MB at the max. The one I have created is of 21.1 MB approx. with 2576 pages in total.

This is a good way to have all the information at one central location and just have to skim through whenever I need something to refer. This is just me but people can still have them separate and refer.

Hope you will find the same as useful as me. For now the file can be downloaded from here.

If you have any other suggestion then you can leave the feedback and I will try to work on that.

Good Luck with your study for the VCAPs ;-)