VMware vSphere: vCenter Single Sign-On (SSO)

One of the key pieces to administering a vSphere infrastructure is being able to assign administrative permissions on vSphere resources. Managing logins and permissions in a VMware vSphere vCenter Server environment is critical to not only allowing granular permissions on resources but also providing an audit trail of actions that are being performed within the vCenter environment.

Let’s take a look at key features to assigning permissions including vCenter Single Sign-On, Active Directory, roles and permissions assignment based on these.

vCenter Single Sign-On (SSO)

Prior to vSphere 5.1, vSphere authentication was either via the local security authority on vCenter server or via Active Directory. However, starting with vSphere 5.1, VMware introduced Single Sign-On or SSO to address the problem of being able to manage multiple ESXi hosts and other vSphere resources with the same user credentials. SSO allows not only Active Directory authentication but also any other Security Assertion Markup Language (SAML) 2.0 based authentication source. SSO authentication also improves security and agility of the VMware vSphere authentication mechanism by allowing token based authentication.

SSO is also important as today’s suite of VMware vSphere products integrate with the SSO authentication piece with vCenter. This allows for resources across the suite of products to be controlled/granted for a particular user with SSO.

The SSO piece of the vCenter infrastructure is handled by the Platform Services Controller VM when vCenter is installed. The platform services controller is configured during the configuration of the VCSA appliance. The PSC can be configured as the Embedded Platform Services Controller or can be configured as an External Platform Services Controller.



The Single Sign On domain for vSphere is also configured during the deployment of the VCSA appliance. The SSO administrator, password, SSO Domain name, and SSO Site name are configured during the install.



The SSO domain is the default identity source of the vSphere environment when no other authentication domain is specified such as Active Directory. As already mentioned, it provides a token exchange mechanism for authenticating with identity sources such as AD, etc. Another item to remember when thinking about setting up your SSO domain is that this should not be the same as your Active Directory domain name and can cause issues if you set the SSO domain to mirror the AD domain name. Many choose an SSO domain name with *.local” as the suffix.

The SSO domain is a critical part of any vSphere architecture that provides the necessary mechanism to simplify and centralize access control and privilege management across the board with the vSphere family of products.

ESXi vMotion Network Configuration

Another very important network that needs to be configured when multiple ESXi servers are in a cluster configuration is the ESXi vMotion network (a concept we will discuss in our next post).

The ESXi vMotion Network Configuration enables live migration of running virtual machines from one ESXi host to another ESXi host. This allows for high availability of service for VMs running in the vSphere environment and moving VMs due to hardware maintenance, updates, or other service interruptions at the physical layer. VMs can simply be moved to another host with no interruption.

We have to have a Port group on a vSwitch that is enabled for vMotion in order to successfully vMotion a VM to another host. That host, of course, would need to have a vMotion network setup as well for the move to be successful.

The steps to configure the vMotion network are similar to configuring iSCSI storage networks, with a few subtle differences. Click on the Add Networking link in the upper right hand corner.


To create the vMotion vSwitch, we select VMkernel as the connection type.


Select the vmnics we want to assign to the vMotion vSwitch.


We name our first vMotion Port group. We will have one port group per vmnic that we are assigning to the vSwitch for vMotion. Also, note we are checking the box next to Use this port group for vMotion.


Next, we assign our IP Address settings.


We finish out our configuration of the first port group in the new vMotion vSwitch.


Add the second port group by viewing the properties of the vSwitch we created and click Add.


We select that we want to use this port group for vMotion. After that, we need to assign an IP address to this VMkernel configuration.


As we finish out, we see both port groups created.


Again, we need to go into the properties of both the vSwitch and the port groups and make the change to jumbo frames.

Multi-NIC vMotion

To enable multi-NIC vMotion so that even vMotioning 1 VM will utilize multiple links, Under the NIC Teaming tab in the properties of both our port groups we need to select Override switch failover order and move the second adapter to Standby Adapters. We do the opposite for our second port group.

Thoughts

As mentioned, the vMotion network is an important network configured on our ESXi host as it will allow multiple ESXi servers configured in a cluster to live migrate VMs between their compute resources. In creating the vMotion network, we utilized the VMkernel ports making sure we enabled jumbo frames, as well as setting our NIC teaming so that multiple network adapters would be utilized during the vMotion process. In the next post, we will take a look at the VM network.

VMware Cluster. DRS Configuration

In the previous post, we looked at the importance of utilizing the VMware vSphere ESXi cluster to unlock the true potential of what VMware ESXi can do in the enterprise. One of the key advantages with the VMware cluster configuration is the efficient management of resources. The vSphere cluster technology that makes this possible is VMware DRS or distributed resource scheduler.

VMware DRS is designed to manage a cluster’s available resources effectively and efficiently. DRS can proactively manage resources in the cluster so that the load between hosts is more evenly shared. Also, DRS rules can make sure that certain VMs or groups of VMs are always on different hosts or the same hosts. Also, new to vSphere 6.5, DRS can take network bandwidth into consideration when scheduling resources to prevent oversubscription. When a host is added to a DRS cluster, the host’s resources become part of the cluster’s resources and is managed accordingly. This allows for the use of cluster-level resource pools and resource allocation policies. Resource pools allow you to allocate resources according to your needs, policies, or VM requirements. Resource pools can allow some VMs to have access to more hardware resources and others less resources.

Requirements for DRS include the following:

• Shared storage
• Processor compatibility – since DRS utilizes vMotion, the vMotion process transfers the running CPU state between the various ESXi hosts, requiring that destination hosts have at least the equivalent CPU instruction capability
• Hosts in the cluster must participate in a vMotion network

DRS Configuration

In the vSphere vCenter 6.5 Flash Web UI, the DRS and HA options are configured using the Configure tab of the cluster. Click vSphere DRS and then Edit.


We are presented with a simple checkbox where DRS can be enabled.


If we drill into the DRS settings a bit more, we can customize the behavior of DRS within our VMware cluster. The automation level can be selected to decide how much control DRS has over migrating resources.


New to DRS in vSphere 6.5, there is a Predictive DRS that allows DRS to interact with vRealize Operations Manager to actually predict the moving around of VM resources based on vROPs.

After we select our DRS options, we can select OK and the VMware cluster will be configured for DRS.

Thoughts

VMware DRS technology allows efficient and effective resource management of multiple hosts in the vSphere cluster. As shown, the feature is easily enabled and is very intuitive to configure. The new features of vSphere 6.5 also allow the technology to be predictive and proactive. The other very important technology feature that is enabled with the vSphere cluster is VMware HA or high availability. In the next post we will take a look at this other key VMware vSphere cluster feature.

Configuring a VMware ESXi Cluster

In a VMware ESXi cluster configuration, multiple ESXi hosts provide compute, memory, and network resources to the cluster environment as a whole, as well as protect cluster-housed VMs against physical server failures. This is accomplished by using a VMware vCenter Server (a requirement to create a VMware ESXi cluster). Once created, a vSphere cluster enables “cluster only” features such as HA (high availability) and DRS (distributed resource scheduler). Each of these features contributes to the tolerance of the VMware cluster withstanding failures as well as distributing resources across the VMware ESXi hosts. We will take a look at both of these in detail in upcoming posts. First though, let us take a look at the process of creating a VMware ESXi Cluster.

Creating a VMware ESXi Cluster

The configuration process for creating a VMware vSphere ESXi cluster is fairly straightforward. The main requirement is that you have a VMware vCenter Server up and running as well as have network connectivity to the intended ESXi hosts that are to join the cluster.

Let’s take a look at the steps to create a cluster once we have connected to the Web UI of our vCenter Server.
Right click on your vCenter server in the Web UI and choose New Datacenter. The datacenter object contains all the different types of objects needed to do work in the virtual infrastructure – hosts, VMs, networks, datastores, etc.



Next, we assign a Datacenter name:

How to Create a New Cluster

Once the datacenter is created, we can choose to create a New cluster.


We assign a cluster name.


Once the cluster object is added, we can Add Hosts to the Cluster object. Once we add a host to a cluster, the host’s resources become part of the cluster’s resources. The cluster manages the resources of all hosts.


The Add Host wizard begins and we enter the name or IP address of the host to add to the cluster.


Provide the credentials to access the host.


You may receive a certificate alert. Simply click Yes to continue connecting. This is a common warning with self-signed certificates present on the hosts by default. We can safely ignore this warning.


The Host summary screen shows us any VMs that are present on the host if any.


We have the option to select the license we want to use on the host. You can simply choose the evaluation license to continue with the trial license which is good for 60 days.


Lockdown mode prevents remote users from logging into the host directly. This option is available for a more secure posture with the ESXi hosts. This can be enabled later as well.


Finally, we are ready to add the host. We will continue this process for all the hosts we wish to join to the cluster.


As you can now see, we have a datacenter, cluster, and our two ESXi hosts joined to the cluster.

Thoughts

To unlock the true potential of a VMware ESXi hypervisor environment, utilizing the VMware vSphere cluster functionality is key. Running VMware ESXi in the cluster configuration with VMware vCenter server allows you to utilize the enterprise datacenter VMware vSphere technologies including HA (high availability) and DRS (distributed resource scheduler). Both of these technologies contribute to the tolerance of the VMware cluster withstanding failures as well as distributing resources across the VMware ESXi hosts. In the standalone VMware ESXi configuration, this is not possible.
Next, we will take a look at VMware DRS.

How to find Windows Product Key using Command Prompt or PowerShell

Recover Windows product key using Command Prompt

From the WinX Menu in Windows 10 / 8.1, open an elevated command prompt window, type the following command and hit Enter:

wmic path softwarelicensingservice get OA3xOriginalProductKey

Your Windows product key will be displayed.