WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

Potential ESX(i) 4.1 Update 1 upgrade caveat

03.01.2011 by William Lam // Leave a Comment

If you are planing on upgrading to the recent release of ESX(i) 4.1 Update 1 from ESX(i) 4.1, you may want to verify that you will not be impacted by a previous security/password bug found in ESX(i)4.1. The security bug that was identified with ESX(i) 4.1 was the encryption algorithm which changed from default MD5 as previous releases of ESX(i) to legacy DES.

This bug has since been resolved and a VMware KB article (KB1024500) was released with a temporary fix by adding the keyword "md5" to system-auth PAM configuration entry. This fix also required the user to update the root password afterwards, as the previous password was encrypted using DES.

The potential caveat is if you did not apply the fix as mentioned from the above VMware KB article prior to upgrade, after the ESX(i) 4.1 Update 1 upgrade, you will continue to run into the same problem. The fix is to reset your root password after the upgrade of ESX(i) 4.1 Update 1, this will ensure that the new password will be encrypted using the MD5 algorithm. Though the fix is simple, it can be tedious and manual for users who do not regularly rotate their root passwords or have an automated password management system.

To check whether this will impact your upgrade, login to ESXi Tech Support Mode or classic ESX Service Console and check whether the root password was encrypted using MD5 or DES. To do so, you will cat out the contents of /etc/shadow

If the root password was encrypted using MD5 algorithm, you should see root hash start with "$1$"

If the root password was encrypted using DES algorithm, the root hash will not start with "$1$"

If it is the latter, you will need to either apply the fix and update the root password before upgrading or reset the password after your upgrade. To change the root password, you need to login to either the Serivce Console for ESX or Tech Support Mode for ESXi and run the passwd utility to change your password.

It is probably quicker to rebuild than to login to each host an update the root password, especially if you have an automated kickstart environment. This will ensure that that all hosts will be consistent and no manual fixes will be required. IMHO, this is something that VMware should have clearly pointed out in their release notes as not everyone may be aware of the VMware KB article and implemented the fix prior to upgrade.

Categories // Uncategorized Tags // esxi4.1, security, vSphere 4.1

Updated vSphere Security Hardening Report Script for vSphere 4.1

01.22.2011 by William Lam // 5 Comments

VMware released earlier this week the first draft copy of the vSphere 4.1 Security Hardening Guide which provides several changes to the vSphere 4.0 version released last year. Unfortunately there was no change list provided and you have to manually go through both documents to get the differences. Luckily I did the heavy lifting for you and here are the changes in 4.1 version:

Edit: It looks like Charu of VMware has already posted a "diff" of the 4.0 and 4.1 version here.

Added Checks (14):

  • VSH07 (Enterprise) - Check for privilege re-assignment after vCenter Server restarts
  • VSH10 (Enterprise) - Clean up log files after failed installations of vCenter Server
  • VUM06 (Enterprise) - Do not use default self-signed certificates
  • VMX23 (Enterprise) - Use secure protocols for virtual serial port access
  • VMX24 (DMZ) - Disable certain unexposed features
  • VMX56 (Enteprise) - Restrict access to VMsafe network APIs
  • HIN02 (Enterprise) - Keep ESX/ESXi system properly patched
  • HCM05 (DMZ) - Disable Welcome web page
  • HMT12 (Enterprise) - Prevent unintended use of VMsafe network APIs
  • HMT15 (Enterprise) - Audit for loading of unauthorized kernel modules (ESXi only)
  • HMT20 (DMZ) - Ensure that vpxuser auto-password change meets policy
  • HMT21 (DMZ) - Ensure that vpxuser password meets length policy
  • HCN05 (SSLF) - Disable DCUI to prevent all local administrative control
  • HCN06 (Enterprise) - Disable Tech Support Mode unless needed for diagnostics and break-fix

Removed Checks (10):

  • VMX03 (Enterprise) - Disable copy/paste to remote console
  • VMX51 (Enterprise) - Restrict access to VMsafe CPU/memory APIs
  • VMX54 (Enterprise) - Restrict access to VMsafe network APIs
  • HCM04 (Enterprise) - Ensure that ESX is configured to encrypt all sessions
  • HMT10 (Enterprise) - Prevent unintended use of VMsafe CPU/memory APIs
  • HMT11 (Enterprise) - Prevent unintended use of VMsafe network APIs
  • HCN01 (Enterprise) - Ensure that only authorized users have access to the DCUI
  • HCN03 (Enterprise) - Avoid adding the root user to local groups
  • HCN04 (SSLF) - Disable tech support mode
  • COP06 (DMZ) - Ensure that vpxuser auto-password change in vCenter meets policy

Note: Some of the removed checks may have been replaced with newer and updated information and shows up in the added checks.

To help with your vSphere validation, here is the latest version of the vSphere Security Hardening Report script 1.5 script. There have been a few enhancements to the script which only validates a check based on whether it it is applicable to classic ESX or ESXi, which in the past it would display "N/A". There is also some further validation of the service endpoints for /, /ui, and /mob that may also help reduce manual verification where applicable. You can also join the new vSphere Security Hardening Report VMTN Group for new updates, bug report and discussions.

Here is an updated sample report based on vSphere 4.1:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

One other thing I noticed while going through both the 4.0 and 4.1 security guide is the numbers for the code are all over the place, there are sometimes huge gaps that are unexplained (e.g. VSH6, VSH7 ... VSH10)

Categories // Uncategorized Tags // hardening guide, security, vSphere 4.1

How to configure and use vMA's vi-fastpass with fpauth and adauth on vSphere 4.1

11.07.2010 by William Lam // 7 Comments

From time to time, I see users posting on the VMTN forums with some questions and confusion around the proper implementation and functionality of vMA's vi-fastpass. The confusion is further enhanced with the new Active Directory functionality and integration with vMA's new vi-fastpass type called adauth.

The vi-fastpass component found in vMA is a credentials caching mechanism to allow you to connect to your ESX(i) or vCenter servers. Prior to vMA 4.1, vMA 4.0 only supported one type of vi-fastpass which is just called fpauth (fastpass authentication). This fpauth basically allows you to manage an ESX(i) or vCenter server under vMA by creating a vi-adminXX and vi-userXX account. The password for these two accounts are obfuscated using a simple XOR cipher. A user can now initialize one of these managed targets and execute either vCLI or vSphere SDK for Perl scripts without having to specify credentials each and every time, this works because the vi-adminXX credentials are being used to connect to your target. This can make running a simple command across n-number of hosts simple without having to provide the credentials for every host.

In vMA 4.1, a new vi-fastpass type has been introduced called adauth, in which you can leverage your Windows Active Directory credentials to authenticate against a managed target without having to store an insecure cipher in vMA. The concept works exactly the same as fpauth, but there are some additional pre-requisites that must be met before you take advantage of adauth. You need to ensure that your ESX(i) or vCenter server is joined to your Active Directory and that your vMA host is also joined to that same Active Directory domain. Once this is all configured, you will now be able to login to vMA using your AD credentials and execute a vCLI command or vSphere SDK for Perl script against an ESX(i) or vCenter host and your AD credentials will be used to authenticate against your target without using any stored cached credentials. This helps to centralize your user management and is much more secure than using the standard fpauth where the credentials are stored in a simple XOR cipher which can easily be decrypted.

The following will describe instructions on setting up and verifying both standard fpauth and adauth using vMA 4.1 and vSphere 4.1 (ESXi and vCenter server). Before continuing, it is highly recommended that you take a look at both the vSphere 4.1 and vMA 4.1 documentation with regards to Active Directory integration.

Configuring vMA vi-fastpass using fpauth (fastpass authentication):

1. Login to vMA using vi-admin credentials, note that your user context is with the vi-admin account.

2. Use the vifp addserver command to add an ESX or ESXi host, you will be using the root account to do so and provide the credentials to that account. If you do not receive any errors, you have successfully added the target.

3. Using vifp addserver again, we now add a vCenter server and we will be using a local account found on the host. In this example, we will be using the administrator account and provide the credentials to that account.

Note: You do not need to add both your ESX(i) and vCenter server to utilize vi-fastpass, this is just an example of adding both types of supported targets.

4. Next, we use vifp listservers to display the managed targets and the type of vi-fastpass we are using denoted by fpauth or adauth.

5. Earlier we mentioned that when using fpauth, the stored credentials are encrypted using a simple XOR cipher. You can view these entries by taking a look at /home/vi-admin/.vmware/credstore/vmacredentials.xml.

6. To use a target, you need to first initialize the target by using the vifptarget -s command. This will change your command prompt in which it will display the current target that has been initialized.

7. As you can see from the screenshot, we now have initialized the host esxi4-1.primp-industries.com and now we can run a vCLI command without having to specify the credentials to the host. In this example, we will just list the number of vmnics using esxcfg-nics -l command.

8. We can also perform the same operation against the ESXi host by going through vCenter. To do so, you will need to initialize your target to your vCenter server and specify the --vihost parameter to the name of a managed ESX or ESXi host under vCenter.

As you can see, you perform this vi-fastpass using fpauth against an ESX(i) or vCenter server. When you initialize a target, the command prompt tells you which host context you are currently in. If you decide you want to switch context, you can issue the vifptarget -c command which clears the target.

Configuring vMA vi-fastpass using adauth (Active Directory authentication):

1. Login to your ESX or ESXi host using the vSphere Client, you will need to first join your ESX(i) host to your AD domain. Click on Configuration tab and on the lower left hand side, click on Authentication Services and click on Properties. You will need to select Active Directory as the type and specify the Domain and click Join Domain. You will now be prompted to provide credentials that have the permissions to add a new host to the domain.

2. If you joined the host to your AD domain successfully, you should see the following displaying the domain.

3. When you join an ESX or ESXi host to AD, it actually does a group lookup for "ESX Admins", if it exists, it will assign the Administrator role to it. If it does not exist, it will periodically query your AD until one is created. In my lab environment, it was not created automatically and I had to manually create this group. For more details, take a look at this blog post by Maish - http://technodrone.blogspot.com/2010/07/esxi-41-active-directory-integration.html

4. Next, you will need to either add the individual users or group that will utilize the vi-fastpass with adauth. You need to do this for each and every ESX or ESXi host under the Permissions tab. If you have more than one user, I would suggest creating and Active Directory group and adding all the users into that group so you add only the group. You will right click and Add Permission and specify your AD domain and select either the individual users or groups and make sure you select Administrator role. Once you have added the appropriate users, you should see the following.

 

Note: At this point you should be able to login to your ESX(i) host using AD credentials using the vSphere Client and remember to use DOMAIN\username. If you are unable to login using your AD credentials, you will not be able to proceed with the next step as this is required for vi-fastpass adauth to function.

5. You will login to your vMA host using the vi-admin account. You will now join your vMA host to your Active Directory domain using the domainjoin-cli join command. You will need to use sudo and specify the name of your domain and the username which as the permissions to join a host to your AD domain.

6. To confirm you have successfully joined vMA to your AD domain, you can run the domainjoin-cli query command to list the domain. You can also verify the new computer name in your AD server.

7. Now we add an ESXi host to vi-fastpass but instead of using fpauth, we will leverage adauth. You will need to use the vifp addserver command and specify --authpolicy adauth parameter. You will need to specify an AD account that will be utilizing the vi-fastpass, make sure you specify the DOMAIN_NAME\username. If you decide to use the --username parameter, make sure you escape the forward slash with another slash (e.g. --username PRIMP-IND\\primp). You would repeat this if you plan on adding a vCenter Server that is joined to the same domain.

8. We can also verify that the vi-fastpass targets have been added using adauth by using the vifp listservers -l command which displays the managed targets and the type of vi-fastpass they have been added with.

9. Since we are using adauth, we can confirm that no cached entries should be stored locally within the vMA host by looking at /home/vi-admin/.vmware/credstore/vmacredentials.xml which should be blank now.

10. Now, we are ready to login to vMA using our AD credentials. Depending if you implemented this vMA AD Intergration Tip, you may not need to specify the full domain when logging in. If you did not, you would to need to specify the full DOMAIN\[email protected] when logging in.

11. You will now use the vifptarget -s command to initialize an ESX(i) server just like in our fpauth use case and you now should be able to run esxcfg-nics -l without having to provide any additional credentials.

12. We can also use the vifptarget -s command to initialize a vCenter server just like in our fpauth use case and specifying --vihost parameter to either your ESX(i) host and now should be able to run esxcfg-nics -l without having to provide any additional credentials.

Hopefully by outlining the entire process for both vi-fastpass fpauth and adauth, implementing this functionality will be a breeze now.

Additional Caveats: There have been some users who have not been able to get full vi-fastpass with adauth working with ESXi host. There have been a few threads on the VMTN forums including this one which refers to a potential VMware bug. I have not been able to reproduce the issue noted by the user, but I have seen several cases in which the above workflow is not the behavior that users have seen. If you run into any issues, I would recommend before trying again to unjoin both your ESX(i) host and vMA from your AD domain. You will also want to make sure you go into your AD server and delete these entries before trying again.

Categories // Uncategorized Tags // active directory, vi-fastpass, vifp, vma, vSphere 4.1

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 14
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • Blocking vSphere HTML5 VM Console and allowing only Standalone VM Remote Console (VMRC)? 02/08/2023
  • Quick Tip - Inventory core count for vSphere+, vSAN+ & VCF+ Cloud Service 02/07/2023
  • How to automate adding a license into vCenter Server with custom label?  02/06/2023
  • Automated ESXi Installation with a USB Network Adapter using Kickstart 02/01/2023
  • How to bootstrap ESXi compute only node and connect to vSAN HCI Mesh? 01/31/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023