vSphere 4.1 Hardening Guide

vSphere 4.1 Hardening Guide

This document is the official release of the vSphere 4.1 Security Hardening Guide.  This version is based on feedback collected during the public draft comment period.  We will still be collecting feedback on this document -- if there are any typos, errors, or changes, please add them to the comments below.

PLEASE NOTE: the latest version of this guide may be found here: http://www.vmware.com/resources/techresources/10198 .


Hi, you need to change code for "Set a timeout for Tech Support Mode" policy. HCN06 is used twice. Draft version has HCN07 code for this policy

Thanks for pointing this out.  I made this correction and uploaded a new version of the PDF.

I have a few general comments reference the hardening guide.

Nice to have items:

  • Consider tracing the controls to NIST 800-53 for each setting line by line. I will happily do it, but those skills come at a cost.

  • Impacts on the system - security is great, but it is also critical to understand the impacts of implementing a control. Document the potential impacts of implementing higher security levels and qualify the risks of not doing so as well.

       EXAMPLE: A nice feature in vCenter could be allowing users to be

                         shadowed by having  a "PROMPT" popup.

  • Needed in vCenter - add policy to the deployment of VMware tools. Best practice installations need to be the DEFAULT, not the exception (remember Microsofts growing pains?). PAY BETTER ATTENTION guys, you didn't learn from their past experiences.

  • Add a certificate based installation section the install guide. PKI should be a part of Deployment Best Practices, and NOT the exception. Also, for the price I expect to see smart card integration and a few other features... Ideas are worth money, so if you want more feel free to contact me.

Parting Advice - secure by default, not by exception should always be the standard. Get off the old MSDE SQL 2005 installs, you place systems at risk and cause extra work.

MSDE SQL 2005 is a classic FAIL on your behalf. Deploying old unpatched database instances by default is shameful. C'mon guys, you follow security best practices, right?

Otherwise, kudos on the 4.1.x product, I like it better then what Microsoft has to offer. Smiley Wink

I didn't see any password policy modifications for ESXi.  Granted, most admins will configure the ESXi Servers for Active Directory Authentication, followed by Lockdown Mode.   I was still surprised to see that there were no modifications to the local password policies in /etc/pamd.d/system-auth.   In our environment, we add one additional local account for DCUI access.  We used to modify the /etc/pam.d/common-password file in ESXi 4.0, but now I guess we will modify /etc/pam.d/system-auth in ESXi 4.1.

*edit* sorry for replying to Robert321, I just noticed the add comment link on the upper left.


How important is it to turn off vix? code VMX30.

Several products will fail if vix is turned off such as vcb and vum.

Can you confirm that VUM and VCB fail when VMX30 is implemented?  I was told by the developers that this would not happen.

I have the impression that there are support hooks for AD in 4.1--are there support hooks within the hypervisor for other applications as well?  Oracle, SAP, SharePoint 2010, Lync 2010 perhaps.  Thanks so much.

For HTM20 is there any file or powercli cmdlet that will let me check the password aging policy for ESXi (not ESX) hosts? I did not find a login.defs file in the ESXi hosts /etc dir.

I just got done working with VMware support.  In ESXi4.1u1, changes to the /etc/pam.d/system-auth file will not persist after two reboots, even if you chmod +t the file.  This is a known problem that may get fixed in 4.1u2.    I have requested that VMware update the hardening guide and produce a KB article.


Can your provide clarification regarding VSH07?

Namely:  which log file to monitor and what the message should look like.

To monitor (or have a tool monitor for me) I need to know where to go and what to look for.  Can anyone provide any help here?  


VSC07 (Disable managed object browser) has a typo:

The forward slash at the end is in the wrong place - it should be here:
If it is at the end vCenter will not start - it will log a mismatched tag error.

I think that's better to use vim-cmd command to disable MOB: vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect" instead of manual cfg file editing. What do you think?

That's what I did for the individual hosts, however the line above was for vCenter.

oh, sorry. you're right. I didn't draw attention to the code and your last note.


Is it anywhere in future VMware dev roadmaps to make an ESXi deployment secure by default versus after action hardening?


1. Boot ESXi during installation it asks what baseline you follow.

2. User selects baseline from options such as DISA STIG, PCI, or whatever supported hardening configuration VMware fully supports - eliminates all those silly supported versus non-supported questions.

3. User responds DISA STIG or whatever selected baseline they choose

4. ESXi initial deployment is security by default IAW best practices - NO MORE BOLT-ONS Smiley Happy

5. Remainder of VMware vSphere, DB, VUM, and ESXi Auto Deploys follows DISA template by default and sample scripts are provided whenever necessary.

6. New built in health check tool self-audits vSphere architecture for STIG compliance and auto reports on itself for non-compliance.

Makes for a Happy User Community Smiley Happy

Apply same workflow concept to VM's to include policy based deployment of VMware tools and OS hardening.

Btw, I beta test for Microsoft but they don't listen too well. Let's see how well VMware listens to some really good advice of what user's want out for out of the box experiences. Certainly willing to beta test for VMware if you can point me in the right direction.

Hardening issues today:

"Something too often added after the fact because few understand it"

"Panic'd work frequently performed after an audit, and then turned off because they didn't understand what they broket"

"The guides vendors always develop after the fact because they were so busy cramming in one more insecure feature or widget"

Just a follow-up report to note that the /etc/pam.d/system-auth issue is still present in 4.1u2, I tested it today.

Hi all.

Can somebody comment VMX30 setting. It recommends to set "guest.command.enabled=FALSE". I was confused a little with "enableD". Is it correct or typo?

Most of parameters use ".disable" without "d". So question is "guest.command.enabled=FALSE" correct? Moreover "Security Hardening" has next note: "You can also use any vSphere API-based tool such as PowerCLI to view and modify VMX parameters. In many instances, a VMX parameter has two versions:

XXX.disable and XXX.enable. In nearly all cases, it is better to use the form
XXX.disable=TRUE to disable a feature..."

So what do you think?

At the following link it has guest.commands.enabled -


I have previously used guest.command.enabled and the VM did manage to power on.

Yes, thanks. I checked with Guest Console. Yes, parameter "guest.command.enabled=FALSE" and only it alone works. Confused...

Well, last note is wrong. You need to use guest.commands.enabled=FALSE" to disable VIX in real life. NOTE char S at the end of "commandS".

Doc contains wrong parameter name. KB describes correct one.

The current version 3 of this document is missing an update for recommendation HCM05 (Disabling the Welcome Page) in the field "Effect on Functionality" contains "The welcome web page will no longer be accessible." That effect is not complete. The correct text is: "The welcome web page will no longer be accessible. If the ESX/ESXi 4.1 host is managed by vCenter Server 5.x then VMware HA and log file collection will not work for this host. For details see KB 1016039 (http://kb.vmware.com/kb/1016039)".

This recommendation will be dropped from the upcoming hardening guide for vSphere 5.


make sure you are using the latest version of this document available at:


Also take a look on the following KB

Update to vSphere 4.1 Security Hardening Guide

Version history
Revision #:
1 of 1
Last update:
‎04-05-2011 09:25 PM
Updated by: