Home > Blogs > Support Insider > Tag Archives: SSO

Tag Archives: SSO

Patching ESXi 5.5 for Heartbleed without installing Update 1

On April 19th, VMware released a series of patches for ESX 5.5 and ESX 5.5 Update 1 to re-mediate the CVE dubbed “Heartbleed” (CVE-2014-0076 and CVE-2014-0160).

VMware also recently announced that there was an issue in the newest version of ESXi 5.5 (Update 1 and later), which can cause difficulties communicating with NFS storage. This NFS issue is still being investigated, and customers are encouraged to subscribe to KB article: Intermittent NFS APDs on ESXi 5.5 U1 (2076392) for updates.

Due to the confluence of these two unrelated issues, you might find yourself trying to patch ESXi to protect yourself from the Heartbleed vulnerability, while at the same time trying to avoid installing ESXi 5.5 Update 1.

Here is the information from the VMware Knowledge Base on the topic:

2

The note at the bottom is the key. Stated simply, if you are…

  • Using NFS storage
  • Concerned about patching to Update 1 due to change control
  • Not already running ESXi 5.5 Update 1 (build-1623387)

… then you should patch your install for the Heartbleed issue and at the same time stay at ESX 5.5 by applying Patch Release ESXi550-201404020, and not ESXi550-201404001.

An Explanation of Patch Release Codes

To better understand the Patching process in a VMware environment, it is valuable to understand the codes which are used in VMware Patch Releases.

When VMware releases a patch, or a series of patches, they are bundled together in what is known as a Patch Release. A Patch Release will have a coded name which is formed using the following structure. I have added braces to demonstrate the different sections better in each example.

[PRODUCT]-[YEAR][MONTH][THREE DIGIT RELEASE NUMBER]

For example, the patch release for ESXi 5.5 that was released in January 2013 would be coded like this (without the explanatory braces):

[ESXi550]-[2013]-[01][001]

As part of a Patch Release, there will be at least one Patch. Each Patch is given a Patch (or Bulletin) ID. Patch IDs are similarly structured to Patch Release codes, but also have a two letter suffix. For Security Bulletins, the prefix will be SG. For Bug Fix Bulletins, the prefix will be BG.

For example, the two Patch IDs which were released to patch Heartbleed are:

[ESXi550]-[2014][04][401]-[SG]
[ESXi550]-[2014][04][420]-[SG]

Note that the only difference in the Patch IDs here is in the three digit release number (401 vs 420).

Patching with VMware Update Manager

There are a number of methods for patching ESXi hosts, and the most commonly used is VMware Update Manager (VUM). VUM will present a pair of Dynamic Baselines which will be automatically updated when patches are available. The danger in this case is that VUM may show you both the Pre-Update 1 patch, as well as the Post-Update 1 patch. If you are not careful as to which patches you apply, you might accidentally end up patching your host to Post-Update 1.

Here are the patches which were released on April 19th, as seen in VUM. The Update 1 patch is highlighted in red, while the Pre-Update 1 patch is marked in green.

1

Note: VMware also released two other ESXi 5.5 patches on April 19th, as part of Patch Release but these are not related to the Heartbleed vulnerability in any fashion. (ESXi550-201404402-BG, and ESXi550-201404403-BG).

Creating a Fixed Baseline

Patching a host using ESXi550-201404420-SG (Pre-Update 1), while avoiding ESXi550-201404401-SG (Post-Update 1) requires the use of a Fixed Baseline in Update Manager.

  1. Start in the Update Manager Admin view.
  2. Select the Baselines and Groups tab.
  3. Click Create… in the Baselines column.
    3
  4. Give the new Baseline a descriptive Name (and optionally a Description).
    4
  5. Click Next.
  6. For Baseline type, select Fixed.
    5
  7. Use the Search feature to find the only Patch we want to apply. You will need to select the Patch ID option from the dropdown menu to ensure the search scans for the appropriate column.
    6
  8. Enter the Patch ID into the search field: ESXi550-201404420-SG and click Enter to search.
  9. Select the Patch which shows up in the filtered list, and click the Down Arrow to move it into the selected Baselines.
    7
  10. Click Next and confirm that the Patch ESXi550-201404420-SG is the only one selected.
    8
  11. Click Finish.

The Baseline is now created and available for use.

Remediating a Host using the Fixed Baseline

Once the Fixed Baseline has been created, we can use it to Scan and Remediate an ESXi host.

  1. Select the host you wish to patch, and place it into Maintenance Mode.
  2. Click the Update Manager tab.
  3. Make sure that there are no Dynamic Baselines attached to the host you wish to patch. Detach any baselines which are currently attached:
    Critical Host Patches (Predefined)
    Non-Critical Host Patches (Predefined)
    Any other Custom Baselines which you have created
  4. Click the Attach link.
    9
  5. Select the newly created Baseline and click Attach.
    10
  6. Click the Scan link and make sure Patches and Extensions is selected. Click Scan again.
    11
  7. When you are ready to patch the host, select Remediate.
  8. Complete the Remediation wizard.

Once the host is patched, it will reboot automatically.

Patching an ESXi host manually via the command line

Another option to patch an ESXi host is to use the esxcli command line tool. The patch files required are the same. For more information on how to proceed with this route, refer to the vSphere 5.5 Documentation under the heading Update a Host with Individual VIBs.

References

Author: Andrew Lytle
As a member of the VMware Mission Critical Support Team, Andrew Lytle is a Senior Support Engineer who is specializes in vCenter and ESXi related support.

Top 20 vCenter Server 5.5 issues

For the next few weeks, we are focusing our efforts on helping our vSphere 5.5 customers find answers to questions as quickly as possible. We tend so see a surge in March of customers installing, upgrading, and configuring their new vSphere 5.5 environments so we present you this list of the top 20 vCenter Server KB articles. Please share if you find this list useful :^)

  1. Re-pointing and re-registering VMware vCenter Server 5.1 / 5.5 and components (2033620)
  2. Upgrading to vCenter Server 5.5 best practices (2053132)
  3. Resetting the VMware vCenter Server 5.x Inventory Service database (2042200)
  4. Installing vCenter Server 5.5 best practices (2052334)
  5. Enhanced vMotion Compatibility (EVC) processor support (1003212)
  6. Configuring VMware vCenter Server to send alarms when virtual machines are running from snapshots (1018029)
  7. Migrating the vCenter Server database from SQL Express to full SQL Server (1028601)
  8. Unlocking and resetting the vCenter Single Sign-On administrator password (2034608)
  9. Methods of upgrading to vCenter Server 5.5 (2053130)
  10. Reducing the size of the vCenter Server database when the rollup scripts take a long time to run (1007453)
  11. Troubleshooting transaction logs on a Microsoft SQL database server (1003980)
  12. Determining where growth is occurring in the VMware vCenter Server database (1028356)
  13. Consolidating snapshots in vSphere 5.x (2003638)
  14. Updating rollup jobs after the error: Performance data is currently not available for this entity (1004382)
  15. Collecting diagnostic information for VMware vCenter Server 4.x/5.x (1011641)
  16. Verifying jobs and stored procedures installed in vCenter Server 5.1 and 5.5 (2033096)
  17. Installing VMware Tools 5.1 on a Windows virtual machine reports Unity warnings in Windows Event logs (2038263)
  18. Update sequence for vSphere 5.5 and its compatible VMware products (2057795)
  19. vCenter Server 5.5 displays a yellow warning in the Summary tab of hosts and reports the error: Quick stats on hostname is not up-to-date (2061008)
  20. Cannot take a quiesced snapshot of Windows 2008 R2 virtual machine (1031298)

ALERT: Active Directory authentication fails when vCenter Single Sign-On 5.5 runs on Windows Server 2012 along with AD

VMware Support AlertVMware has become aware of an issue where machines running vCenter Single Sign-On 5.5 running on Windows Server 2012 authenticating to an Active Directory Domain running on Windows Server 2012 will not be able to authenticate to Active Directory.

 

For further information and updates, please refer to KB article: Active Directory authentication fails when vCenter Single Sign-On 5.5 runs on Windows Server 2012 and the AD Domain Controller is also on Windows Server 2012 (2060901).

ALERT: vSphere 5.5 Single Sign-On upgrade rolls back after importing Lookup Service data

VMware Support AlertVMware has become aware of an issue where an upgrade to vSphere 5.5 may fail when upgrading the SSO component. The issue appears to be related to the default SSO certificate generated when installing vSphere 5.1 Build #799735

For details and updates on this issue refer to KB article: vSphere 5.5 Single Sign-On upgrade rolls back after importing Lookup Service data (2060511)

Related info:

Location of Single Sign On log files for vCenter Server 5.1 (2033430)

SSL Certificate Automation Tool version 1.0.1

Last month we announced a new SSL Certificate Automation tool to help everyone with the implementation of custom certificates. Yesterday, we released the second version of it (version 1.0.1). This is a minor update which aims to simplify the replacement of certificates further by adding Certificate Signing Request (CSR) functionality to the tool. This functionality allows a user to quickly generate certificate requests (and consequently the private keys) for submission to the Certificate Authority.  The CSR functionality was the largest portion of manual steps, and as a result the update reduces the number of steps by over 15.

In addition, there are several minor bug fixes which were fixed which impacted tool functionality.

For further details and to download the latest version of the SSL tool see: Deploying and Using the SSL Certificate Automation Tool (2041600)

We hope these additions provide useful for everyone!

Logging in to the vSphere Web Client failing

Some customers are still running into issues when logging into the vSphere Client and we want to re-publicize the fix for this. If you see either of the following two messages:

unknown user or bad password

or:

The authentication server returned an unexpected error: ns0:RequestFailed: 
Internal Error while creating SAML 2.0 Token. 
The error may be caused by a malfunctioning identity source.

This is caused by a configuration issue related to the groups on the local Operating System having Active Directory users in them.  There is an easy fix to the issue, removing the localOS identity source from vCenter Server Single-Sign-On(SSO). All of the steps are detailed in KB article: Logging in to the vSphere Web Client fails with the error: ns0:RequestFailed: Internal Error while creating SAML 2.0 Token (2043070) but you can think of this as an addendum.

Before you go ahead and remove the local identity source, one should be aware that any local users will no longer have login access once the local identity source is removed.  Also, a domain account should be configured with SSO administrative privileges before removing the identity source.

To remove the identity source, log in to the Web Client using the SSO administrator,(admin@system-domain, go to Administration, then Configuration under Sign-On and Discovery and then remove the Local Identity Source (local machine name) as shown.

A couple of common questions:

Q – What if I can’t log in with SSO Administrator credentials?
A – See Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608)

Q – How do I add an SSO administrator?
A – Log in to the vSphere Web Client as an SSO administrator. By default, this user is admin@system-domain.

In the home page, click Administration > Access > SSO Users and Groups.

Click on the plus sign and add account from identity source.

Introducing the vCenter Certificate Automation Tool 1.0

Fresh out of development today VMware has a new tool to help everyone with the implementation of custom certificates. The vCenter Certificate Automation Tool 1.0, will help customers update certificates needed for running vCenter Server and supporting components. This is primarily of interest to customers who use custom certificates either generated internally from Corporate CAs, or from public CA’s like VeriSign.

To add a little background information various components within vSphere and the vCenter platform use certificates for identifying themselves as well as for secure communication with external software entities (browsers, API clients).  These can broadly be classified into the following categories:

  1. Secure token Service Certificate – Certificate used by vCenter Single Sign On (SSO) for encryption tokens
  2. Solution User Certificates – Certificates used by each solution to identify themselves as users to SSO
  3. SSL Certificates  – certificates needed for SSL communication for the UI and API layer
  4. Host Certificates – These certificates are deployed in each ESXi host and used for secure vCenter to ESXi communication.

Note: The new certificate tool automates the updating of certificates in the management layer only (a, b, c above). This tool does NOT handle replacement of certificates in ESXi hosts.

The vCenter Certificate Automation Tool aims to automate the process of uploading certificates and restarting the following components within the vCenter Platform:

  1. vCenter Server
  2. vCenter Single Sign On
  3. vCenter Inventory Service
  4. vSphere Web Client
  5. vCenter Log Browser
  6. VMware Update Manager (VUM)
  7. vCenter Orchestrator (VCO)

For more information on how to download, install, and use the tool, refer to KB article: Deploying and Using the SSL Certificate Automation Tool (2041600).

How to deploy SSO in a multisite configuration

For those of you administering multiple vSphere environments, getting a SSO multisite deployment up and running in a correct configuration is very important. Multisite deployments are where a local replica is maintained at remote sites of the primary vCenter Single Sign-On instance. The process of setting this up is not complicated, but it is possible to take a wrong turn and end up wasting a whole lot of time correcting it. That is why we have created a best-practice Knowledgebase article titled: Multisite Single Sign-On deployment best practices. (2042849). We highly recommend you look at the examples in that article.

We’ve written extensively in this blog about SSO in the past. You can see all the other posts on the topic here: http://blogs.vmware.com/kb/tag/sso

If you are still at the point where you are asking yourself- what is SSO? and why do I care? we recommend you start with this great introduction from Justin King: vCenter Single Sign-On Part 1: what is vCenter Single Sign-On?

Where is the Best Practice Guide for SSO?

We recently received a tweet request from a customer directed at our @vmwarekb account asking:

@VMwareKB Also when can I expect a best practice guide from VMware on SSO?

The answer is, while we don’t have one single document with our best practices for Single Sign On (SSO), we do have 65 and counting KB articles on the subject. That amount of content would not fit nicely if it were crammed into one article! Thinking that more of you may be asking the same question, I present for you a listing of all of our current SSO articles. In the meantime, we’ll keep working hard on providing the content you want.

Configuring a vCenter Single Sign On Identity Source using LDAP with SSL

So, the Fusion related videos that were mentioned in our earlier post have been delayed. Thus we must apologize to all of our fans who were waiting for these videos to appear. We will try to upload these videos as early as possible in the new year.

In the meantime, we do have a new video today for all of our fans interested in vSphere 5.1 related content.

In this video tutorial we provide a quick demonstration showing the steps to configure an Identity Source in vCenter Single Sign On to use a secured LDAP over SSL (LDAPS) connection as per the written instructions contained within VMware Knowledge Base article Configuring a vCenter Single Sign On Identity Source using LDAP with SSL (2041378).

This is appropriate in secure environments to encrypt all LDAP traffic on between vCenter Server and the authorizing Identity Source.

Note: This video tutorial is a general how-to guide. Consult with the Directory Administrators in your organization for specific procedures. The steps in this video assume that the Domain Controller in question has a valid certificate available for Exporting for Server Authentication. If it is not available in the Personal > Certificates tab, you need to start by making that certificate available.

Note: For best viewing results, ensure that the 720p setting is selected and view in full screen mode.