As you may know, with the release of vSphere 4.1, core vSphere components such as vCenter and ESX(i) all received significant feature updates. This was no exception with VMware vMA, though the number of updates were minimal but still signifcant.
Here is the list of new features:
- Support for Windows Active Directory Integration using Likewise Open
- Offline bundle support for upgrading vMA
- Resolved major security flaw with vi-fastpass component
1. Support for Windows Active Directory Integration using Likewise Open
For those that use Active Directory, you now have the capability of centralizing your user management on vMA. Using Likewise's Open software, users can now login to vMA using their AD credentials. Not only can they login, but with the enhancement of the new vi-fastpass, you can now add a target and configure it to support AD authentication versus normal fastpass authentication. This means that the user who logs into vCenter can log into vMA to perform an operation such as adding a vSwitch or powering on a Virtual Machine without providing further credentials using this new AD authentication passthrough. For more details, take a look at this article vMA 4.1 Authentication Policy - fpauth vs adauth.
2. Offline bundle support for upgrading vMA
Prior to vMA 4.1, to upgrade the software within vMA, you had to use vima-update (now renamed to vma-update) which connects to VMware's online repository. This was an issue for envrionments that did not have direct internet or proxy access to VMware's website and there were no supported work arounds for this. You now can download an offline bundle just like you can for ESX or ESXi and perform an offline upgrade.
3. Resolved major security flaw with vi-fastpass component
Saving the best for last. This has been a security issue that has existed since the release of VIMA 1.0 which was not considered an offiical release by VMware until vMA 4.0. The issue was with the use of vifpinit (now renamed to vifptarget) and when a target was initialized using the vi-fastpass library, the username and password was viewable in plain text.
When you add a target to vMA's management using vi-fastpass, two accounts are created on the target host: vi-adminXX and vi-userXX. The password for these two accounts are obfuscated using a simple XOR cipher which can be cracked in days if not hours and the obfuscated form is stored in a credential store located in /home/vi-admin/.vmware/credstore. Prior to vMA 4.1, when you initialize a target from this credential store, you are allowed to execute any vCLI or vSphere SDK for Perl script without having to provide additional credentials to the host. The authentication is basically bypassed as it uses the vi-adminXX credentials to login and perform the operation. The side effect of initializing the fastpass target, was that the password to the vi-adminXX was exposed as plain text via an environmental variable.
Here is an example of of initializing a target on vMA 4.0 with the password exposed:
As you can see from above, both the username and password is exposed as a simple environmental variable entry. You can now take those credentials and login to an ESX(i) host and perform an administrative operation as if you were root.
Here is an example of using these credentials to create a new vSwitch on an ESX host:
Before you jump and upgrade vMA 4.1, note that the security issue has been resolved but it does NOT make the system any more secure than it was in vMA 4.0. The vi-fastpass is actually available as a library module that supports both Perl and Java. There is available sample code under /opt/vmware/vima/samples/ for vMA4.0 and /opt/vmware/vma/samples/ for vMA 4.1. Using this library, you can access the targets under vMA management which also includes both the username and password in its unencrypted form.
Here is a vMA 4.0 script I wrote called enumeratevifp40.pl that demonstrates the above:
Here is a vMA 4.1 script I wrote called enumeratevifp41.pl that demonstrates the above:
As you can see, even with the security issue fixed vMA 4.1, a user can still access the entire credential store and obtain both the username and password to any of the targets. The only real way to protect against this issue is to use adauth when adding your targets and forcing users to authenticate against your AD server when connecting and performing an operation on vCenter or an ESX(i) host. For those that must use standard fpauth, VMware has released a KB1017669 article for vMA 4.1 on securing the credential store by creating an encrypted volume in which the obfuscated file is stored in. This ensures that if you are transferring your vMA image, someone can not just mount the VMDK and extract the credential store file and try to decrypt the contents.
Now, that you understand the security implication and features available with vMA 4.1, off you go to upgrade 🙂
Here are additional links that may also be useful:
