WilliamLam.com

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:

Installing ESXi 5.0 Update 2 on Mac Mini is Now a Breeze! (No Custom ISO/patches Needed!)

by // 15 Comments

VMware has just released ESXi 5.0 Update 2 which includes many bug fixes, but along with these fixes, these updates usually also include new inbox drivers as part of the default ISO image for ESXi. One important driver that I had noticed while going through the release notes is the inclusion of the tg3 (Broadcom) inbox driver:

  • Updates the tg3 driver to version 3.123b.v50.1
    The tg3 inbox driver version shipped with the ESXi 5.0 Update 2 is 3.123b.v50.1.

Disclaimer: The Apple Mac Mini is not officially supported by VMware. 

Why is this awesome!? Well, for those of you who own an Apple Mac Mini and would like to run ESXi, may recall an additional step is required to create a customized ESXi ISO to include an updated tg3 driver for the networking stack to function in an Apple Mac Mini. Though the steps have been documented here, it is great to see this working right out of the box using the new ESXi 5.0 Update 2 ISO from VMware. In addition to the networking stack functioning properly after installation, it also enables connectivity to an Apple Thunderbolt Ethernet adapter if you happen to have one connected to your Apple Mac Mini! You no longer have to create a custom ESXi ISO for the Thunderbolt Ethernet adapter as mentioned in an earlier article here.

Note: This article is only relevant to pre-2012 Apple Mac Mini, if you have a newer Apple Mac Mini 6,2 - Please refer to this article for installation.

Here are a few screenshots of running the latest ESXi 5.0 Update 2 on my Apple Mac Mini 5,3 as well as showing the Apple Thunderbolt Ethernet adapter active in ESXi:

If you want a tiny form factor for a vSphere home lab, you should definitely consider asking Santa for an Apple Mac Mini this Christmas 😉 Hope everyone has a Happy Holiday and Happy New Years! 

Blocking vSphere C# Client Logins

by // 8 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

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

Login to your vCenter Server and locate a file called version.txt

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉