vSphere Web Client

vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations

06.03.2015 by William Lam // 4 Comments

A common request that I have heard from customers is to have the ability to automate vCenter Single Sign-On configurations from a programmatic standpoint. Unfortunately, this is currently not possible today as a public API does not exist for SSO. Having spent some time exploring the underlying vmdir database which is just an LDAP-based system (here & here) and learning about a way to update a particular key per KB2070433 within the vmdir database which I have shown here and I have found here, I wanted to see if it was possible to query for these specific SSO Admin configurations and also be able to update these properties.

Disclaimer: Please take extreme caution when connecting to the vmdird database. You should take extreme care in making changes while in the database else you can negatively impact your environment.

There are three main sections to the SSO Admin configurations that can be seen from the vSphere Web Client:

Password Policies
Lockout Policy
Token Policy

For each section, I have provided the specific ldapsearch query (please refer to this article as per-requisite) which can either be run directly on the VCSA if you are using that or a system that includes the ldapsearch command. You will need to replace the text highlighted in blue with your own environment details.

Password Policies & Lockout Policy

To view the following set of configurations, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=password and lockout policy,dc=vghetto,dc=local"

Here is a screenshot of the Password Policies as seen in the vSphere Web Client and their corresponding LDAP property names:

UI Setting	LDAP Attribute Name
Maximum lifetime	vmwPasswordLifetimeDays
Restrict reuse	vmwPasswordProhibitedPreviousCount
Maximum lenght	vmwPasswordMaxLength
At least special character	vmwPasswordMinSpecialCharCount
At least alphabetic character	vmwPasswordMinAlphabeticCount
At least uppercase character	vmwPasswordMinUpperCaseCount
At least lowercase character	vmwPasswordMinLowerCaseCount
At least numeric character	vmwPasswordMinNumericCount
Identical adjacent Characters	vmwPasswordMaxIdenticalAdjacentChars

Here is a screenshot of the Lock Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

UI Setting	LDAP Attribute Name
Maximum number of failed login attempts	vmwPasswordChangeMaxFailedAttempts
Time interval between failures	vmwPasswordChangeFailedAttemptIntervalSec
Unlock time	vmwPasswordChangeAutoUnlockIntervalSec

Token Policy

To view the following configuration, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=Tenants,cn=IdentityManager,cn=Services,dc=vghetto,dc=local" -s sub "objectclass=vmwSTSTenant"

Here is a screenshot of the Token Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

Token Policy

UI Setting	LDAP Attribute Name
Clock tolerance	vmwSTSClockTolerance
Maximum token renewal count	vmwSTSRenewCount
Maximum token delegation count	vmwSTSDelegationCount
Maximum bearer token lifetime	vmwSTSMaxBearerTokenLifetime
Maximum holder-of-key token lifetime	vmwSTSMaxHolderOfKeyTokenLifetime

Now that we know how to query for a particular SSO Configuration, here is how you can modify one of these properties. In the example below, we will be changing the life time of a password which dictates the frequency in which you need to change an SSO user's password. Using the "Password Policies" table above, we can see the that property name is called vmwPasswordLifetimeDays

To modify an LDAP entry, we will need to first create a file that contains the change, in the example here we are going to name it change.ldif and it should contain the following where the "replace" keyword shows which property is getting modified and the next line after shows the value that it will be changed to.

dn: cn=password and lockout policy,dc=vghetto,dc=local
changetype: modify
replace: vmwPasswordLifetimeDays
vmwPasswordLifetimeDays: 30

To apply the change, we will now run the following ldapmodify command and specifying our change.ldif configuration file:

/opt/likewise/bin/ldapmodify -f change.ldif -h 192.168.1.70 -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -w 'VMware1!'

If the change was successful, you can confirm by either querying the property again using the ldapquery command or just refreshing the SSO Configurations using the vSphere Web Client.

Configuring VCSA 6.0 as vSphere Web Client Server for vSphere 5.5

04.22.2015 by William Lam // 11 Comments

The vSphere 6.0 Web Client has been greatly improved with the release of vSphere 6.0 which includes a number of performance and UX enhancements. If you are interested in some of the details, be sure to check out this blog post by Dennis Lu, Product Manager of the vSphere Web Client. To really get the best possible user experience and to take advantage of all the new performance enhancements, it is recommend that you upgrade your entire vSphere environment which includes vCenter Server to vSphere 6.0. Having said that, I know this may not be possible for everyone immediately and it will take some time depending on your organizations software upgrade cycles and procedures, qualifications, burn in time, comfort left, etc. with vSphere 6.0 before completely moving over.

Over the last couple of weeks, I have seen quite a few requests from customers who have expressed interest in being able to just use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment as they make their transition over to vSphere 6.0. I can definitely understand where these customers are coming from and honestly, the vSphere Web Client should just be that, a UI Client. We should be able to decouple it from vCenter Server and be able to iterate on it based on feedback from our customers and partners. I did some investigation and I actually discovered that we in fact support something called Mixed-Version Transitional Environment in vCenter Server for Windows Upgrade. This is a bit of a mouth full but basically you can have a hybrid vCenter Server environment that consists of both vSphere 5.5 and 6.0 as you upgrade to full a full vSphere 6.0 environment.

I spent a couple of days researching this topic a bit more to see if I can come up with a solution that would ideally reduce number of changes introduced to a customers existing vSphere 5.5 environment while being able to leverage the new vSphere 6.0 Web Client. After many discussions, prototyping, snapshot reverts and with the help of one of my good GSS buddy G. Blair Fritz, we have come up with a very cool solution using the VCSA 6.0 as a "thin" vSphere 6.0 Web Client Server. The overall goal is to provide a period of time in which customers can use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment and when the time comes for a complete vSphere 6.0 upgrade, this "thin" vSphere 6.0 Web Client can be decommissioned and removed.

Disclaimer: Though this hybrid configuration is supported, using the VCSA as a "thin" vSphere Web Client Server is not officially supported. Please use at your own risk. It is still recommended that you upgrade your existing vSphere 5.5 environment to vSphere 6.0 as soon as possible to get the full benefits of the enhancements made to the vSphere 6.0 Web Client.

Requirements:

vSphere 5.5 running Windows using an External SSO Server
At least one vCenter Server 5.5 pointing to the External SSO Server

Here is the high level workflow as well as a diagram to help you visualize the process:

Step 1 - Upgrade your external SSO from vSphere 5.5 to new PSC 6.0
Step 2 - Deploy VCSA 6.0 and configure it to point the newly upgraded PSC 6.0
Step 3 - Running a configuration script within the VCSA 6.0 to optimize it as a "thin" vSphere Web Client Server

In my test environment, I have deployed a vCenter Server 5.5 which points to an external SSO (also running vSphere 5.5).

Step 1 - The first step is to upgrade the SSO server to the new PSC 6.0, you will follow the existing procedure by mounting the ISO and going through the guided installation. At this point, you can continue logging into the existing vSphere 5.5 Web Client and access your vCenter Server and its hosts and VMs.

Step 2 - Next, you will need to deploy a new Embedded VCSA 6.0 using either the Guided or Scripted Installation. You will need to make sure that it is joining to an existing SSO Domain by specifying the upgraded Windows PSC that you performed in step one. The SSO Domain Name should be vsphere.local as this was not a configurable option in earlier vSphere releases. At this point, you can now login to the VCSA 6.0 which provides the vSphere 6.0 Web Client but you will notice that you only see an empty inventory of the new vCenter Server 6.0 as well as an error message stating "Login failed due to invalid credentials for one or more vCenter Server systems"

The reason for this is that you need to restart the vpxd service on your vCenter Server 5.5 for it to be visible in the new vSphere 6.0 Web Client.

Note: It is important that if your external PSC is joined to an Active Directory Domain that you ensure the NTP Server specified in the VCSA 6.0 deployment also points to the same AD Server for the time source to be synchronized else you will run into problems later.

Step 3 - Login to your vCenter Server 5.5 and restart the vCenter Server service using the Services utility.

Step 4 - Once the vCenter Server service has restarted, you can now open a browser to the Hostname/IP Address of the VCSA 6.0 and you will see both vCenter Servers. You can now manage your vSphere 5.5 environment using the vSphere 6.0 Web Client.

I was pretty happy when I got this solution working but I was still not content. The smallest deployment size for an Embedded VCSA requires 8GB of memory, which is still a considerable amount of resources in my opinion. I wanted to optimize it further by turning off unnecessary services, modify the memory requirements for the unused services as well as un-registering the vCenter Server 6.0 endpoint so that you only see your vSphere 5.5 vCenter Servers only. Surprisingly, this took up the bulk of our research to figure out what could be turned off, how to properly turn it off and then un-registering the VC endpoint.

I have created the following shell script called setup_vcsa_as_webclient_client.sh which needs to be uploaded to the VCSA (need to enable Bash shell on the VCSA). The following three variables must be updated prior to running:

PSC_SERVER - The Hostname/IP Address of your external PSC
SSO_USERNAME - The SSO Administrator account
SSO_PASSWORD - The SSO Administrator password

Once everything completes successfully, you should turn off your VCSA and modify the memory from 8GB to 3GB. From my limited amount of testing, the overall memory utilization was sitting around ~2-2.5GB of memory, so I think configuring it to 3GB should be plenty and you can always adjust accordingly. Since we have disabled all the unnecessary services, the VCSA boot time should be pretty quick and now when you login to the vSphere Web Client, you should only see your vSphere 5.5 vCenter Servers and nothing else.

When the time comes and you are ready to fully upgrade your vSphere 5.5 environment to vSphere 6.0, you can decommission and remove this "thin" vSphere Web Client Server by following the procedure outlined in this VMware KB 2106736. I think it would be really nice to be able to update the vSphere Web Client outside of updating vCenter Server and truly providing a "client" that is decoupled. What do you think?

vCenter Host Gateway ... more than meets the eye

04.10.2015 by William Lam // 9 Comments

While going through the download motion like many of you when vSphere 6.0 was generally available, something that caught my eye in the vCenter Server download area was something called the vCenter Host Gateway (vCHG) virtual appliance. At first, I did not know what that was and until I spoke to a few colleagues did I realize that vCHG is the evolution of the Multi-Hypervisor Management (MHM) Plugin which provides vSphere Administrators a way to natively manage Hyper-V hosts within the vCenter Server UI. MHM was originally released as a Fling and later then productized within the vCenter Server product. At the time, it made sense for the plugin to be Windows based as it needed to connect to Hyper-V which obviously ran on Microsoft Windows.

It looks like the folks over in the MHM team have been quite busy as they have gotten rid of the Windows installer and have now provided a Virtual Appliance which uses winrm to directly communicate to the Hyper-V hosts. In addition, you can now manage Hyper-V hosts within the vSphere Web Client where as previously it was only available using the vSphere C# Client. vCHG works with both vCenter Server for Windows as well as the vCenter Server Appliance, there are no additional Windows host required for this new solution. Deploying and configuring vCHG is relatively straight forward and you can find all the instructions here. There were a few minor gotchas that I ran into and I thought it would be worth sharing, especially figuring out what was needed on the Hyper-V hosts which was mainly due to my lack of familiarity with winrm.

You have the option of configuring winrm to go over standard HTTP (port 5985) or HTTPS (port 5986) on the Hyper-V host but the latter requires you to setup SSL Certificates which you can find more details here. For that reason, I just went with the default HTTP method to quickly get going. To configure winrm, you will need to run following command and accept the default with "y":

winrm quickconfig

Next, you will need to enable winrm listener as shown in the screenshot below by running the following command:

winrm e winrm/config/listener

At this point, you can now login to your vSphere Web Client and to add a Hyper-V host, you will need to add at the vSphere Datacenter level. This was another thing that I missed and though could be added into its own vSphere Cluster. As you can see from the screenshot below, we have extended our "Add Host" workflow to natively support Hyper-V hosts, so that it is intuitive and familiar for our vSphere Administrators.

You will need to specify both the Hostname/IP Address of Hyper-V host followed by the winrm port (e.g. hostname:5985) and then select the Type to be "Hyper-V" and in a just a few seconds, you will be able to see your Hyper-V hosts within vCenter Server and perform basic power operations as well as creating/managing VMs running on Hyper-V. Below is a screenshot of my Hyper-V host and I just finished created a new VM using the vSphere Web Client and you can see it seamless integrated into a single view.

This is great enhancement for customers who have to run a mix workload between vSphere and Hyper-V (I do apologize to those in advance ;)) but at least you now truly now have a single integrated pane of glass to manage all your workloads. I also do want to stress the word "integrated" beyond just the UI component that vCHG provides. I have found that all the operations through the vSphere Web Client is also exposed through our rich vSphere API, for example the AddHost_Task() method now includes a new hostGateway spec. This also means you will be able to use all the existing power operations and create VMs methods against your Hyper-V hosts, again tightly integrated into the existing tools you are familiar with such as PowerCLI for example for Automation. How freaking cool is that!?

but wait ... there's more! 😀

While going through the exercise of deploying vCHG and adding Hyper-V host, I could not help but wonder why we named this feature "Host Gateway", especially since we only supported a single third party hypervisor, did not really make sense to me? Well, it turns out there is a lot more coming! When you select the "Type" from the drop down menu, I notice there were a few more options: KVM and vCloud Air!

I of course I tried to add a KVM host as well as my vCloud Air account but looks like those providers are not available just yet. I am actually quite excited to see support for vCloud Air. This has always been something I felt should have been available natively within the vSphere Inventory so that an administrator could deploy their workloads either locally on-premises or hosted on vCloud Air without having to jump around. It should align with the existing vSphere Administrator workflows and I am glad to see this change. This is definitely an area that I recommend keeping an eye out on and hopefully we will see vCloud Air support soon!