WilliamLam.com

Automate vCenter Orchestrator Configuration Backups

by // Leave a Comment

Last year I wrote an article on how to quickly configure a new vCenter Orchestrator 5.1 appliance which automatically goes through the necessary steps of configuring your vCO appliance and enabling the vCenter Server plugin and associating it with your vCenter Server. These steps are usually performed manually, but when you are looking at deploying multiple vCO instances or even quickly spinning up vCO appliance for testing, this will definitely help speed up your deployment.
Something that I did not consider after completing the vCO setup was backups. Fortunately, this was something that was shared with me recently from a customer who had this exact workflow on backing up their vCO configuration after their initial deployment. This may not be a very well known feature, but vCO provides a very simple mechanism to export your vCO configurations and allows you to restore the configuration in case of a miss-configuration or even deploying a similar configuration to another vCO instance.
Using the same HTTP request trick, to export the vCO configuration you would need to make a request to the following URL:

https://${VCO_IP_ADDRESS}:8283/config_general/ExportConfig_export.action

Similar to the vCO UI, the backup will be stored on the vCO appliance itself and the path will be provided back to you in the message response. To help demonstrate this, I created a simple shell script called backupVCO51.sh which is similar to the setup script in my previous blog article. You can easily take the few lines of code and integrate that with the setup script.

Here is a screenshot of running the backup script:

From the output we can see where the backup configuration is stored on the vCO appliance and you can easily copy the backup to an external system using SCP.

Whether or not you are automating your vCO setup, you should definitely consider performing periodic backups of your vCO configuration, especially before making any changes to your vCO Server.

vSphere Security Hardening Report Script Updated for vSphere 5.1

by // 10 Comments

A public draft of the vSphere Security Hardening Guide for vSphere 5.1 was released a few weeks back by my colleague Mike Foley. Since then I have been asked by several people if I had a chance to update my vSphere Security Hardening Report Script. The answer was unfortunately no due to other projects I had been working on and this script as well as others are maintained outside of my normal day job. I finally found some time this past weekend to go through the 5.1 revision of the hardening guide and make the necessary updates to my script which includes a few additional checks.

The script continues to provide backwards compatibility to previous releases of the vSphere Security Hardening Guide for vSphere 5.0, 4.1 and 4.0. Maintaining this compatibility is actually quite a challenge due to small minor changes in the hardening guide from previous versions, but I am please to say the latest 5.1 draft has now been implemented.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

Here is a sample output for the Security Hardening Report for a subset of my vSphere 5.1 home lab environment using "profile1" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

For more details about the security hardening script, please refer to the documentation here.

If you have any feedback/questions on the vSphere Security Hardening Guide itself, make sure you to leave your comments and questions here. If you have any feedback/questions regarding the script, please join the vSphere Security Hardening Report VMTN Group for further discussions.

How To Compile Google Authenticator for ESXi

by // 2 Comments

In my previous article I demonstrated how to use Google Authenticator to provide two-factor authentication for ESXi using the custom VIB that I had built. In this article, I will show you how to compile Google Authenticator to run on ESXi as well as an additional customizations that can be made to the source code to support multiple users.

Disclaimer: This is not officially supported by VMware, use at your own risk

Prerequisite:

  • Download and install 32-bit Linux distribution. In my lab, I used latest CentOS 6.2
  • Install pam-devel package (CentOS) or libpam0g-dev package (Ubuntu). You can reference this blog here for more details on installation
  • Ensure you have both gcc and make installed

Step 1 - Download Google Authenticator source code by running the following command:

wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2

Step 2 - Extract the source code by running the following command and change into the libpam-google-authenticator-1.0 directory:

tar -jxf libpam-google-authenticator-1.0-source.tar.bz2
cd libpam-google-authenticator-1.0

Step 3 - Edit pam_google_authenticator.c and towards the top of the file comment out the following three lines which should look like this:

//#include <sys/fsuid.h>
//#define HAS_SETFSUID
//#endif

Step 4 - By default the SECRET file is stored in /.google-authenticator and we can change the path by modifying both google-authenticator.c and pam_google_authenticator.c by editing the SECRET macro file which should look like the following:

#define SECRET      "/etc/vmware/.google_authenticator"

Google Authenticator supports multiple users by default and you can also provide this support in ESXi by leveraging the $USER OS environmental variable within the SECRET file location. This would allow each user to generate and store their own SECRET file. To do so, set the path to /etc/vmware/$USER/.google-authenticator and the username will automatically be populated when configuring Google Authenticator for each user.

Note: If you are going to create a custom VIB and would like to support multiple users, you will need to know the usernames in advance so you can create the dummy .google-authenticator file for each user. This is required so the files will automatically persist after setting up Google Authenticator.

Step 5 - Save the changes and then type "make" which will then compile the source code and produce google-authenticator binary and PAM module pam_google_authenticator.so in the same directory.

Step 6 - If you decided to create your own custom VIB, ensure you include an empty secret file so when you go and configure it, the changes will be saved. If you do not wish to lower the acceptance level of your ESXi host for the custom VIB, an alternative trick is to store the google-authenticator binary and PAM module in a local datastore as well as the secret file and copy them over using either /etc/rc.local.d/local.sh for ESXi 5.1 or /etc/rc.local for ESXi 5.0. Here is a sample of what that should look like: